Dencun and EIP-4844 went live on March 13, producing incredible cost reductions for Layer 2s. Dencun Diary is a compilation of +45 core Ethereum contributors looking back on the last two years, and looking ahead to what’s next. This piece features client developers, researchers, and coordinators from 28 different teams.

We hope you enjoy the sentiment snapshots from this time - thank you for reading and being part of the Ethereum story!

Stateful Works creates cultural artifacts for the Ethereum community - see previous versions of this type of project with Merge Manual and Beacon Book.

Also be sure to check out the mint for Delivery at Dawn | a 4844 film! The film celebrates EIP-4844, core dev stewardship, & positive sum L2s! Mint proceeds go towards production costs (20% to Nouns) and Protocol Guild (80%): a collective of Ethereum core contributors.

https://opensea.io/assets/0x72d07BeEBB80f084329Da88063F5E52f70f020A3/1

Responses were collected in February and March 2024, both before and after the upgrade. Respondents may have not answered all prompts. While all core contributors were invited, only a subset submitted to be included. If you intended to submit but were not able to before publishing, please reach out to Trent. Perspectives should be taken as the opinion of the individual, not necessarily that of all core contributors or their respective organizations.

🡰 Looking back 2 years on Dencun, 4844, KZG Ceremony, or other research tracks

a. successes: What has the core protocol community done well? Consider timelines, mainnet incidents, deciding priorities, managing scope, coordinating on ACD, etc.

b. improvements: What should the core protocol community have done better?

c. contributions: Do you have any contributions you are particularly proud of?

d. challenges: What was the most challenging project you worked on? Impossible bugs, unexpected complexity, failed experiments.

e. kudos: Is there someone whose work you particularly appreciated, or you feel went above and beyond? What did you specifically appreciate about their contribution?

Looking forward 🡲

f. priorities: Which protocol improvements should be prioritized in the near, medium, and/or long term? Why?

g. improvements: What should the core protocol community do to improve our processes in bringing future upgrades to mainnet?

• Lighthouse

• Client Implementer

🡰 Looking back

a. successes: Amazing co-ordination and huge efforts from all teams on testing, making sure everyone is up to scratch for mainnet.

b. improvements: As always with a large group of people, coming to consensus on priorities and timelines, but it's to be expected.

c. contributions: I wrote a production version of a gossipsub upgrade called episub to improve network-wide transmission of blobs. In its current form, we've decided not to add it to production. However, we're adding smaller modifications/improvements and perhaps a future fork will contain something resembling episub.

d. challenges: Simulating and modelling the network dynamics of mainnet. We tried big-block experiments to estimate how large amounts of data transmits through the mainnet network and we built simulators that model large scale networks. In my opinion, it was one of the most difficult tasks to try and estimate how a large network-wide change will affect a currently operating real-world large scale distributed network.

e. kudos: Sean and Pawan from the Lighthouse team. Among the many upgrades in the Lighthouse code that needed to be modified for the fork, one was the syncing algorithm. This is notoriously difficult to understand and debug. These two not only updated this part of code but rigorously tested it and ironed out all of the bugs, which was an amazing feat.

Looking forward 🡲

f. priorities: There are a lot which are in active discussion. Aside from Data Availability Sampling (which we are currently actively working on) I'm just going to mention my support for increasing the max effective balance. I think, perhaps the mid-term we should work on increasing the max effective balance, because it will have amazingly positive consequences at the networking layer by reducing validator count. This means fewer messages, less load and less bandwidth on the network. This allows home stakers to use less-powerful PC's, gives a greater margin of error when introducing larger messages in upgrades, and potentially paves the way for smaller epochs (the holy grail being single slot finality).

g. improvements: We are shipping forks. Seems to be working from my point of view. Don't fix what's not broke :)

• EF DevOps

• DevOps

🡰 Looking back

a. successes: From ACD to the KZG ceremony, coordination and communication of the core protocol community has always impressed and inspired me.

c. contributions: Being able to use our Ethereum network monitoring tool Xatu for big block testing to help prepare for 4844.

d. challenges: Forky, our fork choice explorer, was definitely a challenge for my meagre frontend skills.

e. kudos: Mario Vega, always working hard behind the scenes to make sure this train stays on the tracks.

Looking forward 🡲

f. priorities: PeerDAS in the near for scalability, Verkle in the medium for statelessness and Account Abstraction for user experience.

• Consensus R&D (EF)

• Cryptography/security

🡰 Looking back

c. contributions: I have thoroughly reviewed the cryptographic code relevant to the ceremony and the KZG commitment scheme,

e. kudos: I am impressed how such a complex piece of cryptography was implemented so smoothly.

Looking forward 🡲

f. priorities: I believe that delivering full data availability sampling (DAS) is pivotal for the future of Ethereum.

• EF DevOps

• Devnet launcher

🡰 Looking back

a. successes: Speccing out different EIPs, and iterating over different features requests as they came in. We had 12 different devnets and each of them was more and more featureful. I really enjoyed working together with all the different client teams, and was very happy to see a new one rise up from 0 to hero (reth).

b. improvements: Decision making about which EIP to include and which one to leave out for next fork needs to happen more firmly. There were a lot of EIPs that were up in the air for a long time. And now I'm seeing the same for Electra. I feel like we should have a very well defined path going forward with concrete plans for the next 5 years. And what we have currently, is more like a concrete plan for the next 6 months (not even that right now).

I think a well defined path for the next updates would give a better indication for the client teams too, so they would know what work to prioritize and what is important.

c. contributions: I've personally been putting a ton of effort into improving kurtosis. Currently it's able to spin up a new devnet in under a minute; sync up a public testnet; create a shadowfork; create verkle shadowforks (currently WIP), all while supporting the standard set of known toolings, like forkmon, ethereum-metrics-exporter, xatu, blobscan, blockscout etc.

I really hope to see more client teams getting involved with this, and integrating it to their CIs one way or another.

d. challenges: None of the projects were very challenging per say, but we had a lot of work on getting our workflow adjusted to our needs.

e. kudos: My whole team, ethpandaops and g11tech from Lodestar, who was always the first one to have an image ready to test for whatever new feature we wanted to onboard. But I have had a great time working together with everyone throughout the whole year, in person and in the digital world.

Looking forward 🡲

f. priorities: I'm just here to test lol. I let protocol changes be decided by those that understand it all.

g. improvements: We need to have better timelines, and more defined timelines for future forks, potential inclusion of future EIPs. I would like to see a 3-5 year defined timeline, and a EIP list for all the upcoming forks. Nothing needs to be written in stone, but would be a very good indication of where our priorities stand.

• Robust Incentives Group

• Team lead + Research scientist

🡰 Looking back

a. successes: Scaling has been well-prioritised as an existential concern for Ethereum, and 4844 appears to arrive at the right time when the pressures of the current network to serve existing rollups are more apparent. Research has also delivered answers on many important questions, including staking, PBS/MEV, cryptography.

b. improvements: It always feels like we should want the hard forks to be done earlier, but it is hard for me to pinpoint exactly where time could have been better spent. From a research perspective, in hindsight, more energy could have been spent on staking economics and less on PBS/MEV.

c. contributions: (1) Seeing like a protocol This post has been important to orient my contributions to Ethereum and frame them in the larger context of development. (2) Unbundling PBS: Towards protocol-enforced proposer commitments (PEPC) It's still unlikely to see a general PEPC become enshrined, but its main ideas seem to have percolated widely, and resonated with many who work on markets related to Ethereum. (3) Timing games paper From an ethresearch post to a "RIG Open Problem" to a paper to seeing it happen on mainnet — never a dull day in research, what can I say! Not an easy lift, but props to Caspar also for his tireless advocacy.

d. challenges: We tried for a while as a team to solve a difficult model of the PBS auction. In the end, though we didn't have a crisp result, my impression is that we still learned a lot, and got good material out of it for follow-ups or other projects. Julian gave an excellent talk about some of these efforts at SBC, A Dynamic Auction Model for PBS.

e. kudos: I will take the easy way out and not be specific: Anyone who joined EF research in the last two years has brought new energy and new ideas, and I would assume it's the same on the development side. Grateful that our space still attracts bright minds!

Looking forward 🡲

f. priorities: In my opinion, we should be looking to a near-ish future where shipping protocol updates is much more difficult, so we should be aggressive in terms of our updates, privileging "endgame" solutions that preserve optionality, and being comfortable with possible incompleteness. Some ideas that fit the bill are single-slot finality, full Danksharding, execution tickets, censorship resistance gadgets and a holistic review of staking UX, including the reward curve.

g. improvements: We've generally felt in our team that we should get closer to the development process, we're still looking for ways to do that but it doesn't feel like a bad idea regardless to bridge the gap more between research and development. I would also be in favour of any initiatives to bring in more eyes on critical upgrades, via grants, requests for comments or any other programmes, this seems like an unequivocally good thing.

• Teku

• Consensus client development

🡰 Looking back

a. successes: Well, we made it :) The challenge of coordinating across so many researchers, developers and other ecosystem stakeholders is immense. And all done in a fully non-hierarchical, entirely collaborative way. It really shouldn't work at all. But I continue to be impressed and delighted that our methods keep delivering - it is truly Ethereum's super-power.

A particular shout-out to those running testing infrastructure - the devnets, the shadow forks and all that. I feel like our ability to test upgrades at scale has levelled-up considerably, largely thanks to the spectacular EF Devops crew.

b. improvements: Timelines, as ever, were difficult. In late 2022 we fought off pressure from the L2s in order to prioritise delivery of withdrawals (Shanghai-Capella) by suggesting that EIP-4844 (Cancun-Deneb) would be a "fast follow-on" in mid-2023. That was fanciful, and we probably knew it was fanciful. However, we just about got away with it thanks to a lucky summer and autumn of low gas prices on Ethereum Mainnet, which markedly reduced the urgency.

We also had changes along the way. In January 2023 we decided to decouple the blobs from the blocks for better propagation. This was the right thing to do, but probably added a few months to the overall timeline. In late 2023 we modified the design to include the block header in the decoupled blobs. Again, the right thing to do - a "no brainer" - and a relatively minor change. But it was disruptive coming so late, and delayed deployment to testnets. In hindsight, we should have spent more time thinking through blob-decoupling back at the start of the year.

c. contributions: As a weekend project back in 2021 I wrote some data availability sampling demo code (c-kzg) in C, guided by a Go implementation that Protolambda had done. This got adopted and transformed into the "official" c-kzg-4844 library that some clients are using now. Most of my original code has been stripped back (it was for a full dank-sharding demo), but my bindings for the blst crypto library survive!

Looking forward 🡲

g. improvements: Fork early and fork often.

• Consensus R&D (EF)

• researcher

🡰 Looking back

c. contributions: The KZG Ceremony worked really well. Porting over the approach of starting with a (maximally) simple specification, which allows for many implementations of a piece of software. This is a guiding ethos of the consensus specifications and is a driver behind us having so many consensus clients. In much the same way, the kzg-ceremony-specs allowed for 9 different KZG ceremony clients, massively reducing the chances for a coordinated failure.

d. challenges: Trying to debug code around the KZG ceremony. Cryptography is uniquely annoying to debug: when things don't work, you just get "hex-string A does not match hex-string B" and the only way to debug is to think through the algorithm, the brute-force printing intermediate just leads to more meaningless hex-strings.

e. kudos: Trent Van Epps was my partner in crime in coordinating the KZG ceremony. He was instrumental in keeping things moving forward while I got stuck in the weeds. His designs for the website at ceremony.ethereum.org really captured the spirit of the ceremony.

Looking forward 🡲

f. priorities: PeerDAS and similar scaling infrastructure. 4844 and blobs are great, but should we start to see decent adoption of rollups, 4844 blobs will very quickly prove inadequate and L2 transaction pricing will go through the roof.

• Consensus R&D (EF)

• research/spec

🡰 Looking back

a. successes: security. Ethereum remains very secure with unmatched uptime. This is the confluence of many factors, including the diverse range of expertise, the multi-client/spec-first approach, testing, devops, and ultimately the "we have to do it right" (at almost any cost) attitude.

b. improvements: We waffled a couple of times on decoupling blobs. I pressured them to start decoupled, I then campaigned for the re-coupling at devcon bogota, and then finally they were re-decoupled at the impetus and compelling arguments of Jacek at interop-austria. Decoupled was the correct path, but oscillating here cost us.

In this same domain, gossiping headers along with blobs to inherit slashability of duplicate blob p2p messages was such a beautiful and obvious solution. But no one thought about it until Francesco poked his head in. It's not clear exactly how to have expedited this serendipitous moment, but we would have been much better off having had it 12 months prior...

c. contributions: I'm pretty sure I was the first one to discuss the abstraction of is_data_available() being the path to synergize 4844 with "full danksharding". This made its way into the spec and imo is the proper abstraction/way to think about upgrading the data layer. Nothing crazy, it likely would have happened without me.

e. kudos: Codex has been working on DAS research for the past year. They really stepped up and went above and beyond in the mainnet big-blocks analysis which was very impactful in picking the safe 4844 mainnet parametrization. Huge shoutout

Also big shoutout to Mario and the EF testing team. Testing networking is very difficult and their infra has evolved in great ways to not only test 4844 but many of the future networking challenges.

Looking forward 🡲

f. priorities: PeerDAS. Ethereum has global, secure scale within reach. Getting PeerDAS out is a clear and actionable way to achieve it.

• Lighthouse

• Client implementer

🡰 Looking back

a. successes: Execution of the roadmap in parallel to reach the endgame faster :) All the "urges" have been on heavy parallel research for a while, now it's time for implementors to become highly multi-core

b. improvements: Engage with tail-end topics like economic policy or EIP-7514 sooner. Focus tends to be gobbled by the main features causing rushed decisions at fork deadlines.

e. kudos: It brings me great peace of mind to know that Francesco is around making sure that our EIPs don't introduce sneaky consensus risks.

Looking forward 🡲

f. priorities: With a solid danksharding spec widely accepted by the community, there's a lot of energy and momentum to bring it to reality. By far the best return-on-investment ticket on our roadmap menu.

g. improvements: Now we are a 150 strong core dev force, so we could aim to be more ambitious and deliver forks in a stable frequent cadence.

• Reth

• client implementer

🡰 Looking back

a. successes: enjoyed it

b. improvements: nothing

c. contributions: working with Michael Sproul on lh db code was really great, he's a great mentor

d. challenges: everything can be solved, doing it as minimally as possible is the challenge, and to do so one must relax for starters. a stressed mind builds clutter.

e. kudos: Michael Sproul's pr reviews - they're so accurate they gave the rest of the lh team the ability to work with 'fearless concurrency'.

Looking forward 🡲

f. priorities: projects lead by Felix Lange should be allocated resources, in terms of core dev man power! network design needs more love, from someone with expertise.

g. improvements: nothing

• EF Security

• Security Researcher

🡰 Looking back

a. successes: The collaboration and team spirit of everyone involved in this process never ceases to amaze me. People are always more than happy to jump on a call to help solve an incident, or provide valuable feedback and help each other even though people are working on different types of implementations. I believe that this successful collaboration is one of the most important aspects which makes it possible to successfully coordinate with regards to deciding priorities and scope to ensure new hard forks can be shipped within a reasonable time.

b. improvements: One of the most common issues is keeping up with timelines. While there is often no hard timeline decided for when something is to be shipped, there is often a soft timeline. Given the additional complexity and increased efforts in security, testing and more, it's not too surprising things are taking longer to complete. I believe that trying to ship less features in each hard fork and at a more frequent rate could be beneficial.

c. contributions: I would certainly say that the main thing I'm proud of is what we have all accomplished as a group. From a security point of view, some of the contributions that I'm very happy that I had the honor of being part of is starting up the Client Security Calls which is being used to help coordinate security amongst the different client teams, coordinating grant work to help provide funds to security researchers looking to do various security projects, helping to coordinate security audits on 4788, lodestar, AA, KZG and additional projects. I've also worked with various ecosystem public good projects such as the Security Alliance to help increase security for the ecosystem, providing help to the Ethereum Protocol Fellowship and Devcon Scholars Program for people interested in Protocol Security.

We also set up dedicated fuzzing infrastructure that is being used to fuzz everything from clients, networking, kzg, critical dependencies and more. The output of this work has resulted in many issues which were possible to be corrected before hitting mainnet.

The bug bounty program also saw it's most successful year so far with regards to paid out rewards. After the Dencun hardfork, we will as always publish a public disclosure of the vulnerabilities found in the previous hardfork.

d. challenges: Given the many supply chain attacks that have happened around the world these past years, I spent quite a bit of time researching the potential impact various dependencies could have on the Ethereum network if they had vulnerabilities in them that could be exploited. And given the number of Execution and Consensus clients, each with a wide range of dependencies which in turn have subdependencies -- sometimes it seems like a never ending tree, but it's a continued effort.

e. kudos: I'm honestly equally appreciative to everyone involved in this process. It's obvious that this is more than a job to people, and everyone is always doing their best which for some is taking on a more public role and for some to really dig down into something technical. To me, everything is equally important and works as a symbiosis.

Looking forward 🡲

f. priorities: One of my highest prioritized protocol improvements are related to MEV. Exploring potential paths to improving the current implementation of PBS and how to increase censorship resistance. I am also very keen on improving privacy, both for users and validators.

g. improvements: I touched on this earlier, but I believe it could be wise to at least analyze and give our existing process some thought when it comes to shipping upgrades to mainnet. I feel like often we decide on a large and important thing to focus on for the next hard fork, make a rough timeline, and if it seems like it's not too long some smaller things can be included. Another way of doing this could be to have somewhat scheduled upgrades two times per year. This could potentially mean we could ship smaller less complex upgrades more frequently, while running the larger and more complex upgrades as a side track.

• Lodestar

• client implementer

🡰 Looking back

a. successes: Fantastic final design, great execution and testing

b. improvements: faster design iteration

c. contributions: proud and grateful to lead this hardfork for lodestar and ethereumjs

e. kudos: I feel the entire dev community really outdid themselves on this.

thanks dapplion for your spec contribution, cayman, tuyen for the feedback and reviews. thanks phil for the PM support and other members of lodestar team who kept working on the client on various aspects, thanks pari and barnabas for intense devnets and testings, thanks kev and team for c-kzg, thanks andrew and jochem for their ethereumjs 4844 contributions and holger for the the support and reviews

thanks to EF research and testing, specially mario for the amazing hive tests, thanks to other client teams for their contributions

Looking forward 🡲

f. priorities: peerDAS for furthering the dataspace, IL for censorship, universal sequencer to unify L2 liquidity.

g. improvements: keep doing the good work and keep encouraging novices like me lol

• Besu

• client implementer

🡰 Looking back

a. successes: Dencun's success can be attributed to effective community engagement, and strategic planning.

The communication around EIP-4844 was both effective and engaging. Various posts and blogs about 4844 presented a clear and impactful narrative. They highlighted the value Deneb brought to users through support for Layer 2 scaling and reduced fees. Critically, the open engagement with the community during the KZG ceremony built trust, hype, and provided a meaningful way for crypto enthusiasts and users to contribute and feel like stakeholders. These were all great wins for a hardfork that largely is not bringing new user-facing functionality.

Parallel work on Deneb alongside the Shanghai upgrade proved to be a strategic decision. Early interoperability testing provided a sufficient runway to identify the most supportable parameters, ensuring a smoother integration and better overall outcomes. This foresight in planning allowed for a more thorough and less rushed exploration of potential issues and solutions.

Moreover, setting the ambitious goal of having a Deneb testnet ready for the interop event served as a significant motivator for all involved client teams. The collective desire to achieve this milestone at the interop built early momentum and front-loaded a lot of the work for dencun.

b. improvements: The Cancun hardfork initially showed promising momentum, especially during the interop event at Edelweiss, with working testnets in February 2023. However, for various reasons, this momentum seemed to wane over time. The anticipated delivery dates experienced several shifts, moving from late Q3 to Q4, and eventually to Q1 of 2024. While testing and refinement are essential to ensuring a successful hardfork, it seemed to me that dencun lost priority and focus the closer we got to it.

As suggested by others on ACD* calls, we should commit to target timelines earlier in the hardfork scoping process. Committing to soft targets earlier in the process will help right-size scope when considering EIPs for inclusion and should help us deliver feature forks on a more predictable cadence.

Looking forward 🡲

f. priorities: Looking ahead to Ethereum's development priorities, it's clear that Verkle tries and EOF should be the headliners of the next two hardforks. Learning from the successful parallel work on Withdrawals and EIP-4844, we should expect to work on both simultaneously with very clear lines of communication and collaborative specification to ensure that neither makes the other more difficult.

Verkle tries are high priority not only because it becomes harder and harder to transition as the state gets larger, but more importantly verkle makes stateless execution and stateless clients possible. This directly supports Ethereum's principles of decentralization, permissionlessness, censorship resistance, and self-sovereignty. By implementing lightweight stateless clients, we will unlock new use cases that are currently unimaginable, further expanding Ethereum's utility and reach.

EOF addresses the equally essential task of resolving the technical debt within the EVM. Modernizing the EVM and enhancing smart contract safety through formal verification might not grab headlines, but it is key for the ecosystem's long-term stability and security. This foundational effort will ensure Ethereum remains a robust, fast, and secure platform, benefiting the entire community.

• Reth

• Team lead

🡰 Looking back

a. successes: Scoping and shipping Dencun was monumental, we found the KZG libs very useful, and we thought the testing process was excellent.

b. improvements: The community should level up its use of precisely written scientific communication. Calls are expensive time-wise and should follow standard pre-read, discussion on what could not be addressed async in writing, and clear action items with deadlines and strong expectation setting.

Being decentralized doesn't mean we cannot admit a strong high performance and accountability process. We must do better there. People should write and communicate precisely.

c. contributions: We stood up a state of the art node in less than 2 years and we're very proud of that. We think our benchmarks are really remarkable, see our beta post.

We think we're just scratching the surface of "High Performance Ethereum" and we're excited to do more.

d. challenges: The Merkle Patricia Trie code remains always the trickiest in Ethereum. This took us months of squashing and optimization, but we're finally happy with the result. We've published our work here!

We also found the integration with various Engine API edge cases to be weird at times, eg. the newPayload / getPayload vs FCU API. The team can expand more on this.

e. kudos: EF Devops are the real MVPs, congrats. And the entire Reth team has worked overtime every day since we started the project, and their work remains the biggest privilege to experience in my career.

Looking forward 🡲

f. priorities: We shared our view here. We're excited for teams to do more such writing and hope to set a new bar here.

g. improvements: Our strong view is we need benchmarks and more automated tooling for executing such stress tests. We loved the EF Devops teams work there and we need ten more of these.

We also think more rigorous historical analysis is needed to determine optimal values for various protocol parameters like the gas limit.

• Consensus R&D (EF)

• Researcher

🡰 Looking back

b. improvements: We underestimated the time needed for network testing since Dencun represented the first significant networking upgrade post-Merge. On a positive note, this experience highlighted the benefits of gradual upgrades, i.e., transitioning from Proto-Danksharding to Full-Danksharding, as a favorable approach.

d. challenges: The static reorg fork choice test vectors for edge cases. There was a small working group that tried hard to identify the attack vectors and solutions related to the fork choice reorg issues. After approximately one year of rigorous effort, we finally delivered it into Capella upgrade.

e. kudos: 1. Needless to say - a big thank you to Dankrad Feist for his brilliant idea and relentless dedication. 2. Thank you to Dapplion, Etan Kissling, Wenceslas Sanchez, Mikhail Kalinin, Justin Traglia, and many other consensus specs contributors! <3 3. Edelweiss Interop was really great. Thank you to Tim, Danny, and La Donna. 4. Thank you to Tim and Danny for hosting the ACD meetings.

Looking forward 🡲

f. priorities: 1. EIP-7547 (Inclusion Lists): It's good to improve Ethereum censorship resistance before it's too late. 2. EIP-7594 (PeerDAS): It's what we need for unlocking another level of scalability. 3. Staking mechanism and economic improvements.

g. improvements: 1. Rotate ACD meeting time: I still hope to see some attendance of Oceania devs, even if it's just once in a while 2. An online Miro priorities discussion workshop may help collect the vibe checks of over 100 people efficiently

• Stateless consensus (EF)

• Engineer/Researcher

🡰 Looking back

a. successes: I think the coordination between the KZG Ceremony and overall 4844 efforts was done correctly, and efficiently. Running the KZG ceremony transparently/verifiable and correctly had deep implications for the future security of Ethereum.

c. contributions: I'm proud of writing the most used non-official KZG ceremony client, and the most used one for the special projects phase. In particular, one of the special projects used this client to contribute from a satellite in space. See the client repo here!

e. kudos: I wasn't tracking detailed work on 4844 per se, but on the KZG ceremony front I'd like to give a shout out to Carl and Trent for all the coordination and community communication for that project.

Looking forward 🡲

f. priorities: For medium and long term I believe Ethereum should keep pushing on it's core values:

• Improving scalability, with next phases of 4844 (i.e: PeerDAS, full dandsharding, etc)

• Improving censorship resistance, with inclusion lists or any other proposal that improves one of the most important values of the network.

• Improving decentralization: with Verkle Trees we can keep lowering the hardware bar for nodes to verify the chain, and potentially considering increasing the gas limit.

I believe we should try as much as possible to focus on improving what makes Ethereum different from the rest.

g. improvements: I think EIP champions that want to propose their EIPs for the next hard fork, could try doing a bit of more elaborate work on why their change is important for the Ethereum network. As in, if improves Ethereum core values (i.e: which ones), who wants that change, what would happen if we don't do that change and leave it to a future fork, etc -- thus answering some set of "defined" good questions. Even though natural discussions in ACD calls are nice, this more structured "EIP proposal" questionnaire can help core devs take a better decision (or simply assist those calls).

• OP Labs

• client implementer

🡰 Looking back

a. successes: The devnet infrastructure for multi-client testing is impressive.

b. improvements: Getting client teams engaged was difficult. It took nearly a year to get interest and buy-in from client teams. The upgrade's scope crept unnecessarily as we later decided to couple EOF with EIP-4844, even though they were unrelated.

e. kudos: Jacek Sieka for coming up with a more rigorous blob decoupling proposal.

Looking forward 🡲

g. improvements: Having a process for cross-layer collaboration would be very good. This relates to specifications (EIPs are inadequate for this sort of collab) and ACD meetings, which tend to be execution focused.

• Prysm

• client implementer

🡰 Looking back

a. successes: All of the calls and tracking has been very good from the foundation perspective. Big props to those working on the testing and I think devops has greatly improved since early days. We became more pragmatic and focused through this process and especially after the austria trip i think which was great.

b. improvements: Some of the detailed discussions were more in internal channels and pair programmed groups in the early phases and I wish i was more involved or at least caught up in that regard.

c. contributions: I'm proud to have contributed to the API endpoints that enabled Deneb on the Prysm Consensus client.

d. challenges: It's not related to consensus work but tech debt, my work on cleaning up some of the prysm codebase and helping with the api migrations might have been the most challenging work thus far.

e. kudos: I think most of my teammates work has constantly showed passion for the space that goes above and beyond the ask for any standard job; the initiative, the leadership, the execution were all exceptional.

Looking forward 🡲

f. priorities: our team published this piece when we aligned internally, ePBS might be an additional item we are pushing for.

g. improvements: not sure but some way to improve collaboration for more introverted core dev members might be good across teams. working sessions to get newer core devs on the priorities discussed thus far that's more casual than the all core dev calls.

• Coinbase, then Base

• Contributor to 4844 workstream; leader of L2

🡰 Looking back

a. successes: Was so inspired by everyone coming together to ship 4844. I appreciated the balance of pushing for shipping as quickly as possible, while also ensuring there was rigorous design and rollout. Feels like the process of shipping 4844 has also helped build our collaboration muscle and improve our ability to deliver together.

b. improvements: I have really enjoyed the new habit of core development teams sharing their priorities in written form. We didn't do that during the Dencun planning process and I think it would have contributed to a more effective process.

c. contributions: I'm proud of helping rally folks and build momentum in 2022 / the first half of 2023, as well as marshalling the resources from Coinbase to contribute from the very beginning.

e. kudos: I think Roberto Bayardo played a critical role bringing the initial prototypes to viability, driving a number of complex technical decisions, and getting the OP Stack ready to ship 4844 support on Day 1.

Looking forward 🡲

f. priorities: I would like to see continued focus on increasing blobspace capacity via increasing the 4844 target/max and implementing PeerDAS (and the full danksharding roadmap). This should be counterbalanced with other key priorities like decentralization.

g. improvements: Keep encouraging teams to write down their priorities and focus.

• Robust Incentives Group

• Researcher

🡰 Looking back

a. successes: I think it is special how welcoming the core protocol community is to new entrants. Some of the people that have worked on Dencun upgrades could work on these topics quite soon after they got into crypto. This unique atmosphere allows us to achieve milestones quickly.

b. improvements: The emergence of "coordination calls" that are maybe similar to ACD, such as the mev-boost community call and RollCall are I think very helpful. Maybe we should acknowledge that the protocol is growing and that out-of-protocol solutions are super influential. Maybe we should be better at acknowledging the importance of how these communities govern themselves.

e. kudos: Mike Neuder has done amazing work on ePBS, max EB and ILs. I really appreciate his way of thinking and how fast he iterates on desgins!

Looking forward 🡲

f. priorities: I think a censorship resistance solution would be very nice. I don't know how pressing the problem is since censored transactions still get included within a reasonable amount of time now, however, this could shift quickly.

• Consensus R&D (EF)

• researcher

🡰 Looking back

a. successes: Data availability is a cleanly delineated module of the Ethereum stack, largely independent from core consensus and execution. It's a fantastic outcome that researchers and devs can focus on independent modules and that Ethereum has such parallelised R&D.

c. contributions: This may sound counter-intuitive but I am especially pleased to have made essentially zero contribution to 4844 and Dencun more generally :) Plenty of JOMO (Joy Of Missing Out)!

e. kudos: Cheers to everyone who helped get 4844 across the line—a monumental effort that will pay dividends :)

• Besu

• client implementer

🡰 Looking back

a. successes: EIP-4844 was the first time we saw L2s design an upgrade with the core devs in a really substantial way. I was impressed to see folks from Optimism and Coinbase take a leadership role, without really influencing what should be done. I was also really proud of the way the community rallied around our need to generate some entropy for the KZG trusted setup. Nothing on that scale has ever been done, and we made it a fun, community building event.

b. improvements: I think we could've done a better job of keeping L2s engaged after the design phase. Later in the process, during testing and review, I felt we were lacking participation and feedback from L2s.

c. contributions: I really enjoyed working with the testing staff at EF. I got more fluent with the Hive test suite, and am looking forward to incorporating it more into Besu's SDLC. Building Hive was a wise investment by EF, and it was fun being able to collaborate on how specs were interpreted. Some of those insights even made it back up into the specs to clarify things.

Oh, my special contribution to the KZG ceremony was a ton of fun too. It's a bit romantic, but I love the idea that an annual game my friends and I played will live forever in the entropy that Ethereum will use to scale.

e. kudos: Shoutout to the EthPandaOps crew- especially Pari and Barnabas. Mad props to Mario who was a great collaborator on the Hive tests, and Mikhail who used our learnings to further clarify the execution specs. Y'all make a dev feel loved!

Looking forward 🡲

f. priorities: Inclusion Lists and ePBS should be our next urgent priorities. We've conceded too much ground to the forces of rent-extraction, and are already having to design around MEV relays and block builders. Inclusion Lists are a mechanism needed to fight the censorship introduced by MEV, and that correlation is not a coincidence. I am here to make abusing power harder, and it is still not hard enough.

g. improvements: I think our process is awesome and needs no improvement. Any efficiencies to be gained would be negligible. A+ project, no notes.

• EF Security

• Security Researcher

🡰 Looking back

c. contributions: I am particularly proud of my contributions to c-kzg-4844. A lot of the implementation work was already done when I started contributing, but I helped turn it into a production-ready library worthy of being used by Ethereum clients. Notably, I figured out how to include Golang bindings and convinced Supranational to finally add CPU runtime detection to blst. I had a lot of fun working on this library and learned a lot about cryptography in the process.

d. challenges: We had the most annoying bug in c-kzg-4844's Rust bindings. On Windows, sometimes we would experience a stack overflow when verifying a proof. Pawan Dhananjay and I had spent a whole week trying different things like increasing the stack size, "boxing" blobs so they are allocated on the heap, and using different Rust versions. After I had given up all hope, Pawan somehow figured out that it was related to blst. He discovered that under certain circumstances blst would define a boolean (1 byte) as an integer (4 bytes) and rust-bindgen did not like this. After this point, we quickly figured out a fix and moved on with our lives.

e. kudos: I really appreciated working with George Kadianakis (@asn-d6) during this upgrade cycle. He is an excellent cryptographer, researcher, and friend. He was an important contributor to the Polynomial Commitments API specification/implementation for EIP-4844. George is the first person I go to when I have a cryptography question. I thought his (also Ansgar's and Dankrad's) ethresearch post about a Universal Verification Equation for Data Availability Sampling was genius; it made batch verification of sample proofs very fast & efficient.

Looking forward 🡲

f. priorities: I am a strong supporter of EIP-7594 aka PeerDAS. I think it should be prioritized for the near-term. Ethereum needs to scale to remain competitive with other chains. PeerDAS does not necessarily require a hardfork because it does not change consensus protocol, it just changes how blobs are distributed and stored.

In the medium-term, EIP-7251 aka MaxEB would be a welcome change. Consolidating validators would reduce load on the network and would allow solo-stakers to earn rewards on ETH we have sitting on the sidelines. Also in the near-term/medium-term, I would like to see Ethereum improve its quantum resistance. I am afraid that quantum computers which could threaten Ethereum will be here sooner than we think.

• EF cryptography

• cryptography implementer

🡰 Looking back

a. successes: I think the core protocol community has done well in splitting up the vision of ethereum into smaller manageable projects.

b. improvements: I've historically worked in smaller specialized communities in the core protocol, that I think have gone well so far. Theres always room for improvement though!

c. contributions: For KZG ceremony: Researching all of the previous ceremonies and writing up the rationale for why the simpler approach works - see important precedent from Mary Maller here. This meant that the ceremony was significantly simpler.

For 4844: I'm proud that I was able to push for the change to completely separate the cryptography from the rest of the protocol and create a more higher level API. This meant that client devs did not need to care about how the cryptography was implemented.

For Verkle tries: I enjoyed rederiving the barycentric formula and the formual for division by a linear polynomial where the linear polynomial is zero on the domain -- see my notes here.

It was pretty cool to also note how it generalized the previous formula where the domain was the roots of unity.

d. challenges: Out of the projects I've worked on at EF, I think verkle tries were the most challenging because for quite a while we were experimenting, benchmarking and exploring different design choices which necesitated quite a few code rewrites. Its also the longest ongoing project that I've been on which might play into my bias here.

e. kudos: I have three people.

Dankrad Feist has been extremely supportive and patient during my time at EF.

Justin Traglia has shown me through his contributions in 4844 that he is extremely dependable.

Ignacio Hagopian is an unsung hero for verkle tries and is someone that I enjoy working with a lot.

Looking forward 🡲

f. priorities: Very biased opinion: I don't have a particular protocol improvement, I do think we should continuously be asking ourselves "How does this play with zkSNARKs?"

g. improvements: I think:

• Integrating and seeing what fails as soon as possible

• Limiting the scope of features so that we can ship fast and possibly moving towards a more iterative approach to features.

• Geth

• client implementer

🡰 Looking back

a. successes: It's easy to get lost in the minutia of priorities and timelines. We have so much still we'd like to do to improve Ethereum. But looking back at the last two years, we are really shipping at a rather high velocity given the size of this project.

Two years ago, Ethereum had still not even transitioned to PoS. We quickly followed with the Shanghai hardfork enabling withdrawals. All the while, thinking ahead to data scaling with 4844.

It's really incredible when you think about it.

b. improvements: It's hard to fault ourselves in retrospect for the path we followed to Dencun. There were many different, unrelated work streams which needed to converge to be prepared for the upgrade. Additionally we had to do a lot of new things to prepare for this fork, particularly with testing the networking load of blobs.

Although it would have been nice to have 4844 in 2023, it isn't clear what could have been done better to achieve that.

c. contributions: Update EIP-4844: change op to BLOBHASH -- jk, I'm proud of working on the 4788 contract.

d. challenges: Probably trying to pass the hive tests haha. The team has done a great job with creating a lot of detailed test cases.

e. kudos: I'm thankful for Marius and all the testnets he destroyed on the way to dencun! He really has a special knack for sussing out weaknesses in networks.

Looking forward 🡲

f. priorities: I think we should improve the experience of running nodes. Not just as a home staker, but also as a home user who does not want to rely on centralized infrastructure.

g. improvements: These are all hard questions. I think despite some frustration at times with the process, it is working. So I'm not sure how much can be done to improve it. Building a project of this scale in the open is going to be complicated. No way around that!

• Nethermind

• Client Tech Lead

🡰 Looking back

b. improvements: Deliver faster, I think Dencun is few months late.

c. contributions: Reviewing all Dencun Nethermind PR's. Our tx pool resilience to DOS, which I helped design.

d. challenges: Not Dencun related but the most challenging thing is State storage in Ethereum clients. Nethermind has been working on redesigning ours for over a year now, still at least a few months away.

e. kudos: Marcin Sobczak work on tx poll and then stress(spam)-testing it on devnets and testnets that uncovered a LOT of DOS vectors on all the clients.

Looking forward 🡲

f. priorities: Verkle should be prioritized but worked in the background. State is the hardest and we cannot deliver it that quick without committing resources to it.

g. improvements: Tik-tok scheduling, where teams work in parallel on at least 2 next hardforks to improve velocity.

• Nethermind

• client implementer, team lead

🡰 Looking back

a. successes: I have observed that with each hardfork, our testing procedures become more robust. This includes setting up development networks, conducting hive tests, and implementing additional tooling. In this hardfork, I believe we have done good work in defining priorities. We all agreed that 4844 was the main driver, and our focus has been on it.

b. improvements: While we made great efforts in testing Dencun, there is still room for improvement. One area to focus on is the addition of automated chain monitoring (devnet) to enhance incident detection, such as identifying missing proposals or detecting bad blocks in a more automated manner. We could think about automated tracing for consensus issues incidents. Considering the scope for the next 2-3 forks. For the next fork, it's important to define it quickly and avoid additions.

Currently, client teams are working on various tasks like EOF, Verkle, 4844, AA, Staking EIPs, inclusion lists, and SSZification. Prioritizing these tasks or discussing them further during ACD calls is vital. For instance, there are multiple propositions for AA, but a clear path has yet to be defined

c. contributions: I am proud of the Nethermind team getting more and more involved in testing. For example, by creating tooling

I remember that we had quite a few issues before devnet-8 started, we managed to fix them very quickly by brainstorming issues together.

d. challenges: We had a few tricky issues with our blob transaction pool.

e. kudos: I prefer not to mention specific individuals due to the large number of contributors. I want to express my appreciation for the contributions of our Nethermind team, EF DevOps, EF Testing team, other client teams, and all other individuals involved

Looking forward 🡲

f. priorities: Short term: EIP-6110, EIP-7002, EIP-2537. These are crucial improvements for staking and important precompiles to be added. Furthermore, these are relatively small EIPs, allowing EL developers to concentrate on Verkle trees and other priorities.

Medium term: Verkle tree (a significant step forward for light clients and statelessness).

Medium-long term: EIP-4444 (as the chain is growing rapidly, we need to initiate the process of removing history). Account Abstraction is essential to enhance Ethereum's user experience.

Long term: State growth - we need a plan for addressing this issue.

g. improvements: A well-defined scope for the upcoming hardfork is essential, but having a preliminary plan for the subsequent 1-2 hardforks will undoubtedly be helpful for client teams. Currently, our focus includes staking EIPs, possibly EOF, and verkle trees for the next hardfork. However, it would be beneficial to discuss what comes next: AA EIPs?, EIP-4444?, or something related to state growth, all potentially in the research phase. Of course, to some extent, the scope has to be flexible, but the clearer the scope, the better.

• EF Testing

• Protocol Tester

🡰 Looking back

a. successes: The collaboration between the execution client and consensus client teams has been definitely improving, and there is a lot of good synergy between teams. I'm looking forward to closing the gaps that we still have in regards to how testing is done across teams while making the process much smoother.

b. improvements: I think the timelines were a bit too ambitious. I remember first reading EIP-4844 around two years ago and barely understanding many of the concepts in it, which should have been a clear giveaway that this was going to be very hard to test.

c. contributions: The blobber is definitely a standout for testing during Dencun. It prompted a spec modification that, in my opinion, resulted in a more robust protocol. We are really proud of this specially because it seemed like a very innocuous idea, but if this were to have reached mainnet, it would have been a really big deal.

d. challenges: Getting the new tests repo up to speed to be able to be the main source of tests for Cancun was really challenging but the outcome has been extremely good.

We are now better prepared to fill tests for future forks faster, and also we are able to use the full potential of pytest and it's parametrization capabilities to automatically generate Ethereum tests for a ton of important edge cases and scenarios, which is better overall for the robustness of the network.

e. kudos: The EF Devops team just continues to amaze! Parithosh and Barnabas really just outdo themselves on every fork, and keep doing things better. The swiftness of launching shadow-forks and devnets, they make it look easy, but it has been a lot of hard work from them and it has really paid off.

Looking forward 🡲

f. priorities: I think verkle is an exciting next step for Ethereum to make the stateless clients more practical, and I'm enthused as testing is starting to ramp up right now. I do however think that we should take enough time to really consider all the caveats that this change brings.

As an Ethereum user, I really wish that account abstraction was a solved problem at protocol level by this point, but it's not an easy task. I'm a fan of 3074 but also recognize all the problems it could bring since, even when we perform all the exhaustive and necessary protocol level tests, there will still be the need for more user guardrails in wallets and dapps and rigorous testing over there.

g. improvements: I personally think there's still a some way to go to get testing just right, it's been a long way since the merge and a lot of improvements have been made to the process but we are looking into solidifying the testing procedures in this multi-client multi-layer environment.

• Geth

• Client Implementer

🡰 Looking back

a. successes: We've coordinated well, especially with "outside" teams like Optimism, Coinbase and Uniswap. Their prototyping was a great jumping off point for the work on 4844 and 1153.

The testing team has been great at creating tests and notifying the client teams of issues, which made the development cycle way quicker. They found a bunch of very niche, but very critical issues in things like the selfdestruct removal. Also Marcin from Nethermind has been great at fuzzing the test networks with blob transactions.

Working with the researchers, especially Carl, on the KZG ceremony was also a great experience. They provided a (good enough) spec that you could implement if you wanted to build your own client and test vectors.

There've been a few mainnet incidents that were solved very well. Everyone joined a call and debugged the issues until solved. I remember OpenEthereum having a mainnet incident in 2020 where the only people really debugging it were Rai from Besu, Marek from Nethermind and Martin from the Geth team. This has completely changed in my opinion. Every client team has a lot of very capable people now that know both the protocol and their implementation which makes debugging issues easier.

b. improvements: I think the biggest issue in the last years was the cancun timeline in the last couple of months which was pushed because of decoupling and re-coupling of the blobs. There's not much we could do there. There were new issues found and we had to postpone the fork to get them fixed.

Another issue I think was that we did not have the core dev day in Istanbul which could've accelerated timelines significantly I feel. So a shoutout to Tim Beiko for organizing the retreats and dev days which help coordinate our efforts.

c. contributions: I wrote parts of the 4844 implementation in geth link link and prototyped 4788 with Alex Stokes link where we started 4788 as an opcode and then implemented it as a stateful precompile, before Lightclient finally built the system contract as it is now.

I also worked on a client for the KZG ceremony together with Daniel Knopik towers-of-pau which was the first draft of the ceremony and later on became a client for the official ceremony.

e. kudos: Barnabas and Pari for setting up the testnets and devnets and giving me access to broken nodes over and over again. Marek and Ahmad for the late night debugging sessions. Danno, Justin and Matt for reacting so level-headed to me being stupid. Peter, Martin, Matt and the rest of the geth team for being the coolest team I ever been part of. And Potuz for reminding us of our values. And a hundred others that do great work in this community

Looking forward 🡲

f. priorities: I'm a big verkle proponent, but I also see ethereum's unique selling points: censorship resistance and decentralization at stake because of MEV and restaking activity

g. improvements: I think we should stop adding small improvements to the EVM and work on bigger improvements (like 4844, Verkle, ...) which enable us to do a 10x instead of a 10% improvement.

If dev days are cancelled (like in Istanbul) we should book a room anyway and just meet with the people that are there already. Sure we won't have everyone, but good discussions can and will happen even in smaller groups.

Testing has come a long way and I would encourage everyone, especially EIP authors to get in touch with Mario from the testing team early so they can plan testing strategies and to contribute to the execution-spec-tests.

• Teku

• Client Protocol Engineer

🡰 Looking back

a. successes: Deneb coordination and discussions during ACDCs, Deneb specific calls, Deneb testing calls / channels, Client teams collaboration (discord, telegram, calls), Incidents resolution (Devnets and Goerli)

b. improvements: Deneb inclusion proofs was a great design improvement but could have been considered earlier (lack of communication or initiative?)

c. contributions: Participated in the Deneb implementation within the Teku team. Raises spec / beacon API PRs

d. challenges: BlockV3 API: Challenging for Teku (Java) to handle different API return data types

e. kudos: Blobs inclusion proof design

Looking forward 🡲

f. priorities: Optimising client resource usage (decrease memory/disk/cpu usage), decentralisation (mev-boost, staking operators...), improve UX, reduce protocol complexity, increase client diversity

g. improvements: Check users needs (DAOs, polls...), Keep up with the protocol calls and other communication channels (Discord, telegram)

• TXRX

• Research Engineer

🡰 Looking back

a. successes: The core protocol community keeps its pace and passion on delivering complicated features like 4844 and fighting challenges appearing here and there on the way. The delivery of the Ethereum Roadmap features may be delayed, and the feature set itself is constantly evolving but the community doesn’t give up on the main objectives which signifies reliability of Ethereum technology and community long term.

b. improvements: I think the way it is now is practically the best. I can’t recall any existing issue that can be easily solved on practice. Yes, we want Ethereum development to be faster, more predictable, satisfying everyone’s needs and secure and the same time. And I believe that each of these qualifications is at almost the maximum level of quantity as it can be achieved in practice considering all the constraints.

c. contributions: I am especially proud of this almost last minute change: Add blob sidecar inclusion proof #3531. We delayed the delivery but we made the thing right, favoring security of the protocol and the network.

d. challenges: I wasn’t involved in the Dencun work that much. But at the time of it, I was working on the EIP-6110 prototype with Kevin, Navie, EF devops, Lighthouse and Besu teams. The results of this project have exceeded my expectations and I am very proud that our efforts contributed to the decision to include this EIP into the Electra/Prague hardfork.

e. kudos: I believe that everyone in the core developers community is amazing. But I would like to emphasise my appreciation of the work that devops and testing teams do. These guys are constantly improving their infrastructure and tooling to make the delivery of highly complicated features possible. I can’t imagine Ethereum development progressing at the current pace without their outstanding efforts.

Looking forward 🡲

f. priorities: I would prioritise DAS (a.k.a. danksharding), Verkle Trees, and Single Slot Finality and related but smaller upgrades. This is the feature set to keep Ethereum evolving as a settlement layer for L2 solutions.

g. improvements: I think early prototyping of complicated features across client teams is the thing that would help to deliver faster by identifying issues, finding solutions and answering questions early in the process, thus, making new changes easier to be set for a subsequent hardfork. This requires client teams to coordinate their work on new features before they are set for the hardfork. This is somewhat we did with 4844, and I believe should keep doing in the future.

• Lodestar

• Protocol Engineer

🡰 Looking back

a. successes: That was considerably large target to achieve in a small time.

b. improvements: I believe there is less clarity among core devs for KZG, except those who actively work on it. We may start in-house educational seminars/webinars to bring everyone in Core Dev upto a similar level of knowledge in different domains. That can be better facilitated by EF research team.

e. kudos: I believe Gajinder in Lodestar team worked really hard during the Dencun implementation. He not only coordinated with other teams but also lead the implementation in Lodestar.

Looking forward 🡲

g. improvements: More awareness to the community what is coming and why it's important.

• EF DevOps

• DevOps and Testing

🡰 Looking back

a. successes: The core protocol community did a great job of managing scope and handling a complex co-ordination problem across clients. ACD also has gotten quite good at handling potential mainnet incidents and improved at co-ordinating between EL and CL teams.

b. improvements: I would say timeline estimation and making concrete decisions earlier on. I think there have been at least a few times in the last few years where we wanted to over-promise and ended up under-delivering, and the exploration time for the over-promising ended up delaying what we delivered. I hope we get better at understanding what we can ship and how quickly.

c. contributions: We overhauled our entire testnet stack to be based off of a template and that template was stress tested with the Dencun testnets. This saved us countless hours spent on setups and basics while ensuring everything we do remains flexible for catering to the needs of protocol testing.

d. challenges: The Dencun fork was clearly something we needed quite a lot of new tooling for and this testing overview doc helped scope out which changes exist and how they are being tested. The overview doc was the easy part, building/using the tools to actually find bugs was the challenging part. Working with Mario to run his Blobber tool and debugging if the tool even worked was extremely challenging and a humbling experience.

e. kudos: The entire EthPandaOps team has been amazing to work with, the team hit the ground running mostly in 2023 and has already built awesome tools to make deployments (eg. KZG ceremony backends) /testing/research/co-ordination easier for core protocol work. It's been great to work with Mario and the testing team, their depth of knowledge is humbling. Also a huge shoutout to g11tech, Pawan, Sean, Tersec and all the core devs that are constantly available and helping us decipher what we're seeing/pushing fixes in.

Looking forward 🡲

f. priorities: The last couple of upgrades were targeted quite heavily at consensus and scalability, it would be nice to see usability as the next focus. EVM improvements, smaller proofs/light clients and Censorship resistance need some love and care as well.

g. improvements: A hard part of testing is trying to support everything all the time everywhere, as a result our stack tends to be relatively messy - as the same tool needs to support verkle, 4844 and eip-6110 and whisk testing (to name a few) at the same time, all while the inherent fork itself is changing. The overhauls of 2023 helped a lot with making sure we're able to keep up with this rate of parallel testing for now, but its still quite tedious to never know what to expect.

It would be nice to have a clearer roadmap for at least the next fork, so we can make concrete decisions on how to split our tools up and it would reduce the burden in maintaining PRs forever or rebasing constantly.

• Lighthouse

• Client implementer

🡰 Looking back

a. successes: I think 4844 was a very well thought out, forward thinking spec change where it laid the foundation of data availability sampling such that it required fewer changes from the EL for increasing scaling. It also allowed the devops team to create good infra to test further networking changes in the future as we increase scale.

b. improvements: I think we should have had done more work in parallel to test viability of some of the changes that are up for inclusion in Electra. Feels like we are starting from scratch for most of the proposals (at least in terms of client implementations) for the next fork which is making it hard to prioritize things for inclusion.

c. contributions: Not my contribution, but the spec change to add a merkle inclusion proof to the blob sidecar was quite a genius move that simplified loads of assumptions we had to make in our codebase. I'm also quite proud of our implementation of the change.

d. challenges: Making the ckzg library work on windows was a huge pain as it kept crashing unexpectedly. We eventually figured out that the issue was a bool getting redefined as an int in the C code which wrecked the FFI between C and Rust 🤡

e. kudos: Highly appreciate the EF devops team for making the lives of client devs easier. Also, special shout-out to Sean Anderson for his incredible attention to detail regarding potential attack scenarios for all spec and implementation changes. He has a knack for understanding the bigger picture of things we are building and I learnt a lot from conversations with him. Knowing that he'll be around helps me sleep better!

Looking forward 🡲

f. priorities: Near term: I think the main focus should be getting additional scale with the new sharding proposals and improved UX with some form of account abstraction. Also need to make sure that the beacon chain is able to handle the increasing number of validators, especially considering the increased bandwidth because of other scaling related changes. We also need to keep an eye on censorship happening on chain and have mitigations for that which are strictly better than the current state of things.

Medium/Long term: we need to fix a lot of technical debt that we have accrued over the past few years.

g. improvements: It's a hard problem, since we have multiple priorities that are important in their own right, but limited time for core devs.

• Lodestar

• Project Manager

🡰 Looking back

a. successes: The core protocol community has really found a good rhythm of working together and pushing out upgrades that we desperately need to keep the EVM and Ethereum L1 relevant. We understand very well that there is a scarce resource of limited developer time and we can come to relatively good decisions on how to best prioritize features. Shipping one hard fork a year is an absolute minimum to achieving goals and the Ethereum DevOps team has been exceptional in accelerating this front. We haven't had any serious incidents on mainnet outside of some minority client consensus bugs and non-finality incidents, but we are generally very good with responding to them with the help of others in the community. Workshops at conferences and interops once per hardfork is ideal to really help shorten the development timeline. Gatherings of core developers at events such as Devcon help ensure we can have some sort of mindful consensus on what needs to be prioritized for each hard fork.

b. improvements: We need to be more aware of the diversity of knowledge which exists outside of protocol development. Our work affects other builders in the Ethereum ecosystem and I think there can be room for improvement with other layers of the stack participating in our calls/discussions or we participate in theirs. It's important that we know what builders on L2s and Dapps are thinking to help better prioritize the core protocol roadmap. If we don't create a viable environment for new experiments to survive, we will struggle with maintaining a lead in developer mindshare. I think we've come to a good consensus that scalability is very important and doing what we can to lower gas fees is essential to success, which was a big push for getting proto-danksharding in for Deneb.

We need to balance moving forward along with not breaking things due to how important our work is. The teams in core protocol are the backbone to keeping Ethereum running and when teams identify that a timeline is too tight, we should consider this carefully, especially if its a client team with large usage. Some teams are capable of moving faster than others and some teams need to naturally be more conservative to ensure Ethereum remains safe. We should find a balance between that or figure out ways to better diversify usage. We should support each other in this area and always strive for an equal distribution of client usage.

We were really good with last-minute inclusions including EIP-7514 which was based on what we were seeing on Mainnet to give ourselves buffer room for solving larger technical challenges. We aren't always good with foreseeing how our development creates problems elsewhere until it's live out in the wild, but we are good at mitigating problems once they arise (even with temporary solutions).

e. kudos: When we started on the EIP-4844 implementation, the Lodestar team was still trying to build up its team and lacked the resources we needed to ensure we could properly implement c-kzg bindings for nodeJS. The community was very helpful in ensuring that we didn't fall behind and connected us to resources which would help us move quicker. I'd like to especially thank Liam Horne, Tim Beiko, Jesse Pollack and Dan Coffman for connecting us and dedicating resources to ensure we could take over some of the work started by external parties once we further developed our team.

Looking forward 🡲

f. priorities: In the near term, we should be focused on scalability (e.g. PeerDAS, Danksharding) so we can continue to compete with other blockchains and stay relevant. We will bleed builders and users if we cannot figure out how to scale in a way that still respect the ethos of Ethereum. We should be very mindful about staking economics and ensure we can always get close to what we'd ideally like to see: decentralization and a fair playing field for everyone.

In the medium term, we need to further mitigate MEV type issues and censorship. Ethereum needs to remain neutral at protocol and we cannot let liquid staking pools/companies dictate what can and cannot be included on Ethereum. Companies naturally have to follow the local rule of the land and it's important that large entities don't control the direction of Ethereum if it means sacrificing ethos. Enshrined PBS needs to come to a consensus soon and implemented alongside other research for staking economics so we can bring some equilibrium to all players staking/securing the chain.

In the medium term also, we need to parallelize Verkle, EOF, PeerDAS and some sort of account abstraction features to allow for better DX and UX for Ethereum. If builders need to workaround problems within protocol constraints and the natural effect is dangerous UX workarounds, we will not be able to create the interfaces needed to onboard the rest of the world.

Long-term we should try to ossify the protocol to a point where Ethereum has stable enough mechanics that the protocol itself doesn't need to go through anymore hard, unpredictable changes. The hard part is drawing the line of when we think the protocol is "stable enough" to not touch it anymore. I don't believe we've had enough discussions of what that future looks like, but I think ossification is important to give ourselves some endgame which will better legitimize Ethereum as the base settlement layer of global commerce. We could always look at having a more "experimental Ethereum" type project in the future as research and development evolves in the blockchain space.

g. improvements: I think we're doing pretty well here and have improved when it comes to core protocol contributions. We can definitely think about doing things where parallel developments happen and perhaps we can additionally create forks that are independent of the EL + CL for things to potentially move faster, or tackle some debt where there's no dependencies on the other layer. We've been pretty good on the CL side about changes that can be done outside of a coordinated hard fork and we can likely do the same with focusing on some CL only changes while working on larger, coordinated hard forks. We should be clear on expectations of when hard forks should happen. A lot of decisions can't be made until we commit to a harder target of a change. If we want to do a smaller 2024 fork, we should be clear about it so we know what we can realistically try to get in there.

• OPLabs

• rollup engineer

🡰 Looking back

a. successes: While Ethereum has not reached the so called "Endgame" yet, the progress towards Sharding means a lot. Without this, there would be no viable path for any L2 to sustainably scale total Ethereum throughput. Due to forward-compatibility with the full danksharding design, the effort was larger than just "add 400KB of expiring data per block", and I believe this will pay off: the latest DAS designs look promising. Long-term thinking about the protocol is something Ethereum does very well, and what I stick around for.

b. improvements: There is no such thing as a "product manager" in ethereum or ACD. While this is a good thing for the long-term technology sustainability and decentralization, there was definitely a cost to not scaling ethereum faster in more simple ways. I believe ethereum does well, long term in the violent blockchain space, because of a lot of hedging: client diversity, L2 competition, sub-communities. We would see more client diversity if the protocol was more simple. We would see more L2 competition if the data-availability space was not as crowded. We would see more communities if usage cost was not as high. In other words, "squeeze the plan, not the people" is something ACD can improve on.

c. contributions: Based on a pre-danksharding concept design by Vitalik & Dankrad, we entered what we now know as EIP-4844. This started at EthDenver 2022, where I built the first prototype implementation with a group of Ethereum friends. Execution layer: @lightclients @adietrichs (Quilt, at the time), @asn_d6 (EF). Consensus-layer: @terencechain @rauljordaneth @preston_vanloon (@prylabs) Sean A. (@sigp_io) and Hsiao-Wei W. (EF). And then, based on this early draft we developed during the hackathon, I published the EIP, and the Consensus Layer specs. After this, the EIP wasn't quite mainnet ready yet, but it was a big milestone: specifications are a critical step towards realizing the thing. And then during following conferences, like Devconnect, we shared the design and discussed changes with the L1 client implementers. I am proud of how we got the first iteration towards sharding to a complete cross-layer EIP.

d. challenges: The most challenging sub-projects in EIP-4844, that I was part of, were the original hackathon draft, the early execution-layer prototype implementation work (which @Inphi, M. de Hoog and R. Bayardo then helped to continue), repeated drafts of L2 support, and the process of dealing with the long-running EIP (2 years is a lot in crypto time!).

Fun fact: EIP-1153, also in the Dencun upgrade, got some implementation traction during that year in EthDenver also. Since the change away from the old venue (the "castle", a chaotic but beautiful mess) the hackathon vibe has been much worse, but I hope EthDenver, as well as other ethereum hackathons, will offer a "side stage" for protocol developers: many of us are there to share knowledge, collaborate and form teams, but just not as involved on the application layer (often the primary sponsors of the event). If there was more of a connection, then protocol changes would be better informed from a product perspective, and more new cross-application/protocol ideas may come to fruition.

e. kudos: Parithosh, and the whole EF devops team really, helped a lot in the testing phase of EIP-4844, something a lot of people underestimate: scaling comes with stress-testing, advanced monitoring, and large scale deployments of many different client implementations. This meant a lot for client-implementer teams during testing/debugging, and helped significantly accelerate the delivery of the change to L1.

Looking forward 🡲

f. priorities: For roadmap planning I'd like to wait and see what DA-cost impact EIP-4844 has. Increasing the blob-count per block is very tempting, if we want to double down on scaling in the short term (with blob expiry, the cost is bounded and not permanent). That said, new great things like Verkle trees and Peer DAS are looking promising too, but may require another 1+ year span of development. If we are committed to a second Ethereum L1 upgrade this year, the scope should be relatively small. I believe some tech-debt cleanup changes ("the purge") are good to have, and ideally a subset of the SSZ-ification EIPs: transaction receipts are currently nearly impossible to deal with as L2 (due to large max size and inefficient hash commitment) and deserve some tech-debt cleanup (merkleizing them, in any way, can have a big positive impact on L2s!).

