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