You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We propose introducing a remote signer capability to the node, similar to what's available in Cosmos-based blockchains.
We'd leave the current file-based key management system as-is but give node operators a configuration option to offload signing operations to a remote HTTP service.
Such a service could be running on the same machine, on a different server or wherever the user decides to deploy it and it could be implementing various key management schemes, HA approaches etc while being transparent to the node.
Motivation
When initially considering adding HSM support we intended to add a shared Signer trait and implement it for each supported key management solution within the node itself. We believe using a remote signer instead would have some significant advantages:
implementing additional key management solutions (new HSMs, adding HA, integrating with cloud solutions) would be independent from node development itself
additional signer services could be implemented by the community
we would avoid introducing ever-growing complexity to node configuration and codebase
cloud solutions could be made more broadly available accross different providers (for example a Hetzner VPS could in theory access a signer service deployed on AWS with their HSM)
node management can be handed off to a third party without exposing private keys
remote signing capability could be leveraged to implement some HA/fallback solution (for example running multiple nodes with dummy keys and using an external tool to monitor them and only reconfigure master node to use the main remote signer)
enterprise clients could implement their own signing solutions according to their internal requirements
Additionally, existing prior art in CosmosSDK ecosystem leads us to believe that the additional latency would not be an issue as we've feared, since they are using even shorter block times (4s).
Implementation
From the technical perspective implementing remote signer functionality would require following changes:
update node configuration options to handle remote signers
add a Signer trait to allow the node to handle both local keys and remote signers
define a REST API for remote signer services
initially implement a basic HTTP server to offload file-based key management to a remote signer
As the next step we'd propose extending the signer to support some HSM solution.
The text was updated successfully, but these errors were encountered:
General overview
We propose introducing a remote signer capability to the node, similar to what's available in Cosmos-based blockchains.
We'd leave the current file-based key management system as-is but give node operators a configuration option to offload signing operations to a remote HTTP service.
Such a service could be running on the same machine, on a different server or wherever the user decides to deploy it and it could be implementing various key management schemes, HA approaches etc while being transparent to the node.
Motivation
When initially considering adding HSM support we intended to add a shared
Signer
trait and implement it for each supported key management solution within the node itself. We believe using a remote signer instead would have some significant advantages:Additionally, existing prior art in CosmosSDK ecosystem leads us to believe that the additional latency would not be an issue as we've feared, since they are using even shorter block times (4s).
Implementation
From the technical perspective implementing remote signer functionality would require following changes:
Signer
trait to allow the node to handle both local keys and remote signersAs the next step we'd propose extending the signer to support some HSM solution.
The text was updated successfully, but these errors were encountered: