Vitalik recently post an article called "Deeper dive on cross-L2 reading for wallets and other use cases" Let's break down some of the topics mentioned in this article into digestible bits.
As Layer 2 solutions (L2s) and smart contract wallets gain traction, users may find their assets spread across multiple L2s and Layer 1 (L1) simultaneously. One pressing challenge in this environment involves the management of access keys across these scattered wallets, particularly when a change in keys is needed. A comprehensive solution must provide an efficient way to alter these keys across multiple accounts in various locations without triggering a flurry of transactions.
An additional layer of complexity emerges with counterfactual addresses. In the Ethereum network, these are addresses generated upon a user's first interaction with the system, but not yet formally registered on-chain. Despite the lack of registration, these addresses can securely receive and hold funds, and thanks to Ethereum Improvement Proposal 1014 (EIP-1014), also known as CREATE2, they can also exist in smart contract wallets. However, a difficulty arises when a change in the initial verification key stored in these addresses is required. This verification key doesn't automatically propagate to other L2s.
To tackle these challenges, Vitalik proposes an asset / keystore separation architecture. In this model, each user maintains a "keystore contract" that houses the verification key for all wallets and the rules for changing it. In addition, "wallet contracts" exist on L1 and various L2s, which can cross-chain access to the verification key.
Two primary implementation approaches are suggested:
1. Light version: Here, each wallet locally retains the verification key, equipped with a function that validates a cross-chain proof of the keystore's current state and subsequently updates its locally stored verification key to match. This method is secure and minimizes the usage of cross-chain proofs. However, it may incur high gas costs when changing the verification key due to required on-chain updates in both the keystore and all initialized wallets.
2. Heavy version: In this method, every transaction demands a cross-chain proof showing the current key in the keystore. Although less complex on a systemic level and offering inexpensive keystore updates, this approach might increase per-transaction costs and require extensive engineering to make cross-chain proofs affordable. Compatibility issues with ERC-4337 could also arise, given the current lack of support for cross-contract reading of mutable objects during validation.
When it comes to handling keys in a cross-chain context, the concept of a cross-chain proof becomes pivotal. Ideally, such a proof would confirm both the current state root of the keystore's L2 and the present keys in the keystore. However, deciding on the type of proof to use, how an L2 can access the recent state root of L1, or potentially the full L1 state, and understanding the potential delays between an event occurring on one chain and its provability on the other, are substantial challenges in implementing this approach.
Various proof schemes are examined, such as Merkle proofs, Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (ZK-SNARKs), special-purpose proofs using Kate commitments (KZG), Verkle proofs, and direct state reading with no proofs. These options are evaluated based on their infrastructure workload and user costs, considering the potential benefits of "aggregation," a method combining all proofs supplied by users within each block into a single meta-proof.
Further, the document explores how to reduce gas costs of cross-chain transactions, focusing on two primary methods: aggregation and direct state reading. The former involves bundling multiple user transactions into a single block, creating a single proof that can validate all the transactions at once. The latter modifies L2 networks to enable direct static calls to contracts on L1, reducing the need for proofs and thus the gas cost.
However, all these schemes require that every transaction on the L2s must have a corresponding "snapshot" or "window" onto the state of the L1 blockchain at the time of its transaction. This demands periodic anchoring of the L1 state onto L2, a process which could create some delays or result in potentially stale views of L1, but is crucial for the cross-chain proof scheme to work properly.
There are potential solutions to mitigate this latency issue. For instance, using a "latest observed state root" mechanism that works in real-time, or employing a Light Client Bridge (LCB) to provide up-to-date snapshots of L1. The former offers an immediate and updated snapshot, but it carries with it risks of forked or reorganized chains. The latter, although slower and resource-intensive, is much more reliable and secure.
Let’s delve into the implications of these systems on the user experience. While the proposed architectures promise to streamline key management across different L1 and L2 networks, they could add complexities that may confuse users. For instance, users will need to understand the difference between a wallet and a keystore, the implications of changing keys, and the process of managing cross-chain proofs.
To maintain user-friendliness, Vitalik proposes a design where the complexity of the backend operations is hidden, with the user interface (UI) only displaying relevant actions to users such as 'Change Key', 'Transfer', etc. The underlying processes, such as updating the verification keys across different chains or obtaining and validating cross-chain proofs, will be handled automatically by the backend, without any user input required.
This paper highlights the key challenges in managing access keys across L1 and L2 networks, proposes possible solutions, and emphasizes the importance of simplicity and user-friendliness in designing these systems. Despite the many challenges, advancements in blockchain technologies, especially in cross-chain proofs and smart contract wallets, provide promising avenues to make managing keys across different chains simpler and more efficient.