Avoid Hash <> hash() type and func confusion

[protolambda]

Why:

• hash() is the SHA-256 of empty input. Hash() is the default instantiation of the Bytes32 alias, i.e. 32 zeroed bytes.
• Hash(*input*) casts the input to the Bytes32 alias (not changing the contents!). Whereas hash(*input*) hashes the input to a Hash (with SHA-256).

Changelog (no functional changes):

• remove Hash alias of Bytes32
• introduce Root alias of Bytes32
• change roots to Root
• change non-roots to Bytes32

Difficult choices:

• a Bytes32 inside a proof is technically also a combination of nodes. But not necessarily so for the very bottom sibling. So not a Root or Hash
  • Also, Hash is especially confusing, as a leaf item is packed into 32 bytes but not hashed.
• There are a bunch of hashes that are not SSZ roots that we start calling Bytes32 now:
  • Eth1 block hash
  • Randao mix / seeds
  • withdrawal_credentials

I am opposed to making a separation between SigningRoot and HashRoot: the roots should be typed by the (summary) type they represent, not the function that is used.

signing_root already is a hack to make the same object definition work for multiple purposes. But really signatures shouldn't be part of the tree, unless intended so. A SSZ type simply cannot be represented by the same immutable cached (each node) tree, covering both signing-root and hash-tree-root, as the tree structure is dfifferent.
And since we are using signing_root and hash_tree_root pretty much exclusively, I would prefer to just do away with signing_root. Maybe in favor of a way to represent a container with a signature as a serialization-only thing.

Open for suggestions/comments.

[ralexstokes]

changes look sound @protolambda -- can you elaborate on what you mean by "do away with signing_root"?

[protolambda]

@ralexstokes As in completely remove it. With more type definitions it's technically not necessary. And it's difficult to fit one type that can be merkleized in two different forms onto a single binary tree.

[djrtwo]

one minor change