Over 400 subscribers
We wrapped up another @ethereum #ACDE today, covering the Pectra fork scope, next devnet specs, history expiry, upcoming breakouts, and more!
Agenda: https://github.com/ethereum/pm/issues/1052
Stream: https://youtube.com/live/A5EaPLLRsoQ
The call started with a discussion of the scope for Prague, the EL side of the upcoming Pectra network upgrade. Most teams had shared their views async before the call, with Besu, Nethermind, and EthereumJS doing so in the days/hours before the call.
Hyperledger Besu had a blog post where they supported the idea of a "mega fork" (coined by @ethPandaOps in their previous doc), which would include EOF as part of Pectra.
EthereumJS, while also supportive of EOF, feared it would expand Pectra's scope too much and proposed splitting it out from the rest of Pectra in its own fork (potentially shipping with PeerDAS on the CL side).
Nethermind had a similar view as EthJS but was less strongly inclined towards a separate fork for EOF. On the call, @URozmej emphasized that their main priority was shipping the fork rapidly, to allow the team to focus on other important roadmap items afterward.
With these, and the views shared by Reth previously, it seemed like there was broad agreement that EOF should ship prior to Verkle, potentially coupled with Pectra, potentially separate.
Geth highlighted that the Verkle Transition was already estimated at ~2 weeks, and this would keep growing as the state size increases. He questioned whether EOF was urgent enough to warrant pushing back Verkle.
Other client developers didn't seem overly concerned about the increase in transition time, saying that even if it took several more weeks for the transition, that should be fine. There was a fair amount of back and forth on this, which the recording captures well 📺
From the Erigon side, @yperbasis said he'd like to see both EOF and Verkle go live ASAP and believed that having EOF in Pectra is what would be most efficient. His view was that a separate fork for EOF would be the slowest of all options. Besu also +1'd this.
There were also Solidity and Vyper representatives on the call expressing support for EOF, with Vyper caveating that they'd prefer to see other EVM improvements around reentrancy protection prioritized over EOF.
@g11tech from the EthJS team highlighted that if we commit to EOF, we should avoid having it delay Pectra (and by extension Verkle) indefinitely.
I agreed with this. One concern I had with the "Mega Fork" is that different client teams would make progress on different EIPs, making it impossible to do proper cross-client testing until very late in the process.
My proposed solution: include EOF in Pectra, but not in the next devnet. Many spec changes came out of devnet-0 (more on that later!) and I advocated for testing these fixes in isolation before layering more complexity (and continuing the work on static EOF tests).
As we were having this conversation, @lightclients and @vdWijden from the Geth team both expressed skepticism and concern around the total size of the fork and whether EOF should be prioritized right now.
Nevertheless, we ended up including EOF in Pectra, again, with the caveat that we'll iteratively grow the scope of devnets to better coordinate cross-client testing. If, during implementation/testing, we realize EOF is blocking Pectra, we could always move it to its own fork.
But, for now, this emphasizes the need to prioritize EOF implementations and closes the door to expanding the scope of what is now clearly the largest network upgrade ever planned even further
The next biggest thing to figure out for Pectra was EIP-7702. Drafted as a replacement to 3074 that is more forward compatible with the ERC-4337 AA roadmap, the EIP was CFI'd on the last ACD. Since then, we had two breakout rooms to iron out open spec issues.
In short, teams are still unhappy with the current revocation scheme. @yperbasis left a comment about this on the call agenda. While we didn't come up with a better scheme on the call, we agreed to include the EIP in Pectra, add it to devnet-1, and keep iterating on revocation.
After this, @mkalinin2 had a few outstanding spec issues for us to go over. The first one was about handling EL-triggered requests in the Engine API. After some discussion and concerns about the interactions with EPBS, we agreed to drop the change
Next up were changes to enable EL-triggered consolidations in EIP-7251 and the Engine API:
People were generally supportive but had low context. We'll keep these open for review and tentatively include them in devnet-1.
Lastly, he highlighted a change to the semantics of deposit/withdrawal requests in the Engine API, which had already been merged. This will also be part of devnet-1.
And that was it for Pectra scope and spec changes !
You can see the changes to the Meta EIP here: https://github.com/ethereum/EIPs/pull/8627/files?short_path=ecfd0b2#diff-ecfd0b2a30ff0aa53b70f57df1b431bade81bf17b36998de841c61faefa1f7c7
Next up, @gballet raised a concern around EIP-158, which, as a mitigation to early DoS attacks on Ethereum, prevents accounts with 0 nonce/balance/code to be saved in the state, even if it has storage. With EIP-7702, this could potentially be possible.
This would be problematic for Verkle, as clearing the state of these accounts would have the same problems around fetching the state to clear that led us to deactivate SELFDESTRUCT.
Guillaume wanted to gauge whether other clients also thought this was an issue, and if it made sense to draft an EIP which would modify EIP-158 to have similar behavior as SELFDESTRUCT post-EIP-6780 https://eips.ethereum.org/EIPS/eip-6780
There was agreement we should spec this out, and depending on whether 7702 ends up being problematic or not, either couple the change with that EIP or, otherwise, with the Verkle transition.
After this, @pipermerriam came on to talk about history expiry & Portal. He asked teams about their current progress and Nethermind + Besu both shared that while they cared about prioritizing this work, there are many priorities at the moment so couldn't make firm commitments.
With about 5 minutes to go, I quickly brought up my set of proposed improvements for AllCoreDevs & Network Upgrades:
Specifically, I asked about interests on (1) moving to async EIP reviews by default and (2) introducing PFI to network upgrade planning. https://ethereum-magicians.org/t/allcoredevs-network-upgrade-ethmagicians-process-improvements/20157
No objections on the first, so we'll give it a try going forward and see how it goes
The PFI/CFI/SFI proposal also didn't have objections but given the scope of the change (and the little time left on the call), I said I'd draft a more formal proposal for people to review and comment on async.
And, lastly, @elbuenmayini had a proposal to re-organize the Eth R&D discord to better surface testing conversations: https://notes.ethereum.org/@danceratopz/testing-channels
No objections on the call, but we'll see if anyone on discord objects before trying this out.
That was it for today's call! We concluded with an announcement for tomorrow's EPBS and next week's PeerDAS breakout rooms
EPBS: https://github.com/ethereum/pm/issues/1060
PeerDAS: https://github.com/ethereum/pm/issues/1059
Lots to do in the next few weeks, and my next threaded update will be on June 20, for ACDE #190 🫡 https://github.com/ethereum/pm/issues/1066