比特币质押注册

本文详细介绍了在 Babylon 链上进行比特币质押注册的技术协议。内容涵盖了预质押和后质押两种注册流程，深入解析了交易构造、MsgCreateBTCDelegation 消息结构、质押管理（如解绑与提现）以及包含联合质押在内的奖励分配与提取机制。

比特币质押注册

目录

  1. 简介
  2. 比特币质押注册方法
    1. Post-Staking 注册
    2. Pre-Staking 注册
  3. 比特币质押注册
    1. 需要提交的数据概览
    2. Babylon 链 BTC 质押参数
    3. 创建比特币交易
    4. MsgCreateBTCDelegation Babylon 消息
    5. 构造 MsgCreateBTCDelegation
  4. 管理你的比特币质押
    1. 按需 Unbonding
    2. 提取已过期/已 Unbonded 的 BTC 质押
    3. Slashing 后提取剩余资金
  5. 比特币质押奖励
    1. 奖励分配
    2. Costaking 奖励
    3. 奖励提取

1. 简介

本文档详细介绍了与 Babylon 链进行通信以注册比特币质押的协议。 文档结构如下：

  • 第 2 节 概述了在 Babylon 链上注册质押的两种流程。
  • 第 3 节 描述了质押注册所需的数据、注册过程本身，以及用于向 Babylon 链传达质押交易的 MsgCreateBTCDelegation 消息。
  • 第 4 节 详述了质押管理，包括按需 Unbonding 和提取。
  • 第 5 节 侧重于比特币质押奖励以及如何获取这些奖励。

目标读者：本文档旨在作为技术读者的参考，这些读者打算实现自己的比特币质押注册方法（无论是已经在比特币上的质押还是新的质押）。其他质押方法（或托管质押平台）包括使用前端 CLI（运行 simple staking 参考实现）或使用 Staker CLI 程序。

2. 比特币质押注册方法

比特币质押必须在 Babylon 区块链上注册，以获得投票权并赚取奖励。 此注册过程涉及提交一个注册交易，随后由关键的网络组件（包括 Babylon 链 CometBFT 验证者和 Covenant 委员会）对质押操作进行验证。

在 Babylon 区块链上注册比特币质押主要有两种方法：

  • Post-staking 注册：这适用于已经在比特币网络上提交了 BTC 质押交易，然后将其在 Babylon 上注册的 Staker（例如，第一阶段的 Staker）。
  • Pre-staking 注册：这适用于在向比特币提交质押交易并锁定资金之前，寻求 Babylon 链验证的 Staker，以确保获得接受保证（例如，Babylon 链启动后新创建的质押）。

每种方法旨在适应不同的质押偏好和情况。在接下来的章节中，我们将更详细地探讨这些方法。

⚡ 关于 k-depth 的说明：在接下来的章节中， 我们经常提到 k-depth。Babylon 链 仅在质押交易达到 k-depth 时才会激活它们， 其中 k 是在 x/btccheckpoint 模块中定义的 Babylon 链参数（作为 btc_confirmation_depth）， 并由治理控制。

深度衡量交易所在的区块在比特币区块链中的深度。 它的计算方法是比特币尖端高度与包含交易的区块高度之差。

示例：如果比特币尖端高度为 100，则：

  • 第 99 块是 1-deep
  • 第 90 块是 10-deep

2.1. Post-Staking 注册

此流程适用于其 BTC 质押交易已在 k-deep 的比特币区块中确认，并随后在 Babylon 链上注册的 Staker。 例如，这包括来自 Babylon 第一阶段网络的参与者。

下图说明了 Post-staking 注册流程： stake-registration-post-staking-flow

步骤：

  1. 生成质押元数据：从包含该交易的比特币区块中检索质押交易，并生成包含证明 (Proof of Inclusion)。
  2. 填充 MsgCreateBTCDelegation 消息，包含 Unbonding 交易、已签名的 Slashing 交易和 Proof of Possession (POP)，并将其广播到 Babylon 区块链（有关如何操作的详细信息将在 第 3.4 节 中提供）。
  3. 等待 Covenant 验证：质押将保持在 PENDING 状态，直到 Covenant 提供其验证签名。
  4. 激活：一旦达到 Covenant 签名的法定人数 (Quorum)，质押将被指定为 ACTIVE。

