ACDC #154: Insights
Creating consensus
Good evening,
Yesterday, Ethereum developers agreed to push back the Pectra mainnet activation date by a week and strongly consider expanding the scope of the Fusaka upgrade. Neither of these decisions was surprising. They also don’t matter much as the work to finalize Pectra and the scope of Fusaka depends on other more important milestones and decisions.
Below are my takeaways from the latest All Core Developers (ACD) call, ACDC #154.
Yours Truly,
Christine D. Kim
April 30 → May 7
Ethereum developers have pushed back the timeline for Pectra mainnet activation by one week. More importantly, this means that the deadline for final client releases for Pectra has also been pushed back from April 14 to April 21.
The timeline shift is minor, which may give the impression that the additional testing client teams want to do for Pectra is minimal. After all, if any critical testing were still needed for Pectra, one would think client teams would have waited for these results before deciding on a mainnet upgrade date. Also, this was the sentiment shared by one of the developers on yesterday’s call regarding additional testing for Pectra related to validator attestations.
“At the end, what we have now is still okay. We are just working on improvements on the attestation pool that can anyways be shifted a little bit later and we can definitely provide an early version with what we have now that is fully Pectra compatible.” - Enrico Del Fante, Teku client developer at Consensys
However, based on the hesitation and lack of consensus among client teams for any client release deadlines earlier than April 21, it was clear that for some teams, the additional week is essential for important last-minute testing and checks. The proposed week, initially suggested by the Lighthouse client team, does not seem to be the most time needed for all client teams to adequately prepare for Pectra but the least.
So, my take on this minor date change to Pectra is that client teams' readiness for Pectra is currently mixed. Some are ready, and others are not. Developers are hoping the additional week will be all that is needed for any client teams (and applications, for that matter) that are not ready for Pectra to get ready.
PeerDAS + 2
The two EIPs that developers agreed on yesterday’s call to strongly consider for implementation in Fusaka are EIP 7892, blob parameter only hard forks, and EIP 7917, deterministic proposer lookahead. What’s notable about these two EIPs are that they are consensus layer (CL) focused EIPs. They are the first CL focused EIPs that developers are considering for inclusion in the upgrade alongside PeerDAS. PeerDAS represents a major improvement to the scalability of Ethereum’s blob capacity and it is the most important code change that developers want to ship in Fusaka.
Developers have committed to shipping PeerDAS in the Fusaka upgrade as soon as it is ready, which has made developers cautious about including any other CL focused code changes that may potentially delay PeerDAS. Yesterday’s summary includes more information on what these EIPs do but in short, EIP 7892 is a code change that would enable developers to make incremental increases to blob capacity in an automated fashion. This may be a safer way for developers to scale blobs shortly after PeerDAS activation and allow developers to set more ambitious targets for blob capacity increases post-PeerDAS. EIP 7917 is a code change that supports the adoption of based rollups.
The common denominator for both EIPs is that they are important EIPs to Ethereum’s rollup-centric roadmap. If ever you were in doubt about developers’ commitment to rollups, note that the only code changes they are considering in Fusaka beside PeerDAS are EIPs that extend the benefits of PeerDAS further for rollups on Ethereum.
Creating consensus
One part of the call I found particularly notable was when the chair of the call, Alex Stokes, was moderating decisions about the scope of the Fusaka upgrade. Six EIPs were mentioned on the call for Fusaka, and only two EIPs were formally CFI’d or “considered for inclusion.” How did this happen? In my call summary, you’ll notice paragraphs with similar language. For example:
Stokes asked if EIP 7892 should be CFI’d. There were no responses on the call. Stokes said that he would assume the silence as an agreement to CFI EIP 7892.
There are many paragraphs like this in the call summary but note how the outcomes of decisions differ depending on Alex’s interpretation of the silence on the call. When Alex asks a question on the call, he is already usually leaning toward an answer, and most of the time, because no strong opinions are shared, he will move forward with making a call based on what he thinks is best or reflective of general call participant opinions and views. Of course, at any point, call participants can speak up to push back on any decisions they disagree with.
ACD call chairs frequently propel decision-making on ACD calls. They behave like a forcing function for decision-making about the Ethereum protocol. Thus, being an ACD call chair or moderator is an extremely important but also difficult role as the role is not just about facilitating discussion but also trying to create consensus.
That’s all for my takeaways on ACDC #154. I hope you’ll join me again next week for more insights on Ethereum protocol development and governance. Below are links for further reading on other topics related to the Ethereum protocol.
Reconfiguring AllCore Devs: Tim Beiko, the Chair of the ACDE calls, has outlined a new structure for improving the ACD calls. It involves reorienting the ACDC and ACDE calls to focus on scoping upgrades and a new call series, the ACDT calls, to concentrate on shipping upgrades.
Ethereum Foundation Protocol Research Call #1: A new Ethereum Foundation-led call series kicked off this week. It’s hosted by Ethereum Foundation Research Co-Lead Barnabe Monnot and will feature discussions among various Ethereum stakeholders about the future of the Ethereum protocol.
Erigon Client Ready for History Expiry: Erigon developer Giulio Rebuffo announced that the Erigon client is ready for history expiry on Ethereum and shared early statistics on how it improves client performance.
Lighthouse Client Security Advisory: Sigma Prime, the company that develops and maintains the Lighthouse client, announced a mandatory upgrade for all node operators running the latest version of their Electra client release.
