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

[chore]: use wrapper structs for heights #1448

Open
wants to merge 22 commits into
base: main
Choose a base branch
from

Conversation

MCJOHN974
Copy link
Collaborator

@MCJOHN974 MCJOHN974 commented Feb 28, 2025

Description

Switch from raw u64 to struct BlockchainNameBlockHeight(u64) in signer

Closes: #1405

Changes

Scope: refactoring was only in signer
I will not promise that I changed 100% of heights to wrappers, but I think so.

Testing Information

Since it is refactoring we do not need any new tests.

Checklist:

  • I have performed a self-review of my code
  • My changes generate no new warnings
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

@MCJOHN974 MCJOHN974 self-assigned this Mar 3, 2025
@MCJOHN974
Copy link
Collaborator Author

Whoa, during this PR, I first started with changing all heights from u64 to my structs everywhere in code. And now I have a couple of errors saying "you try to put Stacks height but expected Bitcoin height". And this is great, this mean this aliases are really useful!

@MCJOHN974
Copy link
Collaborator Author

whoops, sqlx don't actually work =(

@MCJOHN974
Copy link
Collaborator Author

Blocked until #1466 will be resolved, changing seed not saves from overflow, but do something different

@MCJOHN974 MCJOHN974 marked this pull request as ready for review March 5, 2025 11:48
@MCJOHN974
Copy link
Collaborator Author

Well, even if changing seed to fix test is not so good, we can merge even with it, because on main branch we have same issue. And I think it is better to merge it earlier than later, because I afraid that merge conflict will be terrible if we delay this =)

Comment on lines +1380 to +1416
/// Implementation of saturating_add for int wrapper type `[$type]`. Behavies same way as inner type.
pub fn saturating_add(self, rhs: impl Into<$type>) -> Self {
let rhs: $inner = rhs.into().0;
Self(self.0.saturating_add(rhs))
}
/// Implementation of saturating_sub for int wrapper type `[$type]`. Behavies same way as inner type.
pub fn saturating_sub(self, rhs: impl Into<$type>) -> Self {
let rhs: $inner = rhs.into().0;
Self(self.0.saturating_sub(rhs))
}
/// Implementation of wrapping_add for int wrapper type `[$type]`. Behavies same way as inner type.
pub fn wrapping_add(self, rhs: impl Into<$type>) -> Self {
let rhs: $inner = rhs.into().0;
Self(self.0.wrapping_add(rhs))
}
/// Implementation of wrapping_sub for int wrapper type `[$type]`. Behavies same way as inner type.
pub fn wrapping_sub(self, rhs: impl Into<$type>) -> Self {
let rhs: $inner = rhs.into().0;
Self(self.0.wrapping_sub(rhs))
}
/// Implementation of checked_add for int wrapper type `[$type]`. Behavies same way as inner type.
pub fn checked_add(self, rhs: impl Into<$type>) -> Option<Self> {
let rhs: $inner = rhs.into().0;
self.0.checked_add(rhs).map(Self)
}
/// Implementation of checked_sub for int wrapper type `[$type]`. Behavies same way as inner type.
pub fn checked_sub(self, rhs: impl Into<$type>) -> Option<Self> {
let rhs: $inner = rhs.into().0;
self.0.checked_sub(rhs).map(Self)
}
/// Implementation of overflowing_add for int wrapper type `[$type]`. Behavies same way as inner type.
pub fn overflowing_add(self, rhs: impl Into<$type>) -> (Self, bool) {
let rhs: $inner = rhs.into().0;
let (val, overflow) = self.0.overflowing_add(rhs);
(Self(val), overflow)
}
/// Implementation of overflowing_sub for int wrapper type `[$type]`. Behavies same way as inner type.
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 do not really need all of this for now, only saturating ones, but probably it is ok to keep this impls

@@ -339,7 +339,7 @@ pub struct SignerConfig {
/// already been run, the coordinator will attempt to re-run DKG after this
/// block height is met if `dkg_target_rounds` has not been reached. If DKG
/// has never been run, this configuration has no effect.
pub dkg_min_bitcoin_block_height: Option<NonZeroU64>,
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Tbh I don't get the point of using NonZeroU64 here. We probably are not ok with height = 0 in all cases, not only here? Like, even in test environments, on height 0 there are no testBTC mined, and nobody have funds to do a deposit.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

So I think knowledge that it is a BitcoinHeight is more important that knowledge that it is non-zero. Aaand, I also don't think we want to have non-zero checks on all heights in our codebase

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

And we probably can add some NonZeroBitcoinHeight only for this, but I'm not sure if it is very necessary

}
impl $trait for $type {
type Output = $type;
fn $method(self, other: $type) -> Self::Output {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe $int as output type will make more sense here (at least for substraction). But probably this is also okish

@djordon djordon added this to the sBTC: Withdrawal fine tuning milestone Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Review
Development

Successfully merging this pull request may close these issues.

[Chore]: Use wrapper structs for bitcoin and stacks block height
2 participants