# Week 17 ## Recap This week I was able to at last complete the client SSZ implementation. This included a successful SSZ library swap and the passing of all the Portal Wire vector unit tests I had implemented. I was also able to merge the feature branch containing everything and deal with all of conflicts caused by the codebase re-org and some additional packet functionalities. The biggest challenge was coming up with a working solution for the CONTENT packet SSZ problem I was facing. Which turned out to be a result of parsing the Union type inside of an SSZ container. This was solved by creating an individual wrapper class for the Teku SSZ Union interface and design it with the strict three sub-types that the Portal Wire specs intend the packet to have. When merging I also noticed a problem with the Consensys Discovery V5 library in regards to the NodeRecord enr sequence value. The value is stored as a Tuweni library UInt64, whereas the Teku internal SSZ library processes UInt64 values under the Teku UInt64 implementation. The temporary solution for this is to just convert the Tuweni UInt64 to bytes, then to long and then finally into the Teku UInt64. This is something that will eventually have to be resolved with some sort of wrapper but the temporary fix works for now. Outside of completing the pull request merge I also began work on designing and implementing the PING/PONG handling in order to have a more generalized way of establishing connection with other Portal Client nodes. ## Learning Like in previous weeks, most of the learning this week was an extension of what I have already been searching through. I was fortunate in that most of the stuff I found this week directly solved the problems I was experiencing instead of just serving as ambiguous hints. ### Concepts #### Teku Internal SSZ Because the Teku internal SSZ library does not contain a Bytes2 SSZ type I had to find an appropriate replacement to use inside the CONTENT packets SSZ Union. After searching through the library and trying out a few types such as Byte, Bytes32 and ByteList I found the ByteVector type which did exactly what I needed. It allows for the strictly enforced size of any array of bytes that it parses. When given a size of two it functions identically to the Bytes2 SSZ type. Searching through the library was also useful in learning how SSZ Union is implemented. Unlike the SSZ Container implementation, Union is implemented as an interface and so it does not allow for inheritance in the same way that I could do with the other packets. Figuring out how Union works instead was what allowed me to come up with the wrapper design that ended up working. ##### Resources 1. https://github.com/Consensys/teku 2. https://github.com/Consensys/teku/tree/master/infrastructure/ssz #### Portal Wire Specifications The Portal Wire Specifications were once again useful for referencing packet SSZ types and the corresponding test vectors. For this week I was pretty much exclusively focused on the Content packet specifications in regards to the three vector tests for each SSZ Union sub-type. I could then also refference my existing packet SSZ implementations in combination with the test vectors if they had the same SSZ type as one of the three sub-types in the SSZ Union. ##### Resources 1. https://github.com/ethereum/portal-network-specs/blob/master/portal-wire-protocol.md 2. https://github.com/ethereum/portal-network-specs/blob/master/portal-wire-test-vectors.md ## Tasks My biggest accomplishment this week was finally completing the Portal Wire packet SSZ implementation. All of the Portal Wire vector tests for all packets pass and so I can now officially move on. To achieve this I had to fix the CONTENT packet SSZ serialization and deserialization that I had started last week. To do so I had to change my implementation from fitting the SSZ Union inside an SSZ Container to instead be a wrapper of the SSZ Union class designed to work with the three sub-types that the packet can have. In doing so I was able to get rid of the 4 byte offset that the container had been adding. I had not realized previously but it appears as though this offset is added only when containing complex SSZ types such as Union. Which is why when adapting a different packet SSZ implementation to CONTENT I was not getting the desired results, as the other packet only contained primitive types. After finishing everything I then had to do a codebase re-org on my end to make the merge process easier. I was able to resolve all of the merge conflicts and succesfully merge the feature branch. Which included all of the vector test implementations as well as the migration from SSZ libraries. I then moved on to designing the PING/PONG handlers as well as learning the new network systems that Meldsun had implemented. https://github.com/meldsun0/samba/pull/15 ## Week 18 Plan Moving on to Week 18 I am looking to really dive in to client interaction with other Portal Clients. This also includes working with the History sub-network as some packets need a sub-network to work on top of. Working on the interopability also segways into beggining to set the client up to interact with the Portal Hive test network which should make it easier to see if the messaging systems are working correctly, as well as provide an easily demonstrable milestone for the client to have reached. The tasks that will further push the client to that point that I intend to work on in the coming week are: - Continue to configure the PING/PONG handlers to work directly with the PortalWireMessageHandler and the corresponding outgoing request system - Continued work on the FINDNODES system using the work-in-progress DHT system from Meldsun - Look into dockerizing the client so that it can begin to run on the Portal Hive test network Another thing I hope to spend time on in the coming weeks is creating some psuedo sequence diagrams for both ease of understanding the many moving parts, but also so that I can include them in our project presentation to give an idea of how the client works. This also should help for when we begin a more formal documentation process for both detailing standalone client use, as well as how it could be incorporated as a library in Besu or any other project.