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

Refactor signature handling #540

Closed
JustinDrake opened this issue Jan 31, 2019 · 2 comments
Closed

Refactor signature handling #540

JustinDrake opened this issue Jan 31, 2019 · 2 comments
Labels
general:enhancement New feature or request

Comments

@JustinDrake
Copy link
Collaborator

JustinDrake commented Jan 31, 2019

Right now the signature logic across SSZ object is ad-hoc. The following are dealt differently:

  • Beacon blocks: custom signed header
  • Attestations: external signature
  • Exits: overwrite signature field with 0x0
  • RANDAO reveals: sign raw data

Here's one way to unify the signature logic (discussed with Danny and Vitalik):

  • Remove signatures from the existing SSZ objects
  • For every SSZ object o have a corresponding "signature header" h and canonical signature h.signature.
  • The signature header h is defined below, where h.root = tree_hash_root(o) and h.signature = bls_sign(h) of where h.signature is first set to EMPTY_SIGNATURE .
{
    epoch: Epoch,
    shard: Shard,
    root: Bytes32,
    signature: Signature,
}
@djrtwo djrtwo mentioned this issue Feb 1, 2019
16 tasks
@vbuterin
Copy link
Contributor

vbuterin commented Feb 2, 2019

Adding an empty signature field to every SSZ object seems like a bad idea; it would just add a lot of hashing overhead. The cleanest would just be for every type T have a type SignedT = {data: T, signature: Signature}.

However there is another issue which is that for attestations, we need to have the attestation and custody bitfields not be signed over, because the signers don't know who each other are, so the signature mechanism is not going to fit it well no matter how it is done.

Another more general possibility that covers these cases and others is to establish a rule that the signature is the signature of all fields that come before it. This way we can just use order of appearance in the object to denote order of signing and what does and does not need to be signed.

@JustinDrake
Copy link
Collaborator Author

Closing in favour of #649.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
general:enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants