Roadmap

Cross-Chain Syncing Improvements

Support for More Chains

Keyspace will expand beyond OP Stack L2s to support a wider range of chains for both master and replica functionality. We expect most replica chains to implement EIP-4788 to be able to verify proofs from L1. For alt-L1 replica chains, we plan to add support through multiple trusted oracles using the Hashi project, providing a more secure syncing solution for these chains. For master chains, we'll need to implement an _extractConfigHashFromMasterChain function for each rollup stack.

Resilient Fallback Syncing

We will implement syncing via deposits and withdrawals as a resilient fallback method when other syncing methods aren't available or have stopped functioning due to hard forks. Once this has been implemented, wallets should be able to sync on each chain as long as each chain between the master and the replica continues to function.

Standardized Beacon Root Oracle Access

ERC-4337 prohibits cross-contract storage access during the validation phase of user operations. We are working to standardize access to the EIP-4788 beacon root oracle access during ERC-4337 validation across all bundlers. Each slot can only be written to once per day, so it's straightforward for bundlers to defend themselves from the mass invalidation attacks that these restrictions were intended to prevent. This will allow new signers to sync their wallet's configuration to a replica chain without assistance.

L1SLOAD

We currently use either Merkle proofs or withdrawal and deposit transactions to sync wallets across chains. Merkle proofs are more efficient, but are fragile because each hard fork of an L1 or L2 can change the assumptions that the Merkle proof relies on, and would require a contract upgrade with new logic to verify cross-chain state. Withdrawal and deposit transactions are more resilient, but are costly and slow. L1SLOAD provides a way for rollups to read state directly from L1, which is fast, cheap, and resilient to L1 and replica chain hard forks. (Master chain hard forks would still be fragile.) It would also lower the gas costs for syncing wallets across chains: each Merkle proof is about 5kb of calldata that direct state reading eliminates.

Standards for Cross-Chain Proofs

Since deposits and withdrawals are costly and slow, we aim to push for standardized contracts for verifying cross-chain proofs that are updated with each hard fork, just like the deposit and withdrawal bridges are. When all rollups offer such contracts, it will always be possible to sync wallets between any two chains without slow and costly deposits and withdrawals. At this point, wallets may be able to require syncing for all wallet actions, which makes revoked signers permanently removed once the eventual consistency period has passed.

Dedicated Keystore Rollup

Vitalik's original vision for keystore wallets was based on a dedicated keystore rollup where keystores would be stored. Keyspace currently uses general purpose L2s as master chains because it makes keystore wallets easier to deploy today. We believe the endgame for keystore wallets is a dedicated keystore rollup, and we see Keyspace as a stepping stone to that future.

Reduce the Hard Fork Burden

General purpose L2s have frequent hard forks that often break cross-chain syncing. A dedicated keystore rollup would have a much smaller number of hard forks and would prioritize maintaining backwards compatibility with existing wallets, so wallet vendors wouldn't have to push as many upgrades to keep their wallets working.

Speed Up Finalization

Many general purpose L2s have long finality times (3.5+ days) because they are optimistic rollups. A dedicated keystore rollup would be a zero-knowledge rollup, so it would have much faster finality times. We expect that a configuration change made on a zero-knowledge rollup could be finalized on L1 within two minutes, and available on L2s within five minutes. This would reduce the need for preconfirmations in some cases.

KEYSTORESLOAD

Just like L1SLOAD would do for L1 state, KEYSTORESLOAD would provide a way for rollups to read state directly from the keystore, which is fast, cheap, and resilient to master chain hard forks. This would make wallets resilient to hard forks of the dedicated keystore rollup and would eliminate more Merkle proofs from calldata when syncing wallets across chains.