Samba, a Besu Portal Client

All right. Yes. So I am Derek. Unfortunately, my partner Meltson wasn't able to make it. But yeah, our joint project is Bezu portal client, Samba.

So. Yes, so I guess I'll give a brief introduction to Portal, because I think a lot of the reasons that I wanted to work on this project were just because I found Portal to be such an interesting topic. And so, there we go. So for the purposes of SOMB up to the scope of EPF, which is just for a few main roles through the history subnetwork. Portal network provides a solution to the proposed changes in EIP-44s that allows for the drastic limiting of storage requirements to run a node.

As well, it also provides a way to handle the sharing of data in a way that not only can handle scaling, but actually benefits from scaling. And these benefits also directly link to Ethereum usability in lowering the barrier of entry to participation in the Ethereum ecosystem. And then as well, outside of the scope of EPF, as we continue, Portal also contains proposed solutions to managing state and beacon chain-related information, although this is somewhat more preliminary. Oh, there we go. And so now moving into the role of Samba in Portal, although this is somewhat more preliminary.

There we go. Now moving into the role of Samba in Portal. There we go. So there's kind of two main roles Samba can play in this big kind of puzzle. One of the big roles is, of course, to fill the gap in the consensus hyperledger ecosystem in terms of a long-term EIP-4IP44 solution in regard to the existence of Samba.

This also works to increase the portal client diversity in addition to ease of use in terms of the base of execution clients. But I think the other one and potentially more exciting in my eyes is its unique position compared to other portal clients in that it has a way to easily bring portal functionality to different Android, to the Android ecosystem with the benefit of the inherent modularity of Java, but also its native support. And so it's a very realistic goal to expect that Samba could simply be built on top of, as a library for other mobile or resource constrained applications. And so, moving into where Samba is at right now, my initial proposal at the beginning was extremely ambitious, and I admit that obviously not quite where we got to, but essentially this proposal is a model of where Samba will be at one point. And so all communications and related infrastructure, including disk B5, portal wire, and UTP, are eventually going to be implemented, mainly UTP at this point, it's the one that we're working on.

And then to have a fully functioning history network, as well as full function of state beacon, state and beacon to the point of present portal development, as well as full interoperability with other portal clients. And so our updated goal range, of course, for the scope of EPF up to this point just pertains to what we figured would be reasonable in this time scope, but essentially that's to get, to have had primary communication infrastructure including a Discovery V5 and then the portal wire. Unfortunately, UTP was a big setback in the sense that there is no generalized UTP library, and so unfortunately we're not able to piggyback off anything like that and will have to be something that we sit down and do ourselves. And then to have infrastructure in place where history network function. And so then moving on, once we have that infrastructure and that we have is to have generalized internal testing, we wanted to have SSD sterilization, deserialization, exposed API infrastructure, metrics.

And the only thing on the list that we weren't quite able to achieve in this goal range is portal hive testing. Unfortunately, just given the scope, we are very close to having had it. A lot of it was just putting little pieces together to test it, but we figured it'd be better to just add more functionality before we go and add just small pieces of testing, as opposed to now we can, as we go forward, add a lot more tests and then prove that we can then interop with other clients. And so this is a general diagram of kind of how Samba functions and the layout of Samba. And the big two pieces on the bottom here are the ones that really took the brunt of the time is getting all the base protocol communication systems in place.

And so that includes like inbound, outbound communication. Whether that be coming from a client, there's a different way to handle requests coming in as opposed to sending out requests or then receiving inbound requests or responses and vice versa. But then of course there's other pieces of the puzzle such as the API which Meltzun had done in Expose an API. So we're very well set up to then start actually serving different pieces, such as the disk v5 and history, portal history APIs. And so, moving forward in the project, the future of Samba, obviously the development of Samba does not stop with EPF.

