-
Notifications
You must be signed in to change notification settings - Fork 742
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
[WIP] Block validation #24
Merged
Merged
Conversation
This file contains 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
This was created in another branch along with a whole bunch of other commits building out databases and other common elements. This full history of these works is available on master, however it should not be necessary.
So that benchmarks don't run each time tests run
- Return a fully deserialized block from validate_ssz_block - Ensure the parent_hash field is handled
- Specified that the block is "serialized".
- Rename errors returned from SszBlock. - Add parent_hash concept to block validation. - Add more comments to block validation.
Move more parameters into get_simple_params()
The length generated when converting from a string was incorrect.
There was a logic error
Now benches just live with the rest of the code in the default feature.
This reduced code duplication.
pawanjay176
pushed a commit
that referenced
this pull request
Nov 28, 2022
* add a rt is_blob_batch * use the mixed type everywhere * glue * more glue * minor fixes * fix range tests * filling in the gaps * moore filling in the gaps
Woodpile37
pushed a commit
to Woodpile37/lighthouse
that referenced
this pull request
Jan 6, 2024
* add a rt is_blob_batch * use the mixed type everywhere * glue * more glue * minor fixes * fix range tests * filling in the gaps * moore filling in the gaps
mergify bot
pushed a commit
that referenced
this pull request
Apr 22, 2024
* add bad state warn log * add rust docs to new fields in `SyncNetworkContext` * remove timestamp todo * add back lookup verify error * remove TODOs
mergify bot
pushed a commit
that referenced
this pull request
Apr 22, 2024
* by-root-stream-terminator * Fix tests * Resolve merge conflicts * Log report reason * Some lints and bugfixes (#23) * fix lints * bug fixes * Fix tests * Merge branch 'unstable' of https://github.com/sigp/lighthouse into handle-sync-lookup-requests * Pr 5583 review (#24) * add bad state warn log * add rust docs to new fields in `SyncNetworkContext` * remove timestamp todo * add back lookup verify error * remove TODOs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR introduces the ability to verify some SSZ serialized block, assumedly (not not necessarily) received from some P2P peer.
The
validate_ssz_block()
function should check the basics of the block (e.g., slot is valid, pow hash known, etc) and verify each attestation inside.It will return either a block validation error, indicating the the block was invalid (or there was an application error) or a status that indicates if the block is (a) already known, or (b) new and valid. If a block is new and valid, the next step would be to start seeing how it fits into our view of the chain -- this procedure is out of scope of this PR.
To do before this PR is ready