Get Early Access
You're in! We received your sign-up successfully. 🥳
Oops! Something went wrong while submitting the form.
Please, refresh the page and try again.
Please, refresh the page and try again.
The flexibility in the design of modular blockchains and rollups motivates flexibility in the design of IBC as well. IBC network topology is changing from a homogenous and densely connected network to a heterogenous and sparsely connected network. Modular IBC adapts the IBC protocol to this dynamic environment.
Previously, we talked about how to think about modular interoperability. Today, we deep dive into how modular blockchains affect the design of IBC’s state layer.
Splitting the state layer
Currently, a single Tendermint light client is sufficient to represent a logical blockchain in the IBC network since the network itself is homogenous. Modular blockchains like Celestia break this homogeneity, splitting a logical blockchain into many chains. So instead of a single light client to represent a blockchain, you need multiple light clients to represent a single logical blockchain. Each light client can represent a different layer of the blockchain stack.
Prove it to me
In the monolithic setting, running a full node or verifying a single consensus proof generally suffices to convince a third party of a state transition. In the modular setting, we need to source a variety of proofs to be convinced of a state transition.
We can categorize the various verification methods as such:
- Direct proof (e.g. running a full node)
- Fraud proof (e.g. optimistic rollups)
- Validity or ZK proof (e.g. zk rollups)
- Consensus proof (e.g., light clients)
We can mix and match the composable layers of the blockchain with the verification methods above to convince ourselves of a state transition. For example, we could perform data availability sampling directly against Celestia. Or we could opt to verify a Celestia consensus proof instead.
Regardless of the type of proof used, a logical light client (LC) wants to be convinced of 3 things:
- Data availability (DA)
- Sequencing or transaction ordering (TO)
- Execution
- Settlement
To demonstrate the flexibility in design we’ll take a look at various designs of rollups on top of a common DA layer.
- Execution + Fraud proofs == Optimistic Rollup
- Execution + Consensus proofs == Pessimistic Rollup
- Execution + ZK proofs == ZK Rollup
Can I borrow some security?
In monolithic blockchains, the security of a chain is dependent on mining power in the case of PoW chains and economic stake in the case of PoS chains. This causes various security issues in spinning up new chains like the bootstrapping problem. In the modular blockchain stack, chains can source security externally from one or more sources.
There are a few modes of shared security some of which are IBC compatible out of the box and others which require modular IBC to work properly.
- Inherit security from a producer chain via interchain security (e.g. Cosmos Hub)
- The v1 of cross chain validation replaces consumer chain validators with producer chain validator - Inherit security from a common settlement layer (e.g., Ethereum)
- Inherit security from a common DA layer (e.g. Celestia, EigenDA)
- A common DA layer can provide censorship resistant data for fraud proofs for trust-minimized bridging - Inherit security from a programmable security provider (e.g. EigenLayer)
- A security provider is one that subjects themselves to additional slashing conditions based on some validation work - Inherit security from a producer chain via a checkpointing mechanism (e.g. Babylon)
- A checkpointing mechanism can protect against long range attacks and also weakest link attacks (in multi-hop IBC routing) - Inherit security from re-staking and cross-staking (e.g. liquid staking, superfluid staking etc.)
- Subject staked capital to validator level slashing conditions
How about some examples?
Connecting Ethereum with IBC
For Ethereum L2 <> L2 connectivity, we need multiple light clients to represent each logical L2 chain. Let’s look at optimistic rollups specifically. There’s different IBC channel paths you can form between L2s with different security properties. Note that this example assumes that we have IBC transport running on the chains below. A model using Polymer for IBC transport is different.
Higher latency but low risk path:
- An Ethereum light client and state proof for DA + Settlement.
- An optimistic light client with a conditional rule on Ethereum representing Aribitrum or Optimism for proof of execution + TO.
- The conditional rule ensures that an Arbitrum or Optimism block has settled and has been finalized on Ethereum before routing to the other L2.
Lower latency but high risk path:
- A solo machine, committee, or consensus light client representing an attestation by a third party or a sequencer as a soft confirmation.
- An optimistic light client with a conditional rule on Ethereum representing Arbitrum or Optimism for proof of execution + TO.
Extending IBC to Celestia Rollups
Let’s use Celestia as an example, you need multiple light clients to represent a logical optimistic rollup. Celestia serves up consensus proofs as proof of DA and TO.
See modular IBC in action on an IBC chain connected to a Celestia rollup:
- A Tendermint light client (TMLC) representing Celestia for proof of DA + TO
- An optimistic light client initialized with a conditional rule on Celestia representing the optimistic rollup for proof of execution
- The conditional rule ensures that a block of data is available on the Celestia network before finalizing a block.
Note that multiple optimistic light clients will depend on the Celestia TMLC. Additionally, you could have the following setup for a logical pessimistic rollup:
- A Tendermint light client (TMLC) representing Celestia for proof of DA + TO.
- A Tendermint light client (TMLC) initialized with a conditional rule on Celestia representing the pessimistic rollup for proof of execution
- The conditional rule ensures that a block of data is available on the Celestia network before finalizing a block.
Shared Security with Eigenlayer using IBC
Eigenlayer allows Ethereum validators to restake or subject their Ethereum stake to additional slashing conditions that are enforceable on-chain. This allows consumer chains of Eigenlayer to borrow security from the Ethereum network.
By adding a slashing condition on Ethereum, EigenLayer validators can sign off on consumer chain headers for increased levels of security. If EigenLayer integrates IBC, cross chain validation can be used to add EigenLayer validators into the active validator set of the consumer chain. Otherwise, a consumer chain can still inherit some protection at the IBC connection level for connected chains.
How this would work:
- A slashing condition on Ethereum for double signed headers means that if EigenLayer validators double sign a header for a consumer chain ⅓ of the stake on EigenLayer will get slashed.
- Chains connecting to an IBC enabled EigenLayer consumer chain will need to run two light clients — one for EigenLayer and another for the consumer chain.
- A connected chain will verify that a header has been signed by both the consumer chain and EigenLayer before accepting.
- This means that IBC connections to EigenLayer consumer chains have fork and additional economic protection against attacks.
Shared Security with Babylon using IBC
In the case of Babylon, it serves as a checkpointing or timestamping service that publishes an aggregate timestamp to Bitcoin to allow chains to leverage Bitcoin security for specific transactions. It serves as a producer of security and connected chains are considered consumers of security.
By opening up a connection to Babylon, a consumer chain can checkpoint states to Bitcoin to leverage Bitcoin security for high value transactions. Additionally, they must enforce a slow finality rule to delay the finalization of these transactions until the checkpointed state is *k-*deep **in the Bitcoin network.
See modular IBC in action on the Babylon consumer chain:
- A localhost client is initialized with a conditional rule on the Babylon TMLC.
- The conditional rule ensures that a committed packet is checkpointed before execution. - A packet is written over the initialized localhost connection/channel.
- The packet is not executed until it’s both checkpointed and committed. - Sending a high value packet from a Babylon consumer chain → IBC connected chain:
- Send first over the localhost connection/channel enforcing the slow finality rule.
- Once slow finality is guaranteed, the packet gets sent over an IBC connection to the IBC connected chain.
Polymer at Shared Security Summit
During ETH Denver 2023, Polymer Labs co-hosted the Shared Security Summit with many of our ecosystem partners. Fortunately, our friends at Eigenlayer and Babylon Chain recorded all of the presentations.