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