SSZ: Allow partial deserialization of containers

[jannikluhn]

To decode a SSZed string, we need to know its schema. This makes it a little clumsy to use SSZ as a network serialization format as there are multiple different message types with schemas that are unknown in advance. As far as I can see, the only solution to this is to serialize the actual message and then embed it as byte string in an envelope container. The receiver can then deserialize the envelope, read the message type id in the container, choose the appropriate schema from this id, and then deserialize the actual message. In some cases, we may even have to do this on multiple levels (e.g. to further distinguish between success and failure responses).

Incidentally, containers that have a length prefix can successfully be interpreted as byte strings already. So in some sense containers embed sub-containers automatically as byte strings and we don't have to do this explicitly. This saves us one length prefix, we don't have to do anything special at serialization time, and it makes the process more elegant. Unfortunately, this breaks in the case in which containers have a fixed size as those don't have a length prefix.

If all of this makes sense, it might make sense to require a length prefix for all containers, no matter if they have a fixed size or not (assuming that the resulting overhead is acceptable and we actually are going to use SSZ for network messages).

Tl;dr: If we require a length prefix for all containers to allow deserializing them as byte strings if we don't know their schema (yet).

[protolambda]

Please refer to #754
And the corresponding brain dump: https://notes.ethereum.org/QF8jgOQbRTWUhK1zoi8D4Q#

The idea there for single value encoding + two structure encoding options should cover a lot of use-cases.
Also note that we want an option without the unnecessary-meta encodings for constrained usages such as proofs. Agree that other alternatives make sense in other use cases.

[jannikluhn]

Outdated