The project is in a very good place infrastructure-wise and has achieved a lot of milestones in terms of functionality. Like at this point currently, we are able to send and receive all different types, all the available portal wire packets to all the other portal clients. And in terms of certain packet types, such as ping pong, obviously work well. And then we are able to now up to this point almost full functionality on just sending and receiving nodes in terms of building our peers. And so moving forward then the continued development will eventually bring us up to date with the other portal clients.

And so that is, to me, also an exciting part of being a part of Portal is that for the development of Samba, we have EPF. But then also, moving after EPF, there's a portion of getting fully caught up to other portal clients. But then in terms of, I guess, my experience, it's also very exciting in that once we get to that point, it's an entirely different development paradigm where instead of catching up and following different specs, it's now actively participating in development. And so this development is much more something that I will have to learn as well, and that kind of brings me to, I would like to talk a bit about my EPF experience, because I think that was a really big part of this program for me, is just a lot of the learning that I've done. And so I think for me, there's definitely too many skills to list here.

But if I were to sum it up, EPF was my introduction to Ethereum. Before EPF, I didn't know what Ethereum was. I didn't even know what blockchain technology was. So for me, that was a huge, just to get into the space and learn everything. And of course, that brought a huge confidence boost in terms of development.

I previously, you know, I've never worked on such a large-scale project before. And so those organizational skills that are required to create that project was huge to me, and definitely gives me a lot more confidence moving forward in terms of developing projects and continuing to work on this project. As well, I think I acquired a lot of new learning skills. For me, I think I could best describe it as I learned how to learn. So I guess the biggest example for, in my case, is going through and learning the consensus discovery of V5 library.

I had never had such a large scale library that I had to learn in the past. And so learning this library and then automatically going over to the Techu library and then learning the SSC internal infrastructure was a way to then quickly apply the skills that I just learned to then learn a new library, which was a really great experience. And as well, it gave me a project I really enjoy working on and of course will continue working on. And so yeah, the Samba repository can be found onelson's GitHub. I hope that one day we can have a hyperledger or consensus repository for that name.

And then of course, I'd like to give a big thank you to Melson, unfortunately he wasn't able to be here, but he's been a great partner, great working with you Melson if you're watching. And then my friend and mentor, Colby. So unfortunately I can't say that to Colby. If you're interested more in Portal, his talk is going on, I believe, on stage two right now. And then, of course, EPF organizers, Josh and Mario.

It's been a really great experience. I really thank you for this. But yeah, thank you. Thank you so much, Derek. I really appreciate it.

I really appreciate your words and also your experience with EPF. It's amazing to see. I'm also going to make it. I met him in Argentina a week ago. He's also a great person.

Couldn't come, but he will be still also contributing to Samba. Anyone has a question about Portal, about the best Java implementation, yeah. Yeah, just kind of a general question, like if you're still working on UTP, how are you doing the interop testing to verify correctness with the other portal clients? So for interop testing, there's a lot more than just actual content sharing testing, like for example, just the propagation of peers is one thing that we can test, and there's general testing in terms of like just making sure that ping pong, find nodes, nodes responses are functioning. And then as well exposing APIs.

A lot of the stuff also just includes serving like information that comes just from the discovery B5 library. And so that's kind of the part that we are now stepping into is getting all that set up. Cool. Thank you so much. We have space for another question if there is anyone, any comments, any questions.

Yeah. I mean, it's a very important topic right now because probably in like next year the 4.4s will ship, the Ethereum will drop its history. Veracruz is not coming anytime soon. So meanwhile, having light clients serving the state and serving the history is extremely important.

And as we have diversity in the L1 clients, we need diversity in the portal clients. So yeah, I really respect the work, man. And if there are no more... Yeah, sorry. For serving the data, are you getting that from BASU?

Like if you're resharing this chain state over the network, does that come from the BASU database? So that will eventually. But in terms of history right now, the portal network itself, history is being slowly propagated into the network, so that it can then be shared around. The state and beacon will eventually come, but as it stands, we're just trying to get history up and running and then that's kind of the points where we'll then focus on other things and then as well, where we kind of shift into actual, they're participating in the development of portal. Okay, thank you.

Awesome, thank you so much, Derek.