g. improvements: While I appreciate a fast rollout (ship it!), making significant changes to L1 without timely announcement makes it a challenging task for L2s with delayed upgrades to keep up. This incentivizes L2s to not implement delayed upgrades. For proper decentralization of L2s, upgrades happen with a lot of process: public L2 testnet (depends on L1 testnet), change review, governance voting, upgrade-veto, upgrade/announcement-time. For the OP-Stack, this balance was very tight, and exact rollout timelines still remain uncertain. As of writing this in mid-february, no other L2 team has published a public testnet yet. Day 1 adoption of EIP-4844 is uncertain for most (if not all) L2s, and may be very chaotic. Ideally change-control later in the L1 process is stricter, and earlier tentative announcements for mainnet L1 can help resolve the uncertainty around L2 upgrades.

• EF DevOps

• Testnet and KZG ceremony infrastructure

🡰 Looking back

c. contributions: I am really proud of all the tooling that the EthPandaOps folks have been shipping. With dencun we did a major change on our ansible setup and now have a collection of ansible roles that we've been using a lot, together with our k8s helm charts for our dencun devnet deployments. It's great to see more infrastructure code being open source and available for everyone to reuse.

Additionally, I enjoyed working alongside Carl, Trent, and Nicolas on the KZG sequencer setup, where we successfully gathered a total of 141,416 contributions!

d. challenges: Early devnets on any new "big feature" are hard. Having all these different client combinations is nice for decentralization but it also brings a lot of complexity into testing. In the beginning there will be a lot of breaking changes and bugs. It normally always takes a couple of devnets until clients mature into a more stable release. For dencun, we had a total of 12 devnets.

e. kudos: A huge shoutout to my team. EthPandaOps let's go! Without these folks (Andrew, Barnabas, Pari, Philipp and Sam) we wouldn't have most of the testnet infrastructure and visibility into the current state of these networks. We've learned so much together and kept improving our tooling which has been used by a lot of devs and researchers.

Also, huge thank you to client devs which are always so kind and helpful at debugging problems. It did require a lot of team work but now "blobs are coming" is for real.

Looking forward 🡲

f. priorities: Guillaume keeps talking about some Elephant in the room. So maybe we want to tackle that one sooner than later 🐘

g. improvements: Coordinating these efforts is a hard job and I think that we're doing well on that front.

• Applied Research Group

• researcher

🡰 Looking back

a. successes: It has been great to watch the process unfold as we move from the early ideas of "protodanksharding" all the way to EIP-4844. It involved a lot of active work from all core protocol teams as we moved from early idea to early spec to early prototypes and the refinement process that unlocked. And this example serves to highlight a particular strength of the core protocol community as we integrate a diverse number of skill sets and perspectives as we all discover how to make Ethereum better.

b. improvements: If I had to highlight one part of the process to improve, I'd suggest stronger focus on (ideally) one thing at a time. Hard forks come somewhat infrequently given the coordination overhead. And this means a lot of good ideas to improve Ethereum all have to compete for a very limited amount of "core protocol development" bandwidth. However, the more we put into a given hard fork, the more we will have inevitable delays in shipping the latest and greatest to improve Ethereum. One way to address this is to be laser-focused on a small set of things, even to the exclusion of other stuff that is good in isolation, but may not quite stack up in the final prioritization. Attempting to implement this brings the immediate challenge of what to prioritize and to answer this question we have to have a clear definition of what we are actually trying to accomplish -- in short, answering the question, what is Ethereum for? I think for a number of reasons the answer is muddy. Part of this reflects a strength of the Ethereum community broadly: its decentralization. But at the same time, having an unclear idea of what Ethereum should become spirals out into all the decisions we make with tangible impact to actually getting to the protocol's future.

c. contributions: I'll call out EIP-4788 that I was involved with. It provides a trustless mechanism to access consensus layer state inside the execution layer, with direct impact to the security and scope of what staking pools can hope to accomplish.

d. challenges: In broad strokes, the part I play in stewarding the MEV ecosystem is the most challenging: not for intrinsic technical reasons but more for organizational reasons. There are somewhat competing views that "mev-boost is outside the core protocol," and so the core protocol should just be secure and then what happens outside of it is not the core protocol's business. But at the same time, there is overwhelming adoption of mev-boost so I find it hard to simply stop support with the core protocol itself. This adjacency is also mirrored in the organizational structure of core protocol teams and those in the MEV ecosystem, so there is a lot of coordination work that can be done to ensure this support can be delivered. At the end of the day, I think we are simply in a "growing pains" phase as we figure out how important these "extra-protocol" actors will ultimately end up being. In other words, the current situation is to be expected and I'm consistently amazed the extent to which various teams will go the extra mile to make sure things are working end to end. And this makes me hopeful for the future.

e. kudos: I'd have to call out the work of the EF testing team, especially Mario Vega. As the protocol becomes more complex, the testing load increases and the efforts of this team are the first line of defense to ensure that Ethereum remains as secure as it has so far. And while I think overall the Dencun development process has been a great success, the road to get there was definitely winding. In concrete terms, this means testing becomes that much more complex -- not only testing the protocol but following all the various iterations as they evolve over time.

Looking forward 🡲

f. priorities: This is a hard one and I think my specific opinions are still evolving, as ultimately the best timing of a given feature reflects the most pressing priorities of Ethereum, rather than reflecting the opinions of a group of people on a given day. That being said, my own view is something like this:

Near term: data scaling; we want to continue the push to provide an affordable path for everyone to actually use Ethereum, and the rollup-centric roadmap seems like a great way to do this.

Medium term: censorship resistance; if anything the adoption of mev-boost is rational for individuals but has gotten us to a place where a core Ethereum value starts to become compromised. I think the research here is still getting to a solid place which is why I have given it some time beyond the "near term" goal, but do think it would be the next best place to focus assuming we had a much bigger data facility in the protocol.

Long term: staking economics; I think we ultimately want to drive to a world of minimum viable issuance. However, the path to get there is not super clear as it touches just about everyone who interacts with the core protocol and will ultimately be a very political decision to navigate.

g. improvements: Focus, focus, focus. We should do everything we can to drive towards tightly-scoped hard forks that can be delivered quickly. There's no reason we couldn't upgrade the protocol say twice a year, other than the sheer coordination effort required to actually roll stuff out. And being ruthless about focus will only help us maintain high velocity towards improving Ethereum.

• Base

• client prototyper

🡰 Looking back

a. successes: KZG ceremony in particular was brilliant! ACD is also very open and I love how everyone's input is heard and (almost always) respectfully considered.

b. improvements: a few things took too long in hindsight: (1) blobs with block or blobs-as-sidecar. We flip-flopped on this decision too many times. (2) closing on the format of blob transactions (we were stuck on potentially adopting SSZ encoding for entirely too long) and (3) understanding & documenting appropriate transaction pool handling of blob transactions. this one is probably because txpool handling is not part of the spec, though probably the spec should still be obliged to provide (potentially heavy handed) guidance given this is so important. Right now you basically have to read the geth code if you want to submit a blob transaction and understand what's needed to get it accepted in a block, which doesn't feel right to me.

There were also a few last-minute additions to Dencun that kept pushing back that release date. E.g. beacon block hash in the block header was I think the last example of this. Not sure if there's something we could do to get these things surfaced earlier or be better about saying NO if it results in any increase to an already extended timeline.

c. contributions: Getting geth & erigon EL 4844 prototypes working for the client dev Edelweiss workshop and having almost every CL/EL pair running on our devnet by the end of the workshop (I think nimbus CL was the only one that wasn't quite able to get up and running). I feel this cemented 4844 as the clear next big feature for the post-Shanghai hardfork (as opposed to say something like EOF).

d. challenges: Getting the initial 4844 devnets and prototypes running. we had an interop repo here that was very chaotic with lots of forks of various clients.

e. kudos: Mofi Taiwo from OP labs was involved very early on in the 4844 prototyping work and drove an enormous chunk of the geth prototype, and he provided a ton of guidance for me getting the erigon prototype going.

I also greatly appreciate Tim Beiko who eagerly pushed having 4844 in the shorter term roadmap. We ambitiously and perhaps naively were pushing to get it in Shanghai, but are happy to have gotten it in Dencun. Tim was supportive the entire time and did what he could to drive alignment.

Looking forward 🡲

f. priorities: (1) increasing the blob-per-block target. It's still too conservative, and by the next hardfork we should have good understanding of just how high we can bump it before adopting a sharding strategy.

(2) blob sharding, e.g. PeerDAS or full danksharding. I think PeerDAS is a nice step towards full danksharding we can pursue as a safer interim step.

(3) more support for smart contract wallets, whether that's through enshrinement or driving more consensus around out of protocol approaches.

g. improvements: The community is getting pretty big and I'm not sure the fully consensus driven approach taken at ACD is going to scale. One could argue it's already grown obsolete and it's why hard forks take so long. I think we need to consider nominating smaller groups with a designated lead for each big feature and expect them to quickly drive consensus and make decisions when things get stuck?

• EF DevOps

• DevOps Engineer

🡰 Looking back

a. successes: Coordination between all involved teams is going from strength to strength. It feels like the split between the consensus and execution layers has really helped in allowing teams to focus on their speciality without being bogged down. The response to the mainnet incident in May 2023 where the chain wasn't finalizing for a few epochs is a great reflection of this.

b. improvements: We need to move a bit faster. It's a tough ask when complexity and risk are ever increasing, but we need to find ways to make it happen.

c. contributions: I'm particularly proud of the Goerli & Mainnet Big Blocks tests that our team was involved in to decide blob parameters. The idea was to create larger-than-normal blocks and to see the effect these blocks had on propagation time and the network in general. We scaled out our infrastructure to capture more data, and then performed analysis on the effects here.

e. kudos: Terence from the Prysm team was a huge driving force when 4844 was early days. His wealth of knowledge on the subject definitely shaved a considerable amount of time off the development cycle of 4844, and the small little things like weekly meeting summaries really helped with adding momentum to such a large task. Thanks Terence!

Looking forward 🡲

f. priorities: PeerDAS & Verkle! Scaling is our biggest issue right now. I'd especially love to see PeerDAS prioritized.

• Lighthouse

• Client implementer

🡰 Looking back

a. successes: The KZG ceremony was massively impressive.

The improvements we had to network-level testing tools throughout Dencun testing were phenomenal. They have enabled us to spin up testnets much more quickly and with a greater variety of configurations which is really helpful for a big network level change like 4844.

b. improvements: We flipped back and forth on a core part of the 4844 design, whether to propagate blobs and blocks together or separate. Getting everyone across the design and its implications more quickly and facilitating conversations about this amongst a broader range of people may have helped here. Easier said than done though.

Looking forward 🡲

f. priorities: A max effective balance increase would benefit all network participants. The validator set is artificially high due to the current max effective balance and this costs the whole network bandwidth and compute. We will start to hit bottlenecks if the validator set grows too large.

Inclusion lists are an important priority. Being resilient to the centralizing forces of MEV are critical.

g. improvements: Figuring out what goes into the next fork is always a challenge. It would be great to get more voices from outside of ACD onto the ACD calls (end users, app layer devs, etc.). And to perhaps get core devs participating in ecosystem discussions outside of ACD. It's tough to weigh priorities between things of technical importance and things that improve Ethereum UX for example.

Additionally, we are working on ways to make prototyping EIPs in parallel in Lighthouse more painless. This could help us feel confident investing more dev time in things that might not end up in the next fork.

• Erigon

• Protocol/Client Developer

🡰 Looking back

a. successes: Dealing with disasters: There have been many hiccups, the community successfully navigated through them. There were many technical changes to the Dencun EIPs to improve user experience and overall stability of the ecosystem

b. improvements: Definitely timelines. With the whole ecosystem getting so much bigger now, the coordination of timelines have to be taken into account across different clients and other stakeholders.

d. challenges: Txpool in erigon needed upgrade for blob transactions and handling spamming: Txpool upgrades PR

e. kudos: I think Giulio's (from Erigon) work on CL side to get to Dencun was great

Looking forward 🡲

f. priorities: More standardization across clients, with respect to how they consume and exchange data. For instance, we could have uniform config files, dump formats, chain snaphsot formats. We should also focus on EVM more

g. improvements: A balance of protocol improvements as per developers, and those as per other stakeholders like API businesses and users

• Prysm

• client implementer

🡰 Looking back

a. successes: The core protocol community never took shortcuts, always unwilling to sacrifice quality for a quicker timeline. We've made several changes to the protocols, including decoupling blob sidecars from beacon blocks and incorporating block headers into the blob sidecar. This demonstrates the core protocol community's continuous growth and maturity.

b. improvements: We could have spaced the testnet dates further apart by an additional week to include more node operators and gain more insights from the instrumentation. The testnets were upgraded with a gap of under 1-2 weeks.

c. contributions: I contributed to the first interop version alongside Proto and others!

d. challenges: The P2P part was more challenging than the rest. Blobs and blocks were decoupled, leading to certain edge cases that required additional consideration. We ultimately included the block header inside the block sidecar, which resolved most of the concerns.

e. kudos: I don't have anyone specific in mind at this moment, so a shoutout to everyone—whether you are part of the client teams, research teams, or community members on Discord, Twitter, you all made a difference!

Looking forward 🡲

f. priorities: I'd like Electra to be a minor hard fork that incorporates EIPs such as an execution-layer-triggered exit, cleanup of the committee index in the attestation object, and provisioning of validator deposits on-chain.

g. improvements: More break-out rooms! jk!

• Protocol Support

• ACD

🡰 Looking back

a. successes: Client teams have gotten better at articulating their roadmap priorities, and we seem to be getting to consensus more efficiently than we used to.

b. improvements: Too many calls! Breakout rooms and recurring calls have become our default way of moving things along. While there's value in getting on synchronous calls to hash out complex things, I fear we're overdoing it and would like us to bias more towards asynchronous collaboration.

c. contributions: Organizing the Edelweiss Interop, at the top of a 1km mountain.

d. challenges: Splitting the EIP and ERC repositories.

e. kudos: The MVP award for the past couple years goes to the EF testing and devops teams. They've enabled client & research teams to keep increasing the speed and complexity of what we're shipping, while also raising our overall quality bar. Huge, huge, shout out to them!

Looking forward 🡲

f. priorities: Once Verkle is live, we need to actually ship stateless clients. Once that is done, then maybe we can even consider (EOF-enabled?) state rent!

g. improvements: Less calls, more asynchronous, high quality, collaboration. Maybe we start by making both ACDE & ACDC monthly calls and going back to a bi-weekly ACD cadence 😄 ?

• Applied Research Group

• Researcher

🡰 Looking back

a. successes: The community has been exceptional in aligning on a roadmap and maintaining a focused approach. Although the rollup landscape is still in its infancy with room for improvements, we can see projects aligning with the core values of decentralization, censorship resistance, credible neutrality etc, striving to become more and more decentralized. In that regard, it was great to see the community getting together to push towards a shared goal which includes a rollup-centric landscape.

c. contributions: Over the past year(s), I've been building different dashboards on various different topics, summarized under the dotpics "brand". I've been able to open souce tons of data, helping young researchers in getting started on Ethereum-related topics, which was super cool to experience.

e. kudos: Alex, Justin and Vitalik were excellent companions during the onboarding process, while Mike performed exceptionally well, addressing various critical topics such as Inclusion Lists (ILs), Max Effective Balance (MaxEB), and ePBS. Furthermore, Matt (lightclient) has also been an incredible colleague, assisting me with my start at the Ethereum Foundation and consistently providing positive vibes.

Looking forward 🡲

f. priorities: Inclusion lists (or encrypted mempools) can protect us from a future in which a single state could negatively impact dApps to the extent that they become unusable. These lists empower validators to reclaim some authority from block builders and make decisions about parts of the Execution Layer contents themselves. Moreover, even though I am merely an observer in this discussion, as someone who operates nodes, I believe Verkle trees are of paramount importance and should be given priority in order to eventually reduce hardware requirements.

In the medium to long-term future, the focus should continue to be on scaling (increasing gas limits, blob counts, zkEVM, etc), always with the underlying principle of not compromising decentralization or other desired properties. Moreover, it's crucial that the landscape remains open and welcoming to privacy tools, as these are fundamentally important for enabling a free society on-chain.

• Protocol Support

• Special Projects

🡰 Looking back

a. successes: 1. the ability to choose priorities and stick with them (the Merge, withdrawals, EIP-4844) while also 2. maintaining parallel research, implementation, and testing tracks. The Merge took a lot of bandwidth in 2022, but it was crucial that other work begin and continue alongside it: client improvements, verkle tries, KZG Ceremony, research into networking, issuance, improving censorship resistance, etc.

The in-person interop in Austria was crucial to getting everyone on the same page - a well-executed, high-impact event.

Base and Optimism's 4844 work was a good integration of a broader contributor set.

b. improvements: Shanghai and Dencun both took an additional quarter - not much in the grand scheme of things, but can always be better.

We depend on a lot of synchronous calls and it would be better to start transitioning to async processes in the medium/long term.

c. contributions: The Protocol Guild Pilot raised $14mm for over 140 members as part of the 1 year Pilot (May 2022 - May 2023). As a member, I'm proud to see it maturing into a robust independent institution capable of supporting core protocol contributors financially. We are close to a v2 launch, which will expand the trustless characteristics the mechanism depends on.

The KZG Ceremony was an important prerequisite for EIP-4844. I was proud of our interface design and successful engagement of the broader Ethereum community. We were able to gather 141k entropy contributions, making it the largest setup of this kind!

I am proud of this piece - "Capital and enclosure in software commons: Linux & Ethereum." The essay asks important questions about how the core protocol commons engages with internal and external capital circuits.

Delivery at Dawn | a 4844 film. The short celebrated the arrival of EIP-4844 to mainnet, core dev stewardship, and positive-sum Layer 2s. ETH proceeds went to Protocol Guild =)

d. challenges: The KZG Ceremony interface was a new kind of project for me and particularly challenging (managing the complexity of the design and moving it from mockups to live frontend).

More broadly, the project itself needed special attention to broad promotion and accessibility, attentiveness to the needs of contributing participants to ensure it was legitimate to the broader community. This was made even more difficult by the design of the lobby and the presence of bots. Happy to be on the other side of that one!

e. kudos: Cheeky gorilla has been an incredible collaborator for Protocol Guild. Tim Beiko remains the GOAT for his abilities to give shape to permissionless collaboration among disparate parties and synthesize next steps out of competing priorities. Carl Beekhuizen for the wonderful technical collaborator through to the end of the KZG Ceremony. Mike Neuder for being a standout new researcher!

Looking forward 🡲

f. priorities: Not EIPs, but cautions: running nodes and validating should be more accessible. Geographic decentralization of nodes is one thing that Ethereum does well and should be considered when considering the tradeoff matrix of scaling approaches. Yes, there are rational balances to be found, but we should track if the range of our norms is drifting over time.

We should be very careful about enshrinement and preferential treatment. Ethereum has done a good job of this historically and should try to stick to that high standard.

g. improvements: Understand that Ethereum is technical project with deeply embedded cultural and political threads. These are incredible strengths that should not be neglected.

Engage the broader developer/application/user community more consistently. Consensus and legitimacy of process emerge from broad bases. However, as usage and interest in Ethereum continues to increase, it will get harder to manage competing approaches/priorities surfaced by stakeholders (eg. Layer 2s, EVM, app devs, users, core developers, blockspace supply chain, commercial employers). These parties will all try to engage in core development, ostensibly well meaning, but bad actors will try to abuse the open processes to their own private gain. Stay vigilant, and build the protocol for the largest public!

• EF Security

• Security Researcher

🡰 Looking back

a. successes: The core protocol community does a good job of collaborating to both construct and, importantly, sustain the essential infrastructure for this ecosystem. Specs and clients undergo meticulous drafting, writing, refinement, and release processes. Moreover, when issues surface on the mainnet, community driven problem-solving resolves them.

b. improvements: Identifying precise areas for improvement within a decentralized group poses a challenge, as it suggests a predefined path toward a clear goal. I do think there are some unique challenges that we currently have that may require a different approach than shipping a desired new feature.

c. contributions: I've invested substantial time scrutinizing code, uncovering issues, and conducting various interop-testing. Multiple teams are actively engaged in similar efforts, and I'm proud to be a part of that process. It takes a village.

e. kudos: Devops.

Looking forward 🡲

f. priorities: Decentralization concerns and incentive alignment always come to mind as things that I think need to be addressed.

Thanks for reading to the end! Let’s continue building towards better worlds on Ethereum. Be sure to check out the Delivery at Dawn short to celebrate the ongoing stewardship of Ethereum core contributors.

https://opensea.io/assets/0x72d07BeEBB80f084329Da88063F5E52f70f020A3/1

