# L2 Interop Working Group - Call #2 **January 29, 2025** - [Recording](https://youtu.be/ca1zzrQLnEk) - [Calendar invite for future calls](https://docs.google.com/forms/d/e/1FAIpQLSfMFEJmyVgjLuiipgxprEkiQXwwK3F_PfGbWvU8ZmV6e_ka0A/viewform) ### [Agenda](https://github.com/ethereum/pm/issues/1249) 1. Updates from the "chain-specific addresses working group" 2. Updates from the "message passing working group" 3. Planning the 3-month "interop roadmap" 4. [RIP-7859](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7859.md) 5. [Reown](https://docs.reown.com/walletkit/features/experimental/chain-abstraction) (formerly WalletConnect) + [7811](https://github.com/ethereum/ERCs/pull/709/files) ## Call Notes *condensed notes below – recommend watching the recording (above) for full discussion* **TL;DR:** - putting the finishing touches on 7828 (chain-specific addresses) - "cross-chain message passing group" continuing to make progress, with the goal to standardize APIs to replicate the UX of same-chain calls in the cross-chain setting - the message passing stuff will take time, so in the meantime there is momentum and desire to accelerate a trustless intents-based solution to deliver value to users asap. - Want to move fast on standardization, but also ensure wallets/dapps will actually be able to adopt the standard as quickly/cheaply as possible. ### 1. Updates from the "chain-specific addresses working group" - [ERC-7828](https://eip.tools/eip/7828): very close to finalizing the main open questions - continued discussions with wallets and L2s - still some work to do on figuring out the details of the rollout strategy / ENS integration - will continue the discussion async in the group with goal to close out the remaining open questions in next 1-2 weeks ### 2. Updates from the "message passing working group" - Ellie from Espresso shared [slides](https://docs.google.com/presentation/d/1oMsHfZfppL4rhoGG7CLk6baQ5I4548zmIHh5fvVBKlU/edit?usp=sharing) and provided an update on where things are: -  - Using ERC-7786 as the basis for the discussion around standardizing the message format - goal: similar user/developer experience of same-chain calls in cross-chain setting - non goal: standardizing the messaging protocol itself (just the APIs the devs will use) - not useful if the ERC is adopted, but then people put a bunch of wrapper contracts around it. Defeats the purpose of having a standard. - how does this message passing stuff relate to the goal of having something in next 3-6 months: - end goal: fast, trustless messaging passing between chains - but probably going to be hard for us to agree on a messaging protocol in next few months - to get fast, trustless message passing we need to standardize: (1) data proved, (2) messaging interfaces (7786), and (3) fetching L1 data (7859) - but difficult to do all these things in <6 months - Suggestion: adopt 7683, and adopt 7828 (chain-specific addresses) - and in the meantime, continue to work on all the other things -  - All doable within next 12 months - Seperate group should focus on 7683 and getting that to mainnet - How quickly could we get 7683 to mainnet? - Hart (Across): - we do have a production deployment of 7683 contracts in place today. There is more work to be done before the full 7683 spec is live (mainly we need to update solvers to properly support it), but we are very, very close. - contracts are deployed and reference implementations for solvers are being written - think that 7683 and 7786 fit together very nicely - intent as an "order ticket" for what you want to do cross-chain - the settlement layer: escrowing user funds and validating that the intent was filled – this should use a message passing interface like 7786 to verify that intent. And then can plug in whatever verification mechanism we want (ZK proofs, optimistic proofs, etc) - Oage (Uniswap): - re timeline on when something like this could get to mainnet: 3 month good rough estimate when we might start seeing systems come online - other open questions: (1) with this system, before sending the message, how to determine how much the message is going to cost? (2) push vs pull based, and (3) specify some degree of sub-standards as part of this? - Ellie (Espresso): - pull-based messaging can be on the messaging protocol level.. doesnt necessarily need to be in the dev API standard. - Hadrien (OpenZeppelin): - For 7786: re determining how much the message is going to cost to send: could happen on any chain or off-chain. Orthogonal to the sending of the message. - Re push vs pull models: believe push model is simple and works fine. Even in pull model, the data that is being pulled was somehow placed there. - Ed (Arbitrum): fast and trustless is great. But how fast in trustless setting? Same speed as L1 block time, or faster? - should be within 3 slots or less (of the slower chain) - examples: - to/from L1: 12 * 3 = 36 seconds - between Arbitrum and Optimism: 2 * 3 = 6 ### 3. Planning the 3-month "interop roadmap"  - End goal: we want people to be able to use what we are building as quickly and cheaply as possible. And want developers to build on top of these things as quickly and cheaply as possible. Advantage of building on top of a standard is you get a lot of built-in distribution (e.g. from wallets) - Lot of urgency to keep momentum high, move fast, and deliver value to users - But we also need to make sure we ship the right things, and find the right kind of structure to collaborate most effectively. Rather than just dump a bunch of messages into Telegram. - Even if we agreed on the perfect APIs and perfect standards, it will still take time for people to integrate this and ship it into production safely for end users. - Make sure we have common language and shared understandings/goals - Move more conversation into GitHub. Try to document as much as possible in the first month in particular. - Plan: - February: - standardize the standards, categorize efforts, work on primitives and properties (our source of truth). Do we agree on certain invariants or not etc. - March: - single draft document per category, focus on the "must-haves", draft demo contracts & UI (in collab with one or more wallets), start draft review process - April: - launch demo and gather feedback, polish and fix, ensure backwards compatibility and future-proofing. - Avoid: custom implementations, bikeshedding, enshrining specific implementations. - For intents / 7683: intents work right now and they can be shipped. But how do we ship them using the shared standard? Key question. To make it easy for any new wallet or any new app etc. They can just the "interop standard" and they get intents for free. - We want to avoid rushing to implement intents, and then soon after say "oh by the way we have this other interop standard you need to implement that also gets you intents." - pgpg (Polygon): - At Polygon, we have people who are doing much of the same work for AggLayer. My goal is to bring those resources/people out here into the public so they have a chance to collaborate. - There are pieces of this that we can really help support both logistically, financially, and brainpower wise...our goal is also to create the same world here. - Would be helpful if we can make sure to highlight places where resource are needed at a high level so can bring in the right people. ### 4.[RIP-7859](https://github.com/ethereum/RIPs/blob/master/RIPS/rip-7859.md) - Ian from Polymer joined for a walkthrough of 7859: - Store L1 origin data and historic L2 block hashes in L2 state - This RIP comes from a desire for all rollups to provide a view inside their execution environment of the L1 block that they are building L2 blocks off of - This unlocks a lot of capabilities, such as ability to verify arbitrary claims about the L1 inside the L2. Also when you're doing cross-chain transactions between 2 different rollups, make sure that the two rollups are building off of the same L1 history. Originally this started as just an informal call to get every L2 to implement EIP-4788 as-is. - 4788 is actually pretty expensive and clunky to generate the merkle proofs. But after getting feedback from Mark from OP, its been reformatted to just standardize a set of interfaces - If you have L1SLOAD, and it's an L1SLOAD implemented such that verification is deferred to settlement time, so you dont have to prove every access in the VM, then that provides a much more efficient access to L1 storage reads. If you have L1SLOAD, then you would not use this proposal to verify L1 storage reads. - But this proposal is also more general purpose and provides capabilities that you can't get in L1SLOAD. - e.g. it can be used to verify claims about state accounts, receipts and logs and tx in addition to storage slots. - Other thing with L1SLOAD: not going to be able to operate if the L2 sequencers loses connectivity with the L1. - Goal isnt to get this specific RIP adopted. Moreso just to agree that we need to have some view of the L1 inside of the L2 execution environment. Because of what it unlocks. ### 5. [Reown](https://docs.reown.com/walletkit/features/experimental/chain-abstraction) (formerly WalletConnect) + [7811](https://github.com/ethereum/ERCs/pull/709/files) - Derek from Reown joined for a demo of latest from Reown's WalletKit + [chain abstraction](https://docs.reown.com/walletkit/features/experimental/chain-abstraction ) functionality for cross-chain transfers - Recently rebranded from WalletConnect to Reown. - Have both wallet SDK and app SDK. In the wallet SDK: goal is to make it easier for wallets to consume bridging and provide bridging to end users. With the goal that the user just sees one aggregated balance and can use it across all networks. And do it in a way that supports EOAs and all accounts. - Derek gave a quick demo, where he showed how it can be used to bridge funds from Arbitrum behind the scenes to pay for something on Base. - Recommend watching the full demo and hitting up Derek (@cyberdrk on TG) for more info!