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

[Merged by Bors] - Added Merkle Proof Generation for Beacon State #3674

Closed
wants to merge 12 commits into from
Closed

[Merged by Bors] - Added Merkle Proof Generation for Beacon State #3674

wants to merge 12 commits into from

Conversation

Giulio2002
Copy link
Contributor

Issue Addressed

This PR addresses partially #3651

Proposed Changes

This PR adds the following methods:

  • a new method to trait TreeHash, hash_tree_leaves which returns all the Merkle leaves of the ssz object.
  • a new method to BeaconState: compute_merkle_proof which generates a specific merkle proof for given depth and index by using the hash_tree_leaves as leaves function.

Additional Info

Now here is some rationale on why I decided to go down this route: adding a new function to commonly used trait is a pain but was necessary to make sure we have all merkle leaves for every object, that is why I just added hash_tree_leaves in the trait and not compute_merkle_proof as well. although it would make sense it gives us code duplication/harder review time and we just need it from one specific object in one specific usecase so not worth the effort YET. In my humble opinion.

@Giulio2002 Giulio2002 marked this pull request as draft October 31, 2022 14:32
@Giulio2002
Copy link
Contributor Author

Giulio2002 commented Oct 31, 2022

CC @pawanjay176 @michaelsproul please give it a quick look, i still need to work some things out and test it properly and in the meanwhile I would like a general opinion on it and if hash_tree_leaves impls makes sense :). also sorry for the big PR but TreeHash trait is everywhere :(.

@Giulio2002
Copy link
Contributor Author

just kidding it just need some unit tests, do anyone knows of something already avaiable or do I have to try making the test myself?

@Giulio2002
Copy link
Contributor Author

On second thought, I think it is not feasible to write unit tests for Beacon State as you would need something real from nimbus (Which I have no idea where to start as I never coded in Nim) and the struct itself is too big, I think it would be better if something breaks when I simulate gossip/resp req

@Giulio2002 Giulio2002 marked this pull request as ready for review November 1, 2022 15:12
Copy link
Member

@michaelsproul michaelsproul left a comment

Choose a reason for hiding this comment

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

I've left a sketch of how I think we should proceed in a code comment.

Re: testing, the BeaconStates are actually quite small (<100MB) and there are unit tests available from the specs repo here: https://github.com/ethereum/consensus-specs/blob/dev/tests/formats/light_client/single_merkle_proof.md.

Our code that integrates the spec tests is here: https://github.com/sigp/lighthouse/tree/stable/testing/ef_tests. To run the new tests we'd need to add a new case runner and handler.

I'm off sick this week, but can get stuck into this more with you next week.

consensus/types/src/beacon_state.rs Outdated Show resolved Hide resolved
@michaelsproul michaelsproul added the waiting-on-author The reviewer has suggested changes and awaits thier implementation. label Nov 2, 2022
@michaelsproul michaelsproul changed the title Added Merkle Proof Generation for Beacon State [DO NOT MERGE, BUT PLEASE GIVE ME SOME FEEDBACK] Added Merkle Proof Generation for Beacon State Nov 4, 2022
@michaelsproul michaelsproul added work-in-progress PR is a work-in-progress and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Nov 4, 2022
@Giulio2002
Copy link
Contributor Author

Giulio2002 commented Nov 4, 2022

I need to get Finality Branch EF test to work thats the one missing, all of the others are working at the first try due probably to some miracle

@Giulio2002
Copy link
Contributor Author

Giulio2002 commented Nov 5, 2022

Okay so this is interesting, all the tests for finality have a proof that starts with 0x0000000000000000000000000000000000000000000000000000000000000000, and then it goes on normally? also it seems that we generate the correct proof if we discard this weird thing, like the rest of the proof match. is that even possible?

@Giulio2002
Copy link
Contributor Author

I just checked against Erigon lightclient we do not indeed get any finality branch starting with 0 hash

@michaelsproul
Copy link
Member

I was wondering if maybe we were appending the extra node at the wrong end of the proof? The 0x0 value could be the epoch value that is the sibling of the finalized root

@Giulio2002
Copy link
Contributor Author

okay i tried to prepend the extra leaf and now everything passed

@Giulio2002
Copy link
Contributor Author

Consider it ready for review now

@michaelsproul michaelsproul added ready-for-review The code is ready for review and removed work-in-progress PR is a work-in-progress labels Nov 6, 2022
Copy link
Member

@michaelsproul michaelsproul left a comment

Choose a reason for hiding this comment

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

looking great on the whole, just a few minor things then we can merge

cargo fmt is currently failing too, you can fix it up with cargo fmt --all

thanks!

consensus/types/src/beacon_state.rs Outdated Show resolved Hide resolved
consensus/types/src/beacon_state.rs Outdated Show resolved Hide resolved
consensus/types/src/light_client_bootstrap.rs Outdated Show resolved Hide resolved
consensus/types/src/light_client_finality_update.rs Outdated Show resolved Hide resolved
consensus/types/src/light_client_update.rs Outdated Show resolved Hide resolved
@michaelsproul michaelsproul added waiting-on-author The reviewer has suggested changes and awaits thier implementation. and removed ready-for-review The code is ready for review labels Nov 6, 2022
@Giulio2002
Copy link
Contributor Author

Giulio2002 commented Nov 6, 2022

I seee execution-engine-integration-ubuntu fail which seems weird as I did not touch anything related to engine API, that is in CI, it fails at compilation and it compiles for me? uh weird.

@Giulio2002
Copy link
Contributor Author

nevermind i think it was an old test

@michaelsproul
Copy link
Member

you can run the linter locally with make lint btw ;)

