Article TL;DR

Make it easier to read L1 from L2, L2 from L1, or L2 from another L2

• Necessary to implement asset / keystore separation architecture
• Can be used to optimize reliable cross-L2 calls

Goal

• When L2s become more mainstream → Users will have assets across multiple L2s and L1s
• When smart contract wallets become mainstream → Keys needed to access some account are going to change over time (old keys will no longer be valid)
• Once both of the above occurs → User needs to find a way to change the keys that can access many accounts which live in many different places → Without making extremely high no. of txns
  • This is essentially saying that they are allowing the users to access the different smart contract wallets (accounts) they have on the different networks with specific keys. And there is a need to implement an architecture to achieve this without creating a complex UX
• Need a way to handle counterfactual addresses which are:
  • Addresses that have not yet been ‘registered’ in any way on-chain → But need to receive and securely hold funds
  • Necessary for all: When using Ethereum for the first time → A user generates an ETH address that someone uses to transfer assets to → This address is not registered on-chain yet
  • Registered on-chain: Require paying of txn fees → Which requires the wallet to already hold onto some ETH
  • We can think of this as a sort of ‘kick-start’ mechanism → Where the address will be registered once they have started making txns → Active wallet instead of passive wallet (purely receiving, not making txns and paying gas fees)
• All EOAs start off as counterfactual addresses
• Possible for smart contract wallets to be counterfactual addresses
  • CREATE2: Allows ETH address to only be filled by a smart contract that has code matching a particular hash

Challenges of Smart Contract Wallets

• Possibility of access keys changing
• Smart contract wallets have an address (unique identifier for the wallet) → Generated based on initcode → Only contain initial verification key (password for wallet)
• Current verification key (might be different from the initial verification key) → Stored inside wallet’s storage
  • This is not propagated to other L2s
• User might have multiple addresses on different L2s → Should there be counterfactual addresses that are not known yet by the L2s (since they are not registered) → Changing the access keys becomes a challenge
  • But why are the addresses different? If it’s EVM, it should still be the same?

Solution: Asset / Keystore Separation Architecture

2 main components:

1. Keystore Contract
   • Can be on a L1 / L2
   • Stores verification key for all wallets owned by user
   • Stores rules for changing key
2. Wallet Contract
   • Exist on both L1 and L2
   • Communicate with each other across different systems to retrieve verification key stored in keystore contract