Interoperability and scaling solutions for blockchains can be implemented at two different layers:
- Layer 1 (L1) - the code which implements the blockchain runtime (e.g., gossip, consensus, txn processing, etc.); L1 updates require a hard/soft network fork
- Layer 2 (L2) - any code which is not baked into the blockchain runtime (e.g., smart contracts, external entities); L2 updates do not require network forks
Let's use L1/L2 scaling/interoperability to to refer solutions implemented at the respective layer.
-
L1 scaling - splits the networks/blocks into sub-networks/sub-blocks (thus full nodes now only track a fraction of the state space)
Structure: multiple sub-chains with shared security
Examples: Homogenous sharded chains, e.g. Ethereum 2.0 Beacon Chain
Note: There are other L1 scaling opportunities we don't consider: more efficient software implementations, better consensus algorithms, etc.
-
L2 scaling - processes txns/blocks off-chain and uses special logic to apply their effects on-chain
Structure: sub-chains that depend on super-chain security
Examples: payment/state channels, plasma/commit-chains, rollups/compression-chains
Suppose we have two blockchains A and B. By blockchain interoperability, we may mean:
- (asset transfer) - moving/using A's native asset(s) on B (sometimes possible to move back)
- (multi-chain contracts) - a smart contract whose output depends on state/events in A and B
- (oracle contracts) - a smart contract on A or B whose output depends on off-chain state/events
Generally, large existing networks do not work very hard to achieve L1 interoperability for two reasons:
- L1 updates require hard to roll out
- L1 updates can fracture network
- Interoperability dilutes network lock-in effects
On the other hand, new networks generally adopt L1 interoperability for the reverse reasons:
- Rolling out a totally new network is at least as hard as rolling out an L1 update
- Network forks caused by L1 updates are easier to resolve in smaller communities
- Interoperability benefits new entrants since they can gain users from existing networks
There are several basic interoperability structures:
| Type | Examples |
|---|---|
| L1-to-L1 | Merge-mining enabled cross-chain payments/logic |
| L1-to-L2 | Cosmos, Polkadot, etc. |
| L2-to-L2 | Currency bridges AKA side-chains (e.g. BTC/ETH) |
| L1-to-World | Permissioned blockchains with special operators |
| L2-to-World | Price Oracles, Custodial Exchanges |
If we squint, chain interoperability and scaling solutions are essentially the same:
- Scaling is about moving data or txn processing off-chain to increase a chain's throughput
- Interoperability is about moving data or txn processing to a side-chain to add new functionality
In both cases, we reduce the storage and computation requirements for the full nodes of a chain.
Note: the scope of off-chain activity includes side-chain activity
Definition: a versioned, stateful context where computation may occur is called a compute/trust domain
Remark: compute domains can be understood as any transition system augmented with a step counter
Domains may or may not satisfy important security properties:
- Definition: integrity - a domain's state transitions are correct
- Definition: availability - the entire domain state (transition history) is retrievable at any time
- Definition: consistency - all observers of domain state n at time t see the same thing
- Definition: finality - after observing domain state n at time t, will not observe different state n at time t' >= t
Suppose we have two different domains A and B, then:
- computation in A and B occurs independently
- given (1), domain state updates occur in A and B independently
- domain A cannot intrinsically share state domain B; such sharing requires out-of-band protocols
Main Idea: off-chain processing must occur in a separate domain
Migrating entities between domains entails accepting different requirements:
-
Migrating computation: must accept new domain's security properties
-
Migrating assets: must lock up collateral in the current domain to obtain asset vouchers in the destination domain
- an asset is native in the domain it orignated; it's voucherized form in other in all other domains is alien
- asset vouchers can nest recursively; i.e., we may have a voucher for a voucher ... for an asset
- locking up assets to receive vouchers is called entering; redeeming vouchers for underlying vouchers/assets is called exiting
Remark: due to domain independence, without locking up assets, we can trivially double-spend
Examples:
- the base chain where block/txn processing takes place
- an oracle is an asset-free computation that is performed off-chain
- an inter-chain bridge allows assets (but not computations) to be migrated to a side-chain
- a rollup is a asset-effecting computation that is partially performed off-chain
Blockchains have several basic functions:
- state transition function - state production/block validity checks
- block/state sharing - data availability
- consensus mechanism - next block selection
Funadmentally, blockchains (currently conceived) only receive input via txns. A consequence of this is that blockchain networks only share data about txns or their applied effects. That means achieving certain effects using L2 solutions requires additional support:
- Base Chain Observability - requires out-of-band state sharing
- Off-Chain Security - requires trusted operator, side-chain, or base-chain synchronization
Main Idea:
- N parties enter domain by deploying N-way multisig contract to base chain and locking initial balances
- Parties can repeatedly execute versioned state moves/balance updates off-chain by exchanging fully-signed move messages
- One party A can initiate exit challenge period by submitting any fully-signed move to chain
- Other parties can cancel A's exit by submitting more up-to-date fully-signed move during challenge period; otherwise, exit succeeds
Notes:
- A fully signed payment/state update is only the right to exit and apply the cumulative effect of all state updates at once
- All parties may exit instantly without challenge period with fully-signed exit move
- Malicious party may submit stale move to chain to exit in state with more favorable balance/state
Main Idea:
- Plasma/commit-chain operator deploys smart contract to base chain with initial state root of virtual chain
- Users enter domain by locking up money in chain contract to obtain vouchers virtual chain
- Users sign payment txns off-chain and submit to operator who confirms txn
- Operator periodically: starts challenge period by (1) evaluating txn batch and commiting state root to chain; (2) broadcasting txn-data to users
- Users read data (1) and (2) to check that: (a) all confirmed txns included, (b) no money stolen by operator
- User can submit fraud proof during challenge period to force mass-exit if data (b) does not agree with current state root
- User exits domain by asking operator and waiting until next update (or) forcing exit via on-chain contract
Notes:
- If operator does not publish txn data, rational user must force exit because they cannot prove chain validity
- Concurrent exits due to operator fraud can increase txn latency which can lead to potential loss of funds
- Money stolen checks can be avoided via ZKPs, but txn inclusion checks cannot be skipped
- Rational user must surface online at least once per commit to check operator update validity/data availablity
Main Idea:
- Rollup operator deploys rollup contract to base chain with initial state root of virtual chain
- Users enter domain by locking up money in chain contract to obtain vouchers virtual chain
- Users sign txns (including general contract calls) off-chain and submit to operator who confirms txn
- Operator periodically: evaluates txn batch and commmits both state root and compressed txn data to chain
- Users read on-chain data to check that: (a) all confirmed txns included, (b) no money stolen by operator
- User exits domain by submitting exit txn to operator and waiting until next update
Notes:
- In optimistic rollups, steps (4-5) require challenge period and fraud proofs, like in plasma/commit-chains.
- In ZK rollups, step (5) is unnecessary, as txn validation is internalized into base-chain contract using ZKPs
- Data unavailability checks not needed like in plasma/commit-chain because txn data published on-chain
Main Idea:
- Bridge contracts deployed on the base (side-) chain that can validate block header of the side (base) chain resp.
- Users enter domain by locking up assets on base chain
- Once base-chain block finalized, user submits block header to side-chain contract
- Side-chain contract checks block header valid and mints asset vouchers on side-chain
- Users exit domain by using side-chain contract to burn asset vouchers on side-chain
- Once side-chain block finalized, user submits block header to base-chain contract
- Base-chain contracts checks block header valid and releases locked assets on base-chain
Notes:
- If one chain does not have immediate finality, chain reorganizations can result in asset theft
Main Idea:
- Oracle operator(s) publish M-of-N multisig contract to base chain with an initially null, publishable value
- Periodically, M oracle operator(s) sign a txn that updates the published value
- Users enter domain by reading and using published value in some calculation
- Users exit the domain by discarding the oracle value or otherwise aborting the calculation
Notes:
- Though the metaphor is somewhat stretched, it is clear that reading oracle values requires additional trust
Main Idea: two parties (both with addresses in different domains) exchange assets across domains using a commit-reveal scheme
- Hash lock operator deploys hash lock initiator contract and responder contract in two domains
- Initiator A sends hashed value h(x) to responder B offline
- In domain 1, A enters shared domain by locking assets in initiator contract which will send to B's address in domain 1, conditioned on receiving x before timeout 2t
- In domain 2, A enters shared domain by locking assets in responder contract which will send to A's address in domain 2, conditioned on receiving x before timeout t
- A exits the shared domain by sending txn with x to responder contract on domain 2 to claim B's assets before timeout t or waiting for the timeout
- B exits the shared domain by learning x from (4) and sending txn to domain 1 to claim A's assets before timeout 2t
Notes:
- If txns can be censored, A can steal money from B by claiming B's assets but censoring B's claim to get A's assets
- Timeouts on the blockchain can only be represented logically where we use block height as a logical timestamp
| Name | Storage/Internal Txn | Receivable Offline? | General Contracts? | Finality Delay | Additional Security Requirements |
|---|---|---|---|---|---|
| Payment/State Channels | O(0) | No | No | Challenge period unless fully-signed | Designated user always online, Uncensorable Txns |
| Plasma/Commit Chains | O(1) | Yes | No | Challenge period | Designated user always online, Uncensorable Txns |
| Optimistic Rollups | O(N) | Yes | Yes | Challenge period | Some honest user always online, Uncensorable Txns |
| Zero-Knowledge Rollups | O(N) | Yes | Yes | None | Must trust initial setup, Quantum insecure |
| Oracles | N/A | Yes | No | None | Must trust oracle operator |
| Sidechains | N/A | Yes | Yes (impls?) | Send: None, Receive: Side-chain Finality | When receving: must trust side-chain finality |
| Hashlocks | N/A | No | No | Both domains finality | Uncensorable Txns |
- Chain Interoperability or use group slack channel
- SoK: Layer Two Blockchain Protocols
- An Incomplete Guide to Rollups, see also the video presentation
See also the papers for Polkadot, Cosmos, Near, etc. for other examples of sharded chains/chain interoperability.