►
From YouTube: PEEPanEIP #115: EIP-6780-SELFDESTRUCT only in same transaction with Guillaume Ballet #SELFDESTRUCT
Description
Resources:
-----------------
EIP-6780 - https://eips.ethereum.org/EIPS/eip-6780
Slides - https://docs.google.com/presentation/d/1YIJ0fvPEWsl6C7Zgb8OlcN_P4y0y7nW0HAAlNRDI3Vw/edit?usp=sharing
Discussion to - https://ethereum-magicians.org/t/deactivate-selfdestruct-except-where-it-occurs-in-the-same-transaction-in-which-a-contract-was-created/13539
YT Shorts : https://youtube.com/shorts/p1Ic6-NggXA
PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Dencun - https://www.youtube.com/playlist?list=PL4cwHXAawZxpnKFDl1KzGOKqwux5JaLlv
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow at Twitter
--------------------------
Guillaume Ballet @gballet | Pooja Ranjan @poojaranjan19
Topics covered
-------------------------
1:43 - Meet the guest
3:35 - Presentation EIP-6780
4:27 - Why SELFDESTRUCT was added to the protocol?
5:30 - Problems: Non-deterministic
6:55 - Parity Multisig
7:49 - Code mutability
9:04 - Verkle tree
12:30 - Security TL;DR
13:40 - Comments received on FEM post
14:29 - Other proposals for removal
17:26 - Conclusion EIP-6780
18:15 - Endo of presentation
19:00 - What are the main advantages of this EIP?
21:07 - Is this intended as a transitional EIP or a permanent change to EVM
23:44 - Client implementation & testing - Will it be included in devnet 8?
25:27 - Experience documenting the EIP
28:30 - Is it ready to be moved to "Review"?
29:16 - Why it took too long to bring SELFDESTRUCT TO the upgrade for the mainnet?
31:50 - Message to the community
A
A
Welcome
to
P
pennyb
episode,
115
I
am
Pooja
ranjan.
In
this
Den
fund
special
episode.
We
are
going
to
be
talking
about
EIP
6780
self-destruct.
Only
in
same
transaction
documented
in
March,
2023
The
Proposal
is
co-authored
by
Gian
belay,
vitalik
buteran
and
Dan
grad
Feast.
It
is
currently
in
the
draft
status
to
learn
about
the
EIP.
What
changes
will
it
bring
to
the
ethereum
main
net?
We
are
joined
by
one
of
the
co-authors
and
go
ethereum
developer.
Guillaume
Valley.
Welcome
to
the
show
game.
Well,.
A
Have
had
Guillaume
on
the
show
earlier
to
share
information
on
eip3102
binary,
try
structure,
a
proposal
to
change
the
storage
structure
from
x-ray
to
Binary.
If
you
are
interested
to
learn
more
about
the
proposal
check
out
the
link
available
in
description,
the
general
format
of
this
show
in
includes
a
presentation
followed
by
question
answer,
but
before
we
dive
D
for
our
new
viewers
and
listeners,
may
I
ask
ion
to
share
a
brief
introduction
and
the
journey
in
the
ethereum
ecosystem.
B
Sure,
yes,
so
that's
working
on
the
go
ethereum
team
and
I'm
also
heading
to
another
team
in
inside
the
EFS
called
stateless
consensus
where
we
work
on
bringing
about
stateless
ethereum,
so
yeah,
that's
currently
that's
focusing
on
vocal
trees.
How
did
I
get
into
ethereum
I
mean
I
was
interested
in
cryptocurrencies
for
since
20
2014
and
I
had
an
opportunity
to
join
the
guest
team
in
in
2017,
so
I
did
that
and
since
then
I
got
dragged
into
protocol
and
protocol
development
and
also
research
yeah.
B
So
most
of
my
time
is
is
spent
working
on
vertical
trees
and
we
have
just
put
up
a
website
to
explain
vocal
trees
and
how
they
impact
ethereum,
how
you
can
help
how
they
work
and
so
on.
So
it's
that
website
work
all
that
info.
And
yes,
another
thing
I
can
say
about
myself.
Is
a
lot
of
people.
Ask
me
about
my
avatar.
B
So
that's
why
I
put
like
this
big
picture
on
the
slide
and
the
the
origin
is
that
it
comes
from
there's
a
some
kind
of
stairway
in
sug
right
next
to
the
lake,
where
somehow,
at
the
end
of
the
of
this
terrible.
For
some
reason,
it
just
gives
you
a
view
of
the
LA,
the
lake
underwater.
It's
pretty
muddy,
so
you
don't
really
see
anything.
But
when
you
take
a
picture,
it
looks
very
like
it's.
The
this
is
a
room
full
of
hazardous
materials.
A
B
So
the
principle
is
that
if
self-destruct
is
called
in
the
same
transaction
that
created
the
contract,
it's
like
it's
retaining
the
old
Behavior,
but
if
it's
called
in
a
further
transaction,
then
it
could,
like
the
traction,
has
the
behavior
of
another
instruction
we
propose,
which
is
called
send
all
where
all
the
funds
are
sent
to
the
Target
address,
but
the
nonce,
the
code
and
the
storage
are
kept
as,
as
is
okay.
So
let's
maybe
talk
about
a
bit
about
self-destruct.
Why
would
why
do
we
want
to
to
remove
it?
B
Well,
let's
look
at
why
we
wanted
to
have
it
in
the
first
place.
So
initially
it
was
called
suicide
when
the
initial
proposal
and
I
think
there
was
actually
the
much
better
name,
because
it
really
implies
what
you're
doing
when
you're
trying
to
call
this
this
instruction,
it's
an
instruction
that
is
fraught
with
Peril
and
yeah.
It
was
initially
meant
to
as
the
first
mitigation
effort
to
to
prevent
State
growth,
try
to
reward
people
from
cleaning
up
after
their
cleaning
robusters
themselves
trying
to
to
delete
contracts.
B
They
no
longer
need
to
recover
some
gas,
but
you
can
see
from
the
get
the
the
number
of
account
creation
since
the
beginning
of
ethereum
that
it
has
really
does
work
to
yeah.
It
has
really
the
the
initial
intent
was
not
realized
so,
and
on
top
of
that,
this
instruction
has
many
many
yeah
perils,
so
I
will
just
go
over
some
of
them.
The
first
one
is
that
it's
not
really
deterministic
I
mean.
B
Will
cost
you
exactly
the
same
amount
of
gas,
and
that
is
a
problem
because
yeah
like
potentially,
if
you
delete
a
very,
very
large
contract
with
gigabytes
and
gigabytes
of
storage,
you
should
you
should
not
pay
the
the
same
amount
of
gas
as
a
very
simple
contract,
and
if
you
try
the
worst
still,
if
you
try
to
actually
account
for
the
amount
of
data
that
is
accessing
the
all
the
disk
access
and
all
the
computation
that
is,
that
is
done.
You
could
actually
run
out
of
gas
while
deleting
a
contract.
B
So
then
you
will
end
up
in
a
state
that
is
undefined
and
that's
really
not
good.
So
yeah,
that's
I
would
say.
That's
the
first
problem
with
self-destruct.
Next
problem
was
brought
out
to
lights,
with
the
story
of
the
parity
multi-sig.
So
what
they
did
is
they
had
this
wallet
management
code
that
was
relying
on
the
Central
Library.
B
So
when
you
would
deploy
your
wallet
and
they
deployed
a
multitude
of
them,
they
would
all
rely
on
the
same
contract
that
they
call
the
the
library
and,
for
some
reasons,
I
will
not
get
into
someone
got
ownership
of
the
contract
and
self-destructed
it.
So
all
those
wallets
that
needed
this
other
contract,
this
Central
contract
to
do
all
their
logic,
could
no
longer
function,
and
that
means
those
wallets
were
effectively
like
all.
B
The
funds
in
those
wallets
were
effectively
locked,
and
that
includes
parity
that
has
lost
a
lot
of
a
lot
of
funds
in
this
pickup.
Another
problem
is
that
it
allows
for,
like
with
the
existence
of
the
instruction,
create
two
it
allows
for
code
mutability,
and
this
is
a
problem,
for
example,
if
we're
going
to
move
into
account
abstractions.
So
here
you
have
like
this
is
a
small,
an
attempt
at
representing
your
account
abstraction.
B
You
have
a
lot
of
users
with
their
transactions
and
they
don't
want
to
pay
the
gas
cost
of
realizing
all
those
transactions
on
chain
directly,
so
they
go
through
a
relayer
that
does
some
kind
of
aggregate
packages
all
the
transaction
and
creates
a
package
transaction
to
be
applied
to
the
wallet
on
chain.
The
problem
is
if
a
hack
such
as
the
parity
one
happened,
this
the
wallet
gets
self-destructed
and
all
those
transactions
end
up
being
completely
irrelevant.
B
Worse
still,
those
users
could
actually
like
someone
who
self-destructed
the
wallet
could
replace
it
with
another
wallet
that
is
either
whoops
extortionary
or
you
know,
just
has
a
back
door
or
whatever
those
users
then
be
able
to
use
their
transactions,
but
the
package
transaction
like
this
wallet
could
do
whatever
it
wants
with
the
package
transactions.
So
this
is
a
problem
and
the
last
problem
in
in
for
me
the
biggest
it's
the
way
we
propose
to
to
do
vertical
trees.
B
So
we,
instead
of
having
one
tree
that
contains
all
the
accounts
and
then
each
account
has
one
subtree
for
all
its
storage
slots.
Everything
would
be
spread
over
one
single
tree
and
there's
no
way
we
lose
the
ability,
given
an
account
to
enumerate
all
its
slots,
all
its
storage
slots
or,
conversely,
given
a
slot
there's
no
easy
way
to
find
which
account
it
belongs
to
so.
B
This
is
extremely
easy,
of
course,
as
you
execute
the
block,
but
when
you
look
at
the
tree
as
a
whole,
without
knowing
the
primages
of
every
key
in
that
tree,
you
cannot
really
see
what
slot
belongs
to
our
account
so
effectively.
The
only
way
we
could
do
to
delete
an
account.
The
only
way
we
could
self-destruct
an
account
in
vertical
tree
would
be
to
just
delete
this
account,
but
right
sorry,
I
should
have
explained
the
Red
Square
represents
an
accountant.
All
the
green
squares
represents
the
slots
belonging
to
this
account.
It's
a
simplified
model.
B
You
create
a
contract
and
access
all
the
for
some
reason.
You
delete
a
contract
near
C32.
You,
an
exploiter,
could
find
a
way
to
delete
the
contract
and
replace
it
with
a
new
erc20
contract
that
they
control.
So
they
would
access
yeah
all
the
tokens
they
would
control.
All
the
tokens
of
the
network
really
and
the
other
problem
could
also
be
I
mean
if
it's
not
necessarily
malicious.
It
could
also
be
some
technique
where,
because
it
happens,
there
are
some
contracts
that
like
to
create
some
subcontract
and
then
self-destruct
them.
B
This
could
happen,
but
then
the
because
the
state
was
not
properly
deleted.
All
the
previously
initialized
state
will
be
there
and
that
might
that
might
disturb
the
proper
execution
of
the
contract.
So
it's
a
very
fecal
and
difficult
and
dangerous
instruction.
I
just
want
to
go
over
the
client
support,
so
most
clients
have
implemented
it
for
there's
a
caveat
here
for
reth,
so
I
contacted
every
client
to
confirm
except
breath.
I
didn't
have
the
time
to
do
it.
So
I
went
to
their
source
code.
I
see
it's
not
there.
So
I
apologize.
B
If
they
have
implemented
it
and
I
missed
it,
but
yeah.
Otherwise,
everybody
except
Aragon
confirmed
that
they
they
had
an
implementation,
it
hasn't
really
been
tested
yet
I
mean
it's
been
tested.
Each
client
did
their
own
test,
but
it
hasn't
been
tested
on
the
tested.
Yet
because,
since
its
package
was
4844
and
the
4844
is
the
major
EIP
to
go
into
Den
Kun
yeah,
it's
it
gets
the
priority,
but
of
course
it
will
be
tested
before
we
get
into
the
fork.
B
Simply
it's
not
the
priority
right
now
right
so
I
was
asked
to
talk
a
bit
about
the
security,
so
we
commissioned
a
company
called
ddob
to
do
the
audits
I
just
stole
one
of
their
slides
and
basically,
what
this
says
is
that
the
impact
of
using
EIP
6780
is
very
mild.
So
they
looked
at
different
use
cases
and
they
tried
to
understand
why
people
use
self-destruct
and
especially,
why
do
they
use
self-destruct
conjunction
with
create
two?
So
this
is
yeah.
B
B
Unfortunately,
yeah,
it's
not
really
clear
who's
who
this
person
is
or
what
project
they
work
on,
so
I
most
also
making
a
call
if
you
have
a
use
case,
if
that
makes
that
yeah,
that
would
point
out
that
our
analysis
was
incomplete.
We
would
like
to
to
know
that,
if,
if
it's
really
a
problem
in
this
case
just
reading
this
description,
which
is,
of
course,
not
complete,
it
seems
to
me
that
the
best
way
forward
would
be
for
this
person
to
tell
all
its
users
to
migrate
their
tokens
before
the
fork.
B
Maybe
there's
a
good
reason
not
to
do
this
so
yeah,
starting
to
get
very
pretty
late
to
provide
this
information.
So
please
do
it
ASAP,
because
yeah
I
just
wanted
to
mention
there
were
some
other
eips.
We
looked
at
other
method.
We
we
looked
at
so
the
first
one
was
the
complete
removal.
It's
clear
that
this
is
a
bit
too
harsh
to
to
perform.
B
So
that's
that's
why
we
came
up
with
6780.
There
was
another
one
Progressive,
so
it's
basically
the
same
idea
as
the
difficulty
bomb.
Every
time
someone
uses
self-destruct,
the
self-destruct
becomes
more
and
more
expensive,
and
the
idea
is
that
it
would
force
people
to
realize
that
something
is
wrong
and
and
come
up
with
a
migration
pass
themselves.
So
that
would
be
a
user
activated
migration
path
and
there
was
another
EIP
which
was
deactivate.
B
So
that's
that
would
just
when
you
call
self-destruct
instead
of
just
deleting
all
the
data
it
would
just
Mark
the
contract
as
deactivated.
This
one
suffers
from
the
problem.
I
described
earlier,
that
you
could
invert
in
a
vocal
tree
context.
You
would
reactivate
the
contract
and
still
obtain
the
former
States,
so
something
could
be
poorly
initialized
or
yeah
like
the
contract
would
could
find
itself
in
a
state.
It
would
not
expect
itself
to
to
find
itself
and
there's
another
one.
B
That's
called
vertical
compatible
and
this
one
was
deemed
too
complex
compared
to
the
benefits
it
would
bring.
So
we
are
aware
of
some
contracts
that
would
be
broken
so
far
as
for
us,
we
can
tell
it
doesn't
Justified
the
complexity
that
this
approach
would
would
be,
and
it's
how
does
it
work?
A
very
quick
summary
it's
like
when
you
want
to
access
a
slot.
You
hash
the
address
of
the
account
and
the
number
of
its
slots.
We
would
add
the
self-destruction
counter
to
this
hash.
B
So,
every
time
you
want
to
access
a
slot,
you
have
to
mix
in
the
deletion
counter,
and
so
the
result
would
be
that
the
new,
like
a
contract
that
is
reactivated,
would
find
itself
with
a
blank
with
an
empty
state.
So
this
is
something
that
is
possible.
It's
especially
easy
to
do
with
vertical,
at
least
on
paper,
but
we
yeah
it's
it's
still
a
bit
more
complex
than
what
we
would
be
yeah
with
like
it's
a
bit
too
complex
to
to
implement.
B
Given
the
amount
of
broken
contracts,
we
see
who
are
not
very
worth
saving
for
lack
of
a
better
word,
so
we
could
potentially
enable
it
later,
especially
after
vocal
tree,
if
it
makes
sense
if
we
do
find
contracts
that
are
that
are
worth
saving
or
worth
the
complexity.
At
least
so
yeah,
like
I,
said
make
yourself
known.
B
If,
if
you
have
a
use
case
because
from
where
we
can
tell
there,
isn't
there
is
nothing
really
worth
the
complexity,
but
if
there
is,
we
want
to
know
yeah,
that's
pretty
much
it
so
I'm
going
to
share
the
slides,
so
you
can
go
check
the
EIP,
the
EOS
implementation.
So
eels
is
the
executable
spec
written
in
Python.
So
yeah
there's
there's
been
an
implementation
recently,
the
report
by
ddobs
and
yeah.
B
One
thing
I
want
to
press
as
a
conclusion
is
that
even
if
self-destruct
is
somehow
retained
in
some
capacity
do
not
use
it.
It's
an
instruction
that
is
fraught
with
Peril
and
we
would
like
to
I
mean
there's
no
promise.
We
will
not
get
rid
of
it
in
the
future.
We
might
re-enable
it
in
some
form
in
the
future
if
it
makes
sense,
but
our
preference
would
be
to
remove
it
all
together.
So
yeah
don't
talk
to
the
devil,
just
don't
don't
use
it.
Basically,.
A
All
right
yeah,
it
was
a
wonderful
talk.
I
really
appreciate
you
explaining
the
sell
this
track,
and
why
was
that
added
to
the
ethereum
in
the
first
place
and
the
progress
made
so
far,
sharing
high
level
of
vocal
tree
info
was
also
good
and
for
our
listeners
we
have
recorded
an
episode
on
Oracle
tree
with
Dan
Craig
Feast
a
while
ago.
Please
check
a
link
available
in
description.
Thank
you
so
much
for
this,
because
I
see
that
you
have
covered
most
of
the
questions
that
we
have
listed
here.
A
So
I
would
like
to
pick
up
a
little
bit
more
to
just
get
into
the
in
depth
of
some
of
the
small
knits
and
bits
that
we
perhaps
met,
as
you
mentioned
in
the
slide
that
there
were
multiple
eips
for
self-destruct,
and
you
also
explained
very
well
that
6190,
which
is
vertical
compatible,
seems
to
be
a
bit
complex.
I'll,
be
curious
to
hear
you
know
what
are
the
major
advantages
that
we
see
this
proposal,
making
changes
on
ethereum
and
why
we
prefer
this
over
any
other
for
Den
cone
upgrade
yeah.
B
So
the
reason
why
we
prefer
this
one
is
because
it
seems
like
the
the
best
compromise
I
would
say
it
doesn't
break
too
many
contracts,
at
least
as
far
as
we're
aware,
and
it's
simple
enough-
it
doesn't
hit
the
so
when
you
create
a
contract
at
the
end,
all
the
contracts,
all
the
new
addresses,
are
kept
in
some
location
in
memory
and
then
at
the
end
of
the
block
they
get
flush
to
disk
unless
they
get
destructed.
In
the
meantime,
of
course,
so
for
us,
it's
nice,
because
it's
contained
everything
is
done
in
memory.
B
There's
no
going
back
and
forth
between
the
disk,
like
we
get
rid
of
those
use
cases,
so
it's
really
much
simpler
and
it
offers
all
the
nice
features
that
we
want.
I
talked
about
Roku
trees,
but
also,
if
we
look
at
replacement
with
biomalicious
contract,
like
what
I
what
I
mentioned
for
accounts
obstruction.
That
doesn't
really
become
a
use
case,
because
presumably
users
will
not
try
to
use
the
account
abstraction
contract
or
the
relayer
at
the
very
moment,
while
it
is
created
in
the
very
same
block
so
for
repair
team
multi-sig.
B
That
would
be
the
same
case
right
if
you
delete
the
library
contract.
Well,
you
you
end
up
with
a
wallet
whose
funds
are
locked,
but
presumably
do
not
find
your
wallet
in
the
very
same
block
that
you're,
or
at
least
in
a
very
same
transaction
that
you're
for
a
while
it
was
created
so
yeah.
We
have
this
kind
of
of
use
cases,
so
it
offers
good
security,
it
offers
the
Simplicity
and
it
doesn't
break
too
many
contracts.
So
that's
why
we
picked
that
and.
A
I
think
those
are
very
good
reasons
to
have
this
proposal
being
selected
along
with
the
flexibility
of
enabling
self-destruct
back
if
somewhere
developers
feel
like
it
is
important
to
have
it
back.
Talking
about
that.
I
I
have
noticed
that
most
of
the
questions
on
Fellowship
of
ethereum
Edition,
which
is
a
discussion
to
link
to
this
proposal,
have
been
answered
and
I
saw
one
question
which
perhaps
maybe
in
a
day
or
two,
you
guys
will
answer
it
over
there.
A
It's
by
a
user
0x
draw,
and
that
is
about
the
consensus
for
using
Create,
two
or
self-destruct
pattern
in
future.
Going
forward
just
trying
just
trying
to
understand,
like
the
EAP
explicitly
states
that
self-destrap
is
discouraged,
but
there
are
definitely
benefits,
and
they
are
trying
to
understand.
Is
this
intended
as
a
transitional
EIP
or
it's
going
to
be
a
permanent
change
for
the
evm.
B
Right
so
it's
it
is
meant
to
be
permanent.
If
there's
a
good
reason
in
the
future.
Because
of
the
structure
of
local
tree,
we
could
go
the
extra
mile
and
produce
something
that
would
mimic
self-destruct,
but
we
still
have
this
problem
that
you
know
all
those
hacks
that
were
described
in
the
like
first
part
of
my
presentation
would
become
available
again
or
possible
again.
So
we
would
need
a
very
good
reason
to
to
do
this
and
yes,
I'm,
aware
of
who
at
least
I
think
I
know
who
asked
this
question.
B
A
All
right,
this
has
been
made
clear
to
the
community
that
people
should
not
be
using
self-destruct
and
in
my
memory
it
was
for
the
first
time
that
we
had
a
meta.
Eve
went
like
like
documented
ahead
of
this
upgrade
where
we
are
considering
to
have
this
feature
removed
and
like
formally
communicated
it
to
the
community
where
please
do
not
use
it
so
yeah,
as
Kiam
already
mentioned,
that
if
you
have
some
concerns,
tell
some
concern
please
reach
out
to
him
or
the
team
on
Fellowship
of
ethereum
magician,
hopefully,
you'll
be
helped
over
there.
A
All
right,
you
did
mention
about
client
implementation
and
testing.
It
looks
like
most
of
the
clients
have
already
implemented.
I'm,
not
sure
if
wreath
is
like
a
fully
functional
client
as
of
now
but
other
than
that
it
looks
like
all
other
clients
are
there
like
have
already
implemented.
So
we
have
heard
that
devnet
8
could
be
a
feature
complete
devnet.
That
means
it
would
include
all
the
five
plus
two
I
guess:
seven
eips
4010
upgrade
so
do
we
expect
this
to
see
with
devnet
eight.
B
B
A
No
worries
I
think
we
are
going
to
have
paritos
here,
sometimes
in
a
week
or
two
to
like
explain
about
all
about
devnets
and
the
progress
that
they
have
been
making,
how
they
are
putting
eips
and
what
are
the
reasons
why
some
of
the
eaps
were
not
considered.
So
we'll
try
to
get
an
answer
with
him
when
he
is
here
on
our
show.
Yeah
I'll
take
yours.
A
Oh
guys,
all
right
so
I
think.
That
concludes
all
my
question.
With
respect
to
EIP
and
its
specs
and
I'll
be
now
moving
into
the
process.
Part
of
it
I
know
this
is
not
your
first
EIP.
You
already
have
documented
a
few
proposals
in
the
beginning.
Maybe
if
you
can
tell
us
a
little
bit
about
your
expect
experience
a
documenting,
an
EIP
or
anything
in
specific
that
you
would
like
us
to
change
improve
what
you
think
is
redundant.
It
should
be
completely
out
of
the
process.
Yes,.
B
So
indeed,
I
I've
documented
some
eips,
my
I'm
trying
to
be
relevant
here,
but
it's
true
that
the
whole
EIP
slash
ERC
process
is
being
overhauled,
so
I
I'm,
not
following
it
day
to
day
so
yeah
it's
hard
to
be
relevant.
What
I
always
find
a
bit
difficult
is
that
there's
actually
a
lot
of
forums
to
follow?
There's
if
you're
a
magician
and
there's
eth
research,
I,
confess
I,
have
a
tendency
to
follow
his
research
and
always
forget
about
ethereum
magicians.
B
So
it
would
be
nice
if
someone
could
remind
me
to
to
get
there-
or
at
least
you
know,
if
EIP
editors
could
actually
point
out
to
discussion
and
say
Hey,
you
know
this
is
happening.
This
needs
your
attention.
That
would
be.
That
would
greatly
improve
the
experience.
Apart
from
that,
I
can
say
when
we
will
see
what
the
new
EIP
process
provides,
but
as
far
as
I
can
say,
it's
it's
just
creating
a
GitHub
request.
It's
about
responding
to
comments
so
that
that
is
very
well
streamlined.
I.
A
A
To
know
that
and
I'm
happy
to
share
here
a
piece
of
information
for
people
who
may
not
have
followed
it
so
closely.
Like
all
discussion,
we
have
tried
to
make
sure
that
all
of
these
discussions
should
be
on
Fellowship
of
ethereum
magician.
Ethereum
research
can
be
a
source
of
information
because
most
of
the
eips
are
stamped
from
there.
So
we
tend
to
add
that
as
a
source
of
information
and
that
too,
the
link
be
added
in
The
Fellowship
of
ethereum
magician.
B
A
Is
what
we
do?
We
try
to
share
information
and
I
hope
people
will
follow
along
just
one
more
piece
of
information
with
respect
to
process
here.
I
see
the
proposal
is
still
in
the
draft
status.
We
generally
recommend
people
to
move
the
proposal
when
they
think
that
that
is
ready
for
Community
as
well.
As
you
know,
EIP
editors,
to
have
a
proper
review
now
that
this
proposal
is
being
considered
for
Denco
upgrade
and
it
is
almost
close
to
a
devnet.
A
My
recommendation
would
be
to
create
a
small
PR,
just
a
status
change
movie
to
review
and
when
the
proposal
is
moved
to
the
public
test
net,
like
not
godly
I,
don't
know,
halski
will
be
around
by
that
time.
Whenever
on
any
of
the
public
test
net,
then
we
can
move
it
to
the
last
call
status.
That's
for
the
core
EIP!
So
we'll
really
appreciate
a
pull
request.
Changing
the
Status,
we'll.
B
A
That's
all
on
the
EIP
status
and
one
last
thing,
because
I
know
this
proposal.
Self-Destruct
has
been
under
discussion
for
a
very
long
time,
any
success
story
or
roadblocker
that
he
would
want
to
share
with
the
community
like
why
it
took
so
long.
And
what
were
the
precautions
that
you
were
trying
to
keep
in
mind
before
we
finalize
any
proposal
for
the
mainnet
upgrade.
B
Yeah
I
mean
the
reason.
Why
is
because
it's
a
bit
controversial,
there's
a
lot
of
people.
I
mean
okay,
we
don't
know
how
many
people
there
are.
We
just
analyzed
the
blockchain
and
we
we
figure
out
how
many
people
there
should
be
affected
by
this.
But
there's
there's
been
some
pushback
from
the
community.
It
makes
sense.
There's
also
some
proponents
that
really
want
to
to
seize
of
this
truck
disappear,
because
it
simplifies
I,
mean
most
I,
think
most
core
developers
and
agree
that
self-destruct
needs
to
go.
So
there's
been
some
back
and
forth.
B
There's
been
some
informal
conversations,
the
first
time
I
I
heard
this
could
be
a
problem
is
I
was
at
Defcon
I
just
made
my
presentation
about
Virgo
trees
and
someone
came
came
to
me
to
discuss
self-destruct
and
say
hey.
This
is
going
to
break
our
use
case
yeah.
We
we
wanted
to
be
cautious,
because
if
there's
a
lot
of
people
out
there,
if
it's
of,
if
using
Create,
two
and
self-destruct
together,
was
a
pattern
that
was
in
widespread
use.
B
Clearly,
we
didn't
want
to
to
break
anything,
or
at
least
we
wanted
to
make
sure
we're
going
to
mitigate
the
bad
effects.
So
there's
been
several
proposals.
They've
been
competing,
we're
trying
to
see
which
one
is
the
most
complex
to
implement,
which
one
is
the
is
the
best
so
yeah,
it's
normal
core
development
process.
A
That
is
true,
like
having
a
complete
analysis
of
anything
on
decentralized
ecosystem
can
be
sometimes
challenging
and
we
have
many
contributors
with
brilliant
ideas,
so
there
were
so
many
proposals,
glad
we
have
made
it
so
far
and
hopefully
we'll
have
it
on
the
minute
very
soon,
oh
well,
we
are
close
to
the
end
of
today's
episode.
Do
you
have
any
message
for
the
ethereum
community
keep.
A
That
is
one
of
the
best
messages
that
we
have
received.
I
mean
like
it's
very
important,
to
have
a
diversity
over
there
and
we
would
like
to
increase
the
percentage
of
solo
stakers,
as
we
have
been
talking
with
many
of
these
Elders
in
this
show
that
how
they
are
here
to
help
anyone
interested
in
staking
so
listen
to
all
our
developers.
Steak
from
home
become
a
solo
sticker.
Today.
A
Thank
you
for
joining
us
on
bibany
and
talking
about
one
of
the
most
important
and
anticipated
change
with
EIP
6780
from
the
announcement
meet
with
the
chapel
upgrade.
We
are
close
to
deploy
this
proposal
for
self-destruct
only
in
the
same
transaction
on
the
mainnet.
Today
we
look
forward
to
seeing
this
proposal
on
testnet
and
finally,
on
the
mainnet
with
tenkun.
A
On
this
note,
thank
you
to
all
our
YouTube
viewers
for
watching
and
podcast
subscriber
for
listening
to
this
special
episode.
Should
you
have
any
question
on
this
EIP
or
any
other
EIP?
Let
us
know
in
the
comment
below
check
out
description
for
more
information,
we'll
be
back
with
another
interesting
talk
until
next
time.
Keep
watching
keep
listening
and
keep
sharing
your
beloved
ethereum
cater.
This.
Thank
you
so
much.