This is a segment from the 0xResearch newsletter. To read full editions, subscribe.
During Thursday’s ACD call, Ethereum core developers confirmed their plans to implement Full EOF (EVM object format) in the upcoming Fusaka fork alongside the PeerDAS main driver. This decision, also known as “Option A” in Ipsilon’s detailed analysis, signifies a significant step towards optimizing, securing, and modularizing Ethereum’s execution engine.
EOF represents a comprehensive transformation of the EVM with the objective of enhancing its long-term performance and flexibility.
The introduction of EOF has sparked debate within the community. While Felix from the Geth team supports the more moderate Option D, his stance slightly differs from that of his Geth colleagues, particularly Lightclients.
External voices, such as Pascal Caversaccio, have expressed strong opposition to EOF, citing the unnecessary complexity highlighted in his article “EOF: When Complexity Outweighs Necessity.” Caversaccio argues that the implementation of EOF may not align with the needs of application developers and could potentially isolate the broader developer community.
Despite the dissenting opinions, key figures within the Ethereum Foundation, including Piper Merriam and Ansgar Dietrichs, alongside client teams like Besu and Erigon, continue to advocate for Full EOF. They believe that this structural reset is essential for meeting the demands of compiler authors and offers backward compatibility for developers who prefer the traditional EVM.
