►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/proving-evm-bytecode-execution-in-the-zk-evm/
Rollups are the go-to solution to scaling Ethereum and at the heart of the Ethereum roadmap. Programmable rollups and zk-evms have gathered a lot of attention and research interest. Provers in particular, which produce cryptographic proofs of evm execution, pose challenging problems both theoretically and practically. In this talk we will present our arithmetization and proving scheme, and demo the zk-evm under development at ConsenSys, providing an EVM bytecode compatible end to end solution.
Speaker(s): Olivier Bégassat, Franklin Delehelle
Skill level: Advanced
Track: Layer 2s
Keywords: zk-evm
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
B
C
Hello,
everybody
thank
you
for
coming
so
yeah.
We
are
both
from
the
Z
sorry
from
consensus.
R
d
we've
been
working
on
a
ZK
VM
pretty
much
for
about
a
year,
and
in
this
talk
we
want
to
talk
to
you
about
it's
everything
today,
arithmetization
how
we
implemented
it
and
we'll
have
an
announcement
at
the
end,
all
right.
So,
first
of
all,
why
is
EK
Roll-Ups?
C
The
screen
is
not
working
for
me
well
in
terms
of
scaling
ethereum.
One
of
the
bottlenecks
that
is
addressed
by
a
ZK
roll-up
is
that
of
the
state.
So
in
order
to
validate
the
state
transition,
which
is
you
need
to
basically
execute
the
transactions
within
a
block
and
the
state
is
a
big
object
and
this
validation
is
a
resource
intensive
operation.
So
the
promise
of
a
ZK
roll-up
is
to
basically
alleviate
that
workload
from
most
of
the
nodes
on
the
network.
C
So
when
you
have
a
ZK
roll
up,
you
have
basically
this
powerful
node,
which
is
an
operator
which
provides
proofs
of
State
transitions,
and
these
proofs
typically
verify
the
following:
the
validity
of
the
transactions
in
the
batch.
The
fact
that
the
internal
logic
of
the
roll-up
is
respected,
Roll-Ups
are
usually
application
specific
and
the
fact
that
they
induce
the
proposed
state
transition
and
here
and
throughout
when
we
talk
about
proof,
we
talk
about
proofs
of
computational
Integrity,
which
in
practice
implemented
as
zero
knowledge
proofs.
C
So
a
ZK
evm
is
a
particular
kind
of
a
ZK
roll-up,
the
big
distinction
or
the
the
thing
that
makes
it
a
zkvm
is
the
logic
part.
The
logic
that
is
being
executed
or
and
proven
in
the
proof,
is
the
execution
of
the
ethereum
virtual
machine.
It
also
means
that
the
transactions
that
roll
in
pretty
much
obey
the
same
format
as
standard
L1
and
instruct
transactions.
Sorry,
okay.
So
how
does
that
work
in
concrete
or
semi-concrete
terms?
C
C
It
takes
into
account
the
transactions
and
basically
the
diff,
of
the
new
state,
and
it
does
its
magic
and
it
produces
traces
which
it
passes
on
to
approver,
and
the
proofer
then
produces
a
proof
which
ends
up
on
mainnet,
and
in
this
way
you
bundle
all
of
these
L2
transactions
into
a
single
L1
transaction.
So
why
would
one
want
to
build
a
ZK
evm?
C
There's
two
parts
on
this:
there's
the
ZK
and
the
evm
part,
so
the
evm
part,
basically
the
advantages
or
the
interesting
Parts
is
that
it
allows
you
to
reuse
or
to
use
all
the
existing
tooling,
which
has
been
developed
for
L1.
You
can
basically
write
in
a
ZK
VM
write
and
deploy
smart
contracts
on
the
site
on
L2,
just
as
though
you
were
doing
it
on
L1.
Furthermore,
you
can
redeploy
already
deployed
by
code
onto
L2
and
the
ZK
part
and
the
zkvm.
C
C
Okay,
when
we
set
out
on
this
project,
we
had
a
few
goals,
so
we
wanted
to
be
able
to,
in
our
zqvm,
prove
the
execution
of
unadulterated
native
bytecode
and
respect
the
logic
which
is
specified
in
the
ethereum
yellow
paper.
We
wanted
full
coverage
of
all
the
op
codes
where
we
allowed
ourselves
to
deviate
is
in
terms
of
the
representation
of
the
state,
and
so,
for
instance,
we
will
not
be
using
ketchup.
C
We
are
building
a
type
2z
KVM
in
the
sense
of
the
classification
put
forward
by
vitalik,
so
this
project
I'm
sure
your
web
presents
a
lot
of
challenges.
There's
a
lot
of
complexity
that
comes
from
the
evm
itself,
which
is
composed
of
many
parts
which
are
tightly
coupled
and
have
complex
interactions.
C
There's
a
lot
of
intricacies
that
are
really
specificities
of
the
evm.
You
have
families
of
opcodes
that
have
slight
variations
in
the
execution.
It's
slightly
non-uniformity,
there's
a
completely
different
kind
of
challenge,
which
is
that
of
auditability,
so
Frank
Lang
will
touch
upon
that
in
his
portion
of
the
talk
and
the
main
challenge
with
challenge
which
everybody
faces
today
is
that
of
performance
efficient,
proving
schemes?
C
You
will
have
a
modified
ethereum,
node
and
execution
client
which
receives
transactions
sent
by
users
by
dapps.
We
plug
ourselves
into
this
execution
client
and
extract
some
data
which
we
use
to
fill
some
traces
I'll
be
talking
more
about
traces
later,
and
these
preliminary
traces
are
fed
into
this
tool,
which
we
call
corset,
which
does
many
things
among
them.
It
is
responsible
for
producing
the
constraint
system
and
it
also
expands
and
computes
the
remaining
parts
of
the
trace.
All
of
this
constraints
and
expanded
traces
are
then
fed
into
our
in
improved
system.
C
The
inner
proof
system
we
use
is
not
compatible
with
ethereum
per
se,
so
we
have
to
feed
it
into
a
verifier
which
is
a
circuit
over
bn254.
This
is
where
we
plug
it
into
with
canarc
and
gnat,
then
produces
the
outer
proof,
which
is
then
posted
on
mainnet.
Okay,
let's
talk
about
a
bit
about
the
arithmetization,
so,
first
of
all
on
Monday
we
published
an
updated
and
expanded
version
of
the
spec,
which
is
now
a
pretty
hefty
document,
and
its
contents
are
basically
the
arithmetization
whoops
of
the
evm.
C
So
when
we
talk
about
arithmetization
in
this
talk
at
least
we
mean
to
basically
construct
or
write
down
a
system
of
polynomial
equations,
the
simultaneous
satisfaction
of
which
perfectly
encapsulates
or
captures
a
particular
computation
performed
on
a
particular
set
of
inputs.
For
us,
the
computations
of
Interest
are
valid
executions
of
the
ethereum
virtual
machine,
given
a
set
of
transactions
and
an
initial
State
okay.
So,
since
the
evm
is
a
beast
of
complexity,
it's
a
big
thing.
C
We
basically
need
or
it's
it
pays
off
to
try
to
decouple
as
many
of
these
components
as
we
can
to
work
in
a
modular
fashion
to
sort
of
concentrate
the
complexity
in
different
places.
So
this
is
the
general
architecture
we
have.
We
have
the
central
piece
which
we
call
the
Hub,
which
is
basically
our
stack
in
our
cold
stack,
and
then
we
have
plenty
of
smaller
modules
that
are
tasked
with
doing
specific
kinds
of
operation
such
as
arithmetic
or
binary
operations,
or
storage
and
I.
C
Don't
know
if
you
can
see
it,
but
there's
also
the
memory
Parts.
Okay,
it
doesn't
work
the
memory
which
is
this
mmu
and
mmio
modules.
Okay,
and
when
you
run
the
ZK
VM,
what
do
you
get
you
get
these
traces
that
I
was
telling
you
about,
which
are
these
large
matrices
which
contain
data
represented
as
field
elements,
there's
one
such
Trace
per
module
and
each
trace
or
base
its
own
internal
constraint
system.
C
C
So,
for
instance,
when
you
update
the
program
counter,
you
expect
something
particularly
to
happen,
but
you
also
have
another
kind
of
constraint
which
is
sort
of
global
constraints,
Global
consistency,
constraints
which
range
over
the
entirety
of
the
block
rather
than
two
or
three
consecutive
rows,
and
that,
for
instance,
May
Express
properties
such
as
that.
Well,
when
you
re-enter
an
execution
context
and
you
load
something
from
Ram,
you
get
what
you
last
put
there.
C
So,
let's
zoom
in
a
bit
on
this
Central
piece,
The
Hub,
which
is
our
as
I,
said,
our
stack
in
our
call
stack.
It
gets
its
instruction
from
the
ROM
and
what
it
does
when
it's
once
it
has.
An
instruction
is
to
basically
dispatch
this
instruction,
wherever
it
makes
sense
once
it
has
an
instruction
that
it
loads
from
ROM.
It
first
does
some
preliminary
decomposition
of
that
instruction.
C
It
extracts
some
parameters
when
which
are
hot
coated,
and
it
decides
on
certain
things,
such
as
how
to
interact
with
the
stack,
how
much
data
to
excavate
from
the
stack
and
where
to
put
it
in
the
in
the
trace,
the
layout
basically
of
the
data.
It
also
raises
some
module
Flags
Etc,
and
the
next
step
is
then
to
dispatch
the
instruction,
but
before
we
can
go
there,
we
actually
have
to
deal
with
potential
exceptions
and
the
The
Hub
also
deals
with
the
exceptions.
It's
basically
some
of
them.
C
It
can
detect
others,
it
Imports
some
other
modules
and
if
an
opcode
makes
it
past
this
hurdle,
then
you
have
the
instruction
dispatching
per
se
which
kicks
in,
and
you
have
these
flags.
These
activation
bits
that
light
up,
and
you
have
some
stamps
that
are
updated
because
you
need
to
keep
track
of
temporality
yeah
at
this
point,
these
activation
Flags
well.
Well,
they
tell
you
what
will
be
active
so,
for
instance,
in
when
you
do
a
create,
you
will
be
touching
Ram,
so
you'll
be
touching
those
two
modules,
mmu
and
mmio.
C
C
Talk
about
about
the
next
big
piece,
which
is
Ram,
so
Ram
is
probably
the
most
complex
piece
in
our
infantization
by
the
way,
all
the
figures
that
I
put
here
are
available
in
the
document
and
some
of
the
well.
One
reason
why
it
is
so
complex
is
that
it
has
all
these
data
stores
which,
with
which
it
can
interact
and
the
different
instructions
which
interact
with
ram,
actually
have
different
sources
and
targets
so
that
there's
already
some
first
complexity.
C
The
next
source
of
complexity
comes
from
the
fact
that
operations
which
are
Atomic
from
the
point
of
view
of
the
evm,
such
as
returns
or
creates,
have
to
be
broken
down
into
smaller
Elementary
operations
in
the
zkevm,
and
so
the
first
task
is
to
basically
do
a
lot
of
offset
computation
and
deciding
when
some
padding
has
to
be
done,
this
sort
of
stuff-
and
once
all
of
this
has
been
decided.
Well,
you
can
start
writing
instructions,
and
this
is
still
just
writing
them
without
executing
anything.
You
just
have
this
sort
of
workflow.
C
That
tells
you,
in
this
case,
I,
need
to
do
this
and
that
some
xoramped
slide
chunk
or
something
and
once
you're
at
this
point,
you
are
at
the
phase
where
you
can
actually
start
doing
something.
So
this
is
the
the
work
of
the
mmio,
which
is
the
the
actual
Ram.
In
a
sense,
this
is
the
the
component
that
touches
data
and
that
actually
does
the
sort
of
byte
decompositions
recombinations
slicing
dicing
surgeries,
Etc,
and
then
you
have
these
consistency,
checks
that
I
told
you
earlier
about,
which
is
basically
finishing
the
the
memory
part.
C
B
Thank
you
for
the
this
very
extensive
description
of
what
is
a
constraint
system
on
the
arithmetization
and
now
I'm
going
to
talk
to
you
about
this
comeback.
Thank
you,
I'm,
going
to
talk
to
you
about
how
to
go
from
this.
Well,
let's
say
conceptual
data
to
how
we
actually
implement
the
whole
thing.
There
is
a
lot
of
challenges
when
we
want
to
go
from
the
specification
to
the
implementation
and
the
most
the
biggest
one
is
that
there
are
three
moving
Parts
on
the
one
on
we
have
the
actual
specification
250
Pages.
B
Then
we
have
the
implementation
of
the
specification
and
then
finally,
we
have
the
proof
system
of
the
verification
of
the
of
the
traces.
So
all
of
this
stuff
is
developed
by
different
people
working
on
different
teams.
We
still
need
to
maintain
100
Conformity
between
all
of
these
pieces.
So,
of
course,
if
the
approver
is
proving
something
else,
that's
what
the
spec
is
describing,
which
is
it's
itself
something
else
that
what
is
actually
implemented.
Nothing
will
work.
And
finally,
he
starts
to
audit
three
diverging
code
bases
or
three
diverging
sources
of
data.
B
So
what
kind
of
solution
did
we
find?
We
developed
a
formalized
single
source
of
Truth,
which
is
then
exported
to
multiple
targets?
So
what
happened
is
that
we
have
in
some
formats
that
I
will
show
you
in
a
few
seconds,
a
description
of
all
of
this
constraint
system
and
from
this
single
source
of
data.
We
are
able
to
produce
first
Google
library,
defining
the
constraints
on
the
data
that
will
be
in
the
that
will
then
be
used
by
the
approver
to
to
actually
prove
staff.
B
Then
we
have
another
good
library
that
is
used
by
the
ZK
VM
implementation
to
ensure
Conformity
with
the
specification
and
finally,
we
can
generate
latex
data
for
integration
within
the
final
specification
document
on
the
215
pages
of
PDF.
So
here
is
how
it
looks,
so
you
can
see
that
this
is
a
very
clearly
lesbians,
very
inspired
languages,
with
a
lot
of
parentheses,
all
other
kind
of
stuff-
and
this
is
a
very
simplified
example
of
what
you
could
find,
for
example,
in
all
of
the
mmu.
So
what
do
we
have
in
this?
B
First,
we
have
the
columns
definition.
Those
are
like
The
Columns
of
the
matrices
that
Olivia
show
you
a
few
minutes
ago,
and
you
can
see
that,
as
you
can
either
be
normal,
like
the
one
at
the
top
or
they
can
be.
We
have
a
very
rough
typing
system
type
systems
that
is
used
for
some
optimization
and
finally,
for
the
pure
pure
ease
of
implementation
on
ease
of
use.
B
We
have
some
kind
of
very
simple
array
that
kind
of
stuff,
so
yeah
afterward,
you
have
helper
fractions,
which
are
functions
that
can
be
well
defined,
like
any
other
list
function
to
act
on
these
data
and
for
instance,
here
you
have
two
functions.
The
first
one
is
checking
the
two
arrays
of
length.
Eight
are
actually
element
twice
equal
one,
two,
zero
zero
on
the
other
one
is
Computing
the.
If
we're
checking
that
an
array
of
eight
elements
is
actually
a
by
decomposition
of
a
given
value.
B
So
so
do
these
do
not
really
exist
per
se,
but
they
are
just
like
smaller
syntactic
sugar
for
the
ease
of
implementation.
And
finally,
we
have
the
the
meat
of
the
the
meat
of
the
data,
which
is
the
constraints
themselves.
So
here
we
have
an
example
of
two
three
constraints,
so
the
first
one
is
doing
a
practical
position
of
some
data.
B
So
here
you
are,
for
instance,
a
piece
of
a
piece
of
latex
card
on
the
PDF,
rendering
that
is
ready
to
be
incorporated
in
the
spec,
so
this
whole
stuff
that
we
call
corset
is
really
a
Cornerstone
in
our
work
workflow
on
the
our
implementation
of
the
ZK.
Now
I
will
talk
to
you
about
some
results
that
we
have
reached
for
now
from
the
specification
to
the
implementation
to
the
actual
results.
So
the
first
thing
we
want
to
Benchmark
our
implementation
against
is
the
evm
test.
Suite.
Of
course,
the
event.
B
The
suite
is
a
golden
Center
for
ethereum
clients,
including,
but
not
traffic,
not
restricted
to
the
evm
itself.
So
we
have
tested
our
current
implementation
of
the
zkvm,
which
is
well
Advanced,
but
not
yet
finished.
So
for
now
you
see
see
here's
a
list
of
modules
that
are
ready,
so
we
have
the
Hub
the
mm
views.
The
ROM
they'll
use
the
binary
on
some
comparator
functions
and
on
over
17
000
tests.
B
We
run
our
evm
on
this
and
16
000
are
success,
so
it
means
that
it
runs
on
the
traces
are
validated,
zero
are
failing,
so
it
means
that
we
do
not
have
any
problem
handling
this
this
test
and
finally,
we
have
1
303,
which
are
heating
functions
that
are
not
implemented
in
the
in
the
area
in
the
ZK
VM,
namely
in
this
case
the
pre-compass
contracts
on
the
self-destructure
operation.
So
for
now
we
have
a
92.6
percent
success
rate
on
the
evm
test.
Suite,
which
is,
we
believe,
a
good
start.
B
Another
way
to
test
and
to
Benchmark
or
implementation
is,
of
course,
to
work
on
real
data
right.
So
we
have
quite
a
few
real-world
examples,
but
the
most
striking
one
we
have
each
is
I
believe
the
successful
execution,
validation
of
proof
of
exemptions
using
the
units
of
contract
and
the
successful
execution
and
validation
of
random
magnet
block.
B
So
what
we
do
is
that
we
run
our
ethereum
client
on
the
main
net
and
we
generate
traces
for
some
blocks
there
on
there
and
then
we
validate
all
of
the
constraints,
so
I
will
show
you
a
little
bit
about
this
work.
We
are
going
to
check
the
verifications
of
the
constraint
of
the
on
the
traces
we
generated
for
this
block,
0x35b7
E90
blah
blah
blah.
This
block
was
created
yesterday
in
the
afternoon.
So
let
us
start
on
the
while
it
is
working.
I
will
show
you
a
little
bit
of
what
is
in
this
block.
B
So
here
is
the
data
or
network
scan
of
this
block.
As
you
can
see,
it
is
like
a
2023
house.
All
we
have
quite
a
lot
of
different
transaction
in
it,
so
we
have
a
basic
transfer
transaction.
We
have
some
wrap
stuff.
We
have
some
multi-call,
we
have
filling
transaction,
we
have
successful
transaction.
We
have
uni
swap
we
have
teaser.
So
it's
quite
a
nice
example.
It's
not
a
very
big
block.
B
It
has
only
52
transactions,
if
remember
correctly,
and
it's
only
using
two
million
guys
on
the
half,
but
it
is
still
quite
quite
inclusive
in
what
it
what
it
provides.
If
we
take
a
quick
look
at
the
traces
that
we
generate
for
this
block,
so
here
you
have
a
decomposition
of
all
the
other
data
that
we
generate
for
this
block.
B
So
on
the
very
big
red
stuff
at
the
top
of
the
screen,
you
can
see
that
in
the
end
we
generate
certain-
let's
say:
13
13
and
a
half
million
of
cells,
so
which
is
like
the
actual
content
of
the
traces.
You
can
see
that
the
biggest
one
are
the
binary
with
2.5
million
of
cells.
Then
you
have
the
ROM.
Sorry,
it's
a
ROM
first
with
five
Millions,
then
the
binary
with
two
million
and
a
half
the
Hub,
which
is
also
before
the
binary.
B
Sorry
with
three
millions
and
all
of
that
is
culminating
into
13
million
of
cells
that
have
to
be
proved
unchecked
and
then
cryptographically
checked.
So
here
we
can
see
that
corset
is
actually
doing
a
very
naive
check
of
all
of
this,
because
it
will
basically
just
run
all
of
the
numeric
numeric
constraints
that
we
defined
on
all
of
the
lines
on
rows
of
the
Matrix
one
by
one,
which
is
obviously
very
sub-optimal,
absolutely
not
cryptographic.
B
But
this
is
only
debugging
tools
that
I
show
you
for
to
to
prove
you
that
our
staff
is
still
working
and,
as
you
can
see,
the
validation
is
successful
on
the
Block.
0X35Be
is
actually
validated
with
all
our
constraints
on
our
evm,
we'll
be
able
to
give
all
of
this
data
to
the
proverb
on
the
proverb
will
be
able
to
generate
the
proof
and
put
it
on
the
main
chain.
Now
going
back
to
the
to
the
presentation.
So
sorry
I
can't
play
because
no
Wi-fi,
so
you
will
have
the
development
version
so
in.
B
B
D
B
Sixes,
all
of
the
the
three
components
with
a
single
single
audit
and
finally,
regarding
performances.
We
are
now
connected
to
the
program
system
and
there
will
be
more
more
information
regarding
that
soon
on
the
in
a
in
a
coming
paper.
So
thank
you
for
our
attention.
We
will
be
launching
a
testness
soon,
so,
if
you
want
to
join,
please
just
scan
the
stuff
or
just
go
to
the
to
the
URL,
and
if
you
have
any
questions
and
we
will
be
happy
to
take
them.
C
C
Arithmetization
is
also
going
to
be
very
different
and
I
think
this
probably
represents
actually
a
strength
overall,
not
for
us
in
particular,
but
for
the
ZK
evm
ecosystem
as
a
whole.
Keeping
in
line
with
this
multi
zkv
improve
a
future
that
vitalik
has
been
talking
about,
but
in
terms
of
concrete
details,
I'm
I'm
not
quite
aware.
B
Regarding
control
details,
the
big
difference
with
scroll
is,
let's
say
the
arithmetician
method
that
the
the
web,
the
both
of
us,
are
using
different
methods
and
we
will
see
which
one
will
sustain
the
test
of
time
on
regarding
the
difference
with
polygon
Hermes.
The
main
difference
is
that
a
polygon,
contrary
to
us,
doesn't
directly
works
on
evm
byte
code,
but
the
first
one
says
the
evm
byte
code
into
another
byte
code
that
is
running
not
on
the
evm
but
on
adock
register
machine
which
is
Zen
approved.
C
You
may
be
surprised,
but
call
data
load
has
been
horrible.
You
would
expect
if
you
do,
if
you
can
do
a
m
load,
you
can
do
a
call
data
load,
but
in
the
way
that
we
arithmetize
things
it's
actually
quite
difficult
because
of
the
provenance
of
the
data
and
the
fact
that
there's
some
padding
involved,
but
in
terms
of
the
real
complexity,
the
real
complexity
is
actually
for
anything
that
involves
writing
a
whole
lot
of
data
with
padding,
potentially
so
anything
such
as
code
copy,
xcode
copy,
I,
don't
know
yeah.