签名：验证区块有效性
大局观
签名者验证并签署提议的 Stacks 区块。
他们在每个周期从有资格的堆栈者中选出。
区块被接受需要 70% 的签名阈值。
他们在签名前验证区块的正确性。
签名有助于防止无效或冲突的区块。
他们的角色加强了最终性和网络安全性。
简介
作为签名者操作的堆栈者在 Stacks 网络（Nakamoto 升级后）中扮演着关键角色，这一职责此前由矿工承担。以前，矿工既决定区块的内容，也决定是否将其包含在链中（即通过决定是否确认它们）。在该系统中，各参与者承担以下责任，以使系统在不产生分叉的情况下可靠运行：
矿工 决定区块的内容。
签名者 决定该区块是否被包含在链中。
Nakamoto 变更的大部分复杂性在于将这两项职责分离，同时确保挖矿和 Stacking 仍然是开放成员制的过程。 关键是，任何人都可以成为矿工，任何人也可以成为堆栈者，就像以前一样。 最重大的变化在于让矿工和堆栈者在其新角色中协同工作以实现本提案的目标。
关键思想是，堆栈者作为签名者，必须在矿工的区块可以附加到链之前确认并验证该区块。为此，堆栈者必须首先就规范链的顶端达成一致，然后在该链顶端上应用（并回滚）区块以确定其有效性。一旦堆栈者一致认为该区块既是规范的又是有效的，他们会集体签署该区块并将其复制到其余的 Stacks 点对点网络。只有在此时，节点才会将该区块附加到其链历史中。
这种新行为防止了分叉的产生。如果矿工在陈旧的链顶上构建区块，堆栈者将拒绝签署该区块。如果堆栈者无法就规范的 Stacks 链顶达成一致，则根本不会附加任何区块。虽然这种行为为 Stacks 引入了一种新的失败模式——即如果堆栈者无法就链顶达成一致，链可能无限期停止——但通过拥有大量且多样化的堆栈者群体，使其中足够多的人始终在线以满足法定人数并通过 PoX 奖励激励他们采取行动，可以缓解该问题。
堆栈者签名
堆栈者就规范链顶达成一致并同意附加区块的方式与 PoX 相关。在每个奖励周期中，堆栈者赢得一个或多个奖励名额；每个奖励周期最多有 4,000 个奖励名额。堆栈者通过对区块生成加权阈值签名来投票接受区块。签名必须代表 PoX 中锁定的总 STX 的相当一部分（即阈值），每个堆栈者在签名中的份额（其权重）与其拥有的锁定 STX 所占比例成正比。
加权阈值签名是一种通过变体生成的 Schnorr 签名，使用了 FROST 协议。每个堆栈者生成一个签名密钥对，并共同生成一个聚合公钥，节点用于验证通过分布式签名协议计算的签名。该签名协议按堆栈者赢得的奖励名额数量按比例分配相关聚合私钥的份额。没有任何堆栈者会知道聚合私钥；堆栈者相反计算私钥的份额并使用这些份额计算签名的份额，这些份额可以合并为单个 Schnorr 签名。
当矿工生成区块时，堆栈者执行分布式签名协议以集体为该区块生成单一的 Schnorr 签名。关键是，只有当在聚合签名中至少包含 X% 的奖励名额时，签名协议才会成功。Nakamoto 当前设置为使用 70% 的签名阈值——至少 70% 的奖励名额（通过代理，即 70% 的被质押 STX）必须为区块签名，才能将其附加到 Stacks 区块链。
Nakamoto 使用了 带有 FIRE 扩展的 WSTS 协议，该协议允许一对分布式密钥生成和签名生成算法，其 CPU 和网络带宽复杂度随不同堆栈者数量增长。FIRE 扩展使 WSTS 能够容忍拜占庭式的堆栈者。
堆栈者与签名者之间的关系
下面是概述签名与堆栈之间关系的图示。
并非所有堆栈者都是签名者 → 因为堆栈者可以 委托 他们的参与（包括签名职责）
所有签名者都由 他们自己的 STX 支持 或 被委托的 STX → 要成为签名者集合的一员，你必须代表 已质押的 STX 权重
验证并追加新区块
当矿工被选为新的任期时，他们开始从内存池的交易构建新区块。然后他们将这些区块发送给签名者审批。签名者必须以至少 70% 的法定人数批准这些区块，才能将它们附加到链上。
签名者将基于若干属性批准一个区块：
区块格式良好
它具有正确的版本和主网/测试网标志
其头部包含在该区块之前的正确数量的 Stacks 区块。
其头部包含在选举当前任期的抽签中消耗的正确总比特币数。
其头部包含与包含其任期的区块提交交易的比特币区块相同的比特币区块哈希*
其头部包含该区块直接父区块的正确父区块 ID。*
交易默克尔树根与交易一致
在应用所有交易后，状态根哈希与 MARF 顶端根哈希相匹配
区块头具有矿工有效的 ECDSA 签名。
区块头具有来自堆栈者集合的有效 WSTS Schnorr 签名。
自上次有效的抽签以来直到（但不包括）该任期的区块提交的比特币区块中的所有比特币交易都已应用到 Stacks 链状态中*
在任期起始区块的情况下：
第一个交易是
TenureChange交易。在该
TenureChange交易之后的第一个交易是一个Coinbase.
带有 * 标记的属性共同构成 Stacks 确保比特币最终性的方式。通过遵守这些属性，它确保矿工只有在他们构建于正确的链顶之上时才能附加区块，这也将历史锚定到比特币上。
签名者通过验证这些规则来确保比特币的最终性。
执行矿工任期变更
区块生产中另一个主要的签名职责涉及执行任期变更交易。如在挖矿部分所讨论，矿工将提交一个 区块提交（block-commit） 交易到比特币链以启动挖矿。如果他们被选中，堆栈者会检测到并创建一个 任期变更（tenure-change） 交易。
该任期变更交易包括：
任期共识哈希
该任期的共识哈希。对应于选择该区块矿工的抽签。可能出现该矿工的任期跨越后续抽签被延长的情况；如果发生这种情况，则该 共识哈希 值保持与挖出获胜区块提交的抽签相同。
20 字节
先前任期共识哈希
先前任期的共识哈希。对应于先前获胜区块提交的抽签。
20 字节
燃烧链视图共识哈希
底层燃烧链上的当前共识哈希。对应于最后一次看到的抽签。
20 字节
先前任期结束
先前任期中最后一个 Stacks 区块的索引区块哈希。
32 字节
先前任期区块数
自上次与抽签关联的任期以来产生的区块数量。
4 字节，大端序
原因
用于指示此任期变更原因的标志
- 0x00 表示发生了抽签，并且新的矿工应开始生成区块。
- 0x01 表示当前矿工应继续生成区块。处理此交易后，当前矿工的任期执行预算将被重置。
1 字节
公钥哈希
当前任期的 ECDSA 公钥哈希。
20 字节
然后将此任期变更交易发送给新当选的矿工，他们必须将其作为其第一个区块中的第一笔交易包含，否则堆栈者将不会批准它。
随着新矿工被选为任期，该过程将一遍又一遍地重复。
务必查看 SIP-021 以获得在这些过程中在底层究竟发生了什么的详细描述。
接下来，让我们更深入挖掘一下比特币最终性的这个概念以及 Stacks 区块生产机制如何实现它。
附加资源
[StacksDevs Youtube] Stacks Nakamoto 发布 签名者 研讨会
最后更新于
这有帮助吗？