Architecture

Keyspace is a minimal zero-knowledge rollup that settles on Ethereum. It's minimal in that it doesn't implement a zkEVM like most rollups. Instead, there are a few specific state changes defined by the rollup.

Keyspace's internal state is an Indexed Merkle Tree, which allows brand new wallets to easily prove that they've never changed their keys so they aren't in the tree, and recovered wallets to prove the current configuration of their wallet. The root of this Merkle tree is managed by the KeyStore contract on L1, where state transitions are verified by SNARK proofs.

Rollup Node

The Keyspace node is derived from go-ethereum to monitor the L1 chain for activity in the KeyStore contract and respond to JSON RPC calls from clients requesting key changes. There currently is no gossip protocol between nodes, so the activity in the KeyStore contract is the only method for Keyspace nodes to communicate.

L1 KeyStore Contract

The KeyStore contract on L1 is the source of truth for the state of the rollup. The sequencer updates the state by generating a SNARK proof of a batch of state transitions and submitting it to the contract to verify the proof and advance the state root. The contract also implements a forced inclusion mechanism, where clients can submit their key recovery proof directly to L1, and the sequencer is forced to include their transaction in an upcoming batch.

Sequencer/Prover

The sequencer generates a recursive batch proof that contains proofs of each client's key recovery transaction and submits it to the KeyStore contract on L1. Sequencing is currently permissionless, but for launch, we expect to begin with an allowlist of sequencers and transition to permissionless sequencing over time.

L2 KeyStore Contract

Cross-chain wallets and other applications integrate with Keyspace by reading from a local L2 KeyStore contract with the latest state from L1. The state is trustlessly synced from L1 using Merkle proofs of the L1 KeyStore contract's storage. (The state can also be trustlessly synced via deposit transactions from L1, but that currently costs more gas.) Currently, this syncing is performed by the Keyspace sequencer, but it can extracted and run independently of the sequencer.

Account Circuits

Key changes are authenticated by Account circuits that generate proofs that the key change is authorized. Integrators will typically use common circuits like an M-of-N multisignature circuit, but you're free to implement your own custom logic to handle key changes.

Wallet Contracts

Wallet contracts authorize transactions with a client-provided proof that the signature's signing key is the current authorized key according to the latest Keyspace state root.

Support Services

To provide a better user experience, vendors can operate their own support services that monitor changes to Keyspace's state and indexes the latest state of all of their wallets.