►
Description
Topics covered
-------------------------
0:39 - About EIP-6049
1:16 - About William Entriken
1:44 - Start of the talk
1:45 - About EIP-6049 by William Entriken
2:37 - What is SELFDESTRUCT?
4:40 - Problems with SELFDESTRUCT
6:13 - About CREATE2
8:50 - Polymorphic smart contract
10:11 - What kind of applications will be affected by deprecating SELFDESTRUCT?
13:28 - EIP Motivation
18:21 - Why choose Meta EIP?
21:04 - What advantage or relationship do we see with the rest of the SELFDESTRUCT EIP?
22:44 - What are other 'Core' proposals for SELFDESTRUCT? Is there a possibility of having one of these core proposals included in the Cancun upgrade?
34:27 - Where is SELFDESTRUCT on the priority list?
38:00 - Thoughts on EIP Process, forking the EIP repository
44:40 - Communication of "Core" EIPs
46:22 - Message to the community
Resources:
-----------------
EIP-6049: https://eips.ethereum.org/EIPS/eip-6049
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Shapella - https://www.youtube.com/playlist?list=PL4cwHXAawZxpok0smGmq-dFGVHQzW84a2
Questions for Guests - https://docs.google.com/forms/d/e/1FAIpQLSdsmujnH_ncIlSEJ23s9jzXAKwfpTGNeJqjREWPloBbkJVQTA/viewform
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
William Entriken @fulldecent | Pooja Ranjan @poojaranjan19
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
Welcome
to
p
penny
episode,
102
I'm
Puja
ranjan.
Today
we
will
be
discussing
EIP
6049
deprecate
self-destruct
in
next
hour,
or
so
we
will
learn
what
this
proposal
is
all
about,
why
it
is
included
in
Chapel,
upgrade
official
announcement,
blog
post
and
more
about
the
proposal.
Eip
6049
is
a
meta
Eep
proposed
in
November
2022.
In
my
mind,
this
is
one
of
a
kind
proposal
and
it
reached
the
common
status
very
quickly,
but
it
provides
you
an
overview
of
The
Proposal.
A
A
Yeah
for
people
who
aren't
aware
William
authored
over
a
dozen
of
eips,
including
meta
informational,
standard
track,
core
and
ERC.
Most
of
them
are
already
in
final
status.
So
if
you
have
missed
earlier
check
out
episode,
58
on
erc721
on
P
pen
e
playlist
at
ethereum,
Caterers
YouTube,
thank
you
again
for
joining
us
William
and
without
further
Ado.
Let's
peep
in.
B
All
right
so
60
49
is
it's
the
one
that
got
pissed.
There's
a
lot
of
other
people
talking
about
this
and
we'll
get
into
what
is
self-destruct
and
how
this
works,
but
I
want
to
recognize
that
this
is
yes.
This
is
a
very
small
Eep
and
it
does
a
very
specific
thing
and
the
reason
why
I
got
pissed
is
because
we
have
consensus.
B
So
one
strategy
that
you
want
to
use
in
EBS
in
life
in
business
in
politics
is
you
want
to
find
the
things
people
agree
on
and
get
that
done?
First,
even
if
it
says
just
a
stepping
stone-
and
that
was
what
we
achieved
here
today-
there's
a
lot
of
different
of
opinions
and
there's
a
lot
of
different
pants
forward
to
go
from
here.
But
there
is
one
thing
we
agree
on,
and
it
is
that
self-destruct
is
a
problem
all
right.
So
that's
the
background.
B
I
guess
we
can
get
into
meta
and
all
this
stuff
later,
don't
forget,
but
let's
just
get
into
the
meat
of
it.
The
problem
we
have
is
something
called
self-destruct.
Self-Destruct
is
an
OP
code.
This
is
a
very
low
level
instruction.
It's
the
lowest
level
instruction
that
smart
contracts
can
do.
So
when
you
you
can
add,
you
can
call,
you
can
send
your
pictures
of
cats.
You
can
do
all
these
different
things.
One
of
the
features
that
any
smart
contract
can
do
is
it
can
destroy
itself.
This
used
to
be
called
something
else.
B
We
don't
call
it
that
anymore
and
it
would
take
any
either
that's
left
over
and
that's
more
contract.
It
would
send
it
somewhere
else
and
the
contract
itself
it's
code,
it's
storage
would
be
gone
permanently,
and
this
is
a
interesting
idea.
It
makes
a
lot
of
sense
that
this
was
added
originally
in
the
week
in
the
all
paper,
so
you
can
create
a
smart
contract.
Why
can't
you
destroy
a
self-contract?
It's
symmetrical.
It
makes
a
lot
of
sense.
B
B
I
was
reviewing
the
very
first
smart
contracts
on
ethereum
one
by
one
decompiling
reading
code
and
we
were
looking.
We
were
looking.
We
were
in
a
hunt
for
what
is
the
first
nft,
so
here's
the
blog
post
and
I
was
just
looking
at
bytecode
from
the
original
contracts
and
just
seeing
what
they
are.
One
of
the
very
earliest
contracts
includes
this
feature
called
self-destruct
again.
It
was
called
something
else
back.
B
Then,
if
you
look
at
the
source
code,
but
you
can
look
this
up
and
you
can
see
these
contracts
were
made
and
then
they
can
be
destroyed
and
I
guess
maybe
the
thought
was.
If
we
have
it
cleaned
up,
then
we
can
maybe
Preserve
the
store
available.
Storage
space
preserve
people's
hard
drives
it
just
it
just
made
a
lot
of
sense,
so
I'm
giving
you
the
historical
perspective.
B
Now
there's
some
problems
with
that
one
and
actually
it's
from
the
beginning.
It
was
a
great
idea
also
because
we
didn't
know
what
storage
was
going
to
cost.
Remember.
The
cost
of
storage
has
gone
up
and
down
back
then
it
was
megabytes
to
hold
the
entire
state
tree
for
ethereum.
Now
it's
you
know
in
terabytes,
it's
just
a
different.
You
know
this
thing
has
grown
a
little
bit
since
it
came
out
now
the
problems
are
well
known.
Self-Destruct
is
a
one-time
operation
that
has
a
one-time
cost,
that's
called
of
one.
B
They
go
in
notation
right,
so
that
means
you're
going
to
pay
one
specific
cost
to
perform
a
self-destruct.
However,
the
effect,
the
actual
amount
of
things
that
are
changed
on
change
changed
on
the
Chain
are
unbounded,
so
that's
all
of
n.
So
if
you've
got
a
very
large
smart
contract,
it
can
do
lots
of
things
and
it
can
have
lots
of
storage,
but
then
one
call
to
self-destruct
changes
all
of
the
storage
to
zero
effectively
and
that's
a
problem
because,
as
we've
seen
before
in
ethereum,
you
can
create
an
attack
with
that.
B
Whether
the
attack
is
practical
or
not
it's
just.
It's
generally,
we've
seen
bad
problems
where
there's
an
O
of
one
cost
and
O
of
n
effect,
and
so
this
is
one
I,
don't
know
if
it's
academic
or
practical
I
don't
really
care.
But
this
is
a
well-known
and
nobody
disagrees
on
it.
We
know
this
is
a
problem
philosophically
and
maybe
even
practically.
B
B
B
That
is
true
or
not
true,
when
you're
using
normal,
create,
because
when
you
use
normal
create
it
just
takes
the
nth
contract
that
you've
made
and
puts
the
nth
one
at
a
specific
spot.
We'll
create
two
does.
Is
it
makes
X
it's
more
based
on
not
who
made
it,
but
what's
in
it,
and
so
the
whole
point
of
this
well
there's
a
few
points,
but
one
of
the
important
points
is
counter
factuals.
B
If
there's
a
problem,
it's
going
to
put
five
ether
in
a
specific
address:
there's
no
smart
contract
there,
but
you're
just
programming
in
a
way
where
it
will
go
to
a
specific
address.
Now
the
world
could
know
what
would
be
there
if
you
deploy
the
smart
contract
because
we
could
use
create
two
and
we
could
put
something
there
and
then
then
it
would
exist
and
the
way
that
smart
contracts
work
with
pre-funding.
She
could
book
five
ether
there
and
then
you
could
go
create
the
smart
contract.
B
So
you
can't
do
other
stuff,
you
might
say:
oh
well,
we're
going
to
have
an
agreement
and
if
things
go,
south
I
need
you
to
pay
me
five
ether.
We
build
that
in
somewhere.
Okay,
that's
cool,
but
that
only
works
between
you
and
me.
If
we
need
a
lot
of
people
to
be
agreeing
to
something
we
might
say,
okay,
we
want
the
fighter
there
to
go
to
this
specific
place.
The
smart
contract
is
going
to
do
these
things
and
it's
not
going
to
benefit
me.
Specifically.
You
don't
have
to
trust
me.
B
You
just
have
to
trust
the
code,
so
that's
kind
of
the
composable
future
that
we're
building
and
this
depends
on
there
being
specific
code
at
a
specific
place.
Well,
this
also
opened
up
another
thing
and
I.
Don't
think
this
is
discussed
here.
There's
a
good
blog
post.
I,
don't
have
it
ready,
but
when
create
two
is
happening
when
you're
allowed
to
choose
the
address
that
a
smart
contract
goes
to.
That
also
means
we
have
polymorphics
Smart
contracts
and
that's
that's
bad.
That's
boo,
boo
Emoji
right.
B
So
that
means
you
could
deploy
code
here
and
then
it
could
self-destruct.
The
code's
gone
and
you
can
deploy
something
else
there
and
that's
bad.
If
my
opinions,
weren't
known
I,
believe
that
upgradable
contracts-
that's
that's
bid,
Diamond
contract
I,
think
that's
bad
unless
you're
using
it
just
for
composability,
not
for
mutability.
We
don't
like
bad
mutable
contracts.
B
If
you
want
to
use
mutable
contracts,
go
use
flow,
we're
talking
about
ethereum
today,
and
so
we
just
want
to
deploy
once
and
we
want
to
trust
what
is
written
there
create
two
and
self-destruct
is
a
known
problem.
There's
a
good
blog
post
about
this
I
hope
we
can
find
it,
but
yeah
you
don't
want
to
deploy
a
smart
contract,
delete
it
and
then
deploy
another
one.
It's
different!
That
is
a
problem,
so
these
are
the
two
main
problems
with
self-destruct.
B
A
I
think
this
is
a
great
explanation
of
self-destruct.
This
definitely
helps
us
understand
why
people
don't
want
it
like
why
ethereum
developers
don't
want
self-destruct
at
this
point
of
time.
My
question
to
you
would
be
like
this
is
on
protocol
level
implemented
on
the
protocol
level
long
ago,
so
many
projects
may
have
used
it
in
their
application.
B
Yep
so
the
Practical
applications
and
the
Practical
problems
we
would
have
are
a
polymorphic
smart
contracts.
That's
where
somebody
expected
the
contract
to
change,
and
that
is
not
the
worst
way
to
do.
An
upgradable
contract.
There's
other
ways
to
do
upgrades
unfortunately,
and
they
all
use
proxies,
is
really
the
popular
way
to
do
it.
So
if
you
do
it
one
way,
you
have
a
proxy,
you
have
a
proxy
and
then
every
time
you
run
the
smart
contract,
you
have
to
go
delegate
that
to
an
implementation,
it's
a
very
popular
way
to
do
it.
B
We
have
proxy
proxy
beacons.
Open.
Zeppelin
contracts
has
implemented
this
a
lot
of
people
use
it.
There's
an
EIP
around
this
as
well,
and
this
is
inefficient
because
you
have
to
go
find
the
implementation
personally.
I
think
upgradable
contracts
need
to
die
in
a
fiery.
Health,
that's
a
different
problem.
You
know,
but
if
people
are
doing
that,
another
way,
a
better
way
would
be
mutable
contracts,
so
you
could
just
make
a
contract
destruct
it
and
then
add
another
version.
B
I
have
not
done
the
research
to
go
see
if
people
are
actually
doing
that
and
the
problem
with
ethereum
is
that
you
know
all
you
have
to
do
is
delete
one
of
the
beacon
proxies
for
one
of
the
things,
that's
one
of
the
things
and
then
D5
breaks
and
then
basically,
it's
a
huge
huge
disaster.
We've
learned
about
this
from
the
Dow,
the
the
capital
D,
the
Dow.
This
is
the
type
of
problems.
You've
got
something
that
points
to
something
else:
you're
not
paying
attention.
B
Someone
deletes
that
other
thing
and
then
there's
big
big
problems
so
because
ethereum
has
the
history
of
with
the
Dao
and
taking
these
considerations
thoughtfully
this
the
idea.
The
problem
is
that
even
if
these
things
are
possible,
we
really
want
to
be
sure
that
we're
not
hurting
people
before
we
go
ahead
and
do
this
and
really
one
of
the
ways
to
just
do
this.
Research
would
just
be
to
make
this
change
retroactively
and
see.
B
Have
any
of
the
previous
contracts
ever
been
affected,
one
of
the
ones
I'll
I'll
even
tell
you,
is
I've,
got
this
blog
post
here
and
I.
Think
I
found
the
first
nft
ever
it's
like
one
of
the
first
10
smart
contracts
ever
deployed
and
the
smart
contract
has
a
feature
where
anybody
can
just
take
it.
So
actually
now
I
stole
it
and
I'm
the
owner
of
this
nft,
and
it
has
another
feature
where
anybody
can
destroy
the
smart
contract
and
so
trolling.
B
Maybe
people
were
saying
well
if
we
get
rid
of
the
ability
to
destroy
smart
contracts.
That
will
forever
enshrine
me
as
the
owner
of
this
nft,
because
nobody
can
destroy
that
smart
contract,
whereas
today
anybody
who's
reading,
you
could
just
go
ahead
and
you
can
delete
it
and
I
will
no
longer
own.
The
world's
oldest
nft
on
ethereum
mean
that
right,
so
you
know
tongue-in-cheek,
but
there
are
little
effects
like
that.
I,
don't
care,
you
can
delete
it.
B
A
Right
so
I'm
curious,
like
this
is
one
of
a
kind
proposal
as
I
was
mentioning
in
the
beginning
of
the
talk.
Generally
speaking,
when
we
are
doing
anything
when
we
are
planning
to
make
some
changes
on
ethereum
protocol
level,
it
is
introduced
as
a
core
EIP
and
that
considered
as
as
a
part
of
upcoming
upgrade,
but
EIP
6049.
It
is
being
considered
for
shape.
Upgrade
I
mean
it
is
already
existing
in
the
list
of
proposals
in
update.md
file
like
shanghai.95,
but
yet
it's
not
a
core
proposal.
B
Great
question
and
create
the
universes
and
and
create
understanding
the
consequence
here.
So
a
core
EIP
changes
the
way
that
the
clients
communicate
that
will
be
on
the
execution
layer
or
back
in
the
neighborhood,
just
say
the
client
right
so
at
the
execution
layer,
the
bits
and
bytes
of
the
transaction
coming
in
and
the
state
results
in
a
new
state.
That's
the
there's,
a
the
F
function
in
the
yellow
paper
right,
so
there's
a
function
that
takes
the
inputs
and
gives
you
a
new
output.
This
does
not
change
that.
B
The
yellow
paper
will
not
change
the
required
functional
output.
As
a
result
of
this,
however,
the
yellow
paper
will
add
a
warning,
but
while
it
will
say
you
shouldn't
do
this,
and
that
is
what
we're
specifying
here-
we're
specifying
that
you
should
not
do
this
and
here's.
Why
and
here's
why
this
is
an
important
thing.
One.
B
Through
than
a
court,
so
people
have
disagreed
on
how
we're
going
to
change
this
people
agree
that
we
want
to
change
this,
but
there's
no
consensus
on
what
we're
going
to
do,
but
there
is
consensus
that
we
need
to
stop
using
self-destruct
going
forward.
That
was
what
was
agreed
upon,
and
that
is
what
is
codified
in
EIP
6049,
so
the
agreement,
the
minimal
the
minimum
viable
product
here,
the
the
thing
we
shipped
was
the
agreement
that
you
should
not
use
this
going
forward.
Why
is
that
important?
B
Just
like
I
said
with
the
create
two
and
the
upgradable
contracts
and
the
okay
create
two
plus
self-destruct
plus
polymorphic
contracts
is
cheaper
and
you
should
use
that
theoretically
today,
instead
of
open
Zeppelin
contracts,
proxy
pattern,
it's
just
it's
just
a
better,
cheaper
way,
and
people
aren't
using
that.
So
if
somebody
realized
that
they're
like
oh
I,
should
go
start
using
self-destruct
now,
because
it's
going
to
give
me
what
I
want,
we
want
to
stop
that.
So
we
don't
want
people
going
forward
to
use
this.
B
In
fact,
you
know
we
just
spelled
it
out
there
and
it
by
by
what
this
people
need.
Putting
it
in
the
yellow
paper,
putting
an
upgrade
notice,
we're
putting
you
on
notice
that
if
you
do
this,
we
don't
care
about
messing
with
you
when
we
change
this
later
so
effectively.
What
we've
done
is
we
have
a.
We
have
a
lower
bound
and
an
upper
bound
on
the
transactions.
The
the
block
numbers
that
we're
going
to
look
about
before
we
change
this.
So
there's,
there's
X
smart
contracts
going
to
be
deployed
to
those
the
main
domain.
B
I
guess
is
one
that
matters
as
of
a
certain
date.
We're
only
going
to
care
about
those
smart
contracts
because
there's
a
problem
with
the
new
AP.
If
you
have
an
EIP
coming
out
and
you're
like
oh
we're,
gonna,
just
we're
going
to
change
this
Behavior
well,
you've
also
got
to
consider
not
just
how
is
it
going
to
affect
past
people
but
how's
it
going
to
affect
people
during
the
time
that
you're
considering
and
debating
this,
which
could
be
years?
B
So
you
know
what
I
mean
like
you're
chasing
a
moving
Target
here,
so
you
might
come,
get
very
close
to
the
Finish
Line.
With
this
new
EIP
saying
we're
going
to
just
remove
this
function,
we're
going
to
remove
this
by
code
for
self-destruct,
but
in
that
meantime,
in
those
two
years,
maybe
that
opens
Upland
contracts.
Maybe
somebody
else
switched
and
now
everybody's
using
it,
and
so
you
would
have
an
EIP,
you
would
have
agreement.
Everybody
thinks
this
is
a
good
idea.
B
You've
got
science,
you
did
research,
you've
deployed
things,
you've,
you've
downloaded
the
entire
history
of
the
smart
contracts
and
you're
like
okay.
This
isn't
going
to
affect
anybody
that
we've
researched
and
then
you'd
launch
it
they're
like,
oh,
since
the
research
new
people,
starting
using
it
like
that's
a
problem
so
by
putting
people
on
notice,
I
think
it
will
be
easier
going
forward
to
debate
and
finalize
one
of
these
decisions.
This
is
not
the
end
of
the
discussion.
B
Eip2049
just
puts
people
on
notice,
so
we
can
limit
the
damage
that
we're
going
to
do
potentially
with
one
of
these
other
eips
I.
Don't
think
this
approach
has
been
done
before
I'm
I'm
around
here
to
you
know,
push
the
push
the
envelope
and
I'm
learning
with
eips.
You
know
I'm
I'm
learning
with
you
at
the
same
time.
How
do
we
get
consensus
on
things?
How
do
we
get
things
agreed
upon?
You
know
everything's
politics
everything's.
You
know
three
people
two
people
is
a
debate.
B
A
B
A
B
Yeah,
it's
weird
because
the
the
actual
I
mean
I
wanted
it
to
be
a
core
honestly.
You
Know
chords
are
fancy
right
and
it's
a
different
process,
but
the
result
needs
to
change
the
yellow
paper.
So
in
one
interpretation
of
the
word
Court
EIP,
that
means
you
need
to
change
the
source
code
of
the
client.
B
The
client
needs
to
change
or
the
execution
line
or
whatever.
Okay.
So
that's
one
interpretation
of
the
word
core
I
was
taking
a
more
expansive
word
and
I
was
thinking
anything
that
changes.
The
yellow
paper
needs
to
be
core
people
didn't
agree,
I,
don't
care.
So
Meta
was
the
one
that
that
worked.
Information
is
good
too
and
honestly
I
think
there's
you
know
there
could
be
a
debate
on
which
one's
appropriate
and
really
that
you
know
I
I
think
it
could
have
been
core.
B
That's
a
choice:
info's,
a
choice
met
as
a
choice,
and
this
is
kind
of
just
where
I
landed.
We
we
are
in
the
company
of
other
meta
aips,
which
is
up
there
with
eip1.
You
know
this
is
a
guideline,
so
if
we
look
at
60
49
is
that
you
know.
Is
that
a
guideline
if,
if
we
look
at
other
informational
ones,
I
can't
say
like
that,
but
really
doesn't
matter?
You
know,
I
think
this
is
like
I
think
this
is
the
consideration
when
in
math
class
we're
doing
geometry
in
third
grade.
B
A
Right
I
mean
I
have
seen
a
few
proposals
which
are
on
the
EAP
repository
as
of
now.
Some
of
them
are
in
stagnant
status.
Some
are
I,
think
in
review
and
draft
status
as
well.
So,
generally
speaking,
those
proposals
which
are
with
core
category
defined
they
are
there
to
make
changes
to
the
consensus
and
eventually
will
make
changes
to
the
yellow
paper.
Generally,
we
update
yellow
paper
after
the
upgrade,
so
that
was
already
in
place
so
having
this
EIP.
A
B
So
by
having
the
agreement
that
we
should
not
be
that
smart
contract
authors
should
not
be
using
self-destruct
going
forward,
we
can
more
fearlessly
in
the
future,
disable
that
feature
so
by
being
Fearless.
It
makes
these
things
move
faster
and
so
I'm.
Looking
for
a
core
EIP
to
proceed,
I'm
I
can
recommend
one
of
these
and
we
can
look
at
them.
All
I
will
recommend
it,
and
then
you
know
people
will
debate
the
relative
merits
of
each
one
as
well.
Just
throwing
my
way
behind
and
pushing
one
of
them
did
not
solve
the
problem.
B
A
Think
that
makes
sense,
and
when
this
proposal
is
in
final
status,
it
is
like
kind
of
a
standard
people
have
to
follow,
and
this
has
now
been
added
as
a
part
of
announcements.
So
we
are
trying
to
give
a
heads
up
to
DAP
Developers
for
the
upcoming
changes
all
right.
Talking
about
this
changes
like,
as
you
mentioned,
that
you
may
be
able
to
support
what
are
the
possibility
of
having
one
of
these
core
proposals
being
included
in.
B
Let's
check
it
out
so
here's
one
example
X
clear
for
self-destruct,
so
this
proposal
is
specifically
addressing
the
010
problem,
so
we
have
the
o1
cost,
o
n
effect
and
the
way
that
this
works
is
that
these
self-destruct
will
not
clear
storage
and
then
there's
a
new
OP
code
called
X
clear,
which
will
remove
specific
storage.
So
this
addresses
the
unbounded
amount,
so
that's
o
of
n
versus
o
of
One
cost,
and
so
this
is.
This
is
a
couple.
This
is
a
big
change.
This
is
these
are
big
changes
in
the
way
these
things
work.
B
The
self-destruct
here
would
just
be
getting
rid
of
the
code,
not
this
storage.
This
empowers
the
create
two
reincarnation
proxy
pattern
by
retaining
storage
during
an
upgrade.
That's
an
important
idea
too.
Do
you
want
to
retain
storage
people
want
to
upgrade
smart
contracts,
they
want
to
keep
storage.
That's
why
they're
using
proxy
pattern.
This
would
Empower
that
new
feature
by
not
deleting
this
torch
I
mean
this
is
a
cool
idea.
B
It
does
resolve
one
of
the
issues,
the
o1
o
n
problem
and
one
of
the
I
don't
know
if
it's
a
downside
or
a
concern
here
is
that
it's
materially
changing
it's
keeping
storage
that
previously
would
have
been
destroyed,
so
there
may
possibly
be
an
exploit
somewhere
if
this
is
implemented,
because
it's
it's
it's
it's
allowing
new
storage
in
a
place
that
previously
there
would
not
have
been
storage.
So
that's
that's
a
big
thing.
B
However,
it's
very
practical,
so
this
paper
does
address
the
problem
that
exists
and
the
way
to
use
this
self-con
destruct
that
we
don't
like
for
something
more
productive.
Personally,
I
think
this
is
a
new
OP
code.
I
think
this
should
be
a
new
OP
code
for
what
they're
proposing
here,
because
this
is
a
different
Behavior.
But
then
again,
if
you
know,
if
you
have
an
OP
code
that
nobody's
using,
does
it
matter
to
reuse
it
I
don't
know.
B
B
Vitalik
is
a
co-author
on
this,
as
well
as
a
Campbell,
a
and
Deng
round
Feist.
So
this
is
simpler,
so
it's
less
features
of
self-destruct
and
it
still
addresses
this.
One
also
addresses
the
010
problem.
We
have
o1
cost
and
o1
effect.
The
o1
effect
is
just
sending
ether,
so
this
one
is
straightforward
and
it
doesn't
remove
the
code.
B
So
if
the
code
is
not
gone,
that
means
that
you
cannot
reinstantiate
with
a
different
value
with
a
different
smart
contract
and
remember
vitalik
is
the
one:
was
the
author
of
The
create
two,
so
he
kind
of
brought
these
polymorphic
smart
contracts
into
the
world
and
he's
taken
them
out
by
not
allowing
smart
contracts
to
reuse
the
same
address
with
different
code.
So
this
addresses
the
polymorphic
contracts
which
I'm
I'm
a
fan
of
not
having
polymorphic
contracts.
As
you
know,
it
addresses
the
O
of
once.
B
B
B
Why
we're
going
to
deprecate
something,
but
it's
a
lot
harder
to
describe
why
you're
not
going
to
delete
code
or
you
know
you
got
to
justify
more
because
that's
a
bigger
change,
what
what
they're
doing
so
either
one
of
these
I'd
like
to
see
a
lot
more
in
the
EIP
itself,
as
a
trading
okay,
vertical
compatible
self-destruct,
so
verkle
will
be
the
new
storage
construct.
Verkle
replaces
Merkle
trees
for
the
tree
t-r-I-e
and
the
way
verticals
is
going
to
work.
It's
going
to
use
a
witness
wave
my
hands
here.
B
Basically,
we're
going
to
use
zero
knowledge
proofs
to
verify
storage
instead
of
trees,
which
are
log
2
of
this.
The
state
tree
right
so
this
is
this-
is
the
Brave
New
World
of
zero
knowledge
proofs
getting
closer
and
closer
to
ethereum
if
you've
been
reading
any
of
these
IPS.
You
know
that
this
is
there's
a
lot
of
people
thinking
about
this
stuff
and
it's
finally
coming
together
and
so
of
course,
there
will
be
a
vertical
self-destruct
proposal
here.
You
know
it's.
A
big
problem
relates
to
another
change.
B
B
The
purple
trees
will
be
organized
differently,
so
the
problem
here
is
that,
even
if
you
wanted
to
go
delete
all
these
storage
locations,
it
will
be
harder
under
vertical
trees
than
it
would
be
under
the
existing
storage
mechanism.
So
this
EIP
is
going
to
help
with
this
storage
future
in
under
vocal
trees.
So
this
one
is
going
to
change
so
that
we
kind
of
have
a
knots
cookie.
What
do
we
call
this?
We're
going
to
have
a
specific
storage
thing
that
we're
gonna
plop
in
there
to
what's
a
sentence.
B
Sorry
Sentry
value,
we're
going
to
use
a
Sentry
value
of
0
1
for
the
contract's
code
and
we're
going
to
Century
value
for
the
nonce
and
we're
going
to
set
this
so
that
we
can
identify
things
that
have
been
destructed.
So
this
is
kind
of
a
trick.
You
know
you're
writing
code,
you've
got
a
zero
and
then
you've
got
like
a
not
initialized.
So
you've
got
to
have
like
a
special,
not
initialized
thing.
That's
not
zero!
That's!
What's
going
on
here!
B
We've
got
the
top
code,
so
this
is
if
the
contract
was
self-destructed
after
the
call
the
zeroth
so
they're
going
to
put
some
storage
specifically
we're
gonna.
This
is
a
half
price.
So
we're
going
to
use
the
storage
in
the
smart
contract,
we're
going
to
use
the
code
we're
going
to
put
nuts
Sentry
values
in
there
and
we're
going
to
identify
if
this
thing
has
been
self-destructed
just
working
with
the
limitations,
you
have
to
get
the
effect
that
you
want.
B
Okay,
so
this
is
I
think
this
is
more
mechanical
in
the
way
that
this
is
written
but
cool
and
definitely
forward
thinking
last
one
replace
self-destruct
with
deactivate,
so
change
self-destruct
to
not
delete
storage,
keys
and
use
a
special
value
for
the
knots
okay.
So
we're
hearing
that
again
to
Signal
deactivation,
change,
self-destruct
and
not
delete
storage
keys
and
use
a
special
value.
Okay,
because
of
the
semantics,
we
also
rename
it
to
activate
it.
B
B
Eip
2681
has
a
limit
on
nonsense,
I
believe
yep.
So
we
want
to
so
that
that,
actually
you
don't
need
to
do
that,
because
you
can
just
pick
a
high
number.
You
don't
need
to
add
a
bit
there
nobody's
going
to
use
this.
Many
of
anything
the
behavior
of
self-destruct
has
changed.
That's
not
the
lead
storage,
it
leaves
the
account
in
place
transfer
the
account
balance
to
the
Target
set
the
bounce
to
zero.
Okay,
we're
going
to
use
a
special
value
for
the
knots
we
have
no
refund
because
the
refunds
are
reduced.
B
The
rules
are
on
how
self-destruct
works
is
unchanged.
Gas
changes,
okay,
not
affected,
modify
the
account
execution,
so
the
execution
succeeds
returns
an
empty
buffer.
So
it's
basically
going
to
say
that
it's
empty,
basically
we're
going
to
treat
it
as
an
empty
account
and
it
looks
like
this
is
going
to
prevent
redeploy
them.
On
top
of
that,
because
there's
going
to
already
be
code
there
and
an
odds,
this
is
not
nearly
enough
words.
Contract
authors
must
be
aware
and
design
accordingly.
That
is
not
enough
words
on
this
topic
yeah.
B
This
looks
actually
very
similar
to
deactivate,
so
we
have
deactivate
and
then
well.
Those
are
the
profile
called
root.
Deactivate
I've
also
seen
another
proposal,
but
I
don't
see
an
EIP,
so
maybe
it
didn't
make
it
to
drift,
which
was
just
to
no
op
self-destruct.
It
just
doesn't
do
anything
that
one
did
go
anywhere.
B
B
If
you
have
the
ajson
API
and
you
have
a
full
node
that
you
can
actually
query
the
storage
state
of
anything,
you
can
just
pick
a
storage
State
and
query
it,
and
so
right
now,
if
you
do
self-destruct-
and
you
query
it-
you
get
nothing,
it's
just
you
get
zero
right,
because
the
storage
is
gone
default
is
zero.
Your
querying
you're
getting
a
zero
response.
So
these
proposals,
if
you're
not
deleting
it,
then
theoretically,
the
Json
API-
should
return
that
number.
When
you
get
it.
So
that's
really
changing
the
semantics
here.
B
I
think
that
when
we
change
these
things,
we
should
keep
the
semantics
up
when
something's
been
destroyed.
The
needs
to
Return
To
Zero
needs
to
Return
To
Zero
somewhere
now.
I
think
some
of
the
reason
we
have
so
many
different
ideas
here
is
because
probably
these
VIPs
are
they're,
probably
wrong.
These
eips
are
focused
more
on
the
implementation
than
the
desired
outcomes
that
we
need.
B
We
don't
specify
implementations,
we
specify
outcomes
if
we
just
say
hey
when
you
have
a
zero
of
one
operation
like
self-destruct
and
all
the
storage
states
are
going
to
change,
that's
something
you
know.
That's
that's
an
implementation
problem
that
it's
a
zero
of
n
effect,
there's
another
way
to
implement
this,
where
it's
just
zero
of
one
effect.
The
way
you
do
that
is,
you
just
put
an
answer,
a
secret
value
or
whatever,
and
you
don't
even
specify
any
of
this.
You
can
just
say
you
can
just
go
down
here
into
the
rationale
and
say:
look.
B
Maybe
today
there's
an
attack
or
there's
a
problem
because
there's
a
zero
of
one
cost
and
a
zero
of
an
effect,
but
that's
an
implementation
problem.
That's
not
my
problem.
You
can
fix
this
in
other
ways.
Here's
a
potential
solution,
here's
another
potential,
Solution!
That's
your
problem
before
team,
you
go.
You
go
Dev
this
and
make
this
work,
but
there
are
solutions
here
and
we're
not
going
to
specify
them.
We
will
specify
that
this
is
changing
and
this
is
changing.
We
are
specifying
that
you
can't
redeploy
the
same
address,
that's
something
that
can
be
specified.
B
That
definitely
requires
a
zero
of
one
effect,
at
least
on
zero
zero,
and
so
there
will
be
some
effect
here,
but
it's
not
zero
of
n
Over
N,
Z,
It's,
Not,
O
of
n
effect
here,
and
so
so
yeah.
So
really,
if
you,
if
you
consider
that
these
are
looking
more
similar
than
they
are
different
right
now
anyway,
the
main
point
here
is
that
there's
a
lot
more
discussion
that
needs
to
be
written
down.
B
A
Right
so
we
have
quite
a
few
proposals
with
different
ideas.
Maybe
different
implementation
use
cases
for
consideration,
but
as
we
know
that
an
upgrade
when
we
are
making
an
upgrade
on
ethereum
blockchain,
are
there
a
lot
of
things
to
be
considered?
So
if
we
have
to
put
it
put
self-destruct,
maybe
on
a
priority
list?
Where
do
you
see
if
we
have
a
set
of
proposals
for
evm
improvement,
set
of
proposals
for
maybe
scalability
and
then
there's,
of
course,
a
real
self-destruct?
B
This
is
only
effective,
so
this
is
a
prerequisite,
so
prerequisites
are
automatically
number
one
priority
before
something
else
right.
So
this
is
a
prerequisite
for
scalability,
depending
on
how
we're
scaling
and
when
I
say,
scale,
building
I'm
talking
about
side
chains,
if
ethereum
ever
has
an
official
L2,
which
I
think
is
shed,
it
probably
won't
or
it
supports
various
distributed
side
chains.
Then
having
these
counter
factuals
will
probably
be
a
component
of
that,
and
that
is
something
that
needs
to
be
baked
into
the
sauce
here
right.
B
So
if
we're
going
to
do
that,
then
we
cannot
have
mutable
contracts.
That's
that's
a
problem
with
that
or
they'll
just
have
to
be
built
a
certain
way,
but
I
think
it's
a
really
okay,
so
I'm
gonna
I'm
gonna
debate
what
I
said
it
would
be
a
really
nice
step,
not
a
priority.
One
it'd
be
really
nice
to
have
self-destructs
dead
the
way
they
are
today
before
we
have
side
chains.
B
If
the
side
chains
are
going
to
work
using
counter
factuals,
which
they
probably
won't
otherwise,
honestly
we've
kind
of
let
some
of
the
steam
out.
It
really
doesn't
matter
as
much
so
people
are
aware
of
these
issues.
We
know
that
there's
problems
and
we
know
that
if
you
launch
a
new
smart
contract
that
it's
going
to
possibly
change
the
way
it
works
and
honestly
that
kind
of
solves
a
lot
of
the
problem.
B
So
I'm
not
saying
you
know,
I'm
not
patting
myself
in
the
back
here,
I'm,
not
saying
our
work
is
done,
I'm,
just
saying
that
we
and
it's
not
like
we
bought
time.
It's
just
that.
We've
removed
some
of
the
Practical
problems
with
self-destruct
that
existed
a
few
months
ago
and
no
longer
exist.
Now
those
practical
problems
of
people,
not
people
walking
in
lava
and
not
knowing
that
they're
walking
on
lava
that
problem's
gone
people
saying
Oh,
I
thought
I
was
building
on
this.
B
This
makes
sense
in
your
rug
for
me
that
problem's
gone,
because
when
the
old
people
says
warning
now
it's
their
problem.
You
know
we
can't
be
responsible
for
customers
that
are
not
reading
the
documentation.
You
know
there's
XKCD
for
that,
so
we
put
it
in
there
they're
responsible
and
now,
if
it
turns
out
that
none
of
the
existing
Universe
of
smart
contracts
are
affected,
then
practically
we're
mostly
solved
so
zero.
A
Right
and
I
think
the
next
upgrade
Cancun
upgrade
will
be
mostly
centered
towards
eap4844
that
we
are
trying
to
come
up
with
for
solving
the
issue
of
you
know
with
the
concept
of
blob.
So
probably
it's
a
good
thing
to
have
in
place,
and
hopefully
one
of
these
proposals
make
room
to
the
Cancun
upgrade
cool.
A
While
I
have
you
on
this
call
today
and
I
know
you
are
an
experienced
author,
you
have
written
a
proposal
for
I
think
four
out
of
the
six
different
types
and
categories
that
we
have
like.
We
have
four
under
standard
track
and
meta
and
informational.
So
what
do
you
think
in
general?
Maybe
a
couple
of
good
points
about
the
present
process.
If
there
are
any
and
couple
of
points
that
needs
to
be
improved
sooner,
the
better.
B
So
we
have
an
RSS
feed
here,
please
sign
up
for
the
RSS
feed.
This
is
how
you'll
know
about
new
IEPs
or
also
have
a.
We
have
an
RSS
feed
here.
We
also
have
an
email
button,
so
I
rewrote
the
homepage
for
IPs.
That's
there's
a
PR
for
that,
hopefully,
by
the
time
you're
watching
this
video
there'll
be
an
email
button
and
you
can
just
get
email
updates
because
not
everybody
uses
RSS
right.
So
we
need
to
get
more
eyeballs
on
this
and
we
need
to
consider
the
technical
aspects,
the
non-technical
aspects.
B
We
really
need
to
just
get
these
core
APS
in
more
eyeballs
in
front
of
more
eyeballs
right,
so
I
have
an
interest
right
now
in
doing
that.
Why
do
I
think
that?
Well
we
had
an
EIP
that
was
aborted
in
the
past.
That
was
a
change
of
the
storage
cost.
There
was
anyip
proposed.
It
was
announced
on
the
blog
on
blog
ethereum.org.
It
was
scheduled.
It
was
coming
and
then
24
hours
before
that
it
was
aborted.
B
That
is
a
disaster.
We
cannot
be
telling
people
not
to
upgrade
their
clients
24
hours
before
a
major
production
change.
That
demonstrates
that
there
was
not
enough
pre-work
into
this
now.
I
know
that
we've
learned
from
this
incident
and
we've
would
have
learned
a
lot
more.
If
we,
you
know,
had
a
serious
forking
problem
in
uncles
and
whatever
from
a
failed
upgrade,
but
because
of
ethereum
2
or
what
it
would
call
right
now,
the
consensus
layer
which
is
separated
right
because
of
what
we
have
now
and
because
of
slashing.
B
We
can't
make
this
mistake
ever
again,
so
we
had
training
wheels
before
in
the
past
with
ethereum.
If
you
made
a
mistake
like
we
almost
did
with
that
one
and
we
aborted
it
and
you
have
two
different
Networks,
those
two
networks
live
and
then
one
of
them
dies.
Does
that
make
sense?
I
want
to
build
on
that
point.
B
B
So
now
that
we
have
slashing,
you
can't
do
that
when
you
have
a
network
sort,
you
go
this
way.
Other
people
go
this
way
you
get
slashed.
That
is
a
problem.
You
lose
all
your
ether
right.
That
is
a
major
problem
and
because
all
of
our
staking
is
done
by
these
large
groups
like
coinbase
and
other
centralized
parties,
they're
going
to
decide
the
future
of
ethereum
because
they're
the
ones
who
are
going
to
get
slashed.
You
know
on
behalf
of
everybody
if
they
mess
up,
so
we
cannot
ever
have
a
fork
going
forward.
B
There's
no
more
forking
in
ethereum.
There
will
never
ever
be
another
hard,
Fork
interfering,
we're
doing
our
upgrades
they're,
not
hard
scores,
maybe
they're
hard,
Forks,
there's
no
more
branching!
There's
one
path
forward
right
because
of
ethereum
2
that
we
have
today
and
because
of
the
slashing.
We
cannot
make
this
mistake
ever
again,
which
means
we
can't
mess
up
ever
again.
The
training
wheels
are
off.
If
we
mess
up,
this
will
be
hundreds
of
billions
of
dollars
lost.
B
So
the
way
that
we
don't
mess
up
is
we
go
more
carefully
and
we
have
more
eyeballs
and
we
consider
things
that
are
technical,
like
Hey.
How
do
I
Implement
vertical
treats
that's
technical
or
not
technical
things
like
wow,
you
told
me
all
this
nerd
stuff,
but
transactions
are
going
to
clear
one.
Second
slower,
that's
a
serious
problem,
because
this
is
a
diversity
of
thought
that
we
need
core
developers
might
not
think
of
the
difference
between
seven
second
or
eight
second
block
times,
but
somebody's
written
a
paper.
B
Somebody
who
doesn't
contribute
to
the
code
in
the
Corey
IPS,
but
understands
the
difference
between
seven
seconds.
Eight
seven
block
times
might
have
some
paper
about
the
amount
of
time
it
takes
light
to
go
around
the
earth
and
times
or
that
you
know
the
blockchain.
The
block
times
have
a
major
impact
on
security
and
some
other
things,
and
we
need
these
people
talking
together,
I'm
just
making
up
an
example.
B
That
might
be
a
poor
example,
but
there
will
be
some
situation
where
core
developers
are
building
something
and
other
people
are
affected
and
their
communication
would
be
really
appreciated
if
we
Fork
the
IPS
into
eips
and
erc's
today,
before
all
these
big
changes,
that'd
be
a
problem
and
correction,
it
would
lead
to
less
eyeballs,
and
that
would
be
the
problem
and
so
I'm
against
forking.
This
right
now,
I
want
to
see
everybody
get
through
these
big
changes.
B
We
have
going
forward
and
I'd
like
to
see
ethereum
have
an
L2,
Network
or
side
chains
or
something-
and
we
have
to
do
this
together
and
really
at
that
point
we
don't
even
need
the
IPS
anymore,
because
ethereum
will
be
done.
You
know
this
is
not
like
a
forever
project.
There's
a
reason
that
we
have
the
the
upgrade
difficult
difficulty
bomb
is
because
we
wanted
this
work
to
get
done.
We
know
it
needs
to
get
done.
B
We
have
to
do
it
and
then
we
take
the
can
a
little
bit,
but
then
it
gets
done
so
there
shouldn't
be
more
work
to
do.
We
will
get
to
that
point
and
then,
at
that
point
this
discussion
becomes
Moon
because
there's
just
less
things
to
change
and
now
everything's
at
the
application
layer.
Bitcoin
already
reached
that
point.
B
People
on
bitcoin
are
not
discussing
oh
application
standards,
we've
got
Bitcoin
ordinals,
that's
about
the
biggest
Improvement
that
we've
had
the
biggest
Innovation
we've
had
at
the
application
layer
on
top
of
Bitcoin,
and
we
had
block
sizes
like
that's
it.
That's
a
mature
protocol.
Ethereum
is
going
to
get
there
and
pretty
soon
too.
A
Awesome,
these
are
quite
wonderful
thoughts
and
I
would
like
to
touch
on
couple
of
points.
One
point
that
you
mentioned
is
the
communication
of
the
core
eips
and
people
who
are
not
actually
involved
in
creating
those
VIPs
or
maybe
in
implementation
part.
So
recently,
what
we
have
done
like
we
have
added
a
special
tag,
which
is
called
Network,
upgrade
tag
for
the
discussion
on
discussion
forum
Fellowship
of
ethereum
magician,
where
at
the
time
when
the
proposal
is
proposed,
The
Proposal
discussion
link
will
have
that
tag.
A
So
people
will
know
in
advance
that
this
proposal
is
under
discussion
for
the
upcoming
upgrade.
So
anyone
on
the
Forum,
including
all
developers,
project
developers
that
decentralized
app
developers
they
can
come
and
share
their
thoughts.
So
we
are
trying
to
open
this
communication
Channel
between
the
people
who
are
implementing
it
on
the
core
protocol
and
people
who
are
maybe
ultimately,
the
user
of
these
protocol
for
their
respective
project
and
on
the
on
the
topic
of
working
of
EIP
and
ERC
I.
A
B
B
Nope
I
think
you
just
gotta
stay
tuned.
You
gotta
sign
up
for
the
blog
you're
going
to
sign
up
on
their
last
calls
feed
and
just
read
through
this
stuff.
You
know
people
is
we're
talking
about
technical
things,
but
they're,
not
technical
things.
They
affect
everybody
and
they're,
pretty
clear,
so
don't
be
intimidated
by
any
of
this
stuff.
Listen
through
these
podcasts
subscribe
on
YouTube
to
Peep
and
eat
right,
just
listen
through
and
you
know
these
are
changes
right.
These
are
changes,
so
the
changes
will
get
slower.
A
William,
we
really
appreciate
you
taking
out
time
to
share
about
this
matter
if
60
49
deprecates
self-destruct,
with
the
release
of
this
episode,
my
hope
is
that
it
will
help
tap
developers
to
pay
attention
to
the
warning
and
consider
removing
self-destruct
or
code
from
their
respective
projects
if
they
haven't
done
it
already,
and
on
this
note,
thanks
to
everyone
watching
on
listening
to
the
chapel
special
episode,
should
you
have
any
question?
Let
us
know
in
the
form
available
in
description
or
leave
a
comment.