Syncing to Other L1s

Non-Ethereum L1 chains, like Gnosis Chain, Polygon, and BNB, are less straightforward to integrate with Keyspace than L2s. There's no way to reference the state root of the L1 KeyStore contract directly on these chains. Instead, we're faced with two options: using an Ethereum block hash oracle to verify the Keyspace state root from Ethereum or re-sequencing the state transitions on the other L1 without any reference to the Ethereum instance.

Block Hash Oracles

As Vitalik mentions in one of his keystore rollup design posts, relying on an oracle to read from the keystore is a significant security risk:

"Oracles" (at least, the kind of tech that some defi people call "oracles") are not an acceptable solution here: wallet key management is a very security-critical low-level functionality, and so it should depend on at most a few pieces of very simple, cryptographically trustless low-level infrastructure.

While this comment was in the context of reading L1 state from an L2, the same principle applies to reading Ethereum state from other L1s. If the oracle is compromised, the security of the entire system is at risk.

Proof-of-Concept

Keyspace's Testnet Beta includes a proof-of-concept that syncs to the testnets of other L1s using Wormhole as an oracle. For future releases, we intend to rely on Ethereum block hash data from multiple oracles using Hashi or a similar approach that requires multiple oracles to agree with each other.

Re-Sequencing on Other L1s

We can potentially avoid the security risks of oracles by re-sequencing the state transitions on the other L1. We don't expect to pursue this path because diverging keystores are hard to reason about and are unlikely to deliver the experience we want for Keyspace users. But for scenarios where no reliable block hash oracle exists, re-sequencing may be the only option.