►
Description
EIP: https://eips.ethereum.org/EIPS/eip-2938
Topics covered in this video:
1:29: Introduction
1:45: What is an Account Abstraction?
2:20: Implementation of the protocol.
4:25: What would happen if individual nodes in the network would not bother account abstraction transactions?
4:50: Mempool challenges & support.
8:55: Why can’t a node have an infinity transaction? Why is there a limit to mempool?
11:45: Is it really a resource issue for a miner to be able to find which is a valid transaction and what’s not?
13:22: Mempool challenge analogy.
15:47: How does a valid transaction turn into invalid? Why is that different from the AA than how it is today?
17:45: Double spend scenario.
21:15: Issue with Account Abstraction & solution.
25:40: About the EIP (where we left in Pt.1)
26:10: How can you identify a safe transaction?
31:35: Local state of a transaction?
33:10: How can you know an Account Abstraction contract can not be modified from outside?
37:50: Opt-in process.
38:25: What is SELF DESTRUCT? What does it do? Why do core devs don’t like it, generally?
44:20: How SELF DESTRUCT affect the upgradability pattern?
50:20: Security consideration
54:50: About security, DOS vector. If things go wrong, what would it look like? ABout bad nodes?
1:00:15: Roadmap
1:01:30: Readiness of EIP to move into the next status?
Discussion to: https://ethereum-magicians.org/t/eip-2718-typed-transaction-envelope/4355
Slides: https://tinyurl.com/peep-an-eip-2938
Peep an EIP-2938: Account Abstraction (Pt. 1) - https://youtu.be/HvZd6z2YdZs
Account Abstraction Community call - https://youtu.be/0hAIjLFe38Y
Follow at Twitter:
Sam Wilson @_SamWilsn_ | Ansgar Dietrichs @adietrichs | James Hancock @JHancock | Lightclient @lightclients | Pooja Ranjan @poojaranjan19 | Alita Moore @alitamoore85
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/sgdnxZe
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
another
episode
of
peep
any
an
eip
dedicated
series
where
we
discuss
an
ethereum
improvement
proposal
and
understand
why
that
is
important
for
ethereum
blockchain.
I'm
super
excited
to
welcome
today's
guest
sam
wilson
and
anskar
dietrich,
who
are
authors
for
eip2938
along
with
them.
We
are
joined
by
like
client,
alita
and
william.
A
So
for
those
who
are
new
to
the
show
or
this
proposal
we
are,
we
already
have
recorded
an
episode
episode,
12
on
account
abstraction,
with
a
wonderful
presentation
by
the
authors
that
you
are
going
to
see
in
this
meeting
as
well.
You
can
find
the
link
of
the
episode
on
the
card
on
your
screen
and
also
in
the
description
box.
B
Sounds
good,
hello,
everyone,
I'm
matsuka
and
yeah
is
sam
and
I
basically
are
here
today
to
to
present
basically
the
second
part
of
of
our
eip
walk
through
and
yes,
maybe
quick
intro
again.
We,
we
are
part
of
the
of
the
quilt
team
at
consensus,
doing
like
mainly
ethereum
protocol
research
there,
and
then
the
kind
of
restriction
was
one
of
the
main
things
we
did
in
2020.
B
So
here
we
are
and
then
yeah
for,
like
I,
I
think
I'll
mostly
skip
through
the
the
first
part,
of
course,
that
we
already
covered.
Basically,
I
mean
at
this
point,
if
you,
if
you
reach
this
point,
you
should
know
at
least
on
a
high
level,
what
a
kind
obstruction
is.
So
it's
the
idea
again,
it's
just
basically
abstract
away
the
validity
conditions.
Make
them
programmable,
basically
make
allow
for
contracts
to
to
send
transactions.
B
If
you
will
right-
and
we
had
all
these
nice
little
pictures
and
then
so,
basically
what
we,
I
think,
the
last
thing
we
covered
in
in
detail
on
the
last
call
that
that
is
the
actual
like
implementation
as
far
as
the
protocol
is
concerned.
So
so
basically
the
thing
to
to
maybe
reiterate
here
and
then
to
kick
things
off
with.
B
Is
this
kind
of
this
this
this
divide
again,
where
our
our
design
approach
with
with
a
kind
of
structure,
was
to
basically
keep
the
protocol
changes,
minimal
and
protocol
changes
again,
basically,
meaning
those
consensus
rules
that
that
that
govern
how
exactly
transactions
have
to
be
executed
right
right?
What
is
a
valid
block
and
what
isn't?
Basically?
So
so,
basically,
this
con,
this
very
critical
part
of
the
blockchain
that
that
basically,
every
single
change
really
requires
a
lot
of
attention.
B
We
wanted
to
keep
that
up,
that
one
very
small
and-
and
I
think
we
we-
we
went
through
the
erp
as
well
for
quite
years-
yes
dfp
by
the
way
we'll
we'll
switch
to
that
soon,
but
just
basically
to
kick
off.
They
have
their
presentation
on
the
site
as
well,
but
but
basically
we
went
through
the
through
this
specification
quite
a
bit,
so
so
the
main
thing
really
is
this
pay
gas
up
code
that
signals
if
a
contract?
B
If
a
contract
has
an
account
obstruction
transaction
start
at
the
contract,
then
it
can
call
pay
guess
to
signal.
I'm
willing
to
pay
for
the
transaction,
and
a
contract
has
to
do
that.
Otherwise,
an
account
obstruction
transaction
is
invalid.
Basically,
if
the
contract
decides
it
doesn't
want
to
pay,
then
then
it's
invalid,
but
basically
they
have
a
few
details,
of
course,
but
but
but
with
that,
basically
you
you
get
from
protocol
side,
you
already
get
card
abstraction,
basically
done
that
that
that's
it.
B
Basically,
it's
really
just
the
new
transaction
type
contracts,
consent
transaction-
that
that's
the
the
story
as
fast
as
the
protocol
is
concerned,
and
then-
and
I
think
on
the
last
call-
we
very
briefly
went
through
this
piece,
but
but
basically
just
like
we
could,
because
we're
running
out
of
time
just
a
little
bit
so
so
this
is
probably
the
best
point
to
kick
edge
to
take
it
back
back
up
is,
why
is,
is
the
story
not
just
over
here
right?
If
it
was
so
simple,
I
think
we
had.
B
We
would
have
had
a
construction
for
quite
a
while
now
already
on
ethereum,
but
it's
not
quite
as
simple
and
so
maybe
to
understand
that
it
makes
sense
to
very
briefly
think
about
like
what
would
happen
if
individual
nodes
in
the
network
were
just
basically
not
not
bothering
with
account
obstruction
transactions
right.
So,
usually,
what
nodes
do
in
the
ethereum
network
if
a
new
pending
transaction
is
sent
to
them?
B
They
look
at
it
if
it
looks
good,
they
just
broadcast
it
to
others
to
other
peers
and
they
keep
it
around
and
so
on
until
it
either
at
some
point,
makes
it
into
block
or
it
or
it
gets
dropped,
because
it's
two
to
two
to
basically
too
low
paying
or
something.
But
basically,
if
notes
were
to
not
do
that
at
all-
and
this
is
by
the
way
this
is
called
the
mempoo
right.
I
think
some
people
on
last
call
weren't
quite
fully
familiar
with
the
word.
B
So
memphis,
basically,
is
just
the
part
of
the
client
software
that
deals
with
pending
transactions.
So
what
if
basically
notes,
would
not
bother
with
account
obstruction,
pending
transactions
whatsoever
and
that,
if
that
was
the
case,
then
then
account
objection
would
be
perfectly
safe
right,
because
the
only
the
only
way
north
would
would
have
to
be
bothered
with
that,
basically
is
if
a
new
block
comes
in
and
for
some
reason
the
miner
would
have
decided
to
put
an
account
obstruction
transaction
in
it
right,
no
matter
how
they
got
to
that,
how
they
got
the
transaction.
B
But
let's
say
that
the
miner
just
either
created
it
themselves
or
on
some
side
channel
got
an
account
section
transaction
included
it,
and
it
would
be
no
issue
whatsoever
for,
though,
to
execute
it
right.
It's
the
exact
same
kind
of
rules
that
already
govern
other
kind
of
transactions
you
just
if
it
never
even
never
calls
pay
gas.
It's
an
invalid
block.
If
it
reaches
pegas,
then
it's
then
it's
basically
it
it's
valid
as
fast
as
first
that
that
is
concerned,
then
you
execute
the
transaction
as
normal.
B
You
apply
all
the
effects,
so
it's
basically
like
totally
normal
thing,
so
so
so
from
from
from
a
node
perspective,
validating
a
block
with
a
transaction
in
it
just
feels
very
normal.
So
so
there's
not
nothing
much
that
changes
the
the
thing
that's
tricky
about
account.
Obstruction
is
now
to
kind
of
basically
allow
this
kind
of
the
mempool
support
for
account,
objection
transactions,
so
of
course,
otherwise.
The
whole
thing
is
kind
of
pointless
right.
B
If,
if
the
network
doesn't
forward
a
construction
transactions,
it's
nice
that
we
have
the
support
in
the
protocol,
but,
like
you,
need
a
way
for
your
transaction
that
you
create
to
actually
reach
miners
and
everything.
So
so
we
really
need
this
man
food
support,
and
why
is
this
tricky?
Well,
this
is
what
what
this
nice
little
table
was
here
for,
and
I
think
we
walked
through
it
last
time
briefly.
B
So
so
the
idea
is
basically,
there
are
three
three
different
ways
in
which
processing,
pending
transactions
or
new
incoming
transactions
that
you
haven't
seen
before
can
be
tricky.
The
first
one
is
just
now
form
transactions,
so
let's
say
it
doesn't
even
write
it.
It's
not
even
like
it
doesn't
even
look
like
a
valid
transaction.
You
just
immediately
drop
it
that
for
normal
transactions
for
legacy
transactions
and
for
aaa
transactions
that
both
is
very
like
an
expensive,
that's,
not
an
issue,
but
then
it
gets
a
little
bit
more
tricky
with
invalid
transactions.
B
So
say
the
transaction
looks
it's
it's
well
formatted
and
everything,
but
it
turns
out.
The
signature
is
invalid
for
non-a
transactions.
You
can
check
that
in
very
short
time
right,
so
basically
an
ecds
intercheck.
That
is
very
quick
for
counter
protection.
It's
a
little
bit
more
tricky
because
you
actually
have
to
basically
run
the
transaction
until
the
contract
either
just
decides
it
doesn't
want
to
pay
and
just
stops
execution,
but
it
could
basically
there's
this
this
kind
of
validation,
gas
limit.
So
so
basically
a
contract
could
take.
B
I
don't
know,
let's
say
a
hundred
thousand
guys
before
it
decides
before
it
doesn't
decide
to
pay
for
the
transaction
right.
It
either
just
runs
out
of
gas
or
it
stops,
but
it
consumed
a
lot
of
gas
and
then,
of
course,
running
the
transaction
for
quite
a
while
before
it
reaches.
That
point
is
a
little
bit
more
expensive.
B
I
think
I
shared
with
you
the
last
time
we
had
this
dos
study
as
well.
That's
kind
of
the
that
we
had
a
study
where
we
we
looked
at
like
real
world
impact.
We
implemented
a
prototype
of
account
abstraction
we.
We
did
exactly
this.
We
basically
just
bombarded
nodes
with
a
lot
of
invalid
transactions,
just
looked
how
much
resources
were
consumed
and-
and
we
did
determine
that
it's
a
little
bit
higher
of
an
effort
for
nodes
than
normal
transactions,
but
it's
still
basically
all
within
limits.
So
this
is
not
this.
B
The
the
critical
part
either
but
you're
already
seeing
here's
the
yes
this
this
will
be.
This
will
be
where
where
the
problem
lies.
So
so,
what's
the
the
third
issue-
and
this
is
a
little
bit
tricky
because
that's
the
third
one-
is
something
that
just
doesn't
really
happen
in
in
normal
with
normal
transactions
with
the
legacy
transaction,
it
is
valid
transactions.
So,
like
you
see
a
transaction,
you
process
it,
it
looks
like
yep,
you
could
right
now
this
could
be
included
on
chain
and
then
you
again,
what
notes
do?
B
D
C
B
Execute
it
see.
Oh,
no,
it's
a
belt
anymore
discard
it
go
through
the
next
one,
so
it
would
take
a
lot
of
time
before
they
can
actually
start
before.
They
actually
have
a
valid
block.
They
can
start
mining
on
top
of.
So
it
is
really
important
that
you
have
like
a
good
way
of
keeping
your
mempool
sanitized
with
only
valid
transactions
and
then
in
general,
why
don't
you
want
an
infinite
amount
of
valid
transactions?
Even
that's
really
just
like
a
resource
thing.
So
you
just
basically
want
to
not
key
you.
B
You
don't
have
infinite
a
memory.
You
don't
have
infinite
disk
space,
so
this
is
why
no
it's
usually
right
now,
I
think,
get
keeps
around
like.
Is
it
six
thousand?
I
think
it's
like
yeah,
something
off
that's
another
order
with
the
default
settings.
You
can
of
course
change
that,
but
something
like
six
thousand
dollar
transactions
at
any
time.
E
E
B
That
is
just
like
a
revenue
loss,
because
that
just
decreases
your
probability
of
discovering
the
next
block,
whereas
for
for
front
running
bots
that
that
that's
really
just
like
everyone
has
to
basically
contend
with
the
same
same
problems,
there's
no
way
to
basically
figure
out
if
a
transaction
is
front
runnable
or
not
before
you
actually
looked
at
it.
So
so
this
is
just
like
a
price
everything
to
do.
I.
E
Wasn't
I
wasn't
talking
about
stopping
the
front
running
bots?
I
was
just
saying
that
if
a
front
running
bot
itself
is
able
to
process
all
of
the
transactions
in
the
mempool
to
discover
transactions,
which
should
be
replayed
in
front
run,
that
means
that
they
do
have
the
capacity
and
the
resources
to
keep
up
with
high
volume
and
to
process
transactions
very
fast
in
order
to
find
profitable
transactions,
let
alone.
E
D
So
that's
not
exactly
true,
so
if
a
front-running
bot
falls
behind
for
a
little
while,
that's
perfectly
fine,
they
just
catch
up
and
and
start
front
running
you
know
more
later
on,
but
for
a
miner
they
would
lose.
Well,
I
mean
a
front.
Runner
would
also
lose
that
on
revenue,
but
like
it's
the
same
kind
of
problem,
if
you
can't
keep
up
consistently
as
a
miner,
you
lose
a
lot
more
more
value.
I
think.
B
Also,
I
think
I
think
this
might
be
a
slight
slight
kind
of
inaccurate,
like
the
difference
here.
That's
easy
to
overlook
a
front
runner
like
processes,
every
transaction
once
so
like
a
new
transaction
comes
in.
They
didn't
see
it
yet,
but
they
look
at
it
once
and
check.
Is
it
front
runnable
and
if
yes,
they
do
some
special
thing
with
it,
but
for
99
percent
of
transaction.
The
answer
is
no
and
they
just
never
look
at
it
again.
C
Or
your
node
has
too
many,
maybe
could
I
offer
an
analogy
that
I
think
might
be
helpful
sure
like
if
every
node
is
getting
envelopes
of
transactions,
like
imagine
that
they're
getting
an
envelope
and
the
first
thing
they
do
is
they
have
to
open
the
envelope
and
read
like?
Is
this
transaction
good
or
is
it
like?
Will
this
work
or
will
it
not
work
and
if
they
can
quickly
sort
these
envelopes
into?
I
can
ignore
you,
I
can
hold
on
to
you
and
then
they
stay
green
light
or
red
light.
C
Then
that's
kind
of
what
the
network
does
today
and
if
a
node
can
only
handle
so
many
envelopes
at
once,
and
if
it
has
to
go
back
to
recheck
an
envelope.
If
there's
like
this
gray
area,
then
it
get.
It
adds
like
more
going
out
like
the
second
pass
of
checking
the
envelopes
or
checking
the
transactions
can
is
where,
like
the
well,
we
don't
know
what's
going
to
happen
so
when
like
in
usually
when
we
get
to
this
point
in
the
core
devs
discussion,
it's
this.
C
If
you're
doing
one
pass
for
everything-
and
you
know-
and
this
this
is
kind
of
deterministic
at
the
end,
everybody
knows
that
all
these
transactions
are
going
to
be
green
and
all
these
ones
are
red.
So
we
can
ignore
those,
but
now
we're
kind
of
introducing
these-
these
ones
may
be
green
later
or
maybe
red
later,
but
we
don't
know
and
people
get
worried.
Well,
we
don't
know
what
to
do
about
it.
C
B
I
think
this
is
really
helpful
like
this
is
a
great
analogy,
and
so
so
basically
the
second
row
here
is
kind
of
giving
you
a
like
a
limitation
of
how
many
envelopes
can
you
open
per?
Second,
that's
that's
a
great
great,
great
way
of
visualizing
it.
So
this
is
like
for
new
incoming
things
and
then
the
the
last
one
is
about
knowing
like.
First
of
all,
of
course,
you
immediately
drop
all
all
the
red
envelopes.
B
D
It
is
today
sure
so
that's
actually
kind
of
what
I
was
going
to
get
into
so
right
now.
Valid
transactions
can
turn
invalid,
but
in
very
well
known
and
specific
ways.
So
the
two
that
I
that
I'm
most
aware
of-
and
I
think
they're
the
only
two
but
correct
me
if
I'm
wrong-
are
when
the
accounts
not
changes
or
when
the
accounts
balance
drops
below
the
value
sent
in
the
transaction,
and
those
are
the
only
ways
that
current
currently
transactions
can
become
invalid
or
the
envelope
can
go
red
with
aaa.
D
There's,
basically
an
arbitrary
way
that
the
envelope
can
go
red
that
the
transaction
can
become
invalid
and
that's
according
to
the
contract,
and
we
need
to
make
sure
that
that
those
arbitrary
ways
are
limited
to
predictable
kind
of
ways.
And
that's
what
we're
going
to
talk
about
in
a
bit.
I
think.
B
So
the
only
way
you
can
invalidate
the
transaction
right
now
is,
if
you
send
a
different
another
transaction
from
the
same
account
like
you,
can't
invalidate
a
transaction
from
the
outside.
It
has
to
be
the
same
account
that
sends
a
different
transaction,
and
then
yours
can
become
invalid,
that
you
keep
locally
from
the
same
account.
This
is
like
the
only
circumstance.
B
So,
basically,
every
time
a
new
book
comes
in,
you
basically
only
look
at
the
accounts
that
send
transactions
in
the
block,
and
then
you
go
back
to
your
like
huge
pile
of
envelopes
and
you
you've
sorted
them
by
account
and
you
just
you
only
go
to
the
three
or
like
to
the
50
piles
or
whatever
that
that
that
header
had
one
of
their
transactions
included
in
a
block
and
only
for
those
small
little
sub
piles
that
usually
consist
of
like
one
to
ten
transactions
or
something.
Maybe
you
have
to
recheck
the
validity
right.
B
G
Yes,
I
got
question
so
it
seems
like
to
me
this
all
gets
down
to
the
double
spin
problem.
So
let's
say
if
a
corporation
has
an
account
and
there's
a
person
in
the
western
hemisphere,
with
the
keys
for
that
and
a
person
in
the
eastern
hemisphere.
That
has
the
keys
for
that
and
they
accidentally
double
spend
some
money
and
they
both
send
a
transaction
in
and
they
both
go
into
the
mempool
and
when
they
first
both
go
to
the
mempool
they're
valid
right.
G
But
then
the
first
one,
let's
say
the
first
one
gets
included
in
block
in
and
so
when
it
in
gets
included
in
block
n
that
one's
valid.
But
then
the
other
one
still
in
the
mempool
that
didn't
get
included
goes
invalid.
And
so
is
it
possible
for
that
block
in
and
when
n
plus
one
goes
on.
Is
it
possible
between
those
two
blocks
for
something
to
go
invalid.
G
In
other
words,
you
don't
want
to
double,
spend
any
ether
and
for
block
in.
If
something
has
been
spent
before
block
in
then
then
it
becomes
a
double
spin,
and
so
that
becomes
invalid.
But
if
something
went
in
and
block
that
spent
some
ether
and
you've
still
got
something
in
mempool.
That's
gonna
double
spend
that
ether
that
they
both
accidentally
got
in.
You
don't
want
that
to
go
and
block
block
n
plus
one
because
it
already
got
in
and
block
n,
and
so
you
don't
want
to
in.
In
other
words,
my
quest.
G
It
seems
like
to
me
that
nothing
could
me,
in
other
words,
you
can't
double
spend
that
east,
in
other
words,
if
you're
gonna,
you've
already
got
block
in,
and
you
know
all
of
the
where
all
of
the
ether
is
at
block
in
and
you
can
tell
that
there's
nothing
in
your
mem,
current
mempool
and
or
in
other
words
you're,
not
putting
anything
in
n,
plus
one
when
you're
a
minor,
and
so
you
know
that
there's
no
double
spending,
and
so
it's
valid.
And
so
my
question
is:
can
something
go
valid
between?
B
That's
a
good
question
and
the
answer
is
it's
very
simple
there,
and
the
answer
is
no,
so
so
you're
completely
right
with
the
analysis,
like
I
don't
think
double
spend,
is
the
only
scenario
in
which
kind
of
transactions
that
you
keep
locally.
I
mean
another
word
for
double
spend.
It
could
also
be
replacement
transaction
replacement.
It's
only
only.
B
Yeah
yeah,
so
basically
just
exactly
or
you
could
even
have
some
like
a
transaction.
You
you
sent
transactions
with
nonsense,
one
and
two,
and
then
you
kind
of
send
a
competing
transaction
with
nuns
one.
Then,
then
that
could
involve
both
other
ones
or
something,
but
but
but
again,
yeah,
but
but
you're
completely
right,
and
that,
once
you
have
processed
block
n,
there's
nothing
that
can
happen
before
block
n
plus
one
comes
around
that
changes.
B
That
that
that's
good
but
but
the
this,
of
course,
that's
important
that
also
doesn't
change
with
account
abstraction,
so
basically
the
ground
truth
of
the
blockchain
only
changes
in
the
block
interval.
So
so,
every
time
a
new
block
comes
in
the
the
state
of
the
change
changes,
but
then
between
blocks
it
stays
constant.
So
any
assumptions
you
have
after
processing
a
block
remain
true
until
the
next
block
comes
in
and
so
basically
in
regarding
your
mempool
management.
B
Basically,
this
interval
of
a
new
block
comes
in
this.
This
event,
that's
the
one
that
triggers
the
important
reorganization,
usually
okay,
but
then-
and
I
just
want
to
basically
reiterate
before
we
can
go
to
the
solution-
that
we
kind
of
understand
the
issue
with
account
abstraction
here
and
because
that's
what
sam
pointed
out,
but
it's
really
important
account
abstraction
means
any
contract
can
basically
send
a
transaction,
so
they
can
basically
use
any
arbitrary
computation
and
then
call
pages
or
not
call
pages.
B
B
You
just
don't.
You'd,
have
to
really
go
back
and
rebuild
like
re-look
or
re-execute.
All
of
all
of
your
account
obstruction
transactions
in
memphis
at
that
at
that
point,
if
you,
if
you
do
it
like
naively-
and
this
is
basically
just
oh-
and
this
is
basically
just
like
a
long
way
of
saying-
this
is
not
something
you
can
do
you
can't
just
if
you
want
to
have
like
a
functioning
node,
you
can't
just
keep
every
single
account
obstruction
transaction
that
looks
valid
in
your
manpool.
B
So
so
what
can
you
do
about
it?
Well,
I
think
the
so
so.
Basically,
the
idea
is
really
simple.
We
already
talked
about.
If
you
were
to
just
ignore
account
obstruction
at
all,
then
you
wouldn't
have
an
issue.
It's
really
just
about
that.
You're.
Accepting
all
account
of
section
transactions
in
your
mantle
well
solution
is
simple.
You
don't
allow
all
account
obstruction
transactions
in
your
mempool.
You
basically
have
like
very
strict
rules
that
that
tell
you,
if
a
transaction,
if
an
account
obstruction
transaction
is
safe.
B
So,
basically,
if
it
has
predictable
behavior,
and
only
in
that
case,
do
you
keep
them,
so
you
basically
only
keep
a
subset
of
safe
account
abstraction
transactions.
This
is
this
is
basically
the
main
idea
behind
behind
our
mempool
rules
approach
here.
So
it's
like,
like
all
kinds
of
account
observation
transactions
would
theoretically
be
valid,
but
your
notes
just
only
keep
those
that
they
can.
They
can
understand
basically,
and
the
idea
is
we.
D
B
Exactly
so,
it's
still
basically
on
the
protocol
side,
nothing
changed
and
miners
could
still,
for
example,
if
they
have
some
way
of
being
paid
on
the
side
like
people
could
pay
the
money
to
also
process
weird
conversation
transactions,
but
because
they
are
paid
on
the
side,
they
don't
care,
because
if
it
turns
out
it
wasn't
valid
well,
they
got
the
money
anyway
right.
So
so,
basically,
miners
could
still
do
whatever,
but
the
network
as
a
whole
would
basically
only
fall
back
to
the
subset
of
safe
account,
obstruction
transactions
and
then,
basically,
our
challenge
becomes.
B
How
can
we
identify
safe
transactions?
And
the
approach
is
kind
of
I
think
intuitive
in
that
we
start
out
with
like
a
very
restrictive
set
of
rules
where
we
are
like.
We
only
allow
those
that
are
like,
obviously,
extremely
safe,
and
we
we
have
to
first,
of
course
define
what
does
it
mean
right,
but
we
only
we
start
out
with
very
restrictive
rules,
and
we
are
very
certain
that
those
those
are
simple
to
implement
and
those
work
and
those
only
keep
around
transactions
that
are
safe
and
then
from
there.
B
First
briefly,
it
will
be
brief,
because
it's
simple
it's
a
it's.
A
very
small
set
of
rules
briefly
talk
about
these
simple
rules
and
then
talk
about
these
extensions
if
that
makes
sense
yeah.
So
basically,
I'm
not
even
sure
we
have
like
further
slides,
or,
I
think,
yeah
that
we
already
covered
this
rather
transactions
involved.
I
think
that's
doesn't
really
matter.
Okay,
sorry,.
A
B
Awesome,
so
I
think
now
now
is
the
time
to
kind
of
turn
to
the
to
the
eip,
because
again
this
with
the
sites
were
like
more
like
for
background,
I
think
for
people
if
it
actually
makes
sense
to
actually
peep
to
eat,
and-
and
so
here
we
are
so
I
think
basically
last
time
we
we
actually
got
to
to
to
to
this
part
so
so
like
basically
to
the
end
of
this
part.
This
is
this
is
like
the
protocol
rule.
B
B
But
but
the
idea
is,
that
is
simple.
So
so,
if
you
remember,
we
were
just
talking
about.
When
do
normal
transactions
become
invalid
and
the
point
was
they
can
only
become
invalid
when
they
once
they
were
valid
in
the
first
place,
if
the
same
account
sends
a
different
transaction,
so
the
same
account
has
to
send
a
different
transaction.
Then
then,
other
pending
transactions
from
the
account
could
could
turn
invalid
could
turn
red
and
the
first.
So
so
our
first
approach
is
just:
can
we
just
kind
of
recreate
the
same,
like
security
assumptions?
B
Could
the
same
invariant
for
account
abstraction
transactions?
Can
we
make
it
such
that
only
other
account
obstruction?
Transactions
from
the
same
contract
can
invalidate
other
pending
ones,
because
if
we,
if
we
can
then
well
hooray,
then
we
basically
memphis
can
do
the
same
thing.
They
already
do
today.
It's
where
right,
basically,
they
don't
have
to
go
through
all
of
them.
They
know
which
ones
critically
could
have
turned
red,
and
so
how
can
we
do
that?
How
can
we
basically
so
there
are
two
aspects
of
it.
First,
that's.
B
Yeah,
it's
it's
actually
like
it's
it's
interesting,
because
it's
like
a
funny
story.
How
initially
we
we
we
started
out
with
with
the
kind
of
restriction
with
like
a
vitalik's
proposal
from
like
I
think
march,
or
so
he
just
had
a
write-up
on
on.
I
think
on
the
eighth
magicians
or
something
yeah.
He
just
said
he
is
here's
a
set
of
minimal
rules.
He
could
just
go
ahead
and
implement
it
or
something,
and
that
already
had
all
these
ideas
in
this.
B
Basically,
I
mean
we
just
went
ahead
and
implemented
it
and
then,
very
briefly,
before
we
were
ready
to
publish
the
ap,
we
kind
of
got
back
together
with
vitalik
and
got
his
feedback
and
everything,
and
I
think
he
was
the
main
person
who
actually
like
looked
at
it
and
was
saying
like
wait.
A
second
do
we
need
all
these
rules
in
the
protocol,
can't
we
just
pull
them
out
and
have
them
as
like
restrictions
in
the
in
the
mempool,
so
yeah
all
credits
to
him.
For
that
specific.
For
that,
like
twist,
I
think.
C
B
Yeah
yeah,
that's
exactly
it
yeah
yeah,
exactly
so
like.
Instead
of
being
this
weird
new
dangerous
thing,
just
like
think
of
it
as
no
just
normal,
like
you
already
know
it
yeah
yeah,
exactly
and
even
more
restrictive
by
the
way,
the
first,
the
basic
version
of
the
construction
has
the
additional
restriction
that
it
says:
don't
keep
multiple
transactions
per
contract
only
keep
one.
B
This
is
this
makes
reasoning
even
simpler
because
you
have
to
kind
of
don't
have
to
deal
with
like
sequential
answers
and
everything
just
just
keep
one
right
per
contract
only
keep
one
transaction,
and
this
is
why
one
of
the
extensions
is
then
called
multiple
pending
transactions
because
yeah,
that's
that's
what
it
will
do
then,
but
but
okay,
so
so
how
can
we
make
sure
only
your
own
like
if
you're
a
contract,
basically
imagine
you're
a
contract?
How
can
you
make
sure
only
your
own
transactions
can
invalidate
other
ones
from
from
from
yourself
right?
How?
B
How
can
you
get
to
this
point?
And
it's
actually
two
things
so
so
first
off
is,
and
that's
the
the
obvious
one
I
think
is
just
don't
allow
the
transaction
like
the
transaction
to
access
external
state
so
state
outside
of
your
own
contract
before
it
makes
the
decision
if
it
wants
to
pay
for
the
transaction
right.
So
so,
basically,
what
does
do
what?
B
What
does
it
mean
to
not
allow
that,
of
course,
on
the
protocol
level,
it's
still
allowed,
because
again,
any
kind
of
account
of
certain
transaction
is
valid,
but
in
your
mempool,
if
a
new
new
transaction
comes
in,
it's
an
account
account
abstraction
transaction.
You
verify
if
it
if
it's
even
valid,
if
the
contract
is
willing
to
pay
for
it,
you
execute
it
well
as
soon
as
during
this
validation
before
it
decided
to
pay
as
soon
as
it
kind
of
wants
to
access
external
state.
B
You
just
look
at
it
and
say:
oh,
it's
not
safe
I'll
drop
it.
I
don't
care.
If
it
is
valid
or
not
it's
not
safe,
it
doesn't
look
safe,
I'm
immediately
dropping
it.
This
is
basically
the
whole
rule
here,
and
this
is
what
most
of
the
section
is
about.
So
this
is
like
we
went
through
all
of
the
op
codes
that,
like
can
be
used
to
access
external
state
outside
of
your
own
contract,
and
the
idea
is
just
if
the
execution
hits
any
of
the
following
exit
with
failure.
B
This
this
is
it,
and
this
is
again
only
for
execution
during
validation.
So
if
you
process
a
block,
everything
is
allowed
right
for
transactions
in
it.
But
if
you
locally
see
a
pending
transaction,
you
execute
it.
It
does
any
of
these
things
that
access
external
state,
the
kind
of
the
book
cash
the
time
stamp.
The
right
all
of
these
things
wants
to
call
some
external
contract
even
even
like
set.
It
called
delegate
call
all
these
things.
It's
just
all
not
allowed
right.
You
just
drop
the
transaction.
B
You
just
don't
care
about
transaction
anymore,
and
this
could
this
basically
gets
us
halfway.
So
what
the
invariant
that
that
enforces?
Is
your
transaction,
like
the
only
state
that
you
have
to
be
careful
about?
Is
the
local
state
of
the
contract,
because
other
state
is
just
not
relevant
for
the
decision
to
pay
anymore,
but
there's
still
there's
still
an
issue.
B
What
about
the
local
state
well
for
for
normal
con
for
normal
accounts
right
there
for
normal
transactions
with
normal
accounts,
the
only
local
state
basically
is
the
balance
and
the
nons
as
we
were
talking
about
and
that
can't
be.
They
can't
be
changed
from
the
outside.
Well,
the
balance
can
be
changed
from
the
outside,
but
only
in
one
direction
that
basically,
it
can
only
be
increased
from
the
outside
by
other,
like
transactions
into
your
account,
but
increasing
balance.
It
can't
ever
invalidate
a
transaction.
So
so
this
is
safe.
B
There's
only
one
way:
look
for
external
state
access
to
your
account
and
that's
safe
for
contracts.
Of
course,
that's
just
not
the
case
right
contracts.
Anyone
can
call
into
a
contract
and
call
any
function
in
the
contract
and,
of
course,
depending
on
how
it's
implemented,
but
but
the
contract
could
do
whatever
state
modifications.
So
let's
say
you
have
like
a.
B
I
want
to
pay
boolean
in
your
contract
and
that's
true,
and
only
if
it's
true
you're
willing
to
pay
for
transactions,
but
then
someone
else
calls
a
please
disable
payment
function
from
the
outside,
with
the
diff
within
a
transaction
and
then
that
just
disables,
this
boolean
and
then
all
of
a
sudden,
all
the
pending
transactions
become
invalid
right.
So
so
this
is
also
an
issue.
It's
not
only
about
you
yourself,
not
accessing
external
state.
B
It's
also
about
like
the
external
work,
not
accessing
your
state
or
not
at
least
not
writing
to
your
state
and
now
this
is.
This
is
kind
of
a
little
bit
more
tricky,
and
this
is
one
more
of
these
kind
of
interesting
ideas.
I
think
how
can
we
prevent
that?
Because
we
are
just
like
a
single,
simple
node
in
the
network.
We
can't
enforce
what
kind
of
things
other
transactions
do
right
if
a
new
block
comes
in
and
that
writes
to
the
state
of
the
contract.
We
have
no
choice.
B
We
have
to
execute
it
right
if
it's
a
block,
it's
a
valid
block.
So
how
can
you
kind
of?
How
can
you
look
at
an
account
obstruction,
contract
and
know
that
it
can't
be
modified
from
the
outside,
and
this
is
this
is
the
key
here
we
just
add
another
very
restrictive
rule
and
then
another
very
restrictive
rule
is
just
we
define
this
bytecode
prefix
and
we
only
accept
transaction
to
contracts
that
start
with
this
prefix.
B
So
only
if,
like
an
account,
protection
transactions
comes
and,
and
it
it's,
it
starts
at
a
contract
that
starts
with
this.
This
is,
of
course,
the
solidity
equivalent,
but
but
like
the
the
bytecode,
whatever
the
exact
bytecode
is
only
if
it
starts
with
this
exact
bytecode.
Do
you
keep
it
and
why
this
exact
bytecode?
Well
this?
This
is
a
little
bit
tricky.
Of
course
I
mean
the
earpiece
usually
are
written
for
conciseness,
not
for
for
understanding
for
like
ease
of
of
understanding,
but
basically
this.
This
is
just
a
very
weird
way
of
recreating.
B
B
If
the
current
transaction
is
basically
an
account
obstruction
transaction
that
just
started
right,
so
basically
only
if,
if
you
ju,
you
you're
like
within
the
very
first
step
of
the
execution
of
an
account
obstruction
transaction.
Only
then
are
you
in
this
case,
so
any
external
call
into
your
account.
This
would
always
be
false,
because
message.sender
would
always
be
the
one
calling
into
you.
So
this
this
check
basically
can
never
be
passed
with
external
calls.
B
So
if,
if
during
external
transaction
execution,
you
want
to
call
into
the
contract,
this
will
always
be
false,
and
so
basically
oh
no.
Of
course,
this
is
obviously
true.
I
I
forgot
about
the
not
equals,
so
basically,
this
will
always
be
true
for
external
calls,
and
so,
if
this
is
true,
then
you
basically
immediately
return.
You
don't
allow
any
state
modification.
The
only
thing
you
allow
like,
if
you
want
to
send,
send
the
contract
some
ether
you
you
are
allowed
to
create
a
lock.
That
basically
just
says
I
received
some
ether.
That's
fine!
B
It's
like.
I
can
signal
that
I
self-impose
this
restriction
on
myself
like
on
on
on
my
contract,
and
only
if
you
did
that
to
yourself.
Basically
only
then
do
I
keep
transactions
for
you
around,
and
so
this
is
basically
this
gets
us
to
this
to
this
goal
of,
like
now
being
equal
to
or
like
equivalent
to
two
legacy
transactions,
because
so
so
what
does
it
give
us
together?
So
so
you
don't
allow
external
state
access,
but
you
also
don't
allow
external
state
to
access
you
well.
B
That
just
means
that
you're
basically
be
like
for
at
least
for
the
purpose
of
your
payment
decision.
You're
just
living
inside
your
own
bubble.
No
one
can
touch
you.
You
can't
touch
anything
outside,
so
it's
like
as
long
as
there's
no
transaction
from
your
contract.
You
know
that
the
state
relevant
for
the
payment
decision
does
not
change,
and
if
the
state
doesn't
change
and
the
execution
rules,
don't
change,
then
of
course
the
result
of
the
of
the
payment
decision
will
always
be
the
same.
So
you
see
a
transaction,
you
keep
it
a
mempool.
B
G
So
so
it
sounds
to
me
like
you're
extending
the
n,
once
you
have
block
in
nothing
else,
can
invalidate
what
you
yourself
are
gonna,
as
a
minor
are
gonna
put
in
n,
plus
one
and
you're
just
ex
sending
that
same
rule
to
the
abstract
layer.
So
you're
can
still
say.
No
one
can
invalidate
the
abstract
thing
that
I'm
doing
it's
a
is
that
right.
B
Yeah
I
I
think
that
sounds
right.
Of
course,
of
course,
I
was
a
little
bit
and
I'm
not
fully
sure
with
this,
like
kind
of
this
abstract
layer,
the
way
you
you're
phrasing
that,
but
I
think
I
think
at
least
if
I,
if
I
understand
your
your
your
intention
there
correctly,
then
then
I
would
agree.
Yes
that
that
sounds
sounds
about
right.
B
That
is
like
a
perfect
summary
and
there's
there's
one
more
little
little
wrinkle
about
they
can
lie
about
it.
You
actually
have
to
kind
of
make
sure
they
can't
self-destruct,
because
otherwise
you
could.
They
could
basically
recreate
the
same
contract
with
different
rules,
and
so
they
could
actually
lie.
So
this
is
one
little
as
risk
that
that
you
have
to
keep
in
mind,
but
but
besides.
F
B
That's
a
great
question
actually
and
so
you're
completely
right,
all
core
devs,
don't
don't
don't
tend
to
like
set
indestructible.
It's
one
of
these
features
that
at
some
point
was
added
and
then
now
it's
like
well
we're
stuck
with
it
because
a
lot
of
contracts
kind
of
use
it,
and
so
you
can't
just
remove
it
again,
or
at
least
I
mean
the
people
they're
people
that
just
want
to
completely
just
disallow
the
op,
but
but
this
is
of
course
a
little
bit
extreme.
So
so
what
does
it
do?
B
So,
it's
very
simple.
So
basically,
a
contract
can
just
write.
All
it
does
is
just
execute
bytecode,
and
so
it
just
executes
it
like
a
sequence
of
op
codes
and
there's
this
one
up
code
that
just
is
called
self-destruct,
and
so,
if
you
call
this
up
code,
then
basically
what
happens
is
your
your
contract
is
immediately
destroyed.
So
basically,
all
all
the
storages
is
deleted
or
all
the
code
is
deleted.
The
nonce
is
reset
and
all
the
balance
that
might
be
remaining
is
sent
to
some
some
recipient
address
that
you
specify
without
code.
B
So
it's
like
just
basically
destroy
this
contract.
This
is
what
it
does,
and
that
kind
of
has
a
lot
of
just
it
creates
a
lot
of
issue.
So
the
idea
was
you
want
to
allow
people
to
to
kind
of
do
a
little
bit
of
housekeeping
right,
because
the
state
of
ethereum
grows
all
the
time
and
sometimes
maybe
contracts
aren't
like
used
anymore.
So
maybe
you
could
implement
this
functionality
to
just
basically
clean
up
after
after
you
don't
need
a
contract
anymore,
but
it
created
like
a
lot
of
issues.
B
For
example
this,
if
you
remember
the
parity
wallet
thingy,
where
they
just
had
stuck
funds
like
a
lot
of
slug
funds,
I
think
back
at
the
time
it
was
like
100
million
dollars
of
ether.
That
was
just
unrecoverable
we
lost,
but
because
they
actually
overlooked
some
functionality
that
led
into
a
self-destruct,
and
so
someone
self-destructed
a
very
important
piece
of
code
that
every
single
wallet
was
using,
and
so
basically
yeah
that
was
yeah.
B
It
was
gone
right,
so
yeah
self-destruct
just
creates
a
lot
of
issues
and
again
with
the
kind
of
abstraction
you
just
want
to
make
sure.
If
a
contract
looks
a
certain
way,
you
just
understand
it.
It
won't
change,
and
so
we
try
to
be
minimally
invasive
in
in
in
our
work
around
so
so
we
proposed
two
different
work.
Arounds
the
first
one
was
just
would
just
be
modify
self-destruct
very
slightly
so
that
it
doesn't,
it
doesn't
change
the
the
nonce,
and
so
why
is
it
sufficient?
B
Because
the
code
could
still
be
swapped
well,
at
least
right
right.
I
I
was,
I
was
being
a
little
bit
kind
of
brought
in
in
my
statement
in
that,
like
self-destruct,
is
an
issue
with
account
obstruction
because
of
course,
self-destruct
can
also
only
be
triggered
from
the
inside.
If
you
just,
if
you
have
this,
this
prefix,
then
from
the
outside,
no
one
can
get
in
and
execute
code,
and
so
it
can
only
be
triggered
from
the
inside,
but
we
already
were
saying
transactions
from
the
inside.
That's
okay!
B
If
they
invalidate
things,
because
that
was
the
one
thing
that
is
allowed
to
invalidate
things.
So
the
the
main
issue
with
self-restraint
then
was
that
you
can
also
like
kind
of
reset
the
nons
and
then
all
of
a
sudden.
You
can
basically
recreate
transactions
with
the
same
nons
and
that
they
had
to
have
different
behavior.
So
so
like
it,
it
invalidates
like
transactional
uniqueness
and
it
just
creates
a
lot
of
huge
mess.
B
So
so
the
minimally
invasive
thing
would
just
be
kind
of
prevent,
prevent
receptor
structure
from
from
resetting
the
nons,
but
but
the
cleaner
way
and
the
one
that
actually
also
gives
us
a
lot
of
added
benefits,
and
I
already
heard
from
a
lot
of
teams
that
actually
are
interested
in
this
and
this
functionality
just
independent
from
account
obstruction.
That's
this
set
indestructible
up
code,
so
this
would
be.
B
It's
like,
if
you
basically
oh,
it
doesn't
even
have
to
be
at
the
very
beginning,
but
but
that's
where
you
kind
of
look
for
the
op
code
but
like
if
the
opcode
is
called
and
then
afterwards
you
call
self-destruct.
Well,
then
nothing
happens.
That's
the
whole
purpose
of
the
that's!
Basically,
you
you're
just
it's
another
way
of
these
self-commitments
right
use.
B
Health
commit
to
never
use
a
self-destruct,
basically
that
that's
what
the
opcode
does,
and
so,
if
you
just
put
that
we
would
basically
just
modify
the
the
prefix
that
it
the
very
first
thing
it
does.
Is
this
set
instructable
and
then
after
it
does
the
rest
here,
and
so
that
way
you
just
know
it's
going
to
always
look
the
same.
F
B
Exactly
this
so
well
it
it.
Doesn't
it
basically
the
moment
that
that
it
does
call
this
opcode,
because
you
can't
kind
of
change
that
you
run
into
the
opcode,
but
the
moment
you
would
call
the
opcode
after
you're
it
like
the
the
self-destruct
upgrade
after
you're
ready
called
set
indestructible.
The
transaction
would
just
fail.
It
would
not
in
fact
destroy
the
contract.
It
would
instead
just
fail,
because
you
did
something
that
you
were
not
supposed
to
do,
which
is
fine,
which
is
then
your
own
fault.
C
B
E
B
So
it's
still
executed
against
your
local
state
and
everything.
So
it's
not.
Actually
it
doesn't
actually
like
go
to
the
other
contract
and
execute
there.
It
only
takes
the
code
from
the
other
contract
and
still
execute
executes
at
your
local
place.
Basically,
and
so
this
is
the
main.
This
is
the
main
thing
that
that
is
like
kind
of
used
for
upgradability
for
like
these
these
patterns,
and
this
is
basically
right
now,
with
the
with
these
very
restrictive
rules.
B
It
would
not
be
possible
to
call
this-
I
mean
actually
I'm
pointing
at
it
right
now
in
the
list
of
of
like
disabled
or
like
like
prohibited
up
codes,
you
would
not
be
allowed
to
call
this
before
pay
gas.
So
so,
if
you
want
to
have
like
logic
to
decide,
if
you
want
to
pay
or
not,
that
is
upgradable,
you
can't
actually
do
that.
Because
again
the
issue
is,
you
would
call
you.
B
You
could
basically
call
into
some
some
some
address
and
then
the
the
address
could
could
just
change
right
with
the
self-destruct
and
so
on.
So
so,
basically
like
if
you,
if
you
had
that
allowed
this
and
and
then
and
the
target
location,
would
change
state
from
from
one
code
to
a
different
code
with
self-destruct
or
something.
Then
you
you're,
like
your
envelope,
could
turn
from
green
to
red
without
you
noticing,
because
your
local
state
doesn't
change,
but
the
state
of
the
delegate
called
target
changes,
and
so
basically
your
question
was:
can
we?
B
How
does
it
interact,
is
basically
just
upgradeability,
not
usable,
with
account
obstruction,
and
the
answer
is
well.
You
just
have
to
kind
of
restrict
like
loosen
your
rules
a
little
bit,
because
what
I
was
just
saying,
like
the
only
issue
with
delegate
call,
is
that
the
target
could
could
kind
of
change
their
state
with
with
self-destruct.
B
Well
I
mean
we
already
have
the
tools
we
need
to
prevent
that
right.
We
just
have
to
have
this
set
instructable
eip,
and
this
is
actually
the
very
first
thing
we
described
as
like
an
addition
here.
If
we
have
set
instructable,
you
can
just
allow
delegate
calls
as
long
as
the
target
of
the
delegate
call
starts
with
set
instructable,
because
then
you
know
it
is
immutable.
B
So
then
you
can,
you
can
use
it
as
code
because
then
the
own,
because
then
the
only
way
it
could
change
is,
if
you
again,
if,
if
you
want
to
upgrade
basically
you're
right,
upgradability
only
makes
sense
if
you
can
actually
have
a
way
of
upgrading.
But
upgrading
again
is
like
a
call
in
your
web
into
your
bubble
right.
So
so
you
send
an
a
transaction,
and
that
is
allowed
to
do
things
right.
That
is
allowed
to
modify
things
and
internally.
B
It
says
instead
of
this
address
for
logic
now
you
use
this
other
address
and
that's
fine
that
is
allowed,
but
then,
once
you
set
the
new
address,
then,
basically
for
for
any
given
address
the
logic
behind
it
will
will
remain
constant
because
of
the
set
indestructible
so
basically
short
answer
there
upgradeability
and
then
ie
version
it
would
be
basically
it
would
it
wouldn't
work,
but
this
is
what
all
the
extensions
are
for.
These
are
for
exactly
these
kinds
of
use.
Cases
like
we
would
really
want
to
to
allow
for
for
library
patterns
and
upgradeability.
C
And
it
ended
if
it's
only
the
case,
if
you
want
to
have
it
so
someone
else
can
call
your
upgrade
ability
but
like
if
I
wanted
to
just
do
a
normal
transaction,
and
does
that
can
I
like
does?
Is
that
do
it?
Do
I
always
need
to
have
that
vega
possible,
or
can
I
just
just
do
a
normal
version
of
it
that.
C
B
Know
never
mind
keep
going.
No!
No,
I
think,
let's
let
let's
do
this.
Let's
basically
put
this
question
on
how,
because
I
think
there's
actually
like
an
entrepreneurial
answer.
If
I
understand
the
question
correctly,
so
the
question
is:
who
can
do
the
upgrading?
Can
it
only
be
the
user
from
the
inside
of
the
of
the
a
contract,
or
can
you
do
it
from
the
outside
and
right
now?
The
answer
would
be.
B
If
you
do
this
thing,
then
it's
it's
possible
to
do
it
from
the
inside,
but
you
couldn't
do
like
an
up
trigger
and
upgrade
from
outside
of
the
contract.
It
would
have
to
be
like
a
transaction
that
starts
at
the
contract,
but
actually
allowing
things
from
the
outside
is
one
of
the
other
extensions.
That's
why
I
kind
of
was
saying:
let's,
let's,
let's
put
this
on
hold,
because
without
with
one
of
these
further
additions,
you'd
also
be
able
to
trigger
the
upgrade
from
the
outside.
B
If,
of
course,
the
contract
allows
for
such
logic,
okay,
cool
that
makes
sense.
So,
yes,
I
I
think
it
just
it
probably
just
makes
sense
to
just
briefly
go
through
like
the
the
main
extensions.
So
just
the
way
it's
it's
structured.
I
think
this
is
still
the
way
we
think
about
it,
mainly
it's
like,
as
I
was
saying
initially
just.
F
So
we're
kind
of
nearing
the
time,
but
I,
but
I
really
wanted
to
cover.
I
feel
like
it's
important
to
cover
the
security
considerations,
because
I
know
that
that
was
a
concern
in
the
core
devs
meeting.
Do
do
we
mind
like
really
quickly
going
through
this
and
then
hitting
to
we're
just
getting
like
a
quick
summary,
and
we
can
always
have
another
call
as
well.
I
think,
if
that's
necessary,
but
so
we
can
just
really
quickly
get
to
security.
Does
that
make
sense.
B
You
know
that
that
is.
That
is
a
great
idea,
I
think,
actually,
because
because
you're
completely
right,
this
is
like
the
main
thing
that
that
people
are
interested
in
just
on
a
high
level
if
they,
if
they
don't,
don't
want
to
dive
into
a
kind
of
section
too
much,
but
I
think
actually
like
it's
mainly
the
things
that
we
kind
of
topic-wise
already
covered
so
so
basically,
the
idea
is,
I
think,
I
think
the
main
the
main
slide
here
was
this
one.
So
so,
basically,
oh,
oh
there
they
are
there.
B
There
are
several
things,
so
the
first
one
is
we
are
relatively
confident.
We
are
very
confident
that
the
actual
protocol
changes
that
we
describe
are
very
simple
to
reason
about
so,
of
course,
safe.
One
primary
aspect
of
safety
of
new
erp
is
always
like.
Does
it
change
execution
in
a
way
that
is
unsafe
and
our
our
claim
would
be
that
it
does
not
in
fact,
so
it
only
adds
two
up
codes.
It
adds
a
new
transaction
type.
All
of
these
are
very
well
understood,
and
the
nonzero
code
is
trivial.
B
It
doesn't
doesn't
have
any
security
implications.
The
pay
gas
up
code
is
a
little
bit
trickier,
but
but
of
course
again
all
it
does
it
pays
for
transaction.
It
creates
this
checkpoint
all
of
this.
So
basically
we
put
like
a
lot
of
effort
into
making
sure
that
the
actual
protocol
changes.
We
would
be
very
confident
that
they
are
like
perfectly
safe
and
can
be
like
implement
like
implemented
and
embedded
and
everything
with
very
little
a
little
effort.
This
is
this
is
like
step
one.
B
So,
like
the
actual
protocol
changes,
I
I
think
we
can.
We
can
be
very
confident
that
those
as
those
can
be
done
securely
and
then
the
question
of
course
is-
and
this
is
basically
the
topic
from
just
today-
right
either
just
notes
would
not
support
account
obstruction
transactions
whatsoever,
but
then
it's
useless.
So
can
you
can
you
add,
support
for
pending
transactions?
So
can
you
do
the
memphis
side
of
things
in
a
safe
way
as
well?
This
is
the
only
other
like
the
main.
B
I
think
I
think
I
think
this
is
the
only
other
security
consideration
days.
Protocol
changes
are
safe,
in
my
opinion,
of
course,
and
then
can
you
do
the
mempool
support
as
well
in
a
safe
way
and
there
our
argument,
like
the
the
way
we
kind
of
want
to
build
our
argument
is
this
is
like
a
more
complex
topic,
so
idea.
Is
we
have
this
this
basic
version?
B
This
is
only
like
the
single
tenant
that
the
what
I
was
just
describing
the
upcode
restrictions,
only
one
pending
transaction
and
this
prefix
these
three
together.
I
think
they
are
simple
enough
that
you
can
really
like
you
can
reason
through
them
and-
and
you
can
see
if
you
were
to
only
go
with
this
basic
version,
then
it
is
also
safe
from
all
these
other
aspects.
These
non-protocol
aspects
like
what
about
so
so
we
did
like
in
other
in
other
presentations.
B
We
also
had
like
a
little
like
some
of
these
little
nice
little
nice
little
visual
visualizations.
That
kind
of
kind
of
contrast,
effort
you
can
you
spend
on
change
versus
off
chain
how
you
basically
have
to
pay
for
for
effort
that
you
cause
on
the
network
and
how
that
doesn't
change
with
a
transaction.
So
you
still
have
this
this
mechanism,
so
basically
the
claim
is
as
long
as
like
with
these
member
rules
as
long
as
they
are
safe.
B
Well
as
as
long
as
they
do
what
they
are
supposed
to
do,
then
they
are
safe.
Basically-
and
this
is
of
course
a
bit
more
of
a
involved
argument,
so
I
think
this
is
one
that
people
would
have
to
bet
more,
because
it's
it's,
of
course
like
something
unusual
to
do
these
kind
of
mental
restrictions,
but
this
is
basically
what
the
whole
safety
of
account
obstruction
would
basically
is
based
on.
B
So
so
our
claim
would
be
that
as
long
as
you
have
good
rules
that
reliably
give
you
a
safe
subset
of
transactions,
then
the
overall
account
obstruction
system
is
safe
and
furthermore,
here
is
like
a
more
more
involved
list
of
of
of
safe
rules
to
identify
safe
transactions.
So,
basically
the
main
thing
we
would
want
to
convince
people
is
this.
This
base
variant
would
be
safe
and
then
for
every
single
extension.
We
would
also
go
ahead
and
argue
exactly
why.
F
C
C
I
where's
where,
where
the
security
or
the
dos
vector
or
the
problem
would
arise,
is
if
a
node
has
to
open
up
more
envelopes,
and
it
keeps
has
if
it
keeps
having
to
go
back
and
open
up
envelopes
to
the
point
where
it
can
never
actually
get
anything
done,
then
you
have
a
you,
have
a
network
that
can't
pass
transactions
that
can't
process
blocks,
and
that
would
be.
That
would
be
like
the
security
problem.
F
D
B
Yeah,
so
so
so
I
I,
I
think
I
totally
agree
agree
with
your
your
framing
there.
Basically,
I
I
think
so.
The
first
step
in
our
in
our
reasoning
is
that
we
kind
of
try
and
reduce
it
to
kind
of
at
least
failure
cases
or
like
problem
cases
that
we
are
already
familiar
with
with
normal
transactions,
and
then
we
can
just
just
basically,
then
it's
just
like
a
empirical
question.
B
How
much
worse
is
it
with
the
kind
of
an
abstraction
transaction
so,
for
example,
invalid
transactions
spam
spam,
a
node
with
transactions
with
invalid
signature?
You
can
already
do
that
today
and
it's
already
a
potential
issue.
If
you
just
send
a
lot
of
transactions
with
invalid
ecdsa
signatures,
this
will
this
will
temporarily
take
out
a
node.
So
the
question
is:
how
much
of
an
issue
is
it
today?
How
much
of
an
increased
issue?
Is
it
with
account
abstraction
because
account
restriction
is
more
expensive
to
validate?
B
Basically-
and
this
is
exactly
what
this,
if
we
go
down
to
the
security
considerations,
this
does
write
up
and,
of
course
this
was
the
first
write-up
we
ever
did
on
the
kind
of
section.
So
it
did
use
like
a
lot
of
earlier
assumptions,
so
it's
not
fully
100
kind
of
on
on
point
anymore,
but
it
like
the
the
main
points
hold.
B
So
we
what
we
actually
did
is
we
tested
exactly
this,
so
how
many
transactions
can
we
send
until
you
reach
this
capacity
and
it's
basically
it
is
fewer
transactions
that
can
reach
that
point,
of
course,
because
it's
it's
more
expensive,
but
it's
not
that
many
further.
So
it's
maybe
like
a
factor
of
I
I
I
don't
have.
The
of
course
depends
on
the
gas
limit
or
something
but
it
I
think
it
was
like
something
maybe
a
fact
of
10
or
something.
B
Exactly
so
so
it's
basically,
the
idea
is
try
and
kind
of
reduce
the
same
kind
of
issue,
so
we
already
know
and
then
just
figure
out
how
much
worse
is
it
and
is
it?
Is
it
reasonable
or
not-
and
this
is
also
this-
this
approach
with
this,
of
course,
there's
a
little
bit
trickier
because
it
isn't
really
as
much
of
an
explicit
issue
today,
but
this
is
why
we
have
these
these.
B
These
slides,
where
in
in
theory
where
we
talk
about
or
already
today,
in
order
to
invalidate
transactions,
you
have
to
actually
send
it
a
valid
transaction
on
chain.
That
does
something,
and
you
have
to
pay
for
that
on
chain
and
so
how
much
gas
on
chain
do
you
have
to
spend
to
basically
invalidate
gas
off
chain,
so
that's
at
least
a
little
bit
to
think
about
it
and
and
and
basically
for
counter
protection.
We
also
have
this
exact
same
invariant.
B
We
just
have
like
a
ratio
and
I
think
in
the
erp
we
also
we
even
I
think
we
even
explicitly
kind
of
give
this
a
name.
This
ratio
yeah
it's
basically
the
verification,
gas
multiplier.
I
think,
is
basically
what
you
say
like
how
much
how
much
more
gas
offline.
Can
you
invalidate
by
spending
gas
on
chain
and
and
if
you
have
this,
this
kind
of
upper
limit
there
then
you're
kind
of
safe,
because
then
it's
it's
always
predictably
expensive
to
cause
issues
locally
and
and
that
protects
you
against
and
getting
stores
there.
B
C
You
guys
give
yourself
some
credit.
This
is
like
a
really
a
really
elegant
solution
to
the
general
problem,
like
the
general
case
is
just
like.
Oh
my
goodness,
there's
nothing
you
can
do
and
me-
and
this
is
like
one
of
those
mathematically
beautiful
awesome
stuff-
that
people
come
up
and
you're,
like
oh
yeah,
of
course,.
B
Yeah
yeah
and
it
it
it's
actually
interesting.
I
mean
again
we're
probably
running
we
have
to
to
to
come
to
an
end
soon,
but
like
every
single
time,
we
prepare
for
a
new
new
presentation
or
something
we
kind
of
still
understand
that
the
properties
like
a
bit
better,
because
I
I
think
a
lot
of
the
there's
this
kind
of
this,
this
fixed
ratio,
kind
of
aspect
of
it.
I
think
we
only
understood
when
we
fully
understood
when
we
prepared
for
the
bitcoin
presentation
we
did
recently
so
so.
B
Then
after
we
probably
have
one
for
f9,
then
after
we
might
have
statelessness,
then
after
we
met
the
merge
and
then
maybe
like
in
at
some
point
or
if,
like
one
of
these
things,
gets
late
and
there's
just
a
big
gap,
then
then
I
would
kind
of
try
and
jump
in
and
think
that
we
would
try
and
push
push
for
this
again.
So
this
is
where
we're
at,
and
we
actually,
I
think
we
are
later
today.
We
have
a
call
with
the
optimism
roll
up
people
to
also
talk
about.
B
A
Think
so
yeah!
So,
while
we
are
talking
about
this,
like
you
know
getting
into
midnight
and
vip-
and
this
particular
show
is
all
about
eip
and
we
also
have
an
eip
editor
mat
with
us.
I
would
be
curious
to
understand
the
readiness
of
this
proposal
to
go
to
the
next
level
like
right
now.
It
shows
that
it
is
in
the
draft
status
how
ready
it
is
to
go
to
the
like
review
or
maybe
to
the
last
call.
D
So
there
are
a
few
technical
issues
that
still
need
to
be
decided,
one
of
which
is
whether
we
change
the
behavior
of
self-destruct
versus
requiring
set
indestructible.
That's
one
undecided
question
that
we
have
there's
still
a
few
other
small
points
on
like
what
tx.org
returns
at
different
call
levels.
That's
something
to
be
discussed,
but
they're
they're,
all
very
minor,
like
finer
details
that
I
think
we
can
resolve
very
quickly.
A
B
B
Yes,
and
and
and
that
that
happens
to
also
be
one
of
these
topics,
that
matt
is
actually
one
of
the
main
people
and
involved
with.
So
we
have
this
additional
advantage
of
just
having
that
very,
like
close
to
to
the
effort
like
someone
very
very
familiar
with
these
kind
of
topics
as
well.
Yes,
but
but
but
yeah
and-
and
I
think
just
very
briefly-
for
the
kind
of
the
governance
process
of
the
erp.
B
I
think
it's
somewhat
unusual
in
that
I
think
a
lot
of
earpiece
they're,
just
as
soon
as
they
are
ready
and
all
these
technical
questions
are
answered,
then
they're,
just
basically
cued
and
then
as
soon
as
the
next
hard
fork
is
scheduled.
Then
they
just
basically
include
it
by
default,
unless
someone
has
anything
against
it
or
something
this
erp,
of
course,
because
it
just
even
even
once
it's
kind
of
finalized
from
the
technical
point
of
view,
because
it
just
still
requires
a
lot
of
attention.
B
I
think
it's
in
this
stage,
where
we
it's
I'm,
not
sure
if
it's
basically,
what
exact
kind
of
label
is
the
bright
one
for
it
maybe
consider
conclusion
or
something,
but
it
will
always
remain
in
this
in
this
it's
maybe
similar
to
proc
power
or
something
where
oh,
I
would
be
a
little
bit
more
optimistic
about
it,
but
but
basically
where
it's
like
it's
technically
good
enough
or
mostly
ready
or
something,
but
we
did
definitely
at
some
point.
You
have
like
a
broader
conversation
about
it
on
the
oracle
devs
or
something.
B
C
B
Yeah,
maybe
the
best
ap
to
compare
to
by
the
way
would
be
one
five
f9
at
1559,
because
it's
just
that
this,
I
think
already
has
universal
buy-in
or
almost
universal
buy-in.
So
I
think
once
that's
ready.
It'll
almost
certainly
go
in,
but
it'll
also
like
one
of
these
things.
That
just
requires
a
lot
of
attention
from
the
whole
ecosystem
to
get
it
done,
and
so
I
think
I
think
this
is
very
comparable
in
the
kind
of
effort
that
it.
H
To
the
youth
protocol,
you
know,
since
it
was
considered
a
production
chain
and
so
on.
I'm
particularly
curious,
like
it's
been
very
interesting,
being
a
part
of
2718
and
seeing
how
that
is
progressing
through,
and
I'm
really
curious
to
see
next
year
how
these
things
like
1559,
binary
vacation
of
the
state
drive
these
things
go
because
we're
going
to
learn
a
lot
about
what
it
takes
to
make.
You
know
large
changes
to
a
production
blockchain
while
it's
while
it's
running.
A
Yeah
I
mean
we
probably
went
a
little
over
time,
but
I
think
it
was
totally
worth
it.
I'm
glad
that
we
decided
to
have
this
call
like
the
part
two,
for
this
account
abstraction
and
the
proposal
to
me.
It
seems
like
it
has
a
lot
of
potential
and
I
have
exciting
use
cases,
as
it
was
explained
in
earlier
episode,
like
smart
contract
wallet,
coin
mixture
and
d5
protocols,
and
we
discussed
some
of
the
questions
this
time
in
today's
episode.
A
I
hope
it
would
be
helpful
for
tap
developers
to
implement
this
proposal
in
their
project,
and
I
would
like
to
mention
that
we
also
had
a
community
call
on
account
abstraction
last
month.
I
will
leave
the
link
in
the
description
section
below
for
people
to
refer
who
haven't
watched
it
earlier
and
for
people
watching
on
youtube.
You
may
find
twitch
as
handles
for
today's
guest
and
rest
of
the
participant.
A
We
would
be
having
a
discussion
with
timbeko
to
understand
what
this
proposal
is
and
take
some
of
the
questions
that
people
are
curious
to
know
so
stay
tuned
and
don't
forget
to
subscribe.
The
ethereum
cat
headers
channel
for
youtube
notification,
keep
sharing
your
love
with
the
drum
cat
herders.
You
can
also
join
us
on
discord.