feat: Validator block signatures by sergerad · Pull Request #1426 · 0xMiden/node

sergerad · 2025-12-03T23:43:58Z

Context

The Validator provides an endpoint for signing blocks. This endpoint has so far been stubbed out and needs to be implemented.

The Validator and bootstrap commands need to be configured with ECDSA signers to sign blocks. For now we will use insecure, locally stored secret keys for development and testing while providing an abstraction to facilitate a secure backend for signing in the future.

Relates to #1316.

Changes

Update bootstrap command and genesis state to allow genesis block to be signed by validator key.
- Genesis config TOML is no longer optional (must provide key that is used in subsequent start command).
Add signer configuration to Validator.
Add block signing logic to Validator.
Update Validator SignBlock RPC endpoint to return ECDSA Signature.
Add validator key field to block header proto.
Refactor Dockerfile to not bootstrap at build time.

…lidator-sig

…e verify

bobbinth

Looks good! Thank you! Not a full review, but I left some comments/questions inline.

proto/proto/validator.proto

proto/proto/types/primitives.proto

proto/proto/types/blockchain.proto

bobbinth · 2025-12-11T08:33:34Z

crates/store/src/genesis/config/samples/01-simple.toml

+[signer]
+Insecure = "/tmp/insecure_2"


This is for specifying validator private key, right? If so, I'd change the section to validator and allow specifying either private key or public key - e.g.,

[validator] private_key = "hex-encoded-private-key" # or [validator] public_key = "hex-encoded-public-key"

Then, for dev/test scenarios, the users would be able to specify the private key, and for production scenarios, we could set the public key. Setting both at the same time would be an error.

Also, we should document this (I think we have a section that describes how the genesis file is to be used.

Lastly, I'd move this section up to be before native_faucet.

Providing the public key alone would be insufficient for performing bootstrap - an entire signer needs to be provided in order to sign the genesis block.

Ah yes - good point! I think we can do something like:

[validator] private_key = "hex-encoded-private-key" # or, for production settings: [validator] public_key = "hex-encoded-public-key" block_signature = "hex-encoded-block-signature"

But we can start with just the private_key option for now, and add the production-specific option later.

This approach also means you can no longer do a default bootstrap - you need to wire together the secret key from toml for bootstrap command and then into the subsequent start command via CLI flags

I see - so, we can use the private key file for both - genesis block construction and for node startup, right? In this case, probably fine to keep it as a file.

Another option is to output the private key file as a part of genesis construction procedure (similar to how we output the account files).

I think we've gotten lost by focusing on the toml config file. What about keeping the current definition of the toml file - as an (optional) way to configure the contents of the genesis block.

We then take in the private key via CLI separately. I would prefer this be in-line aka no key file - the caller can always use a file and echo it in via an arg. imo this is maximally flexible and alleviates us having to manage a file since the key can just be passed in via env var.

Yea that makes sense. Will update

bobbinth · 2025-12-11T08:35:05Z

bin/node/src/commands/bundled.rs

+            long = "validator-secret-key-filepath",
+            value_name = "VALIDATOR_SECRET_KEY_FILEPATH"
+        )]
+        validator_secret_key_filepath: Option<PathBuf>,


Related to the previous comment, I'm not sure this needs to be a filepath. A secret key is just a 32-byte string that could be hex encoded. But maybe keeping it as a file simplifies things?

Given that this is only intended for devnet/local testing I think taking it inline is good enough.

What we can do is give it a more specific name e.g.

validator.development.secret_key

Have done this. Note that genesis TOML is no longer optional because you need to use the bootstrap key in subsequent node start command.

crates/store/src/genesis/config/mod.rs

bobbinth · 2025-12-11T08:56:32Z

crates/store/src/genesis/config/mod.rs

