Inter Blockchain Communication (IBC) is the most popular trust-minimized cross-chain bridging protocol, used by over 110 chains and facilitating over $72B in annual transfers so far (reference).
While other bridging solutions may have well-defined decentralized protocols, they still require users to trust the third-party protocol, which increases trust assumptions.
If I’m making a transaction from chain A to chain B, I should only trust that chains A and B are working fine. Why do I have to depend on some other third party, no matter how good it is? That’s the core principle of IBC: trust the chains, not the bridge.
IBC achieves this by making cross-chain functionality native with the help of light clients. Refer this blog for more details on IBC but in brief, this is how it works :-
- Chain A keeps a light client of Chain B in its state, and vice versa.
- Chains don’t have any idea whose client they are maintaining (chains agnostic) until a connection handshake process is initiated, which connects two chains by performing double authentication.
- Chains themselves don’t communicate with each other directly. If they want to communicate with other chains, they will commit some predefined message in their own chains.
- Relayers listen to these commits as events and pass them to the receiver chains in the form of transactions.
- The receiver chains can verify these transactions against the light client and process them.
Trust Assumptions:
- While relayers act as the main transport layer, the chains don’t need to trust them; they can’t affect security. As for liveliness, one honest relayer is enough. That’s a weak trust assumption.
- Light clients only verify the consensus of the chains, not the actual state transitions. As long as the light clients can guarantee certain properties, IBC tends to function properly. That would be a weak trust assumption for highly secured chains and a strong trust assumption for weakly secured chains.
- Two chains can have multiple clients of each other and multiple connections between them. The receiver chain treats assets from one channel differently from another channel, even though they are from the same chain.
- One interesting thing to consider is that the receiver chain doesn’t have to verify the security of sender chains as long as their light client is functional. It is not responsible for the state frauds of the counter party. From its perspective, all assets received via IBC are the same (since they all pay fees). They can’t disrupt other assets, as the only way for them to revert to the original asset is by traveling via the route it came from.
So to speak, for monolithic chains (eg: Cosmos-hub with tendermint consensus) which have strong consensus, ibc light client architecture works like magic in a trust-minimized way. But what about the rollups, the systems which don’t have the consensus themselves but inherits the security from other L1s like DAs and settlement layers?
Let’s consider some rollup architectures and see if they can scale for ibc.
Zk rollups and Optimistic rollups with Settlement layers :-
With the Settlement layer like Ethereum finalizing rollup blocks, it is fairly simple to integrate IBC as long as the said Settlement layer have a working light client implementation.
Dymension is another example (in fact Dymension might be the most complete case study for IBC + rollups for now). Refer to their official docs to see how Dymension leverages ibc.
In simple terms, a light client of rollup (for packet inclusion proof) with conditional clients, DA consensus light client (for Data availability guarantee) and Settlement layer consensus light client (consensus guarantee) are enough to form a trust-minimized IBC bridge.
Sovereign Rollups :-
Having a settlement layer makes it easy to integrate IBC for rollups. However, having it affects the sovereignty of rollups.
Removing a settlement layer for rollups might completely change how one can look at rollups. Traditional rollups are like a scaling extension of L1 chains. But sovereign rollups are different. They are completely independent networks that rent the consensus from DA layers. The source of trust lies in the network itself, not on the settlement layer.
Let’s discuss the trade-offs involved in integrating IBC for sovereign rollups, the rollups in which end-users can verify the state without relying on any L1 (settlement layer).
Rollkit’s Pessimistic Rollups :-
Pessimistic architecture is the simplest of the rollup architectures. A centralized sequencer executes the transactions and updates the state machine. It publishes the transactions data to the configured DA layer so that anybody can download the data in a trust-minimized way and have guaranteed ordering. The verifiers can then execute the transactions and can verify the correctness by checking their state root against the sequencer’s state root.
Things to take note of in pessimistic architecture :-
- Only full nodes can verify the correctness of the state machine.
- This architecture doesn’t have byzantine tolerance (atleast current design). It’s unclear how honest full nodes can come to a consensus to elect a new sequencer without relying on settlement layer. (ofcourse considering settlement layer is also impossible since it can’t afford to run full nodes in its state machine).
Until the above limitations are not resolved, IBC needs to have some strong trust assumptions to work. A light client of rollup can guarantee double signing resistance, and a conditional light client of DA can guarantee data availability. But since rollup itself doesn’t have any consensus, that makes it a strong trust assumption towards validity of state transition.
One guarantee is that, in byzantine case, the relayers (running full nodes) should stop the relaying once it detects fraud state transition so that the client will be frozen. Relaying is costly (in rollup R to chain C IBC transfer, paying fees for receiver chain while they get compensated on a byzantine state machine is bad business), they should be sensible to enough realize the loss.
We can also try decreasing the light client’s trusting period, enforcing even more cost to maintain the light client. Then again, its still another strong trust assumption. One dishonest relayer is enough to keep the IBC connection lively thus continuing fraud state machine.
Though in the worst case, anyone can hard fork starting from the fraud block height, since the data is available on DA. Then think of how to recover funds that transferred after the invalid block.
So In conclusion, the current pessimistic architecture itself suffers from scaling (trust minimization requires running a full node), it might be hard to integrate IBC without some strong trust assumptions. So its better to consider more robust rollups like optimistic ones or zero knowledge ones.
Optimistic Sovereign Rollups :-
Optimistic Sovereign rollups reintroduces concept of light clients though with a twist. The light clients we have been hearing are the ones that achieves trust minimization by tracking consensus updates. They don’t have the capability to validate the state.
But this new light clients do!
These new lights are capable of validating the state transitions (invalid state transition to be more precise) even though themselves don’t maintain the complete state. Let call them state light clients for now to differentiate them from consensus light clients. This is not an official name by the way.
This architecture’s flow is pretty similar to that of the pessimistic rollups but the main difference is if one want to verify the correctness of the state,
they don’t need to run the costly full nodes, running the light weight state light clients is enough.
When a state light client receives a block, it initially assumes that block have valid state transitions. Hence the name, Optimistic.
But when some(any one honest) full node detect a fradulent state transition, it will construct the state fraud proof and pass it to their peer networks.
The state light nodes can then verify these fraud proofs and can decide if a fraudulent state transition really occurred or not. If proven, they can rollback to the latest trusted block height, halt itself and wait for recovery to take place.
Things to consider :-
- At least one honest full node is required for this architecture in trust-minimized way.
- While running state light node is better than full node, the state light nodes don’t have instant finality unlike full nodes. That’s the reason why some window time period is installed. A block when received considered valid but not finalized. Only when some predefined time is passed and no valid fraud proof is submitted till then, it will be considered finalized.
- Technically the state light nodes don’t have instant finality, but practically the block can be considered finalized. The probability of fraud occurring is very low since it is easily detectable and costly.
Now that we have these state light clients to verify the state frauds, can we consider using them for IBC?
We definitely can! though it requires some considerations :-
- IBC requires instant finality which state light clients doesn’t have. We can solve this problem by introducing fraud proof window period.
// Overhead :-
full node > state light client > consensus light client (eg: tendermint light client)
// instant finality :-
full node > consensus light client > state light client
// security :-
full node > state light client > consensus light client- One concern about IBC is that running a normal consensus light client in state machine itself is being considered a bit of roadblock and not very optimal. Wouldn’t this more so in case of state light clients? Then again, this concern might be relevant only in fraud case, which has a low chance of occurring.
- Implementation of state light client. The concept of state light client is great, but is it easy to implement? proving state transition without maintaining application state requires more than some simple inclusion merkle proofs. Especially considering all different merkle trees available like AVLs, SMTs, Patricia Merkle tree, etc. It might be hard to implement a generalized state light client.
In conclusion, while there might be some challenges for integrating IBC with optimistic rollups, it is still possible to achieve a trust-minimized IBC bridge.
There is one more interesting way.
If there is an L1 chain which can act like a hub of rollups i.e.. running state light clients of rollups, then this can become source of trust for IBC. A consensus light client of this hub can become conditional client, like how a consensus light client of DA can be a conditional client. It removes the need of implementing a state light client directly into IBC.
This hub is just a source of trust for IBC, not for the rollup itself. So it doesn’t effect the sovereignity of the rollups. Think of it more like a service to rollup similar to how a DA guarantees Data availability.
Sovereign ZK-Rollups
Zk rollups are way more straightforward compared to previous architectures. The blocks need ZK proofs to become finalized. So a verifier can verify these ZK proofs and finalize the blocks instantly, without needing to have to run full nodes like in pessimistic rollups and have optimistic view like in Optimistic rollups.
Things to consider :-
- These are considered hardest to implement. A deep understanding of cryptography is essential which can be a hard road block for wide spread adaptation.
- While ZK proofs provides instant finality, from the perspective of receiver chain, processing them on chain still introduces a lot of overhead. Considering there can 10s and 100s of rollups one chain can connect it to, it might not be practical to run all those verifiers on state.
To tackle the second issue, the Avail Fusion of Avail Trinity talks about a unique solution: Proof Aggregation, to remove the necessity of running multiple verifiers for each ZK-rollup. Refer this blog for more details. To conclude, while challenging, it is possible to integrate IBC for ZK rollups in a trust-minimized way.
In summary, Sovereign Rollups represent the latest trend in achieving application-specific blockchains without the need to individually secure consensus security.
At the same time, IBC serves as the cutting-edge bridging protocol driving towards the ultimate endgame of blockchains: establishing a network of interconnected chains where each chain can communicate with every other chain anonymously and trust-minimally, without the need for a third party.
Therefore, understanding the various trade-offs involved in connecting these two innovations is very crucial.
Note: This blog reflects my personal opinions and understanding. If you believe there are omissions or inaccuracies, please don’t hesitate to provide feedback. Your input is greatly appreciated. Thank you!
