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

Yet another attempt at adopting IETF BLS Standards #1532

Merged
merged 19 commits into from
Jan 8, 2020
Merged

Conversation

CarlBeek
Copy link
Contributor

This is an alternate approach to #1398 and #1499 with the goal of having complete separation between BLS libraries and the spec.

Initially I attempted to include @JustinDrake's requests in #1499, but it got very ugly very quickly. So this is a rewrite that deprecates #1499.

@JustinDrake, I believe this addresses your concerns from #1499, please let me know whether it does.

Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

Awesome! This looks and feels clean

How far are we from having a conforming py_ecc?

specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
specs/validator/0_beacon-chain-validator.md Outdated Show resolved Hide resolved
test_libs/pyspec/eth2spec/utils/bls.py Outdated Show resolved Hide resolved
@CarlBeek
Copy link
Contributor Author

How far are we from having a conforming py_ecc?

Pretty darn close. I opened a big PR this morning. It passes all tests etc.

Annother point I'd like to raise for clarity is whether we should treat BLS as a module. Is bls.Verify() clearer than Verify? In a similar vein, we could alias all bls functions: bls_verify = Verify etc.

@djrtwo
Copy link
Contributor

djrtwo commented Dec 19, 2019

I like the idea of treating it like a module for readability. You can easily jump to a random part of the spec and see bls.Verify and know what is going on.

A quick note that they are used under the bls module in the "BLS Signatures" section for added clarification.

As for bls.Verify vs bls_verify... Keeping the names in line with the standard seems fine even though it breaks pythonic convention. I like the easy mapping to the standards spec. I find myself searching that doc from time to time and it's easy to see what to search for.

CarlBeek and others added 2 commits December 20, 2019 08:12
Co-Authored-By: Danny Ryan <dannyjryan@gmail.com>
@CarlBeek
Copy link
Contributor Author

BLS is now a module and I think it is much clearer.

If we can reach agreement on what to call roots before they are signed/verified then we can get this thing merged. 🎉@djrtwo, can I ask for your input on our comment chain above re: wrapped_root.

@djrtwo
Copy link
Contributor

djrtwo commented Dec 20, 2019

wrapped_root is reasonable but wrapped doesn't give too much description on what the wrapping is.

message is reasonable except that the signed containers use message for the entire object. message_root might work well because it is the root of the message from the signed container.

I'm okay with message or message_root

specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
specs/core/0_beacon-chain.md Outdated Show resolved Hide resolved
@CarlBeek
Copy link
Contributor Author

The way domain-bytes were handled was a hack which I perpetuated with the change of domain into bytes in lieu of ints cast to bytes.

BLS_WITHDRAWAL_PREFIX had a similar problem and so I fixed both in #1551

@CarlBeek
Copy link
Contributor Author

CarlBeek commented Jan 3, 2020

Having replaced all the domain_wrappers with signing_roots, I think this PR is semantically complete. 🎉 The only thing that should change first is the BLS API in the tests. As soon as ethereum/py_ecc#83 is merged and a new release is cut, I can change the API in this PR and then merge.

Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

Very happy with this.
Thanks @CarlBeek !

edit: waiting on the py_ecc release before merge

@djrtwo
Copy link
Contributor

djrtwo commented Jan 6, 2020

ethereum/py_ecc#83 is merged!

@JustinDrake
Copy link
Collaborator

@CarlBeek: What is the status of PoP separation domain? Is that nailed or still somewhat in flux relative to the standardisation effort?

waiting on the py_ecc release before merge

Do we also want basic tests?

@djrtwo
Copy link
Contributor

djrtwo commented Jan 7, 2020

Do we also want basic tests

@JustinDrake once we integrate py_ecc here and all existing tests run, we'll have satisfied the testing requirement. [py_ecc independent tests and all of the existing eth2 test suite]

Copy link
Contributor

@djrtwo djrtwo left a comment

Choose a reason for hiding this comment

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

  • added version bump in a couple more places
  • bumped circlecli cache version to resolve CI failure
  • fixed merge conflicts

LGTM!

@CarlBeek
Copy link
Contributor Author

CarlBeek commented Jan 8, 2020

  • added version bump in a couple more places
  • bumped circlecli cache version to resolve CI failure
  • fixed merge conflicts

I was just trying to push these changes myself, but I see you've already done them. Looks good to me! Ready for merge.

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.

4 participants