This is a quick, easily-digestable wrap-up of the last four protocol development calls with a bit of my own perspective of how it ties in to community commentary. I’ll aim to do one every ~4-5 calls, depending on current events.
Relevant ACD calls:
Over the last four ACD calls, we’ve moved from a buggy Pectra devnet-5 to a stable devnet-6. Dates to activate the Pectra fork on the two testnets (Holesky & Sepolia) were chosen, with Holesky forking this coming Monday, February 24th at 9:55pm UTC. Audits were completed and Pectra is expected to go live on mainnet ~30 days after a successful Sepolia testnet fork (plus some days for coordination of mainnet launch date choice). The mainnet date, expected early April, will be announced on the EF blog.
There was lots of conversation asking client teams and any interested parties to evaluate the upgrade process as seen throughout Pectra so that we can move to make protocol upgrades as efficient as possible. All client teams contributed feedback. There was strong consensus on a desire to increase the frequency of forks and to keep scope smaller per fork. EIP-wise, Pectra has been the largest fork to date. There was also strong recognition that testing is a bottleneck in the process - this led to calls for more uniform testing standards and also better fleshed-out EIPs at the point of considering them for inclusion (”CFI” status).
Hardware & bandwidth recommendations for running an Ethereum node are being finalized into an EIP. And blob-parameter only (“BPO”) forks have been proposed, which would create a separate type of fork to adjust only the number of blobs available. A Fusaka fork could aim for 12 (or more?) blobs, but BPO forks could get us far beyond that before Glamsterdam, the fork after Fusaka.
A clear result of the “Pectra retrospective” discussion was a desire for a faster cadence, and it was proposed to freeze the scope of the fork following Pectra, “Fusaka”, within a month (~Mar 13th). The only EIPs in the Scheduled For Inclusion (SFI) status are PeerDAS and EOF. PeerDAS has broad consensus and is already in its fifth devnet but devs are currently in discussion about whether or not EOF is in a place to not slow down the shipping of PeerDAS, which is increasingly being viewed as an urgent upgrade.
The proposal to finalize the Fusaka spec before even shipping the current fork creates a strong departure from the general expectation that Fusaka’s earliest release might even be early 2026 - the goal would be to ship it as quickly and as leanly as possible to aim for ~6 month cadences going forward. Nine other EIPs have been Proposed For Inclusion (”PFI” status) for Fusaka, so we’ll have to see if devs are able to keep scope creep down…
We’ve seen a shift toward “accelerationism” in community conversation and I think it’s been a combination of this and of L2s talking to researchers about projected DA needs that have created a sense of urgency around both PeerDAS and increasing the number of available blobs. Scaling for both the L1 and L2 are at odds with keeping node requirements low - as blobs and gas limit increase, node requirements increase. PeerDAS or a flag for validators to choose the number of blobs they want to include are examples of features that mitigate these increases in order to maintain Ethereum’s most valuable asset: its decentralized validator set. If L2s are doing the projections for the DA they’ll need, I encourage them to share those publicly so the community can unite behind the need for scaling and the magnitude and timeline of that need.
This does not represent a Standard Operating Procedure (SoP) for Ethereum upgrades. This is a personal account of how the Ethereum upgrade process works
If you’re on the app layer, totally separated from Ethereum core development, and have fundamental frustrations with the L1 protocol, this post is for you.
Once the Pectra network upgrade goes live, attention is going to be turned to Fusaka (the next network upgrade) and you might think: how would I get a proposal into a network upgrade? How would I write it? How do I begin to even think about addressing an L1 problem as an app developer?
There’s some criticism in the Ethereum community that core developers are too separated from the app layer and there’s validity to that claim. As many programmers tend to, core developers can get hyper-focused on their niche, especially knowing that so much value depends on their finding and addressing bugs before release. But they often don’t even know how each others’ clients work. And because the core development process is, first and foremost, making sure these client software can talk to each other with whatever features are going into the next network upgrade, their voices tend to naturally dominate the All Core Dev (ACD) conversation and make it somewhat intimidating to see where you can fit in.
The good news is that the Ethereum community has communicated this shortcoming - core devs & researchers are listening and facilitating solutions that address the situation. One such frustration is L2 interop(erability) - standards, liquidity, and UX across L2s needs to get better
The Ethereum Foundation (EF) is running its first-ever internship, and an aggregated resource is provided here to give insights into the R&D teams. It’s intended to help potential applicants do proper due diligence on the teams they'd be interested in working with and includes information on all EF R&D teams, with the teams relevant to the internship denoted.
While creating this resource, it became clear that it could serve as a valuable tool for the broader public as well. For this reason, it’s being made publicly available so anyone interested in Ethereum R&D can benefit from it.
Each list of links is far from comprehensive! Teams each have their own resources and ways of presenting their work and this overview simply aims to cover a broad sampling of each team's research interests.
[ internship ]
The Applied Research Group (ARG) bridges the gap between theory and practice navigating the path to the future of the Ethereum protocol. Working at the research frontier, they identify open problems facing Ethereum and apply a broad skill set of analysis and engineering expertise to identify how best to move solutions from the idea phase into production. Their interests center around protocol security, scalability and sustainability including topics like the consensus staking protocol, interactions with MEV, expanding Ethereum’s data layer, and protocol support like testing and specification writing/maintenance.
Links:
Pectra
Until recently, the host of the
But back to the point - how do you get this attention on the problems that you as an app developer experience? Here’s how I see the process - and this isn’t an official process™️ - it’s just how I’ve seen it work in this governance model we call rough consensus.
Find others who are similarly affected by the issue that you experience. If you’re an L2 app developer, even better if they’re across different L2s. Write up explainers about it. Gather feedback from those who are affected. If it’s a widespread frustration, it might be a good candidate for a proposal
You’ll need to brainstorm a fix, but you don’t have to do it alone - you can start off by looking at EIP-1, which describes how the EIP (Ethereum Improvement Proposal) process works. Knowing the process can help you approach the problem with a framework for a solution
Does it need to be an EIP? It should only be an EIP if it absolutely must be a protocol-level change. Maybe what you need can be handled at the application layer with an Ethereum Request for Comment (ERC) or Rollup Improvement Proposal (RIP) - these will be faster processes as you don’t need to wait to be included in a network upgrade
Bring that conversation to the appropriate category on Ethereum Magicians. If you don’t know exactly what the fix for the problem is, this is the place to flesh it out! This is also where you can gather feedback to ensure it truly is necessary at the protocol layer
When you have a draft for your EIP* (using the template), you can submit it to the EIP Github repo as a pull request. You can check out old examples of newly proposed EIPs here. You will also need to create a discussion topic in Eth Magicians and an EIP editor / associate will assign your EIP the next sequential number
*scroll down to “writing an EIP is daunting” for tips on getting an EIP written
This is where it’s important not to let momentum drop off - you need to educate the appropriate people about your EIP. If there’s strong support behind it, it’ll be easier to get included into the process! The people who need it should be willing to publicly put their support behind it. Write posts explaining the benefit and costs of the EIP and share them and your Ethereum Magicians discussion widely!
If you’re technical (or know someone capable), you can implement a proof-of-concept on at least one client or client pair. u/sm3gh34d points out that EIP-1153 languished until it had PRs to clients
Once you have general consensus from the community that:
this is an important change that’s needed
it will make life better for a large majority of app developers and / or users
the change will not break things (you’ll likely need client teams to chime on this bit - and depending on where in the next network upgrade cycle we are, their bandwidth may be limited)…
then…
Propose it for a specific network upgrade by opening a pull request to add it to the Proposed for Inclusion section of the Upgrade Meta EIP (which is the EIP that lists all the EIPs going into the upgrade)
Prepare a short (~5 min) presentation with slides to explain to client teams why it’s important to implement, what it does, who it affects, and what kind of due diligence has been done to make sure it doesn’t break things
Then ask to add the EIP to for the agenda of the next appropriate ACD call (depending if it impacts execution or consensus layer). This can be done in the open issue for the meeting & make sure to include your slides. Client developers may choose to wait so they can review all of the Proposed for Inclusion EIPs for a network upgrade in one go
Attend calls relevant to this! There are all kinds of breakouts on different topics both within the pm repo and outside of it (e.g. L2 Interop, RollCall, CAKE) and the best way to make sure your EIP doesn’t fall off the radar is to go to the relevant calls
Keep up the momentum! Educate the community about it and keep the public updated on the EIP’s progress
I know what you’re thinking at this point:
If you lack the funding to dedicate time to this process, there are a ton of public goods funding initiatives that will fund exactly these sorts of things. If your proposal benefits L2s, check out Optimism, Arbitrum, Polygon or Base for grants. If it benefits a wide variety of app developers, check out Gitcoin, Octant or the EF’s Ecosystem Support Program (EF-ESP).
If you don’t feel like you’re the right person to brainstorm a fix, that’s okay! You can stop at the first step. Gather feedback, write up explainers, talk to people who might be able to bridge the gap of knowledge in order to come up with a solution. Sometimes the right people to figure out the solution to something is a different group than the ones who experience the problem.
Jason Chaskin at the Ethereum Foundation just started a series where you can get your experiences in front of some core devs, researchers, and those in the EF in a private call. It was kicked off with Patricio Worthalter at POAP, who spoke of his issues with the L1 and roadblocks he’s encountered while building on Ethereum and it was very illuminating for those who attended.
To help you draft an EIP or if you have questions about the process, there’s a regular EIP editing office hour hosted by the Ethereum Cat Herders (ECH). And if this is your first EIP, I suggest reaching out to someone who’s written one before for some advice or mentorship!
Ethereum is a new type of technology and the cadence and norms for these upgrades have just recently been established and rapidly evolved along the way.
Coordinating the upgrades around decentralized software that has millions of participants, tens of thousands of developers, and hundred of core protocol developers is a new situation to navigate. With an enormous amount of increased interest in getting features into the network upgrades in the past few forks, it has become clear that the current process has its strengths and weaknesses in choosing which features get prioritized and which do not.
As the ACD calls have gotten relatively quiet while the final Pectra feature set is implemented, tested, retested and tested again, core developers and protocol supporters are now taking the time to talk about what can be done better in the process. If you want to follow along or contribute to the conversation, check out Tim Beiko’s thread on Ethereum Magicians.
I know this can be a frustratingly long process. As Ethereum’s value, relevance, and number of involved parties increases, the more difficult it becomes to get consensus across the majority. Whether or not this is on our way to protocol ossification and subtraction of human intervention is a matter of discussion. This is the nature of decentralized governance & “rough consensus” and the tradeoff we make to get a credibly neutral platform on which to launch our apps.
EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
Data viz
Toni Wahrstätter’s dotpics.info, where onchain data is visualized for easier digestion
Blobs
Censorship resistance
EIP-7547: Inclusion lists
EIP-7805 (collaboration): FOCIL
MEV’s impact on the L1
Validator set decentralization
With fast-evolving tech, the EF’s researchers have found their own niches and directions and teams have split off from each other. The Consensus R&D used to be the EF Research Team. Now it’s one of many and with its focus being on improving the consensus layer.
Links:
consensus-specs Github repo
Developed and maintains the original staking-deposit-cli
Research to improve the consensus mechanism & mitigate problematic side effects (smattering of ethresear.ch posts)
hackmd post for validator hardware specs: Hardware Requirements For Validators
L2 interop
Pectra
Wallet QoL / UX: EIP-7702: Set EOA account code
Staking QoL / feature: EIP-7002: Execution layer triggerable withdrawals
Validator set size: EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
Validator security / UX: EIP-6110: Supply validator deposits on chain
The cryptography research team researches cryptographic protocols that are useful to the future development of the ethereum consensus protocol and more generally for the ethereum community. They provide support for the core research team, publish and review research papers, give presentations in a wide variety of events, participate in standardization processes, and provide outreach to the wider academic community.
Links:
Security analysis
Ethereum VDF security analysis
Publication: Cryptoanalysis of Algebraic Verifiable Delay Functions
ProgCrypto Devconnect 2023: Talk
Data Availability Sampling (DAS)
4844 and PeerDAS KZG library / polynomial commitments spec
FRIDA / Foundations of DAS
Publication: FRIDA: Data Availability Sampling from FRI
Publication: Foundations of Data Availability Sampling
Zero-knowledge proofs
Elliptic curves
[ internship ]
The Protocol Security Research team safeguards Ethereum’s integrity. Through coordination, meticulous code reviews, research, developing advanced tooling, and real-world simulations, they focus on securing the network and its critical components. Their hands-on approach includes managing the bug bounty program, continuously monitoring the network, and collaborating with client teams. They’re committed to identifying and mitigating risks to Ethereum mainnet.
Links:
Protocol Security Github repo
SoK: What don’t we know? Understanding Security Vulnerabilities in SNARKs
Code review & sourcing audits
[ internship ]
The Robust Incentives Group is a research team dedicated to the study of mechanism design and cryptoeconomics for Ethereum. Their work maps all the ways that incentives directly or indirectly affect users and protocol stakeholders of Ethereum. Where possible, they propose mechanisms to recover incentive compatibility and system optimization. Their methods are varied, from formal analysis to data science and simulations, and they engage academic and general audiences with diverse formats of grants, publications and talks.
Links:
RIG website: RIG does a great job of keeping their website up-to-date!
Censorship resistance
FOCIL overview: https://meetfocil.eth.limo/
by Thomas Thiery, on September 30th, 2024 Thanks to Julian, Terence, Jihoon, Jacob and Anders for their input and feedback on this post. Introduction Fork-Choice enforced Inclusion Lists (FOCIL) is a mechanism designed to enhance Ethereum's censorship resistance and chain neutrality properties by enforcing timely transaction inclusion.
focil => fossil => protocol ossification by Thomas, Barnabé, Francesco and Julian - June 19th, 2024 This design came together during a small, week long, in-person gathering in Berlin with RIG and friends to discuss censorship resistance, issuance, and Attester-Proposer-Builder-Consensus-Execution-[insert here] Separation.
Staking & issuance
issuance.wtf: comprehensive & up-to-date list of all issuance discussions!
Vorbit SSF with circular & spiral finality: validator selection & distribution
MEV: PBS, APS, MEV burn
[ internship ]
The AA team focuses on the development, growth and coordination efforts related to account abstraction and chain abstraction, which started via the ERC-4337 standard, and continue through additional standards and protocol level changes on L1 as well as L2s. The team is responsible for research and development of various components and standards of account abstraction, chain abstraction and cross-L2 communication. It also supports entities in the ecosystem that are building on top of these standards, while advocating for their overall adoption in the space through education, conferences, grants and other growth strategies.
Links:
Entrypoint v0.7: Announcement
EIPs
ERCs
ERC-4337 Shared Mempool: Announcement blog post
ERC-7769: JSON-RPC API for ERC-4337
ERC-7796: Conditional send transaction RPC
RIPs
Talks
The EthPandaOps team helps ensure well tested, co-ordinated, and safe forks on Ethereum. They achieve their goals via custom tooling, deployment scripts and data collection pipelines. Additionally, they aim to empower the community to repurpose our tools for their own needs - whether it’s testing, data visualization, or deep analyses.
Links:
EthPandaOps is marvelous, I don’t need to create a list of links because they already have a list of their links and an overview of their projects
Devcon 2024: Tales from Interop
[ internship ]
Geth (go-ethereum) is a Go implementation of Ethereum - a gateway into the decentralized web. Geth has been a core part of Ethereum since the very beginning. Geth was one of the original Ethereum implementations making it the most battle-hardened and tested client. Geth is an Ethereum execution client, meaning it handles transactions, deployment and execution of smart contracts and contains an embedded computer known as the Ethereum Virtual Machine. Running Geth alongside a consensus client turns a computer into an Ethereum node.
Links:
The Ipsilon team’s core concern is the execution environment / engine of Ethereum (aka the EVM or any future versions or replacements of it). This includes both Mainnet and L2s. They provide analysis and implementation of own and third party proposals (i.e. new EIPs proposing changes to the EVM), provide tooling (evmc, evmone, fizzy), and support existing teams (e.g. go-ethereum, Silkworm/Erigon, Solidity, Vyper, Fe, Huff) with implementation and analysis.
Links:
Website, with an up-to-date list of articles, EIPs, and talks!
The JavaScript team provides core Ethereum protocol implementations which are mainly targeted to be used in a development context, being it as an integral part of main Ethereum developer tools like Hardhat, Truffle or Remix or as building blocks for browser UIs of decentralized applications (dApps). They maintain EthereumJS and Ultralight (the JavaScript Portal Network Client).
Links:
js-team-organisation Github repo, with detailed roadmaps!
EthereumJS Github
Ultralight Github repo
Live roadmap with links to current work
[ internship ]
The Portal Network is a new networking design for Ethereum that aims to solve the data availability problem for "light" nodes without having to trust or put extra strain on full nodes, by sharing the necessary data in small chunks across the network. Internally the team works on Trin which is a portal client written in Rust.
Links:
[ internship ]
This team is a combination of two projects that came out of what was referred to as the “Testing” team: Ethereum Execution Layer Specifications (EELS) and Ethereum Execution Specification Tests (EEST).
Ethereum Execution Layer Specifications (EELS): The EELS project is responsible for the main Ethereum protocol reference specification written in Python, which aims towards replacing the yellow-paper specification and being a crucial aid to the EIP process in order to provide a prototyping framework for new updates. Check out the Devcon SEA 2024 talk on EELS.
Ethereum Execution Specification Tests (EEST): The EEST project is responsible for the Ethereum protocol reference tests, used by all clients to detect consensus issues during new hard-fork implementations and regressions. Check out the Devcon SEA 2024 talk on EEST.
The STEEL team also takes care of maintaining and improving the tooling, frameworks, documentation and guidance required to facilitate the client developers with the consumption of the tests, which includes the EEST, the legacy ethereum/tests repository, and also integration tests in the form of various hive simulators.
Links:
EELS Github repo
EEST Github repo
STEEL Devcon 2024 R&D workshop breakout notes
The Snake Charmers team maintains Ethereum Python developer tools, provides user support, and creates educational resources to empower those users. The Snake Charmers collaborate with STEEL to aid in EIP implementation and testing, and provide ongoing maintenance support for other python libraries written by EF members, like the staking-deposit CLI.
Links:
The Stateless Consensus team is dedicated to building Stateless Ethereum, an evolution of the protocol designed to support significantly scaling the EL while also reducing hardware and computational requirements.
Links:
Share Dialog
Share Dialog
Share Dialog
