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

try rebase #64

Merged
merged 17 commits into from
Sep 25, 2024
Merged

try rebase #64

merged 17 commits into from
Sep 25, 2024

Conversation

SebastianElvis
Copy link
Member

@SebastianElvis SebastianElvis commented Sep 24, 2024

This PR merges all latest changes in main to the base branch

NOTE:

  • num pub rand cannot be the default value of 70000, which is too large
  • parallelise e2e

gitferry and others added 16 commits February 8, 2024 18:36
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 SebastianElvis force-pushed the try-rebase branch 3 times, most recently from fe9b9c6 to 3b5992a Compare September 24, 2024 06:13
@SebastianElvis SebastianElvis marked this pull request as ready for review September 25, 2024 01:02
@SebastianElvis SebastianElvis merged commit e3495a3 into base/consumer-chain-support Sep 25, 2024
12 checks passed
@SebastianElvis SebastianElvis deleted the try-rebase branch September 25, 2024 01:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants