Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for "dry-run" mode in signer binary #5668

Open
kantai opened this issue Jan 7, 2025 · 0 comments
Open

Support for "dry-run" mode in signer binary #5668

kantai opened this issue Jan 7, 2025 · 0 comments

Comments

@kantai
Copy link
Member

kantai commented Jan 7, 2025

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):

  1. 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
  2. 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!
  3. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Status: 🆕 New
Development

No branches or pull requests

1 participant