ERC-6735 Address aliasing between EVM chains (L2 Aliasing of EVM-based Addresses)
Review · Other · created 2022-03-20
Defines an address aliasing method for consistently identifying and converting the addresses of the same asset or account across Ethereum-family chains (L1, L2, sidechains) according to a rule.
Why it is needed
A single token or account often exists simultaneously on the Ethereum mainnet and multiple L2s (scaling networks that process transactions on behalf of the mainnet) and sidechains. However, there has been no standard method for determining which address on the counterpart chain is being referred to when exchanging messages between chains. The source compares this to a situation where every internet service provider defines its own IP addressing scheme. Without a standard, a message sent from chain A has difficulty clearly specifying an asset or an externally owned account (EOA, an account managed directly by a person with a private key) on chain B, and the receiving side also has difficulty definitively verifying which chain the asset originally came from. This standard aims to unify the address identification needed for cross-chain interoperability into a single method by allowing aliases to be created by attaching a chain-specific offset to the address on the originating chain according to a rule.
In depth
Basic alias construction rule [R1]
An address alias used between chain A and chain B must be constructed in the form addressAlias (Chain A) = offsetAlias (for Chain A) relativeAddress (on Chain A) offsetAlias (for Chain A). In other words, the structure wraps the relative address with chain A's offset alias before and after. An alias constructed this way can be tested for conformance by decomposing it with an existing open source parser and comparing it against the relativeAddress used in construction.
Offset alias and chain ID rules [R2]-[R5]
A chain's offset alias must be in the form 0xchainId00000000000000000000000000000000chainId. The chainId used in the offset must not be 0 and must be 8 bytes; if it is fewer than 16 digits, it must be zero-padded to 16 digits. For example, Polygon PoS's chainId is 137, and its offset alias is 0x0000000000000137000000000000000000000000000000000000000000000137. The source notes that the list of EVM-family chain IDs can be found at chainlist.org.
Fixed offset for the Ethereum mainnet [R6]
The offset alias for the Ethereum mainnet, the reference point for EVM-family chains, is fixed at 0x1111000000000000000000000000000000001111. This is because existing L2 solutions have already adopted this offset. The source gives the alias example for the USDC asset as addressAlias = 0x1111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB481111.
Nested structure of the relative address [R7]
relativeAddress can be a smart contract or EOA address on the originating chain, or it can itself be a relativeAddress already created on another chain. In other words, aliases are nested. In the source example, the relative address of wrapped USDC is 0x1111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB481111, and the relative address of wrapped USDC on Polygon is 0x00000000000001371111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB4811110000000000000137. An example alias referring to Ethereum's wrapped USDC from Arbitrum is 0x00000000000421611111A0b86991c6218b36c1d19D4a2e9Eb0cE3606eB4811110000000000042161.
Offset ordering rule [R8]
Within an alias, offsets must be arranged so that the root chain's offset wraps the relative address innermost, with the offsets of chains the asset passed through appended outward in that order. For an asset bridged from chain A to B to C, in that order, chainId(C) chainId(B) chainId(A) relativeAddress chainId(A) chainId(B) chainId(C) is valid, and the reverse order is invalid. However, it states that proof that a given order is provably correct is outside the scope of this document.
Conformance levels and test procedures
Conformance levels showing whether an implementation follows the standard are divided into three. Level 1 is a level that demonstrates all MUST requirements with a test report; Level 2 demonstrates MUST and SHOULD; Level 3 demonstrates everything including conditional requirements. When claiming conformance, the test procedure performed for each requirement must be described (D1 is SHOULD, and for claims of Level 2 or higher it is MUST per R9), and it states that standardized test fixtures for all requirements will be released in the next version.
Scope of application and proposal status
This standard covers only aliasing between EVM-based L1, L2, and sidechains. Aliasing between EVM and non-EVM chains, and between non-EVM chains, is outside the scope. The design generalizes the aliasing method already used from Ethereum to EVM-based L2s such as Arbitrum and Optimism. In addition, this proposal was written by the L2 working group of an EEA community project managed by OASIS and is currently in Review status, so it is a proposal under review whose content may still change.
Things to watch out for
- Code hash verification for EOA addresses: If the address used in relativeAddress is required to be an EOA, the receiving side must verify that the original account's codehash is NULL. This is to prevent malicious code from being secretly executed during asset transfer.
- Code hash matching for contract addresses: If the address is required to be a smart contract account representing an asset, it must be verified that the original account's codehash matches the codehash of publicly available Solidity code, to confirm that the contract behaves as expected.
- ERC-55 checksum verification: When verifying relativeAddress, it is recommended to also perform the address checksum verification defined in ERC-55.
- Regulatory compliance and tool selection are the implementer's responsibility: The standard does not establish requirements for jurisdictional legal compliance or the use of specific libraries. Compliance with data privacy laws and due diligence in selecting tools and libraries are the implementer's responsibility.