feat(rpc): expose protocol config over the gRPC APIs by kkovaacs · Pull Request #2596 · 0xMiden/node

kkovaacs · 2026-09-09T10:09:57Z

Summary

Add protocol configs to GetBlockHeaderByNumber, SyncChainMmr, and public/validator block subscriptions.
Verify config commitments and propagate configs through signing, replication, and recovery.
Use verified RPC configs in NTX execution, the network monitor, and benchmarks; remove --fee-faucet-id options.

Changelog

[[entry]]
scope       = "rpc"
impact      = "breaking"
description = "Expose protocol configurations through gRPC and use verified configs across synchronization, recovery, NTX execution, monitoring."

_{Stack created with GitHub Stacks CLI • Give Feedback 💬}

Mirko-von-Leipzig

Only a partial review

Mirko-von-Leipzig · 2026-09-10T13:24:38Z

+            let (start, _) = view
+                .get_block_header(Some(current_client_block_height), false)
+                .await
+                .map_err(super::get_block_header_error_to_status)?;
+            let start =
+                start.ok_or_else(|| Status::internal("starting block header is missing"))?;
+            start.protocol_config_commitment() != block_header.protocol_config_commitment()


We could optimise this if we also store the block at which a protocol config changes with the protocol config data?

How would that help us? I mean, that'd still mean that you'd need to make a DB query that checks is there were changes in the (start, tip) range?

Yes but you wouldn't have to fetch and decode the entire header and calculate the commitment.

Oh, it's not actually calculating anything (the protocol config commitment is a field in the header). You have to decode that though, but that should be fairly cheap?

I think this just seemed easier to do just this range search:

super::load_protocol_config(&view, current_client_block_height..=block_header.range).await

Mirko-von-Leipzig · 2026-09-10T13:27:53Z

I suggested adding a block number tracking here as well; but that means changing PK to composite (or to block number).

If if not strictly required, I think it would be useful to have the block number in this table - would allow us to easily inspect all protocol configurations as they evolve over time. I'm assuming that adding this field is very easy - if not, then we can come back to it later.

Mirko-von-Leipzig · 2026-09-10T14:01:26Z

+        let commitment = header.protocol_config_commitment();
+        if let Some(config) = protocol_config.as_ref() {
+            let calculated = config.to_commitment();
+            if calculated != commitment {
+                return Err(crate::errors::DatabaseError::ProtocolConfigCommitmentMismatch {
+                    expected: commitment,
+                    calculated,
+                }
+                .into());
+            }
+        }
+        let stored = self.db.select_protocol_config_by_commitment(commitment).await?;
+        if stored.is_none() && protocol_config.is_none() {
+            return Err(crate::errors::DatabaseError::ProtocolConfigNotFound(commitment).into());
+        }
+        let new_protocol_config = if stored.is_none() { protocol_config } else { None };


Took me a while to understand why this looked more complicated, but I think its because we avoid re-storing a config if we already have it. e.g. A, B then A again, the last A doesn't get stored.

I don't think that's really worth optimising for, we can just insert or ignore, or if we go with my suggestion to also add the block number, then we have to insert regardless.

I'd like to avoid adding the block number unless there's a really good reason to do so, so we should maybe just do an "insert or ignore" here?

One downside is that if we just "insert or ignore" then we don't actually ensure that the commitment in the block header that's being applied is present (is either already in the DB or being added just now).

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

…the commitment changed

bobbinth

Looks good! Thank you! This is not an exhaustive review - I largely skipped big parts of the NTX builder and the monitor changes, and focused primarily on the non-test code. I left some comments inline - the main one is about using BlockProofRequest message for validators - but maybe I just misunderstood something there.