Dencun and EIP-4844 went live on March 13, producing incredible cost reductions for Layer 2s. Dencun Diary is a compilation of +45 core Ethereum contributors looking back on the last two years, and looking ahead to what’s next. This piece features client developers, researchers, and coordinators from 28 different teams.

We hope you enjoy the sentiment snapshots from this time - thank you for reading and being part of the Ethereum story!

Stateful Works creates cultural artifacts for the Ethereum community - see previous versions of this type of project with Merge Manual and Beacon Book.

Also be sure to check out the mint for Delivery at Dawn | a 4844 film! The film celebrates EIP-4844, core dev stewardship, & positive sum L2s! Mint proceeds go towards production costs (20% to Nouns) and Protocol Guild (80%): a collective of Ethereum core contributors.

https://opensea.io/assets/0x72d07BeEBB80f084329Da88063F5E52f70f020A3/1

Responses were collected in February and March 2024, both before and after the upgrade. Respondents may have not answered all prompts. While all core contributors were invited, only a subset submitted to be included. If you intended to submit but were not able to before publishing, please reach out to Trent. Perspectives should be taken as the opinion of the individual, not necessarily that of all core contributors or their respective organizations.

🡰 Looking back 2 years on Dencun, 4844, KZG Ceremony, or other research tracks

a. successes: What has the core protocol community done well? Consider timelines, mainnet incidents, deciding priorities, managing scope, coordinating on ACD, etc.

b. improvements: What should the core protocol community have done better?

c. contributions: Do you have any contributions you are particularly proud of?

d. challenges: What was the most challenging project you worked on? Impossible bugs, unexpected complexity, failed experiments.

e. kudos: Is there someone whose work you particularly appreciated, or you feel went above and beyond? What did you specifically appreciate about their contribution?

Looking forward 🡲

f. priorities: Which protocol improvements should be prioritized in the near, medium, and/or long term? Why?

g. improvements: What should the core protocol community do to improve our processes in bringing future upgrades to mainnet?

• Lighthouse

• Client Implementer

🡰 Looking back

a. successes: Amazing co-ordination and huge efforts from all teams on testing, making sure everyone is up to scratch for mainnet.

b. improvements: As always with a large group of people, coming to consensus on priorities and timelines, but it's to be expected.

c. contributions: I wrote a production version of a gossipsub upgrade called episub to improve network-wide transmission of blobs. In its current form, we've decided not to add it to production. However, we're adding smaller modifications/improvements and perhaps a future fork will contain something resembling episub.

d. challenges: Simulating and modelling the network dynamics of mainnet. We tried big-block experiments to estimate how large amounts of data transmits through the mainnet network and we built simulators that model large scale networks. In my opinion, it was one of the most difficult tasks to try and estimate how a large network-wide change will affect a currently operating real-world large scale distributed network.

e. kudos: Sean and Pawan from the Lighthouse team. Among the many upgrades in the Lighthouse code that needed to be modified for the fork, one was the syncing algorithm. This is notoriously difficult to understand and debug. These two not only updated this part of code but rigorously tested it and ironed out all of the bugs, which was an amazing feat.

Looking forward 🡲

f. priorities: There are a lot which are in active discussion. Aside from Data Availability Sampling (which we are currently actively working on) I'm just going to mention my support for increasing the max effective balance. I think, perhaps the mid-term we should work on increasing the max effective balance, because it will have amazingly positive consequences at the networking layer by reducing validator count. This means fewer messages, less load and less bandwidth on the network. This allows home stakers to use less-powerful PC's, gives a greater margin of error when introducing larger messages in upgrades, and potentially paves the way for smaller epochs (the holy grail being single slot finality).

g. improvements: We are shipping forks. Seems to be working from my point of view. Don't fix what's not broke :)

• EF DevOps

• DevOps

🡰 Looking back

a. successes: From ACD to the KZG ceremony, coordination and communication of the core protocol community has always impressed and inspired me.

c. contributions: Being able to use our Ethereum network monitoring tool Xatu for big block testing to help prepare for 4844.

d. challenges: Forky, our fork choice explorer, was definitely a challenge for my meagre frontend skills.

e. kudos: Mario Vega, always working hard behind the scenes to make sure this train stays on the tracks.

Looking forward 🡲

f. priorities: PeerDAS in the near for scalability, Verkle in the medium for statelessness and Account Abstraction for user experience.

• Consensus R&D (EF)

• Cryptography/security

🡰 Looking back

c. contributions: I have thoroughly reviewed the cryptographic code relevant to the ceremony and the KZG commitment scheme,

e. kudos: I am impressed how such a complex piece of cryptography was implemented so smoothly.

Looking forward 🡲

f. priorities: I believe that delivering full data availability sampling (DAS) is pivotal for the future of Ethereum.

• EF DevOps

• Devnet launcher

🡰 Looking back

a. successes: Speccing out different EIPs, and iterating over different features requests as they came in. We had 12 different devnets and each of them was more and more featureful. I really enjoyed working together with all the different client teams, and was very happy to see a new one rise up from 0 to hero (reth).

b. improvements: Decision making about which EIP to include and which one to leave out for next fork needs to happen more firmly. There were a lot of EIPs that were up in the air for a long time. And now I'm seeing the same for Electra. I feel like we should have a very well defined path going forward with concrete plans for the next 5 years. And what we have currently, is more like a concrete plan for the next 6 months (not even that right now).

I think a well defined path for the next updates would give a better indication for the client teams too, so they would know what work to prioritize and what is important.

c. contributions: I've personally been putting a ton of effort into improving kurtosis. Currently it's able to spin up a new devnet in under a minute; sync up a public testnet; create a shadowfork; create verkle shadowforks (currently WIP), all while supporting the standard set of known toolings, like forkmon, ethereum-metrics-exporter, xatu, blobscan, blockscout etc.

I really hope to see more client teams getting involved with this, and integrating it to their CIs one way or another.

d. challenges: None of the projects were very challenging per say, but we had a lot of work on getting our workflow adjusted to our needs.

e. kudos: My whole team, ethpandaops and g11tech from Lodestar, who was always the first one to have an image ready to test for whatever new feature we wanted to onboard. But I have had a great time working together with everyone throughout the whole year, in person and in the digital world.

Looking forward 🡲

f. priorities: I'm just here to test lol. I let protocol changes be decided by those that understand it all.

g. improvements: We need to have better timelines, and more defined timelines for future forks, potential inclusion of future EIPs. I would like to see a 3-5 year defined timeline, and a EIP list for all the upcoming forks. Nothing needs to be written in stone, but would be a very good indication of where our priorities stand.

• Robust Incentives Group

• Team lead + Research scientist

🡰 Looking back

a. successes: Scaling has been well-prioritised as an existential concern for Ethereum, and 4844 appears to arrive at the right time when the pressures of the current network to serve existing rollups are more apparent. Research has also delivered answers on many important questions, including staking, PBS/MEV, cryptography.

b. improvements: It always feels like we should want the hard forks to be done earlier, but it is hard for me to pinpoint exactly where time could have been better spent. From a research perspective, in hindsight, more energy could have been spent on staking economics and less on PBS/MEV.

c. contributions: (1) Seeing like a protocol This post has been important to orient my contributions to Ethereum and frame them in the larger context of development. (2) Unbundling PBS: Towards protocol-enforced proposer commitments (PEPC) It's still unlikely to see a general PEPC become enshrined, but its main ideas seem to have percolated widely, and resonated with many who work on markets related to Ethereum. (3) Timing games paper From an ethresearch post to a "RIG Open Problem" to a paper to seeing it happen on mainnet — never a dull day in research, what can I say! Not an easy lift, but props to Caspar also for his tireless advocacy.

d. challenges: We tried for a while as a team to solve a difficult model of the PBS auction. In the end, though we didn't have a crisp result, my impression is that we still learned a lot, and got good material out of it for follow-ups or other projects. Julian gave an excellent talk about some of these efforts at SBC, A Dynamic Auction Model for PBS.

e. kudos: I will take the easy way out and not be specific: Anyone who joined EF research in the last two years has brought new energy and new ideas, and I would assume it's the same on the development side. Grateful that our space still attracts bright minds!

Looking forward 🡲

f. priorities: In my opinion, we should be looking to a near-ish future where shipping protocol updates is much more difficult, so we should be aggressive in terms of our updates, privileging "endgame" solutions that preserve optionality, and being comfortable with possible incompleteness. Some ideas that fit the bill are single-slot finality, full Danksharding, execution tickets, censorship resistance gadgets and a holistic review of staking UX, including the reward curve.

g. improvements: We've generally felt in our team that we should get closer to the development process, we're still looking for ways to do that but it doesn't feel like a bad idea regardless to bridge the gap more between research and development. I would also be in favour of any initiatives to bring in more eyes on critical upgrades, via grants, requests for comments or any other programmes, this seems like an unequivocally good thing.

• Teku

• Consensus client development

🡰 Looking back

a. successes: Well, we made it :) The challenge of coordinating across so many researchers, developers and other ecosystem stakeholders is immense. And all done in a fully non-hierarchical, entirely collaborative way. It really shouldn't work at all. But I continue to be impressed and delighted that our methods keep delivering - it is truly Ethereum's super-power.

A particular shout-out to those running testing infrastructure - the devnets, the shadow forks and all that. I feel like our ability to test upgrades at scale has levelled-up considerably, largely thanks to the spectacular EF Devops crew.

b. improvements: Timelines, as ever, were difficult. In late 2022 we fought off pressure from the L2s in order to prioritise delivery of withdrawals (Shanghai-Capella) by suggesting that EIP-4844 (Cancun-Deneb) would be a "fast follow-on" in mid-2023. That was fanciful, and we probably knew it was fanciful. However, we just about got away with it thanks to a lucky summer and autumn of low gas prices on Ethereum Mainnet, which markedly reduced the urgency.

We also had changes along the way. In January 2023 we decided to decouple the blobs from the blocks for better propagation. This was the right thing to do, but probably added a few months to the overall timeline. In late 2023 we modified the design to include the block header in the decoupled blobs. Again, the right thing to do - a "no brainer" - and a relatively minor change. But it was disruptive coming so late, and delayed deployment to testnets. In hindsight, we should have spent more time thinking through blob-decoupling back at the start of the year.

c. contributions: As a weekend project back in 2021 I wrote some data availability sampling demo code (c-kzg) in C, guided by a Go implementation that Protolambda had done. This got adopted and transformed into the "official" c-kzg-4844 library that some clients are using now. Most of my original code has been stripped back (it was for a full dank-sharding demo), but my bindings for the blst crypto library survive!

Looking forward 🡲

g. improvements: Fork early and fork often.

• Consensus R&D (EF)

• researcher

🡰 Looking back

c. contributions: The KZG Ceremony worked really well. Porting over the approach of starting with a (maximally) simple specification, which allows for many implementations of a piece of software. This is a guiding ethos of the consensus specifications and is a driver behind us having so many consensus clients. In much the same way, the kzg-ceremony-specs allowed for 9 different KZG ceremony clients, massively reducing the chances for a coordinated failure.

d. challenges: Trying to debug code around the KZG ceremony. Cryptography is uniquely annoying to debug: when things don't work, you just get "hex-string A does not match hex-string B" and the only way to debug is to think through the algorithm, the brute-force printing intermediate just leads to more meaningless hex-strings.

e. kudos: Trent Van Epps was my partner in crime in coordinating the KZG ceremony. He was instrumental in keeping things moving forward while I got stuck in the weeds. His designs for the website at ceremony.ethereum.org really captured the spirit of the ceremony.

Looking forward 🡲

f. priorities: PeerDAS and similar scaling infrastructure. 4844 and blobs are great, but should we start to see decent adoption of rollups, 4844 blobs will very quickly prove inadequate and L2 transaction pricing will go through the roof.

• Consensus R&D (EF)

• research/spec

🡰 Looking back

a. successes: security. Ethereum remains very secure with unmatched uptime. This is the confluence of many factors, including the diverse range of expertise, the multi-client/spec-first approach, testing, devops, and ultimately the "we have to do it right" (at almost any cost) attitude.

b. improvements: We waffled a couple of times on decoupling blobs. I pressured them to start decoupled, I then campaigned for the re-coupling at devcon bogota, and then finally they were re-decoupled at the impetus and compelling arguments of Jacek at interop-austria. Decoupled was the correct path, but oscillating here cost us.

In this same domain, gossiping headers along with blobs to inherit slashability of duplicate blob p2p messages was such a beautiful and obvious solution. But no one thought about it until Francesco poked his head in. It's not clear exactly how to have expedited this serendipitous moment, but we would have been much better off having had it 12 months prior...

c. contributions: I'm pretty sure I was the first one to discuss the abstraction of is_data_available() being the path to synergize 4844 with "full danksharding". This made its way into the spec and imo is the proper abstraction/way to think about upgrading the data layer. Nothing crazy, it likely would have happened without me.

e. kudos: Codex has been working on DAS research for the past year. They really stepped up and went above and beyond in the mainnet big-blocks analysis which was very impactful in picking the safe 4844 mainnet parametrization. Huge shoutout

Also big shoutout to Mario and the EF testing team. Testing networking is very difficult and their infra has evolved in great ways to not only test 4844 but many of the future networking challenges.

Looking forward 🡲

f. priorities: PeerDAS. Ethereum has global, secure scale within reach. Getting PeerDAS out is a clear and actionable way to achieve it.

• Lighthouse

• Client implementer

🡰 Looking back

a. successes: Execution of the roadmap in parallel to reach the endgame faster :) All the "urges" have been on heavy parallel research for a while, now it's time for implementors to become highly multi-core

b. improvements: Engage with tail-end topics like economic policy or EIP-7514 sooner. Focus tends to be gobbled by the main features causing rushed decisions at fork deadlines.

e. kudos: It brings me great peace of mind to know that Francesco is around making sure that our EIPs don't introduce sneaky consensus risks.

Looking forward 🡲

f. priorities: With a solid danksharding spec widely accepted by the community, there's a lot of energy and momentum to bring it to reality. By far the best return-on-investment ticket on our roadmap menu.

g. improvements: Now we are a 150 strong core dev force, so we could aim to be more ambitious and deliver forks in a stable frequent cadence.

• Reth

• client implementer

🡰 Looking back

a. successes: enjoyed it

b. improvements: nothing

c. contributions: working with Michael Sproul on lh db code was really great, he's a great mentor

d. challenges: everything can be solved, doing it as minimally as possible is the challenge, and to do so one must relax for starters. a stressed mind builds clutter.

e. kudos: Michael Sproul's pr reviews - they're so accurate they gave the rest of the lh team the ability to work with 'fearless concurrency'.

Looking forward 🡲

f. priorities: projects lead by Felix Lange should be allocated resources, in terms of core dev man power! network design needs more love, from someone with expertise.

g. improvements: nothing

• EF Security

• Security Researcher

🡰 Looking back

a. successes: The collaboration and team spirit of everyone involved in this process never ceases to amaze me. People are always more than happy to jump on a call to help solve an incident, or provide valuable feedback and help each other even though people are working on different types of implementations. I believe that this successful collaboration is one of the most important aspects which makes it possible to successfully coordinate with regards to deciding priorities and scope to ensure new hard forks can be shipped within a reasonable time.

b. improvements: One of the most common issues is keeping up with timelines. While there is often no hard timeline decided for when something is to be shipped, there is often a soft timeline. Given the additional complexity and increased efforts in security, testing and more, it's not too surprising things are taking longer to complete. I believe that trying to ship less features in each hard fork and at a more frequent rate could be beneficial.

c. contributions: I would certainly say that the main thing I'm proud of is what we have all accomplished as a group. From a security point of view, some of the contributions that I'm very happy that I had the honor of being part of is starting up the Client Security Calls which is being used to help coordinate security amongst the different client teams, coordinating grant work to help provide funds to security researchers looking to do various security projects, helping to coordinate security audits on 4788, lodestar, AA, KZG and additional projects. I've also worked with various ecosystem public good projects such as the Security Alliance to help increase security for the ecosystem, providing help to the Ethereum Protocol Fellowship and Devcon Scholars Program for people interested in Protocol Security.

We also set up dedicated fuzzing infrastructure that is being used to fuzz everything from clients, networking, kzg, critical dependencies and more. The output of this work has resulted in many issues which were possible to be corrected before hitting mainnet.

The bug bounty program also saw it's most successful year so far with regards to paid out rewards. After the Dencun hardfork, we will as always publish a public disclosure of the vulnerabilities found in the previous hardfork.

d. challenges: Given the many supply chain attacks that have happened around the world these past years, I spent quite a bit of time researching the potential impact various dependencies could have on the Ethereum network if they had vulnerabilities in them that could be exploited. And given the number of Execution and Consensus clients, each with a wide range of dependencies which in turn have subdependencies -- sometimes it seems like a never ending tree, but it's a continued effort.

e. kudos: I'm honestly equally appreciative to everyone involved in this process. It's obvious that this is more than a job to people, and everyone is always doing their best which for some is taking on a more public role and for some to really dig down into something technical. To me, everything is equally important and works as a symbiosis.

Looking forward 🡲

f. priorities: One of my highest prioritized protocol improvements are related to MEV. Exploring potential paths to improving the current implementation of PBS and how to increase censorship resistance. I am also very keen on improving privacy, both for users and validators.

g. improvements: I touched on this earlier, but I believe it could be wise to at least analyze and give our existing process some thought when it comes to shipping upgrades to mainnet. I feel like often we decide on a large and important thing to focus on for the next hard fork, make a rough timeline, and if it seems like it's not too long some smaller things can be included. Another way of doing this could be to have somewhat scheduled upgrades two times per year. This could potentially mean we could ship smaller less complex upgrades more frequently, while running the larger and more complex upgrades as a side track.

• Lodestar

• client implementer

🡰 Looking back

a. successes: Fantastic final design, great execution and testing

b. improvements: faster design iteration

c. contributions: proud and grateful to lead this hardfork for lodestar and ethereumjs

e. kudos: I feel the entire dev community really outdid themselves on this.

thanks dapplion for your spec contribution, cayman, tuyen for the feedback and reviews. thanks phil for the PM support and other members of lodestar team who kept working on the client on various aspects, thanks pari and barnabas for intense devnets and testings, thanks kev and team for c-kzg, thanks andrew and jochem for their ethereumjs 4844 contributions and holger for the the support and reviews

thanks to EF research and testing, specially mario for the amazing hive tests, thanks to other client teams for their contributions

Looking forward 🡲

f. priorities: peerDAS for furthering the dataspace, IL for censorship, universal sequencer to unify L2 liquidity.

g. improvements: keep doing the good work and keep encouraging novices like me lol

• Besu

• client implementer

🡰 Looking back

a. successes: Dencun's success can be attributed to effective community engagement, and strategic planning.

The communication around EIP-4844 was both effective and engaging. Various posts and blogs about 4844 presented a clear and impactful narrative. They highlighted the value Deneb brought to users through support for Layer 2 scaling and reduced fees. Critically, the open engagement with the community during the KZG ceremony built trust, hype, and provided a meaningful way for crypto enthusiasts and users to contribute and feel like stakeholders. These were all great wins for a hardfork that largely is not bringing new user-facing functionality.

Parallel work on Deneb alongside the Shanghai upgrade proved to be a strategic decision. Early interoperability testing provided a sufficient runway to identify the most supportable parameters, ensuring a smoother integration and better overall outcomes. This foresight in planning allowed for a more thorough and less rushed exploration of potential issues and solutions.

Moreover, setting the ambitious goal of having a Deneb testnet ready for the interop event served as a significant motivator for all involved client teams. The collective desire to achieve this milestone at the interop built early momentum and front-loaded a lot of the work for dencun.

b. improvements: The Cancun hardfork initially showed promising momentum, especially during the interop event at Edelweiss, with working testnets in February 2023. However, for various reasons, this momentum seemed to wane over time. The anticipated delivery dates experienced several shifts, moving from late Q3 to Q4, and eventually to Q1 of 2024. While testing and refinement are essential to ensuring a successful hardfork, it seemed to me that dencun lost priority and focus the closer we got to it.

As suggested by others on ACD* calls, we should commit to target timelines earlier in the hardfork scoping process. Committing to soft targets earlier in the process will help right-size scope when considering EIPs for inclusion and should help us deliver feature forks on a more predictable cadence.

Looking forward 🡲

f. priorities: Looking ahead to Ethereum's development priorities, it's clear that Verkle tries and EOF should be the headliners of the next two hardforks. Learning from the successful parallel work on Withdrawals and EIP-4844, we should expect to work on both simultaneously with very clear lines of communication and collaborative specification to ensure that neither makes the other more difficult.

