Feedback on EIP4844 contributors Collection

đź”´ RetroPGF
1

Hello, I was recently directed to the following page Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. with a list of EIP4844 contributors which presumably will get a reward in OP for their work on EIP4844.

I am very pleased that successful projects like Optimism are funding public goods and in particular core development. Not only with monetary funding but also with their own time and man-hours in research and implementation. I am also glad to be personally considered for this funding even if my participation in EIP4844 has been infinitesimal at most. I wish other projects, in particular those with their own tokens, do allocate a percentage of their token to fund core development and public goods in general.

However, I believe that in this particular instance the approach taken by Optimism is not right for several reasons. Most, if not all of the people in that list, are core developers that already belong to a collective that is self curated and that distributes funding towards them, this is the Protocol Guild. I believe this is the right place to allocate funding for core development.

Although it is understandable that Optimism may want to have a finer decision on how their funds are allocated among members, in this particular instance of a feature that has not even been shipped to Ethereum mainnet and whose date hasn’t even been set on public testnets, I believe that this hurts Ethereum governance credibility of neutrality.

It also may have impact among core dev teams themselves: should I be careful in the future deciding in which subprojects do I work within Prysm to expect a higher payout if I work on projects that are of interest to Optimism? (noting that this project in particular is of high interest to Prysm’s mother company). Should I neglect forkchoice and allocate more of my time to EIP4844?

On the other side of the same coin, the list itself fails to recognize participation of many people that do contribute under the hood. How about the devops on each team that helped setup and run special CI flows for the respective EIP4844 branches? How about project managers that are involved in facilitating some of these coredevs to take time from other resources to work on EIP4844? I don’t want to claim that I have any right to decide how Optimism allocates their funds, just noticing that the protocol guild has already gone through these questions in detail, in an ample forum of coredevs and has instructed guides on who and how much should be distributed from the funds it obtains, and often times, in order to see a feature live on mainnet, there are many more working directly and indirectly (even facilitating those that work directly) than those that receive credit for it. I also don’t want to take credit off the people in that list: I have personally seen the work and the countless hours that some of my colleagues are putting into this, they are true champions.

Having said so, and again repeating that I am very glad and honoured to be considered and quite happy to see such an influential project donating funds towards core development, I kindly request my name to be taken off that list.

5 Likes
2

I agree completely. To be frank I see some people from Nethermind missing from that list. While they weren’t particularly involved in 4844 community calls they were involved in Nethermind networking and tx pool 4844 integrations and very detailed code review of whole 4844 changes. Not sure how the list was compiled, but it is not complete even on it’s own terms.

That being said, core devs focusing on withdrawals or other general improvements are not less aligned with 4844 and making it happen on mainnet and excluding them is an unfair treatment. And we have already a mechanism to include them through Protocol Guild.

4 Likes
3

I’ll echo the sentiment. I think doing RPGF in this granular of a form incentivizes doing more visible and “popular” work in a degenerate way. Everyone on the Prysm team is working on keeping the lights on, and if Prysm doesn’t keep the lights on, no upgrades happen.

Similarly, some work is very high-profile by the nature of the role. Such work can certainly be instrumental in shipping an upgrade, but so is lower-profile work. For example, timelines would easily slip by 6 months if devops folks weren’t around.

Trying to capture the granularity of who and how an upgrade was shipped will create view-biased asymmetries and create perverse incentives around how people choose to structure their work in the future.

4 Likes
4

Thanks for the Feedback @potuz!

This nomination for EIP-4844 contributors is for Retroactive Public Goods Funding Round 2, where Badgeholders will decide how much funding to allocate to it. Protocol Guild and a lot of client teams are also nominated.

We only stepped in here because no one else nominated EIP-4844 contributions and we felt like it was important work that should be on the ballot.
Initially we thought about nominating all the contributors on the list as individuals, but were afraid that asking Badgeholders (voters in RetroPGF2) to understand the granularity of each contribution would be a lot to ask. This is why we decided to put it out as a collection.

While this collection was created by Protolambda, Liam and others from the OP Labs team, who were deeply involved in EIP-4844 work, I don’t think anyone is claiming this collection is a perfect reflection of contributions.
But I personally think it’s better to have a decent collection of contributors that is nominated rather than no nomination at all.

One possible solution for the future could be that anyone can create such a collection and different collections can reflect different views of understanding of the contributions.
E.g. if you don’t agree with this collection you could come along and create your own EIP-4844 collection that reflects your best understanding of the contributions.

Curious to hear your thoughts on how we might solve this in the future!
I think we can’t ask Badgeholders to have the best understanding of how 100+ different people contributed to particular work. There needs to be some way for Badgeholders to outsource this curation to others. This could be self-curation (e.g. Protocol Guild) or curation by third parties (what we tried to do here). Open to any ideas on this!

1 Like
5

In regard to your concerns about allocating all or most of the funds to a certain group of developers, I might say that you are quite right. It has to be fair. I am definitely a new account here, but I think your argument is logical and your concern has to be taken into consideration. Of course, the fund does not solely belong to the Optimism Collective, and all the Delegates have to decide on it that how to spend the fund.
However, the project itself might be highly beneficial for the whole system and help all of the members in Delegation. Thanks for your post.

1 Like
6

