Recently, Babylon launched a Bitcoin staking campaign on Testnet-4, sparking community discussions about Bitcoin staking. Today, the Chakra research team will take you through the latest Bitcoin staking solutions.

In Babylon's recent Testnet-4, the staking process is divided into three types of transactions: Staking Tx, Unbonding Tx, and Slashing Tx. These transactions generate three types of Bitcoin outputs: Staking Output, Unbonding Output, and Slashing Output. The conversion process is shown in the figure below.

Pledge Transaction

The pledge transaction must include two special outputs. One is the Taproot output holding the pledged assets, which must contain the BTC pledge script defined by Babylon. The other is a zero-amount output, which stores information identifiable by Babylon pledge via OP_RETURN.

The following image shows an example of a staking transaction, where the first output is the staking output, the second is the OP_RETURN output, and the third is the change output.

Staking Output

The stake output is a Taproot output, as Chakra has written before:

Taproot outputs have two payment methods, key payment path and script payment path. Babylon disables the key payment path by setting the internal key to the "Nothing Up My Sleeve" (NUMS) point, making the staked output only payable via the script payment path.

Staking outputs can be spent through three script paths, corresponding to the process diagram:

1. Time lock path

The time-lock path implements the staking function and also serves as a liveness guarantee.

<Staker_PK> OP_CHECKSIGVERIFY <Timelock_Blocks> OP_CHECKSEQUENCEVERIFY

The timelock script locks the staker's BTC for a certain number of blocks. The timelock path does not require other entities, thus providing liveness guarantees for stakers. Even if the finality provider and the contract committee become inactive, stakers can still get their BTC assets back after the lock-up period.

2. Unbinding Path

If BTC is locked by a time lock, how can users end the pledge early? Babylon solves this problem by introducing an unbinding path.

<StakerPk> OP_CHECKSIGVERIFY <CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD <CovenantThreshold> OP_GREATERTHANOREQUAL

This path requires not only the signature of the staker, but also more than

CovenantThreshold

The main reason for introducing the contract committee is to artificially create an unbonding period to prevent pledgers from escaping punishment through the unbonding path.

3. Punishment Path

Punishment is necessary to ensure the security of PoS. If the finality provider behaves maliciously, it is necessary to confiscate its own and delegated funds to provide economic security. Babylon provides punishment functionality by introducing a punishment path.

<StakerPk > OP_CHECKSIGVERIFY <FinalityProviderPk > OP_CHECKSIGVERIFY <CovenantPk1 > OP_CHECKSIG <CovenantPk1 > OP_CHECKSIGADD ... <CovenantPkN > OP_CHECKSIGADD <CovenantThreshold > OP_GREATERTHANOREQUAL

Before the pledge status changes to Active, the pledger must pre-sign a penalty path transaction to prevent them from withholding their signature to avoid BTC loss if the finality provider behaves maliciously. After receiving the pledger's signature, the contract committee first verifies the signature and releases their own signature once it is confirmed to be valid.

Punishable behavior in BTC staking is when a finality provider signs two conflicting blocks at the same height, at which point any user can obtain the private key of the malicious finality provider through EOTS. Since the stakers and the contract have pre-signed the penalty transaction, the user who obtains the private key of the malicious finality provider can sign a transaction to send part of the staked funds to the burn address as a penalty through the penalty path.

OP_RETURN Output

Although Taproot outputs express complex usage conditions with smaller ScriptPubKeys, this also makes it challenging to distinguish pledge transactions from other transactions in the Bitcoin network. Therefore, it is necessary to disclose pledge-related information in other ways so that users can identify penalty transactions based on this information.

Babylon serializes the information that needs to be disclosed, embeds the information in the OP_RETURN script, and attaches it to another output of the pledge transaction. The format is shown in the figure below, and the data must correspond to the data in the Taproot script.

type V0OpReturnData struct { MagicBytes []byte Version byte StakerPublicKey []byte FinalityProviderPublicKey []byte StakingTime []byte }

According to the previous transaction snapshot, the valid data carried by the OP_RETURN output is indeed 4+1+32+32+2=71 bytes in total. In the figure, the FinalityProviderPublicKey of the pledge transaction is f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, which belongs to Chakra.