⚠️ 关键警告：从第一阶段迁移质押时，必须包含包含证明 (Proof of Inclusion)，以指明你的质押已经包含在比特币账本中。 如果不提供此证明，将使 Babylon 节点预期你的质押将包含在较晚的比特币高度，从而导致拒绝任何后续的质押注册。 在这种情况下，质押必须进行 Unbond 并重新质押。

⚠️ 关于 Finality Provider 的重要警告：为你的质押选择 Finality Provider 时要谨慎。如果你委托的 Finality Provider 在你的质押注册之前被 Slashing，你的质押可能会被卡住。这对于正在注册过程中的第一阶段质押尤为重要。

2.2. Pre-Staking 注册

Pre-staking 注册流程适用于在向比特币账本提交其 BTC 质押交易之前，寻求 Babylon 链验证的 Staker。通过这样做，他们在对比特币锁定资金之前，可以确保其质押将被接受。

该过程始于 Staker 向 Babylon 链提交所有相关的质押数据。随后，Covenant 委员会为按需 Unbonding 和 Slashing 提供验证签名，为 Staker 提供了继续广播其 BTC 质押交易所需的保证。在交易在 k-deep 的比特币区块中确认后，Staker（或像 Vigilante Watcher 这样的自动化服务）会提交一个包含证明 (Proof of Inclusion) 以完成注册并导致质押激活。

下图说明了 Pre-staking 注册流程： stake-registration-pre-staking-flow

步骤：

  1. 填充 MsgCreateBTCDelegation 消息 包含必要的元数据并将其广播到 Babylon 区块链。 （有关如何操作的详细信息将在 第 3.4 节 中提供）

    ⚡ 注意：由于质押交易尚未在比特币账本上，因此应省略包含证明 (Proof of Inclusion)。这信号表示遵循 Pre-staking 注册流程，并将稍后提交包含证明。

  2. 等待 Covenant 验证： 在此之前，质押保持为 PENDING。
  3. 验证： 一旦达到签名的法定人数，质押将被标记为 VERIFIED，这意味着用于 Slashing 和按需 Unbonding 的必要 Covenant 签名已经就位。
  4. 提交 BTC 质押：验证后，Staker 签署并向比特币网络广播 BTC 质押交易。
  5. 监控比特币包含情况： Vigilante Watcher（或 Staker）监控比特币的交易确认和 k-deep 包含。
  6. 确认 k-deep 包含： Vigilante Watcher 将识别出该交易在比特币链中处于 k-deep。
  7. 提交包含证明 (Proof of Inclusion)： 一旦交易达到 k-deep，Vigilante Watcher（或 Staker）提交 MsgAddBTCDelegationInclusionProof。

    ⚡ 注意：如果你不想依赖 Vigilante Watcher，你可以手动跟踪比特币深度并自行提交此消息。有关消息构造的详细信息，请参阅 x/btcstaking 模块文档。为了简化起见，本文档的其余部分将假设依赖 Vigilante Watcher 服务。

  8. 激活： 收到包含证明后，质押将被标记为活跃。

⚠️ 重要：Pre-staking 注册的 Gas 要求

由于 Pre-staking 注册不需要事先在比特币上进行资金承诺，它可能会被利用来进行链上垃圾邮件攻击，特别是由于它触发的多次 Covenant 签名提交。

为了缓解这种情况，通过 Pre-staking 注册流程提交 MsgCreateBTCDelegation 需要增加最低 Gas 费用，该费用涵盖了质押、Covenant 签名和包含证明提交的 Gas。 此最低 Gas 由 Babylon 链的 delegation_creation_base_gas_fee 质押参数定义 （该参数将在 第 3.2 节 中详述）。

3. 比特币质押注册

3.1. 注册数据概览

在 Babylon 链上注册比特币质押需要提交质押交易以及基本的元数据。 本节提供了所需数据的概览，而后面的章节将详细介绍如何创建这些数据并将其打包到 Babylon 注册交易中。

关键注册数据：

  • BTC 质押交易：将比特币质押锁定在自托管比特币质押脚本中的比特币交易。它可以以已签名或未签名的形式提交，具体取决于质押流程和 UTXO 输入。
  • Unbonding 交易：一个未签名的 Unbonding 交易，允许 Staker 按需 Unbond 他们的质押。它被提交到 Babylon 链，并在验证后由 Covenant 共同签署。
  • Slashing 交易：两个 Staker 预签名的 Slashing 交易（一个用于质押，一个用于 Unbonding），确保在质押委托给的 Finality Provider 双重签名时执行 Slashing。它们被提交到 Babylon 链，并在验证后由 Covenant 共同签署。
  • Proof of Possession：确认用于质押注册的 Babylon 账户对比特币密钥的所有权。
  • Merkle 包含证明 (Proof of Inclusion)：验证交易包含在 k-deep 的比特币区块中。在 Post-staking 注册流程的初始注册期间提交，或在 Pre-staking 注册流程的稍后阶段提交。

