以太坊当前的开发重心-煤油灯科技

以太坊当前的开发重心

煤油灯科技2023-02-03 09:19

上一篇：Ray开源机器学习框架发布2.2版本

下一篇：量子通信能否实现地外握手？

背景

我写这篇文章的灵感来自两个人：CC和Vitalik。

他们一致认为，学习以太坊的最佳方式是观看所有核心开发者会议并阅读相关的会议记录、hackmd 文档、问题和 PR 以及 EIP，直到您清楚以太坊当前的路线图，核心开发者的担忧和担忧是什么，每次升级/EIP的作用是什么等等。

除此之外，我还受到社区的启发。

以太坊拥有优秀的开源文化，可以在EF YouTube上看到所有的会议视频，以及未来讨论的议程在ethereum/pm（更多，Tim和Kim 的笔记）。以太坊开发者正在尽最大努力让社区了解以太坊当前的升级和改进。

所以我认为写这样的文章对社区是有价值的！

升级的主要内容

2022 年 9 月 15 日以太坊成功合并后，以太坊将注意力转移到后续的改进上，即上海升级（执行层）和Capella 升级（共识层）。

主要有这么几点：

信标链取款
结束符
EIP-4844
其他 EIP

他们扮演着不同的角色。信标链提款是上海升级的核心，而 EOF 只有在提款不会受到影响而延迟的情况下才会被纳入到上海升级中。(译者注：最新的 ACD 中确定 EOF 从上海升级中移除)

另外，因为EIP-4844可能会造成提款延迟，所以在上海升级时被移出了升级的范围（如果EOF延迟也会被移出）。但我们都知道 EIP-4844 是对以太坊的关键改进，因此我们将其作为下一次升级（Cancun升级）的中心。

我会分别解释相关术语和EIP。

信标链取款

理解“提款”需要对信标链的历史和演进有一个基本的了解。

信标链还没有推出

在信标链之前，以太坊是一个完整的单体区块链，它的共识引擎（PoW）和执行引擎（EVM）一起工作，没有耦合和分离。

单体链

阶段 0

信标链在阶段 0 (2020 年 12 月) 推出。

自此，以太坊由单一型区块链转变为两条平行链的结合 (即信标链和执行链)。

在它们之间通信的唯一方式就是存款合约，存入并锁定 32 个 ETH 以成为一名验证者 (这个角色类似于 PoW 机制下的矿工)。

预合并

Altair

而很快，信标链在上线两周内迎来了第一次硬分叉，也就是Altair的升级。此升级进行了一些简单的修复。（共识层升级以星星的名字命名）

Bellatrix

第二次硬分叉升级称为Bellatrix，也称为“合并”。信标链合并到执行链中。

此时，以太坊已经从两条平行链变为一条链，但有两层，即共识层和执行层。这两层通过引擎API进行通信。

总难度为58750000000000000000000，Bellatrix 升级版（CL）和Paris升级版（EL）同时上线。通过EIP-3675和EIP-4399，将以太坊的共识从PoW换成了PoS！

合并后

Capella

这是信标链的第三次硬分叉升级（以二星星命名！），也将与上海升级（EL）同步启动。通过EIP-4895，实现信标链提币到EVM。

这也是目前共识层和各个客户端团队的主要工作。升级完成后，所有验证者都可以提取自己的 ETH。Beacon Chain 中的总存款已超过15,741,431 ETH，动态验证器对以太坊的经济层很重要。

总存款

作为EVM的超级爱好者，相信很多人对EOF期待已久。几年前，有关于“以太坊账户版本控制”的讨论和改进。至此，EOF 已经成为现实，并最终确定纳入上海升级范围（事实上，EVM 自 Genesis Block 以来并没有太大变化）。

简单地说，目前的 EVM 只有一套解释和验证规则来处理所有现有的合约（我们称之为“旧式合约”）。

EOF（由五个EIP组成）引入了一种新的智能合约格式，我们称之为“ EOF合约”。而clients/EVM解释器也有相应的更新。

所以我们现在有两套 EVM 解释和验证规则，它们并行存在。EVM 将能够处理遗留合约和 EOF 合约（在更长远的将来，我们可能会用 EOF 合约替换所有遗留合约）。

为什么选择 EOF，它带来了哪些好处？

