In the future, Chakra will continue to cooperate with Babylon to launch a series of staking activities, providing users with multiple benefits.

Recently, Babylon launched a Bitcoin staking activity on Testnet-4, sparking discussions in the community about Bitcoin staking. Today, the Chakra research team will lead you to understand the latest Bitcoin staking scheme.

In the recent Testnet-4 of Babylon, the staking process is divided into three types of transactions: staking transaction (Staking Tx), unbonding transaction (Unbonding Tx), and slashing transaction (Slashing Tx). These transactions generate three types of Bitcoin outputs: staking output (Staking Output), unbonding output (Unbonding Output), and slashing output (Slashing Output). The conversion process is shown in the following figure.

Staking Transaction

The staking transaction must include two special outputs. One is a Taproot output holding the staked assets, which must contain the BTC staking script defined by Babylon. The other is a zero-amount output, which saves Babylon staking identifiable information through OP_RETURN.

The following figure 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 staking output is a Taproot output, as mentioned in a previous article by Chakra:

Taproot outputs have two spending paths, namely key path and script path. Babylon disables the key path by setting the internal key to the "Nothing Up My Sleeve" (NUMS) point, making the staking output only spendable through the script path.

The staking output can be spent through three script paths, corresponding to the process diagram:

1. Timelock path

The timelock path implements staking functionality and serves as an activity 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 stakers with an activity guarantee. Even if the finality provider and covenant committee become inactive, stakers can still retrieve their BTC assets after the lock period.

2. Unbonding path

If BTC is locked by a timelock, how can users end the staking early? Babylon addresses this issue by introducing the unbonding path.

StakerPk> OP_CHECKSIGVERIFYCovenantPk1> OP_CHECKSIG CovenantPk1> OP_CHECKSIGADD … CovenantPkN> OP_CHECKSIGADDCovenantThreshold> OP_GREATERTHANOREQUAL

This path requires not only the staker's signature but also signatures from more than CovenantThreshold members of the covenant committee. The main reason for introducing the covenant committee is to artificially create an unbonding period to prevent stakers from evading penalties through the unbonding path.

3. Slashing path

To ensure the security of PoS, slashing is necessary. If the finality provider behaves maliciously, it is necessary to confiscate their own and delegated funds to provide economic security. Babylon introduces the slashing path to provide slashing functionality.

StakerPk> OP_CHECKSIGVERIFYFinalityProviderPk> OP_CHECKSIGVERIFYCovenantPk1> OP_CHECKSIG CovenantPk1> OP_CHECKSIGADD … CovenantPkN> OP_CHECKSIGADDCovenantThreshold> OP_GREATERTHANOREQUAL

Before the staking status becomes active, stakers must pre-sign a slashing path transaction to prevent them from withholding signatures to avoid BTC loss if the finality provider behaves maliciously. Upon receiving the staker's signature, the covenant committee first verifies the signature and, once confirmed valid, releases their own signature.

A punishable behavior in BTC staking is when the 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 stakers and the covenant have pre-signed the slashing transaction, a user who obtains the private key of the malicious finality provider can sign a transaction to send a portion of the staked funds to a burn address as a penalty through the slashing path.

OP_RETURN Output

Although Taproot outputs express complex usage conditions with relatively small ScriptPubKeys, this also makes it challenging to distinguish staking transactions from other transactions on the Bitcoin network. Therefore, it is necessary to disclose staking-related information through other means so that users can identify slashing 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 staking 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}

Based on previous transaction snapshots, the effective data carried by the OP_RETURN output totals 4+1+32+32+2=71 bytes. In the figure, the FinalityProviderPublicKey of the staking transaction is f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, which belongs to Chakra.

MagicBytes is used for quick positioning of staking transactions, while Version is a field reserved for future updates for distinction.

Based on previous transaction snapshots, the effective data carried by the OP_RETURN output totals 4+1+32+32+2=71 Bytes. In the figure, the FinalityProviderPublicKey of the staking transaction is f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, belonging to Chakra.

MagicBytes is used for quick positioning of staking transactions, while Version is a field reserved for future updates for distinction.

Unbonding Transaction

When a staker wants to unlock their staked BTC early, they can submit an unbonding transaction by spending the unbonding path in the staking output. The unbonding transaction requires it to accept only a single staking transaction as input and output a single commitment to the unbonding script's Taproot output.

The screenshot below shows the unbonding transaction corresponding to the previous staking output.

In the screenshot, the second-to-last field starting with '20' is the tapscript of the unbonding path, and the one starting with 'c1' is the Merkle Proof of the internal key and the unbonding path in the Taproot, where the NUMS point 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0 is clearly observed. In the Witness field of the unbonding transaction, we can observe the staker's signature and the covenant committee's signature.

The unbonding output can be spent under two conditions: the timelock path and the slashing path, both of which are the same as the paths in the staking output. At a higher level, the unbonding output is an intermediate state designed to prevent stakers from immediately withdrawing their shares and evading penalties, ultimately leading to the stable state of the withdrawal transaction.

Slashing Transaction

The slashing transaction takes a staking transaction or an unbonding transaction as input, spends through the slashing path in the Taproot script, and produces two outputs. One output sends a portion of the staked BTC to a burn address, while the other returns the remaining BTC to the staker.

Strictly speaking, Babylon implements partial confiscation of misconduct rather than burning all the BTC staked by the staker at once. This approach provides higher fault tolerance and protects the interests of the staker.

The slashing transaction can only occur with joint signatures from the staker, the covenant committee, and the finality provider. Therefore, even if individual parties are compromised, it will not lead to the collapse of the entire staking system. The slashing transaction serves as a deterrent, economically preventing participants from engaging in malicious behavior. As long as the punishment for misconduct exceeds any potential gains, participants are likely to comply with the rules.

Security Analysis

There are two types of security related to Babylon:

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

The second type of security involves the PoS system itself, ensuring that the protocol can identify and punish participants if they behave maliciously.

Staker's Perspective

From the staker's perspective, once BTC is staked through Babylon's staking transaction, the funds have only three ways of transfer.

The first is the timelock path, which only requires the staker's signature for spending. This ensures that even if the finality provider and Babylon cease operations, the staker can still retrieve the original BTC after the staking period ends.

The second is the unbonding path, which serves as an intermediate state, creating an unbonding output and allowing for a shorter unlocking time. This provides the staker with the ability to withdraw their staked funds early.

The third is the slashing path, which is the only path that could potentially harm the staker's interests. If external parties attempt to attack the slashing path, they must provide the staker's signature, the finality provider's signature, and the covenant committee's signature exceeding the threshold, which is extremely difficult. Even if the covenant 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 the PoS system, its security comes from the ability to punish finality providers if they behave maliciously.

Babylon adopts the EOTS mechanism, where if a finality provider double-signs a block, any user can extract the private key of the finality provider from these two different signatures. This allows them to sign and submit a slashing transaction, with the partial penalty corresponding to the BTC holding all the voting rights of the finality provider.

This penalty measure prevents malicious behavior by the finality provider, ensuring that their incentives to provide finality for the PoS consensus service connected to Babylon remain consistent, securing PoS systems with a large staked TVL.

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。