Add zkEVM working group

[tvanepps]

Proposal: Add zkEVM working group

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 consensus 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

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".

[lightclient]

Doesn't seem like there is rough consensus on this one. What are the next steps?

[cheeky-gorilla]

Doesn't seem like there is rough consensus on this one. What are the next steps?

Trent and I have just pinged all team leads to get more eyeballs on this PR, and also to get "team-level" consensus on adding a zkEVM working group or not. Will share once we have that! In the meantime, members should feel free to continue voicing their opinions here!

[lightclient]

I don't see "team-level" consensus defined in the eligibility docs. It seems to be a function of all members.

[sauliusgrigaitis]

Doesn't seem like there is rough consensus on this one. What are the next steps?

Trent and I have just pinged all team leads to get more eyeballs on this PR, and also to get "team-level" consensus on adding a zkEVM working group or not. Will share once we have that! In the meantime, members should feel free to continue voicing their opinions here!

Grandine's position is that zkEVM is not mature enough area to be comparable to what most of the PG teams are working on. However, I'm ZK fan myself.

Given there is no rough consensus maybe it makes sense to wait for the next opportunity to reconsider it. Alternatively, a solution would be to allow client team members work on ZK. This would naturally limit the headcount, and this would drive research to production much more.

[lu-pinto]

First of all let me say I appreciate the work @kevaundray, @jsign and @rodiazet are doing in ZK work and wouldn't like for them to move out of PG since they are doing a great job in pushing that research work forward.

Having said that I feel it's still research work at this point, there are no EIPs out there that quantify or accurately describe implementations, the amount of work required at the protocol level for clients to implement. It is on the Ethereum roadmap but there are no plans for implementation yet, just exploration work for now. The same argument could had to post quantum research, they are also not listed here yet and it's definitely on the roadmap, should we list them? I think this opens a precedent for other research streams to get included.

Now if we compare to statelessness, there are EIPs and an implementation path for clients. Whether it's going to be included or not it's an open debate but until it's on the table for a future fork it should be part of PG IMO. That's my personal reasoning about inclusion in PG.

I would be happy for these folks to be in the Uncategorized section or other existing ones for now, because of what I mentioned initially, and a ZKEvm group created later on when the work is scoped into EIPs.
Having less groups should not stop PG going for a vote to add new members to existing groups.

[tvanepps]

I want to clarify some misconceptions that have come up in discussion over the last week

1. we cannot have an "Uncategorised" catch all category to hold random contributors. this will be abused. The point of working groups is to give people a well-defined scope to check their contributions against. Otherwise i would just nominate all the people working on zkEVM to "Uncategorized". If we cannot justify or accept the contributions members are making to a particular existing/proposed working group, this means they must be removed from the membership. this means Kev, radek, Ignacio, Justin Drake, will be fully removed the membership, and potentially others. These are people who have made incredible contributions to Ethereum over the years, many of you have collaborated with and value their inputs. I want members to understand impact of their signaling on this proposal. cc @lu-pinto @potuz as i have seen this perspective from you

2. "It's too early / should have an EIP/CFI before eligibility". By definition, research is early. There are many ongoing research streams that will take years to play out. Now is the time to find what works and what doesn't to inform our future decisions. the only reason stateless had EIPs is because there was extensive research and proving that preceded them. These individuals face the exact same undercompensation and competitive pressures from outside core development.

If this is really the bar that members want to enforce, it would entail a gutting of the entire wayfinding category which doesn't become an EIP or CFI for extended periods. this encumbers two independent political processes (fork inclusion and funding), will make ACD even more contentious because your future comp is in question. increases the weight of every decision, and makes people much more likely to lobby for time and mindshare even more than they already do! the lead up from EIP creation to CFI can be years, people would need funding during that time to refine constructions/iterate. I will not be advocating for this

As Barnabe mentioned elsewhere, gating on EIP/CFI will fund the solutions to problems, not research about the problems themselves. However, in recognition to some of the discussion, I will be adding some of his suggestions to better frame the Wayfinding category today

3. Any client contributor that works on this stream will also be removed from eligibility or have their weight reduced (currently some devs at teku, and potentially lighthouse, nethermind). cc @sauliusgrigaitis as you commented this above

[lightclient]

We cannot have an "Uncategorised" catch all category to hold random contributors

They can be in the prototyping category. Justin is already in the architecture category so he isn't uncategorized. I don't think anyone is specifically trying to remove those contributors from PG. We don't need a 1:1 mapping of Ethereum Foundation teams to categories. Even the documentation states that WGs and categories are more informational than anything:

The delineation between categories and working groups below is for informational purposes only - contributors quite often collaborate across many different working groups and projects

"It's too early" is inconsistent [..] However, in recognition to some of the discussion, I will be adding some of Barnabe's suggestions to better frame the Wayfinding category today

I don't think it is inconsistent. The main eligibility criteria for PG that I think most members would agree with is:

strictly necessary and existential software required to produce blocks and advance the chain (eg. MEV boost and light clients are omitted here as they are not required for local block production and are not implicated in consensus activities)

Optional zkEVM execution proofs clearly does not meet that bar. Yes there may be exceptions to this, but they require rough consensus, which has not been achieved.

Additionally:

The eligibility start date for the project is the date at which the project met the Eligibility criteria above (eg. after open sourcing)

