L2 Interop Working Group - Call #1
January 15, 2025
Agenda
- chain-specific addresses (ERC-7828)
- cross-chain messaging standards (see list here)
Call Notes
condensed notes below – recommend watching the recording (above) for full discussion
TL;DR:
- prioritizing two things: (i) finalize design / format for chain-specific addresses, and (ii) consolidate the multiple designs that have been proposed for cross-chain messaging & align on a shared standard for the group to push forward together.
- we decided to go ahead and start prototyping an end-to-end wallet-based prototype for chain-specifc addresses (h/t to MetaMask, Elytro, Status, ENS, ZKSync, Optimism, and others for jumping in)
- spun up a new group to consolidate on cross-chain messaging designs (thx to Espresso, OpenZeppelin, Hyperlane, Wonderland, LayerZero, Wormhole and others for all jumping in)
1. Chain-specific addresses
- Went through a quick summary of background and goals (ERC-7828)
a unified address format that allows specifying the account as well as the chain on which that account intends to transact.
- Automatic handling of cross-L2 sends for users just by putting the correct address into the “send” field
- Supports all chains in ethereum ecosystem
- Human-readability and intuitiveness
- Scalable: continued rapid growth of L2/L3s
- what it could look like: “alice@rollup-name.eth”
- Open questions: finalizing the format (use @?), rollout plan for onchain-configs (ERC-7785), and how to play nice with CAIP
- On the topic of CAIP, Marcin (ZKsync) shared an overview:
- If and how it can be compatible with CAIP? still being discussed
- Early idea: one prefix for CAIP, and everything underneath being compatible with something like 7828 chain-specific addresses
- Currently, can reach Ethereum chains through a human-unfriendly way with using EIP155 prefix and then address
- Potential idea is to add a new CAIP entry that will support 7828
- Important that we agree on address format here as a first step to interop to mentally unblock people
- Benefit of using CAIP? Bunch of wallets are already using CAIP. Increases chances of being adopted by more wallets. For wallets that are multi-chain / multi-ecosystem, its helpful to have shared standard.
- Vandan (MetaMask): from the wallet side, the use of CAIP are mostly for low level routing, but in the interface we can translate that to another format and present it differently to users so that its in an optimal human-friendly format.
- Is this dependent on ENS for chain registration? what about chains that dont currently work with ENS?
- No, ENS optional. But also down the road, ENS working to broaden support for all.
- Spent a few minutes discussing DIDs, and whether its a viable alternative. Used in regulatory context / EU integration with authentication frameworks? Todo: look more into.
- Eskender (ENS): the ENS team is building towards supporting non-EVM chains. One of the goals of Namechain.
- Jorge (Phantom): we use CAIP internally. Very useful not just for addresses but to identify different resources. Will probably keep using it in any case. But its not human-readable, so wont be shown to users at all. Adopting some other standard for addresses would be great and we are open to the idea of adopting it.
- Vandan (MetaMask): also already using CAIP. But when it comes to displaying to the user, we have a lot more flexibility at the protocol level to be displayed different.
- Arik (Fireblocks): a lot of the conversation between wallets happens at the CAIPs level. e.g. when Fireblocks and MetaMask meet using the CAIP WalletConnect setup.
- Hudson (Polygon): would the ENS governance process get brought into this or become a dependency in any way if this ERC goes through?
- Eskender (ENS): the ENS governance should have no impact on this. The name can’t be revoked from ownership. Comes down to the ownership structure and how its secured, rather than anything to do with the DAO itself. The DAO can’t snatch back a name. Also rebuilding the ENS core protocol from scratch for the Namechain rollout. Going through a migration with a whole new sweep of audits etc. ENS / Namechain has to be able to serve al of the L2s. And right now the lack of standardization is a barrier.
- Mark (OP): anyone interested in starting to prototype chain-specific addresses?
- Something in wallets would be best application of this
- Mark: can imagine a library that just takes a name and resolves it correctly
- YES to prototyping: ENS, Optimism, ZKsync, MetaMask, Status, and several others. TODO: spin up new TG working group (post-call note: this group has now been created)
- Do we want address resolution to be onchain verifiable or not on every L2? Yes
- Vitalik: one of the longer-term goals is to move toward a world where we have a universal L2 client. As a wallet, you can write one piece of code once. And every compliant L2 can just interpret it automatically using config contracts and other machinery.
- Mohammad (Scroll): how will the onchain verification work. TBD not yet figured out.
- Frangio: is there consensus around the way that onchain config is going to happen? See ERC-7785.
2. Cross-chain messaging standards
- On the call we had 4 different groups share their perspective and high-level proposal for a messaging interface: Espresso, Hyperlane, OpenZeppelin, and Wonderland.
- Several of these groups are now collaborating and consolidating their proposals.
- After the call, we spun up a new TG working group to focus on consolidating on best path forward with broad buy-in.
- 5 min. presentations made on the call:
- Note: recommend watching the recording to go through each
- 1. Ellie (Espresso) - ERC-7841: A mailbox API and message format to provide a unified cross-chain developer experience
- general message passing interface
- core primitive used for all other cross-chain things (intents, bridges, etc)
- the interface is differnet from the message-passing protocol
- requirements: no VM changes, easy to use API, support all kinds of interop (async and sync), unopinionated about apps built on top
- 2. Frangio (OpenZeppelin) - ERC-7786: interface for contracts to send and receive cross-chain messages.
- Agree with Ellie that we need to go below and standardize the low level primite of cross-chain message passing
- Simple interface for sending messages on one chain and receiving on another
- Best outcome for users is to have vendor-agnostic solutions
- Made it extensible, so that any feature that falls out of this min. core can be implemented on top of it
- Compatible with non-evm chains
- 3. Skeletor (Wonderland) - ERC-7802: token interface for authorized contracts to mint and burn token representations during cross-chain transfers
- cross-chain mint and burn standard. Just a simple clarification on the function signatures that bridges should be calling. To make it simpler for developers to not have to overload the mint and burn functions.
- Also proposing two different primitives: (1) separation between validation of messages and execution of messages, and (2) an entry point primitives – a wrapper contract on top of the messaging execution that allows developers to enforce specific logic for those messages to be triggered.
- 4. Nam (Hyperlane) - ERC-7854: verification-independent API to send and receive cross-chain messages containing arbitrary data
- Any message-passing interface needs to have two things in particular: (1) easy to use API for devs, and (2) VM-agnostic / proof-agnostic
- Believe the message passing interface has to be standardized and fully open. Been a core belief of Hyperlane from day 1.
- Emphasizes the importance of tooling and infrastructure to offer a reasonable experience compared to non-stardard alternatives