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

F/btc delegations #39

Merged
merged 7 commits into from
Aug 13, 2024
Merged

F/btc delegations #39

merged 7 commits into from
Aug 13, 2024

Conversation

maurolacy
Copy link
Collaborator

Use our own structs for handling btc-staking state. This is needed so that we can add fields to these underlying structs. This also removes the use of Binary from state structs (related to #17).

Now we have our own state::staking structs:

  • BtcDelegation (converted from btc_staking_api::ActiveBtcDelegation).
  • BtcUndelegationInfo (converted from btc_staking_api::BtcUndelegationInfo).
  • CovenantAdaptorSignatures (converted from btc_staking_api::CovenantAdaptorSignatures).
  • SignatureInfo (converted from btc_staking_api::SignatureInfo)

This PR also removes optional from btc_undelegation, for simplicity / clarity.

Take into account that these changes are API-breaking for the delegations queries. Likely the structs on the Go side will need to be adapted as well.

Copy link
Member

@SebastianElvis SebastianElvis left a comment

Choose a reason for hiding this comment

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

Great initiative on simplifying the storage! Some initial discussions

Comment on lines +27 to +30
/// staking_tx is the staking tx
pub staking_tx: Bytes,
/// slashing_tx is the slashing tx
pub slashing_tx: Bytes,
Copy link
Member

Choose a reason for hiding this comment

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

Do we need the full tx or we only need their hash values?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We only need the hashes, AFAIK. I was thinking about simplifying this as well, but better do it in a different PR, WDYT? Will create an issue for it (if it's not already there).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Another option is, simplify the entire chain of messages. That is, Babylon sends the hashes already. Though this makes it more dependent on Babylon, and perhaps full validation can't be done. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

but better do it in a different PR, WDYT? Will create an issue for it (if it's not already there).

Agree, let's do this incrementally and leave this in subsequent PRs

Comment on lines +35 to +38
/// covenant_sigs is a list of adaptor signatures on the slashing tx
/// by each covenant member.
/// It will be a part of the witness for the staking tx output.
pub covenant_sigs: Vec<CovenantAdaptorSignatures>,
Copy link
Member

Choose a reason for hiding this comment

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

We probably don't need covenant signatures anymore after verifying them

Copy link
Collaborator Author

@maurolacy maurolacy Aug 13, 2024

Choose a reason for hiding this comment

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

Let's remove them in a different PR then. Can you document all that can be removed / simplified? Will link the issue here.

Update: This is being handled in or as part of #17. Feel free to expand the list under #17 (comment).

Comment on lines +39 to +47
/// staking_output_idx is the index of the staking output in the staking tx
pub staking_output_idx: u32,
/// unbonding_time is used in unbonding output time-lock path and in slashing transactions
/// change outputs
pub unbonding_time: u32,
/// undelegation_info is the undelegation info of this delegation.
pub undelegation_info: BtcUndelegationInfo,
/// params version used to validate the delegation
pub params_version: u32,
Copy link
Member

Choose a reason for hiding this comment

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

Probably these fields can be consolidated as well? at least staking_output_idx, unbonding_time is not used after verification.

One feature that might be needed is to handle params_version properly. This is the version of BTC staking protocol parameters in Babylon. When Babylon changes the parameters the new parameters will be under an incremented version. Probably Babylon needs to report this to all consumer chains upon updating parameters. This is certainly another feature and needs to be done in another PR

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Let's create one (or two) issues for this.

}

#[cw_serde]
pub struct BtcUndelegationInfo {
Copy link
Member

Choose a reason for hiding this comment

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

My current impression is that contract side only needs to remember the unbonding tx hash and unbonding slashing tx hash and that's it

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The delegator_unbonding_sig field is being used to mark the delegation as undelegated. The same can be done through a boolean though.

Copy link
Member

@SebastianElvis SebastianElvis 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!

@maurolacy maurolacy merged commit fc7930d into main Aug 13, 2024
1 check passed
@maurolacy maurolacy deleted the f/btc-delegations branch August 13, 2024 07:01
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