Protocol Guild Eligibility for dev tooling post-Pilot

[tvanepps]

I'd like to open discussion on future iterations of Protocol Guild eligibility once the Pilot has concluded in May next year. Jumping off from discussion in this new member proposal.

While solidity is certainly the most used EVM programming language, it isn't the only one. Should vyper contributors be included in PG? What about Fe? Additionally, Tim and I have been approached by Franco from the Nomic Foundation about whether their contributors should be eligible, as they believe it's similarly placed as EthereumJS, which is considered eligible (though it's more of a library, not a mainnet client). But if Hardhat contributors are included, then should Foundry as well?

At a certain point, it becomes difficult for an membership largely focused on the core protocol to properly curate people building developer facing tooling (languages, dev tools, libraries, etc). Deciding a special case based on usage or "importance" (as some have argued for Solidity) is unspecific and doesn't give a clear answer on other languages / dev tools.

My general recommendation is that we should reduce the scope of eligibility to more narrowly focus on people/projects engaged in the maintenance or modification of the protocol itself, not the tools which developers use to interface with it. In addition, I would encourage dev tooling projects to start their own PG analogue: a similar split that can operate under its own eligibility and curation methods. These projects would be best fit to decide their own parameters, and their own eligible peers. That way the scale of PG remains manageable and is able to put forward a more rigorous eligibility framework.

Having these better defined boundaries is crucial for longterm PG success - otherwise we end with members unsure where the inclusion starts, and others hurt by arbitrary exclusion. Very interested to hear additional perspectives here!

[SamWilsn]

I think it's a bit fuzzy no matter where we draw the line. Clients are clearly core protocol, so their devs qualify, but what about just EVM interpreters? How much of a client do you need to write to be a core dev?

I am not leaning either way on whether we should or shouldn't include tooling in PG, but I don't think excluding it firms up the boundary.

[acolytec3]

I think my take on it is asking the question of whether the team/individual working on the protocol as a mainstay of what they do. Taking the specific example here of hardhat vs EthereumJS, I don't see what hardhat does as being core development. Dev tooling, while super important to the health of the overall ecosystem, isn't generally protocol work. EthereumJS, while on the surface might be called developer tooling in some parts, the biggest portion of what we do I would argue is core protocol work. We're implementing new EIPs that are candidates for the next hardfork, participating in meaningful ways on the testnets with our client, building a client for the portal network, engaging in the ongoing work of building the protocol, in other words. Hardhat, on the other hand, is building tools for dapp developers. Not minimizing what they are doing in anyway, but as a team, their focus isn't really protocol development. And, in hind sight, I'd probably say that all of the language teams referenced above aren't really protocol development either, from where I sit.

[dapplion]

Subscribe @acolytec3 points above.

Another tangent to clarify. Protocols used by the beacon chain can also be considered? I.e. libp2p related (discv5, gossipsub, etc) or bls implementations (BLST)

[leonardoalt]

I think my take on it is asking the question of whether the team/individual working on the protocol as a mainstay of what they do.

I see the point here, and don't really want to argue against/for Solidity. However the point above does make me think: looking at the current list, is the above true for

• EF Portal
• EF Research (everyone? mainstay?)
• EF RIG
• EF Security
• Erigon
• Ethereum Cat Herders
• Independent
• Status (???)
• Stateless Ethereum

Again, not saying the teams above are not in that description, but if that is the goal then I feel like there's likely more to be cut out so it doesn't look like "we're keeping only protocol cus ewww languages/dev tooling" while at the same time not keeping only protocol.

[ajsutton]

For me pretty much all the membership curation questions boil down to asking how do we best ensure that donators feel they're getting value for their money? There's a couple of aspects of that question that apply here I think:

1. Does the work we include here match what we advertise the guild is supporting?
2. Are we able to make good decisions about eligibility within the entire scope we're trying to cover?

For (1), this is the "Protocol Guild" and messaging is all about supporting the protocol development. While I think things like Solidity are excellent public goods, I wouldn't consider them protocol layer so I think we'd either need to exclude them or change our naming and messaging.

An interesting follow on question on this point though is whether in the long term if PG is successful we'd expect to see a single "guild" supporting all Ethereum public goods or whether we'd expect to see multiple guilds (Protocol, Dev Tooling, L2 etc). I lean towards thinking there should be multiple guilds because being too broad can easily dilute the value donators get (eg they may want to donate to solidity but not viper, or think L2 has enough VC funding and doesn't need donations). As such I'd be inclined to err on the side of saying "no" more often than yes when we get into grey areas and keep the protocol guild reasonably focussed.

For (2) I think there's already a huge challenge in reviewing membership just at the protocol level where we do tend to interact with people from other teams a fair bit. As you expand further that becomes more and more difficult since there's much less overlap and familiarity with the people or even the areas of work.

I also quite like @acolytec3's reasoning above. It doesn't give a strict rule obviously but feels like a reasonable approach to making the judgement.

[ajsutton]

I see the point here, and don't really want to argue against/for Solidity. However the point above does make me think: looking at the current list, is the above true for

I may not be able to explain all of these but to give some context:

• EF Portal

Portal is a pretty key piece of infrastructure to make things like EIP4444 viable and more generally to reduce the storage burden for nodes on the network.

• EF Research (everyone? mainstay?)

EF Research is predominately focussed on research towards improving the protocol (possibly exclusively). There may be individuals from EF Research that we choose not to include based on the specific research they work on. The fact that we approve individuals not teams as a whole helps here.

• EF RIG

Robust Incentives Group - primary focus as I understand it is on ensuring the protocol incentives are safe, so makes sense to include.

• EF Security

Huge focus on protocol level and client security. Again it may be the case that some people from EF security are focussed on things like contract security and thus wouldn't be eligible though I haven't seen any such work.

• Erigon

EL client. I'd be interested why this was questionable at all - it seems like one of the easiest cases to include in PG.

• Ethereum Cat Herders

Initial focus was very much on helping coordinate hard forks and generally keeping the protocol moving forward. Not sure if that focus has changed more recently as we've had more direct coordination from EF employees - that's purely my lack of knowledge though. An important note here is that I don't think all contributors to the PG have to be technical and cat herders is a good example of more non-technical contributions that have certainly been hugely valuable in the past.

• Independent

Would need to be reviewed individually based on what they're actually working on. Currently it's relatively rare for people to be making significant enough contributions to be eligible without being employed by a team but it's certainly happened and if the PG hits its funding goals could become much more common.

• Status (???)

The Nimbus consensus client team. :) I wouldn't expect everyone at Status to be eligible but the Nimbus team definitely should be.

• Stateless Ethereum

This one also seems obviously protocol related to me so interested to hear why you weren't entirely sure of it.

[q9f]

I would be hesitant to remove compiler teams targeting the EVM from the list of eligible projects for the protocol guild, given their deep protocol knowledge and their ability to create sensible contributions to the protocol-design process such as championing their own proposals or valuable feedback to EVM design changes.

Notably, teams like Solidity which emerged from the C++ client face the same challenges when it comes to attracting and retaining skilled talent and therefore should be considered high value to the protocol guild.

I would draw the line between compiler teams and dev tooling if necessary.

[shemnon]

Does this privilege extend only to the solidity team or does it also include Vyper, Huff, Sway (when targeting EVM), Fe, LLVM to the extent it outputs EVM code, etc. et. al.?

While I'm not opposed to adding the solidity team, I think we need a better heuristic than "a compiler that targets/can target EVM" (which is how I read drawing the line between compiler and dev tooling). Perhaps we add in a requirement that they are involved in the EIP process and contribute when appropriate to teh hard fork process and ACD calls?

[pipermerriam]

I'll start with a link to my most recent talk on Portal: https://www.youtube.com/watch?v=M3HExSykXFI&list=PLtd18ZNqUprgXCpWnVVmC_naqy2H2r11W&index=28&t=1s

I of course would prefer for Portal to remain in PG, and given that there are not clear lines that define what should and should not be included, it's a little fuzzy to know how best to present this argument... but here's the best I've got.... treat it as a starting point, and something that I'd love some back-and-forth on if anyone is so inclined.

I think that the Execution layer and indirectly, the Consensus layer need Portal. I lay some of this out in my most recent talk. The DevP2P eth protocol is a relatively simple data transfer layer and it has a fundamental dependency on "full nodes". The consensus layer depends on reading data from the execution layer and thus also depends on full nodes, albeit indirectly. I believe this dependency on full nodes is a problem that will continue to trend our protocol towards only being accessible to those that can afford the hardware costs of running a full node, which continues to go up

Breaking the dependency on full nodes is what Portal is doing. The execution layer clients and consensus clients should both benefit from this.

Much of what Portal aims to deliver is still speculative, however, our history network is live and is able to serve historical blocks. We are ready for EIP-4444 experimentation and integration to begin. I say this to try and qualify that I'm aware that much of what Portal is targeting remains to be delivered, but that some of it is being delivered now as we speak. And if you believe in our roadmap, we should have lightweight decentralized solutions that don't depend on full nodes for following of the beacon chain and fetching arbitrary state in the coming year. Solutions that allow for someone to build a full node that only depends on Portal protocols. We're working to pave the way for consensus clients to not need to run traditional execution clients and for execution clients to be able to follow the beacon chain without running a consensus client.

[q9f]

Does this privilege extend only to the solidity team or does it also include Vyper, Huff, Sway (when targeting EVM), Fe, LLVM to the extent it outputs EVM code, etc. et. al.?

If we were to kick out Solidity I would specifically make a case for that team given their history and knowledge.

However, if we want to find a generally applicable rule, I would include all compiler teams that maintain a target for the public Ethereum VM with their latest protocol specification, which would also include Vyper and others. I'm hesitant to open that up to all the very specific niche layer-2 languages though. In general, if you want to draw a line, I would exclude layer-2 protocols as they have usually their own incentive mechanisms.