Cumulus MultiBlock Prover

[MrishoLukamba]

Project Abstract

The Cumulus Prover project integrates a cryptographic proving system directly into Substrate parachain infrastructure by extending the Cumulus node architecture with execution proof generation and verification capabilities. Our system introduces a distributed proving mechanism where collator nodes generate partial proofs in parallel, significantly reducing computational overhead while maintaining cryptographic integrity. This architecture enables parachains to achieve higher transaction throughput through workload distribution and block distribution while preserving Polkadot's shared economic security model. The project delivers out-of-the-box support for cryptographic block validation, providing developers with a novel approach to parachain security that complements existing consensus mechanisms.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[MrishoLukamba]

I have read and hereby sign the Contributor License Agreement.

[MrishoLukamba]

@keeganquigley requesting your review

[PieWol]

Hey @MrishoLukamba ,
thanks for your application. Would you mind to clean up the application and remove the lines with instructions? Thanks! Somebody from the team will get back soon to you with additional feedback or comments.

[MrishoLukamba]

hello @takahser, any updates on projevcted starting date on reviewing the application
@PieWol @juntao

[MrishoLukamba]

Any updates @PieWol @takahser ?

[takahser]

@MrishoLukamba sry for the delay here, we have a bit of a backlog currently. I'll review by tomorrow EOD. Thanks for your patience!

[MrishoLukamba]

@MrishoLukamba sry for the delay here, we have a bit of a backlog currently. I'll review by tomorrow EOD. Thanks for your patience!

Any updates @takahser ?

[takahser]

@MrishoLukamba Apologies, I thought I replied already here. 😅

Generally, it looks interesting. Would you mind clarifying on the following points?

1. Ecosystem Demand / Fit

   • Can you provide concrete examples of parachain teams or use cases that would adopt a zk-proof based validation layer?
   • How do you see this complementing Polkadot’s existing shared security and para-validation model?

2. Technical Feasibility

   • Embedding the SP1 RISC-V zkVM into Cumulus sounds computational intense. Have you benchmarked its overhead on block production and validation?
   • Can you outline what proof format will be generated (e.g. size, verification cost, latency expectations)?
   • Will it be possible for para-validators tp verify proofs efficiently without significantly delaying inclusion?

3. Future Plans

   • You mention “realtime cryptographic proving on Polkadot SDK standalone chains.” Do you envision this becoming a maintained subsystem within Cumulus, or an optional add-on maintained by your team?

Despite of these questions, I think the application is structurally sound, so I'm going to open it up to other reviewers to avoid further delays.

[MrishoLukamba]

@MrishoLukamba Apologies, I thought I replied already here. 😅

Generally, it looks interesting. Would you mind clarifying on the following points?

1. Ecosystem Demand / Fit

   • Can you provide concrete examples of parachain teams or use cases that would adopt a zk-proof based validation layer?
   • How do you see this complementing Polkadot’s existing shared security and para-validation model?

2. Technical Feasibility

   • Embedding the SP1 RISC-V zkVM into Cumulus sounds computational intense. Have you benchmarked its overhead on block production and validation?
   • Can you outline what proof format will be generated (e.g. size, verification cost, latency expectations)?
   • Will it be possible for para-validators tp verify proofs efficiently without significantly delaying inclusion?

3. Future Plans

   • You mention “realtime cryptographic proving on Polkadot SDK standalone chains.” Do you envision this becoming a maintained subsystem within Cumulus, or an optional add-on maintained by your team?

Despite of these questions, I think the application is structurally sound, so I'm going to open it up to other reviewers to avoid further delays.

Apologies for taking 5 days to reply.

1. Ecosystem fit

• So parachain teams requiring a huge block size that can translate to high POV don't have to worry about it, as the para validators only deal with constant-sized proof and time verification. Teams like Hyperbridge are doing co-processing work for multiple chains.

• For fast chains which don't merklize their storage but want to unequivocally be secured by polkadot can prove their computation straightforward. (Solana like in polkadot),

• Tremendously reducing backing computation on para validators, which on async backing can reduce the backing and inclusion time of the para candidate.

With all this still the security comes from the polkadot relay chain but the securing mechanism doesnt restrict parachain teams on their computation and size of their exportation for verification.

And with the experimentation paradigm exploration on polkadot ecosystem, even setting up kusama as the zk playground this can speed up the experimentation on parachains.

2. Technical feasibility
   "Embedding ZkVM can be expensive", Actually the technical burden on this proposal is on changing and updaing existing cumulus modules as ZkVM is just a libary, the other part of technical is building a new shim for wasm with its executor along with host function to compile to Riscv format specificallt Sp1 RiscV variant.

But I have done a demo for this: https://github.com/MrishoLukamba/succinct-summer-2.5.

The proof formats can be 2, groth16 scheme and Stark, with groth16 is a constant size but for this grant will focus on STARK which scale logarithmically and its fast in verification speed.

And all of this done to make sure the size of POV which is the proof should be lesser than traditional merkle proof.

