►
From YouTube: Sina Mahmoodi - Stateless Ethereum
Description
Berlin Ethereum Meetup - February 2020 Edition
B
So
this
is
Cena,
and
this
will
be
kind
of
like
a
li
reminder.
Kind
of
talk,
I've
been
following
the
ethnics
and
state
conversation
closely,
and
here
I
will
mention
a
few
like
I
will
first
give
an
introduction
or
very
lightening
intro
to
stateless
aetherium
and
what
kind
of
changes
we
can
probably
expect
and
then
how
it
could
influence
contract
development
like
if
you
are
designing
a
smart
contract.
What
should
you
have
in
mind
like
if
you
want
to
have
it
future
proof
when
stateless
aetherium
hits?
B
B
Among
other
goals
is
targeting
reduce
storage
requirements
for
at
least
some
some
of
the
nodes
and
hopefully
improve
like
sink
sink
times
like
block
processing
times,
and
the
goal
is
to
do
it
by
introducing
a
new
kind
of
client,
which
is
called
a
stateless
client,
and
these
clients
do
not
store
the
whole
state.
They
only
store
parts
of
the
state
that
they
care
about,
and
they
depend
on
miners
who
who
additionally,
like
so
miners
right
now.
B
B
That's
that
prove
their
validity
and-
and
they
include
these
witnesses
in
the
blog,
so
that
stateless
clients,
when
they
receive
the
block
and
the
witness
they
can
make
sure
that
the
these
parts
of
the
state
are
valid
and
they
can
run
the
transactions
against
them,
and
this
is
an
example
of
a
block
witness,
and
this
is
not
a
big
block
like
it's
one
of
the
smaller
blocks.
You
can
see
the
tree
structure.
You
can
see
those
orange
boxes
they
are
hashes
here
down
here
are
the
leaves,
and
this
big
thing
is
a
contract
code.
B
So
when
you
make
a
block
witness,
you
need
to
send
all
of
the
accounts
that
are
needed
for
these
transactions.
All
of
the
storage
items
all
of
the
contract
codes,
so
you
can
assume
that
this
will
introduce
a
lot
of
network
overhead,
and
here
is
like
over
a
list
of
recent
blocks
like
from
8
million,
something
to
to
9
million.
B
How
much
these
these
block
witnesses
like
what
what's
their
size-
and
this
is
an
average
average
over
128
blocks
each
point.
So
there
can
be
like
we
have
blocks
that
have
block
witness
of
3
megabytes,
but
sometimes,
if
it's
lower
so
so
up
there.
The
blue
is
the
total,
and
then
you
have
all
the
hashes
that
are
necessary
for
the
Merkel
proofs,
and
then
you
have
like
the
orange
ones.
Is
the
contract
code
that
you
have
to
send
and
down
here
are
the
actual
values
there.
B
So
so
you
can
see
that
the
values
are
not
much,
it's
mainly
dominated
by
contract
code
and
proof
hashes.
So
the
key
takeaway
here
is
that
when
we
switch
to
stateless
aetherium,
then,
although
you
know
some
knows
won't
need
to
store
much,
but
the
network
overhead
will
increase
by
quite
a
lot
and
to
to
make
some
optimization
on
the
network
overhead.
There
are
some
changes
like
some
possible
changes
being
considered.
One
is
to
change
the
tree
structure
of
aetherium
right
now.
B
Medicalization
and
I
will
talk
about
this
in
more
detail
in
a
TCCC.
So
if
you're
curious
check
it
out
code,
my
digits
of
code
medicalization,
is
that
four
four
four
one
transaction
you
don't
need.
You
know
you
don't
need
the
whole
contract
code
like
if
you
want
to
transact
with
makers
at
all.
You
don't
need
the
whole
thing.
You
just
need
one
function,
for
example,
so
here
we
we
break
contract
code
into
chunks,
make
tree
out
of
it
and
then
for
every
transaction.
B
So
because
every
time
you
do
an
S
load
or
a
balance
or
any
of
the
up
codes
that
touch
a
part
of
the
state
miners
would
have
to
include
a
Merkel
proof
for
that.
So
this
means
that
any
state
accessing
up
code
introduces
now
a
lot
of
additional
overhead,
and
it
means
that
the
gas
prices
would
have
to
be
increased.
B
The
other
thing
is
that,
as
we
saw
recently,
it's
it's
very
hard
to
predict
what
the
actual
gas
costs
of
an
app
code
should
be,
and
over
the
course
of
a
theorems
life.
Gasca's
prices
have
changed
a
few
times,
so
something
that's
being
considered
and-
and
this
has
led
to
breaking
some
of
the
contracts
like
with
AIP
1884,
which
broke
some
of
the
contracts.
B
So
so
the
goal
here
with
ungass
is
to
disable
contracts
from
observing
gas
in
their
contracts.
So
you
wouldn't
be
able
to
know
how
much
gas
has
been
so
far
spent
in
this
transaction
and
how
much
is
left
and
the
other
one
that
is
not
directly
related
to
stateless
etherium.
But
it's
kind
of
related
is
chain
pruning.
This
is
a
separate
proposal
because
so
again
full
loads.
They
have
to
store
all
of
the
blocks.
B
Similarly,
for
balance
and
other
output,
it
will
have
to
increase
to
2400.
This
is
to
prevent
some
some
some
blocks
that
can
basically
dass
the
network,
because
you
have
to
for
every
like
every
time
you
do
an
S
load.
We
have
to
include
a
miracle
proof
in
the
block
which
introduces
a
lot
of
data,
so
we
have
to
kind
of
price
it
in
a
way
that
we
can
target
a
maximum
block
size
like
we
don't
want
blocks
to
become
ten
megabytes
or
twenty
megabytes
or
something
we
want
to
limit
them
to.
B
Let's
say
three
megabytes,
so
we
have
to
price
the
state
accessing
up
codes
in
a
way
that
we
can.
We
can
limit
it
as
such.
So
this
is
what
this
is.
One
approach
to
to
pricing
states
accessing
up
codes.
The
other
approach
is
to
price
it
based
on
the
actual
proof
size
that
they
they
induce
on
the
network.
B
So
let's
say
I
have
a
contract
that
only
has
one
storage
slot
the
proof
that
would
need
to
be
included
for
this.
One
storage
slot
is
quite
small.
You
just
need
one
leaf,
but
on
the
other
hand,
I
have
a
contract
that
has
a
million
storage
slots,
which
means
a
tree
of
depth
are
on
a
large
tree,
and
so
each
time
that
contract
does
is
less
load,
a
large
proof
would
have
to
be
included.
B
So
this
is
an
alternative
way
of
pricing,
but
this
would
kind
of
discourage
big
storage
for
contracts
like
contracts
that
have
a
big
storage
would
have
to
pay
more
for
for
storage.
It's
also
very
hard
to
estimate
because
you
can
estimate
for,
like
any
timelike
s,
load
up
code
is
executed,
but
on
the
other
hand,
at
the
end
of
the
block.
We
are
kind
of
aggregating
these
proofs
together,
which
we
get
some
saving
from.
B
So
it's
hard
to
estimate
at
the
time
of
execution
how
much
this
this
s
load
will
actually
add
to
to
about
data.
So
we
have
these
two
approaches
to
two
storage
up
code,
and
then
we
have
the
contract
code.
So
anytime,
you
do
a
call
or
an
X
code
hash
or
something
the
code
for
the
whole
contract
that
you're
calling
has
to
be
included
in
the
in
the
block,
which,
which
can
be
quite
a
lot
like.
B
If
you
imagine,
the
limit
for
contract
size
is
24
kilobytes
right
now,
so
I
can
I
can
create
a
like
a
contract.
That
does
thousands
of
calls,
and
this
would
mean
that
I
that
I
can
I
think
eventually
in
his
post
bitterly
estimated
it
you
couldn't,
you
can
craft
a
transaction
that
induces
a
block
size
of
300
megabytes,
which
is
quite
a
lot
like.
We
don't
want
that.
B
So
one
option
is
to
charge
gas
for
every
byte
of
contract
code
like
if
you,
if
you're
calling
a
contract
that
has
100
hundred
bytes,
you
would
pay
300
gas
for
it.
If
it's
a
contract
that
has
24
kilobytes,
then
you
would
have
to
pay
70
to
kill
72,000
gas
for
calling
that
contract
so,
depending
on
the
size
of
the
contract
that
you're
calling
you
would
have
to
pay
more.
The
other
approach
is
to
go
down
the
Merkel
ization
route.
B
Yeah,
as
I
said,
so
these
are
things
that
you
shouldn't
be
assuming
when
you're
writing
a
smart
contract,
you
shouldn't
assume
the
prices
of
opcodes,
because
these
prices
can
change
and
they
could
therefore
possibly
break
your
contracts,
make
them
more
expensive.
You
shouldn't
rely
that
at
all
at
all,
I
try
to
not
assume
any
any
gas
prices.
The
other
thing
is
like
you
shouldn't
for
now.
B
B
So
even
before
aetherium
itself
becomes
stateless,
you
can
write
status
contracts
and
they
would
be
like
you
have
a
contract
that
doesn't
store
anything
but
a
32,
byte
hash,
and
this
hash
would
be
the
root
of
a
tree
which
you
are
storing
off
chain,
not
in
the
contract
itself
and
every
time
that
you,
like
a
user,
sends
a
transaction
you
send
all
of
the
merkel
proofs
necessary
all
of
the
parts
of
the
tree
necessary
for
that
transaction
with
it.
So
let's
say
you
have
a
you
want
to
develop
a
stateless
token.
B
B
Can
you
can
think
that
the
ZK
roll-up
and
similar
contracts?
They
are
stateless
contracts?
Zk
roll-up
only
stores
one
route,
but
does
the
only
difference
to
what
I'm
saying
would
be
that
they
are
doing
all
of
this
proof,
verification
and
transfer
by
zero
knowledge
proof,
but
but
you
don't
need
the
zero
knowledge
proof
really
and
and
something
that
could
help
with
with
this
approach
is
I
know
some
people
like
ballet
and
and
john
adler.
B
They
are
working
on
pre
compiles
for
proof,
verification,
and
if
these
pre
comp
eyes
come,
then
you
might
be
able
to
do
this
even
for
cheaper.
Today
so
yeah
in
short,
storage
prices
will
probably
increase
it's
not
clear
how
much
or
how
exactly
it
could
be
a
static
increase
in
in
gas
or
it
could
be
based
on
how
large
your
storage
is.
You
should
make
assumptions
about
gas.
B
B
C
B
I
I
have
to
say
that
I
just
wanted
to
like,
in
the
beginning
parts,
I
kind
of
gave
only
a
short
summary
of
what
stateless
a
theorem
is
all
about,
because
if
you're
going
to
eat
si
si,
you
will
probably
hear
about
it.
A
lot
I
like
I
just
wanted
to
focus
on
the
later
part,
which
is
how
it
affects
you,
yeah.
C
So
when
you,
when
you
talked
about
the
witness
that
I
need
to
transmit
with
every
transaction,
that
basically
my
transaction
becomes
the
whole
witness
and
like
the
actual
thing
that
that
I
want
to
do
yeah.
So
in
the
examples
of
like
the
pricing,
wouldn't
it
is
it
has
it
been
considered
that
just
the
size
of
the
witness
would
be
the
somehow
impacting
the
price,
because
that
seems
like
the
the
clearest
one
to
me.
If
the
your
goal
is
to
keep
the
block
size
at
a
certain
limit,
yeah.
B
That's
that's
here.
The
the
second
approach,
like
what
I
call
witness
size,
sensitive
pricing,
it's
basically
to
to
see
how
large
the
witness
is
and
charge
based
on
that.
But
but
the
problem
is
that
you
cannot
estimate
exactly
like
when
you're
trying
to
execute
in
the
transaction.
Let's
say:
you're
you're
running
EVM
bytecodes
like
when
you
reach
an
S
load.
B
At
that
point,
you
won't
know
how
many
other
merkel
proofs
would
have
to
be
included,
because
the
thing
is
like
you
can
you
can
estimate
the
price
of
one
branch,
but
at
the
end
of
the
block,
we
are
all
merging
all
of
these
into
one
big
proof
like
this
one.
So
you
would
get
quite
a
lot
of
saving
and
we
like
this
only
we
know
the
exact
size
only
at
the
end
of
the
block,
not
during
the
execution
of
a
transaction.
C
B
No,
so
this
is
like
with
the
stateless
client
approach.
You
don't
need
to
do
that
this
is
you
just
send
a
transaction?
The
miner
pick
will
pick
it
up,
and
the
miner
will
include
all
of
like
when
the
miner
wants
to
make
a
block
out
of
all
these
transactions
in
the
pool.
It
will
also
add
the
witness
to
the
block
itself,
so
users
won't
need
to
directly
send
include
the
proofs.
B
B
No,
no,
no
them
the
miners
will
be
saiful.
I
should
have
made
this
clear.
Miners
will
be
stateful.
It's
just
that
you
add
a
new
class
of
clients
that
are
fully
executed.
They
are
different
from
light
clients
in
that
they
can
fully
execute
or
fully
verify
the
chain.
They
can
start
verifying
from
the
genesis
and
they
will
they
will
receive
a
block
with
its
full
witness
verify
it
go
to
the
next
block
and
so
on,
but
these
are
a
new
kind
of
entity.
B
C
C
This
is
great
I.
Thank
you
for
that
information.
Yeah,
so
can
I
just
follow
up
with
one
more
stupid
question
there
like
if
I
run,
then
this
new
type
of
client
that
it's
not
doesn't
have
the
full
state,
then
I
can't
even
use
that
to
create
a
witness
for
my
transaction
right.
So
I
still
have
to
know
somebody
like
in
fora.
Oh
yeah,.
B
B
B
The
network
structure
would
have
to
change
and
the
the
stateless
clients
would
store
parts
of
the
state
that
they
care
about
like
if
I'm,
if
I'm
an
end-user
I
will
I
would
hold
my
my
own
account
or
all
of
my
accounts
in
in
my
storage
and
the
contracts
that
I'm
more
like
most
likely
will
interact
with
and
anytime
that
I'm
missing
part
of
the
sig,
like,
let's
say,
I,
want
to
interact
with
a
new
contract
that
I
haven't
interacted
with
before
then
I
ask
the
network?
Ok,
what's
this,
so
this
part
would
be
interactive.
B
Like
I
asked
some
some
of
my
peers.
Does
anyone
have
this
part
of
the
state
I
get
it
with
the
proof.
I
have
it
now
locally
and
then,
but
again
so
the
end
user
wouldn't
need
to
include
the
witness.
So
they
don't.
They
only
need
this
part
of
the
state
to
be
able
to
know
okay.
What
is
my
balance,
what
is
this
friends
balance?