⚡ 注意：有关比特币质押、Unbonding 和 Slashing 交易的更多详细信息，请参见 比特币质押脚本规范。

一旦组装完成，这些数据将被打包到 Babylon 链交易中并广播到网络。该过程根据 Staker 遵循的是 Pre-staking 还是 Post-staking 注册流程而有所不同。

接下来的章节：

  • BTC 质押交易所需的参数。
  • 构造用于质押的比特币交易。
  • 使用所需的质押数据构建 Babylon 链交易。
  • 向 Babylon 链提交注册交易。

3.2. Babylon 链 BTC 质押参数

BTC 质押交易必须遵守 Babylon 链定义的参数，这些参数根据比特币区块高度而变化。每个参数版本由 btc_activation_height 定义，确定该参数版本生效的比特币高度。 要确定在比特币区块高度 lookup_btc_height 生效的适用参数版本：

  1. 按 btc_activation_height 升序排列所有参数版本。
  2. 第一个满足 lookup_btc_height >= btc_activation_height 的参数版本适用于该质押。

下面是 x/btcstaking 模块管理的不同版本中包含的关键质押参数概览：

  • covenant_pks： Covenant 委员会的 BIP-340 公钥（64 位十六进制字符串）。公钥仅为 secp256k1 曲线点的 x 坐标表示，因为 y 坐标是隐含的。
  • covenant_quorum： 实现 Covenant 法定人数所需的最小签名数量。
  • min_staking_value_sat / max_staking_value_sat： 以 Satoshis（比特币的最小单位）计的最小/最大比特币质押额。
  • min_staking_time_blocks / max_staking_time_blocks： 最小/最大比特币质押持续时间（以比特币区块计）。
  • slashing_pk_script： Slashing 交易第一个输出中预期的 pk_script。它存储为字节序列，表示花费该输出的条件。
  • min_slashing_tx_fee_sat： 预签名的 Slashing 交易所需的最低交易费用（以 Satoshis 计）。
  • slashing_rate：一个标量，指定如果 Finality Provider 双重签名，则罚没质押的百分比。
  • unbonding_time_blocks： 以比特币区块计的按需 Unbonding 时间。
  • unbonding_fee_sat： Unbonding 交易所需的比特币费用（以 Satoshis 计）。
  • min_commission_rate：一个标量，定义 Finality Provider 的最低佣金率。
  • delegation_creation_base_gas_fee：定义通过 Pre-staking 注册流程注册质押时要支付的最低 Gas 费用。
  • allow_list_expiration_height：初始质押交易白名单过期的 Babylon 区块高度。 有关白名单的更多详细信息可以在这里找到。
  • btc_activation_height：此参数版本生效的比特币区块高度。

⚡ 检索质押参数

这些参数是 x/btcstaking 模块参数的一部分，可以通过 Babylon 节点使用 RPC/LCD 端点或 CLI 进行查询。

⚠️ 警告：请确保你是从受信任的节点检索 BTC 质押参数，并使用其他来源验证其真实性。未能使用正确的 BTC 质押参数可能会使你的质押无法验证或在比特币上暂时冻结（在无效的 Covenant 模拟委员会的情况下）。

⚡ 选择正确的质押参数

Staker 必须确保其比特币交易根据所遵循的注册流程遵守正确的参数：

  • Post-staking 注册流程：使用与质押交易包含在内的比特币区块高度相对应的参数（类似于第一阶段）。
  • Pre-staking 注册流程：使用与 Pre-staking 注册时 Babylon 链上比特币轻客户端 相匹配的参数。这确保了交易承诺根据当前的质押参数版本进行验证（由 Babylon 链观察到的）。 这确保了 Pre-staking 注册的交易即使随后被包含在不同参数生效的比特币区块中，也将保持有效。链上比特币轻客户端的尖端高度可以通过查询 x/btclightclient 模块使用 RPC/LCD 端点或 CLI 来检索。

