Ethrex: A Modular Ethereum Execution Client for L1 and L2 - Leandro Ferrigno - LambdaClass

Transcript

Hey, well uh first thank you all for being here and thanks for the invite um for Idris especially because okay this is like the our first time here. Uh it's it's not the first time that we presented but I think that it's the first time that we are doing an introduction for okay for for the rest of the builders. So I'm I'm pretty excited. Um, also I'm pretty much excited because well we are Argentinians and dev connect happening here is like a huge challenge and it was a great source of energy for like this last few months because we had to have this client in a good shape. We we had to make it. So I hope

it's in a good shape. Um, and well, if you ever doubt who is the Argentinian team, you just have to look to Digos Maradona's references or or any Argentinian references. So that that's usually we do that a lot. Um, well, and just to be just to begin, I'm Leandro. I'm the head of engineering at Landlass. I will show you. It will be kind of a an overview of the project. So it won't have much technical detail for you that are the builders. But I will try to explain a little bit on why why we did this, why we did this and what inspired

us into doing this. Uh I think that well the first thing I want to mention we are here because the rest of you right it's pretty easy for us to be here and to be working in a new execution client uh like 10 years after Ethereum began. So we are here because of you. So it most of the the people that are here uh worked on in code bases that we have been looking into uh and most of things are are actually really great but well as we are have been working as well building infra from different rollups many L2s uh building also some infra for some of of the clients here also working in in

different L1s um over the time we were realizing like okay this and well we love Rust we actually work in Rust a lot is a Rust execution client we we realized that okay this code base that we're working with are quite complex are more complex that we would want it to be right and we start playing around a little bit okay let's try to figure out what this would be like if we have developed that and well we were thinking about Okay, we need to have something more minimal.

Everything should be vertically integrated. As I was mentioning, we have been working with many L2s. So, we should have like the L2 and the L1 part like sharing also some code base. Uh and this will make for everyone a much more easier uh way to to on board into Ethereum, right? Uh so that those are are basically our like like goals and well here it says exe infrastructure we would have wish we had when we started right and this is not because the rest isn't good enough I think that Ethereum had had evolved very very quickly especially over the last years and and well as I said it's easier for

us to be like okay we didn't have to deal with the mar for example So now a codebase can be much more simple that that the code used to be and as I said we we love rust and we want rust but in a simpler way we should have an effortless setup and execution. It should be very easy to okay you download a binary and you just run it. We shouldn't have much dependencies. I will show some some graph later around dependencies and lines of code. uh well this is wrong uh but it's an old slide I won't talk about type systems but we shouldn't have much uh too many abstractions it

you we don't need to like do um optimizations beforehand I will show you later how we deal with performance but actually we we never care about performance until last month right and Um and and we have been working on this like over a year and after that we had we had everything working and we we we said okay how fast are we and we were like 20 megabytes 20 megabytes throughput that was terrible and but in just a couple of weeks we went from 20 to 250. So we're confident we can work with performance in a later stage and we

are doing that. we don't need premature optimizations. Um we should deal with concurrency only when needed. And this is also the the the way we work in the way we try to work in every project because concurrency might be complex. MA most of the improvements uh related to performance has have to do with concurrency uh but we added in a later stage. This is um well here less than half of dependencies. It's not easy to compare dependencies against code bases in in different programming language. It's not easy to compare lines of codes either with with code bases in different programming

languages. But compared with similar programming languages, we have half of dependencies than than other projects. And comparing lines of code with a few of of the other clients, we are one/ird away just with the other one. uh we are one/ird of lines of code of the the rest of the clients and even when the L2 is just like 15,000 lines of code of code more. So this is what we're trying to do. We check this every day. This is what we have been trying to do all the time. We think that both things here are big surface of attacks and and we are trying okay to to deal with this at every day.

Also what we're trying to do is to keep it simple in the sense okay I should look at code and understand how Ethereum works. We were builders of infra for different Ethereum projects and every time we we had to deal with with parts of execution clients realize okay I don't understand this it's very hard to understand well someone mentioned about researchers there are things that look like written for and by researchers and and that can be complicated when you're trying to have engineers like working in that code base. So it should be simple. You just have had to have some small crates. You

should have had to have an architecture that explain how it works. Okay, I have something in common the try RLP type sketch that interacts. You had a store, you had the networking, you had the VM and that's it. Also, what we're trying to do here is have some modularism. The VM should be able to change the storage. The storage should be able to change uh whatever part that might be. Okay, I want to change this dependency by this other one or I want to tweak a little bit this. You should be able to do it with the codebase.

