什么是中本聪升级？

Nakamoto 版本是在 2024 年第四季度对 Stacks 网络进行的一次硬分叉，旨在带来若干益处，其中最主要的是提高交易吞吐量和实现 100% 的比特币最终性。

在 Nakamoto 中，Stacks 区块产生将不再与矿工选举绑定。相反，矿工以固定节奏产生区块，而参与 PoX 的质押者（Stackers）依赖矿工选举来决定当前矿工何时停止出块以及新的矿工何时开始出块。该区块链只有在 70% 的质押者批准分叉时才会发生分叉，链重组的难度将与重组比特币一样困难。

Nakamoto 版本通过关注一组核心改进，为 Stacks 区块链带来了许多新功能和改进：提高交易速度、增强交易的最终性保证、减轻影响 PoX 的比特币矿工 MEV（矿工可提取价值）机会，并增强对链重组的鲁棒性。

之前的 Stacks 区块产生设计

当前 Stacks 区块链按以下描述的算法产生区块： SIP-001 和 SIP-007，以及 SIP-015。矿工通过由 VRF 支持的抽签（sortition）过程进行矿工选择，竞争将区块追加到区块链。矿工向比特币提交一个区块提交交易（block-commit），该交易对矿工打算追加的区块哈希进行提交。抽签过程在随后产生的比特币区块中最多选择一个区块提交，这使提交者有权传播其区块并获得区块奖励。

问题

在过去三年中，Stacks 社区发现当前系统设计存在若干问题：

1. 缓慢的比特币区块、Stacks 分叉和错过抽签会干扰链上应用。 等待抽签选出有效矿工后再产生新区块的做法，将最佳情况下的 Stacks 区块产生速率绑定到比特币的区块产生速率，导致交易确认延迟非常高。

2. 微区块（microblocks）在加速交易确认方面并不高效。 虽然微区块有可能缓解错过抽签的问题并改善交易被包含的时间，但在实践中并不奏效，因为协议无法确保微区块会在下一次抽签发生之前被确认。此外，新矿工通常会使旧矿工在微区块中已包含且刚被确认的交易成为孤块，因为没有达成共识的关键程序强制下一位矿工在最近的微区块之上继续构建。

3. Stacks 的分叉并不与比特币分叉绑定，从而允许廉价的重组 重组 Stacks 区块链最近 N 个区块的成本等于产生接下来 N+1 个 Stacks 区块的成本（即通过花费比特币），与重组比特币的成本相比这相对廉价。该 SIP 描述了一种将规范的 Stacks 分叉与比特币区块链绑定的机会，使得重组 Stacks 链历史的行为需要得到 70% 质押者的签署。

4. Stacks 分叉是由于连接不良的矿工造成的。 如果一组矿工在提交区块提交时难以获悉规范的 Stacks 链顶，那么他们会集体使那些连接更好的矿工的区块成为孤块。实践中曾发生过这种情况。

5. 一些比特币矿工运行自己的 Stacks 矿工并故意将其他 Stacks 矿工的 区块提交（block-commits） 从他们的比特币区块中排除。 一旦 STX 的区块奖励变得足够大，这使得他们能够支付微不足道的 PoX 支付，同时保证他们将在其比特币区块中赢得加密抽签。这在最初的设计中已被预见到，但如今这种情况发生的频率比原协议预期的要高，因此必须现在加以解决。

解决方案

为了解决这些不足，Nakamoto 对 Stacks 的工作方式做出了三项根本性改变。

• 快速区块： 用户提交的交易被打包进区块（从而被确认）所需的时间现在将以秒为量级，而不是以几十分钟计。通过将区块产生与加密抽签分离实现——一个获胜矿工可能在两次连续抽签之间产生多个区块。

• 比特币最终性： 一旦交易被确认，要撤销它至少与撤销一笔比特币交易一样困难。Stacks 区块链不再自行发生分叉。

• 抵抗比特币矿工 MEV： 该提案更改了抽签算法，以确保比特币矿工在作为 Stacks 矿工时不会具有优势。他们必须花费具有竞争力数量的比特币才能有机会获得 STX。

Nakamoto 设计

为实现这些目标，Nakamoto 对 Stacks 协议引入了以下更改：

1. 将 Stacks 任期变更与比特币区块到达解耦。 在当前系统和 Nakamoto 中，矿工轮流将区块追加到 Stacks 区块链——下一位矿工由加密抽签选出，且矿工有相当于比特币区块持续时间的任期来宣布新区块状态。Nakamoto 允许一个矿工在每个比特币区块期间产生多个 Stacks 区块而不是一个，并要求下一位矿工确认所有这些区块。不再有微区块或以比特币为锚的区块；取而代之的只有 Nakamoto Stacks 区块。这将实现快速区块时间。

2. 要求质押者在下一个区块产生之前协作。 质押者需要集体验证、存储、签名并传播矿工产生的每个 Nakamoto Stacks 区块，才能产生下一个区块。质押者必须这样做才能获得他们的 PoX 支付并解锁他们的 STX（即 PoX 现在被视为矿工为其扮演这一关键角色的补偿）。在 Nakamoto 中，抽签仅选择新矿工；它不会像今天那样赋予矿工单方面使已确认交易成为孤块的权力。这将确保矿工不会制造分叉，并且能够在被选中之前确认所有先前的 Stacks 区块。

3. 利用质押者来监督矿工行为。 抽签导致质押者通过 (a) 就当前矿工的“最后签署”区块达成一致，和 (b) 同意只签署来自新矿工且从该最后签署区块衍生的区块，从而执行任期变更。因此，质押者监督矿工行为——质押者防止矿工在其任期内挖掘分叉，并确保他们在任期开始时以规范链顶为基础构建。新矿工不能使旧矿工最近确认的交易成为孤块，因为批准任期变更的签名者必然了解所有此前的 Stacks 区块。这 进一步防止矿工对 Stacks 区块链进行分叉。

4. 要求 Stacks 矿工在其提交到比特币区块链的区块提交交易中提交由上一个 Stacks 矿工产生的第一个区块的索引区块哈希（indexed block hash）。 这是 Stacks 识别的所有先前被接受的比特币交易的共识哈希以及该区块本身哈希的 SHA512/256 哈希（当前的区块提交今天只包含 Stacks 区块的哈希）。这将把 Stacks 链历史锚定到比特币，直到先前矿工任期的开始，以及 Stacks 已处理的所有因果相关的比特币状态。这 通过将分叉预防的责任交给质押者，确保比特币最终性并解决矿工连通性问题 。

5. 采用一种惩罚区块提交审查（censorship）的比特币 MEV 解决方案。 应调整 stacks 矿工赢得抽签的概率，使得比特币矿工通过省略诚实 Stacks 矿工的区块提交而获利变得不可行。其机制如下文所述。

---

---

附加资源

• [Hiro 博客] 理解 Nakamoto 在 Stacks 上的快速区块

• [Stacks YT] Nakamoto 升级后 Stacks 的下一步是什么