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.
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.
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:
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:
To demonstrate the flexibility in design we’ll take a look at various designs of rollups on top of a common DA layer.
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.
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:
Lower latency but high risk path:
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:
Note that multiple optimistic light clients will depend on the Celestia TMLC. Additionally, you could have the following setup for a logical pessimistic rollup:
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:
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:
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.
We’re always looking for talented individuals interested in working on problems in web3 interoperability infrastructure. Click the link below to get in touch.