Add zkEVM working group

[tvanepps]

Proposal: Add zkEVM working group

Note: the latest commit reflects suggestions from the discussion to better describe the constraints research and prototyping working groups should be bound by: read here

Motivation

This proposal outlines the rationale for creating a zkEVM working group within the Protocol Guild. This working group will focus on efforts that benefit the entire ecosystem and help scale Ethereum. Consider an excerpt from the zkEVM book:

[zkEVMs] rely on a cryptographic tool known as a succinct non-interactive argument of knowledge (SNARK). The key idea is simple: instead of requiring all validators to re-execute every transaction, we allow a single party, typically the proposer or a specialized prover, to execute the block and generate a short cryptographic proof that shows the correctness of this execution. This proof is then included with the block. Importantly, verifying this proof is much cheaper than re-executing the entire block. By verifying the proof instead of re-executing every transaction, validators dramatically reduce their computational and hardware demands. This allows Ethereum to safely raise the gas limit — and thus increase throughput — without compromising decentralization or validator accessibility.

Additional higher level context can be found at these links:

• Shipping an L1 zkEVM #1: Realtime Proving
• Protocol Update 001 – Scale L1
• Making Sense of a ZK Staking Node

Given the benefits outlined above, it is appropriate to include this new working group under the Wayfinding category: "the exploratory process to surface, describe and validate potential protocol changes". For a similarly positioned long-term engineering explorations currently eligible for PG funding, we can compare to post-quantum cryptography research, or the verkle/stateless efforts.

Eligible Scope

The initial scope of this proposal is narrower than the previously withdrawn Snarkification Working Group proposal from July 2025. While it's true that Ethereum's "snarkification" roadmap is still in its early stages and will likely evolve over several years, the launch of zkEVM "Attester Clients" is anticipated in the short-to-medium term.

Here, EL clients are compiled into RISCV bytecode, AKA the "guest program". zkEVMs take the bytecode plus some input like the block, which outputs a proof. Modified CL clients are able to accept this proof, instead of running an execution client and needing to verify the EL block. Work for clients is already underway:

• Lighthouse
• Teku here and here
• guest program compilation by Nethermind

This initial eligible scope:

• Includes the specification which integrates both consensus and execution verification into a single binary.
• May include guest program benchmarking, security, and compilation as relevant for the attester client work
• May include zkEVM coordination, proof verification, specifications as relevant for the attester client work

Member WG affiliations

In speaking with Kev, I anticipate an additional ~4 nominations from the scope above.

This PR also moves existing members to the proposed new working group, who should provide new links to reflect this work: Ignacio, Kev, and Radek. Any other current members working on any attester client experiments should be fine to remain under their existing working groups, but are invited to update their relevant links.

🚨 PLEASE NOTE 🚨 If this proposal is rejected, then we are obligated to remove/reduce the weight of anyone working in this area from Protocol Guild membership and funding. This includes the three existing members, and potentially any client devs working on it.

Exclusions

"Lean Consensus" client teams are not covered by this proposal.

[gballet]

Suggested change

	| **Statelessness** (1 contributors) | | |
	| **Statelessness** (2 contributors) | | |

[gballet]

this is because it's going to clash with another PR I'm preparing

[kevaundray]

can't your PR or this PR rebase depending on which one gets in first?

[JustinDrake]

Great proposal :) A couple technical comments:

EL clients are compiled into RISCV bytecode

RISC-V is not necessarily the target ISA. For example Geth was compiled to a MIPS zkVM here.

guest program compilation by Nethermind

There's a bunch of progress with guest programs beyond revm and Nethermind :)

• Keeper: Geth is running as a guest program on Ziren (see here)
• Ethrex is running as a guest program, e.g. on SP1 Turbo (see here)
• Zilkworm: evmone is running as a guest program, e.g. on SP1
• ZKsync OS: EVM implementation by MatterLabs running as a guest program, e.g. on Airbender

Looking ahead I expect even more guest programs :)

[kevaundray]

