[READY TO VOTE] Alternative CL/EL Client Mission Request

🏹 Mission Requests
, ,
1

Delegate Mission Request Summary: Implement new OP Stack CL/EL clients to make OP Stack chains decentralized and help to build a multiproof ecosystem.

S5 Intent Please list the Intent your Request aligns with here: Intent 1

Proposing Delegate: PGov

Proposal Tier: Ember

Baseline grant amount: 100,000 OP

Should this Foundation Mission be fulfilled by one or multiple applicants: Multiple

Submit by: To be set by Grants Council

Selection by: To be set by Grants Council

Start date: If applicable

Completion date: If applicable. Please note Missions must be completed within 12 months (i.e. marked as done).

Specification

How will this Delegate Mission Request help accomplish the above Intent?
OP Stack is far ahead of other Rollups in terms of client diversity. There are currently three CL clients: op-node (OP Labs), magi (a16z), hildr (OptimismJ) and four EL clients: op-geth (OP Labs), op-erigon (TIP), op-reth (multiple teams), op-nethermind (nethermind). The next key step towards stage2 rollup is the multiproof system. It is hoped that a variety of fault proof programs can run in a variety of FPVMs. However, currently only Rust and Go have both CL and EL implementations, which can be used to build fault proof programs. By adding more client implementations, we can build more fault proof programs in Java, C++, etc., and enrich the multiproof ecosystem.

What is required to execute this Delegate Mission Request?

  • Open source code repository and developer documentation
  • Node operator running documentation

How should the Token House measure progress towards this Mission?

  • Measure the quality of the code and document.
  • Measure the node can actually run OP Stack chains such as OP Seoplia testnet, OP mainnet, Base Seoplia testnet, Base mainnet, etc.

How should badgeholders measure impact upon completion of this Mission?

  • Measure the functionality and effectiveness of the open source codebase.
  • Gather feedback from badgeholders, the community and the core developers on the implementation.

Have you engaged a Grant-as-a-service provider for this Mission Request? No.

Has anyone other than the Proposing Delegate contributed to this Mission Request? Yes. @Grapebaba who is the author of hildr client participate in drafting this proposal.

18 Likes
2

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes
3

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes
4

as a top 100 delegate I believe this proposal is ready for vote. Delegate Commitments - #71 by MoneyManDoug

2 Likes
5

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

2 Likes
6

Nice one - this is an obvious thing to support.

2 Likes
7

I like this one a lot!

But got a question. Is 100k OP supposed to fund the creation of a team to develop and maintain a new CL/EL client?

Isn’t that a little bit low?

2 Likes
8

It’s actually meant to be 100 K OP for multiple applicants.

It does feels low. Delegates still can agree to change the amount in the following week.

RPGF4 could be an additional source of funding for the applicants. I think it would be liquid earlier too.

Worst case, there are no applicants and that would be a signal. But I think the redundancy of funding mechanism can encourage applicants in any case.

3 Likes
9

Thank you @lefterisjp @Cotabe , my initial suggestion is 50,000 OP for each client, and accept multiple team applications at the same time. Currently, it is actually assumed that there are up to 2 teams, and the amount can be increased if more are accepted. From magi and hildr’s experience, while assuming a 50/50 (Collective/RetroPGF) ratio, it should be enough to cover the cost from 0 to 1 of building a new OP Stack client.

However, continuous maintenance of the client following the upgrade of OP labs (such as Canyon, Delta, Ecotone, etc.) may be a problem. After all, we want all clients to be available all the time. So can we create a dedicated Consensus Layer/Execution Layer Mission Request like the Ethereum Foundation does in each cycle to support client team maintenance development work? Hope to hear everyone’s thoughts.

4 Likes
10

So at the moment creating new mission requests is not possible. Only editing existing ones.

I would like to support this and make it pass but I think we need to adjust the funding required. Otherwise I don’t think people will pick it up.

1 Like
11

Sure, as the optimism Delta and Ecotone hardfork will upgrade soon, the new client need implement more features, it is reasonable to adjust the grant size.

12

Still in support of this one but i think we need some more impact measurements. Stuff like use, contributions, ethings like that

13

I agree that the amount is too low for creating an entirely new EL client.

I think a more productive MR might be to take an existing maintained EL client that does not yet have an op sibling (e.g. Besu) and have it be converted so that it can be used for OP. This is not only a smaller lift than building a new client from 0 to 1 but has similar benefits and I believe could be accomplished with the suggested budget.

14

Since the missing request also support CL client which should code from scratch and we assume that developers should know that EL general just a fork from any ethereum EL for OP stack. Maybe not a big problem for missing request description. :grinning: In additional the work to convert an exist client to support OP stack which is also not too easy :stuck_out_tongue:

15

@PGov @lefterisjp @Cotabe @jackanorak @philogy Noticed this MR is ready to submit proposals, is it too late to modify the baseline grant size which already limit in proposal template and impact measurements?

1 Like
16

it’s definitely doable - up to @PGov to do it and would need all approvals i believe

1 Like
17

Yes, you can modify it, but all approvals will need to be reconfirmed. Additionally, as a Mission Request under Intent #1, it will require approval from the Developer Advisory Board.

18

I have chatted with @PGov and are interesting in possibly changing it.

19

The Grants Council has opened early submissions as an Indication of Interest for this mission request here

For your application to be considered, the Mission request must pass the Token House vote on February 14th. Early submissions will not be considered if a Mission Request is not approved on the 14th.

20

I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.

1 Like