Verkle tries are high priority not only because it becomes harder and harder to transition as the state gets larger, but more importantly verkle makes stateless execution and stateless clients possible. This directly supports Ethereum's principles of decentralization, permissionlessness, censorship resistance, and self-sovereignty. By implementing lightweight stateless clients, we will unlock new use cases that are currently unimaginable, further expanding Ethereum's utility and reach.

EOF addresses the equally essential task of resolving the technical debt within the EVM. Modernizing the EVM and enhancing smart contract safety through formal verification might not grab headlines, but it is key for the ecosystem's long-term stability and security. This foundational effort will ensure Ethereum remains a robust, fast, and secure platform, benefiting the entire community.

• Reth

• Team lead

🡰 Looking back

a. successes: Scoping and shipping Dencun was monumental, we found the KZG libs very useful, and we thought the testing process was excellent.

b. improvements: The community should level up its use of precisely written scientific communication. Calls are expensive time-wise and should follow standard pre-read, discussion on what could not be addressed async in writing, and clear action items with deadlines and strong expectation setting.

Being decentralized doesn't mean we cannot admit a strong high performance and accountability process. We must do better there. People should write and communicate precisely.

c. contributions: We stood up a state of the art node in less than 2 years and we're very proud of that. We think our benchmarks are really remarkable, see our beta post.

We think we're just scratching the surface of "High Performance Ethereum" and we're excited to do more.

d. challenges: The Merkle Patricia Trie code remains always the trickiest in Ethereum. This took us months of squashing and optimization, but we're finally happy with the result. We've published our work here!

We also found the integration with various Engine API edge cases to be weird at times, eg. the newPayload / getPayload vs FCU API. The team can expand more on this.

e. kudos: EF Devops are the real MVPs, congrats. And the entire Reth team has worked overtime every day since we started the project, and their work remains the biggest privilege to experience in my career.

Looking forward 🡲

f. priorities: We shared our view here. We're excited for teams to do more such writing and hope to set a new bar here.

g. improvements: Our strong view is we need benchmarks and more automated tooling for executing such stress tests. We loved the EF Devops teams work there and we need ten more of these.

We also think more rigorous historical analysis is needed to determine optimal values for various protocol parameters like the gas limit.

• Consensus R&D (EF)

• Researcher

🡰 Looking back

b. improvements: We underestimated the time needed for network testing since Dencun represented the first significant networking upgrade post-Merge. On a positive note, this experience highlighted the benefits of gradual upgrades, i.e., transitioning from Proto-Danksharding to Full-Danksharding, as a favorable approach.

d. challenges: The static reorg fork choice test vectors for edge cases. There was a small working group that tried hard to identify the attack vectors and solutions related to the fork choice reorg issues. After approximately one year of rigorous effort, we finally delivered it into Capella upgrade.

e. kudos: 1. Needless to say - a big thank you to Dankrad Feist for his brilliant idea and relentless dedication. 2. Thank you to Dapplion, Etan Kissling, Wenceslas Sanchez, Mikhail Kalinin, Justin Traglia, and many other consensus specs contributors! <3 3. Edelweiss Interop was really great. Thank you to Tim, Danny, and La Donna. 4. Thank you to Tim and Danny for hosting the ACD meetings.

Looking forward 🡲

f. priorities: 1. EIP-7547 (Inclusion Lists): It's good to improve Ethereum censorship resistance before it's too late. 2. EIP-7594 (PeerDAS): It's what we need for unlocking another level of scalability. 3. Staking mechanism and economic improvements.

g. improvements: 1. Rotate ACD meeting time: I still hope to see some attendance of Oceania devs, even if it's just once in a while 2. An online Miro priorities discussion workshop may help collect the vibe checks of over 100 people efficiently

• Stateless consensus (EF)

• Engineer/Researcher

🡰 Looking back

a. successes: I think the coordination between the KZG Ceremony and overall 4844 efforts was done correctly, and efficiently. Running the KZG ceremony transparently/verifiable and correctly had deep implications for the future security of Ethereum.

c. contributions: I'm proud of writing the most used non-official KZG ceremony client, and the most used one for the special projects phase. In particular, one of the special projects used this client to contribute from a satellite in space. See the client repo here!

e. kudos: I wasn't tracking detailed work on 4844 per se, but on the KZG ceremony front I'd like to give a shout out to Carl and Trent for all the coordination and community communication for that project.

Looking forward 🡲

f. priorities: For medium and long term I believe Ethereum should keep pushing on it's core values:

• Improving scalability, with next phases of 4844 (i.e: PeerDAS, full dandsharding, etc)

• Improving censorship resistance, with inclusion lists or any other proposal that improves one of the most important values of the network.

• Improving decentralization: with Verkle Trees we can keep lowering the hardware bar for nodes to verify the chain, and potentially considering increasing the gas limit.

I believe we should try as much as possible to focus on improving what makes Ethereum different from the rest.

g. improvements: I think EIP champions that want to propose their EIPs for the next hard fork, could try doing a bit of more elaborate work on why their change is important for the Ethereum network. As in, if improves Ethereum core values (i.e: which ones), who wants that change, what would happen if we don't do that change and leave it to a future fork, etc -- thus answering some set of "defined" good questions. Even though natural discussions in ACD calls are nice, this more structured "EIP proposal" questionnaire can help core devs take a better decision (or simply assist those calls).

• OP Labs

• client implementer

🡰 Looking back

a. successes: The devnet infrastructure for multi-client testing is impressive.

b. improvements: Getting client teams engaged was difficult. It took nearly a year to get interest and buy-in from client teams. The upgrade's scope crept unnecessarily as we later decided to couple EOF with EIP-4844, even though they were unrelated.

e. kudos: Jacek Sieka for coming up with a more rigorous blob decoupling proposal.

Looking forward 🡲

g. improvements: Having a process for cross-layer collaboration would be very good. This relates to specifications (EIPs are inadequate for this sort of collab) and ACD meetings, which tend to be execution focused.

• Prysm

• client implementer

🡰 Looking back

a. successes: All of the calls and tracking has been very good from the foundation perspective. Big props to those working on the testing and I think devops has greatly improved since early days. We became more pragmatic and focused through this process and especially after the austria trip i think which was great.

b. improvements: Some of the detailed discussions were more in internal channels and pair programmed groups in the early phases and I wish i was more involved or at least caught up in that regard.

c. contributions: I'm proud to have contributed to the API endpoints that enabled Deneb on the Prysm Consensus client.

d. challenges: It's not related to consensus work but tech debt, my work on cleaning up some of the prysm codebase and helping with the api migrations might have been the most challenging work thus far.

e. kudos: I think most of my teammates work has constantly showed passion for the space that goes above and beyond the ask for any standard job; the initiative, the leadership, the execution were all exceptional.

Looking forward 🡲

f. priorities: our team published this piece when we aligned internally, ePBS might be an additional item we are pushing for.

g. improvements: not sure but some way to improve collaboration for more introverted core dev members might be good across teams. working sessions to get newer core devs on the priorities discussed thus far that's more casual than the all core dev calls.

• Coinbase, then Base

• Contributor to 4844 workstream; leader of L2

🡰 Looking back

a. successes: Was so inspired by everyone coming together to ship 4844. I appreciated the balance of pushing for shipping as quickly as possible, while also ensuring there was rigorous design and rollout. Feels like the process of shipping 4844 has also helped build our collaboration muscle and improve our ability to deliver together.

b. improvements: I have really enjoyed the new habit of core development teams sharing their priorities in written form. We didn't do that during the Dencun planning process and I think it would have contributed to a more effective process.

c. contributions: I'm proud of helping rally folks and build momentum in 2022 / the first half of 2023, as well as marshalling the resources from Coinbase to contribute from the very beginning.

e. kudos: I think Roberto Bayardo played a critical role bringing the initial prototypes to viability, driving a number of complex technical decisions, and getting the OP Stack ready to ship 4844 support on Day 1.

Looking forward 🡲

f. priorities: I would like to see continued focus on increasing blobspace capacity via increasing the 4844 target/max and implementing PeerDAS (and the full danksharding roadmap). This should be counterbalanced with other key priorities like decentralization.

g. improvements: Keep encouraging teams to write down their priorities and focus.

• Robust Incentives Group

• Researcher

🡰 Looking back

a. successes: I think it is special how welcoming the core protocol community is to new entrants. Some of the people that have worked on Dencun upgrades could work on these topics quite soon after they got into crypto. This unique atmosphere allows us to achieve milestones quickly.

b. improvements: The emergence of "coordination calls" that are maybe similar to ACD, such as the mev-boost community call and RollCall are I think very helpful. Maybe we should acknowledge that the protocol is growing and that out-of-protocol solutions are super influential. Maybe we should be better at acknowledging the importance of how these communities govern themselves.

e. kudos: Mike Neuder has done amazing work on ePBS, max EB and ILs. I really appreciate his way of thinking and how fast he iterates on desgins!

Looking forward 🡲

f. priorities: I think a censorship resistance solution would be very nice. I don't know how pressing the problem is since censored transactions still get included within a reasonable amount of time now, however, this could shift quickly.

• Consensus R&D (EF)

• researcher

🡰 Looking back

a. successes: Data availability is a cleanly delineated module of the Ethereum stack, largely independent from core consensus and execution. It's a fantastic outcome that researchers and devs can focus on independent modules and that Ethereum has such parallelised R&D.

c. contributions: This may sound counter-intuitive but I am especially pleased to have made essentially zero contribution to 4844 and Dencun more generally :) Plenty of JOMO (Joy Of Missing Out)!

e. kudos: Cheers to everyone who helped get 4844 across the line—a monumental effort that will pay dividends :)

• Besu

• client implementer

🡰 Looking back

a. successes: EIP-4844 was the first time we saw L2s design an upgrade with the core devs in a really substantial way. I was impressed to see folks from Optimism and Coinbase take a leadership role, without really influencing what should be done. I was also really proud of the way the community rallied around our need to generate some entropy for the KZG trusted setup. Nothing on that scale has ever been done, and we made it a fun, community building event.

b. improvements: I think we could've done a better job of keeping L2s engaged after the design phase. Later in the process, during testing and review, I felt we were lacking participation and feedback from L2s.

c. contributions: I really enjoyed working with the testing staff at EF. I got more fluent with the Hive test suite, and am looking forward to incorporating it more into Besu's SDLC. Building Hive was a wise investment by EF, and it was fun being able to collaborate on how specs were interpreted. Some of those insights even made it back up into the specs to clarify things.

Oh, my special contribution to the KZG ceremony was a ton of fun too. It's a bit romantic, but I love the idea that an annual game my friends and I played will live forever in the entropy that Ethereum will use to scale.

e. kudos: Shoutout to the EthPandaOps crew- especially Pari and Barnabas. Mad props to Mario who was a great collaborator on the Hive tests, and Mikhail who used our learnings to further clarify the execution specs. Y'all make a dev feel loved!

Looking forward 🡲

f. priorities: Inclusion Lists and ePBS should be our next urgent priorities. We've conceded too much ground to the forces of rent-extraction, and are already having to design around MEV relays and block builders. Inclusion Lists are a mechanism needed to fight the censorship introduced by MEV, and that correlation is not a coincidence. I am here to make abusing power harder, and it is still not hard enough.

g. improvements: I think our process is awesome and needs no improvement. Any efficiencies to be gained would be negligible. A+ project, no notes.

• EF Security

• Security Researcher

🡰 Looking back

c. contributions: I am particularly proud of my contributions to c-kzg-4844. A lot of the implementation work was already done when I started contributing, but I helped turn it into a production-ready library worthy of being used by Ethereum clients. Notably, I figured out how to include Golang bindings and convinced Supranational to finally add CPU runtime detection to blst. I had a lot of fun working on this library and learned a lot about cryptography in the process.

d. challenges: We had the most annoying bug in c-kzg-4844's Rust bindings. On Windows, sometimes we would experience a stack overflow when verifying a proof. Pawan Dhananjay and I had spent a whole week trying different things like increasing the stack size, "boxing" blobs so they are allocated on the heap, and using different Rust versions. After I had given up all hope, Pawan somehow figured out that it was related to blst. He discovered that under certain circumstances blst would define a boolean (1 byte) as an integer (4 bytes) and rust-bindgen did not like this. After this point, we quickly figured out a fix and moved on with our lives.

e. kudos: I really appreciated working with George Kadianakis (@asn-d6) during this upgrade cycle. He is an excellent cryptographer, researcher, and friend. He was an important contributor to the Polynomial Commitments API specification/implementation for EIP-4844. George is the first person I go to when I have a cryptography question. I thought his (also Ansgar's and Dankrad's) ethresearch post about a Universal Verification Equation for Data Availability Sampling was genius; it made batch verification of sample proofs very fast & efficient.

Looking forward 🡲

f. priorities: I am a strong supporter of EIP-7594 aka PeerDAS. I think it should be prioritized for the near-term. Ethereum needs to scale to remain competitive with other chains. PeerDAS does not necessarily require a hardfork because it does not change consensus protocol, it just changes how blobs are distributed and stored.

In the medium-term, EIP-7251 aka MaxEB would be a welcome change. Consolidating validators would reduce load on the network and would allow solo-stakers to earn rewards on ETH we have sitting on the sidelines. Also in the near-term/medium-term, I would like to see Ethereum improve its quantum resistance. I am afraid that quantum computers which could threaten Ethereum will be here sooner than we think.

• EF cryptography

• cryptography implementer

🡰 Looking back

a. successes: I think the core protocol community has done well in splitting up the vision of ethereum into smaller manageable projects.

b. improvements: I've historically worked in smaller specialized communities in the core protocol, that I think have gone well so far. Theres always room for improvement though!

c. contributions: For KZG ceremony: Researching all of the previous ceremonies and writing up the rationale for why the simpler approach works - see important precedent from Mary Maller here. This meant that the ceremony was significantly simpler.

For 4844: I'm proud that I was able to push for the change to completely separate the cryptography from the rest of the protocol and create a more higher level API. This meant that client devs did not need to care about how the cryptography was implemented.

For Verkle tries: I enjoyed rederiving the barycentric formula and the formual for division by a linear polynomial where the linear polynomial is zero on the domain -- see my notes here.

It was pretty cool to also note how it generalized the previous formula where the domain was the roots of unity.

d. challenges: Out of the projects I've worked on at EF, I think verkle tries were the most challenging because for quite a while we were experimenting, benchmarking and exploring different design choices which necesitated quite a few code rewrites. Its also the longest ongoing project that I've been on which might play into my bias here.

e. kudos: I have three people.

Dankrad Feist has been extremely supportive and patient during my time at EF.

Justin Traglia has shown me through his contributions in 4844 that he is extremely dependable.

Ignacio Hagopian is an unsung hero for verkle tries and is someone that I enjoy working with a lot.

Looking forward 🡲

f. priorities: Very biased opinion: I don't have a particular protocol improvement, I do think we should continuously be asking ourselves "How does this play with zkSNARKs?"

g. improvements: I think:

• Integrating and seeing what fails as soon as possible

• Limiting the scope of features so that we can ship fast and possibly moving towards a more iterative approach to features.

• Geth

• client implementer

🡰 Looking back

a. successes: It's easy to get lost in the minutia of priorities and timelines. We have so much still we'd like to do to improve Ethereum. But looking back at the last two years, we are really shipping at a rather high velocity given the size of this project.

Two years ago, Ethereum had still not even transitioned to PoS. We quickly followed with the Shanghai hardfork enabling withdrawals. All the while, thinking ahead to data scaling with 4844.

It's really incredible when you think about it.

b. improvements: It's hard to fault ourselves in retrospect for the path we followed to Dencun. There were many different, unrelated work streams which needed to converge to be prepared for the upgrade. Additionally we had to do a lot of new things to prepare for this fork, particularly with testing the networking load of blobs.

Although it would have been nice to have 4844 in 2023, it isn't clear what could have been done better to achieve that.

c. contributions: Update EIP-4844: change op to BLOBHASH -- jk, I'm proud of working on the 4788 contract.

d. challenges: Probably trying to pass the hive tests haha. The team has done a great job with creating a lot of detailed test cases.

e. kudos: I'm thankful for Marius and all the testnets he destroyed on the way to dencun! He really has a special knack for sussing out weaknesses in networks.

Looking forward 🡲

f. priorities: I think we should improve the experience of running nodes. Not just as a home staker, but also as a home user who does not want to rely on centralized infrastructure.

g. improvements: These are all hard questions. I think despite some frustration at times with the process, it is working. So I'm not sure how much can be done to improve it. Building a project of this scale in the open is going to be complicated. No way around that!

• Nethermind

• Client Tech Lead

🡰 Looking back

b. improvements: Deliver faster, I think Dencun is few months late.

c. contributions: Reviewing all Dencun Nethermind PR's. Our tx pool resilience to DOS, which I helped design.

d. challenges: Not Dencun related but the most challenging thing is State storage in Ethereum clients. Nethermind has been working on redesigning ours for over a year now, still at least a few months away.

e. kudos: Marcin Sobczak work on tx poll and then stress(spam)-testing it on devnets and testnets that uncovered a LOT of DOS vectors on all the clients.

Looking forward 🡲

f. priorities: Verkle should be prioritized but worked in the background. State is the hardest and we cannot deliver it that quick without committing resources to it.

g. improvements: Tik-tok scheduling, where teams work in parallel on at least 2 next hardforks to improve velocity.

• Nethermind

• client implementer, team lead

🡰 Looking back

a. successes: I have observed that with each hardfork, our testing procedures become more robust. This includes setting up development networks, conducting hive tests, and implementing additional tooling. In this hardfork, I believe we have done good work in defining priorities. We all agreed that 4844 was the main driver, and our focus has been on it.

b. improvements: While we made great efforts in testing Dencun, there is still room for improvement. One area to focus on is the addition of automated chain monitoring (devnet) to enhance incident detection, such as identifying missing proposals or detecting bad blocks in a more automated manner. We could think about automated tracing for consensus issues incidents. Considering the scope for the next 2-3 forks. For the next fork, it's important to define it quickly and avoid additions.

Currently, client teams are working on various tasks like EOF, Verkle, 4844, AA, Staking EIPs, inclusion lists, and SSZification. Prioritizing these tasks or discussing them further during ACD calls is vital. For instance, there are multiple propositions for AA, but a clear path has yet to be defined

c. contributions: I am proud of the Nethermind team getting more and more involved in testing. For example, by creating tooling

I remember that we had quite a few issues before devnet-8 started, we managed to fix them very quickly by brainstorming issues together.

d. challenges: We had a few tricky issues with our blob transaction pool.

e. kudos: I prefer not to mention specific individuals due to the large number of contributors. I want to express my appreciation for the contributions of our Nethermind team, EF DevOps, EF Testing team, other client teams, and all other individuals involved

Looking forward 🡲

f. priorities: Short term: EIP-6110, EIP-7002, EIP-2537. These are crucial improvements for staking and important precompiles to be added. Furthermore, these are relatively small EIPs, allowing EL developers to concentrate on Verkle trees and other priorities.

Medium term: Verkle tree (a significant step forward for light clients and statelessness).

Medium-long term: EIP-4444 (as the chain is growing rapidly, we need to initiate the process of removing history). Account Abstraction is essential to enhance Ethereum's user experience.

Long term: State growth - we need a plan for addressing this issue.

g. improvements: A well-defined scope for the upcoming hardfork is essential, but having a preliminary plan for the subsequent 1-2 hardforks will undoubtedly be helpful for client teams. Currently, our focus includes staking EIPs, possibly EOF, and verkle trees for the next hardfork. However, it would be beneficial to discuss what comes next: AA EIPs?, EIP-4444?, or something related to state growth, all potentially in the research phase. Of course, to some extent, the scope has to be flexible, but the clearer the scope, the better.

• EF Testing

• Protocol Tester

🡰 Looking back

a. successes: The collaboration between the execution client and consensus client teams has been definitely improving, and there is a lot of good synergy between teams. I'm looking forward to closing the gaps that we still have in regards to how testing is done across teams while making the process much smoother.

b. improvements: I think the timelines were a bit too ambitious. I remember first reading EIP-4844 around two years ago and barely understanding many of the concepts in it, which should have been a clear giveaway that this was going to be very hard to test.

c. contributions: The blobber is definitely a standout for testing during Dencun. It prompted a spec modification that, in my opinion, resulted in a more robust protocol. We are really proud of this specially because it seemed like a very innocuous idea, but if this were to have reached mainnet, it would have been a really big deal.