Great proposal :) A couple technical comments:

EL clients are compiled into RISCV bytecode

RISC-V is not necessarily the target ISA. For example Geth was compiled to a MIPS zkVM here.

guest program compilation by Nethermind

There's a bunch of progress with guest clients beyond revm and Nethermind :)

• Geth is running as a guest program on Ziren (see here)

• Ethrex is running as a guest program, e.g. on SP1 Turbo (see here)

• evmone is running as a guest program, e.g. on SP1 (this is an effort by Erigon called "Zilkworm")

• ZKsync OS (an EVM implemenetation by MatterLabs) is running as a guest program, e.g. on Airbender

Looking ahead I expect even more guest programs :)

On the target ISA, RISCV was mentioned as a simplification for the explanation, since it's the one that is currently supported by most zkVMs. It's true that there are some zkVMs that are targeting MIPs/WASM

One thing to note on guest programs is that this proposal as I understand it, includes guest program compilation in the scope, but not guest program development (ie the STF) -- which was why nethermind was mentioned.

Looking ahead I expect [even more]

I think this is a concern that has been echoed by many in this group re EL/CL clients, which is one reason to have the scope narrowed down to guest program compilation initially

[lightclient]

As I mentioned in #372:

I think it is too early to consider this work for PG. It would make sense to revisit when a zk protocol is in consideration as a headlining feature on L1.

The plans continue to be that this is an optional optimization for clients and it is not yet considered for any fork.

The only defensible bar of eligibility to PG is active and regular contributions that are realized on L1. Anything else will unravel in complexities. The EIP that this work sits behind is 1 week old and just a stub for future work. It doesn't seem ready to dedicate a working group to.

[tvanepps]

It would make sense to revisit when a zk protocol is in consideration as a headlining feature on L1
not yet considered for any fork
active and regular contributions that are realized on L1

@lightclient I strongly disagree. These are near-sighted and narrow frames, which have never been a requirement for PG eligibility, as i mentioned last time we discussed the snarkification proposal. by your measure, the beacon chain work starting in 2018 would not have been eligible because it wasn't yet scheduled for the Merge in 2022. our docs currently use this language to describe the wayfinding category: "the exploratory process to surface, describe and validate potential protocol changes" - should we remove this entirely?

post-quantum cryptography research, or the verkle/stateless efforts

Please describe how you differentiate zkEVM work from either of the research tracks above? tradeoffs will be explored, and many iterations will never get close to mainnet! and yet the work to foreclose paths is also important, and continues to be funded by PG and many other orgs.

final note - you have also just signaled support for state expiry research, which to my knowledge is not currently being actively considered for any upgrade in the near term. can you help me better understand how to square the seeming inconsistency?

[rolfyone]

It seems like we're a little inconsistent with adding teams, similar things to this have been rejected in the past on a basis that they're not slated for inclusion etc... but I did look at the eligibility we've doc'd so lets go...

By our eligibility criteria:

• champion of ethos (👍 )
• open source licence (👍 )
• presence in governance venues like ethresear.ch (👍 ) breakouts (?) (theres also protocols calls + interop, admittedly teku using lighthouse for interop)
• engaged in prototyping (👍 )
• continuously for at least the last 6 months (on zkevm) (?)
• full time (on zkevm) (?)

So we should at the very least probably answer the last 2, which doesn't seem adequately covered above for me to give a fair assessment. I did try dumpster diving commits but it was hard to see what Ignatio is spending their time on, Kev was more obvious, Radslow i'm not sure what some of the projects are, but eof for example Im not sure how would tie into zkEVM.

[jsign]

@rolfyone, happy to explain my personal work in the last months:

• Between April and July, I worked on adding benchmark test cases for EEST, which was a concept that didn’t exist. Originally, I started this project as a way to determine how to establish long-lived and maintained benchmarks for zkVMs in the worst-case scenarios of the Ethereum protocol. Many more core developers collaborated on the effort — these cases ultimately proved also helpful for Perfnet.
• The above was initiated when I was still part of the Stateless consensus team at EF. After the Berlin interop, I changed teams to the zkEVM team.
• In the last three months, I’ve been working (with other teammates) on the workload and ere repositories, which are infrastructure that mainly covers:
  • A unified and reproducible way to benchmark zkVMs for the Ethereum protocol. (We don’t care about other cases for zkVMs in particular). The main goal is to discover (with reproducible numbers) which changes in the protocol we might need to potentially use this tech in the protocol.
  • Explore which EL client optimizations are needed in the context of zkVMs (for this, mainly see merged PRs in the workload repo).
  • Started helping EL clients with their readiness for being zkVMs guest programs.
• I’m working full-time on this topic (as I did before in my previous team).

I see now working in the zkEVM team mainly as being more aligned with my current line of work. My previous work in the EF Stateless Consensus team was also stateless related (Verkle and Binary trees). "In paper" is another team, but my underlying motivation is the same: how we can improve the protocol using stateless strategies.

[lightclient]

These are near-sighted and narrow frames, which have never been a requirement for PG eligibility

I have supported narrower framing of PG for awhile as it avoids scenarios such as years of Portal eligibility. The "wayfinding" category is totally subjective and basically boils down to trusting the individual people / teams involved in the effort. I don't think this is a very defensible eligibility criteria. I think it is reasonable to expect individuals in this category to have a history of direct contributions to the L1 protocol and I think many people do, e.g. Kev has worked on many projects from the KZG related work, general 4844 / blob work, client hardware specs, etc.

the beacon chain work starting in 2018 would not have been eligible because it wasn't yet scheduled for the Merge in 2022

I don't think it is fair to compare Ethereum circa 2018 to today. There was much higher alignment on what to do and who was doing it. Also important to note that the beacon chain itself was L1 since it issued real ether, so they were expanding the protocol in that way. Currently we still in the stages of optional adoption of zk proofs - I don't think this in and of itself merits addition to PG. However, I believe many people working on the effort are generally eligible due the contributions on other active EIPs / efforts.

Our docs currently use this language to describe the wayfinding category: "the exploratory process to surface, describe and validate potential protocol changes" - should we remove this entirely?

I think removing this category would lead inclusion in PG to be a more objective decision. Most of the wayfinding members would continue to be eligible due to contributions they have already made to the protocol and plan to continue making. Maybe the best way to framing this is that PG should reward success and it is extremely difficult to measure success of projects that are not on the critical path e.g. required to operate L1. This is what I see the wayfinding category as. Consistent negative results are difficult reason about -- are the results negative because the problem is very hard? Or because the problem is unimportant? Or is the investigator not the best fit? PG isn't designed to answer those questions.

Forcing wayfinders to make more meaningful contributions to L1 seems like a very positive outcome of modifying the category. I don't think someone with a minimal track record should be able to be a wayfinder for years working on projects that end up being dead ends.

Please describe how you differentiate zkEVM work from either of the research tracks above (PQ / stateless)? tradeoffs will be explored, and many iterations will never get close to mainnet!

PQ I have never weighed in on w.r.t. to PG, but I do think most involved in that track do contribute directly to L1 by helping us with various crypto proposals such as KZG, BLS, modexp, etc.

Verkle / stateless is a difficult one because it was softly scheduled in ~2021 and has continued to be proposed for every fork since then. IMO it is at a different maturity level compared to other wayfinding efforts and has for a long time been a priority of the geth team. Like I said, the optional zkevm EIP was only created last week.

I would turn it back and ask how zkevm is that different from the AA team? They are more developed in some ways, but has similar levels of L1 certainty / uncertainty (depending on who you ask). My point is that wayfinding inclusion as currently defined is just too subjective.

final note - you have also just signaled support for #404, which to my knowledge is not currently being actively considered for any upgrade in the near term. can you help me better understand how to square the seeming inconsistency?

