In a nutshell, Babylon implements the following mechanisms to checkpoint itself to BTC:
An epoching mechanism that disables validator set rotation within an epoch.
BLS multi-signature to generate succinct and verifiable checkpoints for each epoch.
Independent vigilante relayer that submits checkpoints to BTC network via BTC OP_RETURN transactions.
Introduction
Babylon implements a three-layer architecture (Fig 1 below) to help consumer zones obtain secure BTC (Bitcoin) timestamps. Sitting in the middle layer, Babylon acts as an aggregator: It accepts checkpointing data from consumer zones to its ledger while checkpointing its ledger to BTC, so that all the consumer zones’ checkpoints can have BTC timestamps indirectly. Babylon’s BTC checkpoints also protect Babylon itself from long-range attacks, so that the BTC timestamps it generates for the consumer zones are secured. In this post, we will demonstrate how Babylon checkpoints itself to BTC.
Figure 1. Babylon architecture
What Makes a Proper Checkpoint?
For security purposes, conventional checkpoints such as block hash and state hash won’t work. This is because it is impossible to distinguish bogus checkpoints from valid checkpoints of a private fork generated by malicious Babylon validators. In other words, such checkpoints do not support the detection of long-range attacks.
Therefore, Babylon checkpoints must be verifiable: Anyone with the latest Babylon ledger (i.e., a synced Babylon full node) should be able to tell whether or not a checkpoint represents a ledger state committed by at least 2/3 (in terms of total stake) of the Babylon validators.
In addition, Babylon checkpoints must be succinct. This is because BTC network has extremely tight throughput and space constraints: an average of 5 transactions per second and an average transaction size of 300 bytes. Thus, to use BTC respectfully and efficiently, Babylon checkpoints must be both small and infrequent. Indeed, BTC already supports the upload of arbitrary data in a very constrained way via its OP_RETURN transaction type. This transaction supports a special transaction output with a size of up to 80 bytes, and this output will not be included in the BTC UTXO set. These 80 bytes can thus be used to carry arbitrary data without permanently inflating the UTXO set.
A Succinct and Verifiable checkpoint
An example of verifiable checkpoint is the lastCommit carried by every Babylon block, which is the list of Ed25519 commit signatures on its parent Babylon block, signed by the majority of Babylon validators. However, the size of lastCommit is in the order of kilobytes. One will need tens of OP_RETURN transactions to carry one lastCommit. This is not only expensive but is also vulnerable to transaction failures and pollution attacks.
To minimize the checkpoint size, Babylon requires every validator to register a BLS public key when it signs up. BLS signature has the desirable properties that 1) the signatures from any arbitrary signers can be aggregated into one 48-byte BLS multiSig without needing any group ceremony or coordination between the signers, and 2) the BLS multiSig can be verified by anyone who knows the BLS public key of the corresponding signers.
For a block that needs to be checkpointed, every Babylon validator uses its BLS private key to sign the commit hash of this block (carried by the next block as the lastCommitHash) and submits its signature as a special Babylon transaction via Tendermint. The signatures from at least 1/3 validators are then aggregated into one BLS multiSig. The BLS multiSig, plus some metadata (to be specified soon), forms a succinct and verifiable checkpoint for Babylon.
We note that 1/3+ validator power is sufficient for safety. When a Babylon full node observes a checkpoint at block height H that is conflicting with the block-H this node has:
if the corresponding block is available, then all the Ed25519 signers of this block can be identified. By comparing them with the Ed25519 signers of the block-H that this node has, the 1/3 double-signers can be identified and slashed.
if the corresponding block is unavailable, then all the 1/3+ BLS-signed validators are adversarial. In this case, Babylon has less than 2/3 honest validators, so the full node can immediately stall to avoid losses.
Now we have succinct and verifiable checkpoints for any block. The next question is: which blocks need to be checkpointed?
Which Blocks to Checkpoint?
In order to verify a checkpoint, one needs to know what the legitimate set of validators is, as well as their BLS keys. The only way to determine the legitimate validator set is to track every validator set rotation since the genesis. Therefore, whenever there is a validator set rotation, the corresponding block must be checkpointed. Furthermore, it is sufficient to only checkpoint such blocks because it also implicitly checkpoints all the previous blocks committed by this validator set.
In order to have a controllable checkpointing frequency, Babylon implements an epoching mechanism. Every epoch consists of M consecutive Babylon blocks. All requests in these blocks that could cause validator rotation (namely, staking and undelegate requests) are only processed with the last block of this epoch. This way, there will be no validator set rotation within an epoch. Consequently, it is sufficient to only checkpoint one block per epoch.
More specifically, the block we checkpoint is the first block of each epoch-E, BLS-signed by the validator set of epoch-(E-1). This is because this block carries the execution result of the last block of epoch-(E-1) and is committed by the new validator set. By asking the validators of epoch-(E-1) to sign the commit hash of this block, the validator set of epoch-(E-1) effectively acknowledges both the ledger state and the validator power transfer.
Thus, the checkpoint generated in Babylon contains:
epoch number E-1, which indicates the validator set
commit hash of the first block of epoch
EBLS multiSig on this commit hash, signed by 1/3+ validators of epoch-(E-1)
a binary bitmap indicating who in the validator set have signed
Implementation-wise, inside a Babylon node, we introduce two new Cosmos modules to achieve epoching and the generation and maintenance of checkpoints (Figure 2). In particular, the Epoching module wraps the Staking module to control validator set rotation. The Epoching module also handles bond release of the undelegate requests upon BTC finalization (to be covered in a separate post).
Figure 2. Two new modules are introduced to a Babylon node: an Epoching module for validator set rotation control, and a Checkpointing module for checkpoint generation and maintenance. Note that they are not the only new modules introduced.
Submit the Checkpoint
We implement a vigilante relayer to submit the checkpoints to BTC. A vigilante relayer is an independent program that reads the checkpoints from a Babylon node, packages them into BTC OP_RETURN transactions, and submits them to the BTC network using its own Bitcoin. The relayer can optionally attach a Babylon account to the first half checkpoint to claim Babylon rewards.
We call the relayer “vigilante” because it voluntarily contributes to the security of Babylon system. Indeed, one honest and live vigilante throughout the network is enough to guarantee successful and secure Babylon checkpoints to BTC.
In summary, the checkpointing submission sub-system of Babylon node and the vigilante submitter towards BTC are illustrated below in Figure 3.
Figure 3. Babylon checkpoint generation and submission related modules and program.
Comparison with Other Checkpointing Techniques
Besides OP_RETURN transaction, BTC has another transaction type that could be used for secure checkpointing, which is called the taproot transaction. The input UTXO of such a transaction belongs to a Schnorr group public key, and the transaction is only valid if enough members (according to a pre-set threshold) in the group have signed this transaction with their own Schnorr private key. A ceremony is needed to create all the keys and the threshold. A new ceremony is also needed whenever the group composition changes.
Validators of the checkpointing chain can conduct such a ceremony on BTC and register their public Schnorr keys on the checkpointing chain. This way, any data about the checkpointing chain carried by a valid BTC taproot transaction reflects the consensus between these validators. Protocol Lab’s Pikachu protocol uses this technique to checkpoint Filecoin to BTC. Cosmos zone Nomic uses this technique to securely manage the Bitcoins that back up its nBTC token.
Utilizing Taproot transaction is as secure as Babylon’s checkpointing mechanism. It is also an elegant solution because only checkpoints committed by the majority of the checkpointing chain’s validators will appear in BTC ledger. When implemented appropriately, the interlinked Taproot transactions will form an ordered chain of checkpoints, allowing fast retrieve of all the checkpoints without scanning the BTC ledger.
On the other hand, Babylon made a different design choice that favours simplicity, liveness, and flexibility.
Using OP_RETURN transaction and BLS multiSig does not require any ceremony, which could otherwise be cumbersome for Babylon, since Babylon has a short undelegation period and may have high validator rotation rate.
To generate the checkpoints, Babylon validators only need to submit on-chain BLS signature transactions rather than signing BTC transactions. This low-complexity design can hopefully improve the likelihood of timely checkpoint generation. Moreover, with Tendermint’s potential upgrade that supports signature customization, we could use the consensus to force the generation of the BLS signatures. This way, BLS multiSig checkpoint is guaranteed to be immediately available for every committed block. Such enforcement is unlikely to be possible if the checkpoints are generated on BTC. Indeed, when there is no Taproot checkpoint on BTC, one can hardly tell whether it is due to inactive validators or issues with BTC.
By decoupling the generation of the checkpoints from their submission to the parent chain (BTC), Babylon minimizes its dependency on the parent chain. The minimum dependency also allows Babylon to design contingency plans in case the parent chain encounters with issues or makes unfavourable upgrades.
