EVM 对象格式(EOF)详解:开发者需要了解的内容
以太坊最近经历了多次升级,其中以太坊虚拟机仍然是其架构的基础。在即将到来的 Pectra 升级中,以太坊的核心开发团队已宣布同意引入 EVM 对象格式(EOF)——对 EVM 的改进,以创新和提升用户体验、开发者体验以及在 Layer 1 和 Layer 2 上的性能。
在本文中,我们将了解:
首先,让我们了解 EVM 和 EVM 字节码 的基础知识。以太坊使用 EVM 作为网络的核心组件;用高级语言(如 Solidity)编写的智能合约代码需要编译成 EVM 字节码才能在 EVM 上运行。
目前,链上部署的 EVM 字节码没有预定义结构。这意味着数据和代码在同一指令中。例如,在像 Uniswap 这样的合约中,重要的常量如费用被嵌入为字节码中的数据,与可执行代码一起。这需要在每次合约交互时进行运行时验证,导致执行过程中反复出现开销,使交易变得更慢且更昂贵。
总结一下,当前 EVM 的挑战如下:
EVM 对象格式(EOF)是一种以太坊字节码的结构化格式,它将可执行代码与数据分开,提高效率并减少开销。
EOF 通过为 EVM 字节码引入一个结构良好的格式来解决上述挑战。它将代码与数据分开,使以太坊客户端(如 Geth 或 Besu)能够在部署期间进行一次性验证,而不是在每次执行时重复验证。这个过程,特别是 JUMPDEST 分析(用于确保字节码中的有效跳转目标),消耗时间和 gas,导致交易变慢和成本增加。
现在让我们看看 EOF v1 及其 EIPs。
EIP-3540 引入了 EOF 版本 1。 EOF 容器由 header
和 body
组成,header 包含 EOF 的版本和合约的元数据,而 body 包含实际的合约字节码。通过这些组件,以太坊客户端可以更有效地组织和执行合约,而无需重复验证。
以下是 EOF 容器的示例结构化格式:
container := header, body
header :=
magic, version,
kind_type, type_size,
kind_code, num_code_sections, code_size+,
[kind_container, num_container_sections, container_size+,]
kind_data, data_size,
terminator
body := types_section, code_section+, container_section*, data_section
types_section := (inputs, outputs, max_stack_height)+
在即将到来的以太坊 Pectra 升级中,多个 EIPs 补充了 EOF 的实现,包括 EIP-7692 中的:
让我们快速分析 EOF 实现基于测试(在传统和 EOF 上)来衡量在字节码大小、gas 使用和执行时间方面对流行智能合约 UniswapV3 的收益。
EOF 显然在 gas 成本、执行速度和字节码大小方面为开发者提供了可衡量的改进,并显著提升了用户体验。要了解更多关于测试的信息,请访问完整的测试结果这里 。
注意:Solidity 编译器将很快完全支持 EOF,因此像 Hardhat 和 Foundry 这样的框架预计将通过集成 EOF 容器生成来跟进。开发者无需进行代码更改,但应保持更新以利用这些改进。
以太坊虚拟机对象格式(EOF)是 EVM 的一项进步。凭借其结构化字节码和版本控制能力,EOF 承诺在以太坊生态系统中提供更高的安全性、效率和灵活性。随着以太坊的不断发展,EOF 为网络的未来升级和创新奠定了坚实的基础。
关于 BuildBear:
BuildBear是一个专为 DApp 开发和测试量身定制的平台。开发者可以在各种区块链网络上自由构建个性化的私有测试网沙盒。在 BuildBear 上,铸造无限的原生和 ERC20 代币的自由,加上快速的交易时间(不到 3 秒!),大大增强了 DApp 开发生命周期。该平台配备了用于实时测试和调试的工具和插件,确保开发者可以轻松监控复杂的区块链交易。
与我们联系 Twitter | LinkedIn | Telegram | GitHub
贡献者:Emmanuel Antony, Dipesh Sukhani & Sana M Ummer
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!