Multi-chain Native Tokens
In this research article, we propose an extension interface for ERC20 , ERC721 and ERC1155 token contracts, in order for them to become native to multiple chains. This interface will become a necessity with with the upcoming Cambrian explosion of rollups on Ethereum with addition of EIP-4844. You can find the actual EIP proposal here.
Published on
Do not index
Do not index
In this research article, we propose an extension interface for
ERC20
, ERC721
and ERC1155
token contracts, in order for them to become native to multiple chains. These interfaces will become a necessity with the upcoming Cambrian explosion of rollups on Ethereum with addition of EIP-4844. You can find the actual EIP proposal here.Motivation
As more and more rollups launch on Ethereum, it becomes necessary to standardize an interface that will allow bridge contracts natively mint & burn
ERC20
tokens. This is necessary because existing rollups like Optimism & Arbitrum have already defined their own token interfaces that allows their bridge contracts move ERC20
tokens between L1 and L2. If we allow this to continue, then there’ll be a new interface for every L2 that launches on Ethereum. Standardization is necessary to prevent this.Trustless interoperability, ie consensus verifying bridges, haven’t been possible out of Ethereum, until now. With the transition to proof of stake and the introduction of the Casper FFG & Altair light client protocol, It’s now possible for another blockchain to trustlessly track the state of the Ethereum beacon chain, enabling trustless bridges to & out of Ethereum. These new interfaces will provide these trustless bridge contracts with the necessary interface they need to natively transport tokens in and out of Ethereum.
Specification
In order to transport tokens, we consider the mint & burn approach. This allows token issuers to easily track their total TVL across chains, where escrow and release models can introduce new attack surface areas. In order to provide this mint and burn interface, we provide extension interfaces for the standard
ERC20
, ERC721
and ERC1155
token interfaces. These interfaces provide not only the necessary mint & burn interfaces needed to transport tokens, but also the access-control layer for token issuers to add & remove bridges to the allowed list of contracts that can mint & burn.In this new architecture, token issuers are instead responsible for deploying their token contracts across all the chains they wish to support. This allows them to retain full control of all instances of their token across chains, rather than having the L2s or alt-L1s deploy wrapped (usually from bridges) versions of the tokens themselves.
1. Any contract complying with EIP-20 when extended with this EIP, **MUST** implement the following interface:
// The EIP-165 identifier of this interface is 0x01cbdea7*
interface IERC6160Ext20 is IERC5679Ext20, IERC_ACL_CORE, ERC165 {}
2. Any contract complying with EIP-721 when extended with this EIP, **MUST** implement the following interface:
// The EIP-165 identifier of this interface is 0x01cbdea7*
*interface IERC6160Ext721 is IERC5679Ext721, IERC_ACL_CORE, ERC165 {}
3. Any contract complying with EIP-1155 when extended with this EIP, **MUST** implement the following interface:
// The EIP-165 identifier of this interface is 0x01cbdea7*
interface IERC6160Ext1155 is IERC5679Ext1155, IERC_ACL_CORE, ERC165 {}
4. It is RECOMMENDED for compliant contracts to implement the optional extension
IERC_ACL_GENERAL
.
5. Compliant contracts MAY implement the optional extension
IERC_ACL_METADATA
.Rationale
1. We have chosen the EIP-5679 standard to provide the mint & burn interface.
2. We have chosen EIP-5982 standard to provide the access control interface for trustless bridge contracts to check their permissions to mint & burn
ERC
tokens.
3. We have chosen NOT to create new events but to require the usage of existing transfer event as required by EIP-20 EIP-721 and EIP-1155 for maximum compatibility.
Security Considerations
Currently all of the bridges going in & out of Ethereum are unfortunately trusted and rely on 3rd party attestation rather than proof-based authentication. (So much for don’t trust, verify). Given this situation, we don’t expect token issuers to add support for these kinds of bridges. Rather, with trustless interoperability on the horizon with protocols like succint labs, zkbridge, hyperledger labs , snowfork and electron labs. We see a need to begin to set the stage early for projects like these to be able to transport
ERC
tokens natively across L2s and alt-L1s alike.References
https://medium.com/@datachain/datachain-successfully-completes-building-an-ibc-bridge-between-cosmos-and-harmony-on-the-local-5910e094e6c6