-
Notifications
You must be signed in to change notification settings - Fork 12
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
chore: add check in finality for block height finality parameter to accept finality vote/pubrand #204
Conversation
…tart to process events that updates the voting power table
…btc-staking-activation-height
Will be modified to block finality vote and pub rand commit before activation height |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty solid work 👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! After some offline discussion, I think adding the activation height in the abci of finality module is a good way to go 👍
x/finality/abci.go
Outdated
sdkCtx := sdk.UnwrapSDKContext(ctx) | ||
if uint64(sdkCtx.HeaderInfo().Height) < k.GetParams(ctx).FinalityActivationHeight { | ||
return []abci.ValidatorUpdate{}, nil | ||
} | ||
|
||
// if the BTC staking protocol is activated, i.e., there exists a height where a finality provider | ||
// has voting power, start indexing and tallying blocks | ||
if _, err := k.BTCStakingKeeper.GetBTCStakingActivatedHeight(ctx); err == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think we can combine the two checks into one validation like validateActivation
indication that we only handle finality when (1) the height higher than the activation height and (2) at least one fp has voting power at this height
…btc-staking-activation-height
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙌
fmt.Printf("\n Debug: errOut %s", errBufString) | ||
fmt.Printf("\n Debug: output %s", outBuf.String()) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Remove debug statements.
ctx := sdk.UnwrapSDKContext(goCtx) | ||
activationHeight, errMod := ms.validateActivationHeight(ctx, req.BlockHeight) | ||
if errMod != nil { | ||
return nil, errMod.Wrapf("finality block height: %d is lower than activation height %d", req.BlockHeight, activationHeight) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: The error message should be returned from inside the validation function, for generality.
activationHeight, errMod := ms.validateActivationHeight(ctx, req.StartHeight) | ||
if errMod != nil { | ||
return nil, types.ErrFinalityNotActivated.Wrapf( | ||
"public rand commit start block height: %d is lower than activation height %d", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
Add finality param to minimum block height to allow receiving Finality and Pub Rand Commit of
x/finality
This value is a module parameter and it can be updated by governance proposal