foreign
[Music]
gas station network but recently we're
working with your Weiss which was
supposed to pass this presentation but
he's sick in the hotel so we are
covering him up we'll talk about account
obstruction and the
what can be done with it first what is
account obstruction but before we talk
about his account obstruction what is an
account on ethereum
account comes in two flavors one of them
is externally on account but we all know
in the other are contract based accounts
and if you have a wallet you're probably
using an UI account
UI accounts are very easy to start to
work with but they have quite a few
limitations
first of all key management is very very
problematic the private key is tightly
coupled with the address which means you
can change it you have to keep it secret
because if you lose it you lose
everything but if you make copies in
order not to lose it someone can find it
and then he will get everything and you
will lose everything so Key Management
is hard
there's also there's one one fits all
access control you can do everything it
might be good for you for personal usage
that you can do everything but it is
very very limiting if
you know a
all these operations by abstracting them
away we mean it is not the node that
performed operation that checks the
signature that checks the the security
of the node check the balance perform
the payment but we abstract it away and
make a contract the wallet contract
being responsible for all of these
so
the key management becomes simpler
because the world can do a key
management by itself a Access Control
mechanism if we want the Gas payment he
does
a lot of things become easier but just
the easiest way to think about this is
making contracts while contracts first
class citizens they're no longer
second-class citizens of ethereum and
that you don't need an eoa in order to
operate your contract wallet right you
can start from a contract wallet and
you'll never need to have an eoa
okay from now when we're talking about
the contextraction now we're talking
what can be done with it now with the
next slide with all the features none of
them are implemented by us they are
about to be implemented by you we only
open the door with accounts in order to
be able to add all these cool features
so
the first use case is recovery right now
the recovery sucks you can't recap your
private key you can't really recover it
you have to save this private key
somewhere as a multiple funny words or
otherwise
with account obstruction you can
Implement into your wallet social
recovery or other recovery mechanism
and you can add a Deadman switch like if
I'm unfortunately or someone is about
died and you don't want everyone to lose
all the the assets he has it can set a
Deadman switch that is after a period of
time that he's not using the account
someone else uh
will inherit this account this I can
multi-sake that your family controls but
it only becomes active a year after your
you know your your key is is not active
yes we're talking about recovery but
multisig of course when you're talking
about a signature cases multisig is a
uh something that we see we want to have
for accounts another option is per
device Keys you might want your phone
your phone is a very strong Hardware to
protect keys so it might be very easy
that you know the protection of your
phone whether it's fingerprint or
whatever or other biometric check this
is the way to control your account
and if you lose this device yes we have
recovery we use another I will assign
another device as my
a wallet signer
a disappear device keys
there are other signature scheme you can
use BLS signature is a very has a very
cool feature which can be compressed
very nicely and which reduce gas on a L2
Networks
so it's an extension that can be added
on top of account obstruction on those
Networks
to reduce the gas fees
and if you are looking into the future
we know that ecdsa signatures sometime
in the future will become weaker that is
the attack will become stronger and with
the quantum machines eventually within 5
10 or 20 years they will be able to be
cracked we want to be able to upgrade
our accounts at least our important ones
before them
Quantum resistant signatures might be a
way and again each of those cool
features we are talking is not a
systematic change of all accounts is a
specific account want to experiment or
want to add a feature okay you upgrade
your account and now you have those
features like any of those
on the slides around
sorry
dismiss anyone
okay now we're talking about some roles
you know you have
right now as I said with EOS you have a
signature and you can do everything
when you use Smart account you can put
roles you can allow different roles to
do different things maybe on your home
on your personal account you want to do
the master to do it all but if it's a
corporate account you might say that you
want the legal department to be able to
vote but not move tokens you want an
auditor to be able to cancel pending
events but not generate events
is set to a I don't know
set to a payroll system to be able to
submit to known addresses again the
sky's the limit what you can do and it
is still you can add it to this account
okay
wait maybe a little bit about session
Keys ah sorry okay we talked about the
the high end of a account that is
accounts corporate account there is also
the lower end you know you have your
personal account but you also want to
play games with games even the single
accept per request might be annoying you
don't want to accept each operation so
for games you might assign your account
a session key this key is allowed to
make transaction for specific Target
specific game and now you are
Wallet free you free the ux from
accepting each transaction and you know
it is limited it's only this game so it
can be your own wallet but you didn't
sacrifice for this game you're a nice
security
is this the next
yes okay we talked about the security
about the role access now let's talk
about the gas gas obstruction
with normal accounts the account has to
have if in order to pay for the
transaction
with account obstruction we want to
abstract away the gas we want to be able
for
a third party to pay for a transaction
which is very very good for onboarding
like adapt want to pay for transaction
for is deployment of each client or
client that uses its own account
if you have a token it might be useful
to use your own token your for the so
the user will be able to pay with your
dapps token for transactions
and for Traders if a Trader want to
trade on uniswap with a die why should
he have Heath to pay for gas he has died
why not pay with that so paying with
token is a cool use case that we really
want to have a
in in the system a privacy
if you think about it if you go and you
want to protect this privacy and use a
mixer like to another cache or other
and
yes you put the money in now we want to
get the money out but you have to have
gas in order to withdraw this amount how
did you get that gas from some kyc
account so you're not really Anonymous
when you withdraw funds from a
mixer you are not Anonymous even though
you would like to be so
if you're using a count absorption model
you can use
part of the amount that you withdraw
from the mixer is a gas payment
so this way you can withdraw and
completely Anonymous from a mixer
well one thing quick to add is the gas
sponsorship model is very flexible
um toll gave an example of onboarding
where you're subsidizing the fee
entirely but you can have arbitrary
logic it's implemented by a contract you
can limit that in any way you want you
can subsidize if you want only some
transactions you can make a user is
authenticate in some way you can decide
only to subsidize
governance actions I mean it's arbitrary
logic so anything you want you can do
with this just you decide what the
conditions are including asking for
repayment in another token
as I said all of these are features that
you have to implement we implement the
infrastructure
I'm only suggesting a cross chain
operation
a
since we are abstracting as we have a
contract you have a contract that can
pay for its own deployment and you have
a mechanism that can pay for the
deployment and for execution
transactions the next thing to think
about is that I want to make operation
on multiple networks I am on first
Network I can pay on there but I want to
use my account on other networks
so it is possible to create a paymaster
mechanism a payment mechanism that I
will be able to perform that operation
on those and other network
if you use my signature I approve these
transactions so it's not some other
party acting on my behalf it's me acting
on those networks but I don't have any
balance on it I don't have to have any
if balance or native token balance on
those Networks
it's a system that can move the payment
between the networks
why am I keeping people moving back
and lastly we have a wallet so there's a
link for them for the entire
presentation of the everything at the
end uh
as we said with the eoa accounts I'm
limited for performing a single
operation at a time which cannot be
batched and cannot and requires a
exception on each operation it's very
easy to add to a Wallet account
create performing a batch and doing
atomically a sequence of operation
another use case we can see that you
want a
Atomic operation or a delayed operation
that is I create an operation and I want
it to be executed later
a service can do it and again it is my
account that performs this operation
because I gave some service the rights
to do it at a later time
uh okay these are all cool ideas some of
them are very old some regarding just
the event driven flows because they're
very interesting maybe a couple of
examples one let's say there's an nft
that means at a certain time then you
don't have to wait in front of your
computer and then you just like create
the transaction then you could
pre-register the transaction into into a
like a registry contract of pending
transactions and then Searchers you
provide them an incentive to
execute the transaction when the time
comes and they're competing with each
other right now the use case would be
let's say you want to perform some trade
in the future or pending on certain
conditions price
um you know whatever whatever you want
so all this becomes possible and doesn't
require any Trust
foreign
okay with the
ear three four three four three two
seven
uh we wanted to create an implementation
of a counter obstruction that can be a
executed today not something we have to
change the protocol but something we can
add today
so
we Define a mempool
of what we call a user operation user
production is a transaction in our
terminology
so just like the normal user a mempool
of transaction there is the mempool of
user operation that nodes can withdraw
transactions from they
collect them and is to send a
to batch them and send them on the
network
but
the key thing about about this separate
mempool it's not a private mempool like
flashbots it's just separate because
it's accepting this this user operation
um instead of a regular transaction but
the key thing
um that's different about this is just
it doesn't require you to have like an
eua to interact it doesn't require you
to have the eth
um the paper it because what you're
doing is you're specifying within the
user operation the conditions that will
make it worthwhile for bunders to uh
submit your transaction on chain
um and they they make sure they get like
refunded for gas
um so it works out
Okay so our implementation what it does
it takes I said these user operations uh
they know you no longer need an eoa to
send this user operation the node
themselves take the user operation
collect them into batches and put them
on chain perform the validation
that is validation is the signature
nonce and the payment and then perform
the execution that
you want to make
a
if you read the AP most of the AP is not
about usability about how wallets work
but how we protect the network it is
very important that those nodes that
handle operations like when they handle
transactions
are not susceptible to denial of service
attacks
so we had a lot of mechanism
to make sure that they cannot be
attacked
so we batch them together
so that they will be cheaper
and they
sending them on chain it is since it is
contract based it can work on any evm
based Network today
where we we want to take it to the next
level right now when you create a an
account obstructed wallet
we want to make it a first-class citizen
on the network First Class A account on
the network
right now it isn't it is second class
because there are some differences
between UI accounts and some
applications require eoa accounts in the
way they work in the way they require
signature think of permit you cannot do
permit directly with a Wallet account we
do want to make them first class
citizens so the next stage after
uh what we've done today which is
having a contract-based mechanism to
deploy them on chain we want to add them
into the network to what we call
enshrine 437 into the network so that
account abstracted accounts will be
account and transaction in the system
just like normal accounts and then
to make it possible to convert any eoa
account into a smarter into account
obstructed that is there's going to be a
way it is not fully hashed yet it will
take some time until we finish it and
until it be approved into the network
but
[Music]
there's going to be a way that you have
a normal account and you want to have
those uh extra features
so you will be able to
enable this account there are several
ways how to do it one of them is that
you will actively have to
convert your account your account into a
smart account abstract account the other
way is that they're going to be some
point of in time where all eoa accounts
will become
abstracted but with a default
implementation that emulate completely
the normal eoa account and from that
point you can yes you can keep the same
implementation or you can switch to a
different implementation if you want a
extra features
like all of those that we described
earlier
so one one um
um one thing to maybe refine a little
bit is
um we believe eoas will need to go away
at some point
um so right now they are enshrined into
the protocol
um and we've discussed some of the
limitations around that so at some point
eoas even if there's backwards
compatibility they will they will not be
a part of the protocol anymore
um we don't necessarily think that it
makes sense to enshrine any specific
alternative like you know this is an ERC
maybe there will be like you know
improvements in the future because that
could be dangerous but
what's clear is abstract accounts are
going to be enshrined into the protocol
there are going to be there are going to
be accounts that can do all the things
that we discussed out of the box for new
deployments and for older deployments so
otherwise you would need to transfer all
your assets from money away to another
and that's very expensive and cumbersome
and you know potentially risky so that's
where we're headed and in terms of the
implementation yeah like they all said
there are various ways of going about it
um to be determined
okay what can we do
uh you can start experimenting with a
esc-4337a now I see people who
experimented here in the hackathon
and yes
over there also a
you can add useful features to your
accounts innovate do whatever you like
and if you find something that you think
is good for the public you can apply for
an EF Grant
and they
what they and anything building adapt
as we said accounts wallet accounts are
a bit different from UI accounts so even
today when you're working with apps this
is not strictly related to account
abstraction but to Wallet account in
general make sure that you are not
forcing the user to use a accounts like
if you're checking signatures there is
an extension the 1271 that allows a
Wallet account to check a signature
because
it doesn't have a signature by itself
a Wallet account just to be clear we're
talking about contract wallet yes yeah
if you have a token you want to have
permits be aware that permit as it is
today in usdt and die does not support a
Wallet account you cannot use it from a
Wallet account
but again because it uses the signature
there are some other tweaks like TX
origin and stuff
again in general try to be supportive
for wallet accounts because these are
the future not only the glossy safe
today but also account obstructed in the
future
and also if you're using gas sponsorship
models should also think about it how to
interact this probably will need an
interaction between your application and
the wallet in order to provide the ux
how to provide is a to your users
and and the last item would be regarding
uh wallets if you're developing dapps
then maybe
um there's some space if you you find
that well it's not supportive enough of
a contract wallets then you can voice
your concerns and and uh try to lobby
for that as a as adapt developer that
that really helps
um um so you know
getting everyone on board is is a is a
process that
um we could use your help on
okay
okay it is before the last the QR code
is missing here
so if you want the link to all these I
can give you it but it doesn't appear on
this version of the presentation
any question
yes
so I have like two questions like one
are related to how uh currently like
account abstraction exists as of today
as an implementation can you provide an
example like how like it can be
potentially used in a way as it is in
present form and the second question is
related to The Next Step like they're
like uh curious about like smart
contracts containing code then like is
there a distinction between operation
that involves uh the smart wallet
calling its own code versus uh calling
uh the code uh from a different contract
is it like uh on code becomes uh like a
proxy for uh other contract call while
interacting with other uh contracts in
that ecosystem
okay
okay for the first question how to edit
account obstruction is an interface that
a basic implementation that we have in
our source code that your wallet need to
inherit provide a method or two and then
the contract wallet supports account
obstruction there's also sample how we
add on top of existing ignosisafe
without touching the code adding a
module to make it account obstructed
enabled and you do need a wallet
application or browser extension that
will be able to use it
we have the basic SDK how to write it
there are several wallets uh Soul wallet
described behind the behind you a
demonstrated the hackathon and also a
proton wallet a hackathon project that
try to use
there are no
implementation in existing wallet like
metamask doesn't support it right
correct currently you have to use some
other wallets but this is now in the
work there are several wallets that are
adding account obstruction support
regarding how the call is done
the basic solidity it's a wallet is a
contract
when
when someone make a call it validates it
is allowed to make this call that is
either the owner or through account
obstruction the validation method and
then it makes a call outside so anyone
any other contract sees this contract as
the account that makes the operation
like whether it's a token transfer or
voting or whatever
we have another question
so regarding smart contract wallets
um so can you can you comment on the
situation on when you need to use L2
Solutions because in most of the cases
you you cannot because you have a small
contract wallet Deploy on mainnet and
you cannot deploy it on the same on this
uh um on on every L2 like arbit room or
Optimus because it you know it's it's uh
for instance sorry it will become a
different answers that's what you mean
so so you you will need to represent the
exact the exact deployment to get the
same address in order to do things like
claims of course yes the short answer
yes we built it in a way that it will
create the same address so you can have
the same address on multiple networks
yes as a wallet developer it requires
some work from you in order for that to
be possible but it is not that difficult
and it can be
done even
the minimals
the
the minimally
implementation of that is happening when
you just funding your wallet the first
time think of it you open your wallet
software you see the address it is not
deployed anywhere you see my your
address you go to index and you move eth
or whatever into it and then you make a
transaction with that wallet
if you're thinking of it this wallet
contract will pay for its own deployment
and then execute yes that's how account
abstraction implementation works today
so it works any more questions
thank you for your presentation
um I guess we all agree about like the
importance of account abstraction and
this is what Luxo was working on like
starting from 2018 and like starting
with ERC 725 standard but and I was
checking the the CRC like way before and
like I couldn't understand because it
was way like too complicated but I have
just two questions
like can you explain more about like how
users can choose the implementation
and about like the cross chain execution
and just an open question maybe we can
discuss that later like don't you think
that the standardization of the account
up like the account need more standard
laser standardization of other stuff
like I will give you an example if you
have a like a your account needs to
receive token
it needs to implement on
erc721 received on your c1155 received
and token received for erc223
but like what if we come up with a new
standard in the future
like on we need on ERC
6700 maybe and like maybe also we need
something related to followers or like I
don't know why because now it's related
to token now the hype is token maybe in
the future it's not
we can discuss that later if you want
I'll try from the beginning yes there
were wallet accounts before account
obstruction they exist from the
beginning of a ethereum which is not far
away but they exist
we didn't invent the wheel we created a
standard which allows the framework
which allowed nodes to support such
accounts accounts to be able to behave
as close as possible to your accounts
like pay for their own deployments which
would be tricky it's possible we
we created one there
we did standardize on a way to perform
validate to separate validation from
execution
in order to that in order that they
validate us what we call bundlers can be
self-sustained and can be a dose
protected
yes the AP is complex but most of these
complexity comes from these protection
mechanisms
if we should rewrite it in a way that is
more account friendly because most
people don't Implement a bundler they
want to implement an account so they
need to know what they have to do maybe
some of the limitations they have on
what they do and they don't care about
the low level implementation yes
editorial work is required for this uh
spec I agree
and they
of course change the execution a cross
chain execution let's take it off chain
again nothing of it is in the core of
the EIP like BLS
there's no BLS in the core
what there is in the core for example is
the ability to do signature aggregation
that
you check the aggregation in one place
for entire batch
this is in the core
BLS is merely an implementation of that
we narrowed several interface you add
another contract to perform it but it's
separate from the core
so it is modular all the features like
specific feature of wallets you
suggested some callback that exists
today and maybe a callback that will
exist in the future the wallets will
have to implement them right now your
eoa doesn't support them anyway
the idea is that when you deploy a an
accountability contract
I'm not think it's even written in the
spec but we expect it to be an
upgradable proxy that the owner can
upgrade and if it isn't a creative proxy
we have a basic implementation and then
the owner can change it don't don't you
think we're sacrificing security if like
we're going with upgradable
what you do need to do is to make sure
that on your first upgrade you upgrade
it in a way that now you add security
for example after the first upgrade you
can only
specific mechanism will be able to
upgrade it
okay account abstraction can be abused
it is I will not prevent you from
creating an insecure wallet I think you
can create a secure wallet with it
thank you your office your office is
watching us and sending us uh sending us
messages trying to participate in the
question and answer session you've just
said hey like uh what happens post
validation is not part of the standard
it's not part of erc4337 and anything
anything can happen
um we can talk about ideas on how to
make it happen but it's not specifically
related to The Standard that we're
working on right now it's kind of uh you
know outside of the core because we want
to make the core as general purpose as
possible because maybe we don't have all
the best ideas yet
by the way if you think there is a
security breach and something we can add
to this definition I'll be glad to talk
and we'll be glad to edit we are
overtime however with this is a break
time so if you guys have lots of
questions we're happy to yield them if
you guys are happy to have more
questions
anybody else anyone else
so how can you make sure that
um you know a wallet a smart contract
wallet will be able to prove that is for
example only controlled by one
individual versus multi-six such that
the receiving contract can make a
judgment call on whether it should
reject or accept that call right so for
example if I if I have right so we have
we have a separation okay the model we
have is like this a smart contract has a
separation between validation and
execution
execution is anything it calls out you
know you execute external content
whether it's atone another validation
gets the user operation
and validates whatever it likes the
minimum is validated signature and
validate the non so that it's not a
replay and it's a valid signer but it
can do more it can check the actual
executed method and say a okay I
restrict access to this destination or
if it's a complex rule I restrict access
to this destination for this signer
because I have multiple sign and each
one has a different role and is allowed
only specific method the Target contract
like a token usdc token usdc token
doesn't receive all this information
usdc received transfer from a standard
and it will accept it
it is the wallet
Logic the logic inside the wallet within
its validation
whether to allow or disallow specific
the operation we are now trying to make
did I make myself clear I'm not sure yes
it is complex yes if you're if you're if
your target smart contract does not have
you know
um additional computational
things going on that that require it to
for example if so take royalties for
example right if I if I have if I'm if I
can I can circumvent royalty payments if
I transfer an asset from from from from
Alice to Bob right uh um and and right
now if I with an eoa I actually have to
transfer the the private key to
circumvent the the the uh the royalty
payment if I allow a smart contract
doing that I can change ownership of
that of that of that of that no because
the owner of the tokens is the Smart
contract yeah I understand but the point
is if I can transfer the ownership of
the wallet address from a to from Alice
to to you yeah that's exactly the
problem so it's like it's like it's that
is exactly the problem if you're in a
royalty situation that cannot be so if
you want a wallet otherwise just a
second otherwise it's your circumventing
royalty if you want and while you're
doing something illegal I'm not saying
it is I'm not saying that we support it
I'm saying that a contract May support
it for example if you want a soul-bound
wallet that you can't transfer the owner
at all right go ahead create such a
wallet if you want a wallet that doesn't
support set implementation
then create a wallet that will refuse to
change implementation once you fixed you
reach that implementation you don't
allow to change you can create such an
implementation we don't block such an
implementation but we support others
understood it's just is there is there
any standard way to to communicate what
type of wallet implementation it is such
that the the targeting contract can can
check whether because you you don't know
right it's like it's like it's like
whether the targeting contract needs to
know the context of the wall
implementation to make a judgment call
about the owner okay first of all target
contracts
out there in the wild don't know
anything about the collar except that it
is a message center they can check the
code if they like but you are talking
about the use cases that don't exist
with EOS so they really knew also for us
smart contract calls for any operation
you're talking about
the other thing you talk about
standardization how to know
uh yes it is required we are providing
right now the infrastructure for account
obstructions for wallets to be built
about on top of it standardization
between the account contracts and for
example the wallet application that use
them
something that the the ecosystem will
benefit but it doesn't exist yet because
neither the wallet nor the nor the
contracts exist today so usually it will
be a siled like a given application with
a given a a given wallet contract with a
given a UI ux for it but we won't we
will try to push and try to find
Innovations from the from the community
to support such integration in such a
apis your scenarios are interesting but
I don't think they exist at all in the
ethereum ecosystem the short answer is
an nft can just check the code of the
color and if they want to restrict uh
you know themselves the Primitive
wallets they can certainly do that
it was it will this all of this will
happen in a layer above what we're doing
did you all have had some questions that
he wanted
you wanted to present it I'm a proxy for
you right now are you guys okay for a
couple more or okay
oh hi uh thanks for the talk I believe
you're also an author of eip2771
uh is that right
uh yes okay this is basically self a
meta transactions and with open GSN yes
so yeah I was just curious uh what you
see the role the role of eip2771 having
in an account abstraction world and also
for those who don't know it uh just
explain it a little yeah it doesn't it
doesn't
just not needed because I don't need it
anymore open GSN tried to do a gas
abstraction which we later implemented
into account abstraction for existing
eoa accounts
and the requirement of the gas station
network and network of three layers
which are the actually standards of
transactions meant that the Target
contract being token or other couldn't
tell the real sender so we they had to
be modified support
eip2771 at the method so that it can
tell the real sender which is a pain
it's it
because
adaptation of this requires the Target
contract to be changed doesn't support
existing tokens for example if you want
your token to be meta transaction
enabled you have to rewrite it so yes it
was problematic
it was good for dapps to add support for
existing users to sponsor the gas
account obstruction they has a Much
Higher Goals to replace the accounts
and it supports almost all existing
contracts as I said with the limitation
of contracts that limit themselves to
EOS it supports any contracts on the
Chain all tokens for example
so we
yes with the limitation you need to add
support for some tokens in your account
that's right I agree
so the target here is not
helping adapt building the
account obstruction though you can do it
the target is letting the user have
control of his own account and do it in
a better way
thank you George do you have another one
what I mean last one maybe
thanks
um so I haven't looked at four three
three seven so it might be like a basic
question but um
how does like ownership of the account
work like the abstracted account is it
is it private key held so it's kind of
like an externally owned smart contract
account
um is it single owner is it multi-owner
uh and the other question I have is is
this like a complimentary standard to
off and off call or is this like how
would that work with with when off call
is implemented okay the answer for the
question the first question is all of
the above or any of them because each
wallet can decide as I said we had a
wallet here in that demonstrate how to
use zero knowledge proof instead of
signatures another wallet that
implements the RSA signatures from your
phone you want eoa yes our simple
implementation uses in eoa is an owner
but it's just one implementation
the other question regarding Earth and
Oscar
it is possible to do some of the
features with Auto and Oscar they
basically do the
abstracting payment
we believe that it is far too complex
feature just to justify these two op
codes because they don't do anything
else of the account attraction they
don't change they enshrine the ecdsa for
example
so
they can be combined they can be used
together but
we hope for other alternatives
a huge round of applause for a Syrian
drawer thank you very much thank you
everyone thank you so much
[Applause]