Ethereum’s Next Upgrade To Focus on Blobs

Ethereum’s developer community has had time to recover from the Shanghai-Capella (Shapella) upgrade a little over two weeks ago. Now, they have turned their attention to planning what will ship next.

The consensus on Thursday’s bi-weekly all-core devs call, was that the upgrade, known as Cancun-Deneb — shortened to “Dencun” — will focus on a feature vital to the success of the network’s rollup-centric roadmap: proto-danksharding, the nickname for Ethereum Improvement Proposal (EIP) 4844.

Proto-danksharding introduces a new transaction type — the “blob-carrying transaction” — a temporary data storage mechanism that is expected to reduce transaction costs for users on layer-2 rollups, by orders of magnitude.

Péter Szilágyi, team lead at the Ethereum foundation, summed up the overarching view in the Zoom room: “I kind of feel that 4844 should be the thing that everybody focuses on, and the rest is ‘nice to have’.”

Szilágyi was the chief proponent of making 4844 a priority back in January, when he suggested it should take precedence over the withdrawal of staked ether in Shapella, but was overruled by his peers.

This time, he’s all but certain to get his wish. There was no disagreement that Cancun — the execution layer part of the upgrade that was the focus of the call — will have proto-danksharding front and center.

But what goes into Cancun besides 4844?

Deactivate SELFDESTRUCT

It may sound like an urgent task for your movie hero of choice, but in Ethereum-speak it’s an “attempt at getting rid of the SELFDESTRUCT opcode in order to pave the road for statelessness.”

The concept of a stateless Ethereum goes back to co-founder Vitalik Buterin’s October 2017 post. “State” refers to all the key information at a point in time for the blockchain: all Ethereum accounts, their balances, all deployed smart contracts and the storage associated with these.

A future upgrade or set of upgrades will shift responsibility for storing the blockchains full state to more specialized “archival nodes,” allowing for a much larger set of full nodes to store much less. That would make it even easier for anyone to run a node, furthering the goal of network decentralization.

For now, this precursor EIP-6780 was agreed to merit inclusion in Cancun by all client teams.

Call moderator and project coordinator Tim Beiko concluded that “clearly the self-destruct [proposal] is the second most mentioned EIP beyond 4844.”

He noted that an external auditor has been hired to ascertain whether currently deployed smart contracts could be broken by the change using on-chain data. The results are about a month off, Beiko said, yet there was no objection to making plans for the destruction of SELFDESTRUCT, and, as pseudonymous Geth developer lightclient said, “revisit it after the report comes.”

Transient storage

One EIP that was eighty-sixed from Shapella, despite being ready to go, was EIP-1153.

EIP-1153 proposes new, cost-effective ways to temporarily store data in Ethereum smart contracts, improving communication between different parts of a transaction. This update would support various applications, such as enhanced security features and streamlined token approvals.

“I don’t see much effort to push it out, so I don’t see a point for it to be delayed,” Lukasz Rozmej from the Nethermind client team said on the call.

Justin Florentine from the Besu client team said, while he would stop short of calling 1153 “a must-have,” he remained in very strong support.

EIP-1153, or “transient storage” is popular enough to have its own fan page, and was pushed hard by the Uniswap team in late 2022, in a manner that rubbed some Ethereum developers the wrong way.

1/24

TLDR:

EIP 1153 is a technical gas optimization EIP with a ton of uses written by a prominent core dev before uniswap v1 was launched https://t.co/ymuBh3xc4G

— hayden.eth ? (@haydenzadams) December 12, 2022

But, in the intervening months, the proposal has truly become uncontroversial, and Erigon’s Andrew Ashikhmin tipped the consensus in favor of its inclusion when he singled it out for endorsement on the call as “a small EIP that people are mostly in favor of.”

EOF remains a ways off

One upgrade that was originally a part of Shanghai, known as EVM Object Format (EOF), was broadly lauded by the assembled core developers, but once again considered a poor match for the 4844-centered Cancun plan — essentially reaffirming the consensus from late March.

The EVM Object Format (EOF) is an extensible and versioned container format for the Ethereum Virtual Machine (EVM) that introduces a one-time validation during contract deployment. It aims to improve code and data separation, making it easier to introduce new features or deprecate old ones.

Long-time Ethereum core developer Greg Colvin articulated the importance of getting EOF in from his perspective.

“We’ve been discussing this for 7 years,” Colvin said.

Other developers were of the opinion that EOF was “too big to be the second place in a fork,” as Ansgar Dietrichs, a researcher at the Ethereum Foundation, put it. He suggested it should be the focus of the next major upgrade, called Prague.

Danno Ferrin, principal software engineer at Swirlds Labs concurred. “As much as it hurts, I think it’s the right decision,” he told his colleagues on the call.

Beiko analogized the pair of major upgrades — 4844 and EOF — to the prior two — the Merge and withdrawals — telling Colvin, “I think the strongest commitment we can make is to have it be the main thing for the next fork, but even that is not something we can 100% commit to today.”

EOF remains a “quick follow” candidate, meaning developers would likely make it a priority within six months after Cancun.

“It’s just time,” Colvin said. “I’ve got work I’ve been wanting to do on the [Ethereum Virtual Machine] for 7 years that I can’t do until this is in.”

Source