The post specifically focused on the ability to read data from a parent chain or layer-one (L1) to its scaling solution or layer-two (L2), from L2 to L1, and between different L2 solutions.
Layer 2 scaling solutions have gained massive traction in the past few months, with the top L2s amassing $9.38billion in Total Value Locked (TVL).
Buterin believes that their growing adoption, alongside the increasing use of smart contract wallets creates a gap that needs to be filled. The challenge arises from the need for users handling assets on multiple layer-2s within smart contract wallets to change keys. Resolving this requires a method of efficiently updating keys without needing a large number of transactions.
One of the solutions suggested in the post is the use of counterfactual addresses. Smart contract wallets can use counterfactual addresses that are not registered on-chain to receive and hold assets. The CREATE2 functionality enables this by allowing the generation of an ETH address.
The post further proposed the use of an asset/keystore separation architecture to enable users to change their keys in a multi-L2 environment.
Two approaches were discussed in implementing the asset/keystore separation architecture – a light version and a heavy version. While the former requires each wallet storing keys locally and periodically checking for proof to update the keys, the latter requires cross-chain proofs for every transaction and subsequently verifies the key in the keystore.
Ethereum state root
A cross chain proof validates transactions between different blockchain networks or layers. In situations where the keystore and wallet are located on different layer-2 (L2) networks, a complete cross-chain proof for wallet keys comprises two primary elements.
Firstly, there is a verification proof that validates the present state of the keystore-holding L2 network using the Ethereum state root that is known by the wallet-holding L2 network. Secondly, there is a proof demonstrating the existence of the current keys within the keystore by utilising the state root of the keystore-holding L2 network.
Buterin outlined the five different methods of cross-chain proofs (Merkle proofs, General-purpose ZK-SNARKs, Special-purpose proofs (eg. with KZG), Verkle proofs and No proofs (rely on direct state reading). They were ranked in order of ease of implementation and cost using a chart.
The report further explained the working principle of each method and its pros and cons of all methods in terms of gas costs, computational resources and data sizes. It was determined that the choice would be largely dependent on the use-case and the desired trade-off between gas consumption and network security.