Native Implementation of Ephemery Testnet on Besu & Teku Client Pairs

Hello everyone. How are you guys doing today? I hope you're having a great time at DEF CON. Okay, so today I'm going to be talking about native implementation of ephemerate testnet on client pairs, Terco and Bessu. First of all, I'm Glory, and I would like to ask this question.

How many of us have heard of the word Ephemery Testnet before now? Okay, so those people that raised their hand are people in the fellowship. So that means we still have so many persons that are here to know about Ephemery. I remember when I started working on this project, my mentors, the guys from Techco and Best Studio, were like, what is ephemeris? I've not heard of it before.

So I had to start explaining. I had to share the link to the documentation for them to go through it. OK, so with that being said, um. OK. That being said...

All right, so why they're trying to work on it. First of all, what is ephemery? Ephemery is a resettable short-term-based testnet. So when we say it's resettable, it gets to reset itself after a given period of time. So it's not like the regular testnets that we are used like Sepolia or LISC-E and the rest of them.

So eFirmary is kind of dynamic and not like the others like I said. So I wouldn't really want to go deep into eFirmary, so I'll just be diving into what I actually worked on. So yeah, for the project, the goal of the project was for me to implement or create native support for ephemery on Besso and Circle clients. And why was this needed? We realized that just like I asked, most of you didn't know about ephemery.

So ephemery is still pretty new, and we are trying to see how we can get more clients and more people to know about it and to start using it. So we want to improve the user adoption and we want more clients to be running on eFirmware natively without having to go into the manual process of setting it up. So based on the work that I've done, initially when I started this project I noticed there are some work that I've done before in the past by some other fellows and at that time we had support for Forget, Red and Lighthouse and Luster so work has started for these clients. I don't think they are completed yet but as at the time I came in I noticed there was no native support for Teco. So for that, we needed to download the Genesys SSD files and the Genesys files and all of that to do those processes manually when trying to run the node.

So to avoid that headache, we decided to implement native support for it. And what does that really mean when we talk about native support? We want a situation whereby when you are trying to run a node, you can easily do something like besu-network-efermary, just like you do with other supported clients like Sepulia and the rest. So because efermary is quite different, the process of implementing it on clients was not as straightforward like with other clients. So we needed to do things like trying to write some custom functions or some custom classes as well to be able to work on the updating of the genesis state and all that.

So because we understand that ephemeris updates after a certain period of time, so there was need for a custom function to be created for that to be able to happen dynamically. So these were some of the things I did. Okay, so for the ephemeris genesis 5, I noticed the way it is structured when I checked the original repository, it was quite different from what Best to Clients was expecting. So I had to make some changes like other things like the S-Arch, the discovery nodes and the boot nodes to the Genesis file itself. And also I updated the documentation when I was done with the work so that when you go to their documentation now, you can see, just like you see Sepulia Oliske on their doc, you can see a family there and know the right command for you to run to be able to do that.

And with this, we also implemented some testing because every aspect of this project, with the way BestESU client works, everything you do you have to write tests for it. So every implementation work done here was also properly tested. And so for TEKU we did similar stuff but with TEKU, you know, for the CL clients we don't use the normal JSON format file for the genesis so it was SSE and it and it's not as easy to manipulate as you do with the genesis format file. So with that, we needed to take a different approach and see how we can load the ssd file from the ephemera repository to get the updated states at every given point in time. So the same thing applies with Tecku.

We also created a custom class and function to be able to update the Genesys states at every given point in time dynamically. So if you're running the node, you're able to get the updated states every time, so you don't need to go to the ephemeral website to go download it and use on your system. And also with Tecku, I worked on the reset feature, which means if you are running a node, you don't have to stop the node manually. So go delete your database and all of those stuff. When it's due for resets, it resets itself and then deletes all the necessities that needs to be deleted in the DB.

Yeah, so pretty much like I said earlier, there's not much difference between the implementation on Serco and Bessu, just some different files and changes that were made, which was not exactly the same thing. And then the SSE file I mentioned and Genesis file and all of that. OK, so yeah, so this is like a summary of everything I did on the implementation for Terco and BESU. I completed the initial research, then created a custom function for ephemera on both BESU and the Terco clients, and then right now you can have native support on both then right now you can have, right now we have native support on both clients, so you can use the flag, the native flag like BESU.network.

fmri or Terco.network.fmri and you can do that as well. And then the documentations are also properly updated and we have suitable tests for all of this. So in summary, for the whole period of the fellowship, I was able to get up to 15 PROs merged and currently have one PRO that I'm still working on and one open issue.

