> For the complete documentation index, see [llms.txt](https://docs.stacks.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stacks.co/learn/zh/bitcoin-staking/glossary.md). # 比特币质押术语表 比特币质押文档中使用的术语：债券、债券时间线、分批、覆盖率、提前退出，以及 PoX-5 词汇。 Bitcoin Staking（PoX-5）文档集中的术语。 ## 协议债券 一个 12 个周期的双资产承诺，约六个月：在 Bitcoin L1 上的 BTC 时间锁，配合 Stacks L2 上的 STX 锁定，并以密码学方式关联，目标是获得 BTC 侧的第 1 批次收益。该术语是合约常量 `BOND_LENGTH_CYCLES u12`. ## 第 0 天 / 第 175 天 / 第 182 天（债券时间线） 第 0 天是截止点，届时两条腿都必须已锁定才具备资格；登记必须在债券开始高度之前完成。第 175 天是 L1 时间锁的最小解锁高度。它正好位于债券 L2 结束前半个奖励周期，即主网 1,050 个 Bitcoin 区块，约七天。第 182 天结束 L2 上的绑定期；STX 会在下一个周期边界解锁。 如果 L1 锁定的解锁高度低于第 175 天，则在登记时会被拒绝。 ## 绑定期 单个债券的完整 12 个周期期限，从第 0 天到第 182 天。六个绑定期并发且错峰运行，每两个周期开启一次。债券索引 *n* 在债券索引 *n+6* 开始时结束，这就形成了六层重叠。 ## 签名者周期（奖励周期） 奖励周期的另一个名称：2,100 个 Bitcoin 区块，在主网上约 14 天。它由一个奖励阶段加上其后 100 个区块的准备阶段组成。本页中的其他周期数字都由此推导。 ## 分配周期 半个奖励周期，即主网上 1,050 个 Bitcoin 区块，也是计算钟表奖励的时间单位。每个奖励周期有两次分配，一年大约 50 次，这也是每个债券按分配计算目标收益时的除数。 ## 锁定脚本 L1 侧的部分是一个具有两个花费分支的 P2WSH 输出。时间锁分支要求在 CLTV 高度之后由质押者签名。提前退出分支要求披露一个 32 字节的前像，以满足债券的提前解锁子脚本，并且还要有质押者签名。质押者通过一个哈希承诺与脚本绑定， `sha256(sha256(to-consensus-buff? staker))`而不是以明文推送。这就是为什么 L1 债券本质上只能单一质押者，不能进行池化。 两条分支都需要质押者自己的签名，而不仅仅是时间锁那一条： `staker-unlock-bytes` 会无条件地在 `OP_ENDIF`之后执行，不在分支选择之内。因此，提前退出花费除了早解锁子脚本要求的内容外，还需要质押者签名以及 32 字节的承诺前像。 ## BTC SPV 证明 在登记时提供的比特币侧证明，用于表明 L1 时间锁输出存在且已确认。在构建登记前，有两个硬上限很重要： * **每次登记最多 10 个锁定输出点。** `register-for-bond`的 `btc-lockup` ok 分支的类型是 `outputs: (list 10 {…})`，验证 fold 将其 `seen-outpoints` 累加器上限设为 `u10`。重复的 `(txid, output-index)` 会失败并返回 `ERR_DUPLICATE_LOCKUP_OUTPOINT u46`。你可以把 BTC 分散到多个时间锁 UTXO 中，但不能超过十个。 * **Merkle 证明的深度不能超过 14。** 证明的 `leaf-hashes` 字段的类型是 `(list 14 (buff 32))`. ## 第 1 批次：活跃协议债券 瀑布机制的第一站。每个活跃债券都会先领取其目标收益，然后才分配其他任何资金。根据白皮书第 4.2 节，大约 10% 的第 1 批次容量预留给通过池子的社区参与。完整说明见 [奖励与批次](/learn/zh/bitcoin-staking/rewards-and-tranches.md). ## 第 2 批次：仅 STX 质押者 第二站。仅 STX 质押者按其质押份额比例获得该周期超额部分的 85%。 ## 第 3 批次：储备基金 第三站。获取该周期超额部分剩余的 15%。 > **内部惯例。** 这个词汇表是整套文档中唯一写有批次数字的页面：第 1 批次是协议债券，第 2 批次是仅 STX 质押者，第 3 批次是储备基金。在文档的其他地方，这些批次都只按名称出现，从不编号：协议债券批次、仅 STX 质押批次、储备基金批次。当两个或多个一起提及时，顺序始终是协议债券，其次仅 STX，最后储备基金。 ## 周期超额 某个周期中超出第 1 批次义务的矿工收入。第 2 批次和第 3 批次分割的就是这部分：85% 给仅 STX 质押者，15% 给储备基金。 ## 瀑布分配 在三个批次之间分配奖励的优先顺序：先债券，再把超额部分在仅 STX 质押者和储备基金之间拆分。债券按递减 `stx-value-ratio` 顺序支付，若出现缺口，则完全由该顺序中的最后几笔债券承担，而不是按比例摊分。其效果是 BTC 侧收益更稳定，而仅 STX 侧回报更具波动性。 在本词汇表之外，这三个站点按名称提及，顺序为协议债券、仅 STX、储备基金。完整说明见 [奖励与批次](/learn/zh/bitcoin-staking/rewards-and-tranches.md). ## 覆盖率 每个周期的奖励池除以每个周期的配对 BTC 义务。目标为 2.0x，响应区间为 0.8x 到 2.0x 及以上，在 PoX-5 引导期由 Stacks Endowment 人工管理。合约本身既不计算也不响应它；这是一个设计层面的概念。 ## 储备基金 瀑布分配中的第三站。它累计该周期超额部分的 15%，以及在某个周期中没有仅 STX 质押者时的 STX 质押者分成。 白皮书将其描述为以两个部分持有：BTC हिस्सेदारी和由稳定币或短期国债组成的 USD 部分，在存入时拆分，BTC 部分优先动用，USD 部分作为最后防线。该结构并不在 pox-5 中，后者只跟踪一个 `reserve-balance` 以 sBTC 计价。该双部分结构是链下的财政安排。 合约内部没有任何东西可以动用它。 `reserve-balance` 在 `calculate-rewards` 中增加，并且只在一个地方减少， `transfer-from-reserve`，它是 `define-private`，带有 `#[allow(unused_private_fn)]`，且在合约中没有任何调用点。它只能由节点作为共识的一部分调用，因此要触及储备基金就需要硬分叉。债券管理员和暂停管理员都无法触及它。 ## PoX-5 实现 Bitcoin Staking 的 Clarity 启动合约。它在 Epoch 4.0 取代了 PoX-4。PoX-5 运行一种由 Endowment 介导的引导机制，其中容量、比例和目标 APY 由管理层设定；PoX-6 是计划中的算法化后继版本。 ## Epoch 4.0 激活 PoX-5 的 Stacks 共识纪元，同时也包含 SIP-044 的 Clarity 和共识变更：新的区块头版本方案、移除成本投票、恢复每个区块 1,000 STX 的发行，以及移除烧毁地址。它在 Bitcoin 区块 960,230 处激活，并需要 4.0.1 版本。 ## 准备阶段 每个奖励周期最后 100 个 Bitcoin 区块，每个周期都会重复，在此期间，下一个周期的签名者和质押者集合被冻结。期间有六个入口会被拒绝，并返回 `ERR_STAKE_IN_PREPARE_PHASE (u47)`: `register-for-bond`, `update-bond-registration`, `stake`, `stake-update`, `announce-l1-early-exit`，以及 `unstake-sbtc`. `unstake` 会通过单独检查被拒绝，错误为 `ERR_UNSTAKE_IN_PREPARE_PHASE (u28)`. ## 签名者管理器 每个质押者都会委托到的一个合约，无论是债券质押还是仅 STX 质押。它通过由 `validate-stake!` 定义的回调来拥有审批逻辑， `signer-manager-trait`，并且奖励先到达这里再向外分发。大多数集成者会直接使用现成的 signer-manager，而不是自己编写。参见 [将质押加入现有签名者管理器](https://docs.stacks.co/operate/staking-stx/stack-with-a-pool). ## 签名者集合最小值 `SIGNER_SET_MIN_USTX u50000000000` 是 50,000 STX。它是委托给某个签名者的总 uSTX 的聚合阈值，既计算债券 STX，也计算仅 STX 的 STX，不设单个质押者最低值。签名者一旦超过该阈值，就会被加入该周期的签名者集合；跌破则移出。 ## 提前退出 L1 锁定脚本的提前退出分支，需要提前解锁密钥和质押者共同参与。任何一方都无法单独转走这些币。 ### 合约所允许的内容 提前解锁子脚本由债券管理员在 `setup-bond`时按每个债券单独设置。合约自身的文档注释写道 `early-unlock-bytes` “应当采用如下形式 ` OP_CHECKSIG` 或一个 M-of-N `CHECKMULTISIG` 模板，并且必须在栈上留下一个有效结果（它会被共享的 OP\_VERIFY 消费掉）。”它以不透明的 `(buff 683)` 按债券存储，合约从不检查其结构。因此，签名者集合的结构是每个债券的策略选择，而不是协议常量。 ### 实际部署的内容 实际上，它始终是一个带有 `OP_CHECKSIG`的单一共签公钥，由带冗余、基于 KMS 的提前退出签名服务管理的一个密钥，而不是链上多签。这是运维选择，不是协议约束。仅说 “M-of-N” 会误导你去设计并不存在的多签；仅说“一直只有一个密钥”，又会让你以为合约强制了它并未强制的事情。 ### Stacks 侧调用 `announce-l1-early-exit` 是 Stacks 侧调用，质押者必须自己发起： `contract-caller` 必须同时等于 `tx-sender` 和质押者参数，因此没有任何合约可以代替他们执行。它会将成员记录的 `amount-sats` 清零，同时保留成员行，因此 **配对 STX 会一直锁定到期**. 每个债券只能宣布一次。对同一债券的第二次宣布会回滚并返回 `ERR_L1_EARLY_EXIT_ALREADY_ANNOUNCED u50`，因此调用方应先检查 `fetchHasAnnouncedL1EarlyExit` 。 ### 顺序 合约对 `announce-l1-early-exit` 与比特币侧花费之间不强制任何顺序。实际上，操作顺序无论如何都是固定的：共签者只有在 Stacks 上找到宣布交易后才会签名，而一旦该宣布落链，仓位就立即停止赚取收益。仅凭合约语义来构建流程会得出错误的操作顺序。 只有在 CLTV 高度之前才需要共签。之后，质押者通过 `OP_IF` 分支即可独自取回，不再涉及共签者。 sBTC 锁定参与者则改用 `unstake-sbtc` ，它没有提前退出门控，也没有宣布步骤。 ## sBTC 自动桥接 默认奖励路径：矿工 BTC 流入奖励池并自动桥接为 sBTC 进行分发。质押者可以通过提供 `signer-calldata` 在 signer-manager 层选择退出，改为 L1 BTC 付款。它不是一个 `register-for-bond` 参数。 `signer-calldata` 是一个不透明的 `(optional (buff 500))` ，pox-5 会将其原样传递给 signer-manager，而不加解释。 ## 滚存窗口 结束中的债券可以在不经过中间提现的情况下直接滚入新债券或仅 STX 质押的期间。它在债券的 L1 解锁高度开启，也就是债券 L2 结束前半个奖励周期，并且不会关闭。当调用方已经持有债券成员资格时， `register-for-bond` 和 `stake` 都会检查这一点；提前操作会返回 `ERR_ROLLOVER_TOO_EARLY (u48)`. 另一个不重叠测试会拒绝新的仓位，因为其第一个周期早于旧债券的结束时间。两道门槛会在债券最后半个奖励周期同时通过，因此那是最早可滚存的时间。债券转债券只转移净 sBTC 差额；债券转仅 STX 质押会退回全部托管 sBTC。 ## 安灯绳 单向的链上断路器。暂停管理员调用 `pause-rewards`，之后 `claim-rewards` 会回滚并返回 `ERR_REWARDS_PAUSED (u53)`。奖励会继续在合约中累积。没有恢复暂停的函数；恢复需要硬分叉。 ## `BOND_GAP_CYCLES` 合约常量 `u2`。它同时设定了新债券在开始高度之前可以建立的窗口，以及新债券开启的节奏，这正是稳态下形成六个重叠的 12 周期债券的原因。 ## 来源 本页中所有合约级别的说法都已与固定版本和已部署合约进行核对： * [`pox-5.clar` 标签 4.0.1](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/chainstate/stacks/boot/pox-5.clar) * [`SP000000000000000000002Q6VF78.pox-5` 在主网上](https://explorer.hiro.so/txid/SP000000000000000000002Q6VF78.pox-5?chain=mainnet\&tab=sourceCode) 覆盖率目标与区间，以及自动桥接作为默认奖励路径，这些内容都以任何形式没有出现在合约中。二者都来自 `glossary.mdx` 和白皮书。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.stacks.co/learn/zh/bitcoin-staking/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.