关于 EVM 对象格式（EOF）的一切
- AI 翻译官
- 更新于 2024-07-30 19:59
- 阅读 910
关于 EVM 对象格式（EOF）的一切
本文档的目的是作为 EVM 对象格式(EVM Object Format: EOF)的说明和链接集合。这是一份持续更新的文档，因此预计会有更新和更改。
请在 Ethereum Magicians 论坛上留下评论，或者在特定 EIP 的讨论 URL 上留言。
动机
目前，链上部署的 EVM 字节码没有预定义的结构。代码通常在客户端进行验证，运行时每次执行之前都会进行JUMPDEST分析。这不仅会带来额外开销，还会对引入新功能或淘汰旧功能提出挑战。
在合约创建过程中验证代码允许进行代码版本控制，而无需在账户中添加额外的版本字段。版本控制是一个有用的工具，特别适用于引入或淘汰功能，尤其是对于较大的更改（例如对控制流或帐户抽象等功能进行重大更改）。
两次硬分叉
为了确保类似于 EOF1 的代码实际上是有效的 EOF1 代码，我们必须 a）引入所有提交的合约的部署时间验证，并 b）确保在此功能在主网上启用之前不会部署任何这样的（恶意）合约。
解决此问题的方法是首先拒绝新合约的特定起始字节，然后选择不在任何已部署合约中存在的最短前缀（以此字节开头），最后将其用作 EOF 格式的前缀。这样就不可能遇到现有代码“伪装”成 EOF1 的情况。
时间表
伦敦分叉
EIP-3541已推出，拒绝任何以0xEF字节开头的新合约。在分叉块之后，我们将检查链上所有现有代码以选择前缀。
上海分叉
EIP-3540中描述的格式引入了一个简单且可扩展的容器，需要客户端和语言进行一些必要的更改，并引入了验证的概念。
它提供的第一个切实可行的功能是将可执行代码与不可执行数据分离。这种分离对于链上代码验证器（例如那些由二层扩展工具（如 Optimism）利用的验证器）特别有益，因为它们可以区分代码和数据（这包括部署代码和构造函数参数）。代码和数据的分离可以带来易用性和对这类用例的显着节省 gas 费用。此外，各种（静态）分析工具也可以受益，尽管离线工具已经可以处理现有代码，因此影响较小。
如果时间允许，我们还希望在上海包括 EIP-3670。该 EIP 通过部署时间验证代码部分，拒绝使用未分配指令或截断 PUSH 的代码，扩展了 EOF。
坎昆及以后
我们计划提供一个新的扩展，EOF2，对控制流进行全面改进。目前考虑的想法包括：
- 包括
JUMPDEST表（以避免执行时的分析）或完全删除JUMPDESTs。 - 引入静态跳转（使用相对地址）和跳转表，并同时禁止动态跳转。
- 将函数表示为单独的代码部分，而不是子程序。
请注意，其中一些是互斥的，所有这些都需要对技术复杂性、对以太坊客户端的好处以及对用户的好处进行调查。
未来的其他功能可能包括：
- 要求代码部分以 STOP 终止。（这样的假设可以在解释器中提供显著的速度改进，例如在 evmone 中看到的速度提升约 7%。）
- 任何需要多字节操作码（没有任何变通方法）的功能。
- 引入 EIP-2938 帐户抽象的特定部分，简化提案。
核心规范/说明
- EIP-3540：EVM 对象格式（EOF）v1
- EIP-3541：拒绝以 0xEF 字节开头的新合约
- EIP-3670：EOF - 代码验证
- EIP-4200：静态相对跳转
- Magicians 论坛：EOF
- PEEPanEIP 说明（2021 年 6 月）：视频 和 幻灯片
各种潜在用例
附加链接
- 原始撰写（解释了 EVM 的一些背景和动机）
- 来自 chriseth 的反馈
- 一些想法（datacopy，jumpv）
- 上海的跟踪问题
- Magicians 论坛：以太坊账户版本 包含所有/许多先前的想法和讨论的链接
实现
本文由 AI 翻译，欢迎小伙伴们来校对。