+    pub fn into_state<S>(
+        self,
+        signer: S,
+    ) -> Result<(GenesisState<S>, AccountSecrets), GenesisConfigError> {


Why do we need to parametrize this with the signer?

GenesisState<S>::into_block() performs signing

Mirko-von-Leipzig

Thanks, looks good in general. The main contention is whether we truly need to be generic over the signer and whether we need a secret key file at all.

Mirko-von-Leipzig · 2025-12-11T09:33:19Z

crates/store/src/server/mod.rs

+    pub fn bootstrap<S: BlockSigner>(
+        genesis: GenesisState<S>,


Do we not have a concrete implementation for this?

How would we support secure + insecure signers without this abstraction?

Can we flash out different scenarios/steps we are trying to cover? For example, we have the dev/testing flow, this flow requires us to have the private key in 2 places:

When generating the genesis block. Here we need the private key for two reasons:

To generate the validator's public key that goes into the block header.

To sign the resulting block.

When starting up the bundled node. Here, we pass the private key to the validator so that it can sign the blocks produced by the block producer.

The production flow will probably be different from this:

The genesis config file would be pre-populated with the public key of the validator and the signature over the block. Or maybe, we'd have an external component that generates the genesis block out of band (from the genesis config file), and then, the node bootstraps from the pre-built genesis block.

When we start up the validator component, we'll need to provide the private key to it. There are probably a couple of options to do it:

The private key could be provided via an environment variable (probably not very secure).

There could be a separate signing services (though, the benefit of such a services is somewhat questionable because it would be doing just "dumb signing" and so, whoever controls the validator can get it to sign anything).

Are there other options?

When we start up the validator component, we'll need to provide the private key to it. There are probably a couple of options to do it:

The private key could be provided via an environment variable (probably not very secure).

There could be a separate signing services (though, the benefit of such a services is somewhat questionable because it would be doing just "dumb signing" and so, whoever controls the validator can get it to sign anything).

For the second point, the main thing is that the corresponding key would be retrieved securely from some remote backend.

The genesis config file would be pre-populated with the public key of the validator and the signature over the block. Or maybe, we'd have an external component that generates the genesis block out of band (from the genesis config file), and then, the node bootstraps from the pre-built genesis block.

The out-of-band process should be as secure as the validator's process of signing blocks. Which would be an argument for using the same/similar approach that the validator uses above for creating the genesis block.

Having said that, I'm happy to remove the Signer trait usage from the bootstrap stack. I don't think we should remove it from the validator/bundled stack, however.

You can remove it either by using an enum to represent signer options, or taking in a dyn T. At some point in the node you'll need to pass in a concrete implementation so we will know what that is.

LMK if we want to go with enum or dyn T. If we go with the former then I will update base to remove the pub trait BlockSigner { altogether.

If it doesn't introduce more complexity, I'd probably go with dyn BockSinger approach. But keeping as is is probably fine too.

crates/validator/src/server/mod.rs

Mirko-von-Leipzig · 2025-12-11T10:26:49Z

bin/node/src/commands/bundled.rs

+            long = "validator-secret-key-filepath",
+            value_name = "VALIDATOR_SECRET_KEY_FILEPATH"
+        )]
+        validator_secret_key_filepath: Option<PathBuf>,


Given that this is only intended for devnet/local testing I think taking it inline is good enough.

What we can do is give it a more specific name e.g.

validator.development.secret_key

bin/node/src/commands/bundled.rs

crates/block-producer/src/block_builder/mod.rs

crates/ntx-builder/src/state/tests.rs

…lidator-sig

bobbinth

Looks good! Thank you! I left some comments inline - once these are addressed, we can merge.

One set of comments is about making insecure_secret_key a required parameter. But I wonder if instead, if the key is not provided, we can assume some default value (e.g., 32 bytes of alternating ones and zeros). This way, in dev/test environments, users won't need to bother about this key at all.

crates/store/src/genesis/mod.rs

bin/node/.env

crates/block-producer/src/validator/mod.rs

crates/store/src/genesis/config/mod.rs

bin/node/src/commands/store.rs

bin/node/src/commands/bundled.rs

bobbinth · 2025-12-15T09:56:21Z

crates/store/src/genesis/mod.rs

    pub fee_parameters: FeeParameters,
    pub version: u32,
    pub timestamp: u32,
+    pub block_signer: S,


It is still not clear to me if the genesis state needs to be generic over BlocSigner - but I guess it doesn't create too much complexity.

bobbinth · 2025-12-15T09:57:28Z

crates/store/src/server/mod.rs

+    pub fn bootstrap<S: BlockSigner>(
+        genesis: GenesisState<S>,


If it doesn't introduce more complexity, I'd probably go with dyn BockSinger approach. But keeping as is is probably fine too.

sergerad force-pushed the sergerad-validator-sig branch from fefe7e4 to 126d992 Compare December 4, 2025 02:43

sergerad added 8 commits December 10, 2025 10:40

Return signature from validator

6e4e575

Update base

1cce801

Fix after base update

bb10a61

Reverse verification logic

b7efb24

Partial complete - add signature proto and genesis bootstrap

08be859

Stringified local key

331d4b3

Feed signer through

e7116b5

Update deps

659e14e

sergerad force-pushed the sergerad-validator-sig branch from 5064109 to 659e14e Compare December 9, 2025 21:44

sergerad mentioned this pull request Dec 10, 2025

Guardrails: Tx and Block Validation #1316

Open

12 tasks

sergerad added 7 commits December 10, 2025 15:40

Rename validator key

e124ff3

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-va…

0d7fb78

…lidator-sig

Fix base integration

c5ed44e

Add unit test and wire validator together with filepath secret, enabl…

75d0516

…e verify

Toml

c7835c7

Changelog

1fdbac0

Comments and use<>

1e8e933

sergerad marked this pull request as ready for review December 11, 2025 03:06

sergerad requested review from Mirko-von-Leipzig, bobbinth and drahnr December 11, 2025 03:06

Fix signer config name

44587b2

bobbinth reviewed Dec 11, 2025

View reviewed changes

Mirko-von-Leipzig reviewed Dec 11, 2025

View reviewed changes

Rename sig proto

5c481e6

sergerad force-pushed the sergerad-validator-sig branch from f0db6e8 to 5c481e6 Compare December 11, 2025 21:07

sergerad added 3 commits December 12, 2025 10:12

Rename public key

0f6f969

Update bootstrap validator configuration

95fe8d1

No optional genesis config

78b4347

sergerad added 11 commits December 12, 2025 11:10

Use context

fc271d8

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-va…

49d8446

…lidator-sig

Update deps

d02a6da

Toml

670ca1c

RM bootstrap from dockerfile

4c89a82

Fix dockerfile dirs

42331a1

Rename to block sig

63f0455

Reduce fns and args

f0f3761

Remove key from toml

01b1001

Merge branch 'next' of github.com:0xMiden/miden-node into sergerad-va…

7fe8b69

…lidator-sig

Fix test

5250615

sergerad requested review from Mirko-von-Leipzig and bobbinth December 14, 2025 20:11

bobbinth approved these changes Dec 15, 2025

View reviewed changes

sergerad added 2 commits December 16, 2025 08:14

Remove deser

8a9ce85

Misc pr fixes

fbd2389

sergerad mentioned this pull request Dec 15, 2025

Simplify env var names for node URLs #1456

Open

Add predefined validator key

8d42710

sergerad merged commit 53660be into next Dec 15, 2025
6 checks passed

sergerad deleted the sergerad-validator-sig branch December 15, 2025 19:50

		[signer]
		Insecure = "/tmp/insecure_2"

Conversation

sergerad commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Context

Changes

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mirko-von-Leipzig Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mirko-von-Leipzig left a comment

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!

Choose a reason for hiding this comment

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

sergerad commented Dec 3, 2025 •

edited

Loading

Mirko-von-Leipzig Dec 12, 2025 •

edited

Loading