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

rafactor/Refactor handler for staker message #33

Merged
merged 4 commits into from
Aug 29, 2024

Conversation

KonradStaniec
Copy link
Collaborator

@KonradStaniec KonradStaniec requested a review from a team as a code owner August 28, 2024 09:00
Copy link
Member

@gitferry gitferry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! Mostly nits

// 2. Basic stateless checks
// - verify proof of possession
if err := parsedMsg.ParsedPop.Verify(parsedMsg.StakerAddress, parsedMsg.StakerPK.BbnPk, ms.btcNet); err != nil {
return nil, types.ErrInvalidProofOfPossession.Wrapf("error while validating proof of posession: %v", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return nil, types.ErrInvalidProofOfPossession.Wrapf("error while validating proof of posession: %v", err)
return nil, types.ErrInvalidProofOfPossession.Wrapf(err)

The message is already in the error text


// 4. Check finality providers to which message delegate
// Ensure all finality providers are known to Babylon, are not slashed,
// and their registered epochs are finalised
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should cut the last line as we don't have the registered epoch anymore

}
// ensure the finality provider is not slashed
if fp.IsSlashed() {
return nil, types.ErrFpAlreadySlashed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about wrapping the slashed fp pk?

}

// no need to do more validations to the btc header as it was already
// validate by the btclight client module
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// validate by the btclight client module
// validated by the btclightclient module

endHeight := stakingTxHeader.Height + uint64(parsedMsg.StakingTime)

btcTip := ms.btclcKeeper.GetTipInfo(ctx)
stakingTxDepth := btcTip.Height - stakingTxHeader.Height
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
stakingTxDepth := btcTip.Height - stakingTxHeader.Height
stakingTxDepth := btcTip.Height - stakingTxHeader.Height + 1

Should we follow the convention that inclusion counts as 1 confirmation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think on Babylon node we are using depth everywhere i.e for being k-deep, and for w-deep. Of course we may discuss this change as it makes sense to be compatible with phase-1, but this is not something to be done in refactor pr.

For now I have created ticket to track this - #39

Comment on lines 166 to 172
type ParamsValidationResult struct {
StakingOutputIdx uint32
UnbondingOutputIdx uint32
}

// ValidateParams validates parsed message against parameters
func ValidateParams(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think we move the params-related code to a separate file or a different package?

And would it be better if we make ValidateParams a method of ParsedCreateDelegationMessage?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm I guess it can be moved to types as it really do not touch/modify the state.

As for making it a method on ParsedCreateDelegationMessage, I am slightly against mostly due to the fact validating against the parameters is not really a property of ParsedCreateDelegationMessage (I know this sounds weird 😅 ) but rather operation that is by using ParsedCreateDelegationMessage with other pieces of data.

Maybe in other words, ParsedCreateDelegationMessage is just data transfer object without any assumptions how it will be used. Other functions, object by use it for its own purposes, but the dto object should be as bare as possible.

pk, err := key.ToBTCPK()

if err != nil {
return nil, fmt.Errorf("failed to parer *bbn.BIP340PubKey: %w", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return nil, fmt.Errorf("failed to parer *bbn.BIP340PubKey: %w", err)
return nil, fmt.Errorf("failed to parse *bbn.BIP340PubKey: %w", err)

Comment on lines 18 to 19
PublicKey *btcec.PublicKey
BbnPk *bbn.BIP340PubKey
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
PublicKey *btcec.PublicKey
BbnPk *bbn.BIP340PubKey
*btcec.PublicKey
*bbn.BIP340PubKey

A bit confusing about BbnPk because we also call it a BTC public key

Comment on lines 39 to 40
Signature *schnorr.Signature
BbnSig *bbn.BIP340Signature
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Signature *schnorr.Signature
BbnSig *bbn.BIP340Signature
*schnorr.Signature
*bbn.BIP340Signature

Same here. BbnSig is a bit confusing

@KonradStaniec KonradStaniec changed the title Refactor handler for staker message rafactor/Refactor handler for staker message Aug 29, 2024
@KonradStaniec KonradStaniec merged commit 07bd533 into main Aug 29, 2024
17 checks passed
@KonradStaniec KonradStaniec deleted the refactor/refactor-staking-message-handler branch August 29, 2024 06:30
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.

2 participants