MagicBytes is used to quickly locate the pledge transaction, while Version is a field reserved for future updates for easy differentiation.

According to the previous transaction snapshot, the valid data carried by OP_RETURN output is indeed

4+1+32+32+2=71 Bytes

In the figure, the FinalityProviderPublicKey of the pledge transaction is f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, which belongs to Chakra.

MagicBytes

It is used to quickly locate pledge transactions, while Version is a field reserved for future updates for easy distinction.

Unbinding Transaction

When a staker wants to unlock their staked BTC early, they can submit an unbinding transaction by spending the unbinding path in the staked output. The unbinding transaction requires that it only accepts a single stake transaction as input and outputs a single Taproot output committed to the unbinding script.

Below is a screenshot of the unbinding transaction, corresponding to the previous staked output.

The second-to-last field starting with ‘20’ is the tapscript of the unbinding path, and the field starting with ‘c1’ is the Merkle Proof of the Taproot internal key and the unbinding path. The NUMS point can be clearly observed.

0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0

In the Witness field of the unbinding transaction, we can observe the signature of the pledger and the signature of the contract committee.

Unbonded outputs can be spent under two conditions: a timelock path and a penalty path, both of which are identical to the paths in staked outputs. At a high level, unbonded outputs are an intermediate state designed to prevent stakers from immediately withdrawing their stake and escaping penalties, ultimately leading to a stable state for withdrawal transactions.

Penalty Transaction

The penalty transaction takes a pledge transaction or unbinding transaction as input, spends it through the penalty path in the Taproot script, and generates two outputs. One output sends part of the staked BTC to a burn address, while the other returns the remaining BTC to the staker.

More strictly speaking, Babylon implements partial confiscation for misconduct instead of burning all BTC staked by stakers at once. This approach provides a higher fault tolerance rate and protects the interests of stakers.

Penalty transactions can only occur with the joint signatures of stakers, the contract committee, and the finality provider. Therefore, even if an individual party is compromised, it will not lead to the collapse of the entire staking system. Penalty transactions act as a deterrent, economically dissuading participants from malicious behavior. As long as the penalty for misbehavior exceeds any potential gain, participants are likely to follow the rules.

Security Analysis

There are two types of security associated with Babylon:

The first type of security concerns the stakers, ensuring that as long as the staker and his delegated finality provider do not engage in any malicious behavior, his staked assets will never be punished.

The second type of security concerns the PoS system itself, ensuring that if participants behave maliciously, the protocol must be able to identify and punish them.

The staker’s perspective

For stakers, once BTC is staked through Babylon’s staking transaction, there are only three ways to transfer funds.

The first is a time-lock path that only requires the user's own signature to spend. This ensures that even if FP and Babylon cease operations, the staker can still get back the original BTC after the pledge period ends.

The second is the unbinding path, which is an intermediate state that creates an unbinding output and allows a shorter unlocking time. This provides the staker with the ability to retrieve their staked funds early.

The third is the penalty path, which is the only path that can harm the interests of stakers. If an outsider tries to attack the penalty path, they must provide the signature of the staker, the signature of the finality provider, and the signature of the contract committee that exceeds the threshold at the same time, which is extremely difficult. Even if the contract committee is malicious, as long as the finality provider is honest, the staker's BTC is safe.

PoS System's Perspective

From the perspective of a PoS system, security comes from the ability to punish finality providers if they behave maliciously.

Babylon uses the EOTS mechanism, if the finality provider double signs a block, any user can extract the finality provider's private key from the two different signatures. This enables them to sign and submit a penalty transaction, with part of the penalty corresponding to the BTC of all voting rights held by the finality provider.

This penalty deters malicious behavior by finality providers, aligning their incentives with providing finality for PoS consensus services connected to Babylon, ensuring the security of PoS systems with large amounts of staked TVL.

In the future, Chakra will continue to work with Babylon to launch a series of staking activities to provide users with multiple benefits while solving liquidity and interoperability challenges, unlocking the huge value of Bitcoin in all crypto ecosystems.