[Babylon 101, blog 4] Censorship Resistance via Babylon

Censorship Resilience

PoS blockchains such as Cosmos zones typically require validators holding over 2/3 of the stake to honestly follow the protocols for the inclusion of new transactions in the chain. When validators holding over 1/3 of the stake is adversarial, they can arbitrarily prevent the finalization of blocks, thus selectively censor transactions. For instance, the adversarial validators can engage in ransom attacks, during which they ask for bribes from users with time sensitive transactions (similar to the Validium ransom attack).

Unfortunately, the 1/3-resilience against censorship is not a shortcoming of the design of Cosmos zones, but a fundamental limitation of the PoS protocols with the ability to slash misbehaving validators (e.g., validators that have signed conflicting blocks). This slashability guarantee discourages attackers from creating conflicting chains; however, results in the degradation of the censorship resilience from 1/2 as is the case for Bitcoin, to 1/3, as observed for Cosmos zones.

Babylon for Censorship Resistance

Babylon can help PoS chains with slashability guarantees (e.g., Cosmos zones) to close the gap and achieve the censorship resilience of 1/2. Towards this goal, Babylon connects PoS chains to Bitcoin, enabling them to operate in a rollup mode, where Bitcoin is used as an ordering service for the PoS transactions. During the rollup mode, the PoS validators are only responsible for validating the availability of the data within the PoS blocks, whereas the canonical sequence of blocks is determined by the order of their checkpoints on Babylon. The canonical Babylon chain is in turn constructed using the checkpoints of Babylon blocks on Bitcoin, the ultimate authority for the ordering of the PoS blocks.

Entering the Rollup Mode

Figure 1: Censorship complaint on Babylon

If a user of the PoS chain thinks that a certain transaction tx is censored by the PoS chain, it can prompt the chain to enter the rollup mode by sending a censorship complaint to Babylon (Figure 1). Censorship complaint is a Babylon transaction that contains the hash of the censored transaction tx.

Figure 2: Checkpoint of the censorship complaint becomes k deep in Bitcoin. At this point, validators stop executing the PoS protocol.

Upon observing a censorship complaint on Babylon, PoS validators wait until the checkpoint of the complaint becomes k deep in Bitcoin. By this point, if a validator has not yet seen tx become finalized within the PoS chain, it stops proposing new PoS blocks or signing new proposals (Figures 2). Instead, it sends a checkpoint for its view of the PoS chain to Babylon (Figure 3).

Figure 3: Checkpoint of the censorship complaint becomes 2k deep in Bitcoin. Validators and the user enter the rollup mode.

Once the checkpoint of the censorship complaint becomes 2k deep in Bitcoin, if none of the checkpoints on Bitcoin attest to PoS blocks containing tx in their prefix, the validators (and the user) enter the rollup mode (Figure 3).

During the Rollup Mode

Figure 4: In the rollup mode, validators create bundles and sign those that are available in their view. Bundles with sufficiently many signatures are checkpointed on Babylon by posting their hashes and the associated signatures.

During the rollup mode, any validator can propose a bundle of PoS transactions (Figure 4). Upon receiving a bundle, each validator that entered the rollup mode signs the hash of the bundle if its transactions are available in the view of the validator. Bundle hashes that gather signatures from validators with over 1/2 of the stake are posted to Babylon. These hashes and the associated signatures are called bundle checkpoints. A bundle checkpoint is valid if it is accompanied by signatures from validators holding over 1/2 of the stake.

The signatures on the bundles are needed to prevent the adversary from posting arbitrary hashes to Bitcoin and pretending as if they are checkpoints of unavailable PoS transactions. Recall that upon observing an unavailable checkpoint, the validators stop outputting new PoS blocks as part of the chain to prevent data availability attacks. Thus, without signatures, the adversary could post an arbitrary hash resembling an unavailable checkpoint, and stall the PoS chain. With signatures, the adversary has to corrupt over half of the validators in proportion to stake to obtain an unavailable checkpoint signed by these validators.

To construct the PoS chain during the rollup mode, users of the chain first identify the PoS checkpoints whose timestamps are within 2k blocks of the checkpoint of the censorship complaint on Bitcoin. They subsequently identify the longest PoS chain attested by these checkpoints. Finally, they attach bundles with valid checkpoints to the tip of this chain in the order their checkpoints appear on Babylon.

Exiting the Rollup Mode

Validators exit the rollup mode after observing T>2k blocks building on the checkpoint of the censorship complaint on Bitcoin. Here, T is a protocol parameter representing the duration of the rollup mode. Upon observing these T blocks, both the validators and users of the PoS chain treat the last bundle added to their view of the chain as the new genesis block. This block is used as the anchor restart/bootstrap the PoS protocol.

Limits of Censorship Resistance

Via the rollup mode, the PoS chain mitigates censorship attacks as long as there are enough honest validators to sign the bundle hashes. This implies a censorship resilience of 1/2, matching the resilience of Bitcoin. Unfortunately, it is impossible to design a protocol that attains a resilience greater than 1/2 even with the help of Bitcoin unless all of the PoS block data is posted to Bitcoin, which is not feasible (cf. Theorem 4 of the paper). In the light of this impossibility result, Babylon’s design achieves the optimal resilience against censorship attacks on Cosmos zones.