Mega EOF Endgame

EOF (Ethereum Object Format) is a collection of code changes aimed at upgrading the Ethereum Virtual Machine (EVM). Ethereum's core developers discussed EOF in detail during the last week's ACD Execution Call. Alex Beregszaszi, provided an update to developers on the modifications made to EOF since December, in response to feedback from core developers and client teams.

• Possible EOF Implementation
• “Mega EOF Endgame” Specification
• Cancun or Prague
• RLP to SSZ
• Developers' View

Possible EOF Implementation

Andrew Ashikhmin from the Erigon client team suggested that EOF is too significant a change to combine with EIP-4844 in the upcoming Cancun upgrade. Ansgar Dietrichs, Ethereum Foundation Researcher, proposed that EOF should be implemented in its own hard fork after Cancun if it cannot be bundled with proto-danksharding in that upgrade. This would prevent EOF from being continually postponed.

“Mega EOF Endgame” Specification

Developers have created a detailed document on EOF titled 'Mega EOF Endgame' Spec. This document describes all the changes that were previously discussed under the titles EOF 1.1 and EOF 2.0, which do not have an EIP yet. This unified specification should be used as a guide to understand the various changes that the EVM Object Format is proposing. The individual EIPs still remain the official specification.

The updated EOF specification aims to address concerns about code and gas observability by removing them as much as possible from EOF contracts. This involves significant alterations to contract creation and the disabling or modification of several opcodes. Changes could also be made to the proposed EIP-4844 transaction type to accommodate new contract deployment constraints.

Cancun or Prague

Developers are also considering implementing an Ethereum data structure upgrade, replacing Merkle Patricia Trees with more powerful Verkle trees. The post-Cancun upgrade on the EL side is named Prague. EOF and Verkle tree implementation are EL-focused code changes that do not affect the Ethereum Consensus Layer (CL). Therefore, some developers think that EOF should be implemented with the Prague upgrade.

RLP to SSZ

Ethereum uses two serialization formats for its two underlying layers. Execution clients use RLP, whereas Consensus clients use [SSZ](/2023/01/25/why-ethereum-clients-prefer-ssz-over-rlp/ for data storage and transmission. Due to the different structured formats, it creates additional overhead and complexity. Developers are also working on upgrading the EL serialization format from Recursive Length Prefix (RLP) to Simple Serialize (SSZ).

The full migration of the EL stack from RLP to SSZ is unlikely to happen during the Cancun upgrade due to its complexity and other factors. Last week, the developers agreed to partially implement SSZ for blob transactions (EIP-4844) during the Cancun upgrade.

Developers' View

During the call, the development teams expressed general positivity towards EOF but showed skepticism about combining it with EIP-4844 in the Cancun upgrade. They discussed the possibility of scheduling EOF for the next fork while considering the impact on Verkle Trees implementation. Further discussions and detailed evaluations are needed to reach a consensus on the best way to incorporate EOF into the Ethereum network.

No consensus was reached during the meeting regarding the timing for EOF implementation or decisions on bundling EOF with other EL-focused upgrades. Danno Ferrin from Hedera Hashgraph encouraged developers to share their thoughts asynchronously through Discord and bi-weekly EOF calls.

Related Articles

• Shapella Testing
• Why Ethereum Clients prefer SSZ over RLP?
• Upcoming Changes to Ethereum Blockchain
• How Warm COINBASE helps in Gas Cost Reduction?
• Transient Storage for Beginners: EIP-1153 Explained

Related Videos

• The Future of Ethereum Goerli Testnet
• ETH Withdrawals: Everything You Need to Know
• Client Diversity
• Reth: Ethereum Execution Layer Client Written in Rust
• Sign-In with Ethereum: EIP-4361