3.3. 创建比特币交易

前一节中的比特币质押参数用于创建必要的比特币交易，以便在 Babylon 和比特币账本上注册比特币质押。 这些交易包括：

  • BTC 质押交易：将质押锁定在自托管比特币质押脚本中的比特币交易。
  • Slashing 交易：一个预签名交易，同意在双重签名的情况下进行 Slashing。
  • Unbonding 交易：用于在最初承诺的时间锁到期之前解锁质押的按需 Unbonding 交易。
  • Unbonding Slashing 交易：一个预签名交易，同意在 Unbonding 过程中双重签名的情况下进行 Slashing。

你可以使用以下工具创建这些交易：

⚡ 注意：创建比特币交易时，请确保使用有效的 Babylon 参数。

3.4. MsgCreateBTCDelegation Babylon 消息

Cosmos SDK 交易用于在 Babylon 链上注册 BTC 委托。 MsgCreateBTCDelegation 消息捆绑了必要的质押数据，并在 Babylon 区块链上注册比特币质押。

MsgCreateBTCDelegation 中的关键字段
// MsgCreateBTCDelegation 是用于创建 BTC 委托的消息
message MsgCreateBTCDelegation {
  option (cosmos.msg.v1.signer) = "staker_addr";
  // staker_addr 是接收来自 BTC 委托奖励的地址。
  string staker_addr = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
  // pop 是 staker_addr 对 btc_pk 的 Proof of Possession。
  ProofOfPossessionBTC pop = 2;
  // btc_pk 是 BTC 委托者的比特币 secp256k1 公钥
  bytes btc_pk = 3 [ (gogoproto.customtype) = "github.com/babylonlabs-io/babylon/v4/types.BIP340PubKey" ];
  // fp_btc_pk_list 是 Finality Provider 的比特币 secp256k1 公钥列表，如果有多个
  // finality provider pk，意味着委托被重新质押 (re-staked)
  repeated bytes fp_btc_pk_list = 4 [ (gogoproto.customtype) = "github.com/babylonlabs-io/babylon/v4/types.BIP340PubKey" ];
  // staking_time 是质押交易中使用的锁定时间
  uint32 staking_time = 5;
  // staking_value 是锁定在质押输出中的 satoshis 数量
  int64 staking_value = 6;
  // staking_tx 是比特币质押交易，即锁定资金的交易
  bytes staking_tx = 7 ;
  // staking_tx_inclusion_proof 是质押交易在 BTC 链中的包含证明
  InclusionProof staking_tx_inclusion_proof = 8;
  // slashing_tx 是罚没交易
  // 请注意，交易本身不包含签名，签名在链下。
  bytes slashing_tx = 9 [ (gogoproto.customtype) = "BTCSlashingTx" ];
  // delegator_slashing_sig 是委托者在罚没交易上的签名（即与 btc_pk 对应的私钥）。
  // 它将成为质押交易输出见证的一部分。
  // 质押交易输出还需要来自 Covenant 和 Finality Provider 的签名才能被花费。
  bytes delegator_slashing_sig = 10 [ (gogoproto.customtype) = "github.com/babylonlabs-io/babylon/v4/types.BIP340Signature" ];
  // unbonding_time 是资金在 unbonding 时使用的锁定时间。它用于：
  // - unbonding 交易，时间锁花费路径
  // - 质押罚没交易，找零输出
  // - unbonding 罚没交易，找零输出
  // 它必须小于 math.MaxUInt16 且大于 max(MinUnbondingTime, CheckpointFinalizationTimeout)
  uint32 unbonding_time = 11;
  // 与 unbonding 交易相关的字段
  // unbonding_tx 是一个比特币 unbonding 交易，即花费质押输出并将其发送到 unbonding 输出的交易
  bytes unbonding_tx = 12;
  // unbonding_value 是锁定在 unbonding 输出中的 satoshis 数量。
  // 注意：staking_value 和 unbonding_value 可能会有所不同，因为质押交易和 unbonding 交易的手续费存在差异
  int64 unbonding_value = 13;
  // unbonding_slashing_tx 是罚没 unbonding 合约的罚没交易
  // 请注意，交易本身不包含签名，签名在链下。
  bytes unbonding_slashing_tx = 14 [ (gogoproto.customtype) = "BTCSlashingTx" ];
  // delegator_unbonding_slashing_sig 是委托者在罚没交易上的签名（即与 btc_pk 对应的私钥）。
  bytes delegator_unbonding_slashing_sig = 15 [ (gogoproto.customtype) = "github.com/babylonlabs-io/babylon/v4/types.BIP340Signature" ];
}
字段说明
  • staker_addr： 一个 Bech32 编码的 Babylon 地址 (bbn...)，表示 Staker 的 Babylon 账户，质押奖励将累积在该账户中。 这应该是签署注册交易的同一个地址。

  • pop (Proof of Possession)： 一个加密签名，证明注册交易的提交者是用于质押的比特币私钥的所有者。

    • btc_sig_type：指定所使用的签名算法。选项包括：
    • 0 代表 BIP-340 (Schnorr 签名)
    • 1 代表 BIP-322 (通用签名格式)
      • 请注意，使用的是 simple 签名格式。
    • 2 代表 ECDSA (椭圆曲线数字签名算法)
    • btc_sig：通过使用所选算法签署 Staker 地址生成的签名。验证过程因算法而异：
    • BIP-340：应签署 Staker 地址字节的哈希。
    • BIP-322：应签署 Bech32 编码地址的字节。
    • ECDSA：应签署 Bech32 编码地址的字节。
    message ProofOfPossessionBTC {
  // btc_sig_type 表示 pop 中 btc_sig 的类型
  BTCSigType btc_sig_type = 1;
  // btc_sig 是通过 sign(sk_btc, babylon_staker_address) 生成的签名
  // 该签名遵循 BIP-340 规范或 BIP-322 规范中的编码
  bytes btc_sig = 2;
}
  • btc_pk： 这是 BTC Staker 的比特币 secp256k1 公钥，采用 BIP-340 格式（Schnorr 签名）。它是一个从 Staker 私钥派生的紧凑型 32 字节值。此公钥对应于构造 BTC 质押交易中使用的 质押脚本 所用的 Staker 公钥。
  • fp_btc_pk_list： 该质押委托给的 Finality Provider (FP) 的 secp256k1 公钥列表，采用 BIP-340 格式（Schnorr 签名）和紧凑型 32 字节表示。 对于第二阶段，此列表包含单个密钥，因为 Babylon 是唯一受比特币质押保护的系统。 该公钥应与构造 质押脚本 时使用的公钥完全相同。
  • staking_time： 以比特币区块计的质押持续时间。这与构造 质押脚本 时使用的时间锁相同，并且必须符合 Babylon 质押参数。
  • staking_value： 锁定在 BTC 质押交易 (staking_tx) 质押输出中的 Satoshis 数量。此值必须与质押交易中的比特币金额精确匹配。
  • staking_tx： 十六进制格式的比特币质押交易。此交易将比特币资金锁定在质押输出中，至关重要的一点是，它必须精确遵循使用正确的比特币质押参数的 质押脚本 格式。MsgCreateBTCDelegation 中包含的某些值应与质押交易中的值匹配。

    ⚠️ 重要：质押交易的输入是否应该被签名？

    质押交易是否应包含已签名或未签名的 UTXO 输入取决于所使用的输入类型。 由于 Babylon 链根据交易哈希跟踪质押交易，因此 Staker 提交的质押交易格式必须包含生成与完全签署交易相对应的完整哈希所需的所有数据。

    对于需要填充 script_sig 字段的 Legacy 输入，向 Babylon 提交交易时必须包含签名，因为此字段直接影响交易哈希。

    另一方面，对于需要 witness 字段的输入（例如 SegWit 输入），签名不需要作为交易的一部分包含。

    虽然这种区别不会影响遵循 Post-staking 注册流程的质押交易的保证（因为质押首先承诺到比特币），但选择 Pre-staking 注册流程的 Staker 必须确保任何 Legacy 输入（需要 script_sig 字段）必须以完全签名的形式提交质押交易。

    例如，如果 Staker 创建了一个具有多个输入的质押交易，且其中至少一个是 Legacy 输入，则提交交易时应满足：

    • Legacy 输入的 script_sig 字段已填充签名。
    • 其他输入（如 SegWit 输入）可以在没有见证 (witness) 的情况下提供，以尽量减少成本。

    这样做的一个缺点是，通过提交一个完全签署的质押交易，存在它在收到 Covenant 签名之前过早传播到比特币的风险（即与 Post-staking 注册相同，在收到 Covenant 验证之前先在比特币上进行）。 然而，一些 Staker 可能仍会选择 Pre-staking 注册流程，因为与 Post-staking 注册流程相比，它需要的等待时间更短（如果 Staker 选择依赖 Vigilante Watcher）。

  • staking_tx_inclusion_proof（可选）： 一个 Merkle 证明，显示质押交易包含在 k-deep 的比特币区块中。在使用 Post-staking 注册流程时应填充此字段，而在使用 Pre-staking 注册流程时留空。 该字段定义为 InclusionProof protobuf 数据类型（规范如下），包含以下字段：

    // 在 x/btccheckpoint 模块类型中
