If there is one Ethereum upgrade that has been ever a bridesmaid, it’s the EVM Object Format (EOF).
Engaged once, with plans to be married in Shanghai, it was cast aside soon after by developers swooning for a blobular future in Proto-Danksharding.
If you have no idea what that sentence means, don’t fret. It’s a metaphor for hours of discussion over years of Ethereum all-core developer calls.
Following Thursday’s ACD call, we still don’t know whether EOF will finally get a chance to be a bride. But at least there’s a clear proposal on the table.
Developers had been strongly considering EOF for the Shapella hard fork. A year ago however, after a fair bit of introspection, it was pulled in favor of keeping the focus solely on staking withdrawals.
Once Shapella had safely shipped, the candidates for inclusion in Dencun had yet again EOF among them. And again it was shelved, much to the chagrin of the feature’s two main champions, Danno Ferrin and Greg Colvin.
The consensus in April 2023 was that EOF was too big to share the stage with EIP-4844 — Proto-Danksharding — and therefore one had to go. The latter, with its potential to dramatically improve the user experience of layer-2 rollups, won out.
As a consolation, Ansgar Dietrichs at the Ethereum Foundation suggested having EOF as a focus of the next upgrade, Prague. “It’s too big to be the second place in a fork,” he said. So, it should have its own.
Dencun, with 4844 as its “driver,” remains on track for mainnet in March as developers reported an “uneventful” hard fork of the Sepolia testnet on Tuesday.
“We saw finality as well as blobs showing up exactly when we wanted them to,” said the Ethereum Foundation’s Parithosh Jayanthi.
Just one testnet, Holesky, is left before mainnet, and Dencun should be given its final test on Feb. 7.
Pushing EOF over the finish line
Most of Thursday’s call was aimed at understanding the current status of the next big feature fork. Named “Prague,” this consensus layer upgrade is titled after the location of Devcon 4. Meanwhile, “Electra” — a designation inspired by a blue-white giant star within the Taurus constellation — is the term used by execution clients to refer to the same upgrade.
The priorities for “Pectra” are slowly taking shape. Very slowly.
Ferrin once again made the pitch for EOF, calling it “existential to the EVM in the next couple of years.”
As a leader of the EOF implementers working group, Ferrin said developers “have been moving into ‘ship it’ mode.”
EOF aims to make Ethereum smart contracts more secure, efficient and developer-friendly. It’s of particular significance to Ethereum dapp developers, who don’t typically join the biweekly all-core dev calls.
That’s left some client teams with the impression that EOF isn’t important in the past, a stigma that has been hard to shake.
On the Jan. 4 call, Dragan Rakita from the Reth client team expressed strong support for EOF, and Nethermind developer Lukasz Rozmej noted EOF is a lot easier to test than Verkle trees — the main competing focus for the next fork.
Even Marius van der Wijden from Go Ethereum (Geth), previously an EOF-skeptic, sounded relatively on-board with the idea.
“I’ve been warming up to EOF, [it’s] just not a [priority] for me,” van der Wijden said.
Support built further on the Jan. 18 call. Paradigm’s Chief Technology Officer Georgios Konstantonopolous said it was “doable by one person in a couple months.”
Ferrin reiterated that sentiment on the most recent call, arguing that work on EOF and Verkle is done by different engineers within client teams, and therefore committing to it wouldn’t prevent work on Verkle from progressing.
But Guillaume Ballet, a Geth developer at the Ethereum Foundation, was not yet convinced, worrying EOF could adversely affect Verkle.
“If it does go first, I need to make sure we don’t ship something and paint ourselves in the corner realizing we broke something,” Ballet said.
Andrew Ashikhmin, software engineer on the Erigon client team, proposed to commit to EOF with the caveat that it be tried on a Verkle testnet and that there be time carved out for collaboration between Verkle and EOF implementers in the coming weeks.
It’s a bit of a chicken-and-egg problem, as Ferrin observed.
“Before we can put it in testnet in Verkle, we need it working in clients,” he said, adding that his Besu client team could have EOF up and running soon for testing purposes.
But he’s convinced it should be compatible with Verkle.
“I don’t want ‘shoulds,’ I want to see it working,” Ballet retorted.
EOF is left still trying to catch the bouquet, awaiting a suitor to walk it down the aisle.
