Truly decentralized NFTs by ERC-1155
By Sönke Bartling inspired by Titusz Pan
In this post, we will describe a method to truly decentralize NFTs by means of the current token standard ERC-1155.
NFTs provide a means to establish publicly verifiable ownership of easily reproducible digital goods such as pictures, videos, animations, and such. Furthermore, they are used to convey ownership of abstract things such as intellectual property rights.
Since storage on the blockchain is expensive, the NFT payload, such as name, attributes, and artwork is stored in another location and called NFT metadata. The smart contract provides a reference to the storage location.
Most current NFTs are being criticized for being centralized as their metadata and payload is being stored on centralized servers. It is therefore prone to centralized control. This makes blockchain and the idea of immutability at least somewhat ‘questionable’.
Metadata can be stored on IPFS to decentralize an NFT. Doing so prevents centralized control over it. If metadata IPFS files are pinned at least somewhere on an online computer they cannot get lost. For long-term IPFS storage check out Filecoin or Arweave.
The problem with the current way IPFS is being used together with the ERC1155 standard is that all metadata of all the tokens that are being minted with the contract need to be defined at smart contract deployment. Minting novel tokens after deployment is not possible. This is in contrast to the idea to reuse token smart contracts on the blockchain to issue low-gas-cost NFTs. Here we provide a solution for that.
How metadata is stored and retrieved in ERC-1155
A smart contract address and a token ID uniquely define an NFT and are stored immutably on the blockchain.
The ERC 1155 metadata address is defined at the deployment of the smart contract.
The metadata for a defined NFT (TokenID@smart contract address) is being read by marketplaces by calling the publicly available URI function of the smart contract. Today's market places expect a directly resolvable URI string back.
For a (bad:)) centralized NFT it returns the metadata location in the form of
HTTP://centralizedserver.com/TokenID
and as long as the centralized server is being updated with the metadata for each new-minted token (TokenID) beautiful art and animations are being displayed in marketplaces.
Sure, one could return something like
ipfs://contendidentifierhash/TokenID
But as a friendly reminder, IPFS can only provide an immutable hierarchical file system structure that looks like a read/write file system but without the writing part. While it is tempting to try to somehow store a new TokenID under the contend identifier hash this is just not possible. It would need a complete change of the contend identifier hash and hence a novel smart contract deployment on the blockchain. Don´t get me wrong, if all tokens and TokenIDs are set at the time of the smart contract deployment, this is a great way to decentralize, eg. an ERC-721 token. However, new tokens cannot be minted afterward.
IPNS — also not a good idea.
At first glance, one might be tempted to solve this problem by using IPNS — and redirecting the IPNS to a new contend identifier hash full of metadata(s) after each new minting process. However, this would again hand the control of the metadata to a central third party, namely the holder(s) of the private keys to change the IPNS — so not a good idea either.
Heureka: Using the TokenID as IPFS content hash
So, let's recall what we have available on the blockchain. A token address: not useful — it is a given beyond our control. So all information needs to go in TokenID and URI which we can be freely defined: URI can´t change over the lifetime of the deployed smart contract, but TokenID can. So why can´t the TokenID be a pointer itself to the metadata — an idea by Titusz Pan? We would then just add “ipfs://” in front… which is well possible….
TokenID=IPFScontentidentifierhash
And as we will see — it truly can! :)
But first, we have to look how ipfs content identifier looks like. CID (=contentidentifierhashes) come coded to the base58. CID like this one looks familiar to us.
ipfs://bafybeigbl5trfojjfuynhcehzgjtupqlehyiovdeymenuhjojyq3n2oal4/guides/concepts/cid/
A CID as base58 encoded hash does not make a great TokenID, I doubt that Solidity can handle base58 natively. But thanks to Version 1 , CIDs can have many different formats, identifiable by different leading multi-base identifiers characters. Decimal CID would make a perfect TokenID, however, decimal denominations of CID are work in progress at the time being. On the contrary, the hexadecimal denomination is well implemented into the current version of IPFS and solidity can handle hex numbers pretty well — so why not stick with hex. We will do so in the following.
Creating a TokenID that is a full IPFS CID
So let's take this metadata for our beautiful proof-of-concept token.
We create a CID V1 by adding “cid-version=1 hash=blake2b-208”.
$ ipfs add MetaDataIPFSToken.json cid-version=1 hash=blake2b-208
added bafkzvzacdkm3bu3t266ivacqjowxqi3hvpqsyijxhsb23rv7nj7a MetaDataIPFSToken.json
Than convert it to hex “-b=base16”.
$ ipfs cid format -b=base16 bafkzvzacdkm3bu3t266ivacqjowxqi3hvpqsyijxhsb23rv7nj7a
f01559ae4021a99b0d373d7bc8a80504bad782367abe12c21373c83adc6bf6a7e
Without the leading “f” this gives a wonderful token ID.
What is still necessary is to tweak the ERC 1155 URI function a bit to give back a full ipfs URL with hex number (and leading “f0”) in a string.
A ERC-1155 standard contract would then look like this:
And it worked!
Open sea and Rarible loaded our completely decentralized metadata. And by calling the mint function with the right TokenID we can create new decentralized ERC1155-NFTs as long as we don´t run out of gas … and without the need of deploying new token contracts to the blockchain.
Disclaimer: This has been tested only on testnet AND there are many more ways to provide a unique CID to a given TokenID … but we think that this way is the closest to the ERC1155 standard. Furthermore, we did not analyze the gas costs for minting new tokens with long TokenIDs on the blockchain.
