inject privval instance spawned by cometbft into the signer#2981
Open
tschuyebuhl wants to merge 3 commits intoberachain:mainfrom
Open
inject privval instance spawned by cometbft into the signer#2981tschuyebuhl wants to merge 3 commits intoberachain:mainfrom
tschuyebuhl wants to merge 3 commits intoberachain:mainfrom
Conversation
Contributor
|
Hi @tschuyebuhl, I am having difficulty fully testing this change locally. Could you update the PR with a test plan that shows the commands you used to get this working? |
Author
|
hi @fridrik01! Thanks for the reply 💟 Updated the description with the test setup. There are a few manual steps. I'd be happy to integrate this into e.g Kurtosis if this approach is something you guys would like to go forward with. |
fridrik01
reviewed
Jan 28, 2026
Contributor
fridrik01
left a comment
fridrik01
left a comment
There was a problem hiding this comment.
Excuse the long review time on this...
Few comments:
ProvideBlsSignerstill requires local key files to exist at startup so consider skipping that file check whenpriv_validator_laddris configured- Some CLI commands (
validator-keys,show-validator,show-address) load keys directly from disk so consider adding sth like--validator-public-keyflag for remote signer setups (unless its possible to query the pub key of the remote signer?) - Regarding kurtosis, I don't think we need to look into that for now
cc @calbera
|
|
||
| // The privval has been started, we can now swap the FilePV | ||
| if s.privValConsumer != nil { | ||
| s.privValConsumer.SetPrivValidator(s.node.PrivValidator()) |
Contributor
There was a problem hiding this comment.
It would be helpful to log here when we swap the PrivValidator
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
At Chorus One, we recently deployed https://github.com/ChorusOne/nebula on Berachain as a remote signing solution that allows for decoupling of the validator node from the signer keys. It seemed to be running fine, but we noticed that our node was failing to propose a block.
After some further investigation, we found out that beacon-kit spawns another privval signer that's based on file-on-disk, requiring the node to have access to the key regardless of the remote signer deployed.
Also, the remote signer did not receive any
SignBytesrequests, which should be required for building blocks (IIRC it's randao?)Proposed solution
After starting CometBFT, inject the built privval signer into the component provided to depinject. I deployed this on a local devnet, and I'm seeing the network progress, and also started seeing the requests (which currently on mainnet are absent)
Test setup
Clone the forked repo and checkout
privval-for-signing-v2:Start beacon-kit:
In a separate terminal, start reth:
Let it produce a few blocks to make sure it works properly, then stop both nodes.
Update CometBFT to use a remote signer:
Grab the private key, it will be supplied to the remote signer:
Clone nebula repo:
Use this config file to connect to your local beacon-kit node. Please remember to update the
private_key_path:Nebula config inside
Start the Nebula signer:
Then, start beacon-kit and reth. Remember to not reset the current state, i.e input
nwhen prompted.In second terminal:
After some time, the Nebula signer will receive requests to sign bytes, prevotes, precommits, and proposals:
Nebula logs inside
This is the full development setup. The logs show expected results. Now we can substitute the key in beacon-kit repo for some dummy key, and the consensus will still move forward, as opposed to the current
mainbranch, where payloads for proposals will fail to be built because of theBlsSigneralways using the local key.Other notes
Ideally, we'd just change the
ProvideBlsSignerto return the Comet's privval from the get go, but that caused issues with circular dependencies, because we'd have to provide CometBFT service to the Signer, which currently is relatively pure and used by components which are in turn used by CometBFT, closing the loop.Maybe there's some more sophisticated way to handle this. If so, please let me know! I'm not very well versed with cosmossdk / cometbft development, so there's a big chance this solution isn't optimal