Lightning Talk: Expanding Ethereum’s Proving Landscape with Ethrex by Leandro Ferrigno, LambdaClass

Transcript

expanding Ethereum's uh proving landscape with ethics. So, Leandro Verno from also from Lambda class aligned. Okay. Hello. Thank you. Thank you for having me here. Well, the idea for this uh talk is to well talk a little bit about the and the idea that we have of expanding the the proven landscape with with another client. If we take a look in the execution client landscape, there are the diversity is quite good. There are many great clients but when we start looking into the proving side of things

most of the teams are most of the team here uses like just one only client getting aside Cync that uses their own like OS. So I I wanted to bring here which is uh the execution client that we have been working over the last year. Mostly well one thing is that we love Rust but besides loving Rust we have been working in this field for many years and we realized that code bases were quite complex and we have been always talking with different teams struggling with complex code bases. Uh so we decided to okay why not building a new one when why not add

some new piece of software to this to the to this like field uh and that's when we came up with withdrex the idea that it should have minimal dependencies uh much much less lines of codes we shouldn't have like clever abstractions all over the place and we should have concurrency only where needed and and I guess at this last this last point is quite essential for for proving uh and while talking about this ecosystem explicitly I've been hearing I've been hearing today that most of you see execution as latency uh that's weird for us but you see us as latency and well I think that uh with this code that

we have there is a great room for improvements and we will be able to gain much more o over this latency that you see is uh we have a share code the L1 and the secret roll app that we're building because it is both for DL1 and and C rollups so we don't have a duplicated code and we ensure consistency everything that we that we do is consistent with CK uh also we have been building this Ethereum reexecution tooling enable to enabling us to execute and prove Ethereum blocks in different CKVNs easily like a separate repo. I will show later a QR.

So for everyone like we are we are already integrated with re zero SP1 and CISK and we have been working with with Rev with Pico from Revis and with OpenBM for a while to to include us but right now this is like our repo and it should be very simple to have your own guest program in this explorment. We just need to handle the stateless execution for any CKVM that that we want and it should be pretty easy actually with CISK. We just did it in this last two couple of days working directly with them and it was super easy to to integrate and exclusively talking about minimalism.

We really enjoy uh showing this this small graph like okay we are one/ird of lines of code and other clients and well this is uh for us something that we celebrate a lot and and we're always taking care of it should be easy to change it should be easy to improve. Also we have less than half of dependencies. It's not easy to compare dependencies, but with with clients built in the same programming languages, we are above half of of the dependencies than than they have. And some performance, you won't be much interested looking into those these numbers here in the proving land landscape.

But what I wanted to show is that we're working a lot with performance. What you see here on the on your left uh is all the achievement that we have done over the last month. We did a 10x on the last month on the gigas uh by block and well block time reduce by 10x. Uh this is quite amazing amazing. These are not very good CPUs. With better CPUs we have a better performance of course. Uh and we still have a lot of improvement to be done. We're working that and we are confident that we can achieve much more performance and not only with this but

also we like adapting the guest programs for the the different CKBMS that that that you have. These are the numbers that we have and that we have recently uh incorporated with the 16 team. And here you can see like for example for SP1 turbo we are like in from two to 12 minutes that that's a lot that's obvious obviously not real time but well yesterday and the day before yesterday but with the help of CIS that um share with us the their their multiple GPU thing uh their their GPU farm with 1690.

Well, we achieve proving some blocks in the range between six second to 15 seconds and this is with what we have at the moment. We haven't done anything in particular uh to adapt or to improve. So this is like the starting point and I think that as a starting point is a very exciting starting point and well what I'm asking here we would love to work with with all of the people that are in the room. It's very exciting for us. We have done a few collaborations as well with different teams with the for the team foundation and the CKBn team.

We help them integrate EDRex in their CKBM and we're very grateful with that uh because well that that give us also a place where we can show what we have been doing uh and we are reviewing their standard their standardization proposals for different CKBMs and that that is a great effort not easy to be done and well I think that they are doing a great job over there and we are eager to help them. uh and the idea is for us to become fully compatible with array which is like the this effort of unifying the interface written in Rust.

Our future work on this as I said this is just the starting point. We need to lower our proving times with a single CPU. Those are not great. We have there with 60 33 second or 60 seconds for for 2 minutes for SP1. We need to lower those numbers but we also need to work in multip proving also pipelining execution to reduce latency. We need to integrate and we want to integrate with more CKBMS and well we we want to work on the integration with as an alternative for forex and this replay which is this this which is this execution uh tool in that dimension.

This is a link to the repo but if you cannot scan the QR if you want you can just look for ether replay in in lambda class repositories. Um well I think I'm just on time. Uh this is us if you want to follow us or give us some love in in inreo. Uh we'll be around we have been around all this week here but we are pretty easy to find. uh and we will love you to reach us out and or or to answer when we reach you out uh for for integrating with with index. Okay, thanks.

>> Thanks so much, Landrew. Uh we've got time for uh one question if you're open to it. So, >> uh are you looking into doing ZKVM specific optimizations other than using pre-ompiles like using hints or ZK friendly hashmaps? >> Yeah. Yeah, that that's a possibility that we are exploring actually. Uh it's something that it will be great to discuss with the specific teams working in CKBMs, but yeah, definitely it's it's something to explore. And then uh a final question, how many of your per how much of your performance optimizations are due to SIMD instructions and other CISK and GPU optimizations that aren't available in risk five risk 5 as a

>> okay to be honest I don't have the answer for that uh but we can discuss later with the team all the CIS integrations has been done in the last two days that I've been like >> all around the place and without what my team did. >> Okay. But happy to continue later. >> Okay. Thank you very much. >> Thank you.