d. challenges: Getting the new tests repo up to speed to be able to be the main source of tests for Cancun was really challenging but the outcome has been extremely good.

We are now better prepared to fill tests for future forks faster, and also we are able to use the full potential of pytest and it's parametrization capabilities to automatically generate Ethereum tests for a ton of important edge cases and scenarios, which is better overall for the robustness of the network.

e. kudos: The EF Devops team just continues to amaze! Parithosh and Barnabas really just outdo themselves on every fork, and keep doing things better. The swiftness of launching shadow-forks and devnets, they make it look easy, but it has been a lot of hard work from them and it has really paid off.

Looking forward 🡲

f. priorities: I think verkle is an exciting next step for Ethereum to make the stateless clients more practical, and I'm enthused as testing is starting to ramp up right now. I do however think that we should take enough time to really consider all the caveats that this change brings.

As an Ethereum user, I really wish that account abstraction was a solved problem at protocol level by this point, but it's not an easy task. I'm a fan of 3074 but also recognize all the problems it could bring since, even when we perform all the exhaustive and necessary protocol level tests, there will still be the need for more user guardrails in wallets and dapps and rigorous testing over there.

g. improvements: I personally think there's still a some way to go to get testing just right, it's been a long way since the merge and a lot of improvements have been made to the process but we are looking into solidifying the testing procedures in this multi-client multi-layer environment.

• Geth

• Client Implementer

🡰 Looking back

a. successes: We've coordinated well, especially with "outside" teams like Optimism, Coinbase and Uniswap. Their prototyping was a great jumping off point for the work on 4844 and 1153.

The testing team has been great at creating tests and notifying the client teams of issues, which made the development cycle way quicker. They found a bunch of very niche, but very critical issues in things like the selfdestruct removal. Also Marcin from Nethermind has been great at fuzzing the test networks with blob transactions.

Working with the researchers, especially Carl, on the KZG ceremony was also a great experience. They provided a (good enough) spec that you could implement if you wanted to build your own client and test vectors.

There've been a few mainnet incidents that were solved very well. Everyone joined a call and debugged the issues until solved. I remember OpenEthereum having a mainnet incident in 2020 where the only people really debugging it were Rai from Besu, Marek from Nethermind and Martin from the Geth team. This has completely changed in my opinion. Every client team has a lot of very capable people now that know both the protocol and their implementation which makes debugging issues easier.

b. improvements: I think the biggest issue in the last years was the cancun timeline in the last couple of months which was pushed because of decoupling and re-coupling of the blobs. There's not much we could do there. There were new issues found and we had to postpone the fork to get them fixed.

Another issue I think was that we did not have the core dev day in Istanbul which could've accelerated timelines significantly I feel. So a shoutout to Tim Beiko for organizing the retreats and dev days which help coordinate our efforts.

c. contributions: I wrote parts of the 4844 implementation in geth link link and prototyped 4788 with Alex Stokes link where we started 4788 as an opcode and then implemented it as a stateful precompile, before Lightclient finally built the system contract as it is now.

I also worked on a client for the KZG ceremony together with Daniel Knopik towers-of-pau which was the first draft of the ceremony and later on became a client for the official ceremony.

e. kudos: Barnabas and Pari for setting up the testnets and devnets and giving me access to broken nodes over and over again. Marek and Ahmad for the late night debugging sessions. Danno, Justin and Matt for reacting so level-headed to me being stupid. Peter, Martin, Matt and the rest of the geth team for being the coolest team I ever been part of. And Potuz for reminding us of our values. And a hundred others that do great work in this community

Looking forward 🡲

f. priorities: I'm a big verkle proponent, but I also see ethereum's unique selling points: censorship resistance and decentralization at stake because of MEV and restaking activity

g. improvements: I think we should stop adding small improvements to the EVM and work on bigger improvements (like 4844, Verkle, ...) which enable us to do a 10x instead of a 10% improvement.

If dev days are cancelled (like in Istanbul) we should book a room anyway and just meet with the people that are there already. Sure we won't have everyone, but good discussions can and will happen even in smaller groups.

Testing has come a long way and I would encourage everyone, especially EIP authors to get in touch with Mario from the testing team early so they can plan testing strategies and to contribute to the execution-spec-tests.

• Teku

• Client Protocol Engineer

🡰 Looking back

a. successes: Deneb coordination and discussions during ACDCs, Deneb specific calls, Deneb testing calls / channels, Client teams collaboration (discord, telegram, calls), Incidents resolution (Devnets and Goerli)

b. improvements: Deneb inclusion proofs was a great design improvement but could have been considered earlier (lack of communication or initiative?)

c. contributions: Participated in the Deneb implementation within the Teku team. Raises spec / beacon API PRs

d. challenges: BlockV3 API: Challenging for Teku (Java) to handle different API return data types

e. kudos: Blobs inclusion proof design

Looking forward 🡲

f. priorities: Optimising client resource usage (decrease memory/disk/cpu usage), decentralisation (mev-boost, staking operators...), improve UX, reduce protocol complexity, increase client diversity

g. improvements: Check users needs (DAOs, polls...), Keep up with the protocol calls and other communication channels (Discord, telegram)

• TXRX

• Research Engineer

🡰 Looking back

a. successes: The core protocol community keeps its pace and passion on delivering complicated features like 4844 and fighting challenges appearing here and there on the way. The delivery of the Ethereum Roadmap features may be delayed, and the feature set itself is constantly evolving but the community doesn’t give up on the main objectives which signifies reliability of Ethereum technology and community long term.

b. improvements: I think the way it is now is practically the best. I can’t recall any existing issue that can be easily solved on practice. Yes, we want Ethereum development to be faster, more predictable, satisfying everyone’s needs and secure and the same time. And I believe that each of these qualifications is at almost the maximum level of quantity as it can be achieved in practice considering all the constraints.

c. contributions: I am especially proud of this almost last minute change: Add blob sidecar inclusion proof #3531. We delayed the delivery but we made the thing right, favoring security of the protocol and the network.

d. challenges: I wasn’t involved in the Dencun work that much. But at the time of it, I was working on the EIP-6110 prototype with Kevin, Navie, EF devops, Lighthouse and Besu teams. The results of this project have exceeded my expectations and I am very proud that our efforts contributed to the decision to include this EIP into the Electra/Prague hardfork.

e. kudos: I believe that everyone in the core developers community is amazing. But I would like to emphasise my appreciation of the work that devops and testing teams do. These guys are constantly improving their infrastructure and tooling to make the delivery of highly complicated features possible. I can’t imagine Ethereum development progressing at the current pace without their outstanding efforts.

Looking forward 🡲

f. priorities: I would prioritise DAS (a.k.a. danksharding), Verkle Trees, and Single Slot Finality and related but smaller upgrades. This is the feature set to keep Ethereum evolving as a settlement layer for L2 solutions.

g. improvements: I think early prototyping of complicated features across client teams is the thing that would help to deliver faster by identifying issues, finding solutions and answering questions early in the process, thus, making new changes easier to be set for a subsequent hardfork. This requires client teams to coordinate their work on new features before they are set for the hardfork. This is somewhat we did with 4844, and I believe should keep doing in the future.

• Lodestar

• Protocol Engineer

🡰 Looking back

a. successes: That was considerably large target to achieve in a small time.

b. improvements: I believe there is less clarity among core devs for KZG, except those who actively work on it. We may start in-house educational seminars/webinars to bring everyone in Core Dev upto a similar level of knowledge in different domains. That can be better facilitated by EF research team.

e. kudos: I believe Gajinder in Lodestar team worked really hard during the Dencun implementation. He not only coordinated with other teams but also lead the implementation in Lodestar.

Looking forward 🡲

g. improvements: More awareness to the community what is coming and why it's important.

• EF DevOps

• DevOps and Testing

🡰 Looking back

a. successes: The core protocol community did a great job of managing scope and handling a complex co-ordination problem across clients. ACD also has gotten quite good at handling potential mainnet incidents and improved at co-ordinating between EL and CL teams.

b. improvements: I would say timeline estimation and making concrete decisions earlier on. I think there have been at least a few times in the last few years where we wanted to over-promise and ended up under-delivering, and the exploration time for the over-promising ended up delaying what we delivered. I hope we get better at understanding what we can ship and how quickly.

c. contributions: We overhauled our entire testnet stack to be based off of a template and that template was stress tested with the Dencun testnets. This saved us countless hours spent on setups and basics while ensuring everything we do remains flexible for catering to the needs of protocol testing.

d. challenges: The Dencun fork was clearly something we needed quite a lot of new tooling for and this testing overview doc helped scope out which changes exist and how they are being tested. The overview doc was the easy part, building/using the tools to actually find bugs was the challenging part. Working with Mario to run his Blobber tool and debugging if the tool even worked was extremely challenging and a humbling experience.

e. kudos: The entire EthPandaOps team has been amazing to work with, the team hit the ground running mostly in 2023 and has already built awesome tools to make deployments (eg. KZG ceremony backends) /testing/research/co-ordination easier for core protocol work. It's been great to work with Mario and the testing team, their depth of knowledge is humbling. Also a huge shoutout to g11tech, Pawan, Sean, Tersec and all the core devs that are constantly available and helping us decipher what we're seeing/pushing fixes in.

Looking forward 🡲

f. priorities: The last couple of upgrades were targeted quite heavily at consensus and scalability, it would be nice to see usability as the next focus. EVM improvements, smaller proofs/light clients and Censorship resistance need some love and care as well.

g. improvements: A hard part of testing is trying to support everything all the time everywhere, as a result our stack tends to be relatively messy - as the same tool needs to support verkle, 4844 and eip-6110 and whisk testing (to name a few) at the same time, all while the inherent fork itself is changing. The overhauls of 2023 helped a lot with making sure we're able to keep up with this rate of parallel testing for now, but its still quite tedious to never know what to expect.

It would be nice to have a clearer roadmap for at least the next fork, so we can make concrete decisions on how to split our tools up and it would reduce the burden in maintaining PRs forever or rebasing constantly.

• Lighthouse

• Client implementer

🡰 Looking back

a. successes: I think 4844 was a very well thought out, forward thinking spec change where it laid the foundation of data availability sampling such that it required fewer changes from the EL for increasing scaling. It also allowed the devops team to create good infra to test further networking changes in the future as we increase scale.

b. improvements: I think we should have had done more work in parallel to test viability of some of the changes that are up for inclusion in Electra. Feels like we are starting from scratch for most of the proposals (at least in terms of client implementations) for the next fork which is making it hard to prioritize things for inclusion.

c. contributions: Not my contribution, but the spec change to add a merkle inclusion proof to the blob sidecar was quite a genius move that simplified loads of assumptions we had to make in our codebase. I'm also quite proud of our implementation of the change.

d. challenges: Making the ckzg library work on windows was a huge pain as it kept crashing unexpectedly. We eventually figured out that the issue was a bool getting redefined as an int in the C code which wrecked the FFI between C and Rust 🤡

e. kudos: Highly appreciate the EF devops team for making the lives of client devs easier. Also, special shout-out to Sean Anderson for his incredible attention to detail regarding potential attack scenarios for all spec and implementation changes. He has a knack for understanding the bigger picture of things we are building and I learnt a lot from conversations with him. Knowing that he'll be around helps me sleep better!

Looking forward 🡲

f. priorities: Near term: I think the main focus should be getting additional scale with the new sharding proposals and improved UX with some form of account abstraction. Also need to make sure that the beacon chain is able to handle the increasing number of validators, especially considering the increased bandwidth because of other scaling related changes. We also need to keep an eye on censorship happening on chain and have mitigations for that which are strictly better than the current state of things.

Medium/Long term: we need to fix a lot of technical debt that we have accrued over the past few years.

g. improvements: It's a hard problem, since we have multiple priorities that are important in their own right, but limited time for core devs.

• Lodestar

• Project Manager

🡰 Looking back

a. successes: The core protocol community has really found a good rhythm of working together and pushing out upgrades that we desperately need to keep the EVM and Ethereum L1 relevant. We understand very well that there is a scarce resource of limited developer time and we can come to relatively good decisions on how to best prioritize features. Shipping one hard fork a year is an absolute minimum to achieving goals and the Ethereum DevOps team has been exceptional in accelerating this front. We haven't had any serious incidents on mainnet outside of some minority client consensus bugs and non-finality incidents, but we are generally very good with responding to them with the help of others in the community. Workshops at conferences and interops once per hardfork is ideal to really help shorten the development timeline. Gatherings of core developers at events such as Devcon help ensure we can have some sort of mindful consensus on what needs to be prioritized for each hard fork.

b. improvements: We need to be more aware of the diversity of knowledge which exists outside of protocol development. Our work affects other builders in the Ethereum ecosystem and I think there can be room for improvement with other layers of the stack participating in our calls/discussions or we participate in theirs. It's important that we know what builders on L2s and Dapps are thinking to help better prioritize the core protocol roadmap. If we don't create a viable environment for new experiments to survive, we will struggle with maintaining a lead in developer mindshare. I think we've come to a good consensus that scalability is very important and doing what we can to lower gas fees is essential to success, which was a big push for getting proto-danksharding in for Deneb.

We need to balance moving forward along with not breaking things due to how important our work is. The teams in core protocol are the backbone to keeping Ethereum running and when teams identify that a timeline is too tight, we should consider this carefully, especially if its a client team with large usage. Some teams are capable of moving faster than others and some teams need to naturally be more conservative to ensure Ethereum remains safe. We should find a balance between that or figure out ways to better diversify usage. We should support each other in this area and always strive for an equal distribution of client usage.

We were really good with last-minute inclusions including EIP-7514 which was based on what we were seeing on Mainnet to give ourselves buffer room for solving larger technical challenges. We aren't always good with foreseeing how our development creates problems elsewhere until it's live out in the wild, but we are good at mitigating problems once they arise (even with temporary solutions).

e. kudos: When we started on the EIP-4844 implementation, the Lodestar team was still trying to build up its team and lacked the resources we needed to ensure we could properly implement c-kzg bindings for nodeJS. The community was very helpful in ensuring that we didn't fall behind and connected us to resources which would help us move quicker. I'd like to especially thank Liam Horne, Tim Beiko, Jesse Pollack and Dan Coffman for connecting us and dedicating resources to ensure we could take over some of the work started by external parties once we further developed our team.

Looking forward 🡲

f. priorities: In the near term, we should be focused on scalability (e.g. PeerDAS, Danksharding) so we can continue to compete with other blockchains and stay relevant. We will bleed builders and users if we cannot figure out how to scale in a way that still respect the ethos of Ethereum. We should be very mindful about staking economics and ensure we can always get close to what we'd ideally like to see: decentralization and a fair playing field for everyone.

In the medium term, we need to further mitigate MEV type issues and censorship. Ethereum needs to remain neutral at protocol and we cannot let liquid staking pools/companies dictate what can and cannot be included on Ethereum. Companies naturally have to follow the local rule of the land and it's important that large entities don't control the direction of Ethereum if it means sacrificing ethos. Enshrined PBS needs to come to a consensus soon and implemented alongside other research for staking economics so we can bring some equilibrium to all players staking/securing the chain.

In the medium term also, we need to parallelize Verkle, EOF, PeerDAS and some sort of account abstraction features to allow for better DX and UX for Ethereum. If builders need to workaround problems within protocol constraints and the natural effect is dangerous UX workarounds, we will not be able to create the interfaces needed to onboard the rest of the world.

Long-term we should try to ossify the protocol to a point where Ethereum has stable enough mechanics that the protocol itself doesn't need to go through anymore hard, unpredictable changes. The hard part is drawing the line of when we think the protocol is "stable enough" to not touch it anymore. I don't believe we've had enough discussions of what that future looks like, but I think ossification is important to give ourselves some endgame which will better legitimize Ethereum as the base settlement layer of global commerce. We could always look at having a more "experimental Ethereum" type project in the future as research and development evolves in the blockchain space.

g. improvements: I think we're doing pretty well here and have improved when it comes to core protocol contributions. We can definitely think about doing things where parallel developments happen and perhaps we can additionally create forks that are independent of the EL + CL for things to potentially move faster, or tackle some debt where there's no dependencies on the other layer. We've been pretty good on the CL side about changes that can be done outside of a coordinated hard fork and we can likely do the same with focusing on some CL only changes while working on larger, coordinated hard forks. We should be clear on expectations of when hard forks should happen. A lot of decisions can't be made until we commit to a harder target of a change. If we want to do a smaller 2024 fork, we should be clear about it so we know what we can realistically try to get in there.

• OPLabs

• rollup engineer

🡰 Looking back

a. successes: While Ethereum has not reached the so called "Endgame" yet, the progress towards Sharding means a lot. Without this, there would be no viable path for any L2 to sustainably scale total Ethereum throughput. Due to forward-compatibility with the full danksharding design, the effort was larger than just "add 400KB of expiring data per block", and I believe this will pay off: the latest DAS designs look promising. Long-term thinking about the protocol is something Ethereum does very well, and what I stick around for.

b. improvements: There is no such thing as a "product manager" in ethereum or ACD. While this is a good thing for the long-term technology sustainability and decentralization, there was definitely a cost to not scaling ethereum faster in more simple ways. I believe ethereum does well, long term in the violent blockchain space, because of a lot of hedging: client diversity, L2 competition, sub-communities. We would see more client diversity if the protocol was more simple. We would see more L2 competition if the data-availability space was not as crowded. We would see more communities if usage cost was not as high. In other words, "squeeze the plan, not the people" is something ACD can improve on.

c. contributions: Based on a pre-danksharding concept design by Vitalik & Dankrad, we entered what we now know as EIP-4844. This started at EthDenver 2022, where I built the first prototype implementation with a group of Ethereum friends. Execution layer: @lightclients @adietrichs (Quilt, at the time), @asn_d6 (EF). Consensus-layer: @terencechain @rauljordaneth @preston_vanloon (@prylabs) Sean A. (@sigp_io) and Hsiao-Wei W. (EF). And then, based on this early draft we developed during the hackathon, I published the EIP, and the Consensus Layer specs. After this, the EIP wasn't quite mainnet ready yet, but it was a big milestone: specifications are a critical step towards realizing the thing. And then during following conferences, like Devconnect, we shared the design and discussed changes with the L1 client implementers. I am proud of how we got the first iteration towards sharding to a complete cross-layer EIP.

d. challenges: The most challenging sub-projects in EIP-4844, that I was part of, were the original hackathon draft, the early execution-layer prototype implementation work (which @Inphi, M. de Hoog and R. Bayardo then helped to continue), repeated drafts of L2 support, and the process of dealing with the long-running EIP (2 years is a lot in crypto time!).

Fun fact: EIP-1153, also in the Dencun upgrade, got some implementation traction during that year in EthDenver also. Since the change away from the old venue (the "castle", a chaotic but beautiful mess) the hackathon vibe has been much worse, but I hope EthDenver, as well as other ethereum hackathons, will offer a "side stage" for protocol developers: many of us are there to share knowledge, collaborate and form teams, but just not as involved on the application layer (often the primary sponsors of the event). If there was more of a connection, then protocol changes would be better informed from a product perspective, and more new cross-application/protocol ideas may come to fruition.

e. kudos: Parithosh, and the whole EF devops team really, helped a lot in the testing phase of EIP-4844, something a lot of people underestimate: scaling comes with stress-testing, advanced monitoring, and large scale deployments of many different client implementations. This meant a lot for client-implementer teams during testing/debugging, and helped significantly accelerate the delivery of the change to L1.

Looking forward 🡲

f. priorities: For roadmap planning I'd like to wait and see what DA-cost impact EIP-4844 has. Increasing the blob-count per block is very tempting, if we want to double down on scaling in the short term (with blob expiry, the cost is bounded and not permanent). That said, new great things like Verkle trees and Peer DAS are looking promising too, but may require another 1+ year span of development. If we are committed to a second Ethereum L1 upgrade this year, the scope should be relatively small. I believe some tech-debt cleanup changes ("the purge") are good to have, and ideally a subset of the SSZ-ification EIPs: transaction receipts are currently nearly impossible to deal with as L2 (due to large max size and inefficient hash commitment) and deserve some tech-debt cleanup (merkleizing them, in any way, can have a big positive impact on L2s!).