Stateless has been proposed for every major fork since the merge. I think it is your perspective that it isn't being actively considered, I think if geth could chose we would prioritize it :) The stateless team is already in PG and it is custom to "trust" the team to police it's own members. I have seen Wei Han's contributions first hand and approved the PR in that sense.

[jflo]

The Wayfinding category of Protocol Guild membership is more subjective than the others. The adoption of an entire working group is a much larger decision than considering an individual contributor. Adopting a working group is an endorsement of a protocol direction, promoting it from pure research that may be discarded, to an aspect of the protocol for which we need to retain talent.

In this context, I cannot endorse a zkEVM working group as a member of the Protocol Guild. I am not yet convinced that this direction of research is ethereum aligned, considering how weakly it addresses the matter of permissionless block proposal:

From the zkEVM book:

To make this goal tangible, the standardized definition for L1 provers includes specific constraints on hardware and energy costs:

• On-prem Capital Expenditure (CAPEX): ≤ $100,000 USD for the necessary hardware.
• On-prem Power Consumption: ≤ 10 kW, a limit designed to fit within the power capacity of a standard residential home.

This is far too thin of a solution to a design weakness that threatens what Ethereum is. I would vote AGAINST a zkEVM working group due to lack of alignment.

[JustinDrake]

permissionless block proposal

See FOCIL EIP-7805. FOCIL would provide significantly more censorship resistance than the status quo, thanks to local inclusion list building :)

Edit: Importantly inclusion list proposers do not need to provide proofs for the lists they propose. A Raspberry Pi would be sufficient to be a list proposer :)

[barnabemonnot]

I'd take a few signals into account for things that are research/not yet CFI'd or even EIP'd:

• Is this generally agreed to be a major direction for the protocol?
• Are the people working on it sufficiently tethered to the protocol production? (this excludes large swathes of academics for instance)
• Are the people at EF or other orgs that are sufficiently tethered to protocol production? (to be clear, neither a necessary nor a sufficient condition, but I do think a legitimate signal of research generally aligned with protocol production)
• Is the work performed according to general research principles? (open production of artefacts, peer reviewed/part of a larger community, systematic and documented efforts to arrive at a result comparing with different approaches)

Noting that the set of people concerned by this proposal may fall closer to "research engineering" than to "research". Here there is an additional set of criteria I'd consider:

• Is the research engineering happening in support of a research direction satisfying the criteria above?
• Are the research engineering resources commensurate with the complexity and confidence for the research direction? (avoid sinking many research engineers behind a research direction that may matter but does not require this amount of resources, or many engineers behind a low confidence but possibly relevant research direction)
• Are these resources necessary to move the research direction to a concrete proposal for mainnet? (sometimes it's really just about implementing but you can make up more research engineering than necessary, e.g, extra prototypes)

In my view the group as proposed satisfies these criteria.

[rolfyone]

I'd take a few signals into account for things that are research/not yet CFI'd or even EIP'd:

so i find it interesting that none of this is documented process, if we don't agree with the documented criteria, or need caveats, maybe the documented criteria needs updating.

[barnabemonnot]

I'm not against a change of documentation, mostly I think of PG as making deliberative decisions more than ticking off boxes and using deterministic rules, particularly for scoping new focus areas vs adding members from existing focus areas.

If it helps to codify some of this, I am for it. Looking back at past messages, this type of discussion already came up and there too I attempted to provide some guiding questions.

[cheeky-gorilla]

I generally stay out of eligibility discussions because my main focus is on the operations side of PG, but I would like to help push the convo forward, so;

It seems everyone's aligned that "Wayfinding" needs to be more tightly defined. Given @barnabemonnot's feedback above, we could expand the "Wayfinding" section's definition from simply "the exploratory process to surface, describe and validate potential protocol changes" to;

the exploratory process to surface, describe and validate potential protocol changes that is:

• In the case of research:
  • Generally agreed to be a significant direction for Ethereum's core protocol
  • Composed of contributors who are sufficiently tethered to Ethereum's core protocol R&D, potentially being part of existing entities or teams focused on such work
  • Performed according to general research principles, including open production of artifacts, peer review, and systematic, documented efforts to compare different approaches
• In the case of research engineering:
  • Supporting a research direction that satisfies the criteria outlined above
  • Equipped with sufficient resources that are commensurate with the complexity and confidence of the research direction, necessary to move the research direction to a concrete proposal for mainnet

We can then also add a sentence at the top of the eligibility page clarifying that "Working groups undergo periodic review as Ethereum's core protocol development roadmap evolves." This clarifies that working groups can eventually be removed, even if today it makes sense to try to retain talent for them (to address @jflo's concerns). As for how we actually carry out those reviews, @shemnon had a proposal here.

As for @lightclient's comments about "removing [the Wayfinding] category" and instead "anchoring to active and regular contributions that are realized on L1", I do agree this would simplify eligibility a ton, however I also believe it would hurt PG's legitimacy and thus impede our fundraising abilities. The reality is, there is basically no discussion about Ethereum's core protocol development roadmap that doesnt involve zkEVM in one way or another. I do not think it's worth streamlining our eligibility to such a degree that the ecosystem no longer feels that PG is helping to fund Ethereum's core protocol development.

Yes the zkEVM roadmap is not 100% finalized yet, but that's also why this proposal only expands eligibility a tiny amount (we expect <5 new member PRs because of this), and are clearly blocking the floodgates of new lean consensus client teams.

So a prompt for the membership;

• If we shipped the revised "Wayfinding" definition above, are we happy?
• I can speak for the entire PG ops team that it is in PGs best interest to make at least a small part of zkEVM work eligible. If you legitimately feel the scope of this PR is too broad (and seriously, it's super narrow currently), what would be a narrower scope?

🦍

[LukaszRozmej]

IMO we could scope eligibility for the work on existing clients first and later potentially expand it.

[benaadams]

Here, EL clients are compiled into RISCV bytecode, AKA the "guest program".

Can we change "RISCV" to "provable"? RISCV is too opinionated for this group

Here, EL clients are compiled into provable bytecode, AKA the "guest program".

[gballet]

There are a few things to unpack here:

1. are the people who would move to that zkevm group deserving to be in PG?
2. should zkvm be its the right category?
3. more broadly, what is the meaning of PG ?

Regarding 1, I don't think anyone would even think of opposing their membership. There is a lot of talent in that team that is "classyin' up the joint".

Regarding 2, which I think is where the dispute lies, and I believe that in a great part, that is because of the chosen name. zkevms are indeed a direction which is somewhat at odds with Ethereum's core decentralization values (in the short term), and there are countless technical challenges to overcome, which makes the endeavor risky. However, there is little doubt that zk will play a role in broader applications, even if the specific task of block building/proving/verification doesn't pan out. Maybe renaming the group name to a more generic "zk protocol" would do? Much like my team isn't "the verkle team", it's the statelessness team, which means that its role evolves as our understanding of the protocol, its intricacies and evolution change as well.

For 3, we have to recognize that PG isn't a way to make a living. If anything, it's a way for the community to show appreciation. I, for one, certainly hope that this can change when the EF runs out of money, to ensure continuity. But until funding matches what is needed to run multiple client teams and research, I believe we shouldn't be gatekeeping too much - a wide variety of contributors are improving the Ethereum protocol, and we should be grateful to them, too. Hopefully, some day PG will receive enough funding to pay a gatekept community of client developers enough to make a living. Core development will look very differently by then. Let's fight it all out when we get there, and enjoy working on the protocol until then. Kumbaya.

So while I recognize the arguments to oppose adding this group, I am in support of doing so.

[gfukushima]

I do share similar thoughts of the ones expressed previously by @parithosh and @MariusVanDerWijden, have worked @jsign and @kevaundray on the stateless front and don't want to see these out of PG due to the value of their work. I do worry about the precedents this PR may set in the future for groups claiming eligibility.

[cheeky-gorilla]

Heads up this PR will be the main topic on today's membership call (15 UTC), encourage everyone to show up!

https://discord.com/events/795514951376568391/1389606551215669308/1425135579955200000

[kamilchodola]

My 2 cents:

I feel like zkEVM direction is "inevitable", same as PoS with beacon chain was at an early stage (even though it was a few years since the first work done until the actual fork inclusion).

PG should help to fund current work but also "encourage" to work on some hard and broad topics, which will obviously make the entire Ecosystem and L1 in particular better, and it seems like everything which is happening around zkEVM implementation in various ways now feels for me eligible (but a bit on the edge, especially knowing the past discussions around Portal Network).

TL;DR;
zkEVM work should be eligible in a scope of PG.

[tvanepps]

Summary + Next steps

→ TLDR: Rough consensus is clearly in support, I've merged this.

This has been a long, nearly 2 week discussion, and I've done my best to track sentiment over that time. (DM any corrections). We've had participation from 41% (72/176) of the current membership - higher than a vote typically sees. Here are the three stances as of the posting of this message:

Stance	Count	Percentage	Member Signaling
Approve	63	86%	alex stokes, barnabe, trent, cheeky, roberto, rolfyone, lukaszrozmej, benaadams, agemanning, yperbasis, kevaundray, JustinDrake, raxhvl, jsign, tvanepps, MarekM25, tanishq, shoham, somnath, rubo, fradamt, nerolation, awskii, rodiazet, yoav, taratorio, bwag, jtraglia, fredrik, mriccobene, spencertb, jklondon, canepat, samwilson, marioezv, Danceratopz, Guru, peter, jrudolph, caspar, mholt, garyschulte, milos, arantxa, giulio, soispoke, asanso, julian, ericsson49, bzawisto, fgimenez, chfast, marchhill, guillaume, smartprogrammer, cbermudez, shekirin, gfukushima, jframe, domiwei, marcin, kamil, damian
Against WG, Support zkEVM funding within existing WGs	8	11%	lightclient, potuz, lupinto, saulius, marius, mehdi auodi, pari, mkalinin
Against WG	2	3%	jflo, matthew keil

To accommodate some of the opposing discussion as it related to missing constraints on the mandate for WGs, I incorporated suggestions from Barnabé and Cheeky, and others. These changes better frame the expectations we have for working groups broadly, and Wayfinding-eligible Research and Prototyping/ Research Engineering specifically ie. being "sufficiently tethered to protocol work". These will help us maintain rigor in our curation and funding allocation processes.

Considering the IETF's framework of rough consensus that we reference in our documentation:

IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement).

Based on the above, I believe we have met the bar for rough consensus and have merged the PR. However, there are new discussions that have been seeded:

• when to create a new WG vs using an existing one
• ensuring future proposals separate out proposing new WG and changing member categories
• what do WGs "mean" as they relate to the roadmap

[mkalinin]

Sorry, apparently my message wasn’t clear. I wasn’t opposed to the new WG, I was in favour of new WG with narrower scope of work. Specifically, narrowed down to the specification only without benchmarking (which involves some level of prototyping) and compilation explicitly mentioned. It is clear that a specification work may involve benchmarking and prototyping, but in that case they are part of the spec work, done by the members of the WG.

If we see 4-8 (arbitrary but reasonable number) people in the WG dedicated to work on the zkEVM specification/design it is totally fine but if we are about to add 20-40 members to that group then something definitely goes wrong. This is why I think it is important to keep the scope reasonably limited.

[prestonvanloon]

Late to this discussion, but I am also in the camp of Against WG, Support zkEVM funding within existing WGs.

[flcl42]

Riscv group can be a pilot group that we agree to include, because it looks in place, imho. Then we need add more details to the pg inclusion rules, that will connect the roadmap and the membership. If something appears on the roadmap in certain strong enough status and a person or a group is showing promising results that may lead to a significant improvement, let's add em. I mean we probably need to decide not directly but through the roadmap, to not discuss every direction of development. We will still decide if level of research, certain quality of software are eligible