message TransactionKey {
uint32 index = 1;
bytes hash = 2
  [ (gogoproto.customtype) =
  "github.com/babylonlabs-io/babylon/v4/types.BTCHeaderHashBytes" ];
}

// 在 x/btcstaking 模块类型中
message InclusionProof {
  // key 是该交易在 BTC 区块链上的位置 (txIdx, blockHash)
  babylon.btccheckpoint.v1.TransactionKey key = 1;
  // proof 是证明该交易包含在 `key` 中位置的 Merkle 证明
  bytes proof = 2;
}
    • key：识别交易在比特币区块链中的位置。密钥应对应于 TransactionKey 类型，其中包含两个字段：
    • txIdx：交易在区块内的索引（例如，第 42 号交易）。
    • blockHash：包含该交易的区块哈希。
    • proof：一个验证交易包含在比特币链中的 Merkle 证明。它是与质押交易哈希配对（递归）的交易哈希列表，以便追踪获得区块的 Merkle 根，深度配对优先。一些关于构造证明的资源：
    • Merkle 证明规范
    • Golang 实现
    • TypeScript 实现
  • slashing_tx / delegator_slashing_sig： 通过罚没路径花费 BTC 质押交易的罚没交易以及 Staker 对其的 BIP-340 (Schnorr) 签名。两者均为十六进制格式。 一旦具有来自 Staker、Covenant 法定人数和 Finality Provider 的签名，该交易即被视为完全签署。 在交易验证后，将添加 Covenant 签名，这意味着仅缺少 Finality Provider 的签名。 根据 BTC 质押协议，如果 Finality Provider 双重签名，其私钥将被暴露，从而产生完整的签名集。
  • unbonding_time： 以比特币区块计的按需 Unbonding 期限。这与构造 Unbonding 脚本 时使用的时间锁相同，并且必须符合 Babylon 质押参数。
  • unbonding_tx： 十六进制格式的未签名 Unbonding 交易。提交 Unbonding 交易是为了 (1) 接收 Unbonding 交易的 Covenant 签名法定人数，以及 (2) 用于验证花费 Unbonding 交易的罚没交易。
  • unbonding_value： 承诺到 Unbonding 交易的 Unbonding 输出中的 Satoshis 数量。
  • unbonding_slashing_tx / delegator_unbonding_slashing_sig： 通过罚没路径花费按需 Unbonding 交易的罚没交易以及 Staker 对其的 BIP-340 (Schnorr) 签名。两者均为十六进制格式。 此交易具有与 slashing_tx 相同的属性，不同之处在于它花费按需 Unbonding 交易的罚没路径。

