Possible aesthetic rework to get_domain

[vbuterin]

In general I dislike how domains, which should be an unobtrusive out-of-the-way thing that we don't think about much, are taking up so much space in code to express, to the point of them being the single thing preventing bls_verify from being expressed in one line of code. Here I reorder arguments and add a default, and make bls_verify a one-liner.

Not necessarily convinced that exactly this approach is the way to go, but IMO it's worth considering.

[JustinDrake]

All instances of bls_verify, with the exception of RANDAO, involve a self_signed_container where self_signed_container.signature is checked against signed_root(self_signed_container). We could make RANDAO fit into this pattern also and abstract away the repeated pattern.

[djrtwo]

This looks fine to me.

Justin are you suggesting making a RandaoReveal object that gets embedded in the block?

{
    'epoch': 'uint64',
    'signature': 'bytes96'
}

This seems reasonable. It doesn't allow you to fully abstract away the pattern because some objects are verified against the fork epoch current_epoch whereas others are verified against the fork epoch of the slot of the object in question

[JustinDrake]

are you suggesting making a RandaoReveal object that gets embedded in the block?

Making a RandaoReveal object yes, but not embedding it in the block. That is, the RandaoReveal can be populated at run-time. It's purely a cosmetic change to reduce the number of arguments in bls_verify from 4 to 3 (essentially merging message_hash and signature into a single self_signed_container). I think all bls_verify calls would then fit in a single line, including domain.

[vbuterin]

I would say altering bls_verify itself would be a bad idea; it mixes layers, as it would introduce notions of how SSZ works etc etc into what is meant to be a pure cryptographic standard. But I would favor a bls_verify_container function (defined in the phase 0 spec) along with bls_verify. So we can still use "pure" bls_verify for the RANDAO (and possible future functions where adding a container would just complicate things), but get the efficiencies of bls_verify_container in all the cases where we are verifying a container.

[JustinDrake]

it mixes layers

Agreed that we do not want to mix layers :) On that note, it has been bothering me that the current bls_verify mixes layers. Specifically, it mixes the "cryptographic" layer (pubkey, signature, message_hash) with the "application" layer (domain).

My suggestion would be to have cleanly separated functions. First, a "pure" bls_verify, and second an Eth2-specific wrapper with self-signed containers and signature domains.

[djrtwo]

Any verdict on this PR?

[JustinDrake]

Any verdict on this PR?

Very much pro :) Further changes I'd like to see:

1. Decouple domain from the cryptographic layer.
2. Make RANDAO fall into the general signature application-layer pattern by adding a new SSZ object.
3. Further abstract the application-layer pattern with a verification function that takes only three arguments: pubkey, self_signed_container, domain.

[djrtwo]

okay. I'll fix merge conflict and merge