Author: 0xEstarriol, Harry

TL;DR

• Like ERC721 tokens, each ERC1155Delta token is unique.

• Compared to the ERC721A, ERC1155Delta saves ~39% in minting 5 tokens and ~87% in burning 5 tokens.

• ERC1155Delta uses less storage space than most of the ERC721 implementations. ERC1155Delta also releases the storage space of the tokens that are no longer accessible. In addition to the gas refund, ERC1155Delta has less impact on the blockchain storage space.

• With the ERC1155 standard, ERC1155Delta provide batch transfer by default.

• The interface of ERC1155Delta is designed to be as close as possible to ERC721A, so developers can adopt it easily.

• ERC1155Delta is released under the MIT opensource license and free to use. As for commercial support, it is available through Ctor Lab. More information can be found on https://erc1155delta.ctor.xyz

Gas saving strategies & Prior works

One of the most common strategies of optimizing smart contracts is to reduce writing to and reading from the ethereum virtual machine (EVM) storage as these two actions are the most expensive ones.

ERC721A uses a very clever strategy on saving gas on the minting. When a user mint NFTs in a batch, it only stores the ownership information of the first token in the batch to the storage slot. The ownership of the remaining tokens are implicitly defined by the first slot.

Shown in the figure is the storage layout of the ERC721A, each box in the figure represents a storage slot. We can see Alice owns 3 tokens, but Alice’s address is only written on the storage slot of the first token. If the ownership of the third token is queried, the contract will search the storage slots of previous tokens one by one until it finds the information, and in this case it is in the first token’s storage slot.

ERC721A truly shines on minting. It helps the Ethereum community save millions during the moments when the gas price spikes. As a result, it is widely adopted by NFT developers and considered one of the go-to options other than Openzeppelin’s SDK.

However, implicit ownership also comes with its downside.

First, if the batch size of a mint is big, it will require multiple readings from the storage slots to query the ownership information which often results in expensive transactions. One of our previous works, ERC721Psi, manages to solve this scaling issue by using an additional bitmap and de Bruijn sequence to quickly locate where the ownership information is stored. More details about its implementation can be found in the lite paper.

Second, the transfers that touch the virgin storage slots are more expensive. To better illustrate what this means, let me give you an example. Shown in the figure below, it visualizes how the information in the storage slot changes when Bob transfers token #6 to Chad. The storage slot of token #6 now needs to be filled in with Chad’s ownership information. In addition, the original batch becomes discontinuous now, and therefore it needs to explicitly write the ownership information of token #7 to the storage. Consequently, the gas saving from the minting is paid back during the transfer. ERC721Psi also falls short on that as it also uses implicit ownership internally.

The problem is compounded when the burning of NFTs is involved. For the traditionally-used Openzeppelin’s ERC721 implementation (OZ ERC721 in the figure), the ownership information is explicitly stored. As the example in the figure below shows, when burning token #2, Openzeppelin’s implementation simply releases the storage slot of token #2 (writing 0 to the storage slots), and when the storage slot is released the user gets the gas refund. The existence of gas refunds is to incentivize developers to free storage if they no longer need it.

On the other hand, zero has a different meaning in ERC721A. Zero represents implicit ownership. When token #2 is burned, ERC721A instead of freeing the storage slot, writes the burned information to the storage slot. As for ERC721Psi, it maintains a separate bitmap which efficiently tracks the burning information of the tokens. However, it also doesn’t release the storage slot.

Introducing ERC1155Delta, the holy grail of NFT implementations

We’ve discussed the existing implementation and their strategies on reducing gas consumption. Each implementation comes with its pros and cons. At Ctor Lab, we are constantly thinking if there is the holy grail that satisfies all these nice features.

• fixed gas usage in batch minting.

• fixed gas usage in transfer.

• Gas refund from burning tokens.

Finally, we are glad to announce the solution we found. We called it ERC1155Delta which is named after the Kornecker delta function, a mathematical function that only has non-zero value at a given point. We hope you will find it depicts the underlying mechanism well after reading this article.

Instead of using the ERC721 standard, ERC1155Delta is built on top of the ERC1155 standard. Same as ERC20 and ERC721, ERC1155 is also a token standard. It allows developers to create both fungible tokens and non-fungible tokens with a single deployed contract. Traditionally, ERC1155 is used to build tokens that have multiple editions. For example, adidas Originals Into the Metaverse, all the tokens in the same phase are the same.

If one wants to use it for non-fungible token applications, Openzeppelin’s existing implementation doesn’t provide gas advantages. On the contrary, ERC1155Delta achieves significant gas savings by restricting itself to pure non-fungible token applications. Like ERC721 tokens, all the tokens created with ERC1155 are non-fungible, each ERC1155Delta token is unique.

Unlike ERC721A, the gas saving in the minting of ERC1155Delta doesn’t come from the implied ownership. Instead, ERC1155Delta saves gas by compactly encoding the ownership information. Each user has a bitmap that records the token the user owns. When a mint user mint NFTs, ERC1155Delta wrote consecutive “1”s to the user bitmaps. Since an EVM storage slot consists of 256 bits, the cost of minting up to 256 NFTs is essentially the same!

For instance, as the figure below shows, on Alice's bitmap, the 3rd, 4th, and 5th bits are set to “1”. This indicates Alices owns tokens #3,# 4, and #5. As for Bob, he owns tokens #6 and #7. The internal logic of ERC1155Delta ensures no two users can own the same token simultaneously.

When token transfer happens, ERC1155Delta sets the bit in the original owner’s bitmap to 0 and the bit of the new owner at the same index to 1. The process is efficient and doesn’t need to cross multiple storage slots to verify the ownership information. As you can imagine, it is even simpler for burning. ERC1155Delta simply sets the bit to zero. When all the tokens corresponding to a storage slot in the bitmaps are fully cleared either through transfer or burning, the user receives the gas refund.

