这是 0xResearch 新闻简报的片段。如需阅读完整版，请订阅。
以太坊核心开发人员就以太坊虚拟机（EVM）的未来做出了一个关键决定：EVM 对象格式（EOF）将从即将到来的 Fusaka 分叉中删除。
经过多年的努力，EOF 在 Fusaka 范围界定截止日期之前遭遇了新一轮的攻击。最终决定被推迟到今天的互操作性测试电话会议，这将对可扩展性和开发人员体验产生广泛影响。开发人员将继续致力于 Fusaka 的 PeerDAS 和其他扩展性改进，但 EOF 的未来再次充满不确定性。
项目协调员Tim Beiko表示，这是互操作性测试电话会议首次吸引超过100名参与者，由此可见其风险所在。“一旦我们交付了产品，就无法再进行回滚，因此我们应该为此设定非常非常高的门槛，”Beiko在电话会议开始时提醒大家。尽管EOF在某些方面获得了强有力的技术支持，但由于缺乏共识，最终导致它无法与Fusaka捆绑在一起。
EOF 是EVM的升级版，旨在解决长期存在的技术债务问题。它将允许开发人员为新合约提供清晰、可验证的布局，消除不可预测的代码执行路径，并通过使合约行为更易于分析和验证来降低出现错误和安全漏洞的风险。
Geth 开发人员 Marius van der Wijden 最初是 EOF 怀疑论者，他在X 线程中回顾了自己思想的演变。
“有人说‘如果我们从头开始设计 EVM，它可能看起来像 [EOF]’，这促使我致力于此，”van der Wijden 写道。
支持者认为，这将使合约最终更容易迁移到 RISC-V 等新架构。EOF 的主要倡导者之一 Danno Ferrin 在 Interop 电话会议之前写道：“如果没有 EOF，就很难顺利实现迁移。”
缺点
最近几周，反对的声音越来越大，尤其是应用程序开发人员和 Vyper 编译器团队成员。
在周一的电话会议上，Vyper 的核心贡献者查尔斯·库珀 (Charles Cooper) 重申了他的观点，认为这甚至不应该被称为“升级”。
“如果你要破坏向后兼容性，你就不应该说这是对 EVM 的改进，”Cooper 在电话会议上说。“它就像一个新的虚拟机，应该以这种方式销售给用户，而不是告诉他们这是对 EVM 的改进，但它会破坏所有应用程序。”
Michael Egorov 的Curve 协议使用了 Vyper，他也对 EOF 背后的前提提出了类似的质疑。Egorov 告诉Blockworks：“这看起来确实像是 Solidity 编译器试图通过在 EVM 层面上做一些事情来解决技术债务。” 他警告说，增加的复杂性可能会浪费宝贵的资源，并可能降低可扩展性，因为 EOF 的优势本身就可以通过编译器改进来实现。
主流 Solidity 库（例如 OpenZeppelin 和Uniswap）的兼容性也出现了紧张局面。Ipsilon 团队的研究证实，许多库需要进行调整才能在 EOF 下进行编译。虽然向后兼容仍然可能，但采用情况可能不均衡。
Ferrin 对以太坊四大合约进行了简要回顾。他指出，如果开发者选择“方案 D”，EOF 只需进行少量修改。“方案 D ”争议较少，在保留核心结构改进的同时，恢复了代码和 gas 自检机制。
“如果我们取消 EIP-7069（Gas 自检禁令），上述大多数问题就不再是问题了，”Ferrin 解释道。他表示，这一妥协只会让 Fusaka 的 Devnet 2 计划推迟几周。然而，这最终不足以达成共识，无法纳入其中。
电话会议的其他参与者指出，作为任何过渡的一部分，许多合同可能需要重新审核，以确保在新格式下修订时完全安全。这需要花费金钱和时间。
最近几天，社区中出现了截然不同的观点。Elias Tazartes驳斥了人们对 Layer-2 解决方案难以采用 EOF 的担忧。“Layer-2 的承诺是与 Layer-1 等效，早期的基准测试表明，采用 EOF 的 EVM 比不采用 EOF 的 EVM 更容易证明，”他说道。在他看来，EOF 甚至可以提高Rollup 的效率。
Solidity 团队在会议前发表了强有力的意见，为 EOF 辩护，驳斥了外界对它的普遍批评。他们指出，EOF 的积极开发已经持续了四年多，进一步拖延开发并不能显著提升其“准备就绪”程度。
在回应对潜在中断的担忧时，他们强调，遗留合同将继续有效，并且用户可以逐步采用 EOF。
他们辩称：“EOF 不会占用扩展的时间”，并强调大多数客户的工作已经完成，现在放弃 EOF 会浪费过去的投资。关于对执行层路线图的更大批评，他们强调，未来迁移到 RISC-V不会让 EOF 过时——相反，它会让这种过渡更加平稳。
反对派
以太坊核心开发依靠粗略的共识机制，而归根结底，当涉及到 EOF 时，共识机制就显得不足了。正如 van der Wijden 所指出的：
“我们意见不合，而且我们再也无法就EOF达成一致，所以必须这么做，”他说。“我仍然很纠结，我想这次电话会议上的很多人都在两种选择之间犹豫不决——他们真的不知道哪个才是正确的决定——[但]在过去，在这种情况下，我们总是默认不做任何改变，因为那是安全的选择。”
在技术争论的背后，隐藏着更深层次的关于优先级的哲学争论。开发者们争论的是，以太坊的治理模式——仿照互联网工程任务组 ( IETF) 的模式——是否未能及早发现关键问题。
以太坊的治理有意与 W3C 的“选区优先”原则有所区别，例如，W3C 的“选区优先”原则将用户置于开发者之上。尽管在以太坊治理中，开发者的体验有时被优先考虑，但它仍力求做出务实的决策。
这是因为核心开发人员不是最终的仲裁者；每个以太坊节点运营商最终决定运行或不运行什么代码。
正如范德维登所观察到的，“丢弃好的代码会带来一些痛苦，但这不应该影响我们对以太坊的最佳选择的决定。”
Besu 客户团队的 Justin Florentine 热衷于推迟做出最终决定。
“大约一个月前，我们经过一番艰苦的努力，最终选择了方案A，现在突然改变主意，这让我有点震惊，”弗洛伦汀说。“我不知道少数人的声音是否值得倾听。”
他认为，应用程序开发者最近的反对意见应该谨慎对待。“我们是协议的管理者，必须对我们正在积累的技术债务负责并偿还，”弗洛伦汀说。“我们需要停止像产品开发者那样思考，而更多地像平台管理者那样思考。”
Beiko 在电话会议中承认了这些治理挑战，并呼吁重新考虑 EOF。
“交付错误产品的代价远高于拖延的成本，”他说。“如果我们真的想以这种方式彻底改造以太坊虚拟机 (EVM)，我们应该做的是与智能合约开发者和更广泛的工具社区合作。”
最终，虽然 Geth、Nethermind、Erigon 和 Besu 等核心开发团队对缩减 EOF 表示了不同程度的支持（而 Reth 团队则表示反对），但由于缺乏对具体前进方向的压倒性共识，这一问题难以克服。
Beiko 表示，如果要恢复 EOF，就需要对后续的硬分叉（代号为 Glamsterdam）进行新的规划流程。
Beiko 表示：“我认为社区的其他成员应该预料到，如果 EOF 被删除，开发人员可能不会那么热衷于继续致力于此，就像过去一样。”但他总结说，无论如何，这都是一个必要的风险。
因此，Fusaka 将在没有 EOF 的情况下继续推进，重点将集中在 PeerDAS 和关键的可扩展性改进上。以太坊未来的 EVM 升级方案尚未确定，但今天提出的流程问题可能会影响未来几年的发展。
在您的收件箱中获取新闻。浏览Blockworks新闻简报：
- Blockworks Daily ：解读加密货币和市场。
- Empire ：加密新闻和分析开启您的一天。
- 前瞻性指引：加密、宏观和政策的交集。
- 0xResearch ： Alpha直接发送到您的收件箱。
- 光速：所有Solana事物。
- The Drop ：应用程序、游戏、模因等。
- 供应冲击：比特币、比特币、比特币。