Uh I'm saying all this but this is not fully done yet. There are many things here that are a mess. For example, for example, the whole P2P RPC thing, we want to rewrite that fully. Uh it's not that we are absolutely proud of what we built. It's not that we say okay we are the best ones but we know we had to work on that. Uh and we will rewrite any part that we need to the idea is we what we want to do is be vertically integrated. We want to have the the same team building the EVM the L1 the all the L2 components that are needed

to ship fast. Basically uh benefits here is is like marketing thing but is is to ship fast reduce at the cost surface and ship fast. We started this project in mid 2024. We had more than 70 engineers working on this. Uh hopefully we will have less less in in the next month because 70 is like a lot. It's not that there are 70 active now but we have more than 70 working over the the whole year. uh now we have like I think 30 people working and most of them in performance uh and we're already using it actively in many partners and well well we're very happy because everyone collaborated

much uh with us and we find people that were very excited about it showing up in in the in the scenario. So um it's already been used Um I want to show you a little bit about performance and what we have achieved uh and what we were ashamed of and now we don't we were focusing mostly on chicas per second uh as we started we had a hash hashb try now we then we moved to path base now to snapshot which is similar to the flat that bas mentioned our flat key values of and we store the flers uh and also we

have been dealing with reducing the this growth uh and to enhance rights and and reads from the from the storage. This is basically what we have been doing over the last month. We started kind of like this. This is Gagas. I think that you can see this. This was the first version of Idrix. It was around 20 when we added pathways. We were below here before. or I don't have the the graphics for that but we went 2x when we put snap point put path base then we did 2x this is a 2x it doesn't look like it but it 2x

uh when we went to the flat key value store and all this from here to here we're basically adding concurrency in different parts of the of the client mostly like pipelining the merchalization uh dealing with rightes in the background when when we're we are able to and tricking some dependencies uh and while moving parts of the code to to to make it fast uh and well this is pretty similar the the block time is like the the inverse graphic this was very slow and now we are like more stable in in something

that is actually usable about CPU optimization. Uh here I'm not comparing with with others but we are we are around 240. Now this is an old picture. We're moving fast every day. Now we are almost at 240 megas and that is kind of similar to to other clients. There are many of you that that are much more faster and okay our goal is to be as fast as as we can as we can. Um well here I'm showing something about CPU optimization here as well. what we were about uh this was the former versions now we are over here about 5% CPU optimiz CPU

utilization and about uh memory uh now you are able to run with 32 GB which is I think something acceptable as well uh we have been doing some tests with people using orange pie and and it's working well one of the things I'm not mentioning I mean when I say we're moving fast is we're ra breaking everything every day. We're still in in a phase where we do breaking changes from version to version and and it will be like this for for a few more weeks. I expect not much uh time but for a few more weeks we will be continue breaking

everything. Erh feedback is is more than welcome and and and we will try to do erh we accept our our mistakes and and if we break something the first things the first ones that will be like accepting that we're breaking things are us because of of this is because of this is that we were not able to be like actively participating in Fusaka devets We didn't want to bother anyone but we we already are up to Fusaka being run on mainet all the changes all the the fork in

hoodie work great the fork inia work great we're ready for mainet and I hope that for glamsterdam we are in a better shape to start like collaborating more in in the daily basis as the rest of the projects we really appreciate all the work being done by it if panda all the work being done by how all the work being done by by different teams building tests and sharing those tests. Uh we we have dashboards. I would have if I have a computer I would have shown a few dashboards that we have where we're we're using the same tools that you are using and and benchmarking everything with that and well about at the size we are about 500 gigabytes uh

top then for for syncing wireless snaps syncing we have some bump up up to 500 then we have compaction uh and steadily we have for mainet like 350 gigabytes more or less more or less and well we have observability for everything most inspired by by any of you you know what it is but we have RPC observability we have observability for for CPU uh memory and and everything and what we have as well that I'm not showing is for everyone every branch that we are working with we have like this and and um comparisons between this for every branch in a in a unified

dashboard that is very useful to to see if any of the changes that we're working on might be uh bad for performance. I had a demo but I had no computer so no demo but the demo basically would have shown how we install and how how we run a few things and and show you a little bit more about the the graphics. Erh and well this is over. We need more throughput. We need to clean up some code because we like what we did but it's not great. Uh there are many things that need to be removed. We need to document bunch more. We need to add more more tooling. We need to rewrite