@michaelsproul
Copy link
Member

running make lint will also update Cargo.lock which will fix this error from the execution engine integration tests:

error: the lock file /home/runner/work/lighthouse/lighthouse/Cargo.lock needs to be updated but --locked was passed to prevent this

Copy link
Member

@michaelsproul michaelsproul left a comment

Choose a reason for hiding this comment

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

LGTM! Will try to get this merged assuming CI cooperates

@michaelsproul michaelsproul added ready-for-merge This PR is ready to merge. and removed waiting-on-author The reviewer has suggested changes and awaits thier implementation. labels Nov 8, 2022
@michaelsproul
Copy link
Member

bors r+

@bors
Copy link

bors bot commented Nov 8, 2022

🕐 Waiting for PR status (GitHub check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set.

@michaelsproul michaelsproul changed the base branch from unstable to stable November 8, 2022 01:34
@michaelsproul michaelsproul changed the base branch from stable to unstable November 8, 2022 01:34
@michaelsproul
Copy link
Member

bors retry

@bors
Copy link

bors bot commented Nov 8, 2022

Stopped waiting for PR status (GitHub check) without running due to duplicate requests to run. You may check Bors to see that this PR is included in a batch by one of the other requests.

bors bot pushed a commit that referenced this pull request Nov 8, 2022
## Issue Addressed

This PR addresses partially #3651

## Proposed Changes

This PR adds the following methods:

* a new method to trait `TreeHash`, `hash_tree_leaves` which returns all the Merkle leaves of the ssz object.
* a new method to `BeaconState`: `compute_merkle_proof` which generates a specific merkle proof for given depth and index by using the `hash_tree_leaves` as leaves function.

## Additional Info

Now here is some rationale on why I decided to go down this route: adding a new function to commonly used trait is a pain but was necessary to make sure we have all merkle leaves for every object, that is why I just added  `hash_tree_leaves`  in the trait and not  `compute_merkle_proof` as well. although it would make sense it gives us code duplication/harder review time and we just need it from one specific object in one specific usecase so not worth the effort YET. In my humble opinion.

Co-authored-by: Michael Sproul <micsproul@gmail.com>
@bors bors bot changed the title Added Merkle Proof Generation for Beacon State [Merged by Bors] - Added Merkle Proof Generation for Beacon State Nov 8, 2022
@bors bors bot closed this Nov 8, 2022
macladson pushed a commit to macladson/lighthouse that referenced this pull request Jan 5, 2023
## Issue Addressed

This PR addresses partially sigp#3651

## Proposed Changes

This PR adds the following methods:

* a new method to trait `TreeHash`, `hash_tree_leaves` which returns all the Merkle leaves of the ssz object.
* a new method to `BeaconState`: `compute_merkle_proof` which generates a specific merkle proof for given depth and index by using the `hash_tree_leaves` as leaves function.

## Additional Info

Now here is some rationale on why I decided to go down this route: adding a new function to commonly used trait is a pain but was necessary to make sure we have all merkle leaves for every object, that is why I just added  `hash_tree_leaves`  in the trait and not  `compute_merkle_proof` as well. although it would make sense it gives us code duplication/harder review time and we just need it from one specific object in one specific usecase so not worth the effort YET. In my humble opinion.

Co-authored-by: Michael Sproul <micsproul@gmail.com>
Woodpile37 pushed a commit to Woodpile37/lighthouse that referenced this pull request Jan 6, 2024
## Issue Addressed

This PR addresses partially sigp#3651

## Proposed Changes

This PR adds the following methods:

* a new method to trait `TreeHash`, `hash_tree_leaves` which returns all the Merkle leaves of the ssz object.
* a new method to `BeaconState`: `compute_merkle_proof` which generates a specific merkle proof for given depth and index by using the `hash_tree_leaves` as leaves function.

## Additional Info

Now here is some rationale on why I decided to go down this route: adding a new function to commonly used trait is a pain but was necessary to make sure we have all merkle leaves for every object, that is why I just added  `hash_tree_leaves`  in the trait and not  `compute_merkle_proof` as well. although it would make sense it gives us code duplication/harder review time and we just need it from one specific object in one specific usecase so not worth the effort YET. In my humble opinion.

Co-authored-by: Michael Sproul <micsproul@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-merge This PR is ready to merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants