[Music]
uh show too many slides um hi how we
guys doing so I'm ta AKA fake death I'm
a ZKA engineer from chroma so today I
would like to share our experience of
advancing all P tag into zare rollup so
we're trying to enhance efficiency and
security with zero knowledge
proofs so for those of you who don't
know about chroma I want to First
celebrate our successes from last year
our Mainland
launch
so uh uh we were one of the projects
built on op stack so we're one of the
first I mean we're the very first
optimism rollup optimistic rollup with
an active fault proof system so we
utilize CK proofs for it and so ZK
enables to solve some problems in
traditional fault proof systems and
first we approach with a circuit circuit
based implementation of ZK provs but it
has a very very big issue so we're
trying to Transit from circuit based
approach to cdk VM based approach and
lastly we all we're also building a ZK
backend library to push the boundaries
of proof generation
speed so why ZK fault proofs So In
traditional uh fault proof systems it
requires various of it requires a lot of
interactions which leads to high bond
amounts which decreases the level of
decentralization so with ZK fault proofs
we can just narrow it down to a block
level instead of instruction level which
requires much more much less uh
interactions so uh it not only reduces
the operational cost itself since
there's less interaction so we need less
computation but also it can
significantly reduce the bond
requirement so it it naturally leads to
better decentralization and security of
the
network so more over for like arbitrum
spold if we apply ZK ZK technology into
it we can we would be able to sign
reduce the bond requirement
significantly that is usually used for
uh blocking Cil attacks also optimism is
uh putting a lot of resources into
exploring ZK fault
proofs so we have a uh announcement that
we have received uh retro pjf round five
from optimism to explore more on the ZK
fallproof size and this recognition I
think uh shows how much important and uh
possibilities are there into building a
permissionless fa proc system with
ZK so we've looked at like our
achievements since last maintenance
launch and now I would like to share
some our lessons learns and challenges
that we've experienced for building uh
CK fallproof systems in our main
net so the very important fact that we
learned is that the circuit based
approach is just just not sustainable so
we currently have about like 100k L of
code which are for custom circuits so we
have to write it in a circuit language
like plish and it's very very hard to uh
write and debug and verify so what we're
trying to do is check the Integrity of
evm St State transition function but we
have we need like several uh specific
custom circuits written in circuit
languages to verify that the state
transition function given the input is
done correctly and back in 2022 uh vital
given mentioned at the time there was no
like uh production ready zkm circuit
codes but they had a POC version of it
in ethereum's psse and back in the days
it was like 35k lines of code but even
vital mentioned that it's never going to
bug free for a long long time so it's
very prone to errors very prone to human
errors so to sum up there are two
challenges writing the circuit itself is
tough because it's hard to audit and
debug and also since optimism and
ethereum keeps keep brings upgrades to
the main net to support like full
compatibility we have to keep up with
the protocol upgrades they're making
which means that we have to modify
circuits again and again every time the
upgrades come up and this could lead to
like possibly if we make more modifies
modifications then there will be
possibility of more errors which would
like harm our security of our
maintenance so we need a better approach
so now we're trying to take a ZK VM
based approach because ZK VMS can give
us generality and auditability what it
means is as I mentioned in a circuit
based approach we need to write circuits
in a circuit language like plish which
is very
unfamiliar and because of that the
Auditors will have also have a hard time
auditing and even us can't really verify
well that our code is written well but
ZK VMS allow us like flexibility we can
write any program that we want to verify
the computation in Rust and since it's
written in Rust it's very very better to
audit and
debug so now I would like to dive in
more to ZK VM area so how we're trying
to move on from circuits to ZK
VMS so as I mentioned ZK VMS can provide
a general purpose environment for
verifiable computation
so uh what it means is that we don't
need to implement circuits anymore we
can just write rust program and ckvm can
basically execute the program and give a
proof which proves that the computation
was done correctly so how it works is
first the each zkv M vendor would have a
compiler tool chain that I can compile a
rust program into let's say if it's
based on risk
it would turn into a machine code based
on risk 5 and then inside of ZK VM
there's an Executor which executes the
program and generates what's called an
execution Trace execution Trace is
basically a polinomial Bound by some
constraints so back then we have we
would have to write like circuits to
represent some input data into a
polinomial and then have constraints for
it but now zkm circuits could handle
that so now we can just write rust code
there's more
flexibility and then in the proving
stage where the ZK VM gives a proof
based on the execution trace it would
commit to the trace and then generate a
proof so I have a like a summary kind of
uh picture that we can compare like how
it's different so the colored green
parts are the code that we used to
maintain and we have to maintain
so back then we would have to maintain
like zkv ZK evm circuits written in
plish so there would be like evm circuit
RP circuit MPT circuit and transaction
circuit which could uh which kind of
replicates the behavior of evm so it
will verify the logic if the let's say
the transaction body and like transtion
I mean like the block header and block
body comparing with like hash it and
then like compare with the block cash uh
that's what we used to do it's very very
tricky but now since the on the right
side there are ZK VM circuits so ZK VM
circuits would handle that and instead
we would just write a blog execution
program which would which for us as a
ethereum layer to we would derive the
batch from L1 and then execute it on L2
so that will be the program we were
trying to
write and
uh some of you might ask like vitalic
mentioned in 2022 we launched our main
it in 2023 and then like why didn't you
guys first approach with ZK VMS at first
right like why did you guys ride
circuits and do all that hard work
that's because back back then uh ZK VMS
were not like performant so since the
proving time is long in in within the
challenge period we have there can be
possible
volum possible attack Vector for delay
attacks so that's one of the reasons why
we chose a circuit based approach but
now uh RIS risk zero calls it
continuation and like sp1 calls it
sharding like there was a breakthrough
called sharding which with the full
execution Trace you can now divide it
into a a unit called shards so it's
usually represented in the number of
cycles of risk five so sp1 they kind of
have an optimal number of like two to
the^ of 22 cycles for each shart and
since we can divide it into charts now
we can uh parall generate a proof for
each Shard and then compress it later
Into A Single Shard so now there's more
more uh upside in terms of throughput
since we can paralyze
proofs so that's what we're trying to do
and we're almost there shipping it to
the main net and now now I want to like
share more of our of my thought that
what we can explore more in the future
to overcome like barriers to become a
from a optimistic rollup to a zare
roll so my concerns about zkm based
approach is since zkm vendor uh vendor
business model is usually running a
prover Network so they get a delegated
proof and then they generate a proof for
it and then return the proof to the
client
but there might be a situation where zkv
Andover Network might fail so uh usually
zkm vendors since they've built their ZK
VM they're very very good at uh like
giving a good performance so usually
they would have like a cluster of
machines and then they would like uh
split the workloads to each machine and
then like orchestrate it and then create
a proof and return but since most of the
such Prov Network related codes are
close sourced uh maybe to handle this
kind of network reliability issue we
might have to we might like us chroma
might have to implement uh a code to
orchestrate multiple machines so that
every validators could
run by run I'm not sure if this is
correct but they they might have to run
a cluster to generate a proof for the
network so
uh another concern might be so now then
now there's going to be more stage one
rule ups but for stage two uh we we we
only want
the uh Security Council to come in and
resolve like the problem if the failure
is only onchain provable but currently
in my perspective for the ZK VMS
currently there's no way to make like
the network failure to be onchain
provable so that's that's enough another
concern and also since we cannot
Overlook that the fact that ZK VMS
itself might have a bug uh so what I
think is we need a multi-pro system so
that we can compensate the bugs for that
so then in that case the goal would be
to enhance the security of the network
but not much with the overhead so we
don't want like uh periods to be longer
so there might be like three types of
multi-prover schemes instead of like
having a single prover so one I think
most of the networks like scroll and Tao
is trying to use teth but in my opinion
uh there's a trust issue that we have to
trust the te implementation itself so
and there's also like Hydro
centralization problem so we might have
to come up with a clever idea to maybe
use like three vendors of te's and then
like have a multiset kind of thing and
another one would be kind
of very very labor intensive but come up
with another circuit B another circuit
based ckvm so instead of plish and Halo
2 you might have to write another ZK evm
code circuit code with another language
uh I don't think no one will try that
and I think the best would be
uh our approach to have another ZK VM
based zkm I'll tell you why like why we
think this is the
best uh and if if we have a multi-prover
system and if we have like ZK VMS now we
could really really easily ship ZK
rups then like pass one or two years but
I've did some benchmarks with several ZK
VMS but there's still a feasibility
issue so first there's a cost barrier
which is very very important and in my
opinion it would be really really hard
to like charge the users to use it since
like most of the layer twos and most of
the optimistic rollups now have very
very
cheap uh fees so there are three types
of costs that we need to pay to run a zq
rollup first is it's the biggest
bottleneck which is the proving cost so
uh I've tested with like a network with
about like three TPS and you need about
a million dollar for proving the blocks
for a year so I think it's not that
feasible now and also we would have to
com commit to the batches we've uh
settled into layer one so there will be
settlement fees also and to finalize the
blocks we would have to send the proof
to the contract and verify on chain so
there's also going to be verification
piece but that's going to be really
really small because we will be able to
agre aggregate proofs inside a ckvm
which would be way cheaper but there's
going to be trade-off between
finality and also we could Explore More
on future directions where I introduced
the multipro system and
also uh the ckvm vendors would have to
consider more about Pro decentralization
where they don't keep the Clusters
running on only their Network and
getting proof requests but instead of
like have a incentive mechanism so that
Pro Network can be decentralized a bit
more uh and like we're also pushing the
at the same time pushing the boundaries
of proof generation so we have our own
very unique uh open source Library
called takon which is a particle that's
known to be f faster than the light uh
and it's it's basically a modular ckvm
CK backend library and we also have a
feature of Z GPU acceleration so since
we've built our ZK VM based on halo2 we
first optimized Halo 2 a lot and we have
about like 1.5x 6X faster
Benchmark and we also are trying to
utilize sp1 ZK VM at the moment so we
also optimize planky 3 as well which is
used by
sp1 and last since circum is very very
widely used in the community we also uh
optimize a lot in terms of Rapid snark
so it's also
faster and we could wrap up into this
one figure where if if chroma has a
multi ckv Andover back uh backing the
network we would also have takon which
is a modular ZK backend Library which
could support all all kinds of ZK VMS so
we would only have to
maintain the very front like ZK VM main
which is written in Rust and which
mainly uses the library Kona which is
main from maintained from optimism which
has block derivation logic and execution
logic so we could easily write uh a
program for a main net within like 200
lines of code and we would would have an
input with which the which would be the
block we're trying to prove and we would
have a multi-prover like one of the
Frontiers risk zero sp1 o VM uh Alida
maybe and then we have a takon which is
backing with powerful GPU optimizations
which will accelate accelerate the proof
generation
speed yep that's it for today and you
can contact me with fakee 9999 on
Twitter Telegram please contact we could
share more about uh fault prooof systems
I would like to hear your ideas and
that's it thank
[Music]
you oh you can just stay over here all
right uh great talk to so thank you to
the crowd for submitting all these
amazing questions uh we do have less
than five minutes to go through some of
them uh let's go through
uh the most upvoted one how is it
different than op6 sync yeah uh some of
you guys might know and not know but uh
opung and us we have a very very similar
logic actually we were working under
water like for about like two months and
then like we shared it to the sp1 team
about oh we have a choma SPO improver
repository you could take a look if the
logic would be correct for ZK VM based
Prov
and they were also working on water with
the same thing and like it comes out
that like we have almost similar logic
and they have an additional feature of
what I mentioned of aggreg aggregating
the proofs so the logic is very similar
but basically we built the same
thing uh so I'm going to mark this as
answered any stats on Pro cost specs and
time so the Prov cost
for uh the for our fault proof system
for about a block with a TPS of three to
prove a faulty
block uh of tps3 I think it costs about
like uh currently if you so it depends
on the pricing of the N the approver
network you're trying to use but if
you're just using an ond demand plan
which would be the most expensive per
Cycles uh if I remember correctly it's
it was about
like 20 20 bucks for a block with like
about like uh
tps3 and uh the their the stats and like
the machine specs it's not revealed at
the moment for SPO Andover Network so
I'm not sure about that all right do you
know if the ARB ecosystem have similar
plans yes I I definitely know and I also
uh know the fact that they have a fast
withdrawal feature now with ZK proofs I
didn't have much time to like deep dive
into it but I I definitely think like
arbitrum
also is going through the right path so
maybe we could collab more and talk more
about
it all right great so we we can go
through I guess two more questions real
quick uh in your prior implementation by
pish circuit you mean Pony 2 or three or
something custom oh it's it's actually
uh Halo to's plish arithmetization
uh it might have like confused you a
little bit but it our we're using a back
end currently Halo
2 all right so one last question what
happens if the guest program panics can
you still produce a proof so if a guest
program panics then uh you can't produce
a proof
so uh I'm not
sure uh the person who ask who's asking
the question like is intentionally
panicking the program or not but
like yeah if if it's a bug that's
causing panic
then proof is not produced so this is
one also another thing I mentioned in
the slides before is
we need a way to like uh like overcome
like if the program panics like but if
it's a bug inside a ckvm or if it's a
bug in a program then like you would
need to wait to uh verify it on chain or
like have a way to prove it on chain so
that so that Security Council could like
intervene or what all right great so our
time is up thank you so much ta uh