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 deposit contract according to v0.6.1 #130

Merged
merged 16 commits into from
May 21, 2019
Merged

Conversation

zilm13
Copy link
Member

@zilm13 zilm13 commented May 11, 2019

Some quotations to better understand this update:

The deposit contract does little validation, pushing most of the validator onboarding logic to the beacon chain. In particular, the proof of possession (a BLS12-381 signature) is not verified by the deposit contract.
The proof for each deposit must be constructed against the deposit root contained in state.latest_eth1_data rather than the deposit root at the time the deposit was initially logged from the 1.0 chain. This entails storing a full deposit merkle tree locally and computing updated proofs against the latest_eth1_data.deposit_root as needed. See minimal_merkle.py for a sample implementation.

As you see this PR doesn't look like a production version of deposit root/proofs supplier, so I will be glad to give any feedback and help to move it to something we could really use in production.

@zilm13
Copy link
Member Author

zilm13 commented May 11, 2019

Also I've not found this goddamn **** https://github.com/harmony-dev/beacon-chain-java/pull/130/files#diff-9b854443634f1745881ecae0970951edR174 anywhere except deposit contract sources. Am I correct it's really required and it couldn't be simplified?

Also some docs suggests using call of get_deposit_root() method from contract where it's possible but I'm not sure it'll simplify things a lot, especially when we are too far from current deposit event and everything is purged already in eth1.

Copy link
Contributor

@mkalinin mkalinin left a comment

Choose a reason for hiding this comment

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

There is a couple of notes. Otherwise, it looks good to me and ready to get merged.

return zeroHashes[distanceFromBottom];
}

// # Compute a Merkle root of a right-zerobyte-padded 2**32 sized tree
Copy link
Contributor

Choose a reason for hiding this comment

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

Where does this Python code come from? Could we annotate its source in a class header?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done.

@zilm13 zilm13 requested a review from mkalinin May 17, 2019 17:26
Copy link
Contributor

@mkalinin mkalinin left a comment

Choose a reason for hiding this comment

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

If we don't want to make Merkle tree properly abstracted at this stage then this PR is ready to get merged; I'd only like to see a couple of renames.

@zilm13
Copy link
Member Author

zilm13 commented May 20, 2019

@mkalinin done

Copy link
Contributor

@Nashatyrev Nashatyrev left a comment

Choose a reason for hiding this comment

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

Just some minor notes...

@zilm13
Copy link
Member Author

zilm13 commented May 21, 2019

@Nashatyrev ready for re-review

@mkalinin mkalinin merged commit d73d71d into develop May 21, 2019
@zilm13 zilm13 deleted the spec/deposit-contract branch May 21, 2019 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants