Intro
Let’s start by saying that NFTs (non-fungible tokens) are tokens, initially used to represent unique digital works, which today are also widely used in other areas such as industrial ones. In Pomiager we have created a series of applications which allowed to associate an NFT with an electric motor to make available all the information relating to the production process of the reference asset. The problem we faced was that of having to add other metadata to the NFT to add information relating to the life-cycle of the engine (maintenance operations, repairs, etc.). By its nature, however, the NFT, once minted, keeps the reference to the url containing the metadata immutable. Here then we tried a truly effective solution, Tableland, which allows us to use a real database to contain the history of the engine, but at the same time have the same guarantees of immutability as the blockchain.
Tableland
To understand what Tableland is, we report the definition directly from their site:
Tableland is a web3 SQL database that can be used on EVM chains like Ethereum and Layer 2 (L2) solutions. It helps extend and enhance data storage while offloading accessibility to a decentralized network of validator nodes that watch the host chain for updates, which is where SQL data is made available. Developers can use Tableland to help scale, mutate, and effectively access chain-driven data—including on-chain rules and identity—across Ethereum, Optimism, Arbitrum One, Arbitrum Nova, Polygon, and Filecoin.
In practice Tableland decomposes a relational database into two components, one on-chain and the other off-chain. The two components consist of
- On-chain registry with EVM account-based Access Control Logic (ACL).
- A network of permissionless databases running a web3-limited SQLite.
The idea is that of associating (minting) a collection of NFTs via an ERC721 for each table, which is thus associated with the owner-creator of the collection. This table can be designed to hold any type of data such as integers or strings and the insertion is controlled with the privileges of an ACL as in any ERC721. However, the data is not stored in the Blockchain but in a distributed structure (Tableland network) in a SQLite format.
CRUD operations are transmitted to a predefined Tableland smart contract (already deployed in various blockchains) which emits the corresponding events containing the string with the statement and the security policy to check whether the operation can be performed or not.
These events are collected by the Tableland infrastructure and run on all distributed nodes. It is interesting to note that the entire history of the CRUD operations performed on the table remains in the blockchain, so that at any time it is possible to recreate the history of the data from their creation up to the last operation. Now you can use an entrypoint gateway to query the distributed database and get the data. This is the scheme we used for our app:
Dynamic NFT
And we come to our application. We decided to create an ERC721 collection with references to the Tableland smart contract deployed on the Polygon Mumbai network with address 0x4b48841d4b32C4650E4ABc117A03FE8B51f38F68 (see the documentation for the other addresses relating to Blockchains compliant with the Tableland project). In the constructor we have inserted the creation of two tables connected to each other in a one-to-many relationship thus structured:
As we can see, the tables respectively contain the id of the new NFT just minted and its unique name (or the identification code of an asset or its serial number), while in the other table we have the url of the metadata, a timestamp (unix epoch time) and the reference (foreign key) to the token id. Every time we want to add a new metadata document we simply insert a row with the new url, timestamp and NFT id.The query we need to perform to retrieve all the metadata relating to the token id ‘0’ is as follows
https://testnets.tableland.network/api/v1/query?statement=SELECT json_object(‘uri’,metadataurl,’startdate’,startdate) FROM metadata_80001_6381 WHERE tokenid=0
Note the name of the table which consists of a custom prefix, the id of the chosen network (in our case 80001 Mumbai) and the ID of the NFT minted when the table was created.
Below is the result of the query carried out with Postman
Conclusion
The use of Tableland, although still a structure that has to fully enter its production phase, seems to work really well and allow the use of a DB infrastructure in Web3 applications of any type, from DAOs to Gaming development