ERC1155Delta token leaves no residue after burning. Apart from gas saving, we believe releasing the storage slot is for public goods. By releasing the storage slot, it reduces the burden of the blockchain storage space. Before danksharding comes out, every single validator needs to keep a copy of the whole blockchain storage state. For the implementation that cannot release the storage space, even if the burned tokens are no longer accessible, their information is still occupying hundreds of thousands of validators' hard disks. (Even after danksharding comes out, it still helps, as the validators still need to keep part of the data.)

When we design the ERC1155Delta, we provide an experience that is similar to using ERC721A for the developers. Functions like, _nextTokenId, _numMinted, _startTokenId are all supported, and most importantly, the mint function also has an identical interface.

As for ownership verification purposes, instead of having ERC721’s ownerOf(uint256 tokenId) method. ERC1155Delta defines a new method isOwnerOf(address account, uint256 id) which checks if an account is the owner of the token.

Like ERC721A, we also provide a queryable extension, so the front developer can use it to query all the tokens belonging to a user.

To write an ERC1155Delta and ERC721 agnostic DApp for the NFTs, we provide a library for wrapping the NFT contract call. The wrapper automatically identifies the contract interface and makes the correct function calls. If interacting with legacy DApps that only support ERC721 is required, we’ve also developed a contract that allows the user to convert their ERC1155Delta tokens to ERC721 tokens (and back to ERC1155Delta).

Case Study: Elysium Shell’s ESNX Mecha

ESNX is Elysium Shell's Generation 2 PEP Characters. ESNX brings the fun experience of assembling models from the real world to NFTs. Holders can voluntarily choose five different NET parts (head, body, arms, legs, equipment) to assemble into an ESNX mecha. The assembled ESNX mecha can be interacted with and browsed on OpenSea in 3D format. At the same time, ESNX holders will receive well modified 3D files (GLB, VRM, FBX) that are compatible in various metaverse scenarios.

When we designed the smart contract of the ESNX component, we implemented it with ERC1155Delta.

If ERC721A is used for building the ESNX component tokens, the cost for minting would not grow significantly compared to using ERC1155Delta, as ERC721A has already been optimized for batch minting. The cost for minting five tokens is very close to minting one token. However, holders may trade their component tokens, and the gas saved during the minting is now added back to the token transfer.

Moreover, during the second stage, burning ERC721A doesn’t give the user the gas refund. Instead, it is much more expensive as it needs to write the extra information to the storage slot of all 5 tokens. The burned tokens are no longer accessible but the storage slots used by the tokens are never released.

On the other hand, using ERC1155Delta for the ESNX components provides lower minting cost while maintaining the low gas usage in both transfer and burning. When the ERC1155Delta tokens are burned for assembling the ESNX Mecha, the information of the component token is wiped out from the EVM storage slot, and the gas for using the storage slot is refunded back to the user.

Benchmark

Our Methodology:

• To better benchmark the gas usage close to the real world scenarios, we always mint at one token with a separate account to ensure the global internal states are initialized, for example, the counter for tracking the number of minted tokens.

• We chose to compare the gas usage excluding the 21000 base gas. This 21000 base gas is the minimum gas for a transaction on a chain, and it is independent of the smart contract execution.

Mint

We show the benchmark of minting multiple tokens with a single transaction.

For minting 5 tokens, ERC1155Delta uses about 39% lower gas than ERC721A.

Keen readers may notice the growth rate of ERC1155Delta’s gas usage is lower than the two ERC721 implementations. This is because ERC1155Delta leverages ERC1155’s standard to emit a batch transfer event instead of multiple single token transfer event while minting multiple tokens to the same user.

Airdop

ERC1155Delta is about 35% less in gas usage per token than ERC721A, and whereas ERC721Psi is 45% less. ERC721Psi and ERC1155Delta use similar amounts of storage during the airdrop. The difference between ERC1155Delta and ERC721Psi mainly comes from the check if the receiver is a smart contract. The check is mandatory in the ERC1155 standard, but not in the ERC721 standard.

Burn

For burning 5 tokens, ERC1155Delta uses about 87% lower gas than ERC721A. This comparison is without a gas refund. If there is a gas refund (e.g. burning all the tokens one owned), the gas usage will be 4800 lower in the current Ethereum version (after London hardfork / EIP-3529).

Transfer

In this comparison, we transfer different tokens from the same minting batch. We can see ERC721A’s gas usage increase for the token with higher token ID. A more detailed discussion can be found in ERC721Psi’s lite paper. In general, ERC1155Delta saves about half of the gas in transfer.

Conclusion & Roadmap

• ERC1155Delta offers lower gas usage in batch minting, transfer, and burning than existing NFT applications.

• Since the ERC1155 standard is now widely supported across different NFT marketplaces, including Opensea, LooksRare, X2Y2, we at Ctor Lab recommend using ERC1155Delta for most of the NFT application that requires batch minting, including arts, PFP. ERC1155Delta is especially powerful for the application that requires burning of the token. For example, RTFKT’s forging token, Tom Sachs’s Rocket Factory. However, if your application requires ERC721 interface, ERC721A and ERC721Psi are both great choices.

• The ERC1155Delta uses solidity-bits, a library developed by one of the author, 0xEstarriol, for bit operations. In the future, once we are done with more testings, we may switch to vectorized.eth‘s solady to make ERC1155Delta more gas efficient.

Acknowledgement

ERC1155Delta directly uses or modified the code from the following projects.

• Openzeppelin SDK

• ERC721A