签名：验证区块有效性
全局概览
签名者对提议的 Stacks 区块进行验证并签名。
他们每个周期从符合资格的 Stackers 中选出。
一个区块要被接受，需要达到 70% 的签名阈值。
他们在签名前会先验证区块是否正确。
签名有助于防止无效或冲突的区块。
他们的角色增强了最终性和网络安全性。
简介
同时也作为签名者运行的 Stackers，在 Stacks 网络中（Nakamoto 升级后）扮演着至关重要的角色；这在之前是矿工的职责。以前，矿工既决定区块的内容，也决定是否将其纳入链中（即决定是否确认它们）。在这个系统中，每个参与者都有以下职责，以确保系统无需分叉也能可靠运行：
矿工 决定区块的内容。
签名者 决定区块是否被纳入链中。
Nakamoto 变更的大部分复杂性在于将这两项职责分离，同时确保挖矿和 Stacking 仍然是开放成员过程。 至关重要的是，任何人都可以像以前一样成为矿工，任何人都可以成为 Stacker。 最重大的变化在于让矿工和 Stackers 在新角色下协同工作，以实现这一提案的目标。
关键思想是，Stackers 作为签名者，必须先承认并验证矿工的区块，区块才能被追加到链上。为此，Stackers 必须先就规范链尖达成一致，然后在该链尖上应用（并回滚）该区块，以确定其有效性。一旦 Stackers 确认该区块既是规范的又是有效的，他们就会共同对其签名，并将其复制到 Stacks 对等网络的其余部分。只有在这时，节点才会把区块追加到各自的链历史中。
这种新行为可防止分叉产生。如果矿工在过时的链尖上构建区块，Stackers 将拒绝为该区块签名。如果 Stackers 无法就规范的 Stacks 链尖达成一致，那么一开始就不会有任何区块被追加。虽然这种行为为 Stacks 带来了新的故障模式——即如果 Stackers 无法就链尖达成一致，链可能会无限期停摆——但通过拥有大量且多样化的 Stackers 群体，可以缓解这一问题，使得始终有足够多的在线成员来满足法定人数要求，并通过 PoX 奖励激励他们如此行事。
Stacker 签名
Stackers 就规范链尖达成一致并同意追加区块的方式与 PoX 相关。在每个奖励周期中，一个 Stacker 会锁定一个或多个奖励席位；每个奖励周期最多有 4,000 个奖励席位。Stackers 通过对区块生成加权阈值签名来投票接受区块。该签名必须代表 PoX 中锁定的 STX 总量中相当大的一部分（阈值），且每个 Stacker 在签名中的份额（其权重）与其拥有的锁定 STX 比例成正比。
加权阈值签名是一种 Schnorr 签名，通过一种变体的 FROST 协议生成。每个 Stacker 都会生成一对签名密钥，随后他们共同生成一个聚合公钥，供节点通过分布式签名协议验证所计算出的签名。该签名协议会按 Stackers 锁定的奖励席位数量比例，将关联的聚合私钥份额分配给他们。没有任何 Stacker 会知道聚合私钥；Stackers 只会计算私钥份额，并用它们来计算签名份额，最终可合并为一个单一的 Schnorr 签名。
当矿工产出一个区块时，Stackers 会执行分布式签名协议，共同为该区块生成一个单独的 Schnorr 签名。关键在于，只有当至少有 X% 的奖励席位被计入聚合签名时，该签名协议才会成功。Nakamoto 目前设定为使用 70% 的签名阈值——要将区块追加到 Stacks 区块链上，至少需要 70% 的奖励席位（间接对应 70% 的已质押 STX）对区块签名。
Nakamoto 使用 带有 FIRE 扩展的 WSTS 协议，它支持一对分布式密钥生成和签名生成算法，其 CPU 和网络带宽复杂度会随着不同 Stacker 数量的增加而增长。FIRE 扩展使 WSTS 能够容忍拜占庭式 Stackers。
Stackers 与签名者之间的关系
下面是一张概述签名与 stacking 之间关系的图。
并非所有 stackers 都是签名者 → 因为 stackers 可以 委托 他们的参与权（包括签名职责）
所有签名者都由 他们自己的 STX 或 委托的 STX → 要进入签名者集合，你必须代表 已质押的 STX 权重
验证并追加新区块
当矿工被选中进入一个新的任期时，他们会开始从内存池中的交易构建新区块。然后他们将这些区块发送给签名者以供批准。签名者必须以至少 70% 的法定人数批准这些区块，区块才能被追加到链上。
签名者会根据以下几个属性来批准一个区块：
该区块格式正确
它具有正确的版本和主网/测试网标志
其区块头包含在此之前的正确数量的 Stacks 区块。
其区块头包含选出当前任期的 sortition 中正确的 Bitcoin 总花费。
其区块头包含与该任期 block-commit 交易所在的 Bitcoin 区块相同的 Bitcoin 区块哈希*
其区块头包含该区块直接父区块的正确父区块 ID。*
交易 Merkle 树根与这些交易一致
在应用所有交易后，状态根哈希与 MARF 尾端根哈希匹配
区块头具有来自矿工的有效 ECDSA 签名。
区块头具有来自该组 Stackers 的有效 WSTS Schnorr 签名。
自上一次有效 sortition 以来，到（但不包括）该任期 block-commit 对应的 Bitcoin 区块为止的所有 Bitcoin 交易，都已应用到 Stacks 链状态中*
在任期起始区块的情况下：
第一笔交易是
TenureChange交易。在
TenureChange交易之后的第一笔交易是一个Coinbase.
带有 * 标记的属性，合起来就是 Stacks 确保 Bitcoin 最终性的方式。通过遵守这些属性，它确保只有当矿工构建在正确的链尖之上时，他们才能追加区块，这也将历史锚定到 Bitcoin。
签名者通过验证这些规则，确保 Bitcoin 最终性。
执行矿工任期变更
区块生产中的另一项主要签名职责是执行任期变更交易。正如在挖矿部分所述，矿工会在 Bitcoin 链上提交一个 block-commit 交易以启动挖矿。如果他们被选中，stackers 就会检测到这一点并创建一个 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 字节
然后，这笔任期变更交易会被发送给新当选的矿工，他们必须将其作为第一笔交易包含在其第一个区块中，否则 Stackers 将不会批准它。
随后，这个过程会在新的矿工被选为任期矿工时一遍又一遍地重复。
务必查看 SIP-021 以详细了解这些过程在底层究竟是如何发生的。
接下来，让我们更深入地探讨 Bitcoin 最终性这一概念，以及 Stacks 的区块生产机制如何实现它。
其他资源
[StacksDevs YT] Stacks Nakamoto 发布签名者工作坊
最后更新于
这有帮助吗？