Skip to content

Latest commit

 

History

History
90 lines (68 loc) · 3.62 KB

best-practices-to-run-a-signer.md

File metadata and controls

90 lines (68 loc) · 3.62 KB
Raw

Best practices for running a Signer

{% hint style="info" %} Intended audience: solo Stackers or Stacking pool operators. {% endhint %}

The following best practices suggest how to create a resilient setup for running your Signer.

{% hint style="info" %} tl;dr: avoid single point of failures, introduce redundancy, monitor things. {% endhint %}

Monitor your Signer and collect logs

  • See here on how to set up monitoring.
  • Retain at least 1 week of logs for both the Signer and the Stacks node.

Downstream components

  • Run a dedicated Bitcoin node and Stacks node per Signer.
    • Ensure the nodes are provisioned with the minimum hardware requirements described here.
    • Nodes should be exclusively dedicated to serve the Signer. Avoid re-using them to serve other clients as that may negatively affect performance (no mock-signing, no Stacks API nodes).
  • If running dedicated nodes is not possible, then ensure that the Bitcoin / Stacks nodes do not become single point of failures for multiple signers depending on them.
    • Introduce redundancy, load balancing, rely on a robust Bitcoin RPC provider, etc.

Split voting power across multiple Signers

  • Distribute your voting power across multiple, distinct Signer public keys to mitigate the risk of loss or downtime from a single compromised key.
  • Each Signer should also limit voting power to a maximum amount and invite Stackers to use a different Signer when the limit is reached.

Monitor new software releases

  • Stay up-to-date with new releases, patches, and security advisories (e.g., GitHub, mailing lists, Discord).
  • Apply updates as quickly as possible, especially those addressing a security vulnerability.

Upgrade procedures

  • Upgrading one Signer instance at the time.
  • Test the update on one instance and, if successful, proceed to the others.
  • While your Signer is offline for upgrades, it won't sign any blocks. Ensure that the downtime is as short as possible.

Diversified hosting

  • Use different provider / configuration where feasible (e.g., a self-hosted instance and one in the cloud, or in two different data center regions, etc.).
  • Ensure each host has redundant power supply and network connectivity.

Fall-back deployments

  • Deploy additional Stacks nodes and Bitcoin nodes to be used as fall-back.
    • Use the same configuration as your active instances.
    • For the Stacks node, comment out the event_observer section.
  • Prepare a backup Signer (same configuration) to be quickly activated, but do not run it.
    • At all times, there should be exactly one Signer instance running for each Signer private key.
  • These instances should be hosted on separate physical hosts (see diversified hosting) from the instances usually active in operations (serving each Signer).
  • If an active instance (e.g., the Signer, the Stacks node or the Bitcoin node) fails, you can quickly switch to the fall-back configuration to continue operations. To do that:
    • Run the backup Signer.
    • Enable the event_observer section of the Node configuration.
    • Restart the node.

Redundancy in operations

  • Ensure that multiple, trusted users can manage and maintain signer instances.
  • Where feasible, users should span different timezones.

Backup signer keys in cold-storage

  • Keep an offline, secure backup of all Signer private keys (e.g., hardware security modules or encrypted storage devices).