In the previous blog post Babylon: Bitcoin Security for Cosmos and beyond, we described the general architecture of Babylon. In this post series, we give a deeper dive into how this architecture is implemented in the Cosmos ecosystem. This post explains how Inter Blockchain Communication (IBC) can be used as a natural mechanism for checkpointing a consumer zone to Babylon. We also ruminate on a generalization of this observation: an IBC connection between two zones effectively checkpoints the zones to each other and can potentially be a vehicle for sharing security.
Recall that the goal of Babylon is to checkpoint Cosmos consumer zones into Bitcoin, which functions as a secure timestamping service. At a high level, this checkpointing is performed in three steps:
Consumer zones send checkpoints to Babylon
Babylon sends checkpoints to Bitcoin
Consumer zones read checkpoints from Bitcoin
In this post, we focus on Step-1. We will cover the remaining steps in separate posts.
Remind me why checkpoints?
In our previous Babylon 101 series post, we explained how consumer zone checkpoints can replace weak subjectivity by providing secure and objective timestamps. Such timestamps protect the zone against forks due to long-range attacks, and can bring many benefits, such as reducing stake unbonding period from a few weeks to a few hours, and beyond.
Why checkpoint via Babylon?
We showed that direct checkpointing from consumer zones to Bitcoin is not scalable. To address this issue, we presented Babylon – a checkpoint aggregation service. Babylon is designed to facilitate communication between consumer zones and Bitcoin. In this post, we focus on how consumer zones send checkpoints to Babylon.
What to checkpoint to Babylon?
The checkpoint data should be an immutable snapshot of the zone at a certain block height and must carry a proof of consensus, which proves that this snapshot has been committed by the majority (2/3) of the zone’s validators at this height.
Cosmos zone’s block header is a potential checkpoint since it is an immutable snapshot. The question is then how to add proof of consensus to it and communicate it from the consumer zone to Babylon.
Inter Blockchain Communication
There are multiple ways to implement communication between Babylon and other zones. However, Cosmos already provides a powerful tool for that: the Inter Blockchain Communication protocol (IBC).
IBC enables a relayer between two zones. It has two layers: the transport layer and the application layer. The transport layer establishes secure communication between the two zones, while the application layer interprets the messages (carried by IBC packets) sent between the two zones.
The transport layer is very important to us. This layer essentially establishes a light client of each zone inside the other. The light client of the sender zone maintains a header chain of the sender zone inside the receiver zone. The headers are downloaded from the sender zone (by an IBC relayer that connects to a full node of the sender zone) whenever there is an IBC packet from the sender zone. Most importantly, these headers are attached with the signatures of the majority of the validators of the sender zone, meaning that such signatures are exactly the proof of consensus we required above. Therefore, a working transport layer between a consumer zone and Babylon already allows the consumer zone to checkpoint its entire header chain to Babylon in a verifiable way.
This verified header chain carries a commitment to the state of the sender zone. It thus allows the receiver zone to verify the message carried by an IBC packet by verifying its inclusion in the sender zone’s state. Verified messages will then be processed by the application layer of IBC. This allows Babylon to send verifiable acknowledgments of the consumer zone’s checkpoints back to the consumer zone as verifiable timestamps.
Checkpointing via IBC is trustless. The clients that submit IBC packets are known as relayers. There are no trust assumptions on these relayers except existential honesty: As long as there is at least one honest relayer, IBC communication is possible. This makes IBC trustless: its security only depends on the security of the participating blockchains rather than any third party (contrary to most of today’s bridges).
Checkpointing via IBC
So how exactly do we use IBC for checkpointing? First, we establish a bidirectional IBC connection between the consumer zone and Babylon. This is already provided by the IBC transport layer. Once the IBC connection is set up, the consumer zone has an on-chain light client of Babylon and Babylon has an on-chain light client of the consumer zone.
Figure 2. Checkpointing from the Consumer Zone to Babylon
Checkpointing to Babylon consists of three steps (Figure 2):
The consumer zone on a regular basis ping Babylon by sending IBC packets. Since IBC takes care of sending signed consumer zone block headers, the checkpoint is submitted automatically, and the message itself can be an arbitrary string. This checkpoint can be submitted by anyone in the consumer Zone. The checkpoint is published on the ledger and submitted to Babylon’s mempool by an IBC relayer.
Babylon records the checkpoint in its ledger.
Babylon writes an acknowledgment message and sends it back to the consumer zone as an IBC packet. This acknowledgment includes a proof of the checkpoint inclusion into a Babylon block. Again, this is submitted to the consumer zone mempool by an IBC relayer.
IBC as a general vehicle for security sharing
We use IBC as a natural mechanism for checkpointing a consumer zone to Babylon. More generally, an IBC connection between two Cosmos zones can be viewed as a checkpointing mechanism between the two zones. The fact that IBC connections already exist between many Cosmos zones, therefore, means that there is in fact a lot of checkpointing across the zones in the Cosmos universe. It does not escape our notice that these IBC connections can potentially be a basis for security sharing in the Cosmos ecosystem.
