►
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/stateless-ethereum-how-verkle-trees-make-ethereum-lean-and-mean/
This talk goes over the changes brought by verkle trees. It will give a high-level overview of the technical changes, an update on the implementation of verkle trees, and paint a picture of a stateless Ethereum.
Speaker(s): Guillaume Ballet
Skill level: Intermediate
Track: Layer 1 Protocol
Keywords: verkle,stateless,state
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
So
yeah,
why
do
we?
What
do
we?
Why
are
we
considering
vertical
trees?
It's
basically
a
big
change
in
the
in
the
way
ethereum
functions.
So
what
do
we
want
to
risk
this?
Well,
there
are
several
reasons.
The
the
first
one
is.
We
want
to
be
able
to
build
blocks
as
a
self-contained
execution
units.
At
the
moment,
ethereum
has
a
bit
of
a
problem
that
when
you
want
to
join
the
network
or
if
you
haven't
followed
the
network
for
a
while,
you
need
to
go
through
a
process.
That's
called
the
sync
synchronization.
A
You
cannot
access
the
state
directly.
It's
like
you
cannot
just
down
download
the
state.
I
mean
you
can't
download
the
state,
but
it
it's
a
fairly
convoluted
process.
So
the
idea
is
that,
if
you
include
in
the
block
everything
that
you
need,
you
can
just
download
the
block
and
execute
it
and
see
if
you're
interested
like
even
before
you,
if,
even
if,
before
you
execute
the
block,
you
can
even
know
if
it's
going
to
be
of
interest
to
you
or
not,
and
if
it's
of
interest
to
you,
you
can
execute
it.
A
Otherwise
you
don't
even
have
to
to
care.
So
it's
something
that
is
it's
to
build,
something
that
is
in
between
a
full
client
and
like
a
full
node
and
a
light
client
in
the
sense
that
you
are
still
supposed
to
follow
blogs.
But
you
don't
have
to
hold
the
entire
State
and
it's
nice
because
it
paves
the
way
for
other
upgrades
or
it
makes
other
upgrades
a
bit
simpler.
A
For
example,
if
you
want
to
shuffle
committees
between
between
shards
in
the
future,
you
want
shards,
you
don't
want
shards
to
full
short
validators
to
keep
following
the
chain
at
all
times,
like
several
chains
at
all
time.
So
it's
something
that's
going
to
help
them
get
up
to
speed
a
bit
faster
and,
of
course,
there's
the
the
idea
of
State
expiry
like
the
state
of
ethereum
is
quite
large,
so
we
want
to
be
able
to
delete
some
of
the
states,
but
we
don't
want
to
delete
and
forget
forever
if
your
state
has
been
deleted.
A
But
you
want
to
use
it
again.
You
need
a
you.
You
need
to
provide
a
proof
to
resurrect
your
state
and
the
idea
is
that
vertical
trees
make
your
proofs
smaller,
so
it
will
be
cheaper
for
you
to
resurrect
the
state
so
because
it's
a
fairly
like
deeply
technical
topic,
I
have
tried
to
re
to
make
a
simpler
explanation
with
pirates.
A
The
problem
is
inheritance
if
one
of
the
Pirates
wants
to
retire
and,
for
example,
wants
to
to
sell
you
his
bit
of
the
of
of
the
map.
How
do
you
know
he's
not
selling
you
a
fake
map,
a
fake
piece
of
the
map
he's
a
pirate.
After
all,
so
you
should
be
careful
well,
the
problem
with
this,
the
method
that
was
chosen
to
figure
that
out.
You
need
at
least
the
other
two
Pirates
to
check
that
the
the
pattern
matches
the
proof
size
is
quite
involved.
A
A
So,
of
course
we
don't
use
pieces
of
paper,
we
we
use
cryptography
as
stronger
cryptography
than
this,
and
now
this
is
your
proof
size.
And
so
how
do
you
transpose
this
to
vocal
trees?
Well,
the
current
ethereum
state
is
stored
in
a
tree
where
all
the
data
of
ethereum
is
at
the
bottom
of
the
tree,
and
then
you
group
them.
The
parent
is
a
commitment.
A
Don't
remember
exactly
so.
That's
a
lot
of
data.
That's
roughly!
If
you
want
to
pass
the
that
data
in
a
block.
That's
three
megabytes.
We
are
in
Bitcoin
territory,
so
yeah.
It's
a
bit
too
big
to
pass
around
the
network
in
a
reasonable
time.
If
you
use
the
Virgo
commitment,
so
you
have
the
equivalent,
like
you
still
have
the
oops.
That
doesn't
say.
A
Yes,
you
have
the
the
little
cryptographic
proof,
but
all
you
all
you
have
to
pass
as
as
your
proof
is
the
the
nodes
along
the
way
to
your
value,
and
that
is
much
smaller.
First
of
all,
because
you
don't
pass
the
siblings,
but
on
top
of
that,
because
you
don't
pass
siblings,
there's
a
virtual
cycle
that
allows
you
to
widen
the
tree,
you
can
have
more
children
per
tree
and
per
per
node
and
as
a
result,
the
tree
gets
shallower.
So
your
path
is
even
smaller,
even
shorter
and,
as
a
result,
your
proof
is.
A
Is
that
much
smaller?
So
there's
a
unfortunately
it's
not
that
simple,
there's
quite
a
few
changes
to
to
introduce
at
the
same
time
like
the
first
one
is
putting
the
proofs
in
the
block.
That's
that's
that's
the
whole
point,
but
we
also
need
to
change
the
tree
structure
and
I'm
not
gonna,
get
too
deep
into
the
details,
because
once
again
it's
quite
involved.
There's
an
EIP
there
are
other
talks
about
it.
A
Look
at
them,
look
them
up
if
you're
interested,
but
the
idea
is
that
all
the
data
ends
up
in
a
single
tree.
So
currently
accounts
have
their
own
tree
and
for
each
account
you
have
the
another
tree
that
encodes
the
storage
for
this
account.
Well,
here
everything
is
kind
of
yeah,
hashed
or
mixed
together
and
spread
over
the
tree.
A
Each
item
like
each
account
item,
for
example,
the
balance,
the
nons
the
code,
the
any
any
slot
like,
for
example,
if
you're
thinking
of
crypto
Kitty
each
cat
is
accessed
independently,
because
we
don't
want
to
add
more
to
the
proof
that
is
required.
So,
if
I'm
sending
funds
to
to
a
new
address,
well,
I
just
need
the
address.
A
The
target
address,
balance
I,
don't
need
to
know
how
many,
how
much
code
they
have
I'm
only
interested
in
in
the
funds
right
and
like
I
was
saying
the
data
is
spread
all
over
the
tree,
but
we
are
trying
to
group
things
that
belong
together
a
little
bit
so
that
you
don't
spend
your
time
jumping
all
over
the
tree
all
the
time.
So
it's
grouped
in
batches
of
256
and
I'm
going
to
go
over
that
in
just
just
a
bit.
A
So
this
is
a
picture
that
comes
from
the
EIP
itself,
I'm
going
to
describe
on
the
left
side.
You've
got
What's
called
the
stem
tree
and
it's
the
basically
the
top
of
the
tree.
So
the
tree
is
flipped
to
the
side.
It's
rotating
90
degrees,
to
the
to
the
left
and
the
route.
Sorry,
the
the
stem
tree
only
has
a
branch
node.
So
that
means
every
node
in
that
tree
has
at
least
two
children
when
the
when
you
take
your
key
and
you
follow
the
you
follow
the
the
past
Trace
by
the
key.
A
At
some
point,
you
will
reach
a
moment
where
there's
only
one
group
that
is
a
group
of
256
that
is
pointed
out
by
this
key.
So
there's
this
intermediate
like
what's
called
an
extension
yeah
I,
don't
quite
see
the
pointer
here,
sorry,
but
the
blue,
the
blue
box,
that
the
extension
says
this
is
the
prefix,
the
31
byte
prefix,
that
every
key
below
me
have
like
are
keyed
by.
A
So
that
means
that
if
when,
when
you
go
through
the
tree
and
you
come,
you
have
to
compare
the
key
that
you're
using
with
the
the
encoding,
the
the
key
encoded
in
that
blue
box,
and
if
it's
the
same,
that
means
your
data
is
in
the
group
below
it.
Otherwise,
your
your
data
is
not
present
in
a
tree
and
then
there's
the
suffix
tree,
so
that
corresponds
to
the
256
values
and
there's
a
force
column
that
we're
not
going
to
cover.
It's
not
really
important.
A
For
for
this
talk
so,
like
I
said,
every
every
piece
of
data
is
broken
into
chunk.
That
means,
for
example,
the
code
is
broken
into
bits
into
31
byte
pieces
that
are
fitted
in
a
32
byte
piece.
The
storage
slots
are
also
have
their
own
on
at
their
own
data.
The
the
balance
has
its
own
value
and
each
of
these
values
each
of
these
chunks
is
given
an
offset
and,
for
example,
the
the
the
balance
is
always
offset
one,
the
non-set
offset
two
and
then
a
bit
further.
A
You
have
the
beginning
of
where
the
code
is
supposed
to
start
and
then
even
further.
You
have
the
the
bits
where
the
all
the
data
slots
are
are
supposed
to
to
be
and
the
way
you
find
them
in
the
tree
is
you
take
the
address
of
so
you
have
a
key
that
is
made
of
two
two
parts.
The
the
31st
bytes
are
called
the
stem
and
the
suffix.
It's
just
a
byte
that
indexes
in
the
group
that
we
saw
before
I'm
talking
about
the
the
third
column
here.
A
So
the
the
last
byte
is
the
index
in
there
and
and
so
to
build
the
stem.
What
you
do
is
you
take
the
address
of
the
account
and
you
take
the
the
first
31
bytes
of
the
the
offset
of
that
chunk
and
you
you
hash
them
using
what's
called
a
Pederson
hash,
so
it's
like
it's
like
catch
Shack,
but
it's
much
more
friendly
for
for
ZK
applications
and
it's
also
much
slower.
But
you
get
you
so
you
get
a
32
byte
values.
A
You
take
the
the
31st
bytes
of
this
value,
and
that
gives
you
the
stem
and
the
way
you
use
it.
When
you
compare
it
to
the
tree,
the
stem
will
give
you
the
pass
through
the
stem
tree
and
the
extension,
and
when
you
you
found
that
you
use
the
suffix
to
select
the
the
value
in
the
group.
So,
like
I
said
just
a
recap:
vertical
trees
are
are
nice
because
you
can
make
the
tree
much
larger,
much
smaller,
much
more
shallow.
A
Sorry,
you
can
also
experiment
with
with
ideas
like
you
could
sing.
So
I
know
that
this
is
very
interesting
to
dub
developers.
You
can
just
download
the
blockchain,
not
care
about
the
state,
and
when
you
look
at
the
when
you
look
at
the
proof
in
the
block
at
the
witness
you
can,
you
can
figure
out
if
you're,
if
that
block,
is
accessing
something
you're
interested
excuse
me
interested
in
so,
for
example,
if
yeah,
if
your
crypto
Kitty,
you
want
to
see
if
the
crypto
Kitty
contract
is
accessed.
A
A
We
have
one
and
a
half
running
test,
Nets
the
we
have
one
test
net
that
is
fully
working.
It's
a
proof
of
work,
test,
net
called
I'll,
give
the
address
at
the
end
and
so
proof
in
blocks
it
works.
It
works,
it's
been
working
for
a
while
and
then
there's
a
proof
of
stake
test
net
that
is
currently
in
bring
up
phase,
so,
unfortunately,
I
wasn't
able
to
get
it
to
to
work
for
for
Defcon.
But
it's
going
to
happen
shortly.
A
When
we
do
performance,
we
currently
have
like
performance
testing.
We
see
that
is
currently
five
times
slower
than
a
regular
magnet.
So
when
we
replay
blocks
from
Main
mainnet
on
a
translated
vertical
tree
layer,
it's
five
times
slower,
we
have
been,
we
took
it
down,
it
used
to
be
40x.
So
it's
it's
a
bit
faster
already.
We
have
another
Avenue
to
to
make
it
faster,
but
it's
I
mean,
in
my
opinion,
it's
all
is
going
to
be
a
bit
slower
than
the
current
method,
but
it
offers
some
opportunities
to
to
build
interesting
applications.
A
So
I
think
it's
worth
it
and
they
are.
There
are
like
three
implementations
and
there's
a
fourth
one
ongoing
with
with
Basu,
so
I
wanted
to
I,
don't
know
if
it's
quite
readable
but
I
wanted
to
give
an
example
of
what
you
can
do
with
vertical
trees.
So
there's
a
block
Explorer
on
on
that
test,
net
on
the
running
test
net
and
there's
a
piece
of
software
that
is
able
to
read
the
block
and
reconstruct
a
view
of
the
network.
Sorry
of
the
tree.
A
That
is
everything
you
know
to
re-execute
the
block
on
top
of
it.
So
I,
don't
know
if
it's
quite
visible,
I
still
don't
see
the
pointer,
but
basically
you
can
see
that
the
the
leftmost
branch
here
is
an
account.
The
the
next
brand,
the
branch
the
right
of
it
is
another
account.
I
mean
I
can
tell,
because,
because
of
the
way
the
the
last
level
looks
like
and
you
have
the
the
other
two
branches
from
the
root.
These
do
not
have
a
very
deep
tree,
and
that's
because
this
is
a
proof
of
absence.
A
So
that
means
this
is
the
way
you
signal
that
those
branches,
those
locations
did
not
exist
before
the
execution
of
the
block,
and
what
definitely
happened
here
is
that
those
two
accounts
on
the
left
probably
send
funds
to
those
two
accounts
on
the
right
that
did
not
exist
yet
and
that
they
will
exist
after
the
the
execution
of
the
block.
So
it's
quite
interesting
because
you
you
can
see
what's
going
on,
you
can
visualize
it
this
way
without
loading
the
whole
tree
right.
So
this
is
the
current
state.
A
What
are
the
challenges
we
still
have
to
overcome?
One
of
them
is
the
transition.
Converting
a
Merkle
tree
to
a
vertical
tree
is
no
there's
no
walk
in
the
park.
It
requires
a
lot
of
ram.
It
requires
a
lot
of
this
space
and
yeah.
It's
it's
it's
quite
difficult.
So
there
are
two
methods
really
two
Avenues
to
do
this.
This
translation
either
untrust
the
conversion
to
very
powerful
machines.
A
A
A
The
one
where,
like
you,
follow
the
pace
of
the
network,
it's
called
the
overlay
tree,
the
other
one
was
called
offline
conversion,
there's
a
third
one
that
is
known
as
the
roll-up
Appreciation
Week,
where
you
just
do
nothing
for
a
week
or
a
month,
and
you
wait
for
everybody
to
be
done.
Translating
that's
it's
just
here,
because
it's
a
cool
name,
no
one's
really
considering
that
yeah
one
last
thing
I
wanted
to
say
about
this
slide
is
pre-images.
A
So
most
of
most
clients,
including
guests,
do
not
encode
the
addresses
directly.
They
just
write
the
the
hash
of
those
those
addresses
so
to
do
the
translation
and
because
we
use
a
different
hash
system,
we
need
the
pre-images.
It
turns
out
that
most
clients
do
not
store
that
Aragon
does,
but
the
rest
of
them
don't
so
pre-image
availability
is
another
problem
that
needs
to
be
needs
to
be
addressed,
and
it's
not
a
it's
not
an
easy
one.
A
Another
thing
is
the
slower
cryptographic
Primitives,
it's
not
as
fast
as
ketchak,
so
this
is
one
of
the
latest
runs,
and
you
can
see
that
roughly
30
33
35
is
spent
just
doing
elliptic
curve
operations,
so
cryptographic
Primitives
is
really
where
the
well.
The
effort
needs
to
be.
The
optimization
effort
needs
to
be
made
so
either
by
writing
faster
crypto
or
by
by
not
calling
those
functions
as
much
so
caching,
for
example,
is,
is
a
technique
that
has
worked
well,
yeah,
there's
a
slide
on
database
design.
A
So
basically,
the
idea
is
that
that,
like
current,
most
clients
have
written
their
optimized,
their
database
layout
and
their
database
access
layer
for
the
current
MPT.
A
lot
of
those
assumptions
are
no
longer
valid.
Let
alone
help
helpful
with
vertical
trees,
so
there
will
be
some
need
to
adapt
to
something
that
is
a
bit
close
to
to
what
Aragon
is
doing,
but
that
will
take
time,
unfortunately,
and
I
wanted
to
finish
on
people
on
what
you
can
do.
If
you
want
to
help,
the
first
thing
would
be
there.
A
If
you
can
also
try
to
run
your
own
client
like
hashtag
testing,
The
Verge,
you
can
also
modify
a
CL
client
to
figure
out
how
to
propagate
the
proofs,
because
currently
it's
not
it
hasn't
been
defined.
So
it
would
be
interesting
to
to
run
a
fact-finding
mission
yeah
finding
out
where
and
how
the
proofs
need
to
be
need
to
be
propagated
in
a
in
a
proof
of
stake.
A
World
like
I
said
crypto
is
the
is
the
bottleneck,
so
if
you
can
find
a
better
crypto
cryptographic
primitive
than
what
we
have,
that
would
be
also
quite
helpful.
Yeah.
It's
also
going
to
affect
Layer
Two
Solutions,
like
presumably
Layer
Two
layer.
Two
groups
don't
really
want
to
to
diverge
too
much
from
from
the
main
net,
so
they
will
need
to.
They
will
need
to
to
adapt
as
well.
There's,
no
really
there's
not
a
clear
path
for
that.
A
Yet,
like
I
said,
pre-images
are
also
a
problem,
so
if
you
have
a
way
to
to
make
pre-images
available
to
everyone,
that's
a
very
good.
That's
a
very
good
test,
very
useful,
and
then
you
can
go
crazy.
You
can
try
to
prototype
the
interaction
of
vertical
tree
with
the
portal
network,
with
try
to
implement
Statics
by
reusing
vertical
trees.
All
of
that,
no,
no,
no!
No.
B
Thank
you
so
much
Guillaume.
Do
you
mind
taking
a
minute
to
answer
our
questions?
If
you
do
have
any
questions
for
Guillaume
go
ahead
and
raise
your
hand
and
one
of
the
volunteers
will
actually
come
towards
you
there's
a
question
right
there
in
the
fourth
row
of
fifth
row
with
the
black
sweatshirt,
you.
C
A
No,
it
doesn't
mean
that,
but
it
means
that
the
gas
model
is
going
to
change
to
to
follow
this.
This
new
model,
which
is
why
I
was
like
if
you've
got
a
contract,
please
deploy
it
on
the
test
net,
but
you
do
not
need
access
lists
are
going
to
disappear,
they're
replaced
by
something
else
that
is
not
really
exposed
to
the
to
the
to
the
user
so
to
for
the
end
user.
In
theory,
apart
from
the
gas
cost,
everything
will
be
transparent.
Oh.
B
A
There's
plenty
of
drawbacks,
like
I,
said:
there's
the
the
transition,
the
the
slow
crypto.
Otherwise,
yes,
like
the
biggest
drawback
I
only
alluded
to
in
the
previous
sensor.
It's
that
the
gas
model
changes,
and
that
means
that
a
lot
of
code
you
know
like
contracts
into
some
contracts
than
to
be
very
optimized
for
gas.
Those
optimization
can
turn
out
to
be
completely
Obsolete
and
counterproductive.
So
that
I
would
say:
that's
that's.
The
biggest
drawback
I
can
think
of.