Future Plans

Realtime proving will be focused on standalone chains, but also mid plan is to even allow parachain to produce proof from ethereum based succinct network and be secured by polkadot relay chain.

But the current grant will focus on enabling N collators to split the workload and allow paralle proving.
and this will be a subsystem for cumulus maintained by the team. The staking rewards can be used to fund the ongoing maintaining.

@takahser

[MrishoLukamba]

@takahser any follow up question?

[MrishoLukamba]

@takahser any updates

[takahser]

@MrishoLukamba Thx for the detailed reply.

I have a few follow-up questions:

1. Ecosystem Fit / Demand

   • It would help to have actual examples of parachains currently struggling with large PoV sizes or async-backing constraints. Otherwise we risk creating solutions for problems that don't exist.

2. Benchmarks / Proof Characteristics

   • Could you provide some numbers from your demo project that compare the current system (PoV block with Merkle-based witness data) against your proposed zk-proof system? In particular:
     • Size of the data submitted (bytes).
     • Time and hardware needed to generate it.
     • Time required for a validator to verify it.
   • A simple comparison table like this would make the potential value of your solution much clearer.

3. Validator Impact

   • How do you expect verification to fit into the current backing/approval checking budgets?
   • Even if STARKs are fast, para-validators operate under tight constraints. Is it possible to show that inclusion latency won’t be negatively affected?

4. Downsizing the grant

   • Before the full distributed proving system, would you consider reducing this initial grant to an initial milestone that just demonstrates a zk proof replacing a PoV for a small parachain block, with logs/metrics on proof size and verification cost?
   • That would derisk the complexity and give reviewers confidence in feasibility before scaling to collator distribution and aggregation.

[MrishoLukamba]

@MrishoLukamba Thx for the detailed reply.

I have a few follow-up questions:

1. Ecosystem Fit / Demand

   • It would help to have actual examples of parachains currently struggling with large PoV sizes or async-backing constraints. Otherwise we risk creating solutions for problems that don't exist.

2. Benchmarks / Proof Characteristics

   • Could you provide some numbers from your demo project that compare the current system (PoV block with Merkle-based witness data) against your proposed zk-proof system? In particular:

     • Size of the data submitted (bytes).
     • Time and hardware needed to generate it.
     • Time required for a validator to verify it.

   • A simple comparison table like this would make the potential value of your solution much clearer.

3. Validator Impact

   • How do you expect verification to fit into the current backing/approval checking budgets?
   • Even if STARKs are fast, para-validators operate under tight constraints. Is it possible to show that inclusion latency won’t be negatively affected?

4. Downsizing the grant

   • Before the full distributed proving system, would you consider reducing this initial grant to an initial milestone that just demonstrates a zk proof replacing a PoV for a small parachain block, with logs/metrics on proof size and verification cost?
   • That would derisk the complexity and give reviewers confidence in feasibility before scaling to collator distribution and aggregation.

I am preparing all the metrics, and okey we can start with the first milestone

[semuelle]

I am preparing all the metrics, and okey we can start with the first milestone

Please change the application document to reflect this, @MrishoLukamba.

[MrishoLukamba]

I am preparing all the metrics, and okey we can start with the first milestone

Please change the application document to reflect this, @MrishoLukamba.

Yes Samuel, This week with all metrics, Apologies for delaying

[drskalman]

Thank you for submitting the proposal. It indeed seems interesting and I assume a parachain provable by ZK would become useful one way or another. So I'm generally happy with the concept, I just left some requests for few changes that I think are essential.

[drskalman]

I don't understand why you need to change the block header. This could be included as an extra transaction or as a header digest. I don't think you need to change the block header structure for this.

[drskalman]

You don't need to modify validate_block. It is just the runtime that you submit at the parachain registration is the proof validation function instead of the original non-zk runtime of the parachain. It is actually essential that the parachain works with the current relay chain without requiring any change to the relay chain.

[drskalman]

Could you submit some benchmark and estimation on how long it takse for the SP1 RISC-V zkVM to prove a typical block of a parachain?

[drskalman]

Could you point me out to any previous zk programming experience that team members had?

[MrishoLukamba]

Yes I will too, you can check also the demo I did in my application I have attached it

[diogo-w3f]

@MrishoLukamba please note that the grants guidelines have recently changed
. It would be helpful if you could provide information showing how your project fits what we’re looking for, and how it avoids the categories listed under What Doesn’t Fit Our Program.

[MrishoLukamba]

@MrishoLukamba please note that the grants guidelines have recently changed . It would be helpful if you could provide information showing how your project fits what we’re looking for, and how it avoids the categories listed under What Doesn’t Fit Our Program.

I am preparing the document for benchmarks and showing how polkadot validators can take up extra proof verifying task even for other network that requires a verifier. The computational cost for verifying is minimum while the users must pay in DOT.

While at the same time new parachain can opt into using proving system to achieve larger block size and validators perfoming less working in verifying the parachains blocks

Apologies for taking time