Application of NATs to NASs
Last updated
Last updated
Since these two artefacts are both defined from the same data set, they work very naturally together.
A good example would be to use a NAT to represent a resource such as gold in the landscape. This could ensure that gold is deposited in non-arbitrary locations, and is mined along with each new block should the NAT’s element be present. Even the ‘hybrid token’ function can be used, whereby the location of each token is non-fungible, but the trade value remains fungible.
NATs could also be used to define the landscape itself, whereby a NAT increases the elevation around the block it matches to.
An example of this is in Figure 8 below. The features of the NAS are determined by the NAT in the following table:
Elevation source
Transaction count
(none-whole field)
-.14.element
824544
Elevation weighting (~Mountain peak location)
Merkel Root Hash
“2009”
-.2009.7.element
812
9339603183ff7a267eb4fa98920097979520a6c400bc771f50cb81de1b481867
Gold resource location
Merkel Root Hash
“10409”
-.10409.7.element
52
43da91cac10a1a4fb09d5a1893477c8f99104096ccfc06645a7133180b48e9d8
The choice of transaction counts and Merkel tree hashes creates two different data source types. Transaction counts roughly correlate to network utilization, which generally increases with height (block count) up to the bandwidth of the network. Merkel hashes however are pseudo-random in nature.
The gold resources however are pseudo-randomly distributed throughout the space, but are fewer in number since a longer pattern is used.
The image below represents a landscape define by the NAS above, with texture procedurally generated based on surface height and gradient.
(Block ) has tx_count of 457
(Block )
(Block )
This NAS therefore has mountain peaks in pseudo-random locations, with heights getting larger as block count increases (the first block with a transaction count of 1000 doesn’t occur until height )
