-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
EIP-2935 Historical block hashes #9991
Conversation
On hold for a few days until EIP doc is updated |
if parent.Time < config.PragueTime.Uint64() { | ||
p := parent.Number.Uint64() | ||
window := params.BlockHashHistoryServeWindow - 1 | ||
if p < window { |
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.
It's probably equivalent, but I find the pseudo-code in the spec easier to read. What I mean that instead of this p < window
branch you have a early break in the loop. Something like:
for i := 0; i < params.BlockHashHistoryServeWindow - 1; i++ {
ancestorNumber := parent.Number.Uint64() - 1
if ancestorNumber == 0 { // stop at genesis block
break
}
storeHash(big.NewInt(ancestorNumber), parent.ParentHash, state)
parent = headerReader.GetHeader(parent.ParentHash, ancestorNumber)
}
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.
It's an optimization to not have to do big.Int
to uint64()
, or any big.Int
operation that many times
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.
I see. Between optimization and clarity I'd choose clarity until profiling confirms that the performance degradation is material, but OK.
Cherry pick #9991 Co-authored-by: Somnath <snb895@outlook.com>
Cherry pick #9991 Co-authored-by: Somnath <snb895@outlook.com>
Ref https://eips.ethereum.org/EIPS/eip-2935