Season 5 Cycle 19 Intent 1 Developer Advisory Board finalists review

The developer advisory board reviewed all the applications elected by the Grants Council as finalists of Intent 1 mission requests.

You can find their advice on each application below:

Decentralized rollup-as-a-service

Application: CharmVerse - the all-in-one web3 space

  • Reviewer 1:

    • Does the proposed solution address the DMR? Yes, it covers everything discussed in the DMR plus a lot more.
    • Is it feasible? Yes. It’s a lot of work but each step is clear and feasible.
    • Any technical demerits? None.
    • Is this the right team? This seems to be the ideal team. They have done a lot of work in making complex tech easily usable, they’re shown a commitment and ability to accomplish work in the past, and they’re deeply engaged in the Optimism ecosystem.
    • Milestone feedback? The milestones are logically broken down and clear.
  • Reviewer 2:

    • Work review: Seems like a competent team with relevant work experience.
    • Proposed Solution: Absolutely addresses the DMR. Low technical risk here, lots of prior art for this kind of work and the solution proposed seems to follow it well. The marketplace seems as though it could be complex but could also be very cool. The milestones given are excellent and well paced. I am excited to see this come to fruition and approve and recommend this applicant.
  • Reviewer 3:

    • Does the proposed solution address the DMR? Yes, the proposed solution addresses the DMR.
    • Is it feasible? I believe the proposal is partially feasible. I feel that the most valuable part of this proposal is high-quality open source tooling for creating, operating, and upgrading an OP Stack chain without the need for a RaaS provider. Creating this tooling and making it amazing will set the foundation for a decentralized RaaS in the future. Additionally, there are technical limitations on the protocol that make a truly decentralized RaaS less feasible at the moment. By removing the marketplace aspect of this proposal and doubling down on the high-quality tooling, I believe this work would be much more successful long term.
    • Any technical demerits? Not strictly, see comment above.
    • Is this the right team? Unsure. I cannot find any evidence that this team has the understanding of the OP Stack or the experience with cloud infrastructure required to deliver this project. I also cannot find any clear evidence to the contrary.
    • Milestone feedback? See above comment about exploring a more limited proposal.

Research and development on multi-section dispute game

Application: CharmVerse - the all-in-one web3 space

  • Reviewer 1:

  • From a technical perspective, this proposed solution is feasible and addresses the DMR. However, I am concerned that this project would conflict with existing planned work for the fault proof. Other changes like updates to the fault proof required to support Superchain interoperability and support for multiple proof types likely take precedence over this work. Given the security-critical nature of this code path, the proposed changes would likely have to involve engineers from OP Labs whose time would probably consumed by other projects. It is possible that the fault proof protocol changes before this proposal can be accepted into the protocol.
    It is additionally worth noting that the underlying concern that the proposal is addressing has not been sufficiently analyzed. Although the proposal does increase the cost of censorship, the community currently lacks the research to demonstrate that the censorship risk posed by the current 40-transaction model is unacceptable for Stage 2.
    Given the above, I would recommend against carrying out this proposal not on technical merits but on strategic ones. I’m mostly worried that the team will spend time on this project and the end result will not be included in the final protocol. Instead, I would encourage the team to submit an alternative proposal that focuses on carrying out the underlying research to demonstrate the censorship risk relative to the number of transactions required as part of the game. Specifically, it would be valuable to understand the exact cost and feasibility of an attacker to execute a censorship attack as the number of transactions required as part of the proof increases.

  • Reviewer 2:

  • I am excited to see the proposal. I think that it would be high leverage to work on and it’s completion would really improve the efforts to decentralized the OP stack. The team is strong with a good track record and the proposal is well thought out. I think the collection of individuals who have a strong understanding of the dispute game and fault proofs is small and given me personal expertise i believe this applicant has a strong understanding. I think the requested amount is modest and more than reasonable. I believe that stage two decentralization for for the OP stack and that improvements to the dispute game (currently bisection) should be a priority and I endorse this proposal.

  • Reviewer 3:

  • I am a fan of any kind of meaningful performance improvement, especially if it’s an introduction of new algorithm for the dispute game. Very supportive. It definitely promotes the intent of technical decentralization.

