# EPF6 - Week 15 Updates ## Summary 1. Finish Hash Tree Root PR 2. Opened issue in Fastssz library 3. Merkle multiproof ## Details ### 1. Finish Hash Tree Root PR In general, it was a good coding week. I managed to finalize the [PR #15669](https://github.com/OffchainLabs/prysm/pull/15669) and it's about to be reviewed. This PR has been extended and currently computes hash tree roots for all types except from unions and progressive lists. These ones are not relevant as they are not used in CL spec, even though they will be added in a future PR. During this week, the code has been deeply refactored. The functions (mainly for vectors and lists) have been splitted into smaller ones, making the code more readable. A test suite has been added, covering much of the code. It would be great to add more to provide a 100% coverage. ### 2. Fastssz issue - empty bitlist are not serialized In this [issue](https://github.com/ferranbt/fastssz/issues/221) I depict the behaviour of the current fastssz implementation for handling empty bitlists and show how those bitlists must be serialized as per the CL spec. Luckily, CL specs are executable (and pythonic). So making this kind of checks are very fast. The main point is that fast ssz returns an error if it receives an empty bitlist for serialization or hashing. The problem is that an empty bitlist should be serialized as `b'\x01'`, the following code snippet shows this: ```python >>> # Import the SSZ types we need >>> from eth2spec.utils.ssz.ssz_typing import Bitlist >>> from eth2spec.utils.ssz.ssz_impl import serialize >>> # Create an empty bitlist with limit 8 >>> empty_bitlist = Bitlist[8]() >>> serialize(empty_bitlist) b'\x01' >>> serialize(empty_bitlist) = Bitlist[16]() >>> empty_bitlserialize(ist = Bitlist) b'\x01' >>> empty_bitlist_length16 = Bitlist[16]() >>> hash_tree_root(empty_bitlist_length16) 0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b >>> empty_bitlist_length2048 = Bitlist[2048]() >>> hash_tree_root(empty_bitlist_length2048) 0xe8e527e84f666163a90ef900e013f56b0a4d020148b2224057b719f351b003a6 ``` This needs to be properly addressed before the SSZ-QL handles this corner case properly. I added a [PR #15737](https://github.com/OffchainLabs/prysm/pull/15737) to adapt SSZ-QL to the current fastssz implementation, but honestly, I do not think it is the way to proceed. ### 3. Merkle multiproof As previously mentioned, the ### Next steps - Merkle multiproofs: - review fastssz and dynssz - reassess the work, update the [issue #15598](https://github.com/OffchainLabs/prysm/issues/15598). - start coding