3.5. 构造 MsgCreateBTCDelegation

有多种方法可以构造 MsgCreateBTCDelegation 消息并将其广播到 Babylon 网络：

  • 命令行界面 (CLI)： 使用 babylond tx btcstaking create-btc-delegation 命令。
  • TypeScript 实现： 遵循此 参考实现 使用 TypeScript 生成消息，并广播到 Babylon 网络。
  • Golang 实现： 基于此 类型参考 使用 Golang 构造消息，并广播到 Babylon 网络。
  • 外部参考： 有关广播交易的详细说明，请参阅外部 Cosmos SDK 文档。

⚠️ 重要：

  • 使用 Post-staking 注册流程的第一阶段质押交易只有在满足 这些资格标准 时才会被接受。
  • 无论是通过 Pre-staking 还是 Post-staking 注册流程创建的新第二阶段质押注册，只有在白名单过期后才会被接受。

4. 管理你的比特币质押

4.1. 按需 Unbonding

按需 Unbonding 允许 Staker 在最初在原始质押交易中承诺的时间锁到期之前，启动其质押 BTC 的 Unbonding。在 Babylon 参数中指定的 Unbonding 期限（参见 第 3.2 节）之后，资金即可提取。

要进行按需 Unbond，Staker 必须提交他们之前作为质押一部分注册的同一个按需 Unbonding 交易，但必须在添加了所需的签名之后：

  • Staker 的签名，以及
  • Covenant 签名的法定人数

