合并将如何影响以太坊应用层
- ETH中文网
- 更新于 2021-12-01 19:19
- 阅读 2902
合并会有哪些影响？终端用户、智能合约和dapp开发者进来一下。
以太坊向权益证明 (PoS) 的过渡——合并——已近在眼前：开发测试网正在被建立、规范正在被敲定，社区宣传也已经实打实地开展了。合并的设计就是希望以太坊以对其终端用户、智能合约和 dapp 带来最小影响的方式运行。也就是说，还是有一些小变更是需要强调的。在我们深入这些变更之前，读者可以通过以下几条链接了解整个合并架构的背景知识：
下文的内容将假设读者已经熟悉了上面的背景知识。对于那些想更深入了解的读者，下面的链接提供了合并的完整规范：
区块结构
合并后，工作量证明区块将不再存在在网络上。相反，之前工作量证明的内容会变成在信标链上创建区块的组成部分。你可以把信标链想作成为以太坊的新权益证明共识层，取代了之前的工作量证明共识层。信标链区块将包含 ExecutionPayloads (执行数据) ，这是当前工作量证明链在合并后的等同物。下图展示了这种关系：
对于终端用户和应用层开发者，这些 ExecutionPayloads 就是与以太坊交互的地方。在这一层的交易将仍然由执行层客户端 (Besu、Erigon、Geth、Nethermind 等) 处理。幸运的是，考虑到执行层的稳定性，合并只会引入最小的破坏性变更。
挖矿 & Ommer 区块字段
合并后，之前工作量证明区块头包含的几个字段将不再被使用，因为它们与权益证明不相关。为了尽量减少对工具和基础设施的影响，这些字段都会设为 0，或它们的数据结构等同物，而不是完全从这个数据结构移除。区块字段的完整变更可以查看 EIP-3675。
们的数据结构等同物，而不是完全从这个数据结构移除。区块字段的完整变更可以查看 EIP-3675。
| 字段 | 常数值 | 注解 |
|---|---|---|
ommers |
[] |
RLP([]) = 0xc0 |
ommersHash |
0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347 |
= Keccak256(RLP([])) |
difficulty |
0 |
|
nonce |
0x0000000000000000 |
因为权益证明本身不会像工作量证明那样产生 ommers (即叔块)，在每个区块里的 ommers 列表将是空的，而它的哈希值 (ommersHash) 将会变成一个空列表的 RLP 编码哈希值。同样，因为 difficulty 和 nonce 都是工作量证明的特点，这些字段都会被设为 0，同时遵守它们以字节大小为单位。
mixHash 是另一个挖矿相关的字段，这不会被设为 0，而会包含信标链的 RANDAO 值。下文将会更详细地说明。
BLOCKHASH 和 DIFFICULTY 操作码变更
合并后，BLOCKHASH 操作码仍可使用，但由于它不再通过工作量证明进行哈希产生，所以此操作码提供的伪随机性将大大减弱。
与此相关， DIFFICULTY 操作码 (0x44) 将会更新并重命名为 RANDOM。合并后，它将会返回由信标链提供的随机性输出。这个操作码将因此成为应用开发者可以使用的随机性来源，它比 BLOCKHASH 更强，尽管仍有偏差。
RANDOM 公开的值将存储在 ExecutionPayload ，这也是 mixHash (一个与工作量证明计算相关的值) 存储的地方。数据的 mixHash 字段也将被重命名为 random。
下图解释了合并前后 DIFFICULTY 和 RANDOM 操作码的工作原理：
合并前，我们看到 0x44 操作码返回区块头里的 difficulty 字段。合并后，重命名为 RANDOM 的这个操作码指向在区块头里之前包含 mixHash 而现在存储来自信标链状态的 random 值的字段。
这个变更在 EIP-4399 被形式化了，同时也给链上应用提供了评估合并是否已经发生的方法。该 EIP 是这样写的：
此外，此 EIP 提议的变更使得智能合约可以确定以太坊是否已经升级到 PoS。这可以通过分析返回的 DIFFICULTY 操作码来实现。返回的值大于
2**64就表明交易正在 PoS 区块上执行。
出块时间
合并将影响以太坊上的平均出块时间。目前工作量证明机制下，平均每 13 秒出一个区块，实际出块时间有相当大的差异。在权益证明机制下，精确地每 12 秒就会出一个区块，除非是由于验证者离线造成错过了一个 slot 或它们没有即时提交区块。实际上，目前这种情况在少于 1% 的 slot 里发生。
这意味着网络上的平均出块时间减少了 1 秒。在计算中假设一个特定平均出块时间的智能合约将需要考虑这一点。
安全头块和最终敲定区块
在工作量证明下总是会有出现重组的可能性。应用通常会等待几个区块在一个新的区块头被挖出，因为这样这些区块不太可能从权威链被移除，或等区块被”确认“。合并后，我们有了”finalized blocks(最终敲定区块)“ 和”safe head (安全头块)“ 的概念。这些区块比工作量证明下的”被确认“区块更可靠，但理解上有区别，需要转变理解才能正确使用。
一个最终敲定的区块意味着它被大于 2/3 的验证者接受为权威链的一部分。一个攻击者如果要创建一个冲突区块，它必须烧毁至少总质押金额的 1/3。在写这篇文章时，这意味着在以太坊上超过 100 亿美元 (超过 250 万个 ETH)。
一个安全头块是指在正常的网络条件下，我们预期会被包含在权威链上的区块。假设网络延迟少于 4 秒，大多数验证者是诚实的且在分叉选择上没有攻击，安全头块将永远不会有孤块。这个演示文稿详细分析了在各种情况下是如何计算安全头块的。此外，安全头块的假设和保证都将在即将发表的论文里得到正式定义和分析。
合并后，执行层的 API (例如 JSON RPC) 将在询问 latest (最新) 区块时默认返回安全头块。在正常网络条件下，安全头块和真正的链头是互相等同的 (安全头只落后几秒)。安全头被重组比现在工作量证明的 latest 区块被重组的可能性要低。如果要公开权益证明链的真正链头，将会有一个 unsafe (不安全) 的标记添加到 JSON RPC 中。
最终敲定的区块也将通过 JSON RPC 公开，会有一个新的 finalized 的标记。这些都可以用作比工作量证明中的确认更强的替代品。下表对这些内容进行了总结：
| 区块类型 | 共识机制 | JSON RPC | 重组的条件 |
|---|---|---|---|
| head (区块头) | Proof of Work | latest |
可能性较高，必须谨慎使用 |
| head (区块头) | Proof of Stake | unsafe |
可能性较高，必须谨慎使用 |
| safe head (安全头块) | Proof of Stake | latest |
可能，但需要严重的网络延迟或网络攻击 |
| confirmed (被确认的区块) | Proof of Work | N/A | 不太可能，需要大部分的算力去挖一条深度大于确认区块的竞争链。 |
| finalized (被最终敲定的区块) | Proof of Stake | finalized |
极不可能，需要大于 2/3 验证者来最终敲定一条竞争链且会有至少 1/3 的验证者会被罚没。 |
后续计划
我们希望这篇文章能帮助应用开发者为备受期待的权益证明的到来做好准备。在接下来几周里，一个长期的测试网将会推出，让更广泛的社区参与测试。还会有关于基础设施和工具的合并社区会议，应用开发者可以提问并了解关于合并的最新技术。到时见👋🏻
感谢 Mikhail Kalinin 提供关于“安全头”部分的核心内容，感谢 Danny Ryan 和 Matt Garnett 对本贴草稿的审阅。
ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系eth@ecn.co进行授权。
本文首发于：https://news.ethereum.cn/Eth1.x/how-the-merge-impacts-app-layer
