Rewrite SSZ spec

[JustinDrake]

• 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.

Spec changes:

• Support for tuples (see Full support for tuples #665)
• Reduce chunk-size reduction 32 bytes (see SSZ TLDR #679)
• Simplify logic of length prefix serialisation (the same logic is used for lists and containers)
• Restrict the uintN type (N must be in [8, 16, 32, 64, 128, 256]).
• Modify signed_root to take single ssz object, returning the hash_tree_root of the object less the last field
• Do not length pre-fix fixed sized containers (i.e. does not embed a list)

[jannikluhn]

👍 it's much easier to read now.

I wasn't sure if Python conventions are relevant here, but if so we might want to

• replace reduce(lambda x, y: x + y, serialized_elements) etc. with ''.join(serialized_elements).
• renamce object to something else like value as object is a built-in.

[djrtwo]

Awesome! I like the brevity but might argue for a little more verbosity in a couple of places.

[djrtwo]

"Implement tuples and a chunk-size reduction to 32 bytes (see #665 and #679)"
^ Are these the only actual changes that an implementer will need to make?

@JustinDrake

[JustinDrake]

I've updated the description with the changes:

Spec changes:

• Support for tuples (see Full support for tuples #665)
• Reduce chunk-size reduction 32 bytes (see SSZ TLDR #679)
• Simplify logic of length prefix serialisation (the same logic is used for lists and containers)
• Restrict the uintN type (N must be in [8, 16, 32, 64, 128, 256]).

[zilm13]

I'm trying to implement hash_tree_root according to this spec and have few questions/thoughts:

1. Given ordered objects of the same basic type
   Could we clarify here that type and size, just to make it clear

2. Merkleize the chunks, and return the root
   It's not clear from spec, what is merkleization

3. Given the very simple container {i=1}, it's hash_tree_root is 0100000000.. is it ok? So, hash function is never applied. Or did I miss something?

[arnetheduck]

aren't these better called array:s? tuples tend to allow heterogeneous types

[JustinDrake]

I don't care either way. Implementations can use whatever terminology works best. For example, the natural terminology for Go is "array" (instead of tuple) and "slice" (instead of list). Notice that in Python lists also allow heterogeneous types 🤷‍♂️

[mjkeating]

hash_tree_root(value) is referenced several times in this new spec, but it appears to no longer be defined in this new spec. Maybe I'm missing something.

[JustinDrake]

@mjkeating "We now define Merkleization hash_tree_root(value)"