> 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/block-production/signing.md). # 签名：验证区块有效性 PoX-5 下签名者如何验证并签署 Stacks 区块：每个周期如何选择签名者集合、什么是有效区块，以及任期变更如何进行。
{% hint style="info" %} **构建者资源** * 要作为签名者运行，请参见 [运行签名者](https://docs.stacks.co/operate/run-a-signer). * 要查看活跃签名者的完整列表，请参见 [区块浏览器的签名者页面](https://explorer.hiro.so/signers?chain=mainnet). {% endhint %} #### 整体概览 * 签名者在区块加入链之前验证并签署提议的 Stacks 区块。 * 每个奖励周期的签名者集合是固定的。每个至少质押了 50,000 STX 的 signer-manager 都会获得收益分配。 * 签名者的投票权重与通过它质押的 STX 成正比。 * 接受一个区块需要至少占总签名者权重 70% 的签名。 * 签名可以防止分叉，并将 Stacks 历史锚定到比特币。 *** ### 简介 签名者在 Stacks 网络中扮演的角色，过去属于矿工。在 Nakamoto 升级之前，矿工既决定区块内容，也决定区块是否加入链中。自 Nakamoto 之后，每个角色各承担其中一项职责： * **矿工** 决定区块的内容。 * **签名者** 决定一个区块是否被纳入链中。 Nakamoto 变更的大部分复杂性都投入到将这两个问题分离，同时保持挖矿和质押都采用开放成员制。任何人都可以成为矿工，任何人都可以成为质押者。 [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) 描述了其引入时的设计。 在区块可以被追加到链上之前，签名者必须确认并验证矿工的区块。为此，他们必须先就规范链尖达成一致，然后在该链尖上应用该区块以确定其有效性。一旦足够多的签名者同意该区块既是规范的又是有效的，其签名就会随着区块一起传播到 Stacks 其余的点对点网络，直到那时，节点才会将其追加到各自的链历史中。 这种行为可以防止分叉。如果矿工在过时的链尖之上构建区块，签名者就会拒绝签名。如果签名者无法就规范的 Stacks 链尖达成一致，那么最初就不会追加任何区块。由此产生的失败模式——由于签名者意见不一致而导致链停滞——可以通过保持签名者集合足够大且足够多样化来缓解，以便始终满足法定人数，并通过 PoX 奖励向签名者付费以保持在线。 *** ### 签名者如何被选出 在 PoX-5 下，签名者是绑定到一个签名者密钥的 signer-manager 合约。绑定只发生一次：签名者密钥持有者签署一份 [SIP-018](https://github.com/stacksgov/sips/blob/main/sips/sip-018/sip-018-signed-structured-data.md) 授予，命名该管理者，而管理者通过 `grant-signer-key` 提交它，并通过 `register-signer`进行注册。密钥持有者可以通过 `revoke-signer-grant`撤销该授予，这会停止管理者接受新的质押，同时让现有头寸逐步结束。 在每个准备阶段，也就是一个奖励周期的最后 100 个比特币区块期间，下一个周期的签名者集合会被固定。每个已注册且至少有 50,000 STX（`SIGNER_SET_MIN_USTX`）以总计形式质押给它的 signer-manager 都会获得收益分配。该周期中签名者的投票权重与通过它质押的 STX 总量成正比，把仅 STX 质押中的 STX 与协议债券中的 STX 一侧合并计算。债券中的 BTC 一侧不具有签名权重：签名权重与治理权重一样，仅取决于被锁定的 STX。 签名者软件会根据链状态检测其管理者是否在下一个周期的签名者集合中。质押交易需要手动发送；签名者基于这些信息所做的一切都是自动的。 #### 质押者与签名者之间的关系
Manual staking transactions feeding the reward phase, and the signer software acting automatically once its manager is in the signer set

质押者侧手动，签名者侧自动

* 质押者不是签名者。签名由授予其所质押的 signer-manager 的密钥完成，而运行该签名者是管理者运营者的工作。 * 每个签名者都有质押的 STX 作为支持。拥有至少 50,000 STX 总量门槛的管理者会获得收益分配，并且其权重会随着其代表的质押量增长。 *** ### 签名者签名 当矿工提出一个区块时，每个签名者都会独立验证它，并使用其被授予的签名者密钥对其签名。区块携带由此产生的一组签名，只有当这些签名有效、无重复、与签名者集合的顺序一致，并且合计至少占该周期总签名者权重的 70% 时，节点才会接受它。该阈值是节点中的一个共识常量（[`NAKAMOTO_SIGNER_BLOCK_APPROVAL_THRESHOLD`](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/core/mod.rs)). 在该协议中，权重就是质押：代表了全部已质押 STX 10% 的 signer-manager，在每个区块上都拥有 10% 的投票权。区块由锁定资本的经济多数来接受，这也正是把区块生产与 [质押页面](/learn/zh/block-production/staking.md). *** ### 验证并追加新区块 当选出新的任期矿工时，他们会从内存池中的交易开始构建区块，并将其发送给签名者批准。签名者必须以至少 70% 的签名者权重批准一个区块，它才会被追加到链上。 签名者基于以下几个属性来批准区块： * 区块格式正确 * 它具有正确的版本和主网/测试网标志 * 它的区块头包含该区块之前正确数量的 Stacks 区块。 * 它的区块头包含用于选出当前任期的 sortition 中正确的总比特币支出。 * 它的区块头包含与包含该任期 block-commit 交易\* 的比特币区块相同的比特币区块哈希 * 它的区块头包含该区块直接父区块的正确父区块 ID。\* * 交易 Merkle 树根与这些交易一致 * 在应用完所有交易后，状态根哈希与 MARF tip 根哈希匹配 * 区块头具有来自矿工的有效 ECDSA 签名。 * 区块头携带满足 70% 权重阈值的签名者签名。 * 自上一次有效 sortition 以来，直到（但不包括）该任期的 block-commit 所在的比特币区块为止的所有比特币交易都已应用到 Stacks 链状态\* * 在任期开始区块的情况下： * 第一笔交易是 `TenureChange` 交易。 * 在 `TenureChange` 交易之后的第一笔交易是一个 `Coinbase`. 带 \* 标记的属性共同构成了 Stacks 如何确保比特币最终性的方式。通过遵守这些要求，矿工只能追加建立在正确链尖之上的区块，这也将历史锚定到比特币。 ### 执行矿工任期变更 区块生产中的另一项主要签名职责是执行任期变更交易。如挖矿部分所述，矿工会在比特币链上提交一笔 `block-commit` 交易以启动挖矿。如果矿工被选中，签名者会检测到这一点并创建一笔 `tenure-change` 交易。 这笔任期变更交易包含： | 名称 | 描述 | 表示 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------- | -------- | | 任期共识哈希 | 该任期的共识哈希。对应于选出该区块矿工的 sortition。如果该矿工的任期在后续 sortition 中被延长，也可能发生这种情况；如果发生这种情况，则该 `共识哈希` 值将保持与产生获胜 block-commit 的 sortition 相同。 | 20 字节 | | 前一任期共识哈希 | 前一任期的共识哈希。对应于前一个获胜 block-commit 的 sortition。 | 20 字节 | | burn view 共识哈希 | 底层 burnchain 上当前的共识哈希。对应于最近一次可见的 sortition。 | 20 字节 | | 前一任期结束 | 前一任期最后一个 Stacks 区块的索引区块哈希。 | 32 字节 | | 前一任期区块数 | 自上一次与 sortition 关联的任期以来产生的区块数量。 | 4 字节，大端序 | | 原因 |

用于指示此次任期变更原因的标志
- 0x00 表示发生了 sortition，并且新的矿工应该开始出块。
- 0x01 表示当前矿工应继续出块。处理此交易后，会重置当前矿工的任期执行预算。

| 1 字节 | | 公钥哈希 | 当前任期的 ECDSA 公钥哈希。 | 20 字节 | 然后，这笔任期变更交易会发送给新当选的矿工，矿工必须将其作为第一笔交易包含在其第一个区块中，否则签名者不会批准。 随着新矿工被选为各个任期，此过程会重复进行。 [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) 详细描述了这些过程底层发生的事情。 *** ### 如果你了解 PoX-4 下的签名 旧模型的修正，汇总如下： * 质押者会在每次 stacking 或 delegate-stack 交易中注册一个区块签名密钥。现在已经不再如此：签名者管理者通过一次性授予持有一个签名者密钥，该授予可由密钥持有者撤销。 * 奖励名额已取消，随之取消的还有每周期 4,000 个名额的上限。签名者集合就是符合条件的 signer-managers 集合，权重来自质押的 STX，而不是抢到的名额。 * 委托已取消，因此过去区分“亲自签名的质押者”和“委托其签名的质押者”的说法不再描述任何东西。签名归属于质押者所质押的 signer-manager 被授予的密钥。 * SIP-021 规定使用通过 WSTS 协议生成的聚合 Schnorr 签名进行签名，并且每个周期都包括一轮分布式密钥生成。节点会根据一组按质押加权的单独签名者签名来验证区块，如上所述。请将 SIP-021 中的 WSTS 材料视为设计历史。 *** #### 其他资源 * [SIP-021：Nakamoto](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) * [SIP-045：PoX-5，比特币质押](https://github.com/stacksgov/sips/blob/main/sips/sip-045/sip-045-pox-5-bitcoin-staking.md) * [发布 4.0.1 中的 pox-5.clar](https://github.com/stacks-network/stacks-core/blob/4.0.1/stackslib/src/chainstate/stacks/boot/pox-5.clar) * [运行签名者](https://docs.stacks.co/operate/run-a-signer) * [生成签名者签名](https://docs.stacks.co/operate/staking-stx/generate-signer-signature) --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stacks.co/learn/zh/block-production/signing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.