Merkleise SSZ container elements #595
Conversation
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 main practical downside I see is that it would increase the cost of re-hashing a validator record. That said, if we use the existing |
|
We don't frequently re-hash individual validator records because we pulled balances out to a separate array so I think this is fine. |
Would it not decrease the cost of re-hashing? A validator container has 7 fields. For the sake of argument, let's say we update one field and that SSZ chunks are 32 bytes. Without Merkleisation we would have 7*32 = 224 bytes of hashing overhead. With Merkleisation we would have log2(ceil(7))*32 = 96 bytes of overhead. |
Reasons to use
merkle_hashinstead ofhashfor containers:BeaconStateis 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.merkle_hashfor lists/vectors.