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

WEB3-282: feat: Allow querying blocks by hash #416

Merged
merged 6 commits into from
Jan 30, 2025
Merged

WEB3-282: feat: Allow querying blocks by hash #416

merged 6 commits into from
Jan 30, 2025

Conversation

Wollac
Copy link
Contributor

@Wollac Wollac commented Jan 27, 2025

Fixes #384 and WEB3-282

@Wollac Wollac requested a review from a team as a code owner January 27, 2025 12:10
@github-actions github-actions bot changed the title feat: Allow querying blocks by hash WEB3-282: feat: Allow querying blocks by hash Jan 27, 2025
Copy link

linear bot commented Jan 27, 2025

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For the (unstable) history feature we only have the method commitment_block(self, BlockNumberOrTag).
Should we make this consistent with block_number, block_number_or_tag, block_hash for the execution block? Or would that complicate the API unnecessarily (related to WEB3-272)

Copy link
Contributor

Choose a reason for hiding this comment

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

It's a balance for sure, but if possible that would be beneficial. Block hashes may be preferred in some situations, since they are unambiguous (incl in contexts where multiple chains may be referred to, or in a context where reorgs must be handled). It's also not the end of the world to say they need to get the block number and pass that in instead 🤷

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added the missing methods in cca36da

crates/steel/src/host/mod.rs Outdated Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

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

It's a balance for sure, but if possible that would be beneficial. Block hashes may be preferred in some situations, since they are unambiguous (incl in contexts where multiple chains may be referred to, or in a context where reorgs must be handled). It's also not the end of the world to say they need to get the block number and pass that in instead 🤷

@Wollac Wollac merged commit 7c500de into main Jan 30, 2025
10 of 11 checks passed
@Wollac Wollac deleted the feat/block-hash branch January 30, 2025 12:53
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.

[Feature] Allow querying blocks by hash
2 participants