[Music]
Carlos Matana work at polygon and today
I will be talking about the top code
offenders in the zvm in order to explain
that basically I will do at the very
beginning some introductions about the
what are the ZK counters what are the
types of the ZK counters available and
how many Z counters do we have available
on the
zbm the second point will be in the
analysis of the offenders you will see
that there are some straightforward
offenders on the zbm so there is no
correlation between the gas consumed on
ethereum and the Z counters consumed on
the
zvm but I will go more into the details
there are some up codes that are quite
straightforward but uh when we analyze
uh in this case I will analyze a Unis
swap swap uh we will see which is the
worst the the worst of codes that uh
performs very bad in terms of ratio
between gas and GK counters so for that
purpose I will analyze a un swap swap
trace and in in the third point I will
basically explain it what are the next
steps um how I would say the the how we
can optimize those of codes in order to
have a better radio between the gas and
the S en counters wasted and also I will
explain two different approaches um
about how those OP codes could be priced
on the zbm okay so let's
start what are the zik counters you can
imagine the zik counters if you can
imagine the gas on ethereum in order to
measure some computational cost
execution cost you can imagine the zik
counters exactly the same as the gas but
on the zbm okay basically in the zbm we
have in ethereum we have a unit which is
a block in the zbm we have a unit of
proving which is a batch so there is
some relation over there and another
difference between the theum and the zbm
it's like on ethereum we have one single
dimensional um resource which is the gas
but on the ZM site we have the Z
counters and we have multiple of them
okay so basically this this table
summarizes what I have just said on eum
we have a unit which is a block the ZM
is a badge the badge consumes some gas
it has some limitation on the gas and
the gas basically reflects the EXE the
the computational resources that you are
wasting when you execute an OP code this
b a single dimensional gas on the zbm
side we have a batch which is the our
unit of proving we have the zik counters
we have several of them so it's kind of
multi-dimensional and basically they
reflect the the proof computational
cost okay well this is basically uh
piece of code this is in Z assembly uh
basically this is the zik ROM we
implement the evm in the Z Assembly
Language which implements the the evm in
Z assembly uh language and basically
those are all the ZK counters and all
these values quite difficult to read it
so in order to understand it better we
have as I mentioned in the in the zbm we
have a unit which is the the batch and
this batch has several zik counters what
are those Zig counters basically we have
the steps you can imagine the steps
sometime I have heard about kind of the
you can you can change the word and
instead of saying steps you can say kind
of
Cycles H we have the arithmetic State
machine in order to do multiplications
and well also we use the state machine
in order to prove uh divisions by by
doing multiplications we have the binary
State machine in order to do additions
subtractions and bitwise operations
basically we have the memory align State
machine basically uh when you read an
slot and the CBM two different slots and
you want you want to join all the bites
together uh we use that steam machine
have the kak Ste machine which is
obvious in order to do kak hashing we
have the padding poon Ste machine and
the poson Machine again quite
straightforward to do poson hashing and
when we want to do a linear posidon
which is a concatenation of poons in
order to Hash a long r of bite we need
to use the padding POS on Ste machine
and the very last one is the Sha 256 Ste
machine which also doing for so it is
very important to say that each state
machine has its own capacity so as you
may see on on this slide H we have a lot
of steps because I would say the
computational cost of for step is quite
low it's just one I would say one hit
one row when we go through the program
through the GBM R but for example on the
kak you can see that there are way less
resources over there why is that because
basically it's more complex so it uses
more resources so it has less capacity
basically one thing that is very
important also to mention is that none
in a batch we have all those Z resources
none of those s Z resources can be
overflow if any of those Z resources is
is overflowed it means that the proof
will not could not be generated
basically the pro could not generate
that proof so we need to be very aware
of
that okay so let's do some kind of
analysis on the I would say top code
offenders on the zbm and as I mentioned
there are super straightforward op codes
that consumes ZK count ERS very directly
and clearly there are offenders on the
zbm what I mean when I say offenders it
means that those of codes consumes some
gas and this gas is basically not
reflected on the ZK counters that they
consume so there is a misalignment over
there the most straightforward one and
of course you may heard about in every
zvm if you do a loop of kaks then you
are wasting a lot of Z resources but you
pay
quite cheap gas so for example the the
first code is the Gard the second code
is the code copy and cod data copy uh in
this case um I would say that all of
codes that has some kind of um
dynamic dynamic gas pricing given that
uh given the memory expansion uh we need
to do some computations on the zbm that
of course it C some arithmetization
binary and steps
and also when we do some kind of copy
reation between context one context to
another context it will basically waste
um a lot of steps as
well the third one also I think it's
very clear the example it's the external
Cod copy op code in this case we are
just I mean this op code basically just
cop so copy some bytes of a bite code
into a memory region okay that's it
what you need to do inside the zbm you
need to provide the full bite code you
need to Hash it with the linear poon you
need to check that that hash matches the
one that you need to read on the state
three so now you know that the full bite
code is correct and you need to go to
the exactly bite or number of bites that
you want to copy into your memory region
take that bites and then copy to the
memory region so there is a lot of
things to do on the zvm but the cost of
this code is not that
much and of course uh
the clear offenders are the pl compil
smart contracts uh you know specific
functions on ethereum like is recover
pings uh modular exponentiation and so
on and there is a very huge misalignment
between the precompiled smart contract
gas pricing and the ZK counter
resourcing consuming the
zbm okay those of course I would say
that are very clear that that are
offenders but I wanted to analyze the
not the clear codes but the standard of
codes standard transactions on the
evm in this case uh basically here this
table well before going to the table um
all these numbers belong I mean there
some assumptions the first assumption is
that here we are I'm showing data of a
one batch that has only one block and
this block
has and transaction
okay and these transactions are always
the same type so you can imagine a block
in the zbm with just ether transfers
with just toket transfers and just with
un swap swaps so let's go for the first
one the theum transfer we can fill up up
to 2,000 more or less trans a bat and we
can see that the top GK counter the more
limiting GK counter is the
arithmetic why because we are basically
checking the signator inside the C so we
are doing a lot of is recover the
recover uses a lot of arithmetic State
machines if we go to the next two ones
the the Unis swap what we can see is
that okay we can fit less transactions
because you have you have some execution
to
do and we can see that the top of kodik
counter offender are basically the
steps either also I mean either in the
and the Unis swap swap regarding the
UNIS up it gets even worse I mean you
hit the top uh the limit of steps and
the other state machines remain at he
capacity even
less given those numbers uh we're going
to get into the details of what are the
op codes in a Unis swap swap Trace that
consumes more
steps okay so yes what are the up codes
that consume more steps in a Unis swap
swap so in a Unis if if you analyze a
trace of the Unis swap swap uh you will
find that um push one push two M store
pop and push 20 are the most used to
coders if you join all the steps
consumed by all the appearance of that
op coders on the the book Trace you will
find that the push one op code uh will
weighs around uh 12,000 steps
and it appears in the unisoft sh it
appears 658 times so same for p two M
store pop and P so basically this stop
these op codes are the ones that
consumes the most steps on the Unis swap
shop but let's go again into the
details inside these op codes which are
the is the user paying the correct gas
price I mean is the are paying the
correct gas price in order because the
up Cod is consuming 2,000 um 12,000
steps so here's the question yes or no
so let's go to analyze a little bit and
here basically I what I did here is uh
comparing the gas of an not code versus
the steps that that code consumed on the
zbm so basically we can get some kind of
a Rao between gas and
steps here we can say that
by far the worst up code is the Cod copy
because it cost just 15 gas and consumes
1,000 steps so the rtio is I would say
quite bad the second one is a m store
here I highlight it in in in green
because it also it's one of the op codes
that has more appearance also on a uni
swap swap
Trace so clearly if we want to increase
the efficiency of a v in the zvm clearly
we need to optimize we need to get
better ratio in the MS St for example op
code third one is the call that the copy
then push through2 and then call that Lo
we want to get rid of those top up Cod
offenders what we should do is repricing
them or optimize them in order to get a
better Rao
basically on the other
side what are the best of codes what are
the ones that uh basically the user is
paying um I would say fairly about the
ZK counters that it consumes on the zvm
so here we have for example the one jump
jump conditional stand Cod size or log
three of course log three s a store and
this kind of op codes the ratio is very
very very very low because basically you
are paying that you are storage some
data on the receip 3 or on the state
three
okay so now the question is how to di
those OP coders accordingly
to the ZK counters that they are
consuming basically okay and the most
straightforward approach which is the
one that we are following right now is
an static approach you can see from you
can imagine uh the batch as a monolithic
batch we have all the resources
available and think that regardless of
the transactions that are executed on
that batch that batch has a price that's
it in this case
0.01 so the sequencer basically pays for
the batches that it post to layer one
and the verifier when the verifier
verifies those uh batches that are
posted in the ler one it receed the the
fees that's it super simple so the user
I would say that the user um does not
care about that only the sequencer and
of course this price is splitted among
all the transactions in a b but then we
can use uh the next iteration I would
say we can use kind of a dynamic
approach the dynamic approach is very
similar to the gas limit on ethereum so
imagine that we introduce here A New
Concept which is kind of the ZK gas and
ZK gas limit so the sequencer does not
pay for a full badge but the batch is
dynamic so it means that basically the
pr can decide the amount of the state
machines that needs to prove basically
uh we can achieve that via the the bat
cops and basically here the sequencer
just sets a z gas limit very very
similar to the gas limit which is the Z
gas that the sequencer is willing to pay
for a bat and then when the verifier
verifies the proof it's substracting gas
for the gas limit and if it runs out it
will be kind of a an out of gas but out
of gas
limit so the batch is kind of uh
invalid then the next step is okay let's
analyze
properly in the in the in the language
in the compiler why those OP codes are
performing so bad and let's try to
optimize them let's try
to let's try to iterate let's try to add
more instructions in order for those of
codes to have a better ratio H let's try
to improve the constraints the pill in
order for those of c those codes to have
a better ratio and not to be offended on
the
zbm if you want to know more about that
uh tomorrow we will do a workshop at 3
P.M on classroom uh C it is called
optimize zbm thut Series 2 we did one on
Brussels uh which one the series one was
a lot of people over there so uh we're
going to explain um some optimizations
that we did on the Z assembly side and
on the compiler in order to optimize
those uh top up
offenders okay thank
you amazing great talk Carlos much
gracias all right so remember you can
post your questions on the QR code we're
going to start to hit the first one the
top one um what happens if the sequencer
has a bug and it creates a batch that
overflows the counters and then it gets
committed to
ethereum yes inside the good question uh
inside the ROM it can happen two things
so inside the RM if the sequencer has a
bu and commits a badge that overflows
the counter uh we have a program as I
mentioned which is the ROM which is an
evm implementation but inside the the ZM
PR we control the counters uh that are
wasted if you overflow the counters then
the prover can prove the batch but it's
an invalid batch when I say invalid
batch it means that the Old State Route
is equal to the new State Route so there
is no State transition function over
there the issue is when you have a bug
the sequencer and in the ROM then you
end up in a situation when you cannot
prove the watch
amazing thanks um the next one is how
much does ef help eliminate or reduce
the top offender up
codes
uh I just read once the
this uh I mean I would say that uh we
need to analyze uh deeper um what will
be the top of offenders given the change
of the B code and e o f basically it's
very difficult to answer yeah yeah no I
I agree it's coming but it's yeah it it
just requires a lot of work and uh yeah
research do you still need counters if
your proving system supports
continuations you need counters but I
would say that those counters will not
overflow since you can continue the
provent execution into another batch so
this will mean that basically any
ethereum transaction will be provable
still if you are just doing a loot a
loop of kicks imagine that you're
looking a very large loop of kyats and
it consumes seven batches that ethereum
transaction needs to pay the seven
batches but we need to be aware on the
proving system that it's compute seven
batches I mean thanks to the
continuation we will be able to prove it
you need to pay for
it yep makes sense so uh next is around
gas cost would multi-dimensional EAP 50
1559 be
useful I would say I I I was in some um
meetings discussing about this
multi-dimensional gas pricing and it
could be done but it's not easy to
modify the whole I mean adding kind of a
new transactions with new fields in
order to sign this gas that uh it does
not reflect the computation which is the
gas but gas layer to or ZK gas whatever
you want to call it that uh basically
reflects the um ZK counters or proving
computation uh you need to change
libraries you need to change um uxui
metamask this is not easy a chief a lot
of work a lot of work all right how do
upcodes limit work with Force
transactions and would it be valid
reason to exclude
transactions I mean first transaction at
the very beginning is just a regular
transactions but you just bypass the
sequencer and it works exactly the same
that an standard transaction if a force
transactions
overflows the badge which can be and as
I mentioned before in the first question
the batch will be invalid and that's it
so at the very end you are kind of you
want to force your transactions but you
are not achieving to execute your
transactions because the batch is
invalid so and every time of course that
uh a user post um a force transaction
into layer one the user needs to pay for
it because you are bypassing the
sequence right right uh the next one is
are there any steps that smart contract
developers can already take now to
reduce the usage of those offending up
coost I would it's very difficult you
would need to go into a assembly code
otherwise solid just put the op codes
most beneficial for execution not not to
take in account the proving system so I
would say it's very difficult yeah I
guess it would remind require like yeah
reactor architecting the compilers and
doing a bunch of like changes and then
yes again yeah yeah really deep
knowledge of that are there any this is
the last one are there any concerns with
the resulting Divergence with L1 fees in
terms of user
experience I mean we are achieving an
stage LLY that uh the difference I mean
these proving cost are every time that
are cheaper cheaper cheaper cheaper and
cheaper so H I would not expect um a lot
of Divergence between layer one fees but
still the zbm has some mechanism in
order to Port layer one fees into Layer
Two it's the AAP 1559 in the base fees
so it can reflect the DAT availability
cost on layer one so yeah this is some
this is just a technique but there are
several ones yeah but I guess like
there's a lot of improvements still in
the backlog to keep improving layer twos
instead of
yeah a lot of work uh and I think with
that we complete all the questions thank
you so much Carlos it's been a pleasure