fix: support eth_getBlockByNumber - #6442
Merged
Merged
Conversation
jeluard
force-pushed
the
jeluard/prover-block-by-number
branch
from
February 16, 2024 16:41
34374ac to
314d60e
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6442 +/- ##
============================================
- Coverage 61.70% 61.64% -0.07%
============================================
Files 553 553
Lines 57858 57874 +16
Branches 1829 1830 +1
============================================
- Hits 35702 35677 -25
- Misses 22119 22160 +41
Partials 37 37 |
Contributor
Performance Report鉁旓笍 no performance regression detected Full benchmark results
|
nazarhussain
requested changes
Feb 22, 2024
nazarhussain
left a comment
nazarhussain
left a comment
Contributor
There was a problem hiding this comment.
As this PR is addressing a user facing bug, let's extract the refactoring to a separate PR.
- Changes of
RecordtoMap, have no objection just keep in separate PR. - Would be nice to add an E2E test for the fianlized block root, it will be easy to test in the current e2e test setup.
nazarhussain
approved these changes
Mar 13, 2024
nflaig
reviewed
Mar 13, 2024
| import {hexToBuffer} from "./conversion.js"; | ||
|
|
||
| export async function fetchBlock(api: Api, slot: number): Promise<capella.SignedBeaconBlock | undefined> { | ||
| const res = await api.beacon.getBlockV2(slot); |
Member
There was a problem hiding this comment.
are we fine with throwing here if there is a network error?
Contributor
Author
There was a problem hiding this comment.
If an error is thrown here then a light-client header is not processed (that error will be logged).
I think that it's ok in the context of this PR as it doesn't change this behavior. If required a proper solution could be implemented separately.
Member
|
馃帀 This PR is included in v1.18.0 馃帀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Make sure the web3 provider
proverwrapper correctly handleseth_getBlockByNumberDescription
During verification, wrapped calls to
eth_getBlockByNumbertry to access EL blocks using block numbers, which is incorrect. Issue is fixed by keeping track of slots numbers when new light-client header are received.Note that when trying to access older blocks it might get slow, as current implementation tries to find matching EL blocks by querying CL slots one by one starting from freshly finalized slots.
Closes #6032