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

update process_deposit() to actually check is_valid_merkle_branch() #705

Merged
merged 1 commit into from
Jan 30, 2020

Conversation

tersec
Copy link
Contributor

@tersec tersec commented Jan 28, 2020

Should address #703 along with in general finishing a long-standing TODO.

deposit.proof,
DEPOSIT_CONTRACT_TREE_DEPTH,
state.eth1_deposit_index,
if skipValidation notin flags and not is_valid_merkle_branch(
Copy link
Member

Choose a reason for hiding this comment

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

hm, what are the use cases for skipValidation? for tests it should be cheap enough to calculate..

Copy link
Contributor Author

@tersec tersec Jan 29, 2020

Choose a reason for hiding this comment

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

Usually more expensive asymmetric cryptography, especially BLS signing and verification. In this case, the rest of the test-genesis-beacon-block infrastructure wasn't properly creating deposit proofs either, and it's not clear that's relevant to any other nim-beacon-chain functionality for release, so this enables the check for all external deposits (which includes those from the EF test suite).

Copy link
Member

Choose a reason for hiding this comment

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

I meant in this particular case - generating the merkle tree for the deposit data should be quick - it was disabled mainly because during interop, clients were not generating it correctly yet..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In this particular case, yes, generating the Merkle tree for the deposit data should be quick, but nim-beacon-chain stlll cannot create correct trees in this case. This PR splits off the verification-of-other-trees functionality to address a specific fuzzing result, and apparently specific not-actually-run EF test, in a way that doesn't hinder verifying all such trees when nim-beacon-chain itself can correctly create them for mocking purposes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In theory, this lives in https://github.com/status-im/nim-beacon-chain/blob/devel/tests/mocking/merkle_minimal.nim, https://github.com/status-im/nim-beacon-chain/blob/devel/tests/mocking/mock_deposits.nim, and https://github.com/status-im/nim-beacon-chain/blob/devel/tests/mocking/mock_genesis.nim, but that's inconsistent with the correct approach in a few ways.

Most of the mock-genesis-code doesn't even try to use that though - https://github.com/status-im/nim-beacon-chain/blob/devel/tests/testblockutil.nim#L47 has makeDeposit() and makeInitialDeposits() which simply don't attempt to do anything here.

But all of that's a bigger PR than necessary to fix this particular bug, and there are higher priorities at which I was and am aiming.

@tersec tersec merged commit 45dd12c into devel Jan 30, 2020
@delete-merged-branch delete-merged-branch bot deleted the tra branch January 30, 2020 09:31
@arnetheduck
Copy link
Member

shouldn't there be a previously disabled test case enabled after this?

@tersec
Copy link
Contributor Author

tersec commented Jan 30, 2020

@arnetheduck see #712 which adds the bad_merkle_proof deposit operations test that would have caught this separately from fuzzing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants