Skip to content

Conversation

timbeiko
Copy link
Contributor

On "ACDT" 34, a decision was made to remove EOF from Fusaka.

The process here was highly unusual. I encourage people to listen to the full discussion. Here are the reasons why I think this is the correct outcome, despite several client teams expressing support for EOF:

  1. Risks to Fusaka timelines: all client teams, ELs included, seem to agree that shipping PeerDAS ASAP is Ethereum's most important priority. While this wasn't a major topic of discussion on the call, it's worth acknowledging that debating variants of the EOF spec at this point affects our ability to ship. As we move towards Fusaka devnets, and coupling EL & CL changes, keeping EOF would increasingly become the default path. While there are ways to mitigate this risk, such as the modular EOF devnets proposed by the EIPs' champions, it is nevertheless a risk, and one we should only take if we feel the payoff is significant. Points (2) and (3) below make me question this.
  2. Technical uncertainty about impact: while there seemed to be broad support on the call towards the Option D variant, midway through, some participants realized that they did not understand the implications of this variant. Reasoning about the implications of an EIP's semantic change should ideally happen much earlier in the process. Had another EIP with similar levels of open questions been proposed on today's call, ACD would have rejected it without hesitation.
  3. Process considerations: last but not least, I think the entire EOF inclusion debate has shown failures in ACD's prioritization process. While core devs originally agreed to ship EOF (many times), at each occasion, many prominent community members raised objections to it. While, individually considered, it didn't seem like any of these concerns warranted EOF's removal, zooming out, it's clear that ACD's feedback loops failed at addressing these concerns.

Given the above, and the intention to reconfigure AllCoreDevs for Glamsterdam, it seems right to remove EOF from Fusaka while leaving the door for its champions to present a case for it in Glamsterdam, where hopefully the process begins by assessing what the highest impact changes for Ethereum as a whole are.

My apologies to everyone who has sunk more time into this than they should have because of the process failures. I hope we can learn from this to improve how we plan upgrades going forward 🙏 !


Minor note: I left PAY as CFI'd as people expressed wanting to include it in Fusaka independent of EOF. If that's not the case, we can fix this on the next ACDE.

@timbeiko timbeiko requested a review from eth-bot as a code owner April 28, 2025 18:15
@github-actions github-actions bot added c-update Modifies an existing proposal s-draft This EIP is a Draft t-meta labels Apr 28, 2025
@eth-bot
Copy link
Collaborator

eth-bot commented Apr 28, 2025

✅ All reviewers have approved.

@eth-bot eth-bot changed the title Remove EOF from Fusaka Update EIP-7607: Remove EOF from Fusaka Apr 28, 2025
@eth-bot eth-bot enabled auto-merge (squash) April 28, 2025 18:16
Copy link
Collaborator

@eth-bot eth-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All Reviewers Have Approved; Performing Automatic Merge...

@eth-bot eth-bot merged commit 1c702d9 into ethereum:master Apr 28, 2025
13 of 16 checks passed
Copy link

The commit cf1fca0 (as a parent of 9a725dd) contains errors.
Please inspect the Run Summary for details.

@github-actions github-actions bot added the w-ci Waiting on CI to pass label Apr 28, 2025
@jochem-brouwer
Copy link
Member

Hi Tim, yes, regarding PAY, I am one of these persons who want it in Fusaka. An extra reason why we should add it is because of shipping 7702 in Prague. See my open PR: #9590

Super happy to see you removed it from the EOF-CFIs but kept it on the general CFI list 😄 👍

@gcolvin
Copy link
Contributor

gcolvin commented Apr 28, 2025

The process here was highly unusual.

Not really. The precedent was set years ago.

@Pmatt328
Copy link

Don't PeerDAS stil need around six month to be ready? If so this feel premature and forced

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c-update Modifies an existing proposal s-draft This EIP is a Draft t-meta w-ci Waiting on CI to pass
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants