Bitcoin-Enhanced Proof-of-Stake Security: Possibilities and Impossibilities

TL;DR

The paper tackles fundamental security challenges in Proof-of-Stake systems by introducing Babylon, a protocol that anchors succinct PoS checkpoints onto Bitcoin to achieve slashable safety and improved liveness. It formalizes the impossibility of slashable safety without external trust, then presents Babylon 1.0 with fast finality and a rollup mode that leverages Bitcoin to recover liveness, followed by a full two-mode Babylon protocol achieving optimal liveness under data-limited timestamping. The work provides rigorous security proofs, implements a prototype checkpointing system, and analyzes withdrawal latency and cost, showing practical feasibility at modest annual costs. Overall, Babylon offers a principled method to combine PoS efficiency with Bitcoin’s strong trust assumptions, enabling faster stake withdrawals and resilient security for young or high-value PoS ecosystems.

Abstract

Bitcoin is the most secure blockchain in the world, supported by the immense hash power of its Proof-of-Work miners. Proof-of-Stake chains are energy-efficient, have fast finality but face several security issues: susceptibility to non-slashable long-range safety attacks, low liveness resilience and difficulty to bootstrap from low token valuation. We show that these security issues are inherent in any PoS chain without an external trusted source, and propose a new protocol, Babylon, where an off-the-shelf PoS protocol checkpoints onto Bitcoin to resolve these issues. An impossibility result justifies the optimality of Babylon. A use case of Babylon is to reduce the stake withdrawal delay: our experimental results show that this delay can be reduced from weeks in existing PoS chains to less than 5 hours using Babylon, at a transaction cost of less than 10K USD per annum for posting the checkpoints onto Bitcoin.

Figures (5)

• Figure 1: Babylon posts PoS block hashes and the validator signatures on them to Bitcoin. Ordering of these hashes enable clients to break ties between conflicting PoS chains, and slash adversarial validators before they withdraw after a safety violation. The canonical PoS chain in a client $\mathsf{c}$'s view is shown by the red circle. Dark blue blocks represent the checkpointed chain of PoS blocks in $\mathsf{c}$'s view. The fast finality rule determines the PoS chain, while the slow finality rule determines the checkpointed chain, which is always a prefix of the PoS chain.
• Figure 2: An adversary that controls a supermajority of active validators finalizes PoS blocks on an attack chain (top). It keeps the attack chain private, yet posts the hashes of the private blocks and their signatures on Bitcoin. Once these checkpoints are deep in Bitcoin, adversary helps build a conflicting chain (bottom) in public, and posts the hashes of its blocks and their signatures on Bitcoin. A client that sees the earlier checkpoint for the unavailable blocks, and the later one for the public blocks has two options: (1) It can stop outputting the new PoS blocks, or (2) it can ignore the earlier checkpoint and output the public blocks from the bottom chain. However, the adversary can later publish the unavailable blocks, and convince a late-coming client to output the blocks from the top (attack) chain, causing a safety violation. Moreover, as the adversary might have withdrawn its stake by the time the blocks in the top chain are published, it cannot be slashed. To avoid this attack, clients choose to stall upon seeing block $b$, i.e.emergency-break, if they see a signed checkpoint for the unavailable blocks.
• Figure 3: There is an epoch $e$ block containing a withdrawal request, and the hash of the last epoch $e$ block and the signatures from the corresponding active validator set appear in a confirmed Bitcoin block in a client's view. The validator is granted permission to withdraw its stake once the Bitcoin block with the checkpoint becomes $k$ deep in the confirmed Bitcoin chains of sufficiently many validators.
• Figure 4: Inactivity leak attack. Due to inactivity leak, honest and adversarial validators lose their stake on the attack and canonical chains respectively. A late-coming client cannot differentiate the canonical and attack chains.
• Figure 5: If $\mathsf{tx}_1$ is observed to be censored by an honest validator $\mathsf{v}$, it sends a liveness transaction to Bitcoin. Once the liveness transaction becomes $2k$ deep in $\mathsf{v}$'s and the clients' views, they enter the rollup mode. In the rollup mode, validators group transactions into bundles and post signed hashes of these bundles to Bitcoin.

Theorems & Definitions (25)

• Definition 1
• Proposition 1: Chain Growth
• Definition 2
• Theorem 1
• Proposition 2
• Theorem 2: Slashable Safety
• Theorem 3: Liveness
• Theorem 4
• Theorem 5: Slashable Safety
• Theorem 6: Liveness