[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