EVMMAX Implementers Call #5

Transcript

Welcome to EVM uh Max implementers call number five. Um just to start off, could we get some updates from uh the client devs and probably Radic? Uh maybe Radic, do you want to go first? Yeah, sure. So, uh so I made uh um not sure if I was I've been talking about it about it last time, but probably not. Uh so so I made a benchmarks for for more different uh different uh also benchmark for for falcon post for for falcon signature primitive and um I'm showing this now in chat. Uh yeah. So so

basically um basically it looks very very good comparing to what they have implemented in uh in solidity in legacy VM. Uh but you can you can look at numbers and uh and and uh also uh comment on this. Um basically basically I used also for this primitive and for implementation because basically this primitive um works on on a small field. So so it's like two two bytes of uh for each value and uh and I was able to thanks to this I was able to use some library which

which utilize already uh the SMD instructions. uh so I didn't have to basically change so much just use the library to compute the uh vector values um and implement basically basically uh EVM max up codes in EVM1 and it looks very promising uh at the moment uh yeah so so that's that's one thing uh another thing is that uh I also changed a little bit the the spec maybe not the spec in in in in the in in in the in the EIP but but uh I decided that for some small smaller fields with the

Montgomery representation will not be used just the regular rep uh imple representation. So, so it also uh it also speed up a lot the the algorithm basically and uh yeah. So, so but I will also push the PR and the next thing I would like to do is just to push the PR to the to the EIP changing the changing the spec regarding the gas model for for smaller uh fields and smaller values and uh and add assumption about the Montgomery representation. So the threshold when the when the Montgomery representation is is used and uh and uh

also add this um still um additional uh instruction for for inversion in in both cases. So so yeah so I will push the PR PR or PRs with all these changes to the IP as the next thing I would like to do um regarding TVM max. Okay. Um I guess two questions. Uh Freddy inversion has it been implemented in EVM1 and it's just the EIP? Yeah, I implemented this but only for because that was one case I needed till now. So I implemented this for u for power of two modulus which is quite easy and fast

but uh but of course I will also implement this for for for odd modules. Okay. And yeah because at this for power of two I needed this to implement this mod x modx per compile. Mhm. Um and the second question is related to the link that you sent for the PR. So uh we have Falcon which is a signature scheme and the most expensive sort of function in Falcon is this thing called an FFT and the benchmarks that you've shown uh are for the FFT function FFT. Uh yeah this this uh entity FV whatever whatever

it is. Uh and what was the speed up that you got versus solidity for this FFT or NT? So as far as I remember from the chat I think that the the basic cost of this function in gas was about 1 million something like that. So that's the level of uh of uh uh of complexity and uh here we are possible it's possible to calculate in in like 5,000 5,000 gas.

Okay. Nice. So, it's like 20 20 times. Yeah. 20 times. Yeah. Or uh Yeah, it was 1 million to to five five,000 basically. Yeah. So, it's like a 200x 200x. Sorry, 200x. Okay, that sounds great. Um, cool. Yeah, I guess when the PR is uh made then either me or maybe someone else on the call can just review it quickly to put in Mark. Yeah. Um just a quick question about this. So what is this the gas reduction for just the Poseidon hash? Um because just looking at the PR like I see number one like the number four um I think these

are with and without EVM max and doesn't seem as a big gas cost reduction but maybe I'm misreading it. No no no they are all they are all different versions of EVM Max. Oh okay I see. So sorry what what is it without this one? This one, this first one for Poseidon, as far as I remember, is the legacy legacy EVM with introduced EVM Max OP codes, but we already know that it's kind of unsafe and probably this this solution for EVM Max will not be accepted for for by ACD. But I just implemented this to to make the comparison. And uh the second one we and and and this is so the third one and uh

and the first one is the legacy and the second and the fourth is the the eof uh version and uh with vectorized on or non vector version of EVM max. So yeah and but that's a good question that we should also compare this to the solidity imple solidity implementation. The comparison is somewhat but it was some time ago and I forgot uh this but it was also u more than oh yeah this is here so so I will send you link also what was the cost for poson in solidity in solidity was

about more than 100 100,000 gas or ident free uh version was like free for 32,000. Yeah. Okay. Thank you. Yeah, that makes sense. It's a much bigger reduction. Yeah. So, actually actually this this this this uh Falcon Signature Primitive uh um is is the case with the Fal Falcon Falcon Falcon signature primitive looks much better. But also for Porc it's really it looks really good. But yeah, right. Yeah. Thanks,

Radic. Um, does anyone else want to give any um updates or Yeah. Yeah, I can uh give a quick update with Ethereum JS's implementation so far. Um, so the op codes are implemented. Um, I've ported over pretty much all the tests that I could find from the uh EVM1 branches uh for EVM Max. Um, so those are more or less complete. Just kind of some final debugging. Uh, should be done by the end of the week. Um, and should be able to commit to

some new uh follow-up action items for the next time we meet. So, Yeah, sounds great. Um, and are you having any issues? Um, uh, no, no issues. Um, yeah, no, no issues. I I'll I'll just uh update in the uh EVM Max channel um if I if I have any questions because I do uh for example I'm I'm I don't think the gas uh like the gas functions are are I wasn't able to find any tests that were really testing the gas

functions um or like how much gas would be spent uh you know depending on what op codes are being executed. I don't know if I just missed those or if those are um not out yet, but um yeah, just finding uh you know, finding out if if work's already been done that I can port over or um if I should uh find ways to test those and and to uh you know, validate those. So, yeah, I think the gas numbers are currently a bit still tentative. I mean, we have numbers there, but I think they're subject to changing.

Um yeah, makes sense. Um any other updates from people? Uh if no updates, any questions that people have? Um maybe regard still regarding the Amsterdam sort of goal. Um any sub goals that people think that we should still have? Um yeah, just anything. If not, um any new items that we may be missing uh in that case then I think the sub goal that or at least yeah the sub goal

that we should be aiming for is to have something to give to the L2s to get meaningful feedback. Um I think do I know it might have been I don't know if it was recording then but uh before the call started you had some thoughts about EVMax going into Amsterdam. Yeah. Um some of the other teams have been tasked by to determine recommendations for what should go into Glamsterdam and uh Bogota. A lot of their plans are focusing around immediate L1 scaling needs. Whatever is needed to increase the gas limit um and whatever is needed to increase the lob count are what's going in and they

really want to try and keep Glamsterdam as small as possible. Uh there's an EVM resource pricing working group. They want to get some of those features in um on the premise it's going to scale L1. Um, right now those plans don't improve EVM max because I don't think they've received any information on how that's going to help scale L1. They haven't received any um any feedback from any L2 saying we need this for our hash function. Um, people have stopped pushing for things like Poseidon pre-ompile. Falcon is over the horizon um because postquantum um really doesn't help the L1 scale. So since since Poseidon and Falcon are the two biggest use cases for EVM Max um that is by default pulling it out of

Glamster because it's not they're trying to keep it as small as possible. Um so that being said um you know for EVM Max to get into a fork in the near future it's going to take um a very you know it's going to take a specific youth case saying we need this to ship our feature we can't do it without it. Um and you know efficient besidon hashing might be one of them. Um so that's what would be needed. Um my take you know don't don't take my word for it. You whoever's going to champion us and get us into it should make their own call their own decision and read uh what what's going on with it. But my take is it's going to need um someone saying this is essential for us bringing our L2 or some other application to L1

because um the existing math oper operations just are not sufficient for L1 and without it we're going to have to do something like go to stylus. Um those are that's what would be needed I think to to uh to change minds to get it into Glamsterdam. Um but another place this could be positioned is that um before we do any pre-ompiles we do EVM max any new crypto pre-ompiles and I think that's also another place where there's going to be a lot of um support um because every time there's a crypto pre-ompile there's always a rash of issues with the choice of library um and you know lots of arguing over well we need it to mean this and that like went on with a lot of

uh the BLS pre-ompiles you know do we do we do the curve check or do we not do the curve we do the curve check in this and arguing about the particulars of how it's being used. Um, with EVMX, the answer there is just to say, hey, go write your own contract. The only thing that the core has to worry about is basic math, not cryptography. It doesn't matter. We're not cryptographers because we're not doing cryptography. Um, that's the space I think where EVMX would shine. Um, and um, EVMX was there to say, "Hey, it's finished. It's ready. It's speced out. um we should do EVVMAX with this uh with this code representing Poseidon instead of bringing in a Poseidon pre-ompile. That I think um is where um EVMAX is going to get the support of going into a fork. But that's

you know kind of reading the room on uh the social media and the planning circles and um a lot of the the talk going on. Um, scaling L1 is the the the northst star beyond blobs and it would need to fit in that that that uh the story would need to fit that um it need to fit that story if it's going to go in. So that's that's what I would think um some of the some of the situation with uh getting things into mainet right now is. But that being said, if we just put it to the side and ignore it and come back when someone walks the side and we're not going to be able to spin up unless we finish the research, finish a spec and get sample contracts written down and say this is

what the side looks like. That's that's where things would need to be. Um or we need to continue working on it the whole time until it's it's out there. Those are I think where where the uh where EV EMAX would need to go to make sure um that it is useful um when it comes time for something like EDMax to be put forward. Right. And I guess I have some followup questions. Um the first one is on the pre-ompiles. Uh that argument seems like it's um only convincing if we have a bunch of pre-ompiles to implement. I guess just one more none of Amsterdam right now.

Right. Right. And um I guess my second question is how um convinced are people that sort of EVM max is what's needed for the let's say like L2s like are people convinced without even before going to the L2s or are people in the mind frame that we want to implement this thing and we want to go to the L2s and check if it's actually usable like what where where do people fall on this um spectrum. Is the question uh well defined?

I I'm not sure if it's well defined actually. Um I'm trying to figure out what are people's current thoughts on EVM Max. Is it that we're implementing it and we're trying to investigate whether it's useful for L2s or is it that uh we're implementing it and we know that it's useful for these particular use cases already. Um I would say that it's half half now. So we we we know that that it's useful for a couple of use cases we did but uh but also we need some some valuable feedback from from L2s we don't have yet I believe or we don't have uh enough

feedback right and I guess what if the L2 say we don't need this uh what would be the next steps for this It's probably not needed. Yeah. So, we already know that that at least from from some people uh like for ZK Nox project they already find it uh useful and they will be uh they will be supporting this. But uh I think think we need more uh more more valuable players on board uh of supporting this uh this project, right?

That makes sense. Makes sense. Um and I guess to Dan's point on the pre-ompiles, this doesn't scale L1 directly. It just basically scales the shipping in velocity of L1 which is a bit uh different but I also think it's valuable uh versus like Prooseidon which does scale the well that we think scales the L1 directly and that's the thing is it's it's a lot of semantics and it's part of the ACD process. Um I mean a lot of these discussions really haven't gone to ACD yet and um that's you know will ACD accept the premise or not is is the big question about you know how how what scales L1

and what does not. Um but as I said in chat, you know, if we had something like ZK Knox saying we need EVMX to do what we are doing efficiently, um that's the sort of of compelling argument that would be needed to get it in um within the next two hard forks. Um I I don't think I mean I think we need parties, but I don't think ZK Knox is sort of a um maybe wellestablished party enough to say that we need it. Um, I think we actually need like the L2s and the ZK rollups to say like this helps us, this decreases the costs for our contracts by like 5x. Um, the the ramifications of this is

X and this allows us to scale by Y. Um, that would be very compelling that that that's what would be needed I think to get into Glamsterdam, right? Right. Yeah. And I think Yeah, I think we're still in the process of getting that once we have the once we've sort of fixed the spec uh we have the Poseidon um benchmarks down and we implement one of their contracts uh maybe the stockware contract the verifier using this. I think we'll have like a either a convincing argument or that it's good or a convincing argument that it's bad at least one data point.

Um so yeah um any other questions or feedback or Yeah. Yeah. I know I'm sort of asking very uncomfortable questions. Uh, no, not from me. I'm good. Cool. Okay, cool. Uh, oh, Mark. Yeah, just one more question. I mean, have we kind of thought about other people outside L2s that might want to use this? So, I mean,

something like post quantum signature seems like it would be useful for a lot of things, even if maybe people aren't super worried about it today. Mhm. Yeah, I think basically basically every every project which uh which needed should but I I'm not fully aware where it should whether it can be useful. Um but uh but if someone is uh knows better, I we definitely we definitely should try to reach out to to everybody who believes that it's something beneficial for for their project and they they can put a even a short

statement that that I don't know that EVM max like in this in this designed like in this EIP or similar it will be very useful and it will uh and we will definitely be using this and we need it and we would like to have it as soon as possible and uh and but yeah so one one one set of potential clients are in my opinion are are L2s but or rollups but uh but basically any other project would be also very uh useful to to to support this uh this project this this this EIP to be included as soon as possible and Uh so so I I wouldn't I wouldn't um um I

I I would like just to reach as many products as possible basically. Right. I think depending on who you're targeting the when it's going to get shipped uh changes. If you're just targeting postquantum then I think Amsterdam is just completely out of the question. Um but if we're then targeting L2s and L1 or have some story of how this scales L1 with convincing arguments then I think Glamster's uh possible.

I think that this this this EIP is definitely part of the uh of the of the scaling of the L1 scaling road map. I yeah and very important part in my opinion. Okay, cool. Uh, any other questions? Okay, cool. And just to round it up on sort of the to-dos. So, Radic, you're going to create um a PR to the EIP in order to add the inversion and also remove the uh we'll add a special case for not doing Montgomery modulus on when the bit size is like small enough.

Um I believe those are the only to-dos uh left and then yeah and one thing is that we need to but probably it's something for us for for epipsilon team to find out how we want to um declare uh declare u ev max cont max contextes in uh in on the top of the uh eof container just to make uh possible to um to validate uh validate VM max uh immediate arguments values uh and uh on on the on deploy time but

yeah so so that's that's one thing one but that's that's the issue we still are not sure how to do it but uh but we have to find out something and that's probably should happen um before the next EVM max call I believe. But yeah, depends depends a lot on on how the another EOF discussion will go soon. Okay, let me write that down as well. And um once we have these things done, are we then in a position to bring this to L2s? Uh what's like what do we need to do next? Yeah, I think that the next step should be just to take the CIP and and uh try to present it uh to the to

the L2 and our other projects as we said and uh and try to get their feedback on it. Okay. Yeah. Um so yeah so by next week then we should have numbers for Prooseidon gets decreased by this much and we're confident and the EIP is fairly um closed or at least it's not going to change too much. Um, if that's the case, then I think I'll add in a clause to review um the gas numbers uh for the operations uh just to be like sure. Uh and yeah, okay, this sounds good. And I think yeah, next time we can

then start talking about which L2s we present this to, uh who we present it to, who's already using Poseidon, and then get the feedback uh from there. Cool. Um, yeah.