签名

在 Nakamoto 系统中，Stacker 扮演着此前由矿工负责的重要角色。之前，矿工既决定区块的内容，也决定是否将其包含在链中（即通过决定是否确认它们）。在此系统中，每个参与者都有下列职责，以确保系统在不产生分叉的情况下可靠运行：

• 矿工 决定区块的内容。

• Stacker（质押者） 决定该区块是否被包含在链中。

Nakamoto 变更的大部分复杂性在于将这两项职责分离，同时确保挖矿和 Stacking 保持为开放成员制流程。 关键是，任何人都可以成为矿工，任何人也可以成为 Stacker，就像以前一样。 最实质性的变化在于让矿工和 Stacker 在其新角色中协同工作以实现本提案的目标。

关键思想是：在区块被追加到链之前，Stacker 需要确认并验证矿工的区块。为此，Stacker 必须先就规范链的链尖达成一致，然后在该链尖上应用（并回滚）该区块以确定其有效性。一旦 Stacker 达成共识认为该区块既是规范的又是有效的，他们就集体对其签名并将其复制到其余 Stacks 对等网络。只有在这一点上，节点才会将该区块追加到它们的链历史中。

这种新行为防止了分叉的产生。如果矿工在一个陈旧的链尖上构建区块，Stacker 将拒绝对该区块签名。如果 Stacker 无法就规范的 Stacks 链尖达成一致，则根本不会有区块被追加。虽然这种行为为 Stacks 引入了一种新的失败模式——即如果 Stacker 无法就链尖达成一致，链可能无限期停止——但通过拥有大量且多样化的 Stacker 群体来缓解，以确保始终有足够数量的 Stacker 在线以满足法定人数，并通过 PoX 奖励激励他们履行此职责。

Stacker 签名

您可以查看所有 活跃签名者 在 Stacks 区块浏览器上。

我们将在 Stacking 部分介绍 stacking 的工作原理，并在 sBTC 部分介绍 sBTC 的签名；在此我们将讨论与 Stacks 区块生产相关的签名过程。

Stacker 就规范链尖达成一致并同意追加区块的手段与 PoX 绑定。在每个奖励周期中，Stacker 会获得一个或多个奖励插槽；每个奖励周期最多有 4,000 个奖励插槽。Stacker 通过对区块产生加权阈值签名来投票接受区块。该签名必须代表 PoX 中被锁定的总 STX 的一个实质性比例（阈值），并且每个 Stacker 在签名中的份额（其权重）与其拥有的被锁定 STX 所占比例成正比。

加权阈值签名是一种通过变体生成的 Schnorr 签名，采用 FROST 协议。每个 Stacker 生成一个签名密钥对，并且他们集体生成一个聚合公钥，供节点用于验证通过分布式签名协议计算的签名。该签名协议根据 Stacker 赢得的奖励插槽数将关联的聚合私钥份额分配给 Stacker。没有 Stacker 会知道聚合私钥；Stacker 而是计算私钥的份额并使用这些份额来计算签名份额，这些份额可以合并成一个单一的 Schnorr 签名。

当矿工生成区块时，Stacker 执行分布式签名协议以集体为该区块生成一个单一的 Schnorr 签名。关键在于，只有当聚合签名中至少包含 X% 的奖励插槽时，签名协议才会成功。Nakamoto 当前设置为使用 70% 的签名阈值——至少 70% 的奖励插槽（通过代理，70% 的被质押 STX）必须对一个区块签名，才能将其追加到 Stacks 区块链中。

Nakamoto 使用 带有 FIRE 扩展的 WSTS 协议，该协议接受一对分布式密钥生成与签名生成算法，其 CPU 和网络带宽复杂度随不同 Stacker 数量的增加而增长。FIRE 扩展使得 WSTS 能够容忍拜占庭 Stacker。

下面是一个概述签名与 stacking 之间关系的示意图。

验证并追加新块

当矿工被选中获得新的任期时，他们开始从内存池中的交易构建新区块。然后他们将这些区块发送给 Stacker 以供批准。Stacker 必须以至少 70% 的法定人数批准这些区块，才能将其追加到链中。

Stacker 将基于若干属性来批准一个区块：

• 该区块格式正确（格式良好）

  • 具有正确的版本和主网/测试网标志

  • 其头部包含在此区块之前的正确数量的 Stacks 区块。

  • 其头部包含在选出当前任期的抽签中所消耗的正确比特币总额。

  • 其头部包含与包含其任期的区块提交交易的比特币区块相同的比特币区块哈希*

  • 其头部包含该区块直接父区块的正确父区块 ID。*

  • 交易默克尔树根与交易一致

  • 一旦应用所有交易，状态根哈希与 MARF 尖根哈希相匹配

  • 区块头具有来自矿工的有效 ECDSA 签名。

  • 区块头具有来自 Stacker 集合的有效 WSTS Schnorr 签名。

• 自上一次有效抽签以来直到（但不包括）本任期的区块提交所在的比特币区块为止的所有比特币交易，均已被应用到 Stacks 链状态中*

• 在任期开始区块的情况下：

  • 第一笔交易是 任期变更（TenureChange） 交易。

  • 在 任期变更（TenureChange） 交易之后的第一笔交易是一个 Coinbase（区块收益）.

带有 * 标记的属性共同构成 Stacks 确保比特币最终性的方式。通过遵守这些属性，它确保矿工只有在其构建在正确的链尖之上时才能追加区块，这也将历史锚定到比特币上。

Stacker 通过验证这些规则来确保证明比特币的最终性。我们将在下一节中对此进行更多讨论。

进行矿工任期变更

区块生产中的另一个主要签名职责涉及执行任期变更交易。如挖矿部分所讨论，矿工将在比特币链上提交一笔 区块提交（block-commit） 交易以启动挖矿。如果他们被选中，Stacker 将检测到并创建一个 任期变更（tenure-change） 交易。

该任期变更交易包括：

名称	描述	表示
任期共识哈希	该任期的共识哈希。对应于在其抽签中选择出该区块矿工的抽签。可能出现该矿工的任期在后续抽签中被延长的情况；如果发生这种情况，则该 共识哈希 值将保持为赢得区块提交被挖出的抽签时的值。	20 字节
先前任期共识哈希	先前任期的共识哈希。对应于先前赢得区块提交的抽签。	20 字节
燃烧视图共识哈希	底层 burnchain 上的当前共识哈希。对应于最后看到的抽签。	20 字节
先前任期结束	来自先前任期的最后一个 Stacks 区块的索引区块哈希。	32 字节
先前任期区块数	自上次与抽签关联的任期以来产生的区块数量。	4 字节，大端序
原因（cause）	一个标志，用于指示此任期变更的原因 - 0x00 表示发生了抽签，新的矿工应开始生成区块。 - 0x01 表示当前矿工应继续生成区块。处理此交易时，当前矿工的任期执行预算将被重置。	1 字节
公钥哈希	当前任期的 ECDSA 公钥哈希。	20 字节

然后将此任期变更交易发送给新当选的矿工，他们必须将其作为其第一个区块中的第一笔交易包含，否则 Stacker 将不会批准该区块。

随着新矿工被选为任期，该过程将一遍又一遍地重复进行。

请务必查看 SIP-021 以获取在这些过程中底层具体发生了什么的详细描述。

接下来，让我们更深入地探讨比特币最终性的这一概念以及 Stacks 区块生产机制如何实现它。