-
Notifications
You must be signed in to change notification settings - Fork 14
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
try rebase #64
Merged
Merged
try rebase #64
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Release v0.2.0
This PR closes #4. The [change](babylonlabs-io/babylon#23) in Babylon removed voting power from a finality provider if it has no timestamped pub rand for a certain height. Therefore, from the finality provider side, as long as it has voting power, the existence of a timestamped pub rand is ensured. No need to do an extra query to check it. This PR accommodates this change
Pre-step to switching to trunk-based development
This PR bumps Babylon version to accommodate changes about parameters
The goal here was to make life easier for finality provider operators to be able to turn on the finality provider before the consumer node is available and wait for that node to become available for `MinutesToWaitForConsumer` minutes
New flag to command `create-finality-provider` to allow specify eots-pk as hex in the parameters to avoid creation of new EOTS key to store in database This will be useful for finality providers that are in Phase-1 and will need to transition to Phase-2. During Phase-1, only EOTS keys were generated for Phase-2 these finality providers will need to use the same EOTS pk to load and start their finality provider
- Removed previous `MinutesToWaitForConsumer` added in #50 since it was not good enough to wait for the chain to be up, without starting the fpd server to receive fpd creation - Add new loop that verifies the FP status on chain and update it accordingly (before it was only one time at startup) - Add check for keyring key is valid at start of `NewBabylonController` to avoid panic at `mustGetTxSigner`
Partially closes #5 by introducing `jailed` status to the fp instance. The jailing status can be found in two ways: 1. The status update loop periodically checks whether the fp is slashed or jailed 2. Upon `ErrFpAlreadyJailed` error when submitting finality signature Once jailing is detected, the status of the fp instance will be set to `jailed` and terminated.
Add tests to created functions at #52
SebastianElvis
force-pushed
the
try-rebase
branch
3 times, most recently
from
September 24, 2024 06:13
fe9b9c6
to
3b5992a
Compare
SebastianElvis
force-pushed
the
try-rebase
branch
from
September 24, 2024 11:13
abf0999
to
7a7b3b3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR merges all latest changes in
main
to the base branchNOTE: