EVMMAX Implementers Call #4

Transcript

Welcome to uh EVMX implementers call number four. Um and today on the agenda is basically the client updates and uh open questions uh plus the previous task list that we had from implementers call number three. Uh so let's get started with the uh client updates. Is radic here? Uh radic do you want to start? Yeah. So, so regarding some additional use cases of using EVM max in uh in EVM1. So, uh recently I started working on the implementation of u some

algorithm to um which is the signature verification uh from from the ZK Knox ZKOX team. they have some implementation in the in solidity and I started implementing their um their primitives in uh in EVM max and and today or yesterday I was able to finish the first primitive it wasn't simple recently because I was also kind of um kind of busy with u with u with uf arguing uh UF arguing uh topic but but finally I

implemented this and the results are kind of promising. I shared already them on with the ZK ZK no people on telegram channel. So it looks that like um I need to confirm but basically basically it looks like we are able to um to compute the same algorithm uh which in uh plain solid sorry not plain solid but uh using inline inlay assembly solidity uh it costs like 2 million gas we are able to implement this like uh less than 5 50k uh,000 gas but uh the proper the final results and everything with the code

size and gas cost and also also CPU time benchmarking I will be sharing probably early next week um together with this Poseidon results uh I shared earlier uh so I will share a link but yeah so that's what I what I did recently regarding uh regarding EVM max yeah yeah that's super cool so it's basically um about a 40 40x improvement. Um and this is also assuming the gas pricing uh model is sort of overestimating the cost of EVM max. I mean we don't know cuz we haven't checked but it seems like it's

over yeah priced. So now now I I just convert everything to to integers of the size of 256 bits which is very unefficient. uh but I will prepare the version with and but because this modus for the sorry for the for this exact signature is like two bytes um uh but uh but internally it's represented in VM1 as as 256 bits but it's a very easy change to to to apply which will just use at least 64 bits integers which should be much faster already. Um and of course this implementation still doesn't

use um still doesn't use the um um this SIMD instruction uh or processor instructions uh instruction set. So um so it's also should so but but it it this is more related to basically this to the CPU um CPU time not the the gas cost of course but but um based basing on uh on the on the CPU time spent on this computation we will be able also to adjust the uh the gas model for this kind of small uh integers. Uh so yeah so it should be it should be it should be even better than

than this but we'll see we'll see. So basically uh I need more time to to implement uh the rest of two very simple primitives and uh and then prepare proper benchmarks and uh and uh and change a little bit the AVM1 implementation for small numbers. Yeah, this is great. Yeah. Yeah. And thank you for sharing that as well. Yeah. Um, cool. Uh, do any other clients want to give an update or just anyone in general?

Looks like everybody is preparing now for the AC call. Okay, that's fair enough. On that topic, would we want to say that VMAX is relying on UF for the gains that we have just heard? So I assume that for an a version of VVM Max without the immediates that would not be 50k but 50k gas but like what? Yeah. So so couple 100k gas probably. I would like to Mhm. Honestly to to be absolutely sure about the gains between the version of uh of the which which utilizes stack

um EVM stack a lot and and between the version of uh of EVMax with immediate arguments which um which requires which requires EF at least in opinion of of most of of all the of the team members but not uh so so basically I will if if it depends on the on the on the on the result of the today's discussion on ACD but uh if we will end up with in not our favorite scenario that for example if EF is rejected or or or or something like this so basically

basically immediate arguments introduction and introduction and instruction with immediate arguments will be very difficult ult in our opinion to not because of the technical problems but because of the security reasons and pushing this this kind of EIP through the uh through the ACD process. Uh so um so basically I will prepare the also the benchmarks and the version with uh with u um with with stack uh with basically with arguments to the instruction taken from the stack and we can compare it.

But uh from my experience uh it looks like we have uh most of the efficiency gains from uh avoiding using stack operations stack related operations and uh yeah but but I need I need proper proper benchmarks. Yeah, but but I mean like roughly mentioned that that that that there is a big chance that that EVM max um will be so unefficient that it will be that it will be basically useless.

I mean but roughly you would need seven sorry seven pushes for every arithmetic operation correct because there's yeah yeah you can also you can also try to do some duplication dupes or any other or swaps yeah but yeah basically basically in worst case you right right seven push one streaming op codes but they are all at least at the moment they are they all cost free I think so.

Yes. So, so I mean 21 gas versus whatever EVM max charges is probably a big uh a big change. Yeah. Yeah. Definitely. Especially for small for small integers where the cost of the multiplication of the sing small integer the theized cost of the of the multiplication of single small integer is um much less than one basically. So yeah yes I mean cost per mole is up to 12. So that's much less than 21 per vector mole of course. So it depends how big is the vector but basically Yeah.

Yeah. Yeah. That's that will be the the the the overhead on the instruction. So be huge. Okay. Good. Will be huge comparing to comparing to to the to the cost of the of the instruction itself. Yep. Thanks. Cool. Um okay. So, I guess the one thing we can get to next is just uh the to-dos from last uh the last time and just see how they're going. Uh the first one was implementing the inversion up code. Um did we get to that or are we just are we pushing it back? No, no, we we we didn't I I didn't have time to to

to add this uh this PR to this uh to EIP, but I will actually I was focused on this uh on this on this benchmarks and implementation and didn't have time and other things and didn't have time to to go through the to-do list actually. Okay. Yeah, that makes sense. Uh okay, I'll say the other to do and I guess it's also not done and we can just push it uh uh back after you have like the Falcon benchmarks. The other one was to collect numbers using SIMD for Prooidon. Um haven't done.

Okay, this makes sense. And then there was one by Powell but it seemed to be optional which is like can we replace the pre-ompiles? Um, Pow was not on the call, so I'm going to guess this. Uh, as Pavo also was kind of busy with different different stuff recently, so he didn't have time, but maybe maybe Yeah, I I cannot ask ask him personally about an update and he if any he will share only BMB channel, right? Okay, that makes sense. Uh and the other one uh which was to just ask the L2s uh sort of what algorithms they'd like to see. Uh from the people that I've sort of surveyed,

it's basically um just starks that they mostly care about, but I haven't sort of asked the optimistic rollups. I can also ask them to see if maybe something would help them. Um yeah, and those are all of the to-dos. on here. Well, actually I did say ZKL2s, but I think yeah, be good to ask the optimistic uh rollups as well to see what they think. Cool. Uh yeah, so we can go to the open questions part if anyone has any sort of open questions at the moment.

Um, I guess one meta question I I have is, uh, is this still on track to be put into Glamsterdam? Is that still what people want? I don't know that we could answer that today, but I think we do. Yeah. Yeah. I Yeah, I'm I'm I'm still in favor to adding this in uh in in Glamster, but yeah. I think what's needed is a lock in spec. Go ahead. Sorry. No, no, no. I'm finished. I think what is needed is a barely locked in spec by the time Fusaka goes live on mainet um for us to be in Glamsterdam. That's I think what we

should focus pushing towards is getting the spec down rather than getting a reasonable implementation at least one client. Um I don't know how completely we need to be across multiple clients. Yeah, I we don't even know the glam damn timing either. So yeah, exactly. Uh I have als I have also will be sharing some um uh some some feedback outcome from the from the from this um this signature name. I always forgot forgot what's the name it was. Fal Falcon 512. Oh, sorry. Yeah. Yeah. I I

wanted to use this. I I remember that I have to somehow it's somehow related with with Star Wars. Uh doesn't matter. Okay. So basically uh basically uh basically I have also some uh feedback from from this process of implementing this and uh it looks like probably some instructions which do some kind of shuffling on the on the registers would be very useful here. Now I just use uh to shuffle shuffle the the the input from from from the loaded from from memory. I just used uh admodex uh instruction with uh with one argument

being zero and uh and but some kind of shuffling instruction probably similar to the to the SIMD instruction shuffling uh or maybe some simpler one simpler ones would be would be good to have but yeah I will have some some um better feedback um when it everything will be implemented. and and published. So, yeah. Okay, cool. Yeah, I mean, I don't know about adding just shuffle in. It seems like we're partially uh moving down to sort of the SIMD API. Uh so, yeah, maybe it's possible. Uh be good to see once the report is um made. Um, in terms of having it done in

one client, do people have a preference for like the first primary client that just shows um, EVM Max? I think because we have some already uh, implemented version in GF, maybe GF will be a good option to start with, but okay, that makes sense. So, Gaff um yeah, so we probably need to assign resources for someone to uh work on the Gaff implementation. We can do that off uh off offline.

Cool. Um yeah, any other questions people want to discuss? Uh if not, we can keep it short cuz I know that yeah, the the uh ACD is probably going to be a bit um uh yeah, interesting uh today for people in this call. Um okay, cool. Um yeah, if there's nothing else, then we can just end it early. Um yeah, thanks for coming, guys.