Host-Extension Architecture

Describes the Host-Extension architecture, a capital efficient Hub and Spoke architecture - the optimal way to achieve a unified ledger over multiple async environments.

Summary

The Host-Extension architecture is an evolution of the more traditional Hub and Spoke architecture, where liquidity and execution is scattered between multiple environments, and the main role of the Host chain is to contain the unified ledger for settling application logic.

Host Chain Contracts: Contains application logic, and handles critical operations that require low-latency — such as liquidations within a lending protocol

Extension Chain Contract: These contracts satisfy fully the vision of Risc Zero, which states that in the future blockchains will be mostly populated with zk-proofs that serve as anchors to reconstruct the state. With the current proving times, this state is always reconstructed within the host-chain

Design Considerations

Unifying state for an application over multiple environments requires a careful design to satisfy finality requirements for a sufficient end-user experience.

We can consider each blockchain environments as separate servers that need to arrive at a mutual state. For this example we are considering each rollup to be a fully separate state, as from a technical implementation perspective the native bridges via ETH Mainnet do not provide the required connections to sync state.

Option A: Full Sync with multiple deployments

For certain non-latency intensive applications it can be suitable to deploy the full protocol on multiple chains and periodically sync between each deployment to expand cross-chain user experience.

The main factor that developers need to be aware is that the application logic can be built along two principles:

• Full sync - This will result in an internal clock-time of around 30-60 seconds for lightweight applications, or even more if the state sync is extensive. Order flow have to be managed accordingly

• Partial sync - The siloed deployments need to be able to operate on the underlying chains block time, and reconcile the state periodically for global sync.

Option B: Host-Extension

For medium latency intensive application the Host Chain and Extension Chain architecture can implemented. This design operates with block latency on one execution environment, and higher latency for execution environments.

Host chain:

• Contains protocol logic, all operations settle on host chain

• Users can interact with block latency on these contracts

• High throughput chains are better as host chains, as large transactions volumes can clog the host chain.

  • Specific limitation we observed is that about 100 transactions were possible to submit on Linea in one block during load tests, as cryptographic operations are limited per block in order for the Linea prover to be able to prove L2 state to L1 (Note: The Linea team has been actively raising this ceiling, but similar overheads can exist on other chains and applications need to be designed accordingly to avoid generating a queue).

Extension chain:

• Each UserOp is a proof emitting event that is than delivered by the sequencer.

• Inflow UserOps originate in extension chain and delivered to host chain

• Outflow UserOps originate from host chain and delivered to extension chains

• The block time of the host chain is a full overhead for proof generation and delivery:

  • For example if host is on Ethereum mainnet each transaction needs to wait 12 seconds

Option C: Full Stateless Design - Research Phase

This approach is currently in research phase and has a high dependency on zero-knowledge proving time advancing to a sufficient level.

On high-level this is equivalent to only having extension chains and it fully satisfies the long-term vision of only having zk-proofs on-chain while executing application logic off-chain.

The on-chain proofs can be used to fully recalculate the applications state, but all the application logic is calculated within the zkVM.