Covenant 签名作为质押激活过程的一部分在链上记录并承诺。除非已收到 Unbonding 的 Covenant 签名法定人数，否则质押将不会被激活（或在 Pre-staking 注册的情况下通过验证）。

要检索 Unbonding 交易并添加必要的签名，请按照以下步骤操作：

  1. 检索 Unbonding 交易和 Covenant 签名：通过查询 Babylon 账本（例如，通过 RPC/LCD 或 CLI）。
  2. 添加你自己的签名 到 Unbonding 交易的见证 (witness) 中。
  3. 添加 Covenant 签名 到 Unbonding 交易的见证 (witness) 中。
  4. 向比特币网络广播完全签署的交易。

有关如何构造并添加签名以构造完全签署的 Unbonding 交易的实际示例，请参阅：

⚡ 注意：Babylon 链上的 Unbonding 通知

Babylon 系统采用了 Vigilante Unbonding Watcher，这是一项监控比特币账本中 按需 Unbonding 交易 并将其报告回 Babylon 链的服务。一旦 Unbonding 交易包含在比特币中，Vigilante 就会检测到它并通知 Babylon，从而导致该质押失去投票权。

4.2. 提取已过期/已 Unbonded 的比特币质押

提取过程涉及提交一个比特币交易，一旦时间锁到期，该交易将质押的 BTC 从 Babylon 协议输出（质押或 Unbonding 或罚没找零）转移到 Staker 钱包控制下的地址。

该过程包括以下步骤：

  1. 检索具有已过期时间锁的质押/Unbonding 交易。
  2. 构造一个由 Staker 签署的提取交易。
  3. 向比特币区块链提交该交易。

有关如何构造提取交易的实际示例，请参阅：

4.3. Slashing 后提取剩余资金

如果比特币质押委托给的 Finality Provider 双重签名，则该质押将被罚没。Slashing 涉及广播一个 罚没交易，该交易将一部分被罚没的资金发送到销毁地址（如 第 3.2 节 质押参数中所定义），而剩余资金则转移到时间锁脚本中，随后可以使用上一节定义的相同提取过程提取。

要确定 Slashing 时间锁，请参阅 Babylon 链 BTC 质押参数 中的 unbonding_time_blocks 参数。Babylon 确保罚没交易找零输出上的时间锁与 Unbonding 时间相匹配。因此，Unbonding 时间参数实际上代表了你的 Slashing 时间锁。时间锁背后的原因是，我们希望避免某些 Finality Provider 利用 Slashing 作为立即 Unbond 手段的情况。

5. 比特币质押奖励

比特币 Staker 会获得他们协助保护的链的 Native Token 奖励，以换取他们提供的经济安全性。

5.1. 奖励分配

奖励分配如下：

  • 每次创建新区块时都会铸造固定数量的 Native Token。

  • 铸造的奖励分配给四个群体：

    • Native 质押者
    • 比特币质押者
    • Costaker（BTC + BABY 质押者，见 第 5.2 节）
    • 社区池 (Community pool)

    分配由特定参数控制：

    • 比特币质押者部分：由 btc_staking_portion 参数定义，该参数指定分配给比特币质押者的奖励比例。这是根据质押委托给的 Finality Provider 的投票权和佣金率计算的。
    • 社区池部分：通常在 Cosmos SDK 的 x/distribution 模块中定义，通常被称为社区税 (community tax)。
    • Native 质押者部分：分配给比特币质押者和社区池后的剩余奖励将分配给 Native 质押者。

  • 比特币质押者的奖励进一步根据质押委托给的 Finality Provider 的投票权和佣金率进行分配。奖励进入一个仪表盘 (gauge)，Staker 可以通过提交交易来查询和提取。

  • 奖励在区块 Finalize 时分配。系统处理 Finalize 的区块，以确保所有符合条件的 Staker 根据 Finalize 时的投票权和佣金率收到其奖励。

5.2. Costaking 奖励

Costaking 允许通过同时质押比特币和 BABY Token 来赚取额外奖励。接收 BTC 质押奖励的 Babylon 地址和用于 BABY 委托的地址必须相同，才能赚取 Costaking 奖励。

