inject privval instance spawned by cometbft into the signer

[tschuyebuhl]

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 SignBytes requests, 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)

[2025-11-07T13:15:20Z INFO  nebula::handler] Received request after 1.7734945s: ShowPublicKey
[2025-11-07T13:15:20Z INFO  nebula::handler] Processing request took: 5.25µs
[2025-11-07T13:15:20Z INFO  nebula::handler] Sending the response took: 132.791µs
[2025-11-07T13:15:20Z INFO  nebula::handler] Received request after 28.20575ms: SignBytes(snip)
[2025-11-07T13:15:20Z INFO  nebula::handler] Processing request took: 3.140291ms
[2025-11-07T13:15:20Z INFO  nebula::handler] Sending the response took: 140.083µs
[2025-11-07T13:15:20Z INFO  nebula::handler] Received request after 28.223625ms: SignBytes(snip)
[2025-11-07T13:15:20Z INFO  nebula::handler] Processing request took: 3.629916ms
[2025-11-07T13:15:20Z INFO  nebula::handler] Sending the response took: 136.458µs
[2025-11-07T13:15:20Z INFO  nebula::handler] Received request after 28.14925ms: SignProposal(h:185, r:0, step:32)
[2025-11-07T13:15:20Z DEBUG nebula::handler] waiting for lock
[2025-11-07T13:15:20Z DEBUG nebula::handler] lock acquired, took: 6.541µs
[2025-11-07T13:15:20Z INFO  nebula::safeguards] checking if proposal should be signed, state: ConsensusData 184/0/2, proposal: 185/0/32
[2025-11-07T13:15:20Z INFO  nebula::cluster] replicating state: ConsensusData 185/0/32, leader_id: 1

Other notes

Ideally, we'd just change the ProvideBlsSigner to 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