Research on Alternative OP Stack Zero Knowledge Fraud-Proof using Wasm

Application: CharmVerse - the all-in-one web3 space

  • Reviewer 1

    • Does the proposed solution address the DMR? Yes. This moves the OP Stack towards one of its main goals of decentralized fault proving. One could argue that this is less of a research project as it has concrete produce outputs, but it probably fits best of any of the DMRs.
    • Is it feasible? Yes, although more research is needed to understand if their prover is fast enough to accomplish the goals.
    • Any technical demerits? No obvious ones other than the open question of whether their prover is fast enough to support this use case. While they do include some speedups regarding witness generation, it would be nice to see an estimated trace length for proving a block and some estimate of how long it would take to prove said trace based on smaller benchmarks.
    • Is this the right team? Yes. This team includes Delphius, who is working on SNARK provers which is the main relevant are of technical expertise required.
    • Milestone feedback? Looks good.
  • Reviewer 2

    • Does the proposed solution address the DMR?
    • Yes, it contributes to technical decentralization by adding another path by which to add redundancy to a critical part of the OP Stack: the fault proof.
    • Is it feasible?
    • Yes. The core components for this task seem to be present: an op-node implementation in Go, a Go compiler target of WASM, a way to create zk proofs for WASM execution via zkWASM
    • Any technical demerits?
    • Not really, although whether zkWASM’s proving and verification is performant enough to be able to run the client is a concern.
    • Is this the right team?
    • Yes, DelphinusLab specifically seems experienced in this area, although I had trouble verifying that the applicant is directly tied to the org. I mainly searched through contributors on the linked repository and didn’t find anyone directly linked with the name.
    • Milestone feedback?
    • Milestones are good but potentially not very granular.
  • Reviewer 3: Usually I am skeptical of “wasmify everything” movement, do not have strong opinion on benefit of proposed solution. Keen to hear the feedback of other DAB members.

Lightweight Open Source Explorer for the Superchain

Application: CharmVerse - the all-in-one web3 space

  • Reviewer 1:

    • Does the proposed solution address the DMR? Yes. While I think it’s unlikely to be used by too many users on established chains, it seems like a very useful piece of developer tooling for the ecosystem to have. Having audited Blast on a local devnet, it would have been a much smoother experience to have a tool like this.
    • Is it feasible? Yes, absolutely.
    • Any technical demerits? No.
    • Is this the right team? Yes. This project requires a mix of EVM knowledge and front end skills. Their other projects demonstrate deep abilities on both of these skillsets.
    • Milestone feedback? Milestones are clearly laid out with tangible outcomes. All look good to me.
  • Reviewer 2:

    • I believe that this proposal could certainly be constructive to the ecosystem at large, as chain visibility is high leverage. However i do not believe that this is a particular novel proposal but non the less diversity and competition in explorers is good and worth supporting in my opinion. I think that the requested amount here is less modest proportional to the impact (if i had to balance the amounts i would switch the allocation amounts with this and the multi-section dispute). All in all i also endorse this Proposal.
  • Reviewer 3:

    • Work review: Solid prior work on StarkNet explorer (but not public yet it seems). Team has delivered projects in the past.
    • Proposed Solution: Yes it addresses the DMR. I think as superchain vision is realized there will be way more OP Stack L2s that won’t receive support from Etherscan and can’t pay for an integration. And blockscout is generally too much of a departure from normal user flows and that degrades the UX. So going with a Etherscan style UI is great. The team should checkout Otterscan. Tying together the superchain on top of a familiar UX is great.
    • Milestones could be better by adding expected time frames (work weeks/dates).

PermaDA: Utilizing Arweave as a low-cost permanent data availability solution

