Interoperable Addresses using ENS

💬 General Discussion
1

Unruggable have been working with the team at Wonderland, Josh Rudolf from the Ethereum Foundation, and the wider Interop working group on fleshing out the specifications and implementations for interoperable addressing standards.
This post serves as and end-to-end technical summary of these standards, (hopefully) presented in an accessible manner.

This post is supplementary to: [Temp Check] Registration of on.eth to support interoperable addressing standards

ERC-7930: Interoperable Addresses

Interoperable Address
Introduces a standardised binary format to represent a specific chain, an address on a specific chain, or an address on a specific subset of chains. The standard is intentionally flexible such that a single standard can be utilized for all interopability use cases.

For example:

  • 0x000100022045296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef000 represents Solana Mainnet.
  • 0x000100000014D8DA6BF26964AF9D7EED9E03E53415D37AA96045 represents 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 on any EVM-compatible chain (eip-155)
  • 0x00010000010114D8DA6BF26964AF9D7EED9E03E53415D37AA96045 represents 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 on Ethereum Mainnet specifically.

These examples display base16 (hexadecimal) representations of raw binary data. Raw binary data is the most direct, space-efficient way to represent data. Of course, it is not particularly easy for humans to understand visually.

Interoperable Name
ERC-7930 also introduces the Interoperable Name format. This is a human-readable representation of an Interoperable Address. It is defined as <address> @ <chain> # <checksum>.

The three examples above would be represented as:

  • @solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d#2EB18670
  • 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155#4CA88C9C
  • 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:1#4CA88C9C

This representation is more human-readable - the address likely looks familiar, eip155 might ring a bell, and 1 is well established as the chain ID for Ethereum Mainnet. But we can do better…

ERC-7828: Interoperable Names using ENS

Interoperable Name

ERC-7828 extends the Interoperable Name format to allow for the the <address> component to use an ENS name.

As ENS names can resolve to a different address on each chain, a chain reference must be specified.

Assuming that alice.eth resolves to 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045, this example:

  • 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:1#4CA88C9C

Can now be represented as:

  • alice.eth@eip155:1#4CA88C9C

ERC-7828 goes further. It allows for the <chain> component to be represented by a human-readable label which represents a subdomain of an ENS name. For now we will reference the namespace as <namespace>.eth.

The example above can now be represented as:

  • alice.eth@ethereum#4CA88C9C

Under the hood clients resolve the Interoperable Address associated with ethereum.<namespace>.eth to discern metadata about the chain the user wants to interact with.

ENSIP-24: Arbitrary Data Resolution

ENSIP-24 is a proposed standard for a resolver profile that allows the resolution of bytes data. Please see ENSIP-24: Arbitrary Data Resolution for further discussion.

Current resolver profiles such as ENSIP-5: Text Records, are not appropriate for the resolution of an Interoperable Address which is raw binary data of arbitrary length.

The ability to resolve arbitrary length binary data is a huge unlock for ENS generally - storing raw bytes data is gas efficient, and enables true interoperability. This ENSIP also makes ENS Forward Compatible - any proposed resolution use case for ENS can be accomodated immediately by this standard.

Smart Contracts

The canonical implementation of the ChainResolver smart contract to be set as the resolver on <namespace>.eth can be found here: unruggable-labs/chain-resolver.

A basic user interface exists here which demonstrates the registration and resolution of an ERC-7828 Interoperable Address.

What’s next?

These specifications, contracts, and demos are being polished and finalized. Over the past months we have iterated on these specifications based on feedback and discussion within the Interop working group. This post seeks to open the floor to ENS ecosystem participants to share their thoughts, feedback, and suggestions.

Alongside this post, the team at Wonderland have proposed a ‘Temperature Check’ for the assignment of the ENS name on.eth to be utilized as the namespace for ERC-7828. This can be found here: [Temp Check] Registration of on.eth to support interoperable addressing standards.

Previous discussions that relate to the namespace can be found at the following links:

Dependent on the feedback received, the only action required of the ENS DAO specifically is the execution of an on-chain transaction to register the on.eth namespace and set the resolver to the ChainResolver smart contract.

On our end, we will:

  1. Agree on the key holders for the ChainResolver management multsig.
  2. Deploy the ChainResolver smart contract.
  3. Engage with chain operators and populate the ChainResolver.

Happy to answer any questions.

8 Likes