The "open sourcing" of the project should probably be the date of the EIP, which means it isn't eligible until next March. Optional is still not "strictly necessary", but maybe we will have more clarity in the future. Right now if zkEVM can become "strictly necessary" on L1 since undeveloped aspects of who will provide proofs, where will people get state, how will txs be propagated around the network, etc. I think this is the point many client devs are making.

Any client contributor that works on this stream will also be removed from eligibility or have their weight reduced

There would need to be rough consensus for this, which I don't think there currently is?

[jtraglia]

I want to acknowledge that zkEVM work shows strong long-term potential for incorporation into Ethereum L1. However, it is not mature enough at this stage. For that reason, I do not support including zkEVM teams in Protocol Guild at this time.

[fredrik0x]

"If we cannot justify or accept the contributions members are making to a particular existing/proposed working group, this means they must be removed from the membership. this means Kev, radek, Ignacio, Justin Drake, will be fully removed the membership, and potentially others. " - Would this really need to happen? I can't imagine a scenario where I would vote to remove them from PG as I feel their work is in line with what PG is for. It feels to me like the people putting efforts into zkEVM could fit into groups such as these as their work is touching all of them in some way:
Architecture & Coordination
Cryptography
Prototyping

If this is more about being more clear to potential donors, one way could be to add an extra row on Wayfinding which specifies the area they're currently exploring (FOCIL, Lean, zkEVM, etc) which could make it easier for potential funders to understand what areas are being actively researched, prototyped, etc, without having to create a completely new category at this point in time.

[potuz]

Otherwise i would just nominate all the people working on zkEVM to "Uncategorized".

I think this is precisely the issue some of us are raising. The purpose of PG is to retain contributors with a proven track record of L1 work to stay working. I believe the bar is and should be different for people with this proven track record of having already made contributions L1 than for people that have a proven record on areas that are arguably a bit early to be considered L1. Thus, it is very likely that a nomination for "Uncategorized" for someone like @kevaundray with a bunch of work on a series of projects that have hit directly or indirectly (like go-KZG) L1 then it would be approved. He would also be approved if he were to be included in this new zkEVM group. However, someone who's only work has been in zkEVM is likely to have some friction to get in if cataloged as "Uncategorized", while none at all if we include a new group.

Even as Uncategorized it is likely that people don't get any push back since in my experience we tend to either innact or follow the recommendation of the proposer. But still it raises visibility and scrutiny that otherwise these cases would not have.

[garyschulte]

The issue seems to be that creating a zkevm category is an implicit PG stamp on a future direction that is unclear. Nobody wants to oust anyone that this PR purports to categorize under a zkevm category.

I am ambivalent about this PR since I presume a zkvm / zkevm future is almost a foregone conclusion given the momentum. However, this PR implicitly states an opinion and endorses a particular view of future ethereum development by enshrining it as a category.

If this PR was opening the floodgates to a cadre of zkvm teams it would be a different story, but IMO this is a bit of a tempest in a teapot since everyone agrees the contributors in question belong in PG. I will 👍 any PR that is neutral to roadmap and reflects the reality of the value these contributors bring to ethereum.

[lu-pinto]

I may have been misunderstood. I do believe research needs to be compensated, and zkevms is important on going research. Though the creation of a specific category seems a little premature at this point.

Maybe the Uncategorized group is a bad choice, agree, but why not Prototyping for now? Could create a narrower and more accurate working group after that. Can't see why we would have to remove people if there isn't a new group.

[ralexstokes]

• zkevm is happening, happy to discuss with anyone if they don't agree

• the spirit of this PR should be adding context to current PG members, and we should take any concerns around "opening the floodgates" to future PRs when that is a problem

• if we can't get consensus here, i'd suggest separating the eligibility decision of those listed above from the creation of (i) a new working group and (ii) its placement in wayfinding -- this PR couples a few different concerns together and it complicates the decision

i approved above, as i think this is a straightforward change that just reflects what is already happening today and it doesn't materially change PG itself in isolation. i am surprised there is so much pushback on what seems like a very clear path forward for ethereum and its roadmap :)

[rolfyone]

From extensive side discussions, i agree with this specific change but also think we need to dig further into the reasoning behind the discourse, as there's some threads to pull.

In the interest of not blocking this because of that side discussion, i think its prudent to approve this one. I do agree that a specific topic is preferred to 'uncategorised'.

[lightclient]

the spirit of this PR should be adding context to current PG members

I feel like the spirit of this PR is proposing to members a new work stream that will be eligible for PG? Not just adding context- it is seeking rough consensus to be ratified.

[AgeManning]

I agree with alex:

if we can't get consensus here, i'd suggest separating the eligibility decision of those listed above from the creation of (i) a new working group and (ii) its placement in wayfinding -- this PR couples a few different concerns together and it complicates the decision

My preference is to try and get a super majority rough consensus if we are adding a new eligible working stream and we should be hesitant pushing new streams that are contentious. It seems that zkEVM is contentious and perhaps it requires pushing this to the next update where potentially it may be less contentious.

Personally, I don't mind adding zkEVM as a working group as it currently has little impact to the membership pool and we can revisit any future issues if they arise with new members in the group. I agree with others that the subjective nature of this inclusion isn't great and maybe we can improve somehow, like the documentation suggestions. Specifically for zkEVM and the current proposed members (ignoring future possible members as I think we can address when they arise) it seems to me and if I were to bet, the work being done now will benefit Ethereum L1, even if the decision is to abandon it (likely informed by the work being done now).

Caveat: I just voted myself out of PG, so I have less stake than others. Something to consider with my opinion here.