* Implement tuples and a chunk-size reduction to 32 bytes (see #665 and #679)
* Simplify presentation where appropriate. For example, deserialisation is implicit from serialisation (similar to `bls_sign` being implicit from `bls_verify`) and is left as an implementation exercise.
* Dramatically reduce spec size and hopefully improve readability.
If this is accepted, then we can replace all uses of signing in the protocol, which are currently done in a relatively inconsistent way (see proposer signatures, attester signatures, shard proposer signatures, exit message signatures.....) could be unified.
Reasons to use `merkle_hash` instead of `hash` for containers:
1) **Smaller witnesses**: `BeaconState` is a somewhat wide container (26 fields as of now, likely 30+ in phase 2). With concatenation and plain concatenation the size of the Merkle witnesses for the top level are ~32 bytes per field element.
2) **Faster incremental hashing**
3) **Consistency**: Consistent with `merkle_hash` for lists/vectors.
The current spec is arguably inconsistent, in that if a set of N values gets chunked into M chunks where M is not an exact power of 2, the chunks between M and next_power_of_2(M) are filled with SSZ_CHUNK_SIZE zero bytes each, but the last chunk is not padded, and could be arbitrarily short (eg. if the values are 4 bytes and there are 257 of them, then that gets serialized into eight chunks chunks where the first four are 64 values each, the fifth is 4 bytes corresponding to the last value, and the last three chunks are SSZ_CHUNK_SIZE zero bytes). This PR fills every chunk up to exactly SSZ_CHUNK_SIZE bytes for consistency.
terence tsao
JSON
Chih Cheng Liang
Justin
Danny Ryan
Dankrad Feist
jannikluhn
sigmoid
vbuterin
Jordan Andrews
Hsiao-Wei Wang