So as far as work in progress goes, based on what I planned to do during the course of the fellowship, I wasn't able to get to the point where I was able to work on the reset feature. So right now I still have the reset feature to implement on BESU, and then as far as the website goes, I'm still yet to work on that, just redesigning the website and the tutorial work through, which I plan to do, but I didn't have enough time to do that before now. For the challenges, these are some of the challenges I faced. This was my first time working on protocol development. Before now, I do normal application level development.

I write in smart contracts, doing dabs and all that. So this was my first time. And it was a lot of learning process. Had to learn about the protocol, CL, EL. And that was one thing I love about this project, because it gave me the opportunity to learn about those different areas.

And then trying to understand the code base for each of these clients was another big problem. It wasn't even writing the code itself, but going through their code base, trying to figure out where my implementation is going to be, those were some of the challenges I had. But thankfully enough, I had good mentors who were able to help me navigate that. So for the future of the project, I plan to continue my work on the BESU client to complete the research future and to also implement there's still some little work I need to do on TEKU for the validator clients on slots processing and then to expand the support to other clients. So right now, we have some clients that don't currently have native supports.

So my plan is to continue working and to extend support to those other clients, and also to become a validator, an ephemera validator. So key takeaways for me, this program has given me the opportunity to dive into the Ethereum protocol itself, which was one of the reasons I joined. And then I've had the opportunity to learn a lot about what the protocol entails, client implementation, what the different clients we have in the Ethereum protocol and all of that. And then before now, I do Java. Java was actually like my very first programming language when I started.

But I've not done it for like more than four years or so. But with this project, I've come back to Java. And I was able to like improve on my skills as far as Java goes, as well as testing and all that. Then for EIP, I've not actually implemented anything working with an EIP before, but this project actually gave me the opportunity to write code following an EIP, so that was really good for me. Yeah, so for my mentor, special thanks to Paul Harris from the TECO team.

Unfortunately, they are not here right now. And then, thanks to Sally from the BESO team. Thanks to Mario and PK910 from the eFMRI team and the past fellow, Oli. When I started I asked her some few questions and she also shared some of her past updates with me which was really helpful as well. And thanks to Josh and Mario once again for the opportunity and for setting this fellowship up.

So before I go, I'd like to encourage anyone here that wants to, that is considering contributing to ephemeric. So if you want to do that, you can do that in different ways by you can be a node runner, you can implement on client, like I mentioned can be a node runner, you can implement on client, like I mentioned earlier, we still have some client that need implementation, and then you can, if you're a dApp developer, you can deploy to, you can deploy to a family test net on your dApp and run a test and see how it goes, and if you run node, you can also run, sorry, if you run infrastructure, you can run an infrastructure, and if you have any idea or whatever, you can communicate with us to learn more. Okay, so about this, so there's currently an incentivization program on eFemery that gives you an opportunity to contribute and also get incentivized for it. So, okay, let me not be fast to remove it. So in case you want to scan it, you can quickly scan it before I remove the slide.

All right. So, yeah, so this is like summary of the work that has been done and what is yet to be done in terms of client implementation. So that's for EL clients, and then this is also for the CL clients. And for resources, if you want to learn more about Ephemery, you can check Ephemery.dev.

And to join the community, you can check the Ephemery Metrics community. Thank you very much. All right. Thank you, Glory. Any questions for Glory about her work on the Ephemery testnet implementations?

I wonder, is it something different to become a ephemer-e validator? No, no, it's not. The same way you are validator for that network, you can do the same for ephemer validator? No, no, it's not. The same way you are validator for that network, you can do the same for ephemer.

So you still need 32Es? So I didn't get asked. You still need 32Es? Ephemer, yes. Oh, okay.

Anyone else? Yeah, not really a question, just a comment. Like, a huge thank you. I mean, many, many thanks for all your work on ephemera. Like, it's an incredible job what you've done, implementing it and fully merging it and have it usable in both clients.

It's incredible. Thank you so much for mentioning all the resources, the incentivization program. And, yeah, like, anybody can run a validator because being reset every month, resources, the incentivization program. And yeah, like anybody can run a validator because being reset every month, FMRI has infinite ETH for you, so you can just run as many validators as possible, maybe even more than mainnet at one point. But yeah, thank you so much, Glory.

FMRI was created basically at DEF CON two years ago, and now after two years, it's amazing to see such an amazing job being done on the network. So yeah,