OP RPGF is an incredibly important experiment, one worth pursuing. I applaud the efforts to build this norm, and hope other L2s will start to follow the OP community’s lead! Funding our commons is a challenge we’ll have as long as we have an ecosystem worth stewarding.

I also appreciate the intentions behind the OP Labs EIP-4844 curated list. However, feature-specific funding in the RPGF context has challenges which may not be immediately apparent. Other commenters have touched on them above, which I will try to constructively summarize and respond to below.

1. Curation is hard

  • Effectively surfacing the people who’ve done the work requires intimate domain knowledge. Even though OP Labs was deeply involved with 4844, the final list still missed some people who should have been included.
  • Even in the case of a perfect curation, snapshots quickly lose their accuracy as people join/leave the project. Is OP Labs committing to updating this in perpetuity for each successive round? This entails a fair bit of overhead in curating, filtering, and weighting contributors.
  • At a certain point, the implementation work will stop and 4844 will go live on mainnet. Will this list or some future list receive ongoing retro funding?
  • Of course, better curation is possible. Ultimately, taking on the curatorial role puts the onus of inclusion/omission/eligibility/weighting on OP Labs. This is a weighty responsibility with parallels to VB’s idea of “control as liability” - let’s call it “curation as liability”.

2. Implementation is not stewardship

  • The part is not the whole, the feature is not the protocol.
  • Those involved in researching/implementing a particular feature may not be the people stewarding the client code in 5-10 years. And yet, these future stewards will still be responsible for any introduced complexity or inadvertent tech debt. Long-term maintenance should be a core consideration in commons funding, which is not necessarily covered by this curated list.

3. Funding features skews incentives

  • Funding features incentivizes such work at the expense of other equally important features or long-term maintenance of existing features. There is no one piece of the protocol that is more important than another. This pluralist frame has deep cultural roots, seen in our shared obsession with a robust multi-client ecosystem.
  • Core protocol credible neutrality is one of Ethereum’s most important characteristics. This includes both the protocol’s current state (eg. producing blockspace, settling transactions) and the processes by which it evolves. Feature funding adds a thumb to the scale.
  • While the OP Labs decision to fund 4844 contributors may appear directionally reasonable (ie. scaling the chain benefits all users, 4844 benefits all L2s not just Optimism), the Ethereum community should firmly avoid establishing this as a norm. Best case, it introduces strange dynamics into client teams through perks to working on certain parts of the codebase. Worst case, it devolves long-term into “pay to play” funding where client teams name their price for feature inclusion.

Potuz and Jonas mentioned the Protocol Guild above as a potential alternative. And, while it’s still very early days, and there is a lot to improve on, I think the Guild has demonstrated compelling potential. Here’s how its design addresses the challenges listed above.

1. Self curation is neutral consensus

  • Protocol Guild maintains its own membership. As a result, any funder sidesteps the “control as liability” incurred when creating their own list. The successes and failures of curation are assumed by the peer group which maintains the beneficiary set.
  • Bonus: The Guild also handles weighting, abdicating the responsibility to a sufficiently fair time-weighting.

2. Stewardship happens over time

  • The Protocol Guild collective attests to the accuracy of the current membership, and develops stronger guarantees over time to potential funders: curation will continue as long as the mechanism is useful.
  • Vesting of allocated funding adds to this future guarantee.

3. Fund the protocol, not its features

  • Guild eligibility aims to be sufficiently broad, but not more.
  • There is no membership distinction between new features added to and ongoing maintenance of the core protocol. Both of these are crucial for the next decade of Ethereum.
  • This includes client teams, researchers, coordination, security, devops, testnets, and testing: everything needed to continue evolving the core protocol.

A combination of the challenges listed above and my strong conviction that Protocol Guild is the best-fit tool, I will be forwarding any possible RPGF allocation I receive from the 4844 Collection to the Protocol Guild.

As an addendum: here’s a list of similar curation efforts I was part of in the past which have had a strong influence on the design of the Guild.

Open Grants (2019-ongoing)

  • Open Grants was conceived and funded by James Fickel, and seeded by a 4k ETH vesting stream intended to go to “eth 2”. I was involved with curation and diligence for each update.
  • Pros: Focuses on a broader category instead of a narrow feature
  • Cons: Funder which can claw back funding at any time, an unclear weighting and curation methodology, and infrequent updates. “eth2” is not really a meaningful category today - what about the other 120 people stewarding the chain?

Beacon Book (2021)

  • I created the Beacon Book, which fed ETH generated by a physical book & NFT project to a set of Beacon Chain contributors.
  • Pros: Immutable ETH distribution
  • Cons: Concerned with a specific feature, not its ongoing maintenance. Immutable contract can’t update beneficiary list

1559 NFTs (2021)

  • Tim Beiko, Kitteh and myself worked on the 1559 NFT Series, which recognized the work of EIP-1559 contributors
  • Pros: Immutable ETH distribution
  • Cons: Concerned with a specific feature, not its ongoing maintenance. Immutable contract can’t update beneficiary list

These experiences ultimately culminated with the Protocol Guild, launched on mainnet in May 2022. To date, the entire $10mm Pilot has been directed to this list of members, in addition to ETH raised by projects like the When Merge NFTs and New Home of the Heart Merge benefit exhibition.

2 Likes