foreign
[Music]
I know your name
and we've been working on account
abstraction in various forms for a few
years now and you have ice who is not
here is from the ethereum foundation and
he has been our colleague and
um yeah we're working on this in
collaboration with never mind and
originally we were working as the open
GSN team on meta transactions and all of
it kind of merged into account
abstraction the erc4337 standard but
we're going to talk about how account
abstraction is generally useful
regardless of the implementation so
let's talk a little bit about counts and
ethereum So Right Now the default
account well the what you get is an
externally owned account and it is a
one-size-fits all EC DSi key and the
other option you have if you um if you
want to have like your own smart
contract that would be controlled by
code but you would still need an eoa to
interact with it probably your current
wallet is an externally owned address
there are some limitations with that the
first one is maybe some of us have
gotten used to it by now but Key
Management can be hard and there's a
little bit of a paradox with key
management intrinsically because there's
a secret
that you're on one hand trying really
hard not to lose because if you lose it
you can't do anything with your account
anymore
and when you don't want to lose
something what do you do well you create
many copies of it and you make sure the
copies don't get lost
but on the other hand you also don't
want the key to be stolen
and we don't want something to be stolen
what do you do you you know try to hide
uh h-prom adversaries uh make it really
hard to access mini minimize how many
copies there are to be still in the
first place and the engineering
strategies when you just have this one
uh key that you're trying both to
prevent from being stolen and from being
lost they're kind of uh mutually
exclusive or they they pull in different
directions so Key Management is hard
even if you know what you're doing the
other big limitation of EOS is just
Access Control whether you're just
playing a blockchain game or you're a
multi-billion dollar Corporation if
you're using an eua it's like the same
Access Control policy
so that's very limiting you don't have
uh granularity
um you wouldn't have multi-sig support
there is no ability to implement roles
um you can't have spending policies it's
just one size fits all
mechanism based on this access to a
secret key the other big limitation of
EOS is Gas payment so you're paying gas
directly from the eua and it has to be
an East the native token
um now potentially there are many other
ways that you might want to be paying
gas if you hold some you know if you're
a fan of dog coins maybe you want to pay
gas in that you don't want to hold these
um
and uh the other limb big limitation is
that well if you do have to maintain an
eat balance in every account it's hard
to split up your activity between a lot
of accounts because then you have to top
off faith and all of the accounts and
the eat that you top off it has to come
from somewhere that's probably attached
to your identity
I mean kyc at exchanges
um and our identity is known to at least
some players and then yeah it's not too
hard to track and even if we split up
activity oh this is all coming from One
Source
so that's a privacy problem the other
big limitation of EOS is just in terms
of efficiency
many times what you actually want to do
it spans more than one transaction so
let's say you want to approve
um approve and then you want to transfer
those are two transactions but
um really you you are thinking of them
as one operation with the OAS you would
have to send two separate transactions
and
um you know that that might not work out
um it also might be a little bit more
expensive because of that but there's no
optimicity
um
um built in and if there is a revert on
chain that's pretty expensive
um so and that happens sometimes
especially with things that are very
time sensitive
so what is the alternative what is
account obstruction well basically what
we're saying is you know eoas are
um they're the one size fits all past
and we want to move Beyond them to a
world where
um we can really manage the logic uh
that controls our account and the logic
can be pretty arbitrary and then that
opens up a lot of possibilities and
that is the future of how accounts are
going to work so what are the use cases
for this
um you know the one that's been talked
about since the beginning of social
recovery
like let's say something bad happens
um to that secret that you're trying to
both prevent from being lost and from
being stolen
well maybe you have some friends that
you plugged into your account and three
out of five of them can help you
restore your wallet
um and you can do even fancier things
let's say your friends suck
and they're trying to steal your money
well you could have a delay mechanism
built in so if your friend suddenly try
to recover your wallet when you don't
need a recovery you as the account owner
would see that in advance and the
operation wouldn't happen immediately so
you would have time let's say maybe a
week
to respond to that
the other really interesting use case is
a dead demand switch
nobody lives forever unfortunately and
then what happens if what happens if you
know you you need to to pass on
um your your crypto but you're not
around to help do that
so with the dead man switch you could
have a mechanism like okay if you
haven't accessed your account from your
main key for the last year then another
key that your family members have access
to
um it would become active so usually
you're in control full control of your
account but then a year later you
haven't been active something wrong
happened your account automatically
passes to multi-set controlled by your
family I just one thing I want to
explain these are all features of that
account abstraction can give but it it's
not that everything is Comfortably baked
in these are counter possession or
accountability opens the the door for
wallet creators to add all those
features none of those features are
something that will be on day one maybe
a limited set these are options
that are open to do more oh now we can
both talk even if we can talk over each
other if we need to okay
that's a good point I was talking to you
off about that when you're preparing for
the talk
um this is oh yeah maybe that would be
nice
so that's a really good point
um this talk is intended to inspire hey
like we can do these things now
um but we have this
um this infrastructure built in but
um this all depends on the code that's
running
um your your your smart Wallet account
and that's up to wall developers that's
up to anyone that wants to get involved
and most likely there are many use cases
um that are interesting that will not be
covered by this talk so use you know the
sky's the limit in terms of imagination
um but we would like to talk about some
of the use cases that we've been
thinking about so one of the cool things
that happened uh during each Bogota is
there was a project that implemented an
idea that we've um I've been thinking
would be pretty cool is
um well there's there's this signing
mechanism in most mobile phones the
problem is the signing mechanism doesn't
support ecdsa curves so it's it's using
some other mechanism
um but because account obstruction
doesn't lock in ecdsa as the only way to
sign what you can do is you can have
pair device Keys
um that essentially you know you get
your phone and you link your phone to
your account now your phone can
authorize operations on your account
um and and a team actually implemented
that in the recent hackathon which we
thought was pretty cool multi-sig is a
very obvious use case so
you know now
um you'll be able to just
um get that out of the box
um another one is BLS aggregation which
requires a little bit of explanation BLS
is a mechanism to aggregate signatures
um and that's cool because it reduces
your gas costs
and because we have the ability to
implement any signature verification
mechanism in the account
then now we can have more efficient
signature validation and save some costs
the other big one is eventually
we know that the signature mechanisms
that we're using are going to be broken
it's only a matter of time Quantum
Computing is making uh significant
progress it's no longer theoretical the
qubits are getting up there eventually
we will I'll have to stop using ecdsa
but there are alternatives
um and hopefully by the time this
becomes you know a pressing problem we
will just be able to use any Quantum
resistant signature mechanism that we
want that is maybe like gas efficient
and secure
um and you can you can swap that
so you have a lot of flexibility
once you abstract away how you do
signatures and it's not hard hard-coded
so
um other interesting use cases are
spending limits I mean you know if you
if using your wallet for small
day-to-day things maybe you're paying
for coffee for a meal or for something
you know
um that is not usually life-changing
then it makes sense for that to be
something that you can do very easily
um that shouldn't be too hard but then
if you're making you know very big
investment
um then you want you you might want to
add uh add like a more uh secure way of
doing that so you go get your Ledger
um really depending on on what is the
spending limit that you're comfortable
with for different levels of security
uh and you can you would be able to
implement that because again you can
have arbitrary logic inside
um inside a contract that is controlling
your account
um the other cool thing that you can do
is well you can have you can have uh
different roles and you can delegate
specific actions uh to those roles
so you know if you're if the account is
a corporate account you can give payroll
uh authorization
um to people who are in charge of that
and you can specify the spending limits
um another example would be
if you're you know if you're um you have
a legal department or you just want to
delegate voting power for certain tokens
you could do that in a way that still
limits your exposure just to that
um
so they would be able to vote with the
tokens and perform governance actions
but not you know like transfer the
tokens for example
um
and
uh usually in companies I mean this is
something that's very common in
corporate bank accounts you give you
give different uh roles in the company
different powers so you know the CFO
might be able to transfer a larger sum
but there's still a 24-hour delay
um and then you know maybe other c-level
Executives could could veto that if
maybe the you know the cfo's key was
hacked uh or their computer
um was hacked
or the CFO is untrustworthy for some
reason but
um
another example would be well you you
want you want to give an auditor
um the power to monitor payments and
then the auditor has responsibility if
if something you know they have the
responsibility to reach out to authorize
parties and then verify that what
they're seeing happening on chain is
what is supposed to happen
so this way you can tap like maybe like
a third party
accounting firm maybe the one you
already work with say hey like you know
we we owe it to our shareholders at our
treasury management
um it doesn't get compromised and how
about like we plug you into
our our treasury in a way where yeah you
can't you can't perform you don't have
to
rely on maybe your computer security or
your staff we don't have we want to you
don't want exposure from to them in
terms of being able to
um to transfer funds but
we do want to give you the
responsibility of whatever you see
happening you know talk to the people
who are in charge make sure that it is
an authorized action
and you know within this delay limit uh
if it isn't just veto it just like
cancel the transaction so you could give
them the power to cancel but not
initiate transactions
and
I think the one that's going to be like
very useful very soon is session keys so
in fact I think this is something Argent
recently implemented for
um for their uh
Stark Stark net wallet
so the idea is
well you want to play some blockchain
game
and you don't want to have to to click
approve every time like a message needs
to be signed that that would really you
know destruct from the gaming experience
but you also don't want to give this
this game
full power over your wallet that would
be crazy like you know what if there's a
security bug in the game so ideally you
want to create a session key and the
session key has the ability to do
whatever is needed but limited to the
gaming contract nothing else and then
the worst thing that can happen is I
don't know maybe you're like your your
game sword your nft items are stolen
if the game gets hacked but everything
else is safe
and you could you could just store this
this key inside your browser so as soon
as you you authorize this as soon as you
generated the session key
um from that point onwards you're not
even
uh you don't have to be in the loop in
terms of authorizing transactions and
just becomes transparent so that's a
really nice that's a really nice one
um
well the session Keys also you could you
can mix you can mix what we were talking
about before so you could have a session
key not only has maybe limited access
um to uh to a specific contract but you
know maybe you have multiple devices and
you want very easy things to be uh like
very not not secure thing things that
are not very risky
um to be very easy from your computer so
um maybe if you just want to sign into
an event or or
um you know something that doesn't have
world changing implications if your
computer gets hacked so you authorize
your browser
um and you you would still you you know
you would still um have cap control
um over your account in case something
goes wrong browsers are not the most
secure platforms
um but you could just limit how much
power the browser has uh over your
assets
so
um there's also a big ux issue with gas
where you know the traditional web tool
world
where most of our users will be coming
from a gas is not really a concept so if
you have a server you're not really
thinking about who's paying to run the
server and uh how do I share in the
costs it just somehow works behind the
scenes and users who are new to the
space will not be really familiar
um with the concept of gas and it's also
a hassle even for people who are
familiar so with with uh abstract
accounts
um
you can you can have a lot more
flexibility in how you handle this so
for example if you're a game
especially if you're running on a cheap
uh cheaper layer 2 you could decide hey
it's worth worth just subsidizing the
transactions as part of my onboarding
process
um
it's very common to to have to like
um budget some amount
in order to acquire users so if it's not
prohibitedly expensive maybe you want to
do that and then you know later
um that's worth your while
um another very obvious one is just
being able to pay gas in any erc20 token
anything that has value
so if you're
if I pay you in usdc
there's no reason that I would also need
to send eth into your account
um for you to move that usdc and maybe
pay your bills with it
uh it's it's nice if you have the you
know if you have an account you whatever
whatever you have a value there
um like when you know someone sends you
a PayPal
um PayPal transfer they don't have to
send you like some other PayPal tokens
so you can move you know your US dollars
in PayPal to somewhere else
um so payment becomes a lot easier
um but also you know maybe you're
participating in in some governance and
uh the the governance of that project
doesn't want you to have to think
whether it's worth your while to pay the
gas for the interaction or not
um so they just decide to subsidize that
um or you could maybe you know you have
some allotment and if you go beyond the
allotment you have to pay in the in that
uh project tokens
the nice thing about being able to
interact with uh with a blockchain
without needing eth is it also has some
privacy bonuses
so because if you go through the usual
kyc process someone knows who you are
and their companies that are dedicated
to linking all the information
uh together
um so you don't have privacy
but
um yeah that would that would be that
wouldn't be an issue if you can just
um receive payment in any token and also
pay for the gas in any token because
let's say I'm a contractor and I work
online for you and I'm pseudo Anonymous
I do the work I give you an address you
pay me and you know I would be able to
pay my bills with that or or or buy
something online or whatever and I
wouldn't need to also acquire eth
um and I could also separate let's say
I'm working with with different
customers I could give each of them a
separate address and the customers
wouldn't necessarily need to like they
don't need to peek into my bank account
or my equivalent of bank account and see
like how much I'm making and what is the
balance there that's
like we're we're doing that
um and maybe some of us have gone used
to it but it's really weird where you're
working for someone and you you give
them the the like the number of your
bank account and they can see exactly
what's going on there
um that's that's not very private
um
and and once we have once we have gas
abstraction as a built-in feature then
we don't have really have to worry about
that anymore because we could just
generate easily generate new addresses
for for uh everyone that we interact
with if we wanted to
there's also an interesting
um interesting uh use case for enabling
cross chain operations there are many
ways to do that
um
and uh
yeah that's just something that becomes
a lot easier once once you once you have
um this functionality built into the
protocol
um there's also there's also uh some
savings that you get from from just
being able to batch uh different
transactions together
um also from being able to guarantee
that the transactions are going to
execute uh with optimicity so for some
things
it's useful
if everything happens together and if
everything doesn't happen together then
you don't want it to happen
um because there you know it wouldn't
make sense uh for the transactions to
execute separately
um
and you know whether this happens
um whether this happens like in a gaming
environment or you know there are some
you know like Financial scenarios I mean
imagine the simplest one would be you
have to you have to approve you have to
give some authorization to a contract to
perform an action on your behalf
um and then then you want to perform you
want to give them like you know another
transaction to actually perform the
transaction and those both need to
execute together
otherwise like you just wasted gas
um and there is
there there's
um there's a sort of General use case
that's interesting where
um you can actually uh Implement these
um
uh time time delay uh flow so for
example let's say I want I want to be
um I want to be uh uh selling my eth
when it hits uh 5000 but I don't wanna
I don't know when that's going to happen
I don't want to sit in front of my
computer
um so it would be possible for me to
just pre-create the transaction but make
it conditional on certain certain things
happening like okay only if the price of
eighth is 5000 or only after this time
or whatever the condition is and
um so my wallet
would agree to execute and pay for the
gas for that transaction and also maybe
a transaction fee and you would put that
into a registry and or the registry of
uh future time delayed or event driven
transactions and Searchers they would be
able to monitor this registry and
see oh like these are transactions that
their conditions have just been been met
so they can compete on executing it for
you
um and that opens up it opens up a whole
range of of uh interesting um use cases
because now you know it doesn't have to
be you that pulls the trigger at the
exact moment the conditions are met and
if the conditions are met
um the transaction will be executed for
you by Searchers and it could be time
delayed it could be based on essentially
like whatever uh whatever the conditions
make sense
um maybe another example would be you
know there's an nft series and you have
to be or I don't like you
um an event that you have to subscribe
to for in a certain time window
um
okay so a little bit about erc4337
which is so um this is the standard that
we have been um working on
and uh
Paul here is is the guy who implemented
the the contracts
um so
yeah please if there are any technical
mistakes correct me
okay
so this is the first step
um towards protocol level account of
distraction the nice thing about our
approach is that it doesn't require any
change to the rules of consensus so we
can kind of experiment uh for free and
we don't have to solve governance in
advance
um the way we're doing it is okay we
essentially create a mempool new type of
mempool for anyone that wants to
participate in this and uh a single you
don't you don't need more than a single
Network this this mempool it's
um uh essentially it uh accepts it
accepts uh something that is essentially
a transaction we're calling it user
operation but a user operation is
equivalent to a transaction but it's a
it's a transaction that works with with
um with these account contracts
um
so what that does is it makes a contract
wallets a first-class Citizen and it
totally does away with the need for
having
um anyway you don't need a new way to uh
to control
um to control this this account
um
and
I mean the way the way that works about
maybe a little bit about how that works
um
you have it's kind of similar to how um
uh you know flashbots Mev private
mempools like the principal behind it is
you can have a mempool
where bundlers they are provided an
incentive to submit your transaction
um
and
essentially uh we're just we took that
that idea or originally this was
vitalik's idea and we added the gas
abstraction part to it to make it a more
general purpose and
then the bundlers you know they their
their job is to just uh take these user
operations and eventually they they they
bundle them together and they submit
them
um as when they're creating when they're
creating
um
um uh bundles that that are go to the uh
to actual uh blocks
okay the the um the the other advantage
of doing things this way
is that we're separating validation from
execution
so
you can have
[Music]
um
so so if I'm if I'm a bundler and I am
paying for the gas of your transaction
there's there's some risks involved for
me because
um you know what happens if the the you
know like you know if you don't pay me
what happens if I execute a transaction
on chain it turns out that it
um and it ends up uh
um you know um ends up uh well at the
very least you expect to be repaid in
gas because otherwise
um you know why why would you
participate in the scheme
um so to make it make it very safe
for bundlers to participate what we've
done is we've provided
um a contract level guarantee
that you're always going to be paid back
regardless of of what happens with your
transaction when it's executed on chain
so we've separated validation from
execution
um and what the bundle needs to do when
they accept the transaction they're just
verifying that they're doing this off
chain initially just okay if I if I
accept your transaction
um and I'm calling this huge function
and uh am I going to be uh paid back for
the guess that's that's all they're
verifying so it's it's pretty cheap for
them to do that
and
um later
the totally separately when the
transaction is submitted and gets
executed but by then you don't really
care
um as a bundler
um even if it reverts it's your problem
just like with a normal transaction
because you're still going to get paid
and the the
you know without this it wouldn't really
be possible to
um
um the crate
a permissionless uh pool of bundlers
that are participating in in this um
protocol because the bundlers would have
to trust that um they're not going to
get cheated
just one
we use the term brundler which I node
Valley debtors just like any node Valley
that also supports account obstruction
and not one of them is enough to run a
network the more they are the notebook
is more resilient to a censorship and
other things but the bundler eventually
and eventually all validators will
hopefully will be also bundles right so
the right now we have so exactly you
don't need a consensus change you don't
need like 51 percent
um of validators participating in this
scheme because ultimately you're
generating just uh
um Regular legal bucks
um and we have we have another mind
um as as an implementation that is
supporting this
um the more the more clients support
this the faster your transactions are
going to get executed but
um yeah
Okay so
so with erc4337 then you know once we
have this scheme
um we can also use it to make uh uh
Roll-Ups cheaper because you can batch
transaction you can aggregate signatures
so
um
so yeah that's that's another advantage
and like I said it doesn't require any
protocol changes so on any ebm chain
um you can we can start experimenting
with this
is there anything you want to add
yeah okay technically a bundler can run
as a separate entity it is much much
better for you to be a node to be more
resilient so the way to add it right now
the way we currently adding it ungirly
because it's still on test is elegant as
a separate server
a
the wallets don't care it's
implementation in order to be highly
scalable and to be able to batch more it
has to be a node in the network Never
mind already have a node that can run a
nethermind and there's a work to edit
also with a get code
so what's what's next
well yes we can start experimenting and
have
um account abstraction and any evm
compatible chain without consensus
changes
but the goal is to do away with the OAS
eventually we don't we don't need doas
and uh we know we're going to have to
move away from them
um eventually at some point
and there are various ways of of
thinking about this
um
so
we want to want to want to have a count
of abstraction
um as a basic feature of the protocol
but we want to do it in a way that
doesn't enshrine any particular wallet
or gives an unfair advantage to any
particular wallet
um and because the eoas are effect
and they're very very common and they
probably will be
um until we uh you know we move away
from them
um it will take a few years
we need a way to convert EOS seamlessly
um to smart smart contracts
so there will be
there will be some default
implementation where yes everything in
the future is an abstract account
including EOS but if you haven't
upgraded your UA if you have an inserted
code into your eoa if you haven't like
activated it in some way then it just
you know behind the scenes
um continues behaving like in your way
but it has it has the
um the the functionality requiring
allowing you to to upgrade it of course
this would require a consensus change
and there there's various ways this it
can be achieved we're
um we're discussing
um you know one way would be there's if
we create a new transaction type and
then you can set the code
for your eoa this is
this is
um
this is now the code that's running your
UA
um
or you know there's also I've been been
a suggestion
um EIP 3074 maybe that in combination
with another EAP we could also set uh
default proxy contract for all addresses
um I thought you want to add anything
Yeah by default that basically two
options one of them to let a user decide
the exact point of time where he wants
to upgrade its eoa into a a contract
wallet
either using the transaction type or new
OP codes on such the other way is to
decide that at one point of time
all Eos start using some default
implementation we've deployed and tested
thoroughly before which behaves exactly
like anyway so all users will not notice
a difference except that from now they
have a way to modify the replace the
actual implementation so they have a
smart contract that just behaves exactly
like an eoa until they decide otherwise
right yes the basic Contour doesn't
offer any of the Advanced features we
described earlier except the one feature
which is replace implementation the user
can replace implementation once it is
replaced the sky is the limited yeah all
the use cases that we've yeah use cases
in it all the uses that other people
really try to find
okay okay I think that is if anyone has
questioned well we still now we're going
to talk about well how do you join this
okay yeah yeah okay
[Music]
um
so how do you join this account
abstraction Revolution
you can start experimenting with the
rc4337 right away
and uh we had eight wonderful
submissions
um
and uh this is something that's
um you know already working
so you don't have to wait
um
you can add useful features like the one
we discussed you know batching or key
recovery
um or any any of the things that that
we've been talking about
you could build
features that were totally not possible
with the uas that we haven't thought
about and if you do if you if you're
building anything cool
um then you should definitely apply for
an EF Grant because we want to see this
we want to see this
[Music]
used and adopted and we want to see the
experimentation and want to update this
presentation with more interesting use
cases
um so definitely apply for an EF Grant
if you have a cool idea that builds on
ERC on the CRC
the other thing is
if you are building adapt you have to
think about a future where contract
wallets are first class citizens I mean
contract wallets are already
pretty common especially for teams
um you know multi-cigs are an example
but still many dapps assume that they're
going to be interacting with an eoa
and that
that is just
um an obstacle for us to move forward it
means your adapt already can't interact
with things like you know it's a safe
wallet
um if you're assuming you're making
assumptions such as
um you know the the the like you know
the how how signatures are validated so
there are easy ways to make your dap
compatible
both with smart contracts right away and
account abstract accounts in the future
and that's ERC
1271 with just
it checks
um it checks if the caller has code and
then there's a mechanism where it can
just invoke
uh invoke a function and instead of
assuming that there's they can rely on
this EC this DC DC DSi key
the other one is
if you can if you can
um benefit from batching in your user
interface and many many dapps especially
games can
then you should check if you're
connected to a contract wallet that
supports it
um and that will that will create a
better experience for your users it will
save uh uh gas costs
the other thing is
um with how gas is paid
so if you have adapt
you should think about different types
of
uh Gas payment models
I mean you know a big an easy example is
if you have a token then it makes sense
perhaps that your users should be able
to pay uh for the transactions in your
token when you're using your dap
um and if you don't have a token or you
want to subsidize your users that's
easily accomplished
um with with the with account
abstraction
um you you set up yeah you know you set
up a a contract that authorizes to
reimburse
your users for whatever criteria you
feel comfortable with maybe the
onboarding process maybe they they have
to perform some action but
um it's uh it's it's something that's
possible now
and
a lot of the a lot of the improvements
that we're gonna get for for that
usability is going to also require some
you know wallet support
so wallets are an important part
um of uh of usability for depths and as
a depth developer you have some
influence by collaborating with wallet
Dev saying okay this is this is
something that you know would would be
beneficial for my use case
uh
um and you can
you can have a have a bit of an
influence by just saying okay this is
this is useful for me I need this
feature in the wallet
um for example supporting account
abstraction
so other than talking with us
um we're happy to help anyone that's
implementing uh different use cases we
do have an SDK up
uh later you have will share on his
Twitter
um the the links but there's there's a
there's an SDK
there's an SDK you can come up to us and
we'll give you yeah or we'll just give
you but I can I think I think I just
like open this right now and show like
where this is pointing to
wait this is very small why is it so
small
yeah yeah
so we have our SDK it's on GitHub eth
infinitism account obstruction it's not
dedicated contracts oh where is the SDK
is infinity
okay oh this is the link is broken then
all right we'll fix that
that is um
okay oh this this is the SDK okay so the
reference implementation of a bundler
simple bundler and the SDK oh cool okay
so that's the SDK we will fix the link
later
um you can also read up on the ERC
uh
and oh maybe that's the right link no
that's that's really uh yeah that's your
seat itself yeah yeah it's the ERC
itself so you can read the ERC it's very
detailed
uh but you can get very precise
understanding of how it works there's
also a discussion on the ethereum
magician's uh forum
and
and of course
um it's nice to be able to talk with
people so we have a Discord
now we have a Discord server and uh
you're very welcome to join and ask
questions and
even after this event like if there's
something that you don't get to ask us
in person
um and yeah maybe now we will just take
some questions yeah yes over there
okay the
internal development roadmap what we've
developed are the interfaces and the
core contract that performs this magic
we call it entry point
it was audited but then was extensively
modified to support the l2s that is not
yet audited we still have some work on
it the API probably won't change so a
wallet will be able to work so it's not
deployment deploy the mainnet only on
testnet currently
but you can create and start
experimenting with Wallets on top of
that the interface of a wallet the
change of wallet needs to be it's quite
minimal I can go through it adding a
single method
or two uh
yeah we have a sample uh yeah a sample
that uses that adds account attraction
support to ignore the safe you add the
module and you basically get make a okay
a single owner and you can also safe and
account obstruct the compatible
um
so yes you can create
and there are some work on creating
wallets today
in terms of applications yes it's
chicken and egg application it's a
wallet in order to work there is a way
no it's for a basically a hackathon an
application can work without a wallet
but it's not something else you want
your user want to sign blindly a hash
if you're good with that it's also
possible to with an application can work
with accountability in the day
the way gas abstraction works is that
when you submit a user up
I said the contract itself validates
itself the signature and its nonsense
and in order to accept the request but
there's also a pointer to what we call a
paymaster a payment is a contract that
before submitting the transaction has a
chance to decide whether it agrees to
pay or not if it says okay that is it
doesn't revert it will use its own
balance its own stake and everything to
pay for this transaction now what this
payment does on chain depends on the
paymaster so the most obvious example of
a paymaster is that the validation will
be I will check that this user has a
balance of enough die and has approval
for me to use this die and I will grab
enough die to cover this transaction so
and at the end I will refund it with the
excess So eventually
I pay the user pays with tokens for the
transaction this models
it's most obvious use case of a
paymaster but there are other use cases
if you want a voting data and you don't
want the user to pay anything okay
so the check is that the user is
eligible to vote
if a user is eligible to vote and didn't
vote yet I agree to pay
it's an another example of a paymaster
other examples are still open you can
write whatever you like
just just a contrast right now if you're
using Nosa safe
then someone on your someone on your
team has to like pay from their account
right even if the agnostic safe has
plenty of ease
um someone still needs to like pay from
their own accounts just to have that
transaction uh finalized
um so with account obstruction that
wouldn't be necessary
your account will be able to pay for
yourself and this doesn't require a
paymaster but let's say you're you're
safe for
um going back to the safe example if
ignosis safe doesn't hold any heat it
doesn't hold sufficient eth where you
don't want to have to care about the
balance and continually like exchanging
and topping it off and whatever you have
a balance of assuming it's enough to pay
for the gas
um you would essentially include in your
transaction a reference to something
we're calling a token paymaster and
token paint Master can be completely
autonomous contract on chain
that it just um it accepts tokens it and
it it would pay for the transaction in
eth and then it would settle in some way
so well an old reference like an older
reference implementation recreative
which is using swap using unit Swap and
add single transaction which was kind of
expensive either cheaper ways of doing
it but just it's like very simple and
one single Atomic transaction
it gets paid it gets in a sort of an
allowance in whatever token you have it
pays for the gas it charges the
transaction fee
um and then it gives you back the the
remaining uh tokens
so with account abstraction if you want
to use if you want to use that for
example then you would just include oh
the
um The Entity that is paying for the gas
is a token paymaster but there is a way
for the token paymaster you know to to
receive a commitment from your account
to pay it back
so it's not just subsidizing the
transaction that's also possible it
makes it possible right now you have to
split
different concerns if you need some
corporate level security using a Galaxy
safe and if you want a game you will use
this metamask and fuse your private you
can use trezor now if you if you want
them all in the same single address yes
you will be able to do it with a counter
fraction
probably you still might have multiple
abstracted accounts for different
purposes but for different reasons if if
the reason to have multiple addresses is
only security then yes you will be able
to use a abstracted account
to find something that can cover all the
all bases yeah because you can just
limit your risk exposure to each device
depending on how much you trust it again
I'm not saying that there will be one
wallet it will give you all these use
cases you'll find a wallet that give you
all the user's case you need
and use that
and you always can switch
I think the the
first use case of a signature is chain
signature just think of it you start
using metamask and after a few years you
collected a lot of nfts and a lot of
money but you can't change the security
model
your browser holds your private key so
you have no idea if anyone hacked into
your computer and grabbed it through a
copy of your computer without changing
the address you can change the security
with account obstruction with single
operation of change owner now the trays
are on the same account even if with the
basic simple account I just changed the
owner and now I am really secured
because the previous private key is no
longer relevant yeah even before you get
into the really fancy stuff that you can
do with the abstract account abstraction
the basics are actually pretty
um pretty useful just by themselves
because right now if anything goes wrong
then it's really hard to transfer
everything from from one eoa to another
I mean you would have to create separate
transactions for each asset that you
hold that could be pretty expensive
um and if your computer got compromised
you might need to do that in a huge
hurry you know so it's it's
um it's just not not the best situation
to be in even very simple improvements
like this will make a big difference