Replacing SSZ with RLP, Zip and SHA256

SSZ serialization is basically the same as the ABI (except replacing 32 byte word sizes with 4 bytes), which we also already have :blush: So it’s not really that radical a departure.

RLP honestly sucks (and I say that as the inventor of it!). It has lots of edge cases, you can’t easily parse RLP objects without complex libraries (I implemented an RLP parser for the Vyper compiler; it’s hard), and you can’t read individual elements in less than linear time in the worst case. It also sits in an awkward position between being dynamic typed and static typed where the list structure is dynamic but the meaning of the items (especially int vs bytes) is not provided. All this was a big part of the motivation for doing SSZ.

The churn in SSZ

It’s past spec freeze, so no more churn. The only thing left to figure out is the exact structure of SSZ partials.

Finally, compute a hash of the zip stream using SHA256. Again, same requirements. You get a hash for your object.

The main problem here is that this doesn’t allow Merkelization, so you don’t get succinct light client proofs of anything. If you replace hash with a Merkle-tree function, you don’t get the ability to have block headers also be valid serialized objects, or the ability to have different depths for different items…

So the current approach does have quite a lot of benefits.

10 Likes