Skip to content

feat: Move block proving to the Store#1579

Merged
sergerad merged 38 commits intonextfrom
sergerad-store-block-prove
Feb 1, 2026
Merged

feat: Move block proving to the Store#1579
sergerad merged 38 commits intonextfrom
sergerad-store-block-prove

Conversation

@sergerad
Copy link
Collaborator

@sergerad sergerad commented Jan 22, 2026

Context

The state transitions of blocks have changed such that signed (instead of proven) blocks are applied to Store state, leaving block proving to be done asynchronously some time after. The block proving logic is being moved out of the Block Producer so the the Store can managed asynchronous proving after signed blocks are committed to its state.

NOTE: Block proofs are not used in the PR. Follow-up work will be done to make proving deferred/asynchronous to the rest of the Store's apply_block() flow.

Relates to #1316.

Changes

  • Remove block prover client and block proving from the block producer.
  • Add block prover client and block proving to the Store.
  • Update the Store's ApplyBlock RPC endpoint to take data required to perform proving.
  • Add signature column to block_header table.

@sergerad sergerad changed the title Add initial implementation from previous PR feat: Move block proving to the Store Jan 22, 2026
@sergerad sergerad marked this pull request as ready for review January 27, 2026 01:11
@sergerad sergerad requested review from Mirko-von-Leipzig, bobbinth and drahnr and removed request for Mirko-von-Leipzig and bobbinth January 27, 2026 01:11
Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you! I left some comments inline. As I mentioned in some of the comments, it may make sense to do a couple of "preparatory" PRs first and then rebase this PR on top of them. These would be:

  • A PR in miden-base to add SignedBlock.
  • A PR here to move apply_block() into a separate file.

use miden_protocol::batch::OrderedBatches;
use miden_protocol::block::{BlockHeader, BlockInputs, BlockProof};
use miden_remote_prover_client::RemoteProverClientError;
use miden_remote_prover_client::remote_prover::block_prover::RemoteBlockProver;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit (and not for this PR): the namespacing here feels a bit "too nested" - e.g., could this not be just miden_remote_prover_client::block_prover::RemoteBlockProver?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea because we are doing pub mod block_prover; instead of pub use block_prover::BlockProver in miden_remote_prover_client. I can make a PR for that after this one.

@sergerad
Copy link
Collaborator Author

it may make sense to do a couple of "preparatory" PRs first and then rebase this PR on top of them. These would be:

  • A PR in miden-base to add SignedBlock.

Bringing in SignedBlock is blocked while the node next branch is out of date with base next branch

@bobbinth
Copy link
Contributor

Bringing in SignedBlock is blocked while the node next branch is out of date with base next branch

Should be already up to date - no? (#1595 got merged a few hours ago).

@sergerad sergerad requested a review from bobbinth January 28, 2026 01:27
Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thank you! I left few comments inline and some suggestions for future improvements.

let header = signed_block.header();
let body = signed_block.body();

// Validate that header and body match.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably validate that the signature is valid since, theoretically, the store could receive a block with an invalid signature.

Not for this PR, but we could do this as a method on SignedBlock (in miden-base) - something like:

impl SignedBlock {
    pub fn validate_signature(&self) -> Result<(), SomeError> {
        ...
    }
}

We could also do this at SignedBlock construction time - but not sure that's much better.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0xMiden/protocol#2382

Was thinking we could put it in the non-unchecked constructor and use it a bit earlier in the flow (before apply_block() is called here).

Anything else we would want to check in that constructor (the error enum is overkill if there is nothing else). If there is a fair bit of other stuff to check (compare header/body) then might be worth adding the validate_signature() fn rather than doing unnecessary checks in this stack for example.

Comment on lines 51 to 58
let tx_commitment = body.transactions().commitment();
if header.tx_commitment() != tx_commitment {
return Err(InvalidBlockError::InvalidBlockTxCommitment {
expected: tx_commitment,
actual: header.tx_commitment(),
}
.into());
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related to the above comment, we could probably move this into SignedBlock as well - e.g., SignedBlock::validate_transaction_commitment(). Or this could also be done at construction time.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added to constructor in base PR (above comment)

Comment on lines 69 to 79
@@ -78,20 +78,19 @@
return Err(InvalidBlockError::NewBlockInvalidPrevCommitment.into());
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Along the same lines as the previous two comments: this could probably be moved into something like SignedBlock::validate_parent().

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added in same PR as above comments

@bobbinth
Copy link
Contributor

One other thing we should do once the structure is closer to its final shape is update the docs (and related diagrams) with the up-to-date explanation of the node's architecture. @sergerad - could you create an issue for this?

@sergerad sergerad merged commit 1c44ed2 into next Feb 1, 2026
7 checks passed
@sergerad sergerad deleted the sergerad-store-block-prove branch February 1, 2026 22:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants