►
Description
The Ethereum Cat Herders are hosting this Community call on EIP-2938 “Account Abstraction” in partnership with The Ethereum Magicians. We invited authors of the proposal of this EIP — Ansgar Deitrichs and Sam Wilson who are joining us to provide an overview of the proposal and briefly talk about the use cases.
More info: https://medium.com/ethereum-cat-herders/account-abstraction-community-call-4744ff0f56d9
EIP Resources:
* EIP-2938: https://eips.ethereum.org/EIPS/eip-2938
* Ethereum Magicians discussion: https://ethereum-magicians.org/t/eip-2938-account-abstraction/4630
* Peep an EIP-2938 with Sam Wilson & Ansgar Dietrich: https://youtu.be/HvZd6z2YdZs
* AA Community call announcement - https://medium.com/ethereum-cat-herders/account-abstraction-community-call-4744ff0f56d9
A
Hello,
everyone
and
welcome
to
the
account
abstraction
community
call
I'm
going
to
be
your
host
today,
I'm
hudson
jameson.
I
work
at
the
ethereum
foundation
doing
some
community
and
core
developer
liaison
work
as
well
as
co-founding
the
ethereum
cat
herders,
who
are
one
of
the
co-hosts
of
this
call.
A
Today,
let's
go
around
and
I'll
call
out
your
name,
and
then
you
give
me
a
quick
intro
about
yourself,
because
we
have
both
people
who
are
part
of
the
account
abstraction
like
protocol
working
team
and
some
guests
today
who
are
going
to
be
contributing
with
questions
and
discussion.
So,
let's
start
with
puja.
B
Hey
everyone:
I'm
puja
ranjan,
the
herder
in
chief
of
ethereum
cataracts,
a
group
engaged
with
the
project,
management
and
process
improvement
of
the
ethereum
ecosystem.
I
spent
most
of
my
time
extending
support
to
network
upgrade
capab
github
repo
maintenance
array,
meeting
documenting
notes
as
needed.
B
C
Hi
all
my
name
is
matt.
I
usually
go
by
like
clients
on
the
internet.
I
helped
with
the
aaa
proposal
some
on
as
part
of
the
quilt
team,
but
sam
and
once
again
are
really
the
people
who
have
been
pushing
for
it.
The
most
I
generally
just
join
open
any
open
call
the
internet
that
talks
about
ethereum
and
just
try
and
contribute
something
to
that.
So
I'm
playing
my
typical
role
here.
D
E
Sorry
had
to
unmute
I'm
richard
I'm
working
for
the
nose
prognosis
on
the
safe
project.
So
that's
why
I'm
joining
the
call,
because,
as
a
safe,
is
a
smart
contract
wallet.
This
is
in
the
same
area
and
I'm
interested
in
the
topic,
since
we
also
want
to
put
it
forward
that
smart
contracts
becomes
a
standard
account
and
yeah.
That's
why
I'm
turning
the
call.
A
G
I
J
A
J
Okay,
awesome
yeah.
My
name
is
put
my
camera
on
for
a
second
yeah.
My
name
is
patrick
mccory.
I've
done
research
in
cryptocurrencies
for
about
seven
years,
and
now
I'm
doing
a
startup
called
any
dos
sender
that
basically
relays
transactions
to
the
network,
so
account
abstraction's
really
useful
for
us,
because
then
we
can
spend
other
people's
eats
without
having
to
you
know
worry
about
how
they
top
up
our
service.
A
A
D
That
is
basically
just
we
want
to
enable
contracts
to
also
send
transactions.
That's
that's
basically
what
it
boils
down
to
so
that,
under
this
new
thing
we
add
like
a
new
transaction
format,
and
that
transaction
format
would
basically
have
transaction
start,
start
add
contracts,
and
then
the
contract
could
have
whatever
code
it
wants
to
run
to
decide
if
it
wants
to
pay
for
the
transaction
or
not,
and
if
it
doesn't
want
to
pay
for
the
transaction.
It's
in
valid,
basically,
so
that's
that's!
The
high
level
summary
I
would
say.
A
I
got
you:
okay,
cool
yeah.
I
just
forgot
for
a
second
okay
cool,
so
I
guess
with
that
intro
out
of
the
way
do
we
have
any
kind
of
questions
or
commentary
from
any
of
the
people
who
are
attending
the
call
today
I
want
to
make
sure
we
have
plenty
of
time
for
all
those
kind
of
questions.
Otherwise
I
can
just
ramble
and
ask
questions
myself.
A
Okay,
so
I'll
just
go
ahead
and
say
my
experience
like
hearing
about
account
abstraction
goes
all
the
way
back
to
like
devcon,
2
and
devcon3,
and
how
I
remember
hearing
about
account.
Abstraction
is
basically
vitalik
and
a
few
other
people
being
like
yeah
we're
going
to
do
account
abstraction
and
you
can
pay
for
ether
with
any
kind
of
token.
You
want,
and
I
don't
know
if
that's
a
different
thing
than
what
we're
talking
about
now,
just
because
I
haven't
looked
into
account
abstraction.
D
So
basically,
I
I
think
I
think
it's
important
to
to
to
in
order
to
understand
this
specific
erp
that
we
put
out
to
to
to
indeed
look
at
the
broader
picture,
and
so
a
kind
of
section.
You
could
basically
have
that
in
more
and
more
extreme
ways,
and
so
the
most
like
the
most
complete
account
obstruction.
D
That
you
could
imagine
is
something
where
the
protocol
itself
wouldn't
understand:
payment
of
for
transactions
at
all,
anymore,
right
and
and
and-
and
I
think
that
is
later
on-
when
we
maybe
when
with
when
carl-
will
talk
a
little
bit
about
like
the
optimism
side
of
things.
That
is
something
that
that's
interesting
enough.
You
can
really
like
easily
recreate
in
in
roll-ups
and
in
that
kind
of
world.
D
It
turns
out
that
this
is
really
complicated,
though,
because
you
you
really,
it
is
very
hard
to
reason
about
transactions
in
flight
like
how
do
they
behave
under
which
conditions?
What
what
what
has
happened,
when
does
it
does
like?
Does
the
miner
wouldn't
want
to
see
the
transaction
or
not
the
intermediary
nodes
can't
really
make
the
distinction
at
all
these
things,
and
so
basically,
what
what?
What
like
a
account
obstruction
over
the
years
boiled
down
to
it?
D
More
and
more
was
to
say
we
don't
really
want
to
implement
this,
like
full
account
abstraction.
We
want
to
basically
find
a
good
compromise
where
you
get
like
most
of
the
benefits,
but
at
the
same
time
you
kind
of
limit
it
to
like
a
scope
where
you
can
kind
of
understand,
what's
happening,
and
so,
with
today's
account
obstruction.
The
way
we
we
kind
of
went
ahead
and
specified
it.
It's
kind
of
like
a
mix
there,
like
you
still
the
interesting
so
so,
basically
on
the
base
protocol.
D
Payment
is
still
done
in
in
ether
right
that
that
that
doesn't
change
at
all,
so
so
for
the
transactions
the
contract
would
still
have
to
pay
in
ether,
but
because
it's
now
the
contract.
You
can
have
this
mixed
situation,
where
the
user
only
has
some
token.
So
maybe
like
I
don't
know,
I
could
have
a
wrapper
around
die
even
but
or
it
could
just
be
my
my
debt
token,
it
could
be-
I
don't
know
anska
gold
or
whatever,
and
then
every
user
that
holds
some
unskilled
gold.
D
They
can
just
pay
the
contract
in
unscar
gold
and
then
the
contract
then
goes
ahead
and
pays
an
ether.
So
so
from
the
protocol
it
looks
like
oh,
it's
still
being
paid
in
ether
and
the
control.
The
protocol
doesn't
have
to
reason
about
all
these
weird
things,
but
the
contract
could
still
kind
of
wrap
that
and
the
user
wouldn't
so
so
users
wouldn't
necessarily
have
to
own
any
ether
anymore
at
all.
A
B
A
Sure,
if
you
all
want
to
do
the
slides,
feel
free
just
talk
about
it
in
chat
or,
let
me
know,
but
until
they
get
the
slides
pulled
up.
I
know
there
were
some
questions
in
chat
and
I'm
also
just
interested
from
carl's
perspective.
What
what
is
optimism
doing
with
aaa
how
is
aaa
different
on
a
layer
two
than
it
is
a
layer
one
platform
and
before
any
of
that
happens,
actually
explain
what
a
roll-up
is
just
in
case
people
who
are
tuning
in
don't
know
what
a
roll-up
is.
K
K
We
could
call
it
a
child
chain
directly
inside
of
layer,
one
aka
ethereum,
and
so
what
does
that
give
us
that
gives
us
essentially
a
in
in
in
if
we
have,
if
we,
okay,
I'll,
just
talk
about
it
from
the
perspective
of
like
the
kind,
the
roll-up
that
we
are
building,
so
we're
building
a
little
thing
called
optimistic
ethereum
and
it
is
essentially
ethereum
inside
of
ethereum,
so
it
has
its
own.
You
know
evm
and
it
executes
very.
K
K
You
can
actually
use
this
opcode
create
a
contract
wallet
at
the
address
of
your
like
metamask,
you
know
wallet,
so
you
know
on
ethereum,
you
have
like
you're,
either
using
a
contract,
wallet
or
you're
using
an
eoa,
but
in
this
case
you
can
actually
use
the
eoa's
address,
but
have
a
contract
wallet
there
instead.
So
anyway,
that's
a
that's
a
fun
one,
because
it
gives
it
upgrades
everyone
who's
using
metamask
to
use
contract
wallets.
So
anyway,.
D
We
can
follow
up
there
and
because
I
think
the
natural
question
that
like
might
come
up
here
is
why
is
it
so
much
simpler
to
implement
something
like
a
kind
obstruction
in
a
roll-up
right,
because
I
mean
we,
we've
spent
like
months
and
months
to
come
up
with
a
mainnet
compatible
version,
and
then
carl
just
rolls
around
and
it's
like.
Well,
we
just
implement
that
simple
amount
of
selection
on
roll-ups
and-
and
so
the
answer
there
is
is
mainly
I
would.
D
D
You
can
basically,
as
long
as
you
understand
what
kinds
of
transaction
sequences
like
process
right,
what
kind
of
token
payments
they
accept
and
so
on.
You
can
go
get
away
with
this
more,
like
full
account
obstruction
that
I
was
mentioning
earlier,
where
you
could
basically
directly
pay.
In
any
token,
all
of
these
things
as
long
as
you
know,
the
sequencer
supports
that
specific
transaction.
You
can
just
send
it
to
the
sequencer
directly
and
then
the
sequencer.
D
You
could
have
like
a
like
a
naive
sequencer
that
only
accepts
like
ether
and
only
from
like
a
smart
contract
with
a
certain
hash
or
something.
Then
you
can
have
like
a
really
advanced
sequencer
that
also
accepts
dye
and
has
like
advanced
heuristics
for
what
kind
of
contracts
it
supports
and
all
these
things.
But
why
can't
you
have
that
on
mainnet?
Well,
on
mainnet?
We
have
this
decentralized
architecture
with
not
only
are
the
miners
decentralized,
but
also
the
the
the
memphis,
and
so,
if
you
want
to
send
a
transaction
from
you
or
from
your
computer.
D
D
Yeah,
exactly
that's,
that's
like
a
great
summary.
So
basically,
this
is
like
the
upside
is.
It
makes
all
networks
network
decentralized
and
for
the
base
layer
you
need
that.
I
mean
for
sequences.
It's
just
it's
not
like.
That's,
not
a
compromise
that
roll-ups
make
you
just
don't
need
it
for
roll-ups
right,
because
you
already
have
the
trustlessness
of
the
base
layer.
You
can
always.
D
You
roll-ups
usually
have
like
a
mechanism
where
you
can
skip
the
sequences
and
basically
force
your
transaction
indirectly
via
the
base
chain,
and
that
is
important
because
otherwise
you,
like
you'd,
have
problems
with
centralization,
but
on
the
main
base
chain.
You
really
need
this
decentralized
world
where
everyone
is
basically
always
talking
about
here.
I
I
like
know
about
this
new
transaction.
Do
you
maybe
also
want
to
transmit
it
and
so
on?
But
that
requires
like
that.
Every
node
in
the
network
has
like
a
roughly
similar
understanding
of
what
a
valid
transaction
looks
like
right.
D
If
one
miner
supports
these
kind
of
transactions
in
the
other
minor
supports
the
other
ones
that
doesn't
work
because
on
the
base
chain,
you
kind
of
need
to
have
to
be
in
agreement
about
what
kinds
of
transactions
get
relayed
throughout
the
network,
and
so
it's
it's
way
more
complicated
to
get
the
construction
basically
to
work
on
the
mainnet.
That's
that's
why
it
took
us
like
a
long
time
to
get
this
relatively
complex
proposal
out
for
for
base
net
like
base
chain,
whereas
for
rollups
it's
it's
simpler!
That
that's
that's
maybe
for
context.
A
K
A
Heard
it
here
first
carl
has
confirmed
that
december
2020
full
launch.
So
that's
that's
that
no
I'm
joking,
I'm
joking,
don't
get
carl
in
trouble,
so
out
count
abstraction
team.
What
about
you,
the
timeline
for
aaa
in
your
mind,
not
necessarily
for
putting
it
on
mainnet,
but
what's
left
to
do
as
far
as
research
and
development
and
then
what
are
the
next
steps
and
maybe
any
roadblocks
you're
coming
up
with.
D
So
yeah,
I
think
that's
actually
like
a
really
important
kind
of
conversation
to
have
so,
I
would
say,
research-wise.
We
are
relatively
confident
that
we
are
mostly
there
so
there's
there
are
a
few
things
to
do
to
clean
up
a
few
things
to
fully
spec
spec
out.
I'm
not
sure
like
most
people
might
be
familiar.
I
I
do
have
the
presentation,
maybe
at
some
point
later
on,
if
we
want
to
really
jump
into
that,
that
might
make
sense.
D
We
have
this
this
design,
where
we
have
like
a
base,
the
minimal
aaa,
and
then
we
have
these
extensions
that
add
like
more
and
more
functionality
and
the
base
base
version,
I
think,
is
full
completely
specified
at
this
point.
The
extensions
are
mostly
specified,
but
they
would
require
a
little
bit
more
work
and
next
step.
D
This
is
something
that
definitely
would
take
some
time
right.
Not
only
the
implementation
but
then
also
spinning
up
test
nets
actually
get
people
interested
get
get
like
a
little
bit
of
actual
real
world
experience
with
that.
But
then,
of
course,
the
main
the
main
thing
is
like
what
about
the
like:
the
core
developer
process
right?
D
D
If
everyone,
if
like
a
conversation,
would
tomorrow
become
everyone's
top
priority,
which
of
course
it
won't,
but
if,
if,
if
it
would,
then
I
think
first
of
all
of
all
there's
still
the
berlin
heart
folk
that
would
have
to
to
be
actually
done
first,
just
to
get
that
out
of
the
way
a
conversation
would
not
be
part
of
that.
That
is
I'm
not
sure,
I
would
say.
Probably
I
don't
know
late
january
early
february.
D
D
Basically,
if
they
wanted
to
and
wanted
to
basically
take
a
ground
up
section
as
the
big
next
thing
to
do,
and
then
I
think
it
would
from
there
on
maybe
take,
I
don't
know
six
to
12
months
to
actually
arrive
on
main.
I
think
I
think
that
is.
That
is
like
a
realistic,
realistic
expectation,
but
then
again,
of
course,
the
main
uncertainty
is
just
about.
Is
it
a
priority,
and
I
don't
think
it's
right
now.
At
least
I
don't
think
it's
like
the
biggest
priority.
D
I
think
there
are
other
ones
as
well
and
then,
of
course,
just
do
people
want
it
at
all.
I
I'm
I'm
reasonably
optimistic
that
if
at
some
point
there's
just
like
nothing
else
to
do,
I
think
a
conversation
is
definitely
something
that
like,
if,
if
it
doesn't
crowd
out
other
things,
people
would
be
happy
to
to
to
do
it.
So
I
definitely
think
as
soon
as
like,
we
have
some
free
time.
It'll
arrive.
It
just
is
like.
D
I
think
we
just
have
to
be
aware
of,
like
what
are
the
other
big
things
currently
ongoing,
and
I
would
mainly
mention
like
this
one,
five
f9.
Of
course,
which
I
think
people
would
pre
if
it's
ready
by
then
would
like
prioritize
overcome
abstraction,
there
is
statelessness,
which
again
is
probably
like,
is
definitely
like
more
important,
because
other
things
also
depend
on
that
and
then
there's
just
like
all
these
two
activities.
D
So
there's
the
eth
one
is
two
merge
which
we,
as
quilt
team,
also
are
a
little
bit
involved
in
working
on
that
which
also
as
soon
as
that's
relevant
timeline,
wise
would
be,
would
have
higher
priority
and
then
there's,
of
course,
just
like
sharding
and
all
of
all
of
these
things.
So
just
what
I'm
saying
is
just.
We
need
like
basically
like
a
six
to
12
months,
block
of
mostly
like
free
prior
priority
within
the
core
developers,
and
at
that
point
I
I'm
pretty
optimistic.
We
could
move
ahead
with
that
that
that's.
A
G
So
on
the
timeline
of
account
abstraction,
I
would
have
to
say
I
think,
I'm
a
little
bit
more
pessimistic.
I
think
it's
a
little
bit
further
out.
I
think
there's
going
to
be
a
lot
of
testing
and
it's
going
to
be
a
while
for
that
to
get
finished,
but
you
know
I
I
still
see
it
as
making
it
to
mainnet
as
long
as
people
find
it
useful.
A
Cool
cool
okay,
so
let
me
see
if
there's
any
messages.
Okay,
do
we
have
questions
from
any
of
the
people
who
are
joining
us
today
on
the
call,
maybe
about
their
specific
projects
and
how
it
can
interact
with
it?
If
there's
like,
because
I
know
we
had
people
like
rye
from
client,
dev
teams,
I
know
we
had
patrick
from
any
sender
and
stuff
like
that.
Do
and
does
anybody
have
anything
for
the
team.
B
D
Yeah,
so
basically,
I
think
then
we're
a
little
bit
again
with
the
topic
of
of
roll-ups,
because
this
is
like
the
I
think,
the
main
place
or
the
main
alternative.
I
think
I
would
be
too
sad
actually
if
it
turned
out
to
that
that
just
like,
at
least
for
the
next
year,
two
or
something
that's
just
not
a
priority
for
mainnet
and
like
the
roll-ups
just
are
the
first
places
to
to
actually
adopt
a
construction.
I
think
that
they'll
be
fine.
D
Actually
so
so
the
main
one
is
is
like
these.
Oh,
I
forgot
the
name
again.
What's
this
not
sequence,
is
it
sequencer,
whatever
the
sequences,
in
order
for
to
accept
transactions,
they
still
have
to
understand
that
they
are
getting
paid,
and
so
I
think,
the
the
most
naive
initial
implementation
that
the
team,
the
the
optimism
team
is
planning,
is
just
to
say,
they're
only
accepting
transactions
to
like
one
one
exact,
smart
contract
that
they
know
the
hash
of,
and
of
course
this
is
like.
D
Even
this
is
exactly
back
to
the
mainnet
situation
of
only
only
supporting
eoas.
Just
instead
of
an
eoa,
you
have
like
a
smart
contact
wallet
that
that
equals
an
eoa,
basically
and
so
you're,
just
exactly
back
in
the
same
situation
with
that
that
you
were
before,
and
then
it
would
be
up
to
sequences
to
to
understand
other
types
of
transactions.
D
But
what
we
like
figure
like
looked
looked
into
for
most
of
our
time,
is
how
can
you
design
the
base
layer
or
like
the
just
the
execution
environment,
to
make
it
as
easy
as
like
as
simple
as
possible
to
reason
about
transactions?
And
so
I
I
think,
there's
like
a
decent
case.
We
made
that
that
roll-ups,
like
optimism,
should
also
adapt
these
more
restrictive,
like
rules
in
order
to
to
make
it
easier
for
for
for
transactions
to
signal
to
sequences
here.
D
A
Awesome:
okay,
yeah,
that
that's
that's
a
really
interesting
take
going
back
just
a
little
bit.
I
actually
had
a
thought
because
we
were
talking
about
timelines
and
I'm
currently
the
organizer
of
the
core
developer
meetings
and
I've
been
kind
of
seeing
where
a
lot
of
the
talk
for
future
priorities
are
going,
and
I
know
account
abstraction
is
definitely
in
the
top
five.
A
In
my
opinion,
of
major
things,
I
don't
even
know
if
we
have
five
total,
but
I
the
only
ones
I
can
think
of
are
1559
and
this
and
then
the
bls
curve
stuff
coming
in
and
there's
going
to
be
some
fighting
for
other.
You
know
different
cryptographic,
signatures
and
curves
in
the
future,
going
into
pre-compiles
or
stuff
like
that,
like
evm
384.
A
So
that
might
be
another
one,
but
I
can
definitely
see
by
next
summer
this
becoming
a
priority,
if
not
earlier,
in
some
regards
for
the
review
and
re
and
like
the
core
devs
kind
of
giving
feedback
stage.
So
that's
definitely
something
that
I
think
is
an
encouraging
development
to
see
you
guys
on
the
court
of
calls
taking
questions
and
stuff
like
that.
I
think
that's
really
good
and
I
think
that
something
else
oh
yeah
go
ahead.
A
Absolutely
that's
a
really
good
point
and
that's
one
of
the
new
network
upgrade
policies
that
we've
have
in
place
to
kind
of
go
through.
This
call.
What's
something
for
inclusion,
why
am
I
forgetting
what
it's
called
considered
for
inclusion
yeah?
I
helped.
I
helped
draft
that
I
don't
know
why
I
forgot
it
considered
for
inclusion
and
yeah.
It's
cool
that
it's
actually
the
process
is
working
out.
A
G
You're
not
too
far
off
so
account
of
abstraction
on
its
own
doesn't
get
you
there,
because
you
can't.
You
can't
convert
your
eoa
into
an
aaa
contract,
but
you
can
do
something
similar.
If
you
add
in
some
of
the
beyond
aaa
eips
we've
been
throwing
around
one
of
which
is
these
sponsored
transactions
eip
3074..
G
A
D
I
would
say
the
hope
would
be
to
like
going
forward,
establish
contracts
more
and
more
is
like
the
the
native
like
core
unit
on
the
on
the
ethereum
blockchain
and
uas,
more
as
like
the
legacy
type,
but
but
just
like
to
realistically
have
like
some
some
part
of
adoption.
There
there's
these
kind
of
things
like
sponsor
transactions,
that
that
kind
of
give
you
backward
compatibility
with
the
users
that
already
have
eoas
and
and
and
tied
to
their
identity.
D
Basically,
I
think
those
are
really
important,
but
like
going
forward
the
idea,
the
hope
would
be
to
mourn
more.
I
think,
of
course,
like
richard
and
like
the
the
most
people,
all
these
smart
contract
developers
out
there
like
can
can
talk
about
how,
like
it's
a
it's,
a
slow
and
long
road
to
like
bring
more
people
into
smart
contact
wallets,
but
but
hopefully
that
would
like
make
this
easier
and
just.
A
D
So
I
think
that
these
these
things
depend
heavily
on
the
details.
So
if
you
want
basically
upgradeability,
you
can
also
just
have
one
smart
contract
and
then
you
basically
call
out
into
libraries
for
the
for
the
specifics
and
you
just
switch
out
the
libraries
if
you
want
to.
But
of
course
you
could
also,
if
you
just
basically
want
to
have
a
whole
new
account
or
like
write
in
then
you
can
also
just
choose
to
deploy
a
whole
new
smart
contract
wallet
and
have
that
be
on
your
new
main
main
main
identity.
Basically,.
A
L
L
L
G
G
So
so
one
so,
for
example,
when
you
call
from
one
contract
into
another,
if
the
callee
reverts
the
caller
does
not,
and
that
lets
you
do
some
like
error
handling
and
checks
and
stuff.
We
want
to
make
the
pay
gas
op
code
make
a
similar
kind
of
checkpoint,
and
we've
noticed
that
that's
not
too
hard
to
do
in
geth.
How
hard
is
it
to
do
in
other
clients.
F
Yeah,
actually,
I
know
like
one
of
the
like
main
goals
of
this
vip
is
to
make
it
so
that,
like
users,
don't
have
to
like
trust
or
like
rely
on
extra
protocols
for
privacy,
like
tornado
cache.
So
I
was
like
wondering
if
you
could
talk
more
about
like
what
aa
can
bring
for
like
privacy
and
like
relayers.
D
D
This
is
not
that
important,
because
using
relays
it
doesn't
doesn't
add
that
much
of
like
an
extra
extra
step,
although
of
course
it's
always
always
nicer,
but
but
like
the
there's,
this
one
import
really
important
thing.
They
just
pointed
out
of
of
privacy
and,
of
course,
from
for
most
applications
today
on
ethereum.
That
is
not
that
big,
a
thing,
because
it's
already
tied
to
your
I
to
your
ethereum
identity,
like
you,
can
you
can
look
at
like
the
the
the
the
address
behind
it?
D
Basically,
but
something
like
tornado
crash,
I
think,
is
a
great
example,
because
they
that's
exactly
that.
You
don't
want
to
reveal
where,
where,
where
the
the
the
withdrawal
comes
from-
and
you
ideally
also
don't
want
that,
the
relay
knows
you
the
ip
address
of
the
of
the
person
that
sent
the
request
or
all
of
these
kind
of
things,
and-
and
I
personally
had
the
intuition
that
over
time,
more
and
more
of
ethereum
will
like
will
move
towards
these
more
like
privacy
based
solutions.
D
Basically
wrapping
things
inside
of
your
knowledge,
proofs
and
in
that
world,
I
think
it
will
become
more
more
important
actually
for
users
to
kind
of
have
it
have
an
e
easy
way
to
kind
of
not
not
be
identifiable
trackable
and
all
these
things,
and
I
think
in
that
context
this
is
really
like
another
of
these
advantages.
Of
course,
if
you
want
to
interact
with
the
base
net
base
chain
that
also
you
also
have
to
like
actually
have
some
connection
out.
D
So
there's
still
some
point
that
at
which
you
you
could
be
identified,
but
I
think
there
are
other
solutions
that
try
to
also
get
rid
of
that.
So,
like
I
don't
know,
I'm
I
I
personally,
I
I
know
like
the
hopper
team
that
they
try
to
implement
like
some
some
tour
like
system
for
for
for
ethereum
nodes.
So
so
you
can
send
transactions
without
revealing
anything
about
your
identity
and
and
like
those
in
combination
with
with
the
counter
protection
that
would
be
really
powerful.
I
I
think.
A
Okay,
yeah
tornado
cash
is
definitely
gaining
in
popularity,
so
having
more
privacy
around
protocols
like
that
is
going
to
be
really
really
interesting.
Thanks
for
the
question
did
you
have,
I
said
this
earlier
and
then
I
just
blanked,
and
I
didn't
do
anything
with
it.
Do
you
have
a
presentation
of
some
kind
and
scar
or
sam
that
you
wanted
to
give
go
over,
or
would
you
rather
just
take
questions?
This
is
kind
of
your
call.
D
So
we
we
do
have
a
presentation.
We
have
like
basically
like
a
core
presentation
that
we
have
several
different
versions
of,
because
we
gave
a
couple
couple
presentations
over
the
last
few
weeks
and
I
think
the
most
relevant
one
was
the
people
in
eep
session
that
we
recently
had.
I'm
not
sure,
though,
if
it,
if
it
makes
sense,
so
I
do
with
them
open
right
now,
just
like
as
a
reference
in
case,
there's
anything
specific
to
reference.
A
D
C
But
we
do
have
two
people
who
are
leading
teams
in
this
relay
space,
and
I
didn't
know
if
they
wanted
to
weigh
on
what
their
thoughts
were.
In
terms
of
you
know,
you
know
relayers
being
able
to
kind
of
see
the
transactions
that
are
coming
in
and
and
the
differences
between
the
privacy
of
that
and
just
you
know,
interacting
with
the
ethereum
network
directly.
J
I
get
away
in
a
bit,
I
guess
I
mean
I
guess
why
a
a
is
relevant
for
something
like.
I
need
a
sender
where
we
re
so
I
mean
before
I
go
into
that.
It's
just
for
everyone's
clear.
What
any
dust
sender
does.
The
idea
is
that
we
take
a
transaction
like
a
meta
transaction.
We
pack
it
in
an
ethereum
transaction.
J
J
J
J
So
there's
two
ways
to
implement
it:
either
the
target
contract
can
verify
a
signed
message,
so
the
meta
transaction
is
then
as
a
signed
message
from
the
user.
We
take
their
signed
message.
We
send
it
and
then
the
smart
contract
can
verify
the
signed
message,
get
the
signage
address
and
use
that
instead
of
message.sender
or
they
can
have
a
wallet
contract
which
is
basically
doing
the
same
thing
and
then
it
will
dock
called
out
to
the
target
contract.
J
So
you
know
either
you
have
a
wallet
contract
or
you
modify
the
target
contract,
so
account
abstraction
is
more
to
do
with
for
us
around
the
wallet
contract
approach
in
terms
of
solving
that
problem,
but
I
guess
for
the
relay
for
account
abstraction
the
real,
like
the
real.
What
a
kind
of
abstraction
is
really
solving
is
how
the
user
pays
for
the
transaction
for
us
so
right
now
the
user
has
a
pre-deposit
each
in
our
service
and
then
we're
willing
to
relay
transactions
in
their
behalf
where
they
can't
abstraction.
J
You
know
they
could
deploy
a
special
wallet
contract
that
will
then
pay
the
transaction
fee
instead
of
us,
so
they
don't
accept
the
pre-deposit,
the
east
of
us.
You
know
they
just
deploy
their
wallet
contract,
they
put
e
from
their
wallet
contract.
Then
they
can
ping
our
api.
We
can
validate
it
and
say:
oh
yeah,
you
know
we
can
spam
their
eth
and
then
we
can
just
send
the
transaction
on
their
behalf,
so
for
a
kind
of
abstraction.
The
problem-
that's
really
solving
for
us
is
the
pre-deposit
of
eth,
the
message.sender
problem.
J
You
know,
I
can't
abstraction
wallet.
Contracts
do
solve
that,
but
it's
very
difficult
to
convince
people
to
deploy
wallet
contracts.
That's
been
our
experience
so
far.
So
what
would
really
help
a
relay
service
is
a
general
message.sender
solution
like
the
the
new
york
code
that
you
proposed.
You
know
where
you
call
into
an
opcode
and
actually
changes
the
signer
to
the
message.sender.
A
If
not,
I
have
something
I
wanted
to
bring
up.
There's
a
document
that
sam
wrote
about.
I
think
it's
called
eip,
2938
account
abstraction
explained
and
they
give
a
really
good
brief
overview
of
2029-38
and
they
mention
in
it.
Let
me
see
if
I
can
find
it
there's
there's
a
lot
of
talking
about
the
nonce
and
how
basically
this
opens
up
here.
G
Sure
so
so
normal
transactions
can
only
be
invalidated
with
a
very
limited
set
of
conditions.
So
if
the
account's
nonce
changes,
the
signature
is
invalid
or
the
accounts
balance
drops
below
the
value
of
the
transaction.
So
those
are
the
three
cases
that
a
traditional
non-a
transaction
can
be
invalidated.
G
Aaa
transactions,
on
the
other
hand,
can
be
invalidated
by
any
change
at
all
to
the
a
a
contract
state,
so
you
could
have
like,
let's
say,
300
different
aaa
accounts
and
each
one
of
those
accounts
has
a
bunch
of
pending
transactions,
so
we're
just
setting
up
what
the
attack
would
look
like.
So
you
have
all
these
pending
transactions
in
the
mempool.
All
you
know
touching
different
aaa
contracts.
G
Each
one
of
those
contracts
has
an
if
statement
in
them.
That
says.
If
this
you
know
the
the
value
at
storage
slot
0
is
true.
I
am
now
invalid
and
I
will
never
pay
so
you
have
all
of
these
like
ticking
time
bomb
transactions
in
the
mempool,
and
then
the
attacker
sends
a
single
transaction
on
chain
with
a
very
low
gas
feed,
basically
just
a
just
an
s
store
that
writes
into
each
of
these
contracts.
Setting
storage
slot
zero
to
true
invalidating
all
of
these
mempool
transactions,
wiping
the
mempool.
G
So
this
is
kind
of
an
example
of
how
this
kind
of
ratio
thing
works.
So
yeah,
that's
the
attack,
that's
the
whole
thing!
Basically,
you
propagate
the
stuff.
All
these
nodes
do
all
this
work,
validating
these
transactions
and
then
they're
invalidated
by
a
very
cheap
transaction
on
chain,
and
that
that's
a
huge
problem
for
them
for
the
mempool
they
can
crowd
out
legitimate
transactions.
A
G
A
G
A
G
D
Okay,
the
idea
is
really
just
you
want.
You
want
the
same
situation
for
a
contract
that
you
have
for
normal
transactions.
Only
only
transactions
from
the
same
contract
once
they
are
included,
can
can
basically
invalidate
the
other.
So
basically
you
can.
You
can
keep
a
list
like
these.
Are
the
10
pending
transactions
to
the
to
the
contract
here,
and
only
if
one
of
those
gets
included
on
chain,
then
the
other
nine
have
to
be
reevaluated.
D
A
E
Yeah,
so
the
question
was
right:
how
would
this
work
together
with
hypnosis
safe
as
hypnosis,
safe,
being
a
smart
contract-based
motor
signature
wallet
and
how
would
it
benefit
nor
how?
How
would
sygnosis
safe
use
it
so
in
general
right?
So
when
we
started
developing
signals
safe?
Originally,
we
started
with
mobile
and
also
having
mobile.
E
We
collect
the
signature
off-chain.
We
don't
want
that
all
of
the
owners
have
to
hold
key,
because
if
you
imagine
a
setup
where
you're
a
team
of
that
managers
fund
together
and
if
any
member
of
this
team
has
to
have
some
ease
on
their
account
just
to
execute
a
transaction
via
this
or
confirm
a
transaction
on
this
shared
account,
this
would
be
kind
of
a
hassle
and
right
now,
what
we
have
to
do
is
basically
similar
to
any
dot
center.
We
have
something
like
for
the
gnosis
relay
right.
E
We
also
talk
to
all
the
different
people
like
any
dot
center
and
gsm
and
rock
site
because
ignore
the
safe
theoretically
allows
it
already
to
do
most
of
the
stuff
of
shane.
But
obviously
there
is
overhead
of
what
also
sam
just
described
right
like
if
you
have
a
real
layer.
They
also
have
this
non
problem.
You
also,
if
you
go
against
the
account,
it
has
not
there
a
lot
of
these
things.
E
The
hope
would
be
that
we
don't
have
to
write
them
into
our
contract
to
some
extent,
and
they
would
be
a
little
bit
more
native
so
that
the
relay
is
not
involved
anymore
still,
the
safe
would
step
the
safe
contract
would
still
use
a
multi-signature
part
and
do
all
this
logic,
I
think
the
the
first
version
of
the
account
selection.
Even
so
it's
very
interesting.
E
It's
not
where
it
would
be
super
useful
for
the
save
in
its
current
form,
because
the
safe
has
like
some
advanced
logic,
where
it
allows
something
we
call
modules,
which
is
basically,
you
can
register
any
other
address
which
can
go
around
your
logic,
but
so
that
you
can
unchain
use
other
logic
or
recovery
logic.
That
can
then
give
you
back
access
which,
with
the
current
approach,
where
you
have
one
entry
point-
and
only
this
entry
point
is
allowed
to
trigger
state
changes
through
this
account
might
be
a
little
bit
conflicting.
E
But
even
but
probably
this
will
not
be
forever
like
this
and
it
will
change.
So
it's
fine
and
I
would
still
love
to
see
the
first
version
and
even
write
a
save
that
doesn't
have
some
module
functionality
to
even
just
showcase
how
it
works,
and
I
think
the
other
thing
which
would
be
really
cool,
which
is
currently
just
a
blocker,
is
still
that.
There's
this
op
code,
which
basically,
in
the
end,
paste
the
gas
the
page
yes
op
code
right
now.
It's
required
that
your
deployed
contract
actually
calls
like
your
aaa
contract
courses.
E
Obviously,
the
coolest
would
be
if
we
could
just
point
to
a
new
version
of
the
save
that
has
suddenly
this
nice
account
abstraction
logic
with
pay
gas,
but
that
would
mean
that
actually,
the
pay
gas
up
code
would
be
in
the
implementation
code.
So
this
would
be
the
very
long
version
where
it
would
be
for
us
where
we
would
see
it
when
the
account
abstraction
is
fully
supported,
that
we
just
released
a
new
version
of
zygnosis,
safe
and
magically.
E
D
The
hope
would
be
to
just
basically
directly
have
at
least
all
the
protocol
changes
in
place
by
the
time
we
move
to
account
abstraction
to
to
basically
already
go
to
the
fullest
version.
It's
more.
I
I!
I
would
understand
it
as
more
like
the
a
way
of
reasoning
about
the
safety
of
of
the
system.
Where,
basically
like
this,
we
can
very
simply
reason
about
the
safety
of
the
minimal
version,
and
then
we
basically
argue
for
every
individual
extension.
D
Why
why
this
is
also
safe
to
do,
and
if
anyone
has
like
problems
with
one
specific
extension,
we
could
just
not
do
this
one,
or
at
least
not
in
initially
do
this
one.
So
I
would
hope
that
there's
not
like
a
long
period
in
which
we
we
would
stay
at
like
the
like
kind
of
section
light,
but
immediately
like
go
to
the
more
more
advanced
one.
Although
there
are
some
features,
for
example,
this
like
pay
gas
in
that
in
delegate
call
targets,
or
even
some
other
things
like
some.
D
Some
more
advanced
features
you
you
might
want
to
have
for,
like
some
advanced,
defy
arbitrage,
use
cases
or
something
some
of
those
that
not
even
like
our
fullest
version
supports,
because
they
are
just
really
tricky
to
to
to
do,
and
maybe
we'll
add
some
of
them
over
time
before
it
gets
included,
because
we
figure
out
how
to
do
them
safely.
But
those
those
of
course
are
still
like
that's
unclear.
If,
if
we
can
find
a
way
for
those.
A
Thanks
for
that
discussion
shout
out
to
gnosis
safe,
that
is
the
official
place
that
the
cat
herders
keeps
all
their
goodies
that
are
worth
any
value,
meaning
ether
and
die.
So
thank
you
for
building
that
product.
It
looks
like
sam
is
saying:
when
do
we
want
to
schedule?
The
next
call,
do
you
mean
the
community
calls
sam?
B
A
Reasonable
yeah
and
I
think
for
a
future
call
what
I'd
really
like
to
be
interested
in.
I,
there
were
some
great
people
who
came
on
today
like
optimism
and
annie,
cinder
and
gnosis
safe,
but
having
more
wallets
and
exchanges
and
minors
and
stuff
who
can
really
dive
into
what
the
implications
of
all
this
would
be.
I
think,
would
be
really
valuable
if
we
can
get
some
of
those
type
of
people
on.
A
Yeah
so
well,
we
can
definitely
try
to
do
that,
so
we
only
have
a
few
minutes
left.
So
in
these
final
seconds
or
these
final
minutes,
I
should
say
sam
and
ansgar,
if
I'm
a
dap
developer,
if
I'm
a
miner,
if
I'm
an
infrastructure
provider
like
ether,
scanner
and
fiera,
what
kind
of
feedback
do
you
want,
and
where
do
I
put
that
feedback?
Where
should
I
reach
out
to
you
all.
A
G
A
And
more
information
about
this
eip
and
account
abstraction
in
general
is
going
to
be
in
the
medium
post
that
the
cat
herders
put
out
to
announce.
This
call
there's
some
really
good
links
in
there
that
I'd
encourage
people
to
look
at
if
you
want
some
more
deeper
insight
into
this
eip
and
this
whole
initiative
here.
Anybody
on
the
call
any
final
words
we
got
about
two
minutes
left
otherwise,
we'll
just
wrap
this
one
on
up
and
get
going
with
our
is
it
friday,
oh
god,
it's
friday.
Yes,
anybody
have
final.
B
Words,
thank
you,
yeah.
I
would
sincerely
like
to
thank
everyone
to
join
today,
because
this
is
the
first
time
that
we
are
organizing
any
community
call
for
any
of
the
proposal,
but
we
hope
to
see
more
community
calls
coming
up
talking
to
authors
talking
to
people,
as
hudson
mentioned,
that
we
should
be
inviting
more
infrastructure
provider
to
take
their
questions.
So
thanks
to
the
authors,
of
course,
and
people
to
join
I'm
sorry,
I
feel.
Did
I
interrupt
a
light
client
you're
saying
something.
C
Oh,
I
just
wanted
to
say
one
quick
thing.
I
thought
this
was
probably
relevant.
Given
you
know
the
the
scale,
the
change
that
aaa
is,
but
from
the
ama
that
was
hosted
by
the
ef
research
team.
The
other
day
vitalik
had
a
comment
where
he
basically
said
that
over
the
next
two
years,
there's
going
to
be
substantial
changes
to
the
ethereum
protocol
and
to
me
you
know,
I
feel
like
that.
C
Just
means
it's
such
a
perfect
time
to
try
and
have
these
major
changes
go
through
because
we're
already
going
to
be
doing
a
lot
of
huge
changes.
1559
is
going
to
be
a
major
change.
It's
going
to
require
them
significant
changes
to
the
mim
pool
and
with
all
of
this
work
going
in,
it
is
a
good
time
for
people
interested
in
a
and
people
who
want
to
make
that
happen
to
start
contributing,
and
we
can
try
and
bundle
these
things
together.
So
we
can
make
the
ethereum
protocol
a
lot
better.
E
A
Great
well
thanks
everyone
for
the
final
comments.
We
have
hit
time.
Thank
you
so
much
sam
ansgar
and
everyone
who
joined
on
the
call.
This
has
been
great.
I
think
I
learned
a
lot
and
I
can't
always
say
that
about
every
eip,
especially
when
this
dense,
so
you
all
did
a
great
job
of
explaining
it.
Thank
you
all
so
much
everyone
have
a
great
weekend
and
we'll
see
everybody
who
tuned
in
on
the
stream
for
the
next
community
call
bye.
Everyone.