# Samba, a Besu Portal Client
## Project Abstract
My intentions for the project pretty much right out of the gate were to provide a provide a Portal Network solution for the Consensys/Hyperledger ecosystem. This of course required the ability to function and interact with the existing Portal Clients in the space. Naturally in order to achieve this the new client would need to follow the same specifications as the existing clients. An additional sub-goal was that the client was to be designed in such a manner that it could function without the need for Besu. This was/is particularly appealing in the case of the unique position of natively bringing Portal to the Android ecosystem. I was fortunate to come into contact with my partner in development [Meldsun](https://github.com/meldsun0) very early on in the development of the client where we learned of each others similar goals. From there we went with the client name Samba, named after his rescue dog Sambayon. It is important to note that with the scope of the project, it was a given that its development would extend past the duration of the EPF. With this in mind at the beginning of our development we instead set out to accomplish some major foundational goals that would put Samba in a good position for development after EPF.
## Status Report (At the end of EPF)
In honesty, my initial goals at the beginning of EPF when I had originally proposed a Portal Client were quite ambitious given the time frame. The extent to which they could have been achieved largely depended on the size of the team that was available. Fortunately I was able to find my partner Meldsun in which our collaboration enabled us to get much closer than I realistically would have expected. That being said, although at the end of EPF my initial proposal for the client functionality was not completed, the proposal instead represented where the client will be at completion. At the end of EPF the status of Samba was at a point where we were reaching functionality of the history network in a limited context in terms of node propagation and the groundwork to persist data. We got very close to our reworked goal of getting the client prepared for Portal Hive tests as a means of demonstrating interoperability.
Notable parts of the initial roadmap that proved to be more challenging:
- Getting Discovery V5 fully configured and working to propagate other Discovery capable nodes took longer than expected. This was mainly due to the learning overhead of understanding the Consensys library. It was an additional challenge to then setup and configure a system to work within the TALKREQ/TALKRESP packets over which the Portal Wire Protocol operates
- The blocking factor of having no generalized UTP library was a distinct setback in achieving full History Network functionality
- We also determined that at least within the time scope it was not reasonable to directly work on any of the other Portal Sub-networks. Fortunately a good portion of the History Network infrastructure should carry over.
In terms of finished tasks at the end of EPF from my end there were some notable completions:
- The underlying Discv5 handling system was a good first start to the initial Portal Client connectivity. This later underwent a refactor but the logic largely remained the same
- The initial design and underlying logic for Portal packet communication through the TALKREQ/TALKRESP functionality provided by the Consensys Discv5 library. Again this also had some refactoring but the functionality remained the same
- The Portal Wire Packet Serialization/Deserialization was potentially the largest achievement on my end as it enabled the ability for full communication with the other existing Portal Clients using all of the Portal Wire Protocol packets. The main struggle with this one was once again learning an entirely different library and then implementing all of the Portal Wire Protocol packet vector tests
- It was also nice to get some smaller systems in place such as a proper bootnode setup and a configurable CLI
Listing all complete tasks at the end of EPF the distinctive completions were:
- Discv5 incorporation
- Portal Wire Packet design
- SSZ Serialization/Deserialization for packets
- Portal Wire message handlers for inbound and outbound packet communication
- DHT implementation
- History Network infrastructure
- Generalized testing for foundational systems
- Exposed API infrastructure
- Infrastructure to support additional Sub-networks
- Database storage solution and corresponding infrastructure
- Metrics
Listing tasks that we had aimed to complete in the scope but were unable to:
- UTP implementation
- Connection with Portal Hive
- JSON-RPC endpoints/infrastructure
- More expansive testing
## Status Report (End of January 2025)
There was a great deal of progress made in terms of achieving History Network functionality. Most of which simply followed from finishing the tasks that we weren't able to get to at the end of EPF, as well as a few that were a natural next step at the completion of those tasks. These tasks included:
- JSON-RPC infrastructure
- A selection of JSON-RPC endpoints
- Samba integration with Hive
- Portal Content SSZ
- UTP Implementation (Nearly Complete)
Through the integration with Hive, Samba was able to pass 33 tests, this figure will of course continue to grow. The nearest next to be completed new endpoints are reliant on the use of the new Portal Content SSZ Serialization/Deserialization and the use of UTP.
## The Future of Samba
Evidently the development of Samba did not stop with EPF, and it will continue into the foreseeable future not only for functionality with Besu but also with a potential to grow into the Android ecosystem. Given the Ethereum development-wide shift to Portal as a storage solution, the utility of Samba only grows with time. The biggest achievement on the horizon will be to link Samba with Besu once the History Network is complete.
## My Personal Experience of EPF
Overall participating in the EPF was a fantastic experience. Not only did I find an excellent project to work on and an amazing partner in development, but I also learned a lot along the way. At the beginning I had a few difficulties developing interest in the sense that there was so much to choose from. When I eventually was able to narrow down what aspect of Ethereum I was found most appealing I found my interest drastically increased. I additionally had some trouble wrapping my head around starting such a large scale project which proved discouraging. However once I found that working on it was something I really enjoyed, that feeling quickly dissipated. Retrospectively I think I would have benefitted from trusting the process more, but this is a takeaway I am now well aware of. Working on Samba allowed me to gain a great deal of experience in regards to tackling the use and learning process of new libraries. I can best describe this as having learned how to learn. In general I perhaps would have had a smoother start if I had known Samba would be something I was so interested in. Nonetheless hindsight is 20/20 and I believe this is a realization to be mindful of when starting any large scale project. Ultimately I believe I did a good job of finding a piece of Ethereum to work on, especially given that EPF was my introduction to Ethereum and blockchain technology in general.
When looking back at the actual experience of EPF outside of development I think it was a one of a kind opportunity. Even just regarding concepts like learning to better communicate my work were valuable pieces to be included. From my personal experience I found it to be really helpful to attend every stand-up call and do the corresponding weekly write up. I found that it encouraged a solid manner of partitioning work on a week-by-week basis. The office hours were also a great addition to get a general survey on other concepts of Ethereum. Last but not least it was amazing to get to interact with everyone involved, it was an honor to meet so many outstanding individuals.
My primary takeaways from EPF in no particular order are:
- Confidence in development and communication
- Skills on how to work on and design a large scale project
- A great development partner to continue working on Samba with
- An introduction to Ethereum and the developers behind it
- A deep dive into my own development tendencies and potential ways to circumvent
hesitancy towards starting a big project
- Arguably an excellent sample of a space I would really enjoy continuing to work in
## Conclusion
I am extremely grateful to have been a part of this program. It was a pleasure to have been able to meet and interact with the many great people in the space. Getting to work on such an interesting project has and continues to be both exciting and fulfilling.
I of course would like to extend a big thank you to my development partner Meldsun, of which it continues to be a great time working with you. As well as a thanks to our mentor Kolby for continuing to aid in any questions we may have during the development of Samba. Finally a huge thank you to Josh and Mario for making the program possible and creating such a memorable experience.
## Resources
[Samba Github](https://github.com/meldsun0/samba)
[Samba Portal Network Discord Channel](https://discordapp.com/channels/890617081744220180/1301231225276465152)
[Samba Besu Discord Channel](https://discordapp.com/channels/905194001349627914/1326322164118458452)
[Samba, a Besu Portal Client (Devcon SEA)](https://www.youtube.com/watch?v=g9P0Lu2qqnI)