EVMMAX. Fast Modular Arithmetic in EVM by rodiazet | Devcon SEA

[Music] I'm Ric from from Ipson research and development team at etherum foundation and today I want to talk to you about some uh some extension we we're going to add to the to the interium virtual machine uh in the near future so the idea has a couple of years already and it was initiated by some cevs to uh to improve the way how the cryptography is handled or cryptography related functions are handled on the in the in the evm the main reason was to avoid adding or limit limit the need to adding new promiles yes so but before we get into the details I would like to make some simple introduction and explain the reasoning behind evm Max so what's the evm Max so evm max translates to EV interium virtual machine modular arithmetic extension it's a set of modular set of the new modular arithmetic instructions which support every sized C which is important old modules at the current spec we Define uh addition subtractions subtractions and multiplication we also consider adding exponentiation which is a helpful uh for calculation some more advanced uh modular arithmetic functions like modular inversion or square root one every important thing uh uh which should be noticed is here is uh that in this proposal that this proposal is built on the top of the evm object format which we had just a presentation of uh in a minute and also there was one presentation made by Dano uh on Tuesday uh so um yeah so evm max makes a usage of e eof immediate arguments and the validation of the immediate bite code also and it makes uh it possible to validate evm Max code before before the deployment of the contract to the to the chain um but I'm not going to get into details of the of this validation because it's not the the the main topic of this uh of this uh presentation yeah but it's worth mentioning that uh eof is a crucial dependency which makes evm Max easier to implement in an efficient way it doesn't mean that EV eof is uh is a dependency which has to be before it just makes the implementation tvx much easier in an efficient way so but where exactly evm Max is located in the in the crypto graphy related uh evm evm stack so we have a basic operations in the modular arithmetic on the on the bottom level which are used to implement the second level uh the elliptic curve cryptography Primitives like Point addition multiplication and sometime and and more advanced like piring verification and these Primitives are used to implement ECC uh algorith like signature verification and ziker related functions but evm Max implements only the bottom one level of on this diagram the Epsilon team we also uh use evm max to implement the second level to make sure that the set of instruction of evm Max is offer the and the API offer uh right abstractions right abstraction and efficiency so um sorry too fast what is going on yeah okay so we know uh we now know what evm Max is in general um some [Music] so one of the reason I already mentioned at the beginning of the presentation but there are a couple more reasons I want to list so in etherian community there is a need to make the implementation of the cryptography uh in evm much easier and efficient get uh me in efficient uh so yeah so with VX we won't need to wait for a specific uh promiles to be okay okay thank you to be delivered in a in a fork we also would like evm Max to be a tool which allows to avoid adding new promiles in the future it will make the cev's lives much easier because they won't need to uh maintain the very specialized cryptographic libraries in the evm so they they will not have a headache like uh what exactly this function do I'm not the cryptographer exactly or we don't have a specialized cryptographer in the team so why do we need to to to to maintain this complicated libraries which we take basically very often from some from some external libraries which are already implemented but um so evm max will deliver a tool which should make pre compile specification also possible in the evm max bu code so we can imagine if the promiles for some reason will be still needed to to be implemented and to use by the evm we can imagine that the evm bite code we will can define a specification of the promiles how they should be implemented exactly yeah so but let's get little bit deeper into the evm max instruction details so uh we can split it into three different uh three different parts so uh the first part is uh just uh is responsible for setting up the uh the evm max context the second second one is just the set of modular arithmetic instruction I already mentioned and the third one is uh responsible for evm evm Max Contex is communication so so let's get into details of these three three three parts so first uh setup X creates the evm max context if it doesn't exist yet which means it initialize modulus values and allocates evm max value slots in the dedicated for evm max memory only these slots can be only access by the evm max of course of course and also initialize some specific uh constant values like for example air squ which must be which is used for uh which is used by Montgomery Montgomery form in this context if the context is already defined so the set upex just only switch to this to this to this already defined context second part are the arithmetic instructions so basically um they uh perform the arithmetic operation according to their names as you can see so everybody who uh who know a little bit about the the arithmetic modular arithmetic should uh be able uh to know what's what they exactly do but it's worth noticing that they operate only on uh indexes of the slots in the evm max context and the indexes are static and can be validated on the deployment uh uh before before deployment of the contract to the main net which allows to validate them us exactly the same way as all the uh all the immediate arguments in the eof uh are validated and the last but not least part uh is there are are two instructions to upod responsible for loading and soring values from and to uh evm Max context they allow to initialize slots values uh using evm evm memory and loads result back to the evm evm memory because we allow only uh we allow any size of the modulus or C of course but any size we transfer values from and to evm memory instead of uh instead of evm Stack so this is this is the set of uh evm Max instructions and uh but of course it can be extended or changed as the proposal is still in the Des stage sorry I need to take a some more yeah so we have a we have a this set of this five instructions which are quite simple uh yeah so as I mentioned U earlier about the promiles uh they have some downsides I'm going to I'm going to to to present also uh yeah but let me explain what exactly I have in mind so so at first um they are all implemented by many different libraries in in different languages across all the execution execution layer clients this means that they are potentially Vector of attacks on the clients and on the consensus of the chain moreover the IPS proposing new pre compiles cannot spec out the implementation details details of them because the implementations differs differ the implementations differ between between the between the clients as a result of this very often uh promise implementation need to do some redundant operations to make sure that the result will be exactly the same for all possible implementations of the of the promiles so because if the if the result will be different we can have a basically if the result for the same input will generate different res the will be different it means that uh that basically we we we have a consensus problem yeah because we we get we get different results for the same input for the same PR compile on a different on a different clients uh and we have even the recently recently very intensive discussion about uh about exactly this this problem when when uh finalizing the spec of the of the BLS promiles which is going to be introduced in the in the in the upcoming Fork yeah so um and let me show you one example very simple example of the pre compile which already exists um it's a it's a point addition on bn5 254 elliptic curve and I'm just going to present you a simple formula which is used to add two points on Ting curve not going into details because they they they it doesn't matter how they how the addition is defined and why it's this way the formula is quite simple we've got two points on elliptic curve uh we first check that the x coordinates are different of of them are different different and if they are not we switch to the special case which I'm not going to present because it's very similar and doesn't change anything in what I wanted to focus on here assuming that the points have a different x coordinates we calculate the slope of the line intersecting these two points and based on this we calculate third point where the line intersects the the elliptic curve the point addition definition tells that at the last step we have to negate the y-coordinate value to get the final result this is the definition of of the point addition on the on the elliptic curve uh for this exact case when we have a different x coordinates so uh this is simple formula very simple formula and formula and uh let's focus on what and and how many operation we have to do uh to calculate this so as we can see we have a like six abstractions subtractions and two multiplications uh which are basically the operation which we already have uh in a set of uh of the evm max instructions but there is a one more additional uh additional operation which is the division and basically uh it's it's marked with the with the red color so but let's get deeper a little bit deeper um what uh what the how how the division uh can be calculated in modular arithmetic so as you expected it's very expensive and it's uh it's very expensive and if you uh if you use some well-known method to calculate this using adchain for example T it requires about 300 multiplications so comparing to six we have uh sorry two multiplications we have on the previous slides it's 300 uh to calculate the division in the in the arithmetic uh in modular arithmetic but the good thing is that in real world we want to uh we want to add more points to do this sorry so but in real world when we are adding more points so the sequence of points uh we will we never uh make a division every every addition we we do so so like no so every two points we don't do every division uh at at any step because it can be it can be done in different way which allows to make one division at most if ever needed if any needed so so with VM Max we would be able to implement the points addition in the optimal way without redundant operations and return the results in any form need did for a specific case so yeah so sorry let's get back to this slide once again so the the the solution is just to one of possible solution is just to use in different coordinate system like for example projective for Jacobian coordinate system but also there are uh algorithm who which add a sequence of points uh in aine coordinates and you can make a one division in the end so but what are the benefits of EV Max over promiles first of all uh we improve efficiency because of the reason I already mentioned we have also more flexibility uh because we can implement the cryptographic algorith according to the specific needs we also improve security as we mitigate potential consensus risk the complexity of the precompile implementation details is moved from the evm to the smart contract and last but not least again project can and last but sorry where was it okay and last but not least project can deliver functionality they need faster not waiting until the specific promiles will be processed and delivered to the mine so as a summary I would like to give you an update of what we did till now so we prepared a bunch of aips and more IPS are in progress we have an experimental implementation of VM Max instructions support in the vm1 so our project we um we develop from a very long time and on top of this we implemented a couple of promiles by generating evm Max bite code and it appeared that the implementation is faster than implementation in libff which is still being used by some of the execution clients honestly Li is not the the fast the fastest Library available but but but it's still used to to implement the existing promis already by some some clients and thanks to Jared from GFF team we also recently prepared a draft of of the specification of the vectorized version of evm Max up code which is a direction we wanted to investigate in a as a potential Improvement of efficiency of the implementation of the posidon hash function and smaller modulus setup so what what we plan to do next we need uh more use cases for sure to make sure that uh that the spec is correct and the API is convenient uh we plan also to start supporting different models which values which will which will be the power of two some attention also and research on SD s IMD instructions is also uh sorry extension it's also required to utilize uh this extension if it gives measurable uh measurable benefits uh regarding the tooling uh we work on supporting evm Max in higher level languages like for example youu or or half uh we haven't choosed yet which one but now we are very close to very close to to to start with fuel we plan also to research the idea of using KVM Max biteco as a spec language as I mentioned already uh for the pre compiles if they still will be needed for any reason uh it should also result in a tool to transpile this evm Max bite code to higher level Lang language so opposite basically opposite way uh which can be used as a pre compile future pre compile implementation by the execution clients yeah so uh so regarding our goals for the very new future uh we plan basically the most uh the most important is to finalize the evm max spec then um then uh sorry yeah to finalize the evm max pack then uh it when it's implemented it will equip the evm in a cryptographic friend cryptography friendly tool chain and it should minimize the need of adding new pre compiles as I mentioned already and uh make the evm more Z friendly we want to be from the very beginning of the evm existence almost and to introduce and we plan to introduce this ideally after Fork when the eoff will be will be introduced so hopefully next year or 2026 and if you are interested in the and and have more detailed questions and will will not be able to ask it them now uh this is the list of the people I'm aware of who now work on the on the on the evm Max and this is ipsilon team I'm a member of from GF and kef from RG ARG ARG team at TF yeah so thank you for your attention it's time for some question now if you have any thank you thanks again for this very interesting top uh talk uh so let's start with our questions the first question is um is there a chance that uh all these extensions and end up being not enough H what about going in the opposite direction and integrate something like wasm and then implementing it uh at the contract level yeah so uh it always can end up with being not enough if there will be some uh some use case which we uh haven't covered uh when when uh when designing the instructions um but uh but yeah so that's why we that's why we trying to do all this all this use cases and also the the newest one ideas like Poseidon hash uh like any others and uh regarding quasm I think I'm not sure I fully understand but uh but yeah so so the wasm wasm idea to to to to use it to replace evm evm was investigated like a couple years ago by my by my friends from ipsilon at uh I don't remember now exactly the reasons but it was uh it wasn't uh it wasn't finally appeared to be a good uh to be a good direction okay let's go to the next one so uh what's and the next one is the second one so H Eva Max is kind of another co-o co-processor why not just enable restricted wasm kind of similar question I guess H only on some sign the in sequence of AD Mo store yeah yeah that's that's that's another so I okay now I remember one one one one reason why wasm is not uh uh not the best idea here first of all uh wasm as far as I know uh but I can be wrong doesn't operate on the on the register is bigger than uh 64 bits and uh and basically it makes the the implementation of the of the of the 220 56 uh bits Valu is much more complicated that it can be done now in the evm and uh and this also uh this also means that uh yeah so so basically this also means that in the end when we when my friends from Team were were trying to to use wasm instead of evm it appears to be uh basically less efficient than evm great so is it a problem if uh different implementations of a precompile vary in performance if so how to avoid it so basically when we have evm Max we will not have hopefully we will not have uh new promiles anymore anymore new promile related to elliptic curve cryptography or uh or basically to cryptography so we won't have this kind of a problem but there is a problem now with uh with with the promise already and uh basically it means that uh we when when when we uh when we designing the gas schedule for the precompile we just need to um we just need to make it based on the less efficient available implementation and uh available impation in the client execution uh and the layer execution client okay so uh does adding new instructions require a hard Fork a new year version or both uh yeah the it will require hard f it will not require uh your version bu bump mhm um are you foreseeing any ways for uh anyone to exploit uh these extensions in a non- cryptography way uh actually I personally hadn't thought about it but uh but probably some some guys from ipsilon will be able to to to answer this question so we are basically here so we can find us sorry because I I I don't I don't know this one can extensions like this be added freely or is it bad to have too many extensions I guess something similar to evm Max but for another Target uh basically if if it will be needed it can be add but you know the process the process of adding new extensions is like well know and straightforward you need to propose it you need to fight for this on a ACD calls and uh and maybe finally it will be introduced mhm um so if implementing G marks in another language guess not see not uh go or not uh rust um are there potential performance differences then uh yes definitely definitely it can be it can be a per performance differences in the implementation between the clients uh like probably for every other instructions which are implemented in different languages across the clients regarding the yeah yeah so do you want to pick one more yeah so regarding this this question regarding simd uh it's it's a new topic we haven't investigated it very deeply but basically this extension we plan to be used only for for smaller modulus like 64 bits which will probably make much more sense here