> 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). # 签名：验证区块有效性
{% hint style="info" %} **构建者资源** * 要作为签名者运行，请参见 [运行签名者](https://docs.stacks.co/operate/run-a-signer). * 要查看活跃签名者的完整列表，请参见 [Explorer 的签名者页面](https://explorer.hiro.so/signers?chain=mainnet). {% endhint %} #### 全局视图 * 签名者在 Stacks 区块加入链之前，会先验证并签署提议的 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-only 质押中的 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). *** ### 验证并追加新区块 当矿工被选中进入新的任期时，他们会开始根据 mempool 中的交易构建区块，并将其发送给签名者以供批准。签名者必须以至少 70% 的签名者权重批准一个区块，才能将其追加到链上。 签名者会根据若干属性批准一个区块： * 区块格式正确 * 它具有正确的版本和主网/测试网标志 * 其区块头包含在此之前的正确数量的 Stacks 区块。 * 其区块头包含在选择当前任期的抽签中所消耗的正确总比特币数。 * 其区块头包含与包含该任期 block-commit 交易的比特币区块相同的比特币区块哈希\* * 其区块头包含该区块直接父区块的正确父区块 ID\*。 * 交易 Merkle 树根与这些交易一致 * 在所有交易应用完后，状态根哈希与 MARF 尾端根哈希匹配 * 区块头具有来自矿工的有效 ECDSA 签名。 * 区块头携带满足 70% 权重阈值的签名者签名。 * 自上次有效抽签以来直到（但不包括）该任期 block-commit 的比特币区块之间的所有比特币交易，都已应用到 Stacks 链状态中\* * 在任期开始区块的情况下： * 第一笔交易是 `TenureChange` 交易。 * 在 `TenureChange` 交易之后的第一笔交易是一个 `Coinbase`. 标有 \* 的属性合起来，正是 Stacks 确保比特币最终性的方式。通过遵守这些属性，矿工只能追加建立在正确链尖之上的区块，这也将历史锚定到比特币。 ### 执行矿工任期变更 区块生产中的另一个主要签名职责是执行任期变更交易。如挖矿部分所述，矿工会在比特币链上提交一笔 `block-commit` 交易来启动挖矿。如果某个矿工被选中，签名者会检测到这一点并创建一个 `tenure-change` 交易。 这笔任期变更交易包括： | 名称 | 描述 | 表示 | | -------- | --------------------------------------------------------------------------------------------------------------------------- | -------- | | 任期共识哈希 | 该任期的共识哈希。对应于选择该区块矿工的抽签。也可能出现该矿工的任期在后续抽签中被延长；如果发生这种情况，那么这个 `共识哈希` 值将保持与赢得 block-commit 的那次抽签相同。 | 20 字节 | | 前一任期共识哈希 | 前一任期的共识哈希。对应于前一个获胜 block-commit 的抽签。 | 20 字节 | | 燃烧视图共识哈希 | 底层 burnchain 上当前的共识哈希。对应于最近一次看到的抽签。 | 20 字节 | | 前一任期结束 | 前一任期最后一个 Stacks 区块的索引区块哈希。 | 32 字节 | | 前一任期区块数 | 自上一次与抽签关联的任期以来产生的区块数量。 | 4 字节，大端序 | | 原因 |

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

| 1 字节 | | 公钥哈希 | 当前任期的 ECDSA 公钥哈希。 | 20 字节 | 然后，这笔任期变更交易会发送给新当选的矿工，该矿工必须把它作为第一笔交易放入自己的第一个区块中，否则签名者不会批准。 随着新矿工被选出进入各自任期，这一过程会重复进行。 [SIP-021](https://github.com/stacksgov/sips/blob/main/sips/sip-021/sip-021-nakamoto.md) 对这些过程在底层发生的情况有详细说明。 *** ### 如果你了解 PoX-4 下的签名 对旧模型的修正，汇总如下： * 质押者会在每次质押或委托质押交易中注册一个区块签名密钥。这一机制已经取消：signer-manager 通过一次性的授予持有一个签名密钥，并且可由密钥持有者撤销。 * 奖励席位也已经取消，与之一起取消的还有每个周期最多 4,000 个席位的上限。签名者集合就是符合条件的 signer-manager 集合，权重来自已质押的 STX，而不是占用的席位。 * 委托也已经取消，因此旧的“会签名的质押者”和“委托其签名的质押者”之间的区分已不再适用。签名归属于质押者所质押到的 signer-manager 获得的密钥。 * SIP-021 规定，签名使用通过 WSTS 协议生成的聚合 Schnorr 签名，并且每个周期包括一轮分布式密钥生成。节点会根据一组按质押加权的单个签名者签名来验证区块，如上所述。关于 WSTS 的材料，请将 SIP-021 中的内容视为设计历史。 *** #### 其他资源 * [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 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/block-production/signing.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.