bobbinth · 2026-09-12T09:23:26Z

    pub async fn sign_block(
        &self,
        proposed_block: &ProposedBlock,
        block_inputs: &BlockInputs,
+        protocol_config: &ProtocolConfig,
    ) -> Result<Vec<SignBlockResponse>, ValidatorError> {
        let message = proto::block_proving::BlockProofRequest {
+            protocol_config: Some(protocol_config.into()),
            batches: proposed_block.batches().as_slice().iter().map(Into::into).collect(),
            block_inputs: Some(block_inputs.into()),
            timestamp: proposed_block.timestamp(),
            next_validator_config: Some(proposed_block.next_validator_config().into()),
            next_protocol_config: proposed_block.next_protocol_config().map(Into::into),
        };


Not from this PR, but why are we sending BlockProofRequest to the validators? Is it just for convenience because BlockProofRequest message and the message we want to send to the validator have the same "shape"? If so, I'd consider still using two different messages because maybe they'll evolve in different was in the future (could be done in a different PR).

bobbinth · 2026-09-12T09:27:27Z

+  // The active configuration for signing. May be omitted if the validator already stores it.
+  // Proving-only callers may omit this field.
+  optional protocol_config.ProtocolConfig protocol_config = 6;


Probably related to the above comment: I didn't fully understand the purpose of this field - is this something like:

When BlockProofRequest is sent to a prover, we don't need this field.

When BlockProofRequest is sent to a validator and the validator already has the config, we don't need it.

When BlockProofRequest is sent to a validator, and if the validator doesn't already have this config, we do need it.

I guess the question is: how do we know if the validator has or doesn't have the config?

bobbinth · 2026-09-12T09:29:38Z

+    /// Supply the active configuration if its commitment is not yet stored. The configuration
+    /// must match the block header. New configurations are committed with the block.


This will also error-out if protocol_config is not provided and we can't find the config corresponding to the signed_block in the database, right? If so, I'd mention it.

kkovaacs added this pull request to stack #2581 September 9, 2026 10:09

kkovaacs requested a review from Mirko-von-Leipzig September 9, 2026 10:10

Mirko-von-Leipzig reviewed Sep 9, 2026

View reviewed changes

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from 3a0711e to e532549 Compare September 10, 2026 08:58

kkovaacs force-pushed the krisztian/grpc-protocol-config branch 2 times, most recently from 1eb94a1 to d19628c Compare September 10, 2026 09:21

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from d19628c to ddab236 Compare September 10, 2026 09:54

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from ddab236 to 4bdd1b5 Compare September 10, 2026 12:18

Mirko-von-Leipzig requested a review from SantiagoPittella September 10, 2026 13:18

Mirko-von-Leipzig reviewed Sep 10, 2026

View reviewed changes

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from 3851287 to fc34817 Compare September 11, 2026 08:52

kkovaacs force-pushed the krisztian/grpc-protocol-config branch 2 times, most recently from b302641 to fc34817 Compare September 11, 2026 10:45

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from fc34817 to fe71f00 Compare September 11, 2026 11:13

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from fe71f00 to ea9a8e9 Compare September 11, 2026 11:29

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from ea9a8e9 to d42a4d5 Compare September 11, 2026 11:35

Base automatically changed from krisztian/store-protocol-config to next September 11, 2026 11:42

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from d42a4d5 to c8806dd Compare September 11, 2026 11:43

kkovaacs and others added 2 commits September 11, 2026 13:43

feat(rpc): expose protocol config over the gRPC APIs

e8c6e6f

Update proto/proto/rpc.proto

a6e4330

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

kkovaacs and others added 16 commits September 11, 2026 13:43

Update proto/proto/rpc.proto

66dd34e

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

Update proto/proto/rpc.proto

b10d799

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

Update proto/proto/types/block_proving.proto

6f42953

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

Update proto/proto/internal/validator.proto

8c74349

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

fix: compile after rebase

21e93bb

fix(network-monitor): simplify deployment fee checks

4159caf

test(network-monitor): remove obsolete probe startup test

56c5460

refactor(validator): hoist protocol config persistence checks

b778d9f

refactor(store): validate protocol configs in the block writer

1fe9eeb

fix(validator): migrate protocol config storage separately

f4a201c

fix(db): implement FromSqlValue and ToSqlValue for ProtocolConfig

914b4e8

fix: remove bogus test

3bc0bcc

fix: remove more tests

f108bf0

fix: rename to config_required

aeacafb

refactor: apply block tests

b4252c7

fix: compile after rebase

3851775

SantiagoPittella reviewed Sep 11, 2026

View reviewed changes

Comment thread bin/validator/src/db/queries/protocol_config/mod.rs Outdated

fix(db): protocol config is not verified when loading from db

090ceb0

kkovaacs force-pushed the krisztian/grpc-protocol-config branch from c8806dd to 090ceb0 Compare September 11, 2026 12:51

refactor(validator/block_subscription): load protocol config only if …

9b20862

…the commitment changed

Mirko-von-Leipzig approved these changes Sep 11, 2026

View reviewed changes

Mirko-von-Leipzig mentioned this pull request Sep 12, 2026

feat: store and verify genesis protocol configuration #2590

Merged

bobbinth approved these changes Sep 12, 2026

View reviewed changes

kkovaacs added 4 commits September 13, 2026 11:14

refactor(store): add activation block number for protocol configs

9f3c57e

refactor: rename decode_protocol_config

a23a51e

refactor(validator/db): remove unnecessary DB load

8302aa3

refactor(rpc): move helper function to helper section

d5a7824

		/// Supply the active configuration if its commitment is not yet stored. The configuration
		/// must match the block header. New configurations are committed with the block.

Uh oh!

Conversation

kkovaacs commented Sep 9, 2026

Summary

Changelog

Uh oh!

Mirko-von-Leipzig left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bobbinth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants