►
Description
Resources:
Slides: https://vitalik.ca/files/EIP_2929_presentation.pdf
EIP-2930: Optional access lists -https://eips.ethereum.org/EIPS/eip-2930
Discussion to - https://ethereum-magicians.org/t/eip-2930-optional-access-lists/4561
EIP-2929: Gas cost increases for state access opcodes - https://eips.ethereum.org/EIPS/eip-2929
Discussion to - https://ethereum-magicians.org/t/eip-2929-gas-cost-increases-for-state-access-opcodes/4558
Topics covered:
1:25 - Introduction
2:50 - What is EIP-2929
5:04 - Why EIP-2929?
6:48 - Mitigating block processing DoS
9:34 - Pre & post EIP-2929
13:03 - A path towards bounding witness size
16:19 - Is it optimization or a trade-off
18:15 - Mechanics of EIP-2929
23:30 - EIP-2929 will only slightly increase the cost of "average" usage
29:34 - EIP-2930
33:52 - Longer-term notes
37:59 - Reason why 2929 helps prevent DoS
38:25 - Does the access-list mentioned here will help layer2 stuff?
39:45 - Any message for smart contract dev that they shouldn't be doing something from a security point of view?
45:00 - Is the gas changing strategy used for this EIP, is reusable for other gas changes we might want to do at some point?
46:08 - What are the strategy used in Eth2 to avoid some pit holes as witnessed in Eth1 today?
48:30 - Moving to the next EIP status?
50:52 - When is the right time to move the status to the "Final" for any core EIP?
52:32 - What could be the selection process for superseding the proposal in case of a different approach reaching the common result?
55:22 - Is there a reason we can not split 2929 into multiple EIPs one of which addresses precompile costs, it seems unrelated?
Follow at Twitter:
Vitalik Buterin @VitalikButerin | Martin Swende @mhswende | Pooja Ranjan @poojaranjan19 | Hudson Jameson @hudsonjameson | Alita Moore @AlitaMoore85 | James Hancock @JHancock
Other Berlin EIPs:
EIP-2718 with Micah Zoltu - https://youtu.be/JReJRJ5G_UA
EIP-2565: Repricing of the EIP-198 ModExp precompile - https://youtu.be/riBALRAw1Mw
Check out other exciting EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
to
the
one
and
only
eip,
dedicated
series,
p
penney
here
we
discuss
an
ethereum
improvement
proposal,
understand
its
importance
and
talk
about
how
it
is
going
to
make
ethereum
even
better.
I'm
your
host
pooja
randhan
and
we
are
joined
by
lot
of
community
members,
fewer
eip
editors
and
the
authors
of
the
proposal
that
we
are
going
to
discuss
today.
B
A
Going
to
discuss
two
proposals
that
are
considered
for
yolo
v3,
which
are
most
likely
to
be
included
in
berlin,
upgrade
eip2929
gas
cost
increase
for
state
access,
opcodes
and
eip2930
optional
access
list,
and
our
guests
are
co-authors
of
these
proposals.
Vitalik
duterte
and
martin
luther
both
eips
are
standard,
track
core
proposal
and
are
in
draft
status.
A
How
close
these
two
proposals
are
and
how
they
are
going
to
improve
the
ethereum
chain.
Let's
hear
from
the
authors,
welcome
to
the
show
vitalik
and
martin.
These
names
need
no
introduction.
Yet,
as
for
the
format
of
the
show,
may
you
please
say
a
few
words
for
our
audience
about
yourself
before
we
can
actually
get
into
the
eips.
D
Okay,
yes,
I'm
making
sander.
I
work
mainly
on
the
go
ethereum
team,
but
I
also
have
some
kind
of
overall
security
role,
then,
where
I
tried
to
fix
issues
on
the
ethereum
in
it,
preferably
before
they
occur,
which
is
kind
of
why
I
got
into
this
e2929
territory
in
the
first
place
over
to
you
with
alec.
C
And
I'm
vitalik
burderin,
I
write
a
blog
vitalik.ca,
it's
pretty
nice.
I
also
do
a
lot
of
ethereum
research
things.
I
have
been
doing
a
lot.
I've
been
doing
a
lot
on
the
young
and
of
eth2
side
and
some
things
on
on
the
ethon
side
as
well,
and
just
trying
to
kind
of
figure
help
help
push
the
if
ethereum
kind
of
roadmap
toward
where
I
think
we
all
agree
it
needs
to.
It
needs
to
go.
A
C
Sounds
good
okay,
so
I
guess
I
will,
let's
start
off
with
an
introduction
to
kind
of
what
eip2929
is
I'll
talk
mostly
about.
I
guess
you
know
299
at
the
beginning
and
then
to
30
more
at
the
end,
just
because
2
9
30
makes
the
most
sense
in
the
context
of
kind
of
understanding.
What
299
already
is
so
2929
is
a
yes
set
of
gas
cost
increases
for
some
storage
accessing
operations,
so
the
main
ones
are
storage
or
state
accessing
operations.
C
I
mean
there's
two
categories
of
them,
so
one
is
operations
that
access
accounts,
so
there's
a
few
different
families
of
these
there's
a
call
call
code,
delegate,
call
static,
call,
there's
an
ext
ballot
code,
size,
ext
code,
copy,
there's
the
balance
op
code
and
then
the
second
family
is
just
the
s
load
up
code
which
accesses
a
storage
slot.
So
the
eip
significantly
increases
the
gas
costs
for
these
operations.
C
C
C
But
there
is
this
still
one
thing
that's
remaining,
which
is
basically
that
the
gas
cost
increases
that
we
already
made
back.
Then
we're
just
not
high
enough
right,
and
so
there's
this
paper
here
that
I'm
quoting
from
2019,
where
they
basically
try
to
discover
what
would
be
a
worst
case
block
like
what
would
be
a
block
that
takes
as
large
a
time
to
execute
as
possible,
and
they
discovered
a
block.
That
now
on.
C
Some
hardware
takes
a
20
to
80
seconds
to
execute
and
that
attack
is
basically
just
like
repeating
the
ext
code
size
op
code.
Now
nothing
special
about
ext
code
size.
It
could
also
be
ext
code
copy.
It
could
be
balance,
you
could
do
a
somewhat
similar
attack
with
s
load
as
well,
but
generally,
like
storage,
is
the
most
expensive
thing
and
we
actually
kind
of
even
saw
this
in
2016..
C
So
the
very
last
dos
attack
that
we
had
this
is
right
after
the
hard
fork.
It
was
just
the
attacker.
Just
basically
did
a
whole
bunch
of
state
accesses,
and
so
we
see
the
uncle
rate
actually
got
pushed
up
pretty
high
and
at
the
time
we
just
solved
that
attack,
basically
by
removing
about
20
million
empty
accounts
that
the
attacker
created.
So
we
just
removed
a
whole
bunch
of
state
blood
and
we
shrunk
the
state
down
to
about
700
000
accounts
which
allowed
the
state
to
be
in
memory
so
that
stopped
being
a
problem.
C
B
C
C
The
best
of
like
the
miners,
which
tends
to
have
the
the
the
best
software
would
just
fall
behind
the
the
head
of
the
network
and
then
the
other
problem
is
that,
when
blocks
take
that
long
to
process,
there's
a
vulnerability,
a
risk
that
before
one
block
gets
finished,
another
block,
a
supp
or
some
other
minor,
creates
another
block.
And
then
before
the
next
miner
can
finish
processing
that
they
just
cover
a
different
block.
C
It's
11
600,
because
the
call-up
code
is
a
bit
more
expensive
and
then
with
slowed
spam.
And
then
here
I
think,
but
we
I
realistically
the
attacker
would
just
would
have
to
pre-fill
the
contract
themselves
because,
basically
you
like
there's,
I
don't
know
of
the
existence
of
a
large
contract
of
large
existing
contracts
that
you
can
just
make.
C
One
transaction
call
to
and
cause
them
to
make
a
bunch
of
loads,
but
it's
also
about
fifteen
thousand
access
sub
block,
but
the
storage
three
is
smaller,
so
it's
kind
of
slightly
less
of
a
problem.
After
eap,
two
nine,
two,
nine,
the
very
the
the
spams
dropped
to
about
four
thousand
accesses
per
block,
so
about
a
three
to
three
x
reduction.
C
If
it
was
twenty
to
80
seconds
after
it
would
be
a
7
to
27
seconds,
which
is
like
still
very
inconvenient,
but
it's
like
hardly
fatal
to
the
chain,
and
given
that
this
kind
of
attack
would
cost,
like
you
know
millions
of
dollars
a
day
or
like
some
really
crazy
amount,
especially
with
high
gas
fees.
That's
like,
basically
not
the
not
nearly
as
much
of
a
risk
anymore.
So
that
is
on
the
dust
side
right.
C
So,
basically,
storage
accesses
are
expensive
because
you
have
to
you
have
to
go
to
disk,
and
the
worst
thing
is
that
you
can't
parallelize
accessing
the
disk,
because
the
next
s
load
might
or
the
next
call
or
whatever
might
depend
on
the
result
of
the
previous
one.
So
you
just
have
to
do
them
sequentially,
and
so
we
just
make
reduce
the
max
number
of
these
operations
that
you
can
do
by
a
factor
of
about
three
which
is
nice.
C
C
So
if
we
knock
the
hexay
trees
down
to
binary
trees-
and
if
we
add
eip2929,
then
it
turns
out
that
with
both
of
those
things
combined
like
the
binary
tree
is
about
a
4x
benefit.
2929
is
a
3x
benefit,
so
the
top
two
columns
get
not
knocked
down
by
a
f,
oh
by
a
factor
of
12..
Oh
looks
like
I
made
a
mistake
here.
This
actually
should
be
825,
so
this
number
should
be
a
bit
should
be
smaller,
but
in
any
case
after
this
is
about
1.7
megabytes.
C
C
C
Good
question:
okay,
so
binary
trees,
in
my
opinion,
are
purely
better
than
hexa
trees.
There
is
no
disadvantage
of
binary
trees,
except
for
the
the
fact
that
it
takes
time
to
implement
them.
The
eip2929
has
a
and
has
two
disadvantages
that
we've
worked
hard
to
minimize
and
that
we'll
talk
about
a
bit
later,
the
codemoralization
that's
another
potential
gas
cost
increase.
So
that
might
be
that's
something
that
it's
worth
developers
watching
out
for
and
then
snarked
witnesses.
C
Some
good
work,
which
is
like
the
numbers,
are
a
little
bit
worse
than
this,
but
not
too
much
worse.
So
there's
a
lot,
basically
there's
a
lot
of
good
things
that
you
can
do
with
witnesses,
but
that's
all
multiplicative
with
eip2929
right
and
so
like
the
the
reductions
that
we
get,
I
think
are
still
important.
Is
that
urkel
with
a
u
or
furkle
with
an
f?
Sorry,
that's
vertical,
as
in
like
the
word
merkle,
but
replacing
the
m
with
a
v
v.
Okay
got
it
yeah.
C
C
So
when
you
call
self-destruct
on
an
account,
it
doesn't
get
self-destructed
immediately.
It
gets
added
to
the
set
and
then
at
the
end
of
transaction
execution,
all
the
self-destructs
get
processed
and
there's
some
existing
logic
to
handle
what
happens
if
an
account
gets
self-destructed,
and
then
that
gets
reverted.
C
C
There's
two
of
these
one
is
the
set
of
accessed
addresses.
So
this
is
the
addresses
that
have
already
been
accessed
within
that
transaction
and
then
access
storage
keys,
which
represents
kind
of
tuples
of
address
like
address
and
storage
key
pairs
that
were
already
accessed
by
s
loader
store,
so
a
call
to
a
an
ad
order
or
an
access
or
an
ext
whatever
or
a
balance
to
an
address
which
is
not
yet
in
the
set
cost
2600.
C
But
if
it
is
in
the
set
it,
it
only
costs
an
extra
100,
and
this
basically
just
reflects
the
fact
that
if
you
access
something
twice,
then
it'll
be
in
the
cache
for
the
second
time,
and
so
like
you
don't
need
an
another.
I
o
access
to
load
it
again
and
then
four
storage
keys,
it's
a
2100
to
s
load,
something
that's
not
yet
accessed
and
100.
That's
what's
something
that
has
already
been
accessed
s
store
and
s
and
self-destruct
are
integrated
into
the
same
system.
C
So
if
you
modify
a
storage
key
that
has
already
been
accessed
as
store
only
costs
2
900.
But
if
you
access
a
storage
key
that
has
not
yet
been
accessed,
then
store
costs
5000.
But
then
the
key
gets
out
gets
added
to
the
access
set
and
self-destruct
also
costs
another
2
600
if
the
target
is
not
yet
accessed.
C
So
the
goal
is
to
create
this
kind
of
comprehensive
kind
of
com
system
that
basically
says
for
every
address
that
gets
access
to
any
transaction.
You
have
to
pay
pay
2600
and
for
every
storage
key
you
have
to
pay
at
least
a
2100,
so
we're
just
trying
to
kind
of
make
those
things
be
hard
in
variance
and.
C
Question
it
is
transaction
specific.
I
think
the
re.
The
reason
why
we
did
it
this
way
is
because,
like
there's
not
too
much
extra
gain
from
making
it
block
specific,
and
also
we
just
already
have
this
infrastructure,
as
I
mentioned,
like
the
concept
of
transaction
wide
scope
sets
like
self-destructs
is
something
that
already
exists
in
clients,
so
they
can
just
repurpose
existing
code,
whereas
making
block
scoped
objects
would
just
require
a
lot
of
extra
thinking
about
like
well.
D
D
I
mean
this
much
more
limited
the
amount
of
things
that
can
go
into
an
individual
transaction,
whereas
if
you
have
a
full
block,
then
every
time
you
you
run
it,
you
need
to
have
a
way
larger
journals
for
handling
these
things.
It
would
be
a
lot
more
problematic
plus.
There
was
also
this
reasoning
about
side
channels.
C
Right
so
next
slide
is
some
there's
some
wonderful
research
here
that
anna
martin
has
done.
You
know
basically
just
showed
that
eib2929
only
slight,
very
slightly
increases
the
cost
of
average
usage,
so
average
increase
in
total
gas
consumption
from
just
like
randomly
selected
recent
blocks
somewhere
like
a
bit
a
little
bit
under
0.4
percent.
The
number
is
0.53.
C
If
you
don't
take
into
account
intrinsic
gas,
but
if
you
do
take
into
intrinsic
gas,
then
it
kind
of
drops
even
further
so
basically
kind
of
on
average,
negligible
changes
to
existing
gas
consumption
and
like
this
is
worth
like
really
spending
some
time
on
because
like
when
you
first
think
about
it.
It's
like
mind-blowing,
like
you,
know,
wtf
you're,
increasing
the
cost
of
a
major
operation
by
a
factor
of
four
how
the
heck
does
this?
C
Do
nothing,
and-
and
I
have
one
intuitive
explanation
for
this-
so
my
intuitive
explanation
is
basically
that
then
there's
this
effect
where
double
accesses
get
cheaper
right.
So
there's
a
lot
of
kind
of
workflows
in
existing
ethereum,
where
you
just
have
to
kind
of
s
load
and
store
the
same
thing
twice.
C
I
believe
solidity
has
to
be
also
has
the
behavior
where
before
it
calls
a
contract,
it
verifies
that
it
is
a
contract
which
basic,
which
means
that
it
calls
like
ext
code
size
or
something
like
that
right
and
so
like
that
operation,
for
example,
instead
of
being
800,
700
plus
700,
would
only
be
2600
plus
100.
So
it's
going
up
by
a
factor
of
two
and
not
four,
and
then
erc20
transfers
actually
get
cheaper
right.
The
basically.
C
But
now
it
goes
down
to
5
000,
basically,
just
because
the
this
kind
of
effect,
where
you
don't
charge
charge
the
the
high
amounts
twice
for
the
same
storage,
slot
and
kind
of
outweighs
the
cost
increase
right.
So
in
an
erc20
transfer
like
you
had
to
do
things
like
check
that
a
balance
is
at
least
an
amount
and
then
subtract
an
amount.
C
You
have
to
do
a
s
load
and
then,
and
then
an
s
store
to
the
same
slot,
and
so
there's
a
lot
of
a
lot
of
those
effects
where
the
gas
cost
goes
down.
Self
calls
also,
I
know,
there's
our
another
eip
to
make
self
calls
cheaper
this.
This
cip
also
supersedes
that
so
self
calls
go
down
to
100
cost
of
pre-compiles
go
down
to
100.
D
So
there
are
is
quite
a
large
span
of
what
happens
to
contracts,
sorry
transactions,
some
of
them
will
be
like
up
to
4x,
more
expensive
and
typically,
those
are
d5
contracts
that
do
a
lot
of
interactions
with
various
d5
contracts
like
landing
and
doing
flash
loans
and
swapping
on
something
else
and
doing
something.
On
a
fourth
contract,
they
become
more
expensive.
Obviously,
whereas
use
cases
like
the
ones
that
alec
mentioned,
and
things
like
using.
D
D
C
Okay,
so
moving
on
to
eiu
2930.
So
this
is
where,
like
we
can
kind
of
talk
about
the
risk
of
eip2929
breaking
some
existing
contracts.
So
basically,
the
reason
why
this
happens
is
that
there's
some
contracts
that
have
kind
of
fixed
gas
limits
that
they
used
to
make
kind
of
internal
calls
and
those
fixed
gas
limits
were
specifically
chosen
to
facilitate,
like
a
specific
number
of
storage
operations
and
specific
amount
of
computation
or
whatever
else.
C
And
so,
if
you
just
make
that
storage
operations
more
expensive,
then
it
stops
the
contract
that
was
able
to
do
something
before
is
just
not
able
to
do
it
anymore.
So
we
have.
This
got
a
fairly
generic
solution
to
this
issue,
which
is
basically
are
generally
to
the
issue
of
increasing
gas
costs
for
witness
size,
which
is
basically
that
transactions
can
prepay
gas
to
access
particular
accounts
at
storage
slots.
C
So
there's
there
would
be
a
new
transaction
type
and
that
new
transaction
type
can
make
a
list
of
addresses
and
a
list
of
storage
slots
that
it
knows
it's
going
to
access
and
then
the
transaction
would
have
to
pay
2400
per
address,
plus
1900
per
storage
key.
So
a
small
discount
relative
to
kind
of
the
the
high
access
cost
of
call
and
s
load,
and
it
would
just
pay
them
as
part
of
intrinsic
gas
and
then
those
addresses
and
those
storage
slots
would
just
get
added
to
the
access
set
at
the
beginning.
C
And
so
during
the
actual
execution
and
during
every
sub
call
the
calls
and
s
words
would
only
cost
a
100.
so
actually-
and
I
think
this
would
not
only
prevent
things
contracts
from
getting
broken.
It
might
even
end
up
unstucking,
some
of
the
aragon
ones
that
were
taking
down
during
the
earlier
asphalt
gas
increase.
I
don't
know
if
that's
like
to
what
extent
so
that
that's
actually
the
case,
but
it's
it.
It
might
be.
So
that's
just
another
advantage
right.
C
C
Required,
okay,
so
some
kind
of
longer
term
things
is
that
also
that
I
kind
of
these
from
just
these
eips
also
kind
of
move
us
toward
what
I
consider
to
be
out
of
sane,
witness
gas
accounting
so
just
closer
toward
maintaining
a
hardened
variance.
That
say:
there's
a
maximum
amount
of
like
witness
size
that
you
can
can
spend
per
unit
gas
and
the
theoretical
maximum
window
size
that
a
block
can
have
is
not
some
incredibly
huge.
C
High
number
and
access
lists
also
are
something
that
is
useful
for
other
reasons
in
a
kind
of
longer-term,
stateless,
stateless
road
map
so
like
it
is
a
kind
of
like
a
step
toward
those
things,
and
it
also
just
serves
the
function
of
like
kind
of
allowing
the
ecosystem
to
get
used
to
those
things.
But
there
are
further
steps
that
do
need
to
be
taken
right
so
like,
for
example,
the
the
witness
size
and
code
is
not
yet
addressed.
C
So
I
kind
of
briefly
mentioned
this
idea
of
eventually
charging
500
guests
for
every
chunk
of
code
that
gets
accessed
the
cost
of
a
witness
are
not
precise
and
like
an
attack
on
a
merkle
tree.
Could
still
make
a
branch
much
longer
so
there's
some
other
people
that
have
proposed
eventually
switching
to
per
byte
costs
for
witnesses
which
could
work,
and
then
the
access
was
here
voluntary.
C
D
To
that
sure,
yeah
yeah,
so
you
I
mean
to
rephrase
it
a
bit
so
previously,
when
we've
done
gas
calls
changes,
there's
been
like
we're
putting
the
threshold
here
now
and
we
might
break
some
stuff,
but
it's
worth
it
and
we'll
just
do
it,
but
with
e29
plus
e2930
I
mean
we
also
set
the
quite
arbitrary
threshold.
We
set
the
bar
here
now,
but
we
also
provide
a
fix
to
to
solve
it.
D
D
If
the
problem
of
state
growth
keeps
growing,
we
can
just
do
a
forex
increase
again
and
we
can
be
confident
that
even
if
stuff
breaks,
the
only
thing
that
will
happen
is
that
those
cases
where
it
breaks
or
becomes
worse,
they
will
have
to
start
using
the
access
lists
that
come
with
2930
to
unbreak
them
again
and
prepay
the
broken
scenarios.
So
it's
I
one
thing
I
like
about
these
proposals
is
that
they
are
scalable
and
not
just
like
this
one
fix
it
right
now
and
have
the
same
problem
in
a
year.
F
E
C
E
G
C
I
guess
that
depends
on
the
specific
context
because,
like
the
con,
the
word
access
list.
Basically,
it
just
means
like
a
list
of
addresses
and
address
and
storage
slot
pairs
that
are
expected
to
be
accessed
by
a
transaction,
but
there's
a
lot
of
different,
like
rules
that
you
can
attach
to
an
access
list
right,
so
that
that's
one
that's
a
kind
of
issue.
One
right,
like
I
said
like
are
things
that
go
outside
of
the
access
west.
They
just
cost
more
gas.
C
Are
they
are
they
banned
and
do
they
just
lead
to
that
and
the
execution
I'm
immediately
terminating?
Is
it
something
even
different
from
that
and
then
the
second
issue
is:
are
they
referring
to
wanting
access
list,
eips
be
added
to
ethereum,
or
are
they
for
referring
to
access
lists
being
added
to
the
optimism
protocol,
which
is
something
that
they
could
could
easily
make
sense
in
their
in
their
own
context,
as
well.
G
Something
else
I
was
thinking
about,
so
there
are
things
that
smart
contract
devs
shouldn't
be
doing
as
far
as
I
guess,
like
gas
stipends.
If
I
understood
it
correctly
and
stuff
like
that
to
so
that
when
these
eips
come
in,
it
won't
break
their
contract.
Is
that
something
that
we
should
be
kind
of
publicly
yelling
at
smart
contract
devs?
Or
is
there
a
danger
of
people
suddenly
making
contracts
just
to
you
know,
play
around
and
make
it
show
that
there's
a
lot
that
are
breaking
when
really
they're
not
being
used
officially.
D
D
F
The
I
have
been
advocating
very
strongly
that
people
should
not
use
the
gas
type
gas
stipends
in
their
calls
like
if
you're
gonna
call.
It
call
something.
There's
a
couple
reasons
for
this.
One
stuff,
like
gas
price
changes,
breaks
things
two.
It
will
break
smart
contracts,
so
we
want
to
encourage
people
to
use
contract
wallets
like
gnosis,
safe
or
whatever,
like
things
that
have
multiple
recovery
mechanisms
or
multiple
signers
all
these
things,
and
but
we
can't
use
those
cool
features
within
the
ecosystem.
F
As
long
as
people
continue
giving
like
a
tiny
little
gas
type,
then
it
doesn't
let
the
contract
actually
do
anything,
and
so,
when
you're
sending
eth
to
a
contract,
a
contract
might
have
logic
that
says.
Oh,
this
needs
to
get
divided
up
mostly
three
three
people,
because
that's
how
this
contract
works.
What's
how
this
wallet
works
and
those
things
kind
of
stop
being
possible
when
everybody
in
the
ecosystem
is
always
saying,
I'm
going
to
send
you
east,
but
you're
not
allowed
to
do
anything.
F
When
I
send
you
these
so
there's
a
couple
of
reasons
why
I
argue
about
this,
but
one
of
one
of
them
is
this
exact
issue
where
the
gas
costs
should
be
expected
to
change.
We
should
not
expect
gas
costs
to
stay
stable,
because
hardware
changes,
clients
change,
we
find
new,
optimization
opportunities
and
gas
costs
are
meant
to
be
a
pricing
mechanism
that
just
prices
off
codes
relative
to
each
other,
not
relative
to
anything
else,
just
relative
to
each
other.
So
we
want
to
know
how
much
more
is
expensive.
F
Is
it
stored,
a
storage
load
or
a
storage
read
compared
to
adding
two
numbers
together,
that's
what
gas
costs
are
supposed
to
represent
and
when
you
start
having
your
your
contract
depend
on
gas
costing
a
certain
way
it
takes
away.
Our
ability
to
you
know
change
those
to
make
them
more
accurate,
so
like
if
storage
becomes
cheaper
because
some
new
technology
comes
out,
it
makes
it
so.
Storage
is
just
cheap.
Now,
like
new
type
of
drive
or
something
that
everybody
now
has.
F
A
F
A
F
F
At
all,
no,
I
don't
think
they
should
use
transfer,
and
I
tell
everybody
I
see
to
not
use
transfer.
I've
told
the
solidity
team
to
remove,
transfer
and
send
or
change
them
to
give
a
full
gas
amount.
When
you
do
it,
of
course,
there's
they're
worried
about
there's
a
bunch
of
people
who
make
assumptions
that
transfer
will
never
do
a
state
right,
for
example,
and
so
they
that
that
assumption
is
core
to
their
security
of
their
contract.
They're
like
okay.
F
If
I
do
a
stock
transfer,
I
am
guaranteed
that
no
state
right
will
occur
and
therefore
I'm
safe
from
certain
reentry
attacks.
Of
course,
like
I
said,
if
gas
costs
of
storage
go
down,
maybe
state
reads
and
2300
gas
is
possible
in
the
future
or
state
rights
I
mean,
and
so
it's
this
dangerous
game
they're
playing.
I
I
think
I'm
making
progress
like
getting
solidity
to
remove,
transfer
and
maybe
add
something
to
replace
it
that
sends
all
the
gas
and
just
make
it
more
clear
in
the
docks,
but
we'll
see
no
no
progress.
F
B
C
I
think
the
prepaid
approach
for
like
or
the
prepaid
through
access
list
approach
works
for
any
witness
gas
cost
increase
so
like
yeah
earlier
on,
I
mentioned
the
the
potential
of
like
adding
a
gas
fee
per
chunk
of
code
that
gets
accessed.
So
that
would
be
another
example
that
would
perfectly
be
resolvable.
With
that
model
gas
cost
increases
to
other
op
codes.
C
G
I
was
just
thinking
so
we're
having
a
lot
of
these
headaches
with
gas
cost
having
to
change
them
a
lot
and
changing
some
structures,
some
some
like
different
picking
between
trees
and
stuff
and
restructuring.
I
guess
how
transactions
are
stored,
I
think,
is
how
I
understood
it.
What
is
happening
in
eth2
to
prevent
some
of
these
same
like
pitfalls
and
headaches
we
have
in
eth1
today.
C
So
I
think
a
couple
of
things,
so
one
is
that,
with
these
two
we
are
taking
this
kind
of
much
more
conservative
approach
toward
enabling
things
right
so
like
one
example
of
this
is
just
that
the
right
now
the
e3
chain,
like
does
not
even
have
transfers
supported.
The
first
version
of
sharding
is
going
to
be
data.
Only
the
and
like
there's
there
there's
a
list
of
these
things
right
so
like
basically
like
not
going
all
out
and
like
basically
in
instead
of
access
like
asking
like.
C
Why
not
like
you
would
just
ask
like.
Are
we
sure
this
doesn't
break
fundamental
invariance?
And
this
is
like
a
kind
of
early
stage,
youth,
2
design,
philosophy,
and
then
the
second
thing
to
keep
in
mind
right
is
that
I,
like
ultimately
eth2
is
like
and,
as
daniel
said
in
his
presentation.
Right
like
it's,
not
a
like
ift
was
not
a
wholesale
replacement
freeze.
C
One
right
eth2
was
just
a
project
that
is
about
replacing
the
consensus
engine
of
ethereum
and
adding
a
scalability
layer,
and
so
the
parts
of
eth
one
that
have-
or
I
guess,
ethereum
that
have
to
do
with
transaction
processing.
Evm
execution
all
of
this
stuff,
like
they
just
go
into
each
like
e2
as
they
are
like
or
as
they
will
be
when
the
merge
happens,
so
there
aren't
really
kind
of
new
issues
that
get
introduced.
I
guess
thanks.
A
If
not,
then
maybe
we
can
move
on
to
the
other
part.
The
process
part,
as
I
was
saying
this
before
the
call
begins
and
having
these
many
eip
editors
in
one
meeting
is,
and
that
too,
that
meeting
is
not
all
coded
meeting
is
something
very
rare,
so
I
may
have
a
couple
of
questions
related
to
governance,
but
before
that
this
one
thing
related
to
the
eip
status
for
eit
2929
and
eip2930.
A
According
to
the
new
eip
standardization
process,
there
is
this
new
status
review
that
I
believe,
would
be
a
better
representation
of
these
eips
at
development.
If
not
the
last
call,
so
we
are
hoping
to
follow
the
standardization
process
and
make
sure
the
network
upgrade
processes
are
also
followed,
so
just
for
every
author
to
know
that
the
catalyst
are
currently
looking
into
eip
and
creating
pr
to
move
the
eip
to
the
right,
or
maybe
the
best
possible
state.
D
Yeah,
I
would
say
that
29.29
is
definitely,
I
don't
think
anything's
going
to
change
on
that.
As
for
29.30,
I
think
there's
nothing
significantly
that
it's
going
to
change,
but
as
we
implement
these
transaction
formats
into
the
clients,
maybe
we
will
find
that
there
are
some
clarifications
that
needs
to
be
done
with
respect
to
how
the
encoding
is
performed
because
it
ties
into
2718
as
well
mike
emerged.
A
So
my
next
question
is
like
just
a
kind
of
follow
up
with
that.
So
when
do
you
think
would
be
the
appropriate
time
to
move
all
these
not
only
to
these
two
but
to
the
eips
for
the
upgrade
in
general
to
the
final
stack,
as
is,
if
they
are
ready,
I
mean
if
author
thinks
that
there
is
no
further
improvement
is
required.
Would
it
be
before
the
public
test
net
or
just
a
few
days
before
the
mainland
deployment.
F
F
A
G
It's
very
data
and
analysis
based,
so
for
actually
to
come
to
the
conclusion
to
do
2929
and
2930,
there
was
actually
a
multi-month
process
culminating
in
a
heroic
effort
by
micah
to
list
all
of
the
possible
things
we
could
do
across
five
different
eips.
I
think
and
different
combinations
of
solutions
that
had
different
tradeoffs
and
there
was
just
a
synchronous
discussion
in
the
all
core
devs
discord
channel
and
also
in
the
meeting
itself.
G
G
So
there
isn't
always
an
ideal
solution,
but
to
keep
with
the
tenants
of
it
being
very
data,
analysis
and
technical
focused
and
also
to
have
laid
out
all
of
the
different
possibilities
and
trade-offs.
In
order
to
come
to
a
conclusion.
Amongst
all
the
client
devs,
that's
that's
how
I
see
things
happening
a
lot
of
the
time
and
I
like
it
that
way.
A
Right,
my
question
was
because
you
know
it
involves
a
lot
of
engineering
hours.
I
mean
recommendations
from
editors.
The
experienced
editors
would
really
help
to
figure
out
a
way.
The
best
approach.
Of
course,
the
breakout
room
is
there
where
we
are
trying
to
like
continue
discussion.
That
is
helpful,
so
yeah,
thank
you
so
very
much,
but
if
anybody
else
has
any
thoughts,
please.
F
C
C
C
D
Is
that
if
we're
going
to
charge
100
for
a
call,
if
we,
if
we
know
that
we
don't
have
to
access
the
try,
if
this
guarantee
that
we
don't
have
the
access
to
try
to
do
this
call,
and
we
can
do
it
in
100,
then
it
kind
of
follows
that.
Well,
if
the
call
is
to
precompile
where
it's
guaranteed,
we
don't
have
to
access,
try.
F
F
I
put
pressure
to
try
to
separate
them
in
separate
eips,
just
as
a
defense
mechanism
to
avoid
going
down
that
path
of
having
building
up
this
kind
of
ecosystem
of
negotiating
to
get
vips
in,
like
I
think
you
should
go
in
for
the
technical
merit,
not
because
someone
bought
your
vote
by
including
the
thing
that
they
want.
So
that's
awesome.
It's
not.
This
reason
is
good
enough.
For
me,
you're
adjusting
the
call
costs
and
extracting
out
the
storage
costs.
D
A
A
I
really
appreciate
vitalik
martin
taking
our
time
to
join
us
here
and
questions
that
were
interesting
not
only
related
to
eips,
but
in
general
as
well.
Thank
you
for
that.
Thank
you.
Hudson
jameson
litecoin,
james
alita,
mika
and
other
community
members
for
our
youtube
viewers.
I
hope
you
have
enjoyed
it
as
much
as
I
did,
or
maybe
more
than
that.
If
you
have
any
questions
that
could
not
be
answered
in
today's
episode,
you
may
leave
a
comment
or
add
the
article
and
we
we
are
going
to
provide
twitter
handle
in
the
description
section.
A
With
today's
episode
we
have
covered
four
out
of
five
eips
that
are
considered
for
berlin
next
week,
we'll
be
joined
by
greg
colvin
to
talk
about
another
berlin
vip
that
is
vip2315,
simple
subroutine,
so
stay
tuned.
If
you
have
missed
any
of
the
earlier
eips
overview,
you
can
watch
the
recording
of
deepening
playlist
at
the
ethereum
categories.
Youtube.