签名

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

• 矿工 决定区块的内容。

• 质押者 决定是否将该区块包含在链中。

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

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

这种新行为可以防止产生分叉。如果矿工在过时的链尖上构建区块，质押者将拒绝签署该区块。如果质押者无法就规范的 Stacks 链尖达成一致，那么根本不会有区块被追加。虽然这种行为为 Stacks 引入了一种新的失效模式——即如果质押者无法就链尖达成一致，链可能无限期停滞——但通过拥有大量且多样化的质押者群体，使得始终有足够多的质押者在线以满足法定人数，并通过 PoX 奖励激励他们这样做，可以缓解该问题。

质押者签名

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

我们将在“质押”一节中介绍质押的工作方式，在 sBTC 一节中介绍 sBTC 签名；这里我们将介绍与 Stacks 区块生成相关的签名流程。

质押者就规范链尖达成一致并同意追加区块的方式与 PoX 相关。在每个奖励周期中，质押者会赢得一个或多个奖励插槽；每个奖励周期最多有 4,000 个奖励插槽。质押者通过对区块生成加权阈值签名来投票接受区块。该签名必须代表 PoX 中被锁定的总 STX 的相当一部分（阈值），且每个质押者在签名中的份额（其权重）与其所持锁定 STX 占比成正比。

加权阈值签名是一种通过变体生成的 Schnorr 签名，基于 FROST 协议。每个质押者生成一个签名密钥对，他们共同生成一个聚合公钥，供节点用于验证通过分布式签名协议计算的签名。该签名协议将相关聚合私钥的份额按质押者赢得的奖励插槽数分配给质押者。没有质押者会知道聚合私钥；质押者计算私钥份额并使用这些份额计算签名份额，随后将这些份额组合成单个 Schnorr 签名。

当矿工生成一个区块时，质押者执行分布式签名协议以共同为该区块生成一个单一的 Schnorr 签名。关键在于，该签名协议只有在聚合签名中覆盖了至少 X% 的奖励插槽时才会成功。纳卡莫托当前设置使用 70% 的签名阈值——必须由至少 70% 的奖励插槽（作为代理，即 70% 的已质押 STX）对区块进行签名，才能将其追加到 Stacks 区块链中。

纳卡莫托使用 带有 FIRE 扩展的 WSTS 协议，该协议允许一对分布式密钥生成和签名生成算法，其 CPU 和网络带宽复杂度会随着不同质押者数量的增长而增长。FIRE 扩展使得 WSTS 能够容忍拜占庭质押者。

下面是一张说明签名与质押之间关系的图表。

验证并追加新块

当矿工被选中开始新的任期时，他们会从内存池中的交易构建新块，然后将这些区块发送给质押者以供批准。质押者必须以至少 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 区块生成机制如何实现它。