concurrency part and we need to add more profiling. Uh we know that we need to improve a lot. uh but this is already working and we're very happy about that. Uh and well feedback from operators, feedback from other clients is more than welcome. More than welcome. Now a little bit this is not an L2 uh meeting but I hope you don't mind. H I will go quickly over this uh I don't know how much time do I have four minutes. Perfect.

But we have the L2 in the same code base as than the L1. And this allowed us to do some I think uh some good things. Uh the EVM is equivalent directly. We are adding multipro support and having like the proving part in also in the L1. Well, I I think that we are in a good position to start working with some Ethereum initiatives such as native rollups and and looking forward into the lean Ethereum thing. I think that we this will be like a a good starting point. Uh we have to prove our different CKVMs. We have SP1, we have re zero, we're integrating CISK, we will be

integrating uh Pico OpenBM. The idea is to have each each of each one of them working sharebridge the idea and and and base shar is like one step before but it's not a step before but it's one more thing into okay we want base rollups we are we are pushing base rollup to happen so shbridge and and and a few other things that we have here uh had to do with that Um we're powering base rollup stacks. We're working with fabric people. We are working in a few things with the native

roll apps enjoyers and and so on collaborating with different Ethereum initiatives. Um we have private validiums and this is not important for the for L1 but we're ready to collaborate with in line other features that we were adding uh this is uh an old this slide I changed that but we added some path to accountraction we had a few EIPs for accountraction as well already um and well for base roll up we have um Bessu he just mentioned about this uh follower nodes and and so we have some things not

not the same thing but similar things thought for for the base roll up thing and decentralizing the the sequencing of the L2s and basically like uh leaving the responsibility of the L2 to the L1 because the L1 should be the one like uh doing all the all the sequencing and and giving the the trust and and the anti censorship feature. The L2 runs like this. If I had my computer, I will do is XL2.dev and you will see a a cool dashboard here showing everything.

But moving on, this again for the L1 and the L2, we are we need to start working in Amsterdam. We want to be more open in every I'm sorry for you but we will be more open in in every ACD call and and dealing with it panda about the devets. We want to be collaborating there. We we want to participate there. It's very important. Uh we will be adding more support for CK EVMS. We will continue working in performance. We will improve our servability and we will be adding more production deployments and feedback. We will start

doing audits for all the code. It's not here but we are we already have its setup because are important. Um um well I think this is basically it it this is us. Uh you have our socials there. We have most we are mostly using the telegram for sharing things. We are also in some discord for it if it st we are we are there as well but most of our communication goes through the telegram we had the repo you can send the star if if you like and you can you can criticize us uh and we will be very recept receptive with that and we will try to do the best with that feedback. Um well, thank you.

[applause] >> Excellent. I think we're are going to have a uh just a short opportunity for maybe the top two questions uh that were asked in the Mircat app here. Um Leandro, if I have you stand there in the center for the way the camera can get you there. What is the expected Oh, excuse me here. Hang on one second here. >> This is not us. >> Yeah, I gota I gota answer I got to flip it over. Uh the top question is um can you stay synced or stay at the head of mainet?

>> Yeah. Yeah, definitely. Yeah. Yeah. We we're doing a snap syncing. I think we're snap syncing in three hours. Erh then it's like a a few hours more until the the flat key values are all in use but after 50 hours you have mainet sync and you are following the the chain. Yeah. And then uh how many of the dedicated team members uh among the 70 plus contributors >> dedicated? Right now I think we have 30 and something >> 13 >> for the whole like the EVM L1 L2 and different things. DL2 has many many parts. I think for the L1 we have

15 or something like that now. >> Okay. And then uh have you used any of the other clients as a reference to implement Erex? >> All of them. Okay. >> Yeah. Yeah. This wouldn't be here if the other ones don't exist. We we are very open into that as well. We added references in the documentation. You will find references even in the code. Okay. This this comes from this repo. Thanks G for this. Uh you will find that our bench also are bench from Netherman from G. Um and we also are like mentioning everyone of course that the one that we look the more are the one maybe maybe the ones built in in Go or Rust uh because but

but we are pretty there are projects built with with things like Java or or C C sharp that we are amazed by the performance they have with with coming from Rust is is amazing the performance that they have. So we will be looking into into that as well. >> Excellent. >> And feel free to look into our code. So >> excellent. Well, again, another round of applause for Leandra here. [applause]