Here Be Dragons : Going Beyond ERC-20 and ERC-721 To Reduce Gas Cost by ~80%

TL;DR : We’ve designed and implemented a token contract which allows us to transfer bundles of different types of tokens for 80% to 90% less gas than ERC-20 and ERC-721. This is accomplished by “packing” different token balances together, saving a substantial amount of storage space on the blockchain. One trade-off is that the maximum user balance for each token type is lower, however this can be adjusted to be made acceptable for many projects. Multi-class token contracts are particularly interesting for the gaming world, where transferring bundles of items (sets, decks, etc.) is common. — PhABCD @ Twitter


Ethereum Token Standards


ERC-20 Standard: Fungible Tokens

Standardization is important for developers as it makes our life much easier. Imagine if each laptop had a different keyboard layout and you couldn’t change it. It would be quite painful indeed and hence why standardizing some interface (e.g. keyboard) is important for user experience. Currently, with ERC-20 token standard, if Bob wants to transfer 100 ZRX or ANT tokens to Alice (both ERC-20 compliant), he simply needs to execute thetransfer(Alice, 100) function in both cases. If these tokens did not use the same standard, then perhaps Bob would need to call transfer(Alice, 100) in the case of transferring ZRXs, but sendTokens(Bob, Alice, 100) in the case of transferring ANTs. This would be kind of confusing, since Bob and all the other developers would always need to check how each token works and write code for each different implementation. Standards are important as they simplify life for everyone and allow people to easily integrate in their own system tools developed by others. On the other hand, a given standard might not satisfy the needs of all applications, hence these several new token standards being proposed.


ERC-721 Standard: Non-Fungible Tokens

NFT functionality is slightly different than fungible tokens, necessitating a different standard: ERC-721. Indeed, instead of sending X number of tokens, you need to specify which token you want to send. In the case of ERC-721 tokens, when Bob calls the function transfer(Alice, 100), Bob is not sending 100 tokens, but sending the token #100. The actual implementation of the transfer function is slightly different in the new ERC-721 standard, but the essence is the same.

Contracts following the ERC-20 standard keep track of a single class of divisible token and contracts following the ERC-721 standard keep track of many indivisible tokens. However, it can be useful to keep track of many different types of fungible and non-fungible tokens within the same contract, both for simplicity and efficiency, as explained in the next section.


Multi-Class Token Contracts

The latter four standards (888, 1155, 1178, 1203) are practically identical in their intentions and reflect most our implementation. For simplicity, we will refer to these proposed token standards as Multi-Class Token (MCT) contracts. The four MCT proposals can be summarized as having a mapping variable such thatbalances[Bob][tokenA] is the number of tokenA Bob currently owns. With a standard ERC-20 token contract A, balances[BobAddress] returns Bob’s tokenA balance since there is only one token class tracked on this contract. With a standard ERC-721 contract B, balances[BobAddress] would return a list of all NFT tokens Bob currently owns on contract B. MCTs are obviously incompatible with both ERC-20 and ERC-721 standards giving the additional balance mapping. Yet, despite this lack of compatibility, we argue that this new token interface can lead to significant efficiency gains under the right circumstances. Indeed, we will show that we can transfer a large amount of tokens from different classes more efficiently by “packing” the balance of various tokens together.

For the sake of simplicity, in the rest of this post, we will assume that all token classes/types within an MCT contract are fungible tokens. MCTs could implement various token standards within the same contract, but this beyond the scope of this post.


Balance Packing Transfer Efficiency

In our MCT implementation, we store 16 token balances within a single uint256 (a 256 bits unsigned integer) where each token balance occupies 16 bits. You can then keep track of as many token balances as you want by having many uint256 where balances are packed in. However, because of this packing, a given token balance can’t exceed 2¹⁶, or 65,546. This can be a reasonable limit for many applications. For instance, under what circumstances would a single player need to be able to own more than 2¹⁶ swords? The one instance where this limit could become a problem is for a custodial exchange or proxy contract holding the funds on the behalf of many users, however, it is unclear whether or not this will be a problem in practice. Nevertheless, the amount of packing can easily be modified. For instance, packing 8 token balances in an uint256 instead of 16 increases the balance limit from 65,546 to 4,294,967,296. One can also do the opposite and increase the amount of token balances packed per uint256, reducing the balance limit but increasing storage efficiency.

The efficiency gains come from the fact that you can transfer 16 token classes with a single storage update, which is much less costly. However, the balance of these token classes needs to be packed within the same uint256 in order to benefit from this efficiency gain. Indeed, if you transfer 16 token classes where their balance is stored in different uint256, then you will have 16 storage updates, like a regular ERC-20 transfer. This means that token classes that are more likely to be transferred together should have IDs that are close to each others (e.g. 23, 24, 25, etc.) as well, increasing the likelihood of having many token classes within the same uint256.

These compromises and assumptions might be inappropriate for some applications, but we believe others will find this useful.


Comparing Transfer Costs Between Standards

Transferring 100 ERC-721 tokens in different transaction calls :

  • Gas Cost Per Transfer : 51,130

Transferring 100 ERC-721 tokens with a wrapper contract :

  • Gas Cost Per Transfer : 24,637

Transferring 100 ERC-20 tokens in different transaction calls :

  • Gas Cost Per Transfer : 51,533

Transferring 100 ERC-20 tokens with wrapper contract :

  • Gas Cost Per Transfer : 33,738

Transferring 100 fungible tokens from MCT contract without balance packing :

  • Gas Cost Per Transfer : 27,880

Transferring 100 fungible tokens from MCT contract with balance packing

  • Gas Cost Per Transfer : 4,671

Note that the balance packing calculation assumes tokens have close by IDs, hence the result above is a cost lower bound. The balance packing can offer significant efficiency gains under the right circumstances, up to 10x savings compared to regular transfers and 5x–7x when using wrapper contracts for batch transfers. In addition, I am fairly convinced additional significant optimization are possible without adding much complexity.

Computational efficiency is not the only efficiency that matters and better price discovery efficiency is an advantage fungible tokens have over non-fungible ones. Stay tuned for a post on this topic.


Conclusion

You can find our MCT implementation (an ERC1155 contract) with balance packing here: https://github.com/arcadeum/multi-token-standard

Horizon Games

We are a blockchain infrastructure company pioneering a new…

Thanks to Ian Ha, Peter Kieltyka, and Evan FP

Philippe Castonguay

Written by

Distributed Ledger Technologies | Smart contract research and development @HorizonGames | Computational neuroscience research

Horizon Games

We are a blockchain infrastructure company pioneering a new dimension of gaming that belongs to its players and creators. www.horizon.io

Philippe Castonguay

Written by

Distributed Ledger Technologies | Smart contract research and development @HorizonGames | Computational neuroscience research

Horizon Games

We are a blockchain infrastructure company pioneering a new dimension of gaming that belongs to its players and creators. www.horizon.io

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store