►
From YouTube: PEEPanEIP#65: EIP-4337: Account Abstraction via Entry Point Contract specs. with Yoav W., Kristof G.
Description
Topics covered
-----------------------------
1:40 - Guest intro
3:20 - Presentation
3:44 - What is Account Abstraction?
4:38 - How does this proposal work - An Overview
6:30 - Diagram - operations
7:00 - what are the use cases, why make a standard?
7:53 - Incentivize Smart Contract Wallet Adoption
8:33 - Universal & Widespread Interface
9:07 - Custom Signature Schemes
9:50 - Upgradeability
10:04 - Paymaster
10:21 - Pay with Tokens
10:31 - Trading without native currency
10:54 - Private withdrawal from ZK Mixers
11:31 - Paying off-chain with a Credit Card
11:53 - Multi-operations
12:17 - Decentralized
12:30 - Incentive aligned
13:00 - Slow rollout possible
13:49 - Future-proof
14:20 - Drawbacks
15:30 - Explaining user operations submitted by a bundler with diagram
22:38 - Entry Point interface
26:04 - Wallet and Paymaster interfaces
28:20 - Security considerations - contract risks
29:26 - Security considerations - DOS
31:10 - DoS mitigation - validation gas
32:41 - DoS mitigation - environment consistency
35:26 - DoS mitigation - storage access
40:01 - Client / Bundler implementation
42:50 - Links
43:18 - Questions
43:44 - Is there also going to be an EIP on the network for P2P specification?
45:47 - What are the advantages of this proposal being ERC that may help to move it towards a standard?
49:15 - Advantage or limitation of additional mempool?
51:14 - How does this proposal work with the multisig wallet?
53:48 - How comfortable are you relying on a higher-layer infrastructure to avoid consensus-layer protocol changes?
56:42 - Replay attack and chain id discussion
59:47 - Paymaster - Do you think we do not need EIP-3074 if we have EIP-4337 as a standard?
1:04:45 - Will there be any change expected with the introduction of Merge?
1:06:42 - When will the EIP be ready for Review status?
1:11:28 - What is the EIP status change process?
1:13:56 - Anything else you would like to share?
Resources:
-----------------
Slides - https://docs.google.com/presentation/d/1Qt6F98WduHVbm_F15Xf7-fdkvqY7IMrJi6m9x-7p9z8/edit#slide=id.p
Proposal - https://eips.ethereum.org/EIPS/eip-4337
Discussion-to - https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160
Discord - https://discord.com/invite/fbDyENb6Y9
Blog - https://etherworld.co/2021/10/06/an-overview-of-account-abstraction-in-ethereum-blockchain/
Follow at Twitter
-----------------------------------------------
Yoav Weiss @yoavw | Kristof Gazso @kristofgazso | Pooja Ranjan @poojaranjan19
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
EIP-3074 - https://www.youtube.com/watch?v=4A3N8dvdaSk&list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F&index=39&t=1s
EIP-2938 - https://www.youtube.com/watch?v=Xoc4q1nJzsU&list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F&index=51&t=2s
ERC Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/
A
Hello
and
welcome
to
65th
episode
of
t
penny,
an
educational
video
series
where
we
discuss
an
ethereum
improvement
proposal,
upcoming
upgrades
and
the
basics
of
ethereum
blockchain.
I
am,
and
today
we
are
going
to
discuss
eip
4337
account
abstraction
via
entry
point
contract
specification
with
two
of
the
co-authors
of
the
proposal.
A
Joyf
weiss,
christophe,
kessel
and
some
of
the
proposal.
Implementation
team
members
kristoff,
is
with
one
of
the
popular
execution
client
nether
mind
and
you
have
is
a
with
ethereum
foundation.
A
quick
intro
to
the
proposal.
Eip
4337
is
a
standard
track
erc,
which
was
initially
proposed
in
september
2021
by
vitalik,
butherin
and
team.
The
eap
proposes
an
alternate
method
of
account
abstraction.
We
will
learn
more
on
the
topic
in
a
while.
First,
let's
meet
our
guests
for
the
day
christoph
and
eur
welcome
to
the
show.
A
B
A
A
B
Yes
cool,
say
we're
here
to
present
eip
457,
which
is
an
account
abstraction
proposal
via
alternative
memphil,
so
we've
already
had
our
introductions,
so
it's
me
and
joab
presenting
first
of
all,
it's
good
to
note
what
actually
is
account
abstraction,
so
kind
of
attraction
is
a
goal
in
ethereum
to
move
away
from
eoa
accounts
right
accounts
controlled
by
private
keys
and
move
and
incentivize
smart
contract
wallet.
Adoption
specifically,
what
we're
trying
to
do
is
we're
trying
to
allow
smart
contracts
to
initiate
transactions.
B
Erc
4537
introduces
the
concept
of
user
operations.
These
are
structs,
like
you
can
see
here
on
the
right
and
they
have
12
fields.
They
specify
everything
from
where
it
should
be
routed
to
the
signature.
That's
used
if
there's
a
paymaster
and
lots
of
other
custom
fields
and
the
way
it
works
is
that
users
will
state.
B
These
can
be
anyone,
although
the
best
candidates
for
bundlers
are
miners
or
immediate
searchers.
These
bundlers
take
these
operations
and
and
place
them
on
chain
and
send
them
on
chain
via
a
specialized
contract,
called
the
entry
point,
and
this
entry
point
is
going
to
make
sure
that
the
bundler
gets
paid
for
including
the
user
operations
on
chain
and
then
execute
any
arbitrary
call
data
as
specified
by
the
user.
B
Right-
and
here
is
a
nice
diagram
made
by
vitalik,
which
kind
of
portrays
how
this
proposal
works
right,
so
there's
users
they
create
user
operations,
they
send
them
to
nodes,
and
these
get
picked
up
by
bundlers,
and
these
bundlers
are
going
to
take
these
user
operations
and
bundle
them
into
one
big
transaction
for
the
entry
point
and
include
them
as
any
other
normal
transaction
in
ethereum
block
all
right.
So
what
are
the
use
cases,
and
why
should
we
make
this
a
standard?
B
We
need
account
abstraction.
Now
there
are
many.
There
have
already
been
proposed,
many
eips
which
aim
to
achieve
a
kind
of
abstraction
such
as
2938,
and
one
previously,
I
think,
was
86
correct
me
if
I'm
wrong,
but
any
change.
Any
cases
change,
especially
with
regards
to
kind
of
abstraction,
will
take
many
years
to
actually
succeed
to
be
part
of
the
ethereum
protocol.
B
Currently,
all
ethereum
transactions
will
be
signed
by
ecdsa,
which
is
an
elliptic
curve
signature
scheme,
but
this
eip
allows
for
any
custom
signature
scheme
to
be
used
for
validating
whether
user
operation
is
valid
or
not
right.
Anything
that
you
can
write
in
a
smart
contract
can
be
used
as
a
signature
scheme,
so
this
would
allow
us
to
use
more
efficient
symmetry
mechanisms
like
bls,
for
example,
or
even
quantum
resistant
ones
already
like
lampport
or
winternets.
B
B
You
can
yeah,
as
mentioned
before,
you
can
trade
without
native
currency.
So,
for
example,
you
can
use
uni
swap
if
they
are
willing
to
sponsor
your
transaction.
You
can
use
any
other
dap
if
they
have,
if
they're
willing
to
sponsor
users
operations,
zk
mixers
rely
on
people
with
withdrawing
their
their
funds
through
a
real
air
network.
Right
now,
which
is
another
instance
of
just
lots
of
extra
work
for
not
much
benefit
while
they
could
plug
into
a
separate
interface
like
the
one
we're
creating
and
if
they
don't
want.
B
So
the
classic
problem
with
ercs
is
that
you
have
to
call
approve
and
transfer
phone
in
separate
transactions.
This
is
a
major
ux
turtle
and
since
all
transactions
will
be
made
from
a
smart
contract,
these
could
be
batched
up
into
a
single
user
operation,
and
it's
it's
decentralized
as
well.
So
all
of
the
propagation
happens
using
p2p
and
there
is
not
any
single
trusted
entity.
That's
required
for
this
to
work.
B
Incentive
alliance
right,
so
bundlers
get
compensated
for
including
user
operations
on
chain
and
in
fact
they
even
make
a
profit
doing
this.
So
so,
for
example,
by
by
allowing
any
researchers
to
bundle
these
operations,
we
can
make
sure
that
all
entities
involved
in
in
making
this
eip
happen
are
are
incentivized
monetarily
to
to
do
so.
B
B
Finally,
future
proof,
so
ethereum
we
think,
is
moving
and
should
move
in
the
future
to
a
state
where
eoas
are
phased
out
completely,
and
this
is
a
really
good
stepping
stone.
This
iep
is
a
really
good
stepping
stone
for
that,
because
eventually,
it
would
be
possible
to,
for
example,
replace
all
eoas
with
a
default
smart
contract
and
and
that's
my
contract
in
the
future
could
be
compatible
with
this
erc.
B
However,
there
are
a
few
drawbacks
that
are
important
to
mention
right
since,
since
validating
a
user
operation
relies
on
looking
at
edm
state
and
executing
evm
code,
there's
a
higher
potential
dos
vector
because
of
it
at
the
way.
It's
currently
designed
only
one
user
operation
per
center
in
the
mempo
and
the
user
operation
pool.
B
This
means
that
users,
if
they
wanted
to
send
multiple
these
operations,
would
have
to
wait
and
send
them
once
the
first
one
is
included.
And
finally,
there
is
a
gas
overhead.
There
is
a
total
of
54
000
gas
overhead
for
user
operation,
as
opposed
to
just
sending
what
you'd
like
to
do
directly
from
an
eoa.
C
So
initially
initially
we
will
go
through
the
simple
flow
where
there
is
no
paymaster
and
the
wallet
is
paying
for
a
painful
deals,
operation
itself,
so
the
bundle
creates
a
bundle
containing
a
one
or
more
one
or
more
use
operation,
and
this
is
sent
to
the
entry
point
contract.
The
entry
point
contract
is
a
single
tone.
There
is
one
on
the
entire
chain
and
this
is
what
the
bundles
use,
so
the
bundle
sends
it
to
a
sends
the
bundle
to
the
entry
point
and
the
entry
point
runs
two
loops
in
the
first
slope.
C
It
runs.
The
validation
runs
the
validation
for
all
of
the
user
operations.
They
all
run
a
they
all
run
consecutively
before
any
execution,
so
that
validations
don't
have
cross
effects
between
them.
So
what
happens?
So?
What
happens?
First
in
the
in
the
first
loop
is.
The
entry
point
calls
the
wallets
validation
function,
which
each
wallet
each
wallet
must
eat.
What
it
must
must
happen.
It
must
have
before.
C
So
the
wallet
verifies
the
signature
and
it
also
handles
the
replay
replay
protection
which
can
be
incrementing
the
nonce.
So
the
nonce
is
actually
part
of
the
wallet
storage.
Now
it
can
increment
the
non
so
it
can,
it
can
use
a
different
reproduction
schemes
and
finally,
it
pays
for
it
if
it
validates
the
transaction
the
operation
and
thinks
that
it's
a
okay,
then
it
pays
the
entry
point
for
the
maximum
cost
of
the
transaction.
C
This
is
similar
to
the
way
eoas
work
where
initially
the
maximum
cost
of
the
transaction
is
called,
is
a
charged
and
then
refunded.
So
at
this
point
the
wallet
pays
the
maximum
amount
and
returns.
And
now,
if
the
wallet
returned,
okay
and
didn't
revert
to
this
point,
then
entry
point
proceeds.
It
does
this
for
all
the
wallets
after
it's
done
after
after
it's
done,
we
get
to
the
execution
stage
at
this
stage.
C
This
is
a
this
is
the
second
loop
in
this
loop,
each
and
in
this
loop
the
wallets
operation
is
actually
executed,
so
it
calls
the
it
calls
the
wallet
with
the
call
data
from
the
user
operation
struct,
and
this
can.
This
can,
for
example,
call
an
execute
function
in
the
wallet
where
the
wallet
will
perform
certain
internal
operations
or
it
will,
or
it
will
act
as
a
proxy
and
perform
operations
on
any
contract
on
the
chain
and
after
each
operation
and
after
each
operation.
C
In
this
case,
entry
point
looks
at
the
entry
point,
looks
at
the
us
operation
and
it
says
that
it
says
that
there's
a
paymaster,
so
it
still
calls
the
wallet,
validation,
the
wallet
validation,
but
but
it
tells
the
world
validation
that
it
needs
to
pay
zero
for
the
gas.
So
the
gas
payment
will
come
elsewhere
from
elsewhere.
C
The
one
the
the
wallet
still
performs,
the
signature,
verification
and
then
and
the
nons
and
the
announce
increment
or
whatever
replay
protection
it
implements,
but
it
doesn't
pay
it
just
returns.
Okay,
then,
the
entry
point
checks
if
the
paymaster
is
is
valid,
which
means
that
it
needs
to
be
staked
and
I'm
going
to
elaborate
on
the
on
why
this
stake
is
needed
and
how
it
is
used
later
in
the
security
consideration.
C
C
Then
it
calls
the
paymasters
validation
function,
which
so
the
paymaster
also
gets
to
look
at
the
other
operation
and
decide
whether
it's
willing
to
pay
for
it.
And
if
it's,
if
it
sees
that
it's
something
it
is
willing
to
pay
for,
then
it
will
return
okay,
otherwise
it
will
revert
in
this
validation
function.
It's
supposed
to
check
certain
things
such
as
it
can
be
a
white
list
of
certain
users
or
it
can
be.
C
C
Now
the
wallet
operation
is
a
perform
just
like
in
the
previous
case
and
after
the
execution
completes
after
the
execution
completes,
and
the
entry
point
calculates
the
actual
cost
of
the
transaction
and
deducts
it
from
the
from
the
deposit
of
federal
paymaster.
Each
paymaster
has
a
deposit,
so
the
cost
of
the
transaction
is
deducted.
C
So,
for
example,
for
example,
if
it's
a
talking
paymaster,
then
at
this
point
it's
going
to
charge
the
at
this
point:
it's
going
to
charge
the
user,
because
it
now
it
knows
exactly
how
much,
how
much
it
paid
for
the
how
much
if
it
paid
for
the
gas,
so
it
can
calculate
you
can
calculate
an
amount
and
charge
the
user.
Somehow
and
that's
it,
that's
how
the
and
so
that's
how
the
operation
works
in
case
of
a
paymaster.
C
Yeah,
thank
you
so
so
in
order
to
provide
all
of
these
services
the
entry
point,
the
entry
point.
Singleton
contract
needs
to
implement
some
interfaces
for
serving
the
three
entities
involved.
The
first
entity
is
a
bundler
and,
as
we
said,
the
bundler
can
be
a
miner
or
blog
proposer,
but
it
could
also
be
an
independent
bundler
so
and
the
bundler
the
bundler
prepares,
the
the
bundler
prepares
the
bundle
during
bundling.
It
means
the
unbound
league.
It
first
uses
the
simulation
function,
which
is
called
off
chain.
C
This
is
a
view.
Function
called
the
simulator
and
simulated
validation,
it
receives
a
single
user
operation
and
it
checks
it
against
the
current
state
to
make
sure
that
to
make
sure
that
it
is
safe
for
inclusion,
and
this
can
be
done
a
pair
op,
because
since
all
the
ops
are
all
those
operations
are
checked
I'll
check
before
any
before
any
execution,
they
have
nowhere.
They
have
no
way
to
affect
each
other.
Therefore,
it's
okay
to
simulate
each
of
them
and
add
it
to
the
bundle
and
then
after
and
and
then
afterwards
it
estimates
the
gas.
C
It
uses
estimate
gas
to
check
the
entire
bundle
to
see
how
much
does
it
should,
it
should
add,
and
it
sends
it
on
chain
to
the
handle
ops
to
handle
ops.
The
handle
ops
interface
is
a
runs,
the
two
loops
that
I
described
before
and
actually
performs
the
work.
So
this
is
what
so.
This
is
this.
This
is
what
the
bundler
uses
another
another
entity
that
uses
the
entry
point
is
the
paymaster,
so
the
payment
still
needs
to
maintain
a
stake
which
again
I'll
elaborate
on
later,
which
means
that
we
need
to.
C
We
need
to
have
functions
for
managing
the
stake.
This
means
adding
the
being
able
to
add
to
add
a
stake
and
say
what
the
unstaked
delay
is
and
then
there's
the
unlock
stake
for
unlocking
the
for
unlocking
the
stake
and
once
the
once
the
paymaster
unlocks
the
stake.
It
stops
being
a
valid
paymaster
and
then,
after
the
delay
it
can,
it
can
call
withdrawal
stake
in
order
to
withdraw
the
without
a
stake,
and
the
third
thing
is
the
deposit,
so
both
wallets
and
paymasters
can
have
a
deposit.
C
Paymaster
must
have
a
deposit,
and
if
that
and
the
deposit
is
where
entry
point
actually
charges
the
gas.
So
a
paymaster
must
have
a
sufficient
deposit,
a
massive
sufficient
deposit
and
and
after
it
accepts
the
payment
and
the
operation
is
done.
This
deposit
is
charged
and
wallet
wallet
can
have
a
deposit
or
can
pay
directly,
but
there
is
some
gas
saving.
If,
if
the
wallet
there
tops
up
this
deposit
because
it
saves
the
need
for
some
time
for
a
transfers
inside
your
operation,
so
in
order
to
manage
the
deposit
we
have
a
balance
of.
C
C
And
now
wallets
and
paymasters,
I
can
do
pretty
much
whatever
they
they
want,
but
they
need
to
implement
certain
interfaces.
The
wallet
only
needs
one
interface,
it
needs
the
it
needs
a
validate
user
op.
This
is
the
validation
function,
which
is
called
during
the
first
loop
and
this
function.
This
function
should
look
at
the
other
operation.
C
Verify
then
verify
the
signature
using
whatever
signature
scheme
it
uses,
which,
in
our
current
sample,
just
uses
a
recover
for
ecdsa,
and
it
should
also
handle
the
it
should
also
handle
the
norms.
Okay,
increment,
the
norms
in
the
simple
case,
and
finally,
it
needs
to
pay
the
missing
wallet
funds.
So
missing
wallet,
funds
missing
wallet
funds
is
what
entry
point
calculates
to
be:
the
missing
the
missing
funds
for
the
maximum
cost.
If
the
wallet
already
has,
if
the
wallet
already
has
sufficient
balance
in
the
deposit,
then
this
number
will
be
zero.
C
Also,
if
the
if,
if
there
is
a
paymaster,
this
number
will
always
be
zero
if
the
user
operation
has
a
paymaster.
Otherwise,
this
number
will
reflect
the
funds
missing
from
the
deposit
in
order
to
accept
to
accept
use
operation,
and
afterwards
there
are
no.
There
are
no
more
interfaces
for
the
wallet
because
they
were
just
going
to
call
it
with
the
call
date
of
this
operation.
C
The
paymaster
needs
to
implement.
It
must
implement
a
validation
function.
This
is
the
validate
master
user
up.
This
validation
function
is
a.
This
is
a
view
function
because
it
doesn't
actually
need
to
pay.
It
must
have
a
deposit
anyway,
so
it
only
checks
the
it
only
checks
the
us
operation
to
see
if
it
should
pay
for
it
and
it
can-
and
it
can
optionally
have
a
post-op
in
case
it
wants
to
perform
any
to
perform
any
bookkeeping
or
charge
the
user
at
the
end
of
the
operation.
C
C
So
probably
the
most
important
thing
in
this
in
this
proposal
is
the
security
considerations
and
we
have
some
security
considerations
around
the
smart
contract
and
others
around
the
mempool.
So,
let's
start
with
the
smart
contract.
The
entry
point
is
the
entry
point
is
trusted
by
everyone.
It
is
trusted
by
bundlers
to
properly
compensate
them
for
a
for
the
bundle
it
is
trusted
by
the
wallets,
most
importantly,
because
the
wallet
fully
trusted
to
execute
to
execute
operations
on
behalf
of
the
wallet
say
owner.
C
C
I'm
not
going
to
go
through
the
entire
list
here,
but
it's
a
we
can
go
back
to
it.
If
a
question
is
required
and
then
the
other
security
considerations
are
dos.
The
os
ordinal
of
service
attacks
against
the
nodes
and
the
bundlers,
and
as
christoph
mentioned
there
is
an
increased
there-
is
increased
input
and
exposure
to
the
amount
of
service.
C
This
is
because
the
this
is
because
the
evm,
because
we
require
a
evm
state,
require
actual
evm
execution
in
order
to
determine
the
user
operation
validity,
and
this
allows
a
certain
dos
vector.
What
happens
if
what
happens
if
an
attacker
creates
a
very
large
and
a
very
large
number
of
valid
user
operations
which
are
valid
at
the
time
when
they
are
submitted
to
whether
submitted
into
the
mempool
but
then,
but
then
with
a
single
state
change
or
even
with
no
change
at
all.
C
By
looking
at
something
like
the
block
number
for
the
block
time,
it
could
invalidate
it
couldn't
validate
in
all
of
the
orbs
at
once,
and
in
this
case
the
bundlers
will
have
to
re-simulate
each
of
the
ops
in
order
to
in
order
to
drop
them,
and
this
is
a
lot
of
unpaid
work.
It
could
even
it
could
even
stall
the
bundle
for
a
long
time
making
it
a
miss
block.
C
We
so
we
have
so
we
have
a
many
mitigations
against
it.
We
can
establish
in
the
next
slides,
we'll
see
them
one
by
one.
The
first
line
of
defense
is
the
validation
gaz.
The
validation
validation
represents
a
risk
of
unpaid
work
for
the
full
burner
for
the
for
the
bundler,
and
it
also
creates
a
load
on
all
the
nodes
on
all
the
nodes
in
the
mempool
because
they
may
be,
they
may
be
simulating
the
entire.
They
may
be
simulating
the
entire
operation.
C
C
It
can
still,
it
can
still
be
used
with
a
private
bundler
or
even
by
the
user,
submitting
a
bundle,
a
bundle
directly
as
a
transaction,
but
but
then
but
the
bundlers
and
the
mempool
will
not
serve
it
and
finally,
entry
point:
the
entry
point
will
enforce
this
gas
limit.
So
if
the
validation
actually
requires
more
requires
more
than
that,
then
this
this
op
will
fail.
C
C
We
need
to
make
sure
that
the
only
thing
the
only
thing
that
can
invalidate
an
op
is
a
change
in
this
in
its
own,
in
the
state
of
the
in
the
state
of
the
wallet
it
shouldn't
be
affected
by
the
environment,
because,
for
example,
if
if
the
validation
function
would
would
be
allowed
to
look
at
the
to
look
at
the
block
number
or
the
the
block
number
or
the
time
or
even
something
like
a
gas
price,
then
it
is
then
it
could
be.
Then
it
could
become
inconsistent.
C
So
it
will
succeed.
It
will
succeed
during
simulation
and
then
later
fail
when
it
is
when
it
is
bundled.
So
we
we
had
to
ban,
we
had
to
ban
all
of
the
environment
of
codes
and
the
so
all
of
the
ones
listed
here
are
a
band.
There
is
one
special
case
of
a
create
to
create
tool
and
create
two
is
also
used
for
creating
the
for
creating
the
wallet
if
it
doesn't
exist
yet,
but
in
this
case
the
user
has
to
specify
in
a
specify
an
init
code
for
the
wallet.
C
And
this
leaves
us
with
the
storage
access,
so
we
need
to
make
sure
that
a
single
state
change,
a
single
state
change
shouldn't
be
able
to
invalidate
a
large
number
of
user
operations.
It
should
only
invalidate
a
single,
a
single
one,
so
we
do
it.
We
do
it
by
enforcing
that
the
wallet
that
a
wallet
validation
function
is
only
allowed
to
access
the
wallet
storage.
It
cannot
access
the
storage
of
any
other,
and
so
so
we
enforce
say
we
enforce
that,
and
this
is
complemented
by
a
rule
that
says
user.
C
So
then,
so,
with
this
limitation,
combined
with
the
storage
with
the
storage
limitation,
it
means
that
the
damage
of
I
mean
the
amount
of
work
caused
by
a
single
stage.
Change
is
limited
to
one
op,
and
this
limitation
is
this
limitation
may
be
maybe
a
a
ux
problem
because
the
user
might
want
to
send
more
than
one
more
than
one
operation,
but
this
can
be
solved
by
by
batching.
C
Then
the
wallet
can
implement
its
own
internal
batching,
so
you
can
send
the
user
operation
that
actually
wraps
multiple
operations
and
it
can-
and
you
can
also
replace
the
existing
one
by
fee,
just
like
a
replace
by
fee
for
a
current
transactions
and
payment
payment.
Validation
also
has
a
similar
restriction
where
the
paymaster,
the
paymaster,
should
only
access
its
own
storage.
C
But
this
is
not
sufficient
because,
unlike
unlike
wallets,
that
can
only
have
one
op,
a
paymaster
can
have
a
large
number
of
can
have
a
large
number
of
ops
that
that
it
affects.
Therefore
we
needed
a.
We
need
a
reputation,
a
reputation
system
where
we
can
throttle
and
ban
a
paymasters
that
cause
too
much
unpaid
work,
and
this
is
where
the
this
is
where
the
stay
comes
in.
C
We
needed,
first
of
all,
to
create
a
sibling
resistance
mechanism,
so
paymasters
must
lock
a
stake
and
they
have
an
unstaked
delay
if
it,
if
a
paymaster
in
order
for
a
paymaster
to
be
valid,
it
must
lock,
and
it
must
lock
a
lock
some.
If
and
this
it
has
to
remain,
it
has
to
remain
locked
once
it
and
once
it
gets
unlocked
display,
master
is
no
longer
considered
valid
and
any
object
specified.
It
will
be
dropped.
C
Now,
no
can
can
you
go
back,
please
thank
you.
So
this
is
so.
This
is
the
zebra
resistance,
but
so
this
is
a
civil
resistance,
and
now
now
that
we
have
now
that
we
can
have,
we
have
sible
resistance.
We
can
have
reputation
so
we
calculate
it
by
using
and
by
calculating
an
exponential
moving
average
that
tracks
the
paymaster
inclusion
rate.
This
means
that
this
means
that
we
divide
the.
C
We
divide,
the
number
of
with
the
number
of
ops,
actually
the
ops
included
within
by
the
number
of
the
ops
that
were
seen
so
so
this
is
the
inclusion.
This
is.
This
reflects
the
inclusion
rate
and
this
rate
must
be
kept
sufficiently
high.
If
it
drops
below
a
certain
point,
then,
if
it
drops
below
a
certain
point,
it
means
that
the
paymaster
is
causing
too
much
unpaid
work,
so
it
will
get
throttled
and
eventually,
if
it
keeps
doing
that
it
will
get
banned.
C
Now
this
this
is
a
temporary
situation,
because
this
is
a
temporary
situation
due
to
the
moving
average.
But
if
the
pay
master
keeps
misbehaving
that,
then
every
time
it
gets
unbanned
it
will
just
a
it
will
it
will
get
banned
again
quickly,
so
it
can't
cause
too
much
work.
If
an
attacker
tries
to
do
something.
C
B
B
However,
we
believe
that
the
most
one
of
the
most
effective
bundler
candidates
are
the
miners
themselves,
so
at
nethermind
we've
implemented
all
of
this
logic
that
we
have
described
previously.
It's
part
of
the
neighborhood
client.
Now
it
contains
logic
for
the
mempool
of
the
separate
mempool
for
the
p2p
propagation.
B
We
have
the
separate
p2p
specification
specifically
for
user
operations
and
also
does
batching,
and
it's
currently
running
live
on
gurley
already.
So
after
this
present
after
presentation,
we'll
send
you
a
link
that
I
guess
you
can
include
for
the
viewers
where
we
already
made
a
guide
on
how
it's
possible
to
send
an
easy
operation
to
our
gurley
bundler.
B
We
also
have
a
working
implementation
with
the
gef
client,
specifically
mevgef
for
now,
but
we're
also
going
to
port
it
to
normal,
vanilla
gaff,
as
mentioned
before,
a
cool
part
of
the
disposal
is
that
since
anyone
can
be
a
bundler,
we
don't
need
mine
like
complete
minor
support.
Initially,
we
don't
even
need
any
to
begin
with,
because
if
the
user
operations
are
profitable
enough,
we
can
very
reasonably
expect
that
mev
searchers
are
going
to
be
prime
candidates
to
include
user
operations
as
well.
B
So
it's
very
feasible
to
to
have
a
an
mvv
searcher
script
which
just
subscribes,
which
just
runs
runs
a
node
another
mind
or
a
gef
note
that
we've
forked
and
just
subscribes
to
new
user
operations
entering
the
pool
takes
these
operations
checks.
If
they're
profitable
enough,
the
node
will
have
already
checked
whether
they
succeed
or
not.
B
So
that's
going
to
check
that
again
and
as
they
do,
they
just
submit
it
on
chain
as
fast
as
they
can
hopefully
competing
with
other
mev
searchers
do
the
same
thing
and
since
meeb
searchers
are
very
competitive
and
we
can
expect
that
this
will
result
in
very
high
rates
of
easy
operation.
Inclusion
even.
C
B
Very
beginning,
so
here
are
a
few
links
that
might
be
interesting.
We
have
the
proposal
itself.
Vitalik
wrote
a
blog
post
a
few
months
ago
detailing
how
this
proposal
works
as
well.
We
have
a
discord
channel
that,
if
you're
interested
in
the
proposal,
we'd
love
for
you
to
to
join
and
finally
the
link
for
the
contracts
as
well
the
smart
contracts.
A
D
Sure
so
yeah
amazing
presentation,
there
was
one
thing
I
did
want
to
ask
which
is
actually
kind
of
meta
about
the
about
the
eip
itself,
which
is
this
is
an
erc.
It
seems
because
I
mean
you
focused
on
the
contract
quite
a
bit
here,
but
is
there
also
going
to
be
an
eiep
about
the
network,
because
I
mean
a
lot
of
this
also
seems
contention
on
the
kind
of
led
p2p
network
that
that's
being
specified
here.
So
is
there
a
specification
for
that?
Is
it
going
to
be
a
separate
eip
like?
B
D
Yeah,
I
think
it
does.
I
mean
I
guess
this
is
an
interesting
kind
of
eiep.
One
question
which
is
like
if
you
have
one
eiep,
which
is
specifying
something
with
just
both
contract
standard
like
an
app
layer,
standard
and
a
networking
standard,
so
then
like
where,
where
does
it
go?
But
I
mean
that
I,
I
guess
that's
something
for
the
squad
of
eiep
editors
to
decide
on
so
okay,
I
I
did
want
to
add,
like
I
maybe
try
and
nudge
a
bit
also
about
the
the
ptp
specification.
D
B
A
A
We
know
that
there
are
a
couple
of
other
eips
in
the
eip
repo
for
account
abstraction
eip86,
so
that
was
abstraction
of
transaction
origin
and
signature,
and
there
is
another
one:
eitip
2938
account
abstraction
yeah,
but
for
some
reason
they
both
ended
up
as
stagnant.
So
it
is
interesting
to
learn
what
aip4337
has
to
offer.
A
C
Yes,
so
so
the
difference
is
when
looking
at
the
proposals
like
eap
2938,
for
example,
it
serves
itself
a
very
similar
purpose
and
it
could
solve
the
same
use
cases.
But
as
we
all
know,
it's
really
hard.
I
mean
making
such
a
big
change
as
an
eap
is
something
that
takes
a
long
time
very
hard
to
wear
to
get
it
for,
and
we
thought
that
it
may
be
beneficial
first
of
all
to
have
something
earlier
and
also
seen,
and
also
it
allows
us
to
start
to
start
by
experimenting.
C
So
it's
something
that
we
can
deploy
right
away.
We
can
start,
and
people
can
start
expanding
experimenting
with
the
model
and
now
the
end
game.
Even
eventually,
we
will
want
a
account
abstraction
to
happen
at
the
protocol
level.
So
in
the
future
there
will
I
mean
in
the
future.
If
we
get
adoption
for
for
this
proposal,
we
should
have.
C
C
A
C
Also
know
that-
and
we
also
know
that
for
in
the
next
couple
of
hard
forks,
we
will
not
be
able
to
add
to
add
such
changes
and
it's
first
we
have
the
merge
and
then
we
need
to
add
the
withdrawals
and
then
there's
going
to
be
and
the
vehicles-
and
you
know
there's
so
much
going
on
that.
I
think
if
we
had
to
wait
for
a
consensus
change,
then
probably
it's
more
than
a
year
away.
A
C
And
so
on,
so
we
haven't
really
started
experimenting
with
the
mempool,
because
there
is
no.
You
know
there
is
a.
There
is
no
traffic
yet
because
it's
just
I
mean
it's
currently
only
on
test
net,
but
we
have
the
so
we
have
the
restrictions
that
we
talked
about.
The
we
have
had
restrictions
there
to
protect
the
mempool
and-
and
so
hopefully
so,
hopefully
the
experience
will
be
similar
to
using
the
to
using
the
current
mempool.
I
don't
know
a
christopher,
do
you
have
any?
A
That
makes
sense
I
mean,
maybe
when
it
is
on
main
net,
then
the
like
the
status
will
be
more
clearer
if
it
was
useful
or
not
all
right.
Let's
talk
a
little
bit
about
wallet
implementation.
It's
evident
that
this
proposal
is
mainly
useful
for
wallets
and
d5
and
similar
projects
you
did
mention
about
like
upgradeability
right.
The
old
water
wallets
can
be
upgraded.
A
C
Yes,
so
so,
as
you
saw,
the
the
wallet,
the
signature
is
just
an
the
entry
point
is
agnostic
to
the
signature
type.
It's
actually
just
a
byte.
It's
actually
just
a
byte
array
that
we
passed
to
the
validation
function,
so
it
is
entirely
up
to
the.
It
is
entirely
up
to
the
wallet
to
the
contact
wallet
to
decide
what
to
do
with
the
signature.
It
just
need.
C
It
is
given
the
request
id,
which
is
the
hash
which
covers
the
hash
of
the
entire
operation,
the
chain
id
and
the
entry
point
address,
and
then
and
it's
given
the
signature.
Now,
this
signature
could
be,
for
example,
a
multisig.
It
could
be
multiple
signatures
or
an
aggregated
signature
or
any
or
any
such
solution,
and
as
long
as
the
contract
knows
how
to
verify
it,
that's
fine.
C
So
let's
say
you
had:
let's
say
you
were
using
the
default
simple
wallet,
the
one
that
just
just
checks,
a
ecdsa
signature,
and
then
you
want
to
switch
to
a
multi-sig.
Then
all
you
need
to
do
is
to
set
the
implementation
of
your
wallet
in
place.
You
know
the
same
as
the
same
address
you
set
the
implementation
to
a
new
one
where
the
validation
function
is,
is
a
multisig
that
you
manage
in
the
wallet
you
can
implement.
A
C
B
C
A
A
C
Yes,
so
here
it's
important,
it's
important
to
distinguish
between
risks,
to
the
wallet
to
the
wallet
or
paymasters
and
risk
to
the
bundler,
and
then
we
don't
rely
on
higher
level
infrastructure
for
protecting
the
for
protecting
the
user,
because
this
would
make
the
bundlers
a
trusted
party
and
they
are
untrusted.
They
are
essentially
miners,
so
the
security
is
enforced
by
is
enforced
by
the
entry
point
contract,
which
makes
sure
that
makes
sure
that
wallet
operations
only
happen
if
they
were
properly
authorized
by
the
user
and
validated
by
the
wallet.
C
We
don't
need
to
wait
for
the
next
hard
fork
in
order
to
fix
it,
we
could
immediately
deploy
a
new
entry
point
and
the
wallets
can
start
switching
to
it.
This
is,
of
course,
an
opt-in
process,
so
all
the
wallets
should
have
other
wallets
should
have
a
set
entry
point
function
where
they
can
change
their.
They
can
switch
to
a
different
entry
point
if
they,
if
they
see
fit
so,
and
the
thing
that
is
in
that
is
enforced
by
the
higher
level
infrastructure
is
the
protection.
C
B
When
it
comes
to
protecting
them,
the
bundlers
we've
we've.
Basically,
we
believe
we
covered
all
our
bases
right,
but
that's
the
cool
thing
about
this
about
having
an
erc
as
opposed
to
a
consensus,
changing
eip
that
it'll
be
very
since
there's
a
slow
rollout,
we'll
be
able
to
see
and
and
and
change
things
if
needed.
We
don't
think
any
changes
will
need
to
the
mental
behavior,
but
but
it
will
be
possible.
A
C
Yes,
of
course,
so
we
included
the
chain
id
in
the
signed
message,
we're,
including
the
signed
message
to
ensure
that
the
other
operation
cannot
be
replayed
on
other
chains.
On
maybe
I
mean
if
someone
if
someone
was
looking
at
an
earlier
version
of
this
of
this
elc
in
an
earlier
version,
we
actually
forgot
to
write
it
in
the
elc,
despite
having
it
in
the
code
from
a
from
the
start,
so
where
we
added
it,
so
we
added
it
later
now.
C
The
reason
it
is
the
reason
it
is
it
is
needed
is
that
a
replay
on
a
a
replay
on
a
different
network
could
have
a
could
have
unexpected
could
have
unexpected
the
effects.
For
example,
let
me
give
an
example
since,
since
the
create,
since
the
create
op
code
doesn't
when
it
creates
a
new
contract,
it
only,
it
only
depends
on
the
deployer
address
and
the
nonce
not
on
the
code.
Unlike
a
create
tool,
the
same
deployer
could
actually
create
different
contracts
at
the
same
address
of
different
chains
right.
C
So
so,
let's
suppose
that,
let's
suppose
a
user
and
a
user
signs
a
trade
to
a
new
dex,
let's
call
it
a
sashimi
swap
and
there's
and
sashimi
swap-
is
a
it's
a
great.
It's
a
great
project.
It's
running
on
an
ethereum
and
the
the
user
uses
it
to
trade,
to
sign
a
trade
trading
if
to
die
and
later
the
same
deployer.
The
sashimi
swap
deployer
uses
the
same
deployment
key
to
deploy
a
simple
proxy
contract.
At
the
same
address
of
the
the
same
address
of
the
that
it
used
for
the
dex
on
ethereum.
C
Now
it
does
it
does
that
on
a
polygon
and
the
user
happens
to
also
be
holding
assets
on
polygon
in
the
same
in
his
address
there.
So
now,
the
now
the
deployer
can
replay
the
user
operation
on
polygon,
which
would
transfer
the
user's
matic,
which
is
because
it
was
transferring
ethernet.
It
was
transcending
ethernet
ethereum,
so
it
will
now
try
to
transfer
the
user's
matic
to
the
proxy
attempting
to
trade
against
this
proxy
and,
of
course
the
proxy
is
not
going
to
give
to
give
any
die,
but
it's
going
to
keep
them
attic.
A
Right
that
makes
a
lot
of
sense
because
this
is
like,
but
not
prefer,
ethereum,
and
this
also
allows
to
use
any
other
token
defining
chain
id
as
a
lot
of
value.
Here
I
have
a
question
related
to
pay
master.
It
seems
to
me
like
some
of
the
use
cases
those
were
proposed
by
eap
3074
are
already
being
provided
with
this
proposal
with
the
help
of
pay
masters.
So
do
you
think
that
3074
will
not
be
needed
if
we
have
this
proposal
on
board.
C
I
think
phil
3074
made
a
different
made
with
different
trade-offs,
because
it's
an
eap,
so
it's
you
know
it
supports.
It
supports
pretty
much
the
same
use
cases
you
could
do
a
you
could
do
everything
that
everything
you
can
do
with
this.
You
can
also
do
it,
the
ap
3074
and
vice
versa,
but
the
difference
is
that
the
difference
is
that
3074,
first
of
all,
it
requires
a
hardware,
requires
consensus,
change
and
then
it
also
enshrines
the.
C
It
also
enshrines
the
the
eoa
model
which
we're
trying
to
eventually
move
away
from,
so
we're
trying
to
we're
trying
to
create
something
here
that
that
can
that
can
be
native
like
natively,
you
say
these
contracts,
it's
now
it
can
so
like
I
said
it,
can
it
can
say
it?
Can
you
could
write
a
you
could
write
paymasters
with
3074.,
but
there
would
be
some
security.
C
There
will
be
some
security
risk
involved,
because
when
you
sign
a
when
you
sign
an
off
for
a
for
an
invoker
for
when
for
a
30-74
invoker,
you
have
no
way
to
ever
revoke
it.
It's
like
it's
that
you
are
adding
game,
you're,
adding
modules
to
your
wallet
and
these
modules
that
you
keep
collecting
them.
You
can
never
uninstall
them
and
later
if
a
bug
is
found
in
any.
If
a
bug
is
found
in
any
such
paymaster
in
any
such
invoker
that
is
used
as
a
paymaster,
then
it
can
be.
C
It
has
a
long,
lasting
effect.
It's
going
to
affect
your
wallet
forever,
so
you
need
to
to
switch
to
another
address
immediately,
whereas
with
the
37
with
the
with
4.37
the
paymaster.
Can
the
pay
must
tell
only
affects
you
in
the
current
user
operation.
He
doesn't
get
any
authorization
to
do
anything
on
your
behalf.
It
only
pays
for
the
gas
and
if
there
is
a
and
if
a
bug
is
if
a
bug
is
found
in
a
paymaster,
you
can
just
stop
using
it.
B
C
There
is,
there
is
a
there
there
are.
There
are,
of
course,
some
pros
to
a
3074,
which
must
be
mentioned
so
first
of
all,
first
portfolio
with
it
would
be
easier
for
users
to
start
using
immediately
with
their
existing
eoa
and
second
and
second,
there
is
less
gas
overhead.
As
christophe
mentioned,
there
is
gas
overhead
there.
There
is
gas
over
at
the
in
entry
point
which
you
wouldn't
have
to
incur
when
using
a374.
B
Yeah-
and
I
think
it's
also
important
to
mention
that
there's
also
a
philosophical
difference
between
374
and
three
457.,
so
the
question
we
have
to
ask
ourselves
is
which
type
of
account
do,
which
type
of
wallet
do
you
want
to
incentivize
for
ethereum
to
use?
Do
you
want
to
incentivize
eoas,
or
do
you
want
to
incentivize
smart
contract
walls,
and
we
believe
that,
for
the
most
part,
smart
contract
wallets
are
the
future
of
a
theorem
and
that's?
B
A
C
C
B
C
Right,
that's
correct.
The
merge
should
not
affect
the
merge
happening
at
the
consensus
level
should
not
affect
this,
because
everything
we
do
here
is
done
at
the
execution
level
and
we
don't
use
the
difficulty
which
is
replaced
with
random,
so
yeah.
It's
I
don't
I
and
what
and
of
course
the
bundlers.
We
will
then
be
blog
proposers,
which
will
make
this
say
far
more
already
centralized.
C
A
All
right
yep,
all
right.
That's
all
on
that
part.
I
think
I
have
one
last
set
of
question
related
to
eip
status.
It
seems
like
people
have
already
started
implementing.
I
know
we
just
discussed
about
nether
mine
implementation.
I
wonder
as
co-authors
would
you
think
will
be
needed
to
move
the
proposal
to
the
review
status.
C
They
are
being
audited
right
now,
so
hopefully,
in
the
next
few
weeks,
after
after
finishing
the
after
finishing
the
post
audit
fixes
it's
going
to
be
it's
going
to
be
deployed,
it's
going
to
be
deployed
on
a
or
the
networks
and
on
the
and
on
the
client
side.
Kristoff
can
elaborate.
We
are,
but
nevermind
is
so.
Nettleman
has
been
working
on
it,
not
just
for
the
netherlands
client,
but
also
on
the
also
on
geth.
B
C
Yeah,
and
and
also
on
the
implementation
of
things
on
top
of
this
erc,
first
of
all,
you
can
you
have
so
there's
a
samples
directory
in
the
contracts
showing
a
few,
a
few
walking
paymasters
and
a
wallet,
and
there
are
already
wallets
and
all
its
words
that
they
built
pocs.
On
top
of
that,
for
example,.
B
Yeah,
of
course-
and
it
makes
a
little
difference
for
these
potential
world
users-
whether
this
eip
is,
is
audited
right,
so
we
expect
it.
After
all,
this
is
complete.
There's
gonna
be
a
lot
more
willingness
to
to
make
in
the
future
production
ready
versions
as
well.
Gnosis
safe,
also
experimented
with
this
eip,
for
example,.
C
C
C
A
Right
so
erc
basically
is
a
standard
track
eip
with
erc
as
a
category.
There
are
four
standard
track.
Eips
and
erc
is
one
of
those,
so
it
basically
follows
whatever
is
there
for
eips,
except
it
does
not
need
to
be
deployed
in
all
the
clients
at
same
time
it
has
to
be
on
the
project
level,
the
application
level,
and
it
can
be
done
independent
of
that.
However,
the
process
of
a
status
change
means
similar
thing
like
for
code,
networking,
interface
and
erc.
A
That
means
when
a
proposal
is
like
in
discussion
or
early
stages,
we
can
keep
it
in
draft
when
you
think
that
it
is
ready
for
community
review.
More
wider
eyes
should
be
looking
into
the
proposal.
Then
we
move
it
to
review.
Then
eip
editors
consider
it
more
serious
and
once
it
is
like
in
completely
ready-
and
you
think
that
now
we
don't
need
to
change
any
spec
and
everything
is
documented.
Well
documented.
We
have
all
the
references
added,
then
you
can
push
it
to
last
call
other
than
last
call.
There
is
no
wait
time.
A
Last
call
generally
has
wait
time
of
14
days.
It
has
to
be
there
for
14
days
and
unless
it
passes
that
time
period,
you
cannot
push
it
to
final,
but
once
that
is
over
it
is.
It
is
on
the
author
to
push
the
proposal.
Let's
create
a
pull
request
to
move
it
to
the
final
status,
so
we
are
trying
to
move
proposals
to
final
status
as
much
as
possible
and
we
are
discouraging
people
using
it
unless
that
is
in
the
final
status.
A
A
C
A
Thank
you
so
much
generally
speaking,
account
abstraction
is
a
key
concept
in
ethereum
and
there
are
multiple
proposals
suggesting
how
to
make
best
use
of
data.
I
hope
information
shared
today
will
help
the
community
have
a
better
understanding
of
account,
abstraction
and
also
help
move
eip
4337
to
become
a
standard
for
better
usage
of
that.
That
means
projects
and
decentralized
application
implementing
it
in
their
own
project.
A
Thank
you
and
christoph
for
taking
our
time
to
provide
an
overview
thanks
to
all
our
youtube
viewers
for
watching,
be
sure
to
follow
the
discussion
to
link
provide
feedback
to
the
eip
check
out
the
youtube
description,
links
for
all
related
links.
We
will
try
to
add
the
discard
and
other
information.
Those
are
shared
in
the
slides
in
the
description
for
you
to
be
reaching
out
to.
Should
you
have
any
question
on
this
or
any
other
proposal?