# Nakamoto 升级是什么？

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

在 Nakamoto 之后，Stacks 的出块将不再与矿工选举绑定。相反，矿工将按固定节奏出块，而 PoX Stackers 集合则依赖矿工选举来确定当前矿工何时应停止出块，以及新的矿工何时应开始出块。只有当 70% 的 Stackers 批准分叉时，这条区块链才会分叉，而且链重组将像重组比特币一样困难。

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

### 之前的 Stacks 出块设计

如今，Stacks 区块链按照中所述的算法出块 [SIP-001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md) 和 [SIP-007](https://github.com/stacksgov/sips/blob/main/sips/sip-007/sip-007-stacking-consensus.md)，以及 [SIP-015](https://github.com/stacksgov/sips/blob/main/sips/sip-015/sip-015-network-upgrade.md)。矿工通过由 VRF 支持的抽签（sortition）过程参与矿工选举，竞争将一个区块追加到区块链上。矿工向比特币提交一笔 block-commit 交易，该交易承诺其打算追加的区块哈希。抽签过程会在后续的比特币区块中最多选出一个 block-commit，授予提交者传播其区块并获得区块奖励的权利。

### 问题

在过去三年中，Stacks 社区已经识别出当前系统设计中的若干问题：

1. **缓慢的比特币区块、Stacks 分叉以及错过的抽签都会对链上应用造成干扰。** 在抽签选出有效矿工之后才等待生成新区块的做法，将 Stacks 出块速度的最佳情况绑定到了比特币的出块速度上，从而导致非常高的交易确认延迟。
2. **微区块并不能有效加快交易确认时间。** 虽然微区块有潜力缓解错过抽签并改善交易纳入时间，但在实践中并不可行，因为协议无法确保微区块会一直被确认，直到下一次抽签发生。此外，新矿工经常会使旧矿工最近已确认、并包含在微区块中的交易变成孤块，因为没有任何对共识至关重要的程序强制下一位矿工建立在最新微区块之上。
3. **Stacks 分叉并不与比特币分叉绑定，因此允许低成本重组** 重组 Stacks 区块链中最近 N 个区块的成本，就是生成接下来 N + 1 个 Stacks 区块的成本（即通过花费 BTC），这与重组比特币的成本相比要低得多。该 SIP 描述了一个机会，即将规范的 Stacks 分叉与比特币区块链绑定，使得重组 Stacks 链历史的行为需要 Stacks 矿工以 70% 的 stacker 签署同意来生成该分叉。
4. **Stacks 分叉源于连接不佳的矿工。** 如果一组矿工在提交 block-commit 时很难获知规范的 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. **要求 stackers 在下一个区块可被生成之前进行协作。** 在下一个区块可被生成之前，stackers 需要集体验证、存储、签名并传播矿工生成的每一个 Nakamoto Stacks 区块。Stackers 必须这样做，才能获得其 PoX 奖励并解锁其 STX（也就是说，PoX 现在被视为矿工为其承担这一关键角色而支付的补偿）。在 Nakamoto 中，抽签只会选出一位新矿工；它不会像现在这样赋予该矿工单方面使已确认交易变为孤块的权力。这将确保矿工不会生成分叉，并且在被选中之前能够确认所有先前的 Stacks 区块。
3. **使用 stackers 来约束矿工行为。** 抽签会促使 Stackers 执行一次任期变更，其方式是：(a) 就当前矿工的一个“最后签名”区块达成一致，(b) 同意只为新矿工从该最后签名区块延续下来的区块签名。因此，Stackers 会监督矿工行为——Stackers 会阻止矿工在其任期内挖出分叉，并确保他们在任期开始时建立在规范链尖之上。新矿工无法使旧矿工最近已确认的交易变成孤块，因为批准任期变更的签名者必然知晓此前所有的 Stacks 区块。这 **进一步阻止矿工分叉 Stacks 区块链。**
4. **要求 Stacks 矿工在其 Bitcoin 区块链上的 block-commit 交易中，提交由上一位 Stacks 矿工生成的首个区块的索引区块哈希。** 这既是 Stacks 所识别的所有先前已接受比特币交易的共识哈希，也是区块本身的哈希（而今天的 block-commit 只包含 Stacks 区块的哈希）的 SHA512/256 哈希。这将把 Stacks 链历史锚定到比特币上，直至上一位矿工任期开始之前，以及 Stacks 已处理的所有因果相关的比特币状态。这 **确保了比特币最终性，并解决了矿工连接问题** 把分叉防护责任交给 Stackers。
5. **采用一种会惩罚 block-commit 审查的比特币 MEV 解决方案。** Stacks 矿工赢得抽签的概率应被调整，使得比特币矿工省略诚实 Stacks 矿工的 block-commit 不再有利可图。其机制如下所述。

***

{% embed url="<https://youtu.be/zIXY_49xbIY?si=jyBrtZpZd9tC_kUE>" %}

***

### 其他资源

* \[[Hiro 博客](https://www.hiro.so/blog/understanding-nakamotos-fast-blocks-on-stacks)] 理解 Nakamoto 在 Stacks 上的快速区块
* \[[Stacks YT](https://youtu.be/Idjctsghb4s?si=Qxbzt1Md_7cPzFMV)] Nakamoto 升级后 Stacks 的下一步是什么


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stacks.co/learn/zh/block-production/what-was-the-nakamoto-upgrade.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.