Special thanks to Michael de Hoog for his review and feedback. Please read this Introduction to the Keystore Rollup for context if you are not familiar. This work builds on the Minimal Keystore Rollup specification, and seeks to improve the DevX for writing and auditing account authentication patterns. Currently, implementing validation for Keystore updates requires writing zk circuits. However, the number of people who understand and can write zk circuits is small. This barrier to developers risks reduced adoption of the Keystore Rollup. Additionally, these "Account Circuits" are not involved in validating signatures for user operations, just Keystore updates. This causes a divergence in account authentication where a Solidity contract and a zk circuit are responsible different halves of the same question: "can you control this account?". While enabling flexibility, a simpler and unified authentication option should exist for account developers.

At the intersection of scaling and account abstraction efforts on Ethereum, two of The Three Transitions, the Keystore Rollup may become crucial infrastructure to support global-scale Ethereum. Recently, Vitalik’s original proposal for a minimal rollup dedicated for keystores has been iterated on by Base with a more formal specification. While the existing writing is detailed, I want to provide an introduction for those less familiar with the cryptography at play. This post is an attempt to introduce the idea and fundamental logical blocks of a Keystore Rollup without involving the underlying cutting-edge cryptography required to implement it. What does a Keystore Rollup solve? First, a primer on the current state of using Etheruem. Motivated by the need to reduce transaction costs, rollups have started to become default locations to deploy new dApps. Unfortunately, this has introduced new friction in users first having to bridge ETH over into the rollup to pay for transaction on the network. Account abstraction, specifically EIP-4337’s implementation, is poised to help solve this problem by providing new ways for users to pay for gas with less friction, potentially receiving complete subsidies too. As the number of rollup options accelerates (aided by patterns like Modular DA and L3s), smart contract accounts must continue to deploy on every new network a user wants to transact on. Our root problem starts with the isolation of a rollups state with other rollups. Specifically, the state that accounts need to authenticate user operations e.g. an owner key. The ability for smart contract accounts to hold state empowers functionality like key rotation and recovery, but also comes with a complication of syncing state updates across all networks. In the diagram below, consider our user just added a passkey on their phone to control an account while on the go. The change was applied on the Optimism network, but not on Base or Scroll. intro-ksr-1