Written by: psi, jesse, krane (Asula)
Thanks to runchao, xinshu, jim, cygaar, patrick, will, ibrahim, lamby and ren for their thoughtful feedback and comments.
The concept of restaking has recently experienced a surge in popularity. It allows for the creation of new services and networks that can lean on the cryptoeconomic security and decentralization of well-established blockchains like Bitcoin and Ethereum. Using restaking, new Proof-of-Stake (PoS) blockchains or other services needing cryptoeconomic security can lower bootstrapping costs by allowing tokens like ETH and BTC to be used as valid stake on their network. Every time a new network is bootstrapped, the blockchain itself has to pay yield to native token stakers in order to incentivize them to participate in consensus and secure the network. The yield required to pay stakers of a PoS chain is exceptionally high due to the large risk of holding and staking native tokens of newer networks. A holder of ETH or BTC, on the other hand, isn’t faced with as much volatility or risk and as such would require a lower relative yield to provide the same amount of cryptoeconomic security. Ethos Stake talks about this phenomenon in their Price of Sovereignty article.
Restaking is an example of cryptoeconomic shared security, where stakers opt in to secure additional networks or services. The cost to achieve security through restaking is the yield paid out to the operators and restakers of the restaked network or service. Validity Rollups, conversely, achieve cryptographic shared security through validity proofs. Proofs allow rollups to inherit the security of a base chain at the cost of posting data and using this data to verify the accompanying proofs on the base chain. There is no opt-in nature to cryptographic security. To compare this with restaking, if everyone staking to Ethereum also restakes to an additional service, e.g. EigenDA, then the security of the restaked service also approaches the security of Ethereum, the “base” chain.
The main difference between cryptoeconomic and cryptographic security lies in its opt-in nature and the cost to achieve it. In some ways, cryptographic security can be seen as the asymptote that cryptoeconomic security tends to. However, the cost to achieve the same security may vary significantly.
NB: We are using security as an overloaded term here: in practice, security is multi-faceted and includes aspects such as reorg resistance and censorship resistance.
On chains like Bitcoin, without battle-tested ways to verify proofs or run general purpose programs, cryptoeconomic security through restaking platforms, such as Babylon, can offer an enticing pathway to experimentation. Existing BTC holders can make bootstrapping experiments possible via Babylon’s Bitcoin Staking Protocol. Framed this way, we believe Babylon can have a large-scale impact on the future of Bitcoin development by providing a platform for new ideas, experiments and more user-centric applications.
What is Babylon’s Bitcoin Staking Protocol?
Babylon’s Bitcoin Staking Protocol is a system that allows Bitcoin holders to stake and restake their BTC to secure different Proof-of-Stake based blockchains. It offers novel yield opportunities to Bitcoiners without requiring them to move their assets off-chain. In this post we break down the protocol’s architecture and lay out the system’s design decisions as well as the risks that interested users or potential consumers of BTC security should consider. Before we dive into the Bitcoin Staking Protocol, let’s take a step back and discuss the design considerations that are required when building a protocol that enables BTC to be staked to secure PoS networks.
A well-functioning PoS network has a few defining properties. The foremost is the ability to detect and penalize malicious actors by slashing their stake to maintain an incentive-aligned system. This would mean BTC on Bitcoin needs to be slashed in case of equivocation on a BTC security-consuming PoS chain. Another defining property of a PoS network is the capacity for a staker to withdraw or unbond their stake permissionlessly. In the Bitcoin context, this would imply the staker can unbond their BTC on Bitcoin without requiring sign-off from any other party on any PoS chain. In fact, since the BTC lives on Bitcoin, a well-designed staking protocol can allow BTC to be unbonded even if the consumer PoS chain goes down. Babylon implements all these properties and a timestamping feature to enable fast unbonding in their staking protocol. In particular, Babylon’s staking script on Bitcoin, the Babylon Chain (built with the Cosmos SDK) and Consumer Chains with specialized machinery to enable BTC staking come together to achieve the protocol. BTC stakers interact with the staking script to secure consumer chains or zones. Consumer chains are PoS blockchains that derive cryptoeconomic security from BTC the asset. To become a Babylon consumer, PoS chains need to add a finality gadget involving programs known as finality providers to their consensus. Finality providers vote on every block of the consumer chain after core consensus. These finality providers have BTC staked to them and can be slashed in case of equivocation. We’ll talk more about finality providers later in this article.
The Babylon Chain acts as a gateway for the participants (stakers, finality providers and consumers) in the staking protocol to register themselves, and it also performs the function of timestamping data onto Bitcoin. However, the chain is also the first consumer of the BTC staking protocol. A rough depiction of the whole system looks like this:
Babylon Overview
This is quite similar to EigenLayer, which provides a set of contracts on Ethereum to enable restaking to Actively Validated Services (AVSs):
Eigenlayer Overview
The key differences between the two architectures stem from the fact that Bitcoin lacks a Turing-complete virtual machine, which makes implementing restaking or even staking far more challenging. It is also for this reason that a lot of the book-keeping, such as registration of new finality providers and accounting for new staking transactions, happens on the Babylon Chain, whereas on Ethereum, it would trivially happen on the EigenLayer smart contracts.
NB: Babylon is under active development and documentation about some parts of the protocol is sparse. We’ve done our best to piece together information from Github, the Babylon litepaper and the available documentation. Our apologies for any mistakes and inaccuracies! Special thanks to Xinshu and Runchao from Babylon for responding to questions!
With that said, let’s get into the core components of the Babylon Staking Protocol:
Bitcoin Staking Script
Since BTC lives on the Bitcoin blockchain, the staking process will naturally start there. To stake, a user locks their bitcoin in a staking vault using the staking script on Bitcoin. This vault includes a timelock. The staker specifies how much BTC they want to stake, how long they want to lock their coins (thus defining the period for the timelock), and a public key that belongs to the finality provider they wish to delegate to. The finality provider is effectively an entity to which the BTC holder is delegating their BTC (the finality provider could also be a BTC holder themselves, but we view them as two separate actors in the protocol). The finality provider is required to participate in voting on the consumer chain to finalize its blocks and earn yield for the BTC staker. If the finality provider double-signs transactions, their keys get leaked, and the delegator’s BTC gets slashed (more on this in the next section).
NB: Currently, the staking script on Bitcoin can only be used to stake to the Babylon Chain. Restaking can be added with a slight modification to the script though.
The staking transaction is a core component of the protocol since it pre-defines how the locked BTC will be spent in the future. This includes cases where BTC is unbonded, slashed or withdrawn. Let’s look into the staking transaction a bit more.
Bitcoin Staking Transaction
The bitcoin staking transaction specifies a transaction with three output paths:
- Staking withdrawal transaction
- Unbonding transaction
- Slashing transaction
These outputs can be considered as the “result” of the staking transaction. Despite lacking a Turing-complete virtual machine, Bitcoin Script can enable more expressive transactions by using creative combinations of pre-signed transactions, Taproot transactions and Schnorr signatures. Over the last few months, talks of increasing the expressivity of Script by adding new opcodes through soft forks has picked up. Many of these are discussed regarding the utility they offer Bitcoin to enable a specific type of transaction called a Covenant. A Covenant refers to a protocol that enables spending criteria to encumber bitcoins to some future conditions. Simply, the protocol can impose conditions on how bitcoins can be spent in the future. These are especially relevant for Babylon because, in the absence of Covenant functionality in Script, the staking protocol must add a Covenant Committee. The Covenant Committee is an M-of-N multi-sig that emulates Covenants functionality on Bitcoin. As far as the staking protocol is concerned, the covenant committee is used to enforce the rules that govern withdrawal, unbonding and slashing of BTC supplied by stakers.
It’s important to note that the covenant committee cannot act against stakers to steal funds committed in a staking transaction. However, the covenant committee can:
- Censor staking transactions to prevent users from staking their BTC through Babylon.
- Collude with the stakers so that a malicious staker can circumvent slashing (stakers could try to “bribe” the covenant committee using some funds that would otherwise be slashed).
NB: The Babylon docs mention that they plan to move away from the committee as soon as covenant functionality is available natively on Bitcoin.
Now let’s expand on how each of the three staking transaction outputs can resolve:
- Staker Withdrawal Transaction: Allows the staker to withdraw Bitcoin after a timelock. The staker creates this timelock during the staking transaction to reflect the period of time they intend to stake for. They can choose to unbond their Bitcoin before the timelock ends during the staking period using the unbonding transaction.
- Slashing Transaction: If the user’s delegatee (the finality provider in Babylon nomenclature) equivocates in a finality round on any external PoS consensus, its secret key will be exposed, allowing anyone to execute the slashing transaction. In a slashing transaction a predetermined amount of BTC gets sent to a burn address and the rest is returned back to users. This transaction needs signatures from the staker, the covenant committee and the finality provider. The staker and the covenant committee pre-sign this transaction during the staking transaction, so the only signature required to complete the slashing transaction is the finality provider’s. When performing a voting round on an external PoS system, the finality providers use a special form of signatures known as Extractable One-Time Signatures (EOTS). The significance of an EOTS signature is that if the same finality provider signs two blocks at the same block height (double signs), their private key becomes extractable from these signatures. This effectively leaks the private key, allowing anyone to sign the slashing transaction. Using EOTS is a clever technique for performing slashing and getting around some of the fundamental limitations of Bitcoin. It is important to note that using EOTS also means the staking protocol can only slash for equivocation (double signing) but cannot slash BTC for other infractions like downtime since the private key is only leaked on double signing.
- Unbonding Transaction: The staker can trigger an unbonding transaction sooner than their original withdrawal timelock; however, the bitcoin must go through a new timelock corresponding to the unbonding period of the PoS chain. During the unbonding period, the BTC can still be subject to slashing. The unbonding transaction requires the signature of the staker and the covenant committee to execute. The covenant committee pre-signs on this transaction during staking so the only signature required to execute at the moment the staker wants to unbond is their own.
Staking Transaction Flow
Consumer Zones
Consumer Zones are PoS blockchains that derive BTC security using the Bitcoin Staking Protocol. Consumer Proof-of-Stake networks must be set up with finality providers, as well as multiple modules and services that enable connectivity to the Babylon PoS chain for certain processes important for the lifecycle of receiving and managing staked Bitcoin transactions.
Finality Providers
To consume BTC security, a PoS network must attach a finality gadget to their consensus algorithm. As previously explained, this finality gadget runs directly after the consensus of the PoS network and includes votes from participants known as finality providers. Finality providers receive stakers’ BTC to secure consumer chains and participate in voting during the so-called finality round. To vote, they use a special signature scheme known as EOTS, which we first introduced in the slashing transaction above. This is used to enforce that if a given finality provider votes at the same block height twice, their private key becomes extractable. The exposed private key can execute slashing transactions for all the stakers delegating to that finality provider. Upon the execution of a slashing transaction, the amount of BTC to be burned is sent to the burn address as punishment for equivocation and the rest is returned back to the staker. Since the same private key is used in every stakers’ transaction, all stakers to the equivocating finality provider get slashed. We expect finality providers to be the same entities as validators for the consumer chains.
In current implementations of the initial staking transaction, there is some facility for a user to restake the bitcoin by specifying multiple finality providers’ EOTS public keys (link to implementation, or see this article). This would allow the same BTC to be restaked across multiple PoS networks. However, restaking is not yet enabled in Babylon. In the future, users can use multiple finality providers for the same network or use multiple finality providers for multiple networks. Since a slashing event corresponds to the leakage of the finality provider’s private keys on Bitcoin, even if the same entity is acting as the finality provider for multiple networks, they should keep keys across these networks separate. Without separating their keys across different consumer zones, there wouldn’t be a way to know if the finality provider equivocated on one network or several networks.
Connectivity with Babylon Chain
Consumers that want to access BTC security register themselves to the Babylon Chain. Finality providers that want to provide services to consumers are also registered on the Babylon Chain. Any new delegations from stakers are observed by the Babylon Chain and communicated by Babylon to the consumer. The Babylon Chain effectively acts as a coordination hub for all the parties involved in the Bitcoin Staking Protocol. After initial registration, the consumer will also send any slashing messages to update the registry on Babylon. The diagram below outlines most of the interactions between consumers and Babylon:
Consumer<>Babylon Interactions
Additional Consumer Modules
Although consumers use Babylon for certain accounting tasks, they are required to run some additional modules to track its finality providers, delegations and slashing/unbonding changes:
- BTC Light Client module – Maintains a BTC header chain based on the PoW rules of Bitcoin. It provides information about the canonical Bitcoin chain and their finality.
- BTC Staking module – Before a finality provider can receive stake, it must be registered on the Babylon PoS. The BTC staking module is responsible for handling BTC staking requests for the consumer chain. It is also responsible for keeping track of the finality providers on the consumer, unbonding transactions and slashing.
- BTC Timestamping module – This is included on the consumer to stay synchronized with Bitcoin, as well as timestamps from the Babylon chain used for expedited unbonding.
- Finality module – Track outcomes from the finality rounds and check results from finalized blocks on the consumer.
Applications
Let’s also take a look at what kind of applications or infrastructure can be built as Babylon consumers:
- For existing chains, adding Babylon could allow for additional economic security without increasing the load on validators. The Cosmos Hub has some really great discussion around this on their forum.
- For new chains that want to lower their cost of bootstrapping the network before transforming into sovereign chains themselves.
- For chains intending to scale Bitcoin, the lack of cryptographic verification on mainnet poses a significant restriction. Cryptoeconomic security can act as a suitable middle-ground for experimentation before features such as OP_CAT get soft-forked into Bitcoin. We should note even if Bitcoin supports verification, other additive services may still benefit from using cryptoeconomic security.
- For chains intending to provide services to rollups on Bitcoin (once cryptographic security is available). This includes data availability layers, shared sequencing layers and settlement layers. These services for rollups can provide cheaper data availability and proof verficiation. They can also provide lower latency unencumbered by Bitcoin’s 10 minute block times and probabilistic finality.
Until now, we’ve mostly talked about the staking flow on Bitcoin and the consumer PoS networks. It’s important to note that the stake distribution is maintained on the Bitcoin, but voting power is used on the PoS networks. A malicious actor can potentially slow down the PoS chain, resulting in an out-of-date staker set used to validate a PoS block. This would mean that an attacker can unbond their stake on Bitcoin but still have the power to fork on the PoS chain. Even if their key gets leaked once the equivocation is detected, there are no funds at stake for the attacker anymore. This is where the Babylon PoS Chain comes in.
The Babylon PoS Chain
The Babylon Chain is a standalone PoS blockchain, which is also the first consumer of BTC security from the Babylon Bitcoin Staking Protocol. As previously mentioned the Babylon Chain acts as the coordination hub between the different actors in the staking protocol by tracking staking transactions, consumer registrations and finality provider registrations across all consumers.
Babylon also timestamps block data from consumers onto Bitcoin. Consumers post block hashes and staking set information to Babylon which then aggregates this data across several consumers before posting it to Bitcoin, thus amortizing the cost of posting to Bitcoin. In theory any data can be posted to Bitcoin to timestamp it. Since signatures provide proof of authenticity by combining timestamping with signatures, users don’t just get proof of the authenticity of an event, but they can also verify that the event happened at a particular point in time. NB: The unit of time for this timestamping protocol is the Bitcoin block height, not a traditional unit of measurement such as seconds or minutes.
The timestamping protocol has two main benefits:
- A malicious finality provider can slow down a consumer chain, unbond their stake on Bitcoin, and equivocate on the consumer because the consumer assumes incorrect stake distribution since they don’t have up-to-date information. We call this a “nothing at stake” attack. By synchronizing Bitcoin and the PoS stake chain, the consumer’s finality provider set can never be in doubt, preventing this “nothing at stake” attack.
- To enable fast unbonding. On PoS blockchains, long-range attacks are possible since no expensive computational work is required to rewrite the history of the blockchain. This leads to longer unbonding times on PoS networks as there needs to be lead time to find and slash for such attacks. By posting timestamps to a Proof-of-Work chain like Bitcoin where rewriting history is computationally expensive, unbonding times can be made meaningfully shorter. This is becuase Bitcoin becomes the source of truth instead of having to rely on social consensus and since its extremely expensive to rewrite the history of Bitcoin (due to the Proof-of-Work nature of the chain), the truth can be indisputable.
To put all of these pieces together, we can now look at a more holistic view of the Babylon Bitcoin Staking Protocol, incorporating the staking script on Bitcoin, the Babylon PoS Chain, Consumer Zones, Finality providers and other supporting infrastructure:
Full System Overview: Babylon
Conclusion
In this piece we’ve pieced together how Babylon’s Staking Protocol works. Our goal was to elucidate the core components of the protocol and point out some implementation differences between restaking protocols on smart contract platforms like Ethereum and on Bitcoin. We also point out some benefits of anchoring security on an asset native to a Proof-of-Work chain as well as some of the drawbacks of using a chain like Bitcoin with limited expressivity.
References