►
From YouTube: PEEPanEIP #32: EIP-3403: Partial removal of refunds with Vitalik Buterin & Martin Swende
Description
Topics covered
-----------------------------
1:48 - Goals of EIP-3403 (Remove harmful effects of gas refund.)
4:00 - Should we or should we not increase the gas limit?
5:02 - Future of Gas (utility) token if EIP-3403 is actually deployed on the mainnet.
6:47 - Is state bloat a primary problem?
8:40 - Origin of gas tokens
9:45 - Secondary goals
10:50 - Spec - Remove SELF DESTRUCT refunds completely
11:40 - Removing SSTORE refunds in all cases except one.
12:30 - Properties of EIP-3403
13:35 - Gas spent on execution cannot exceed the gas limit
14:35 - there is no way to use this to create a DoS attack
14:45 - Storage slots can not be used as a battery
15:10 - Usage of same storage slot
16:25 - Benefits kept by EIP-3403 and use cases - token approve & send (useful with EIP-3074)
18:04 - Anti-reentrancy locks
20:12 - Weaknesses of EIP-3403
22:45 - Longer-term storage slot rules
27:45 - Tips for developers
29:45 - Why are SLOAD & SSTORE opcodes so expensive?
32:28 - Have you considered not removing zero elements from the state trie after this EIP?
37:25 - On a basic level, what is sub-unit?
44:25 - What are hot and cold storage slots?
46:00 - Discussion on mitigation for non-zero to zero.
54:30 - Are there any notable applications other than arbitrage bot that might be impacted here?
55:18 - How BASE FEE opcode will be better than gas token for some projects?
57:45 - Status of the proposal - is the proposal ready for review?
Resources
--------------------
EIP - https://eips.ethereum.org/EIPS/eip-3403
Discussion - https://ethereum-magicians.org/t/eip-3298-removal-of-refunds/5430
EIP-2929 & EIP-2930 with Vitalik Buterin & Martin Swende - https://youtu.be/qQpvkxKso2E
Follow at Twitter
-----------------------------------------------
Vitalik Buterin @VitalikButerin | Martin Swende @mhswende | Alita Moore @AlitaMoore85 | Brent Allsop @Brent_Allsop | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
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
A
Durian
upgrade
was
deployed
last
week
with
that
done,
the
focus
of
ethereum
client
developers
shifted
to
the
upcoming
upgrade
bundle.
The
eip,
3403
partial
removal
of
refund
is
one
of
the
topless
proposals
to
be
seen
in
london
upgrade
alongside
with
the
eip1559
the
free
market
change,
eip3198
the
base
fee
of
code
and
eip3238.
That
is
difficulty
bomb
delay.
A
According
to
the
simple
summary
provided
in
the
proposal,
this
proposes
to
remove
gas
refund
for
self-destruct
and
restrict
gas
return
for
s
store
to
one
specific
case.
To
talk
more
about
the
proposal,
we
have
got
none
other
than
the
co-authors
of
the
proposal,
vitalik
buterin
and
martin
sunday.
Thank
you
for
joining
us.
B
Thank
you
so
so
to
start
off,
I
guess
we'll
talk
a
bit
about
what
the
goals
of
eip3403
are.
So
I
think
the
most
important
goal
is
to
basically
remove
some
of
the
harmful
effects
that
we've
been
seeing
as
a
result
of
gas
refunds.
So
the
main
two
effects
of
that
we
saw
there
so
or
that
we're
seeing
right
now
one
is
the
gas
and
storage
size
that
is
being
wasted
on
gas
tokens.
B
So
basically,
gas
tokens
essentially
use
storage
as
a
battery
and
they
just
consume
five
thousand
gas
or
20
or
they
consume.
A
full
cycle
of
a
gas
token
consumes
at
least
5
000
gas,
and
this
ends
up
taking
space
away
from
transactions,
and
it
also
increases
the
size
of
the
state
that
nodes
need
to
store
and
the
second
one
is
block
size
variants.
So,
basically,
if
you
take
into
account
refunds,
a
block
with
a
gas
limit
of
12
and
a
half
million
can
consume
actually
up
to
25
million
gas
on
execution.
B
Basically,
gas
refunds
are
capped
at
50,
and
so,
if
you
have
a
lot
of
gas
tokens,
then
for
every
transaction
you
can
just
use
the
gas
token
to
refund
up
to
half
of
the
gas.
And
then
you
can
include
even
more
transactions
now,
unlike
the
variance
in
eip1559,
where
blocks
can
go
up
to
2x
to
the
target
in
eap
1559.
A
spike
of
2x
could
only
go
up
to
about
five
minutes.
C
C
But
until
the
day
that
we
actually
switch
over,
I
mean
they
won't
be
worthless,
but
they
can
actually
the
ones
that
currently
exist
can
be
used
and
basically
cashed
out
but
yeah
if
there
is
continued,
minting
and
too
much
minting
that
making
it
so
that
that
there's
still
a
gas
tokens
left.
When
this
change
happens,
then
that
would
drop
to
zero.
E
B
So
no
it's
actually
not
state
float
the
thing
with
staple.
It
is
that
state
bloat
is
dependent
on
kind
of
long-term
average
usage
and
not
short-term
spikes
and
both
eap,
1559
and
gas
tokens.
Actually,
both
of
them
have
this
property
that
they
only
can
create
spikes.
They
cannot
affect
long-term
usage
in
the
case
of
gas
tokens,
it's
because
it
costs
20
000
gas
to
create
one,
and
then
you
get
a
refund
of
fifteen
thousand.
So
this
is
orthogonal
to
the
storage
issue.
B
This
is
more
about,
like
basically
imagine
a
short-term
dos
attack
where
an
attacker
discovers
some
technique
that
we
don't
know
about,
for
making
blocks
that
take
10
times
longer
than
usual
to
process,
and
then,
on
top
of
that
they
burn
a
bunch
of
gas
tokens
and
then
they
create
blocks.
That
would
say,
take,
I
don't
know
like
15
seconds
to
process
instead
of
seven
and
a
half
and
like
with
dos
attacks
like
it's,
not
a
binary,
it's
a
spectrum
and
then
the
longer
they
take.
B
Though
then
you
know
instead
of
a
51
attack,
you
could
do
a
31
attack,
for
example.
So
it's
at
least
like
to
me.
The
ver
the
the
variance
issue-
it
is
about
dos,
and
I
guess
it
also
is
about
low-powered
clients
potentially
like
having
a
well
like.
Basically,
we
would
rather
low-powered
clients
be
able
to
keep
up
at
all
or
than
low-powered
clients,
keeping
up
excellently
on
mondays
and
not
and
getting
three
hours
behind
on
tuesdays.
F
B
So
secondary
goals,
so
basically
of
eip-3403
one
is
to
just
be
maximally
simple.
So
it's
not
a
kind
of
nirvana,
perfect
solution
and,
like
one
reason,
why
is
you
know
we're
we
wants
to
focus
on
the
merge
and
that
becomes
harder.
If
you
know
weeks
of
core
development
needs
to
be
redirected
on
some
more
complicated
transition,
that
sort
of
completely
re-orgs
things
and
adds
like
five
different
causes,
and
also
this
is
a
short-term
fix
anyway,
so
basically
state
expiry.
B
So
the
the
and
this
or
part
of
the
solution
to
the
state
problems
is
going
to
sort
of
re-architect
storage
in
a
different
way
and
I'll
talk
about
that
in
the
later
slides,
and
also
to
retain
as
many
of
the
beneficial
aspects
of
refunds
as
possible.
So
to
maintain
the
good
as
many
as
we
can,
of
the
good
properties
of
what
of
incentivizing,
clearing,
storage
and
so
forth.
B
When
we
keep
the
invariance
that
there
isn't
one
op
code,
that
has
the
ability
to
like
potentially
affect
tens
of
thousands
of
swats
at
the
same
time,
but
that's
another
discussion,
so
erp
343
will
just
get
rid
of
the
refunds
and
then
removing
s-store
refunds
in
all
cases,
except
for
one
right,
and
that
case
is
basically
this.
So
zero
is
equal
to
equals.
Original
does
not
equal
the
current
or
in
english.
E
B
B
So
what
I
mean
by
this
is
that,
for
example,
if
you
have
this
pattern
of
a
contract
storage
changing
its
value,
it
goes
from
zero
to
five
to
zero,
to
seven,
to
nine,
to
zero
in
red.
Here,
the
zero
to
five
and
the
zero
to
7.
That's
the
20
000
cost
so
for
setting
the
storage
slot
from
zero
to
non-zero
and
then
the
green
five
to
zero
and
nine
to
zero.
That's
setting
non-zero
to
zero.
B
B
So
that's
what,
even
though,
the
cost
of
twenty
thousand
gets
refunded
the
the
effort
that
clients
would
have
needed
to
spend
as
a
result
of
the
twenty
thousand
also
gets
reverted
as
well.
If
that
makes
sense
so
like.
Basically,
what
this
means
is
that
the
refl
like
there's
no
way
to
use
this,
to
create
a
block
that
has
25
billion
gas
available
for
dos
attacks
and
also
because
every
refund
is
paired,
with
this
corresponding
gas
cost.
B
C
Yeah
regarding
that
that
little
feature
about
every
about
keeping
the
the
the
same
storage
slot
so
currently
there's
this
kind
of
quirky
thing
where
you
you
can
clear
one
storage
slot
and
you
set
another
storage
slot,
so
you
get
the
refund
for
the
one
you
cleared
and
you
pay
a
price
for
it
for
the
one
you
set
and
totaling
out.
They
kind
of
somewhat
cancel
each
other
out
and
from
the
perspective
of
the
actual
node
that
is
executing
this
code.
C
That
does
not
that
doesn't
actually
map
to
the
resources
expanded,
because
what
the
node
needs
to
do
is
do
two
right.
It
doesn't
need
to
do
less
work
than
if
you
know
the
the
set
to
zero
was
not
performed,
but
it
needs
to
do
two
writes
and
it
doesn't
matter.
If
one
is
writing
a
zero,
and
I
mean
deleting
something
from
a
try
or
not-
it's
still
too
right.
B
Now
so
that's
one
use
case
and
with
eip
of
3074,
this
is
likely
to
become
more
important
because
whenever
we
end
up
adding
either
eip3074
or
something
similar
or
we
move
to
smart
contract,
while
it's
without
any
eip
any
of
any
one
of
those,
then
you
actually.
There
are
currently
a
lot
of
cases
where
you
have
users
send
two
transactions,
the
first
transaction
to
do
an
approve
in
the
second
transaction
to
do
ascend
and
with
that
with
any
of
those
eips.
B
B
So,
in
both
cases
you
have
zero
to
nonzero
to
zero,
and
the
lovely
thing
about
eip3403
is
that
it
actually
makes
this
cheaper
right
so
before
the
20
000
cost
for
setting
zero
to
non-zero
within
15
000
refunds
for
setting
non-zero
back
to
zero,
so
5
000
total-
and
this
does
not
include
storage,
cold,
read
costs
it
might
also
be
off
by
like
either
100
or
800.
I
forget,
but
it's
approximately.
This
amount
right
after
eap,
3,
403,
20,
000
cost
and
19
000
refund.
B
Basically,
we're
weakened
safely
increase
the
refund,
because
if
the
refund
only
applies
in
the
case,
where
you're
resetting
it
back
to
the
zero
that
was
there
originally,
and
so
you
actually
are
canceling
out
the
storage
on
disk,
and
so
the
total
cost
becomes
1
000,
also
not
not
including
storage
rating
costs,
and
there
are
some
contracts
that
do
one
to
two
to
one.
Instead
of
doing
zero
to
one
to
zero,
but
after
eap3403,
one
to
two
to
one
will
actually
cost
more
than
zero
to
one
to
zero.
F
B
No
okay,
so
weaknesses
of
the
ip3403.
So
this
is
the
one
that
I
think
william
morris
mentioned
on
some
awkward
death
skulls.
It
creates
a
possible
incentive
to
leave
behind
one
subunit
when
you're
emptying
out
tokens.
So
say
I
have
you
know
500
units
of
wraps
dosh
and
I
want
to
send
my
raps
doge
somewhere
else.
Then,
instead
of
sending
the,
if
I
know
that
there
is
even
the
slightest
chance,
I
will
ever
wants
to
receive
the
more
rap
stories
in
the
future.
B
Instead
of
sending
all
500
raps
doors
away,
I
would
send
say
499.999999
and
then
in
my
in
the
rap
storage
contract,
the
rc20
balance
you
would
have
0.0001
remaining
and,
like
you,
don't
really
care
about
0.0001
dosh.
But
what
this
gives
you
is.
If
you
ever
receive
the
ra
some
rap
stage
in
the
future,
then,
instead
of
that
costing
you
a
22
300
gas
for
filling
a
new
storage
slot,
it
will
cost
you.
B
Oh
actually,
this
should
be
only
saving
15
000.,
I
think
it'll
or
actually
no
no
it'll,
save
you
yeah
it'll
cost
you
5,
000
and,
and
so
it'll
save
you
about
17,
300
guests.
So
the
reason
not
to
do
this
today
is
that,
if
you
send
away
all
your
does,
you
do
get
a
15
000
refund,
so
you
would
only
wants
to
leave
one
subu
unit
behind
if
you're
really
sure
that
your
balance
is
going
to
go
back
up
above
zero,
but
with
eip3403.
B
U
value
is
zero,
then
you
would
charge
for
three
thousand
instead
of
five
thousand,
so
you,
basically,
you
do
have
a
bit
of
a
gas
cost
reduction
for
clearing,
and
this
kind
of
improves
things
slightly
except
one
concern
is
that
it
does
increase
the
invariant
on
the
maximum
number
of
storage
slots,
that
you
can
change
in
a
block,
and
that's
also
one
of
the
invariants
that
I
think.
Theoretically,
we
would
like
to
just
be
able
to
clamp
down
clamp
down
on,
especially
as
we
start,
I'm
talking
about
going
into
verbal
trees
and
so
forth.
B
So
those
are,
I
think,
like
the
key
weaknesses
that
other
people
have
pointed
out.
But
one
thing
to
remember
also
is
that,
like
in
the
I
think,
if
you're
building
a
new
application
then
like
redesigning
everything
around,
these
rules
doesn't
really
make
too
much
sense,
because
in
the
long
term
for
doing
state
expiry
state
expiry
is
expected
to
kind
of
change
the
calculation
again,
and
the
reason
is
basically
that
state
expiry
in
like,
in
whatever
format,
is
likely
to
require
us
to
store
zero
and
empty
as
distinct
values
right.
B
So
if
a
contract
goes
zero
to
one
to
zero
to
zero,
and
then
it
goes
zero
to
one
to
zero
again
after
the
first
time,
it
goes
zero
to
one
to
zero.
Like
you,
instead
of
the
storage
being
empty,
you
would
actually
have
a
zero
saved
in
the
storage
stream
and
the
reason
for
why
we
need
to
do
this
is
because
to
determine
the
state
of
an
account
in
a
state
expiry
model.
B
You
generally,
you
basically
have
to
kind
of
look
for
the
most
recent
epoch
in
which
the
account
is
in
the
state
right,
so
either
the
account
is
in
the
current
state
tree
or
the
account
is
in
some
expired
region,
and
you
have
to
figure
out
a
state.
You
have
to
kind
of
start
with
the
most
recent
one
and
walk
backwards
now:
empty,
a
storage
swap
or
being
empty.
Basically
means
nothing
happens
here,
so
you
have
to
keep
looking
backwards
and
zero
means
something
different.
Zero
means
in
this
particular
epoch.
B
The
account
actually
was
set
to
zero,
and
so
the
value
is
zero
and
you
can
stop
looking
right,
and
so
what
this
means
is
that
non-zero
to
zero
in
the
long
term
is
not
even
going
to
be
clearing
anymore
right.
So
the
concept
of
query
of
active
clearing
is
likely
to
not
exist
at
all,
except
basically,
what
you
have
instead
is,
as
state
expires,
state
objects
that
people
no
longer
care
about
kind
of
get
cleared
by
defaults
right
and
so
like
zero
to
non-zero
to
zero
to
non-zero
across
multiple
transactions
would
just
cost.
B
B
So
in
the
longer
term
like
like,
basically
yeah,
you
don't
actually
there's
not
going
to
be
a
lasting
benefit
from
you
know,
leaving
0.0001
rap
storage
behind
in
your
accounts
in
case,
you
want
to
get
more,
there's
not
going
to
be
a
ben
like
definitely
not
going
to
be
any
benefit
in
using
one
to
two
to
one
for
your
mutex
walks,
instead
of
zero
to
one
to
zero
and
so
like
designing
a
long-term
application.
Around
a
kind
of
works
in
eip-3403
roles
is
just
probably
a
bad
idea
for
application
developers.
C
F
G
B
C
B
G
B
B
Okay,
good
to
know,
okay,
so
basically
kind
of
for
developers
or
zero
to
non-zero
patterns
will
continue
to
be
cheap,
using
one
to
mean
zero
and
instead
of
zero
to
mean
queered,
as
this
kind
of
like
this
one
incentive
weakness
that
efp
3403
does
introduce,
but
it
may
be
cheaper
in
the
short
term
but
like
after
state
expiry
which
could
come.
You
know
maybe
one
to
two
years
in
the
future.
There's
not
going
to
be
benefits
from
doing
this,
and
you
know
this.
B
D
B
Okay,
this
is
an
important
question,
so
s
load
basically
they're
expensive,
because
I
o
operations
so
reading
and
writing
to
disk
are
expensive
and
in
fact
the
worst
dos
attacks
we
had
against
ethereum
and
even
the
worst
ones
that
have
been
found.
Academically
since
then
have
to
do
with
basically
just
spamming,
access
to
lots
of
accounts
and
storage
slots,
and
so
in
the
case
of
slo.
B
You
know,
if
you
increase,
you
know
if
you
increase
a
gas
or
a
bit,
and
on
top
of
that,
you
attack
the
tree.
There's
like
this
big,
a
fairly
big
margin
of
error,
but
if
the
cost
of
storage
was
or
continued
to
be
what
it
was
in,
say
2015,
then,
instead
of
the
limit
being
5000,
the
limit
would
be
500
000
and
it
would
just
like
just
making
a
witness
structure
would
be
impossible,
so
it
basically
both
short
term
and
a
long
term.
Storage,
operation,
storage,
reads
and
storage
rights
are
expensive
for
several.
G
G
B
Though
I
think
the
challenge
with
that
is
that
that
is
what
we
would
call
a
deeper
change
to
the
evm
or,
and
so
it
would
require
testing.
It
would
potentially
require
some
clients
to
re-architect
themselves
in
a
significant
way,
so
the
burden
of
the
eap
would
be
higher.
Whereas
here
the
like,
the
eip
is
basically
only
a
few
lines
of
code,
and
so
the
it's
not
deep
in
any
way,
and
that
just
makes
it
safer
to
actually
implement.
G
H
C
C
G
Yeah,
it
just
seems
unfortunate
because
I'm
almost
certain
that
in
this
period
of
time
between
when
this
eve
goes
live
and
when
you
know
we
have
some
state
expiry
mechanism,
that
developers
will
have
a
new
sentinel
value
for
xero
and
then
there
will
again
be
a
transition
back
to
using
zero,
and
so
this
is
a
bad
ux.
This
will
be
a
bad
ux
for
users
when
this
ep
launches,
because
their
contracts
will
become
more
expensive
and
it
will
be.
B
I
guess
the
I
guess
the
arguments
would
be
like
someone
making
a
new
erc
20
contract
would
just
decide
that
you
know
we'll
just
offset
all
the
balances
by
45
and
then,
if
a
balance
like
and
then
we'll
just
pretends,
that
45
means
zero.
And
if
you
see
any,
if
you,
if
you
have
a
new
account,
then
it
will
just
like
be
immediately
like
the
zero
would
also
be
recognized
as
zero.
B
But
if
a
balance
gets
set
to
zero,
the
storage
slot
would
be
set
to
45
and
like
that,
would
be
cheaper
in
the
cases
where
you
go
kind
of
out
and
in
or
where,
where
balance
becomes
zero
but
then
becomes
non-zero
again,
but
yeah
right.
So
no
I
got.
I
went
back
to
this
slide
so
like.
If
we
decide
this
problem
is
significant.
B
One
possible
mitigation
is,
to
also
just
add
the
second
rule,
where,
instead
of
a
refund,
basically,
if
a
storage
slot
is
set
from
zero
to
non-zero,
you
charge
a
lower,
basically
three
thousand
gas
instead
of
instead
of
five
thousand
or
we
could
even
say,
charge
five.
The
five
thousand
and
do
a
refund
to
five
thousand.
G
Yeah
that
makes
sense.
I.
I
definitely
think
that
that's
a
that
would
be
an
important
thing.
I
I
really
don't
like
that
that
it,
as
is
this,
would
push
developers
to
use
a
different
value
for
xero,
because
it's
not
like
consensus
code.
It's
not
simple
to
upgrade
those
things
and,
as
we
transition
there's
always
going
to
be
contracts
that
are
left
behind
using
the
old
things.
D
B
Sorry,
a
sub
unit
is
like
the
equivalent
of
a
way,
but
for
any
rc20
token
so
like.
If
you
have
like
wraps
dosh,
then
if
you
have
42
rap
station,
your
balance
is
saved,
as
you
know,
zero
420
and
then
there
might
be
eighteen
zeroes
or
sixteen
zeros.
I
don't
even
know
how
many
zeros
they
use,
so
you
would
just
leave
behind
like
the
tiniest
amount
of
like
this.
Is
this
is
a
few
watts
to
kind
of
exploit
existing
erc20
contracts?
C
Yeah-
and
I
mean
another
in
the
the
other
example,
so
if
you
have
a
variable
that
you
use
as
a
mutex
to
ensure
that
you
don't
get
no
one,
that's
the
attacks
against
you.
You
have
the
option
to
use
this.
This
mutex
variable
by
default,
set
to
one
and
whenever
you
make
an
external
call,
you
set
it
to
and
then
before
you
leave,
you
set
it
back
to
one.
That's
like
one
two
one
or
the
other
pattern
is
to
have
it.
That's
zero,
set
it
to
one
and
set
it
back
to
zero.
B
D
C
Is
it
better
for
me,
as
a
developer,
to
leave
this
value
that
I'm
going
to
use
to
leave
it
at
not
zero,
or
is
it
better
to
leave
it
at
zero
depending
on?
If
I
want
to
use
it
in
the
future
yeah,
because
it's
because
of
how-
and
this
is
affected
by
how
refunds
work
and
how
how
much
it
costs
to
set
something
that
was
zero
to
non-zero.
So
it's
kind
of
what
we
would
hope
to
avoid
is
is
having
some
an
incentive
where
developers
just
leave
stuff.
C
No
not
quite
more
like
when
you
enter
this
contract.
If
it's
this
contract
during
this
execution
wants
to
use
a
temporary
variable,
let's
say
it
will
always
use
a
temporary
variable
now.
Is
it
better
gas,
wise
consumption
wise
to
have
that
variable
already
initialized
and
leave
it
initialized
for
the
next
time
this
method
gets
invoked,
or
is
it
better
to
to
uninitialize
it
and
set
it
back
to
zero.
D
D
C
B
Makes
sense
right,
like
one
kind
of
development
nuance
here,
is
that
ethereum
clients
they
ten?
They
have
a
cache
right
and
like
what
you
do
in
s
store.
They
don't
like
go
in
and
start
going
into
the
database
and
mucking
around
with
the
patricia
tree
immediately.
They
just
save
the
updates
in
the
cache
and
then
at
the
end
of
the
transaction,
or
sometimes
even
at
the
end
of
the
block
they
take
all
of
the
updates
and
or
or
all
of
the
actual
updates
and
then
process
them
all
in
one
batch.
B
D
C
A
So,
on
storage
slot,
I
I
have
a
term.
Maybe
we
could
use
some
explanation
here
in
the
test
cases.
It
was
mentioned
that
for
two
nine,
two
nine
gas
cars
there
there
are
this
mention
of
hot
and
cold
slots,
so
for
people
like
who
are
trying
to
understand
high
level,
what
are
these
hot
and
cold
slots,
and
also
if
this
is
for
testing
purpose
only
or
would
it
make
any
difference
in
practice.
B
Basically,
a
cold
storage
slot
is
a
slot
that
was
not
yet
accessed
in
that
transaction,
and
so
it
it
might
not
be
in
the
cash,
and
so
you
charge
an
extra
2100
guests
to
account
for
the
cost
of
reading
it
from
disk.
But
if
a
storage
slot
was
already
read
in
a
transaction,
then
we
know
that
it's
in
the
cache,
and
so
we
call
it
hot
or
warm,
and
we
only
charge
an
extra
100
guests
to
read
it
again.
C
B
B
D
B
Let's
say
you
want
to:
let's
say
you
don't
like
rap
storage
today
and
you
you
just
decide
you're
going
to
sell
all
your
rap
storage
on
uniswap.
So
what
you
make
a
transaction
and
as
part
of
it
as
part
of
that
transaction,
the
wrap
storage
balance
goes
down
from
one
zero.
One
million
to
or
the
value
in
the
storage
goes
down
from
one
million
to
zero
right.
B
Yes,
for
this
now,
post
eip
of
3403
in
at
least
the
current
proposed
form,
the
incentive
to
queer
goes
away
right.
So
if
you
go
from
having
one
rap
storage
to
zero
wrap
storage
today,
then
you
would
have
well.
You
would
not
get
a
refund
and
then,
when
you
go
from
zero
back
to
one
tomorrow,
you
would
have
to
pay
22
300..
B
B
But
if
you
think
that
you
know,
oh,
maybe
there's
like
a
twenty
percent
chance.
I
or
I'm
gonna.
I'm
gonna
want
my
rap
stories
back
tomorrow
then
like.
If
there
is
even
that
chance,
then
it
makes
sense
to
weave
like
this
one
tiny
sort
of
speck
of
dust
behind,
so
that
if
the
balance
in
your
accounts
does
fill
up
again
instead
of
being
charged,
a
higher
amount
of
gas
for
storage
expansion,
you're
only
charged
a
small,
the
smaller
amount
of
gas
for
storage
modification
does.
Does
that
make
sense
that.
D
B
Right,
oh
so
before
well,
okay,
before
3403,
the
concern
is
that
you
could
basically
move
one
storage
slot
from
one
to
zero
and
another
storage
slot
from
zero
to
one
and
you
would
get
a
refund,
and
so
you
would.
There
is
an
incentive
to
just
like
fill
up
a
whole
bunch
of
storage
slots
with
once
and
use
that
as
a
battery,
so
that
whenever
he
needs
to
do
some
expensive
thing,
you
can
just
kind
of
flip
some
of
these
storage
slots
to
zero,
to
compensate
to
compensate
and
reduce
your
gas
consumption
with
eip343.
B
C
B
H
B
B
A
So
on
this
particular
thing
like
talking
about
the
usage
of
this
gas
token,
as
I
understand
there
is
one
downside
of
using
this
gas
token
like
they
are
inherently
inefficient.
So
can
you
elaborate
a
little
bit
on
how
it
can
be
like
using
other
op
codes,
so
the
basic
upgrade
would
be
better
than
using
the
gas
token.
B
B
That
just
basically
means
you
know
you
convert
some
of
your
eth
into
this
financial
asset
and
that
financial
asset
will
be
able
to
like
you'll,
be
able
we'll
be
able
to
just
give
you
the
an
amount
of
youth.
That's
proportionate
to
you
know
some
amount
of
gas
multiplied
by
whatever
the
base
fee
is
and
that
that's
different
from
the
base.
B
Is
that
no
matter
how
much,
no
matter,
how
much
gas
worth
of
that
derivative
you're
claiming
it
would
only
cost
a
very
low
amount
of
these
right.
It
would
only
cost
like
maybe
like
what
something
like
20
000
gas,
to
claim
gas
tokens.
On
the
other
hand
like
they
caught,
they
cost
a
fairly
huge
amount
of
gas
overhead
to
claim
and
they're,
not
a
higher
level
derivative
like
they're,
actually
a
kind
of
tying
into
direct
protocol
rules,
and
so
they
actually
do
increase,
say
the
total
amount
of
gas
in
a
particular
block.
A
A
B
G
B
A
A
So,
following
some
of
the
past
codec
meetings,
it
seems
like
there
is
a
particular
group
of
users
who
are
not
in
favor
of
this
proposal
and
have
some
alternate
proposals,
so
whether
it
is
included
in
london
or
not,
it's
a
decision
to
be
taken
by
client,
yes
and
the
community,
but
this
video
that
has
been
created
it's
for
educational
purposes.
We
just
wanted
to
talk
about
the
proposal
and
let
people
know
their
advantage
and
why
chefs
are
thinking
of
including
them
in
upcoming
upgrade.
A
So
on
this
note
for
all
our
youtube
viewers,
thanks
for
watching,
if
you
like
this
episode,
hit
like
if
you
care
about
this
proposal,
do
share
the
video
with
other
community
members
and
help
ethereum
devs
to
close
on
london
proposals.
If
you
have
any
further
questions
that
could
not
be
answered
in
today's
episode,
you
can
find
resources
of
this
proposal
and
presentation
link
with
the
guest
contact
in
the
description
section
below
you
can
reach
out
to
us
with
your
questions
on
the
guests.
A
As
always,
we
would
love
to
hear
feedback
and
improvement
suggestions.
Do
let
us
know
which
eip
would
you
like
to
see
in
future
episodes?
Next
week,
we
will
be
joined
by
afri
to
talk
about
the
difficulty
bomb,
also
known
as
ice
age
and
ethereum,
so
stay
tuned.
Keep
watching
keep
sharing
your
love
with
the
helium
cathodes.
This
is
all
of
us
signing
out.