对于 Costaking，必须同时拥有活跃的 BTC 委托（通过 Finality Provider）和 BABY 委托（通过验证者）。一个人可以拥有的 BTC 和 BABY 委托数量没有限制，所有活跃委托都对 Costaking 奖励有贡献。

Costaking 奖励是使用基于你的组合质押金额的用户分数计算的。分数基于 min(active_btc_satoshis, active_baby_tokens / score_ratio)。score_ratio 是 x/incentive 模块中定义的一个参数，用于确定在计分中 BABY Token 对比特币的相对权重。

算法

每个用户的 Costaking 奖励与其相对于所有 Costaker 的分数成正比：

  • user_score = min(active_btc_satoshis, active_baby_tokens / score_ratio)
  • user_reward = total_costaking_rewards × (user_score / sum_of_all_scores)

score_ratio 参数决定了 Costaking 奖励资格中 BABY 和 BTC 之间的转换率。此治理可调参数定义了在计分计算中多少个 BABY Token 等于 1 BTC。只有向活跃 Finality Provider 质押的 BTC 才计入 Costaking。所有 BABY 委托无论验证者状态如何都计入其中。

例如，如果 score_ratio 参数设置为 20,000，Alice 质押了 6 BTC 和 50,000 BABY，她的分数为 min(6, 50,000/20,000) = 2.5。Bob 质押了 6 BTC 和 150,000 BABY，他的分数为 min(6, 150,000/20,000) = 6。如果总 Costaking 奖励为 10,000 BABY 且他们是唯一的 Costaker，Alice 将收到 2,941 BABY，Bob 将收到 7,059 BABY。

Finality Provider 和验证者

活跃的 Finality Provider 获得总通胀的 0.075%，按其 BTC 委托规模比例分配。活跃的 CometBFT 验证者获得总通胀的 0.075%，按其 BABY 委托规模比例分配。由于 Cosmos SDK 的限制，这些分配补偿了无法对 Co-staking 奖励收取佣金的情况。可以使用 MsgWithdrawReward 中适当的消息类型分别提取这些不同类型的奖励。

注意：实际的 score_ratio 是可以通过治理配置的参数值。

奖励流程：

  • 奖励收集并累积在 Costaking 奖励池中
  • 根据用户分数分配奖励
  • 奖励与常规 BTC 质押奖励一起自动发送到你的激励仪表盘 (incentive gauge)
  • 使用 type: "btc_staker" 的 MsgWithdrawReward 提取所有比特币和 Costaker 奖励

5.3. 奖励提取

可以通过提交 MsgWithdrawReward 消息来提取奖励：

// MsgWithdrawReward 定义了用于提取利益相关者奖励的消息。
message MsgWithdrawReward {
    option (cosmos.msg.v1.signer) = "address";
    // type 是利益相关者类型 {finality_provider, btc_staker}
    string type = 1;
    // address 是利益相关者的 bech32 字符串地址
    // 此消息的签名者必须是此地址
    string address = 2;
}

该消息定义了以下字段：

  • type：指定奖励提取的利益相关者类型。允许的值：
    • finality_provider - Finality Provider 的佣金和奖励
    • btc_staker - 所有与 BTC 相关的奖励（BTC 质押和 Costaking 奖励）
    • costaker - 仅限 Costaking 奖励
  • address：利益相关者的 bech32 地址（必须与消息签名者匹配）。

提交提取交易： 可以通过以下方式提取奖励：

  • 通过任何 RPC/LCD 节点提交 MsgWithdrawReward
  • 使用 CLI babylond tx incentive withdraw-reward <type>
  • 你可以使用 TypeScript 实现以编程方式领取奖励。请参考 TypeScript 领取奖励实现。

查询可用奖励： 可以使用 x/incentive 模块检查奖励：

  • 通过 RPC/LCD 查询：URL 为 /babylon/incentive/address/{address}/reward_gauge，其中 address 是 Staker 的 bech32 地址。
  • 通过 CLI 命令：babylond query incentive reward-gauges <bech32-address>
  • 通过 TypeScript：你可以使用 TypeScript 实现来查询奖励。请参考 TypeScript 库文档。
  • 原文链接： github.com/babylonlabs-i...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
babylonlabs-io
babylonlabs-io
江湖只有他的大名，没有他的介绍。

babylonlabs-io

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！