Application: CharmVerse - the all-in-one web3 space

  • Reviewer 1:

    • Does the proposed solution address the DMR? Yes, the application suggests open sourcing an application to easily integrate Arweave as a DA for OP Stack chains, which could certainly help OP Stack devs.
    • Is it feasible? As far as I can tell, the approach is feasible.
    • Any technical demerits? The explanation of the discrete steps seems a little vague. The broad strokes make sense, but seems like they have not yet thought too much about the exact details or precise work that will go into it.
    • Is this the right team? They certainly seem to have knowledge of Arweave, and they have released 4EVER-Raas based on OP stack, but something in the write up makes me feel a bit iffy about whether they will succeed at this.
    • Milestone feedback? The milestones are ok but dates are off (some are in the past) and descriptions are not that detailed. It’s all fine, just feels a little sloppy.
  • Reviewer 2:

    • Does the proposed solution address the DMR? Mostly. One could argue that this isn’t tooling and is instead infrastructure, but I think it aligns closely enough and is worthwhile enough project to include.
    • Is it feasible? Yes.
    • Any technical demerits? Not really. The only additional feature that may be worth adding is some tooling for verifying the correctness of a blob against an Ethereum node. This should be feasible as one can take the stored data, compute the KZG commitment, and check that it is equal to the commitment stored permanently by Ethereum.
    • Is this the right team? Yes. They have relevant experience.
    • Milestone feedback? Looks ok.
  • Reviewer 3:

    • Does the proposed solution address the DMR?
    • Yes. It contributes to technical decentralization providing an avenue by how Optimism might become more independent from Ethereum should it need to.
    • Is it feasible?
    • Yes. DA is about making data available and Arweave’s stated purpose is to store data although I have doubts I will expand in the technical demerits.
    • Any technical demerits?
    • Optimism seems quite set on being Ethereum aligned. Politics aside using a separate chain whether Arweave or othwerwise may worsen Optimism’s technical decentralization and security by potentially making it reliant on a cheaper but less secure & decentralized DA layer. Furthermore the proposal doesn’t mention a light-client or bridge of any sort that would be required to make proofs that data was made available on Arweave in Ethereum for the sake of fault proofs and disputing sequencers.
    • Is this the right team?
    • Yes. They’ve built heavily with Arweave in the past.
    • Milestone feedback?
    • Besides the missing light-client / data-bridge piece mentioned in the demerits the milestones seem well rounded to complete the project.

@brockelmore Thank you for your insightful comments regarding Research and development on multi-section dispute game .
First, we would like to clarify our position regarding the perceived conflict between the proposed multi-section fault-proof work and the existing bisect fault proof. Our perspective is that the proposed multi-section fault proof not only complements but significantly extends the current bisect game by maximally leveraging the existing work including

We are confident that these integrations will not only preserve the essence of the current fault-proof efforts but will substantially extend their capabilities and effectiveness.

Second, many thanks for pointing out the censorship attack analysis. The analysis is a very important part of the fault-proof system, and there are a couple of excellent analyses to start with:

We propose that the analytical assessment of censorship attacks could proceed concurrently with our initiative, which seeks to reduce the 40 transactions of the current bisect dispute game to 4-5 transactions. This efficiency is achieved through the adoption of cost-effective EIP-4844 BLOBs that carry the counter-sub-claim hashes of multi-section dispute game. In line with this, we are prepared to draft an additional proposal that specifically addresses the examination of censorship costs and complexities in the context of a reduced number of challenge-response interactions facilitated by EIP-4844 BLOBs.

Dear developer advisory board, thanks a lot for your feedback and advice on our proposal! Decentralized rollup-as-a-service

@brockelmore About the suggestion to double down on high-quality tooling, we agree it’s a sensible direction. The decentralized marketplace smart contracts and dapp could be good features to add to a V2 of the project, while focusing on the high quality is a must for our deliverable version.

To address this, we propose to use the first project’s milestone, “Research & Discovery”, to delve deeper and present 2 possible development roadmaps:

  1. One with the original milestones
  2. An alternative roadmap doubling down on the high-quality tooling and removing the marketplace milestones.

We would like to present them to the developer advisory board and decide together on which path to take for the rest of the project.

Regarding the comment about the team, with almost 20 years of software development experience and a dedicated focus on web3 technologies for the past 6 years, we possess deep understanding and expertise in various technologies, including cloud infrastructure, blockchain tech, and general software development. Having closely collaborated with the Optimism ecosystem, we’re committed to leveraging our experience to meet the project’s objectives. We really look forward to initiating this project.

Looking forward to your comments and/or suggestions.

1 Like