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

feat(provider): Receipts by block range in ReceiptProvider #5281

Closed

Conversation

clabby
Copy link
Collaborator

@clabby clabby commented Nov 3, 2023

Overview

Extends the ReceiptProvider trait to add a function that can fetch all block receipts over an inclusive range of blocks.

Rationale

Recently I added a fetching mode to the op-node that allows for it to read receipts directly from a local reth database while deriving L1, however it's still fetching only one block worth of receipts at a time and doing so synchronously. To reduce IO overhead and prepare for taking full advantage of the upcoming parallel prefetching feature, having the ability to fetch many block receipts at once and maintain a backfilled queue of block receipts without blocking the derivation pipeline is useful.

@clabby clabby marked this pull request as ready for review November 3, 2023 12:03
@clabby
Copy link
Collaborator Author

clabby commented Nov 3, 2023

Note: nightly rustfmt does not seem to be respecting the trailing_semicolon rule locally or in CI. Not sure if this changed recently?

@joshieDo
Copy link
Collaborator

joshieDo commented Nov 3, 2023

there is a TransactionsProviderExt::transaction_range_by_block_range. i think it would make this a bit more concise oh its aggregated by block

@github-actions github-actions bot added the S-stale This issue/PR is stale and will close with no further activity label Nov 25, 2023
@github-actions github-actions bot closed this Dec 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-stale This issue/PR is stale and will close with no further activity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants