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

Update epoch_from_block_number for clarity #4037

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

Conversation

Ayiga
Copy link
Member

@Ayiga Ayiga commented Jan 17, 2025

Closes #4036

This PR:

Implements the suggested improvements that I created in issue #4036.

Specifically, it renames epoch_height to blocks_per_epoch, and it replaces the conditional logic with the 3 separate cases with a single calculation.

This PR does not:

The overall logic / return value of the function. Mathematically they are the same. The only potential downsize is removing one epoch of potential usage from consideration before integer overflow occurs.

Upon analyzing the conditional logic of the `epoch_from_block_height`
it seems that we really want the epoch to increase on the successor of
the multiples of the `epoch_height`.  The conditional branches make this less obvious with 3 separate computed results for the calculation.  It seems that this can be achieved with a single statement.

In addition, extra clarity as to the parameter's intents can be added by
renaming `epoch_height` to something that indicates what the
parameter is symbolizing.
@Ayiga Ayiga force-pushed the ts/enh/epoch_from_block_number_adjustments branch from 0d422fa to 27c53a0 Compare January 17, 2025 15:13
block_number / epoch_height + 1
}
pub fn epoch_from_block_number(block_number: u64, blocks_per_epoch: u64) -> u64 {
(block_number + blocks_per_epoch - 1) / blocks_per_epoch
Copy link
Contributor

Choose a reason for hiding this comment

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

This would break if blocks_per_epoch is 0, which happens in cases when epochs aren't configured yet.

Also I just merged a change that adds a new fn option_epoch_from_block_number right after this one, I'd rebase and change that one too

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh, you are right. I was reaching the zero check as being against block_number instead of epoch_height for some reason. Good catch on my misinterpretation.

With the previous change the explicit check for `blocks_per_epoch`
being zero was removed, thereby removing the protection of division
by 0.  This check should be re-added making this change somewhat less valuable as we're unable to remove all conditionals.

This change has been made to re-add the initial conditional in order to ensure compatibility with the previous implementation.
@ss-es
Copy link
Contributor

ss-es commented Jan 21, 2025

approved, though +1 to merging in main and updating the option_epoch_from_block_number function too

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.

epoch_from_block_number improvement suggestions
5 participants