g. improvements: While I appreciate a fast rollout (ship it!), making significant changes to L1 without timely announcement makes it a challenging task for L2s with delayed upgrades to keep up. This incentivizes L2s to not implement delayed upgrades. For proper decentralization of L2s, upgrades happen with a lot of process: public L2 testnet (depends on L1 testnet), change review, governance voting, upgrade-veto, upgrade/announcement-time. For the OP-Stack, this balance was very tight, and exact rollout timelines still remain uncertain. As of writing this in mid-february, no other L2 team has published a public testnet yet. Day 1 adoption of EIP-4844 is uncertain for most (if not all) L2s, and may be very chaotic. Ideally change-control later in the L1 process is stricter, and earlier tentative announcements for mainnet L1 can help resolve the uncertainty around L2 upgrades.

• EF DevOps

• Testnet and KZG ceremony infrastructure

🡰 Looking back

c. contributions: I am really proud of all the tooling that the EthPandaOps folks have been shipping. With dencun we did a major change on our ansible setup and now have a collection of ansible roles that we've been using a lot, together with our k8s helm charts for our dencun devnet deployments. It's great to see more infrastructure code being open source and available for everyone to reuse.

Additionally, I enjoyed working alongside Carl, Trent, and Nicolas on the KZG sequencer setup, where we successfully gathered a total of 141,416 contributions!

d. challenges: Early devnets on any new "big feature" are hard. Having all these different client combinations is nice for decentralization but it also brings a lot of complexity into testing. In the beginning there will be a lot of breaking changes and bugs. It normally always takes a couple of devnets until clients mature into a more stable release. For dencun, we had a total of 12 devnets.

e. kudos: A huge shoutout to my team. EthPandaOps let's go! Without these folks (Andrew, Barnabas, Pari, Philipp and Sam) we wouldn't have most of the testnet infrastructure and visibility into the current state of these networks. We've learned so much together and kept improving our tooling which has been used by a lot of devs and researchers.

Also, huge thank you to client devs which are always so kind and helpful at debugging problems. It did require a lot of team work but now "blobs are coming" is for real.

Looking forward 🡲

f. priorities: Guillaume keeps talking about some Elephant in the room. So maybe we want to tackle that one sooner than later 🐘

g. improvements: Coordinating these efforts is a hard job and I think that we're doing well on that front.

• Applied Research Group

• researcher

🡰 Looking back

a. successes: It has been great to watch the process unfold as we move from the early ideas of "protodanksharding" all the way to EIP-4844. It involved a lot of active work from all core protocol teams as we moved from early idea to early spec to early prototypes and the refinement process that unlocked. And this example serves to highlight a particular strength of the core protocol community as we integrate a diverse number of skill sets and perspectives as we all discover how to make Ethereum better.

b. improvements: If I had to highlight one part of the process to improve, I'd suggest stronger focus on (ideally) one thing at a time. Hard forks come somewhat infrequently given the coordination overhead. And this means a lot of good ideas to improve Ethereum all have to compete for a very limited amount of "core protocol development" bandwidth. However, the more we put into a given hard fork, the more we will have inevitable delays in shipping the latest and greatest to improve Ethereum. One way to address this is to be laser-focused on a small set of things, even to the exclusion of other stuff that is good in isolation, but may not quite stack up in the final prioritization. Attempting to implement this brings the immediate challenge of what to prioritize and to answer this question we have to have a clear definition of what we are actually trying to accomplish -- in short, answering the question, what is Ethereum for? I think for a number of reasons the answer is muddy. Part of this reflects a strength of the Ethereum community broadly: its decentralization. But at the same time, having an unclear idea of what Ethereum should become spirals out into all the decisions we make with tangible impact to actually getting to the protocol's future.

c. contributions: I'll call out EIP-4788 that I was involved with. It provides a trustless mechanism to access consensus layer state inside the execution layer, with direct impact to the security and scope of what staking pools can hope to accomplish.

d. challenges: In broad strokes, the part I play in stewarding the MEV ecosystem is the most challenging: not for intrinsic technical reasons but more for organizational reasons. There are somewhat competing views that "mev-boost is outside the core protocol," and so the core protocol should just be secure and then what happens outside of it is not the core protocol's business. But at the same time, there is overwhelming adoption of mev-boost so I find it hard to simply stop support with the core protocol itself. This adjacency is also mirrored in the organizational structure of core protocol teams and those in the MEV ecosystem, so there is a lot of coordination work that can be done to ensure this support can be delivered. At the end of the day, I think we are simply in a "growing pains" phase as we figure out how important these "extra-protocol" actors will ultimately end up being. In other words, the current situation is to be expected and I'm consistently amazed the extent to which various teams will go the extra mile to make sure things are working end to end. And this makes me hopeful for the future.

e. kudos: I'd have to call out the work of the EF testing team, especially Mario Vega. As the protocol becomes more complex, the testing load increases and the efforts of this team are the first line of defense to ensure that Ethereum remains as secure as it has so far. And while I think overall the Dencun development process has been a great success, the road to get there was definitely winding. In concrete terms, this means testing becomes that much more complex -- not only testing the protocol but following all the various iterations as they evolve over time.

Looking forward 🡲

f. priorities: This is a hard one and I think my specific opinions are still evolving, as ultimately the best timing of a given feature reflects the most pressing priorities of Ethereum, rather than reflecting the opinions of a group of people on a given day. That being said, my own view is something like this:

Near term: data scaling; we want to continue the push to provide an affordable path for everyone to actually use Ethereum, and the rollup-centric roadmap seems like a great way to do this.

Medium term: censorship resistance; if anything the adoption of mev-boost is rational for individuals but has gotten us to a place where a core Ethereum value starts to become compromised. I think the research here is still getting to a solid place which is why I have given it some time beyond the "near term" goal, but do think it would be the next best place to focus assuming we had a much bigger data facility in the protocol.

Long term: staking economics; I think we ultimately want to drive to a world of minimum viable issuance. However, the path to get there is not super clear as it touches just about everyone who interacts with the core protocol and will ultimately be a very political decision to navigate.

g. improvements: Focus, focus, focus. We should do everything we can to drive towards tightly-scoped hard forks that can be delivered quickly. There's no reason we couldn't upgrade the protocol say twice a year, other than the sheer coordination effort required to actually roll stuff out. And being ruthless about focus will only help us maintain high velocity towards improving Ethereum.

• Base

• client prototyper

🡰 Looking back

a. successes: KZG ceremony in particular was brilliant! ACD is also very open and I love how everyone's input is heard and (almost always) respectfully considered.

b. improvements: a few things took too long in hindsight: (1) blobs with block or blobs-as-sidecar. We flip-flopped on this decision too many times. (2) closing on the format of blob transactions (we were stuck on potentially adopting SSZ encoding for entirely too long) and (3) understanding & documenting appropriate transaction pool handling of blob transactions. this one is probably because txpool handling is not part of the spec, though probably the spec should still be obliged to provide (potentially heavy handed) guidance given this is so important. Right now you basically have to read the geth code if you want to submit a blob transaction and understand what's needed to get it accepted in a block, which doesn't feel right to me.

There were also a few last-minute additions to Dencun that kept pushing back that release date. E.g. beacon block hash in the block header was I think the last example of this. Not sure if there's something we could do to get these things surfaced earlier or be better about saying NO if it results in any increase to an already extended timeline.

c. contributions: Getting geth & erigon EL 4844 prototypes working for the client dev Edelweiss workshop and having almost every CL/EL pair running on our devnet by the end of the workshop (I think nimbus CL was the only one that wasn't quite able to get up and running). I feel this cemented 4844 as the clear next big feature for the post-Shanghai hardfork (as opposed to say something like EOF).

d. challenges: Getting the initial 4844 devnets and prototypes running. we had an interop repo here that was very chaotic with lots of forks of various clients.

e. kudos: Mofi Taiwo from OP labs was involved very early on in the 4844 prototyping work and drove an enormous chunk of the geth prototype, and he provided a ton of guidance for me getting the erigon prototype going.

I also greatly appreciate Tim Beiko who eagerly pushed having 4844 in the shorter term roadmap. We ambitiously and perhaps naively were pushing to get it in Shanghai, but are happy to have gotten it in Dencun. Tim was supportive the entire time and did what he could to drive alignment.

Looking forward 🡲

f. priorities: (1) increasing the blob-per-block target. It's still too conservative, and by the next hardfork we should have good understanding of just how high we can bump it before adopting a sharding strategy.

(2) blob sharding, e.g. PeerDAS or full danksharding. I think PeerDAS is a nice step towards full danksharding we can pursue as a safer interim step.

(3) more support for smart contract wallets, whether that's through enshrinement or driving more consensus around out of protocol approaches.

g. improvements: The community is getting pretty big and I'm not sure the fully consensus driven approach taken at ACD is going to scale. One could argue it's already grown obsolete and it's why hard forks take so long. I think we need to consider nominating smaller groups with a designated lead for each big feature and expect them to quickly drive consensus and make decisions when things get stuck?

• EF DevOps

• DevOps Engineer

🡰 Looking back

a. successes: Coordination between all involved teams is going from strength to strength. It feels like the split between the consensus and execution layers has really helped in allowing teams to focus on their speciality without being bogged down. The response to the mainnet incident in May 2023 where the chain wasn't finalizing for a few epochs is a great reflection of this.

b. improvements: We need to move a bit faster. It's a tough ask when complexity and risk are ever increasing, but we need to find ways to make it happen.

c. contributions: I'm particularly proud of the Goerli & Mainnet Big Blocks tests that our team was involved in to decide blob parameters. The idea was to create larger-than-normal blocks and to see the effect these blocks had on propagation time and the network in general. We scaled out our infrastructure to capture more data, and then performed analysis on the effects here.

e. kudos: Terence from the Prysm team was a huge driving force when 4844 was early days. His wealth of knowledge on the subject definitely shaved a considerable amount of time off the development cycle of 4844, and the small little things like weekly meeting summaries really helped with adding momentum to such a large task. Thanks Terence!

Looking forward 🡲

f. priorities: PeerDAS & Verkle! Scaling is our biggest issue right now. I'd especially love to see PeerDAS prioritized.

• Lighthouse

• Client implementer

🡰 Looking back

a. successes: The KZG ceremony was massively impressive.

The improvements we had to network-level testing tools throughout Dencun testing were phenomenal. They have enabled us to spin up testnets much more quickly and with a greater variety of configurations which is really helpful for a big network level change like 4844.

b. improvements: We flipped back and forth on a core part of the 4844 design, whether to propagate blobs and blocks together or separate. Getting everyone across the design and its implications more quickly and facilitating conversations about this amongst a broader range of people may have helped here. Easier said than done though.

Looking forward 🡲

f. priorities: A max effective balance increase would benefit all network participants. The validator set is artificially high due to the current max effective balance and this costs the whole network bandwidth and compute. We will start to hit bottlenecks if the validator set grows too large.

Inclusion lists are an important priority. Being resilient to the centralizing forces of MEV are critical.

g. improvements: Figuring out what goes into the next fork is always a challenge. It would be great to get more voices from outside of ACD onto the ACD calls (end users, app layer devs, etc.). And to perhaps get core devs participating in ecosystem discussions outside of ACD. It's tough to weigh priorities between things of technical importance and things that improve Ethereum UX for example.

Additionally, we are working on ways to make prototyping EIPs in parallel in Lighthouse more painless. This could help us feel confident investing more dev time in things that might not end up in the next fork.

• Erigon

• Protocol/Client Developer

🡰 Looking back

a. successes: Dealing with disasters: There have been many hiccups, the community successfully navigated through them. There were many technical changes to the Dencun EIPs to improve user experience and overall stability of the ecosystem

b. improvements: Definitely timelines. With the whole ecosystem getting so much bigger now, the coordination of timelines have to be taken into account across different clients and other stakeholders.

d. challenges: Txpool in erigon needed upgrade for blob transactions and handling spamming: Txpool upgrades PR

e. kudos: I think Giulio's (from Erigon) work on CL side to get to Dencun was great

Looking forward 🡲

f. priorities: More standardization across clients, with respect to how they consume and exchange data. For instance, we could have uniform config files, dump formats, chain snaphsot formats. We should also focus on EVM more

g. improvements: A balance of protocol improvements as per developers, and those as per other stakeholders like API businesses and users

• Prysm

• client implementer

🡰 Looking back

a. successes: The core protocol community never took shortcuts, always unwilling to sacrifice quality for a quicker timeline. We've made several changes to the protocols, including decoupling blob sidecars from beacon blocks and incorporating block headers into the blob sidecar. This demonstrates the core protocol community's continuous growth and maturity.

b. improvements: We could have spaced the testnet dates further apart by an additional week to include more node operators and gain more insights from the instrumentation. The testnets were upgraded with a gap of under 1-2 weeks.

c. contributions: I contributed to the first interop version alongside Proto and others!

d. challenges: The P2P part was more challenging than the rest. Blobs and blocks were decoupled, leading to certain edge cases that required additional consideration. We ultimately included the block header inside the block sidecar, which resolved most of the concerns.

e. kudos: I don't have anyone specific in mind at this moment, so a shoutout to everyone—whether you are part of the client teams, research teams, or community members on Discord, Twitter, you all made a difference!

Looking forward 🡲

f. priorities: I'd like Electra to be a minor hard fork that incorporates EIPs such as an execution-layer-triggered exit, cleanup of the committee index in the attestation object, and provisioning of validator deposits on-chain.

g. improvements: More break-out rooms! jk!

• Protocol Support

• ACD

🡰 Looking back

a. successes: Client teams have gotten better at articulating their roadmap priorities, and we seem to be getting to consensus more efficiently than we used to.

b. improvements: Too many calls! Breakout rooms and recurring calls have become our default way of moving things along. While there's value in getting on synchronous calls to hash out complex things, I fear we're overdoing it and would like us to bias more towards asynchronous collaboration.

c. contributions: Organizing the Edelweiss Interop, at the top of a 1km mountain.

d. challenges: Splitting the EIP and ERC repositories.

e. kudos: The MVP award for the past couple years goes to the EF testing and devops teams. They've enabled client & research teams to keep increasing the speed and complexity of what we're shipping, while also raising our overall quality bar. Huge, huge, shout out to them!

Looking forward 🡲

f. priorities: Once Verkle is live, we need to actually ship stateless clients. Once that is done, then maybe we can even consider (EOF-enabled?) state rent!

g. improvements: Less calls, more asynchronous, high quality, collaboration. Maybe we start by making both ACDE & ACDC monthly calls and going back to a bi-weekly ACD cadence 😄 ?

• Applied Research Group

• Researcher

🡰 Looking back

a. successes: The community has been exceptional in aligning on a roadmap and maintaining a focused approach. Although the rollup landscape is still in its infancy with room for improvements, we can see projects aligning with the core values of decentralization, censorship resistance, credible neutrality etc, striving to become more and more decentralized. In that regard, it was great to see the community getting together to push towards a shared goal which includes a rollup-centric landscape.

c. contributions: Over the past year(s), I've been building different dashboards on various different topics, summarized under the dotpics "brand". I've been able to open souce tons of data, helping young researchers in getting started on Ethereum-related topics, which was super cool to experience.

e. kudos: Alex, Justin and Vitalik were excellent companions during the onboarding process, while Mike performed exceptionally well, addressing various critical topics such as Inclusion Lists (ILs), Max Effective Balance (MaxEB), and ePBS. Furthermore, Matt (lightclient) has also been an incredible colleague, assisting me with my start at the Ethereum Foundation and consistently providing positive vibes.

Looking forward 🡲

f. priorities: Inclusion lists (or encrypted mempools) can protect us from a future in which a single state could negatively impact dApps to the extent that they become unusable. These lists empower validators to reclaim some authority from block builders and make decisions about parts of the Execution Layer contents themselves. Moreover, even though I am merely an observer in this discussion, as someone who operates nodes, I believe Verkle trees are of paramount importance and should be given priority in order to eventually reduce hardware requirements.

In the medium to long-term future, the focus should continue to be on scaling (increasing gas limits, blob counts, zkEVM, etc), always with the underlying principle of not compromising decentralization or other desired properties. Moreover, it's crucial that the landscape remains open and welcoming to privacy tools, as these are fundamentally important for enabling a free society on-chain.

• Protocol Support

• Special Projects

🡰 Looking back

a. successes: 1. the ability to choose priorities and stick with them (the Merge, withdrawals, EIP-4844) while also 2. maintaining parallel research, implementation, and testing tracks. The Merge took a lot of bandwidth in 2022, but it was crucial that other work begin and continue alongside it: client improvements, verkle tries, KZG Ceremony, research into networking, issuance, improving censorship resistance, etc.

The in-person interop in Austria was crucial to getting everyone on the same page - a well-executed, high-impact event.

Base and Optimism's 4844 work was a good integration of a broader contributor set.

b. improvements: Shanghai and Dencun both took an additional quarter - not much in the grand scheme of things, but can always be better.

We depend on a lot of synchronous calls and it would be better to start transitioning to async processes in the medium/long term.

c. contributions: The Protocol Guild Pilot raised $14mm for over 140 members as part of the 1 year Pilot (May 2022 - May 2023). As a member, I'm proud to see it maturing into a robust independent institution capable of supporting core protocol contributors financially. We are close to a v2 launch, which will expand the trustless characteristics the mechanism depends on.

The KZG Ceremony was an important prerequisite for EIP-4844. I was proud of our interface design and successful engagement of the broader Ethereum community. We were able to gather 141k entropy contributions, making it the largest setup of this kind!

I am proud of this piece - "Capital and enclosure in software commons: Linux & Ethereum." The essay asks important questions about how the core protocol commons engages with internal and external capital circuits.

Delivery at Dawn | a 4844 film. The short celebrated the arrival of EIP-4844 to mainnet, core dev stewardship, and positive-sum Layer 2s. ETH proceeds went to Protocol Guild =)

d. challenges: The KZG Ceremony interface was a new kind of project for me and particularly challenging (managing the complexity of the design and moving it from mockups to live frontend).

More broadly, the project itself needed special attention to broad promotion and accessibility, attentiveness to the needs of contributing participants to ensure it was legitimate to the broader community. This was made even more difficult by the design of the lobby and the presence of bots. Happy to be on the other side of that one!

e. kudos: Cheeky gorilla has been an incredible collaborator for Protocol Guild. Tim Beiko remains the GOAT for his abilities to give shape to permissionless collaboration among disparate parties and synthesize next steps out of competing priorities. Carl Beekhuizen for the wonderful technical collaborator through to the end of the KZG Ceremony. Mike Neuder for being a standout new researcher!

Looking forward 🡲

f. priorities: Not EIPs, but cautions: running nodes and validating should be more accessible. Geographic decentralization of nodes is one thing that Ethereum does well and should be considered when considering the tradeoff matrix of scaling approaches. Yes, there are rational balances to be found, but we should track if the range of our norms is drifting over time.

We should be very careful about enshrinement and preferential treatment. Ethereum has done a good job of this historically and should try to stick to that high standard.

g. improvements: Understand that Ethereum is technical project with deeply embedded cultural and political threads. These are incredible strengths that should not be neglected.

Engage the broader developer/application/user community more consistently. Consensus and legitimacy of process emerge from broad bases. However, as usage and interest in Ethereum continues to increase, it will get harder to manage competing approaches/priorities surfaced by stakeholders (eg. Layer 2s, EVM, app devs, users, core developers, blockspace supply chain, commercial employers). These parties will all try to engage in core development, ostensibly well meaning, but bad actors will try to abuse the open processes to their own private gain. Stay vigilant, and build the protocol for the largest public!

• EF Security

• Security Researcher

🡰 Looking back

a. successes: The core protocol community does a good job of collaborating to both construct and, importantly, sustain the essential infrastructure for this ecosystem. Specs and clients undergo meticulous drafting, writing, refinement, and release processes. Moreover, when issues surface on the mainnet, community driven problem-solving resolves them.

b. improvements: Identifying precise areas for improvement within a decentralized group poses a challenge, as it suggests a predefined path toward a clear goal. I do think there are some unique challenges that we currently have that may require a different approach than shipping a desired new feature.

c. contributions: I've invested substantial time scrutinizing code, uncovering issues, and conducting various interop-testing. Multiple teams are actively engaged in similar efforts, and I'm proud to be a part of that process. It takes a village.

e. kudos: Devops.

Looking forward 🡲

f. priorities: Decentralization concerns and incentive alignment always come to mind as things that I think need to be addressed.

Thanks for reading to the end! Let’s continue building towards better worlds on Ethereum. Be sure to check out the Delivery at Dawn short to celebrate the ongoing stewardship of Ethereum core contributors.

https://opensea.io/assets/0x72d07BeEBB80f084329Da88063F5E52f70f020A3/1