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
The signer binary should support a “dry-run” mode.
In this mode, the binary would operate as if it were a real signer registered in every reward cycle (even though the key it is using is not registered in a cycle — perhaps this mode should even exit with an ERROR if it is registered). The binary wouldn't send any stackerdb messages (because it isn’t registered), but it should instead emit structured logs with the messages that would have been sent. The binary would otherwise function the same as a signer binary normally would: listen for stackerdb messages, evaluate block proposals (even marking them as locally accepted/rejected, etc.), and broadcast globally accepted blocks to its associated stacks node.
This would be useful for several cases (at least):
Infrastructure testing and staging: if someone wants to operate a signer, but wants to test their infrastructure on mainnet before going live, this would give them a fairly accurate way to do that
Debugging and Monitoring in Mainnet: the active signers are sensitive infrastructure: they’re responsible for chain liveness. Because of this, updating them with new behavior or monitoring code as a method of debugging could be dangerous— if the changes degrade performance, that’d be bad!
Testing behavioral changes before release: similar to case (2), testing pre-release versions of the signer binary on mainnet would be actually useful: testnet is a useful environment for this, but when push comes to shove, the best simulation of mainnet behavior is found by running on mainnet.
The text was updated successfully, but these errors were encountered:
The signer binary should support a “dry-run” mode.
In this mode, the binary would operate as if it were a real signer registered in every reward cycle (even though the key it is using is not registered in a cycle — perhaps this mode should even exit with an ERROR if it is registered). The binary wouldn't send any stackerdb messages (because it isn’t registered), but it should instead emit structured logs with the messages that would have been sent. The binary would otherwise function the same as a signer binary normally would: listen for stackerdb messages, evaluate block proposals (even marking them as locally accepted/rejected, etc.), and broadcast globally accepted blocks to its associated stacks node.
This would be useful for several cases (at least):
The text was updated successfully, but these errors were encountered: