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:
| Feature | Block Field | Pattern | Element registry | Quantity | Example Match |
|---|---|---|---|---|---|
Elevation source | Transaction count | (none-whole field) | -.14.element | 824544 | (Block 210 000) has tx_count of 457 |
Elevation weighting (~Mountain peak location) | Merkel Root Hash | “2009” | -.2009.7.element | 812 | |
Gold resource location | Merkel Root Hash | “10409” | -.10409.7.element | 52 |
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.
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 226804)
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.