EVM 版本控制。这使得引入或弃用功能变得容易，防止 EVM 变得越来越复杂和丑陋。向 EVM 添加功能现在比删除它们更困难，而 EOF 可能会改变这一点。
新增控制流操作，完全摒弃动态跳转和运行时JUMPDEST分析，更划算。（并使代码转换更容易等）
将 EVM 在运行时验证的内容（例如 stack underflow、overflow）移至部署时。这使得 EVM 的开销更低，并使合约代码更安全（潜在的错误不会部署在以太坊上）。
代码和数据是分开的。我们将有一个可执行但不透明的代码部分和一个可读但不可执行的数据部分

另外，EOF主要由5个EIP组成，我简单介绍一下各个EIP的作用。如果你想了解更多关于EOF的知识，我建议你去看过去的讨论，比如“ EVM封装格式”和“关于EVM的一切”，以及这五个EIP（有统一规范）。这些都非常有帮助！

EIP-3540: EVM Object Format (EOF) v1
此 EIP引入了 EOF 容器并指定了所有 EOF 合约中包含的字段（您可以在此处查看完整字段）。此外，它依赖于EIP-3541，它保证在上海升级之前部署 EOF 格式合约将被拒绝。
EIP-3670: EOF - Code Validation
此 EIP基于EIP-3540并添加了更多 EOF 合约的验证规则。错误的EOF代码不能部署，你可以在这里看到所有的代码验证规则。
EIP-4200：EOF - 静态相对跳转
该 EIP引入了新的跳转指令 - RJUMP,RJUMPI和RJUMV，用于指向执行代码的相对位置。通过这个EIP，我们可以初步去除JUMPDEST分析（动态跳转，JUMP和JUMPI）。
EIP-4750: EOF - Functions
该 EIP更进了一步，它引入了“EVM 函数”的概念（它是一个独立的子程序），并介绍了调用CALLF和RETF返回 EVM 函数。通过EIP-4750和EIP-4200，我们可以完全放弃JUMPDEST分析（动态跳转，JUMP和JUMPI）。
EIP-5450：EOF - Stack Validation
这个 EIP添加了更多的验证规则，并且将 stack underflow/overflow，inefficient gas等等从运行时检查转移到部署时检查。这可以进一步减少 EVM 的开销（目前underflow/overflow在运行合约代码时由 EVM 解释器检查）。

我个人认为 EOF 是对 EVM 的重大改进，所以我希望看到它在上海升级部署（并且不延迟提款）。

对于 EOF 路线图，我们将在开始时同时保留遗留合约和 EOF 合约，然后我们可能会将现有遗留合约转移到 EOF 合约（显然不是最高优先级）。但这可能会对 zkEVM 产生一些影响。

取决于EOF 合同的数量。如果大部分合约都是遗留合约，现有的 zkEVM 不需要做太多的修改就可以兼容 EOF。
如果现有的合约全部转为EOF合约，我们需要在所有的电路中加入EOF相关的约束（比如数据和代码的分离，可能会改变现有的字节码电路）。
对于操作码，JUMP可能JUMPI会被弃用，因为 EOF 禁用动态跳转。而且根据vitalik的Proposal，CODECOPY以后CODESIZE也有可能被废弃。此外，我们需要为新的操作码编写约束（例如RJUMP, RJUMI, RJUMV, CALLF,RETF等）

但总的来说，zkEVM 总是需要随着 EVM 而变化（zkEVM 服务于 EVM），当 zkEVM 用于 Layer 1（type1）时，每次 EVM 升级也会考虑 zkEVM，同时升级（EVM + zkEVM）是可能的。所以我认为保持 zkEVM 更新没什么大不了的。

对于 EOF。未来还有很多改进，比如考虑禁止EOF代码被CODECOPY, CODESIZE, , EXTCODECOPY,EXTCODESIZE直接读取EXTCODEHASH，实现EVM版本的自动强制转换（版本n代码可以自动转换为版本n+1）。EVM 代码甚至可以转换为其他 VM 代码的等价物。

如果我们决定在未来从 EVM 更改为其他 VM（例如 WASM、Cairo……），则可以自动将 EVM 代码转换为具有等效功能的新 VM 的代码。

EIP-4844

EIP-4844完全是为 Rollups 设计的，以进一步降低数据提交和验证的成本（根据L2fee的说法，L2s的交易费用已经比 L1 便宜 4-20 倍）。

Proto-danksharding 来自proto.eth在 ETH Denver 上对Fully-Danksharding的简单实现。它比完全分片更容易实现，这对于以太坊扩展很重要。

EIP-4844虽然足够简单，但其实现仍然广泛涉及以下几个方面。