[Music]
uh hello everyone my name is Alex I work
on account obstruction and today I will
follow you stock with a deep dive into
the future of native account obstruction
and our plans for it so for the purpose
of this talk I suggest like we all agree
that we want native account obstruction
the way to for C obstruction is to
enshrine it in layer tools and the uh
main net and we need to answer the
following questions before we go into it
uh first we need to know which part of
native account obstruction is already
happening in the next ethereum hard Fork
uh we need to see why it is not enough
and what is still missing for us to
achieve the account obstruction endgame
uh I want to explain how we plan to
achieve it uh and also Explain how other
companies and teams can participate in
this effort and honestly look at the
possible alternatives to doing what we
are proposing so uh uh and a quick recap
of where we stand with account
obstruction right now if somebody was
not involved into it so the first
account obstruction proposal ERC 4337 is
soled the account obstruction uh without
making consensus changes on eum protocol
it uh allowed us with purely out of
consensus to uh provide a count
obstruction solution and it did solve a
vast majority of cases and it has been
released more than a year ago the main
and uh the has have been launched so
it's no longer a new project it has been
used for a year by a very serious
project uh EAP 772 is a very important
proposal because it's the first time uh
mainnet is getting some account
obstruction features uh this EAP allows
uh as you know EOS to like role play for
a time as smart accounts and this
scheduled for the next hard work uh you
have mentioned RP 7560 this is our
proposal to enshrine the design of ERC
4337 as part of Layer Two con ensus uh
and it has been implemented and there is
a devet ready implementation and now we
are also proposing EAP
7701 this is somewhat similar to 7560
but it is trying to be less opinionated
using uh Le less of uh uh uh the
protocol Parts uh and it targets uh
etherum layer one and it relies on eof
to do so it's in early draft stage and
and we request everybody to provide
their feedback on it uh so a little bit
like more on 7702 uh this is how the
account looks for once you update it
with uh
772 so you still have the private key
but you also have Smart contract code so
it changes the behavior of current EOS
allows them to have code as well and
this solv fully solves the execution
part of account obstruction your account
can do multiple operations in the same
time doing T whatever uh it is it does
not however solve the security part of
account obstruction because you still
have a private key you still have an EA
you still have 12 words that can
override your smart contract wallet and
there also needs to be another EA that
creates a transaction to use your
authorization uh the upside of this is
that it works great with ERC 4337 and
such accounts can be part of account
obstruction ecosystem and get gas
obstruction and many other features so
one question you can ask is like great
so next we'll just wait for the rest of
account obstruction to be enshrined in
uh uh e main it well if you look at the
uh specs for the next three hard Forks
this is the list of eaps that are
considered or scheduled for inclusion in
the next uh three hard fors like this is
a long list like these changes will take
quite a lot of time and so if we were to
just wait out for to introduce a account
substra C on layer
one this could take very long time and
also it it's a high bar to clear in
terms of uh production tested uh
specifications uh fully spec road map
and it requires an unanimous consense
among uh core ethereum developers uh to
do such a feature uh it doesn't mean
that we will just wait for these things
to happen we have a lot of uh activity
we can do on layer tools who are eager
to innovate with account obstruction
right now uh another like alternative is
just to keep using ERC 4337 like forever
so can we keep using it well kind of yes
it's good enough in many cases but it's
very much not perfect like the main
downside is it still relies on EAS uh to
act as bundlers so you have an account
abstraction solution but you still need
EAS for that uh we also create a lot of
complexity by implementing a lot of like
parallel technical Stacks parallel mles
uh parall bundlers and modifications to
the node uh and as layer tws want to
innovate they start implementing their
own uh Native account obstruction
Solutions there are chains who did that
and it is it is a problem because then
it breaks the compatibility and also
there are still uh new EAP that
introduce new features to ethereum one
big example is inclusion list uh you
have mentioned fossil uh and this eaps
like don't benefit account obstruction
users in the
account W uh so uh let's zoom into a
flow of a single uh user operation in
ERC 437 so what happens is the user
signs and creates a user operation and
the user has to provide it to a bundler
server the bundler server then collects
and other user operations and uh bundles
them together and provides uh it as a
transaction uh to the blog Builder and
it has to use this uh conditional API
meaning that it performs the validation
and he provides a condition for this
transaction uh to be valid and then the
blog Builder can include this as a as a
call uh onchain with RP
7560 uh we make all this super
structures that we had with the bundler
and conditional API and entry point
contract uh part of consensus protocol
so it very much simplifies and flattens
out the complexity and for the user they
uh sign transaction and they broadcast
it to the mol and the protocol takes
care of the rest uh and the complexity
becomes part of the protocol but again
it's uh
simplified uh so how it works is that
already now like all transactions that
we uh broadcast to meole and include on
chain they have a validation code this
code is not solidity evm code it's a you
probably go code that uh blog Builder
have uh we validate signatures nones
balances G limits uh base fees and these
checks are done uh in go as part of
consensus and then the execution is done
on the evm uh with 7560 we split the
transaction into two parts and the
validation part is also solidity code uh
that also runs on chain and uh but it's
it's still a single uh transaction that
is split into validation part and
execution part and error in validation
part means that transaction is not valid
it's not included onchain and reverted
it just cannot be included uh in a
block uh so if you're familiar withc 437
the most complex possibly uh path for
transaction to take is to have gas
sponsoring and uh to deploy a contract a
smart contract as part of the first
transaction interaction so these are all
execution pathes in account obstruction
and this is what it looks like in
7560 uh meaning that uh for a
transaction type we add a number of
fields uh and what what happens during
this transaction flow is uh First Step
user creates a transaction sends it to
the blog Builder as part of a
transaction uh it's uh smart contract
gets deployed uh pay Master gets queried
if it agrees to pay G for this
transaction then the account is uh
quered to see if it accept this
transaction is valid check the signature
and not and everything then the
transaction gets actually executed and
reaches the Target contract and uh if
pay Master wanted to it gets also notify
that pay transaction execution uh has
finished uh however uh what need to be
said RP 7560 is not meant to be included
and layer to in its current form and
like the RP process itself was started
for
uh features that are common between
various layer twos but not necessarily
Target layer one uh the it provides us a
lot of uh uh flexibility uh because we
don't need unanimous agreement of all
core developers uh it's an opt-in
process where rollups can decide to pick
up features and implement it on the uh
networks and uh uh it's very feasible
and like logical for some RPS who get
adopted to evolve into eaps so uh what
prevents 7560 approach to being part of
the main net EAP well a huge part of it
it uh defines validation as solidity
methods like we Define solidity method
that say and we say that this method has
to return correctly then the transaction
is valid it this a little problematic
because evm is supposed to be language
agnostic and methods are just part of
solidity programming language it's not
such a big deal for layer tws because
almost all of them already have some
kind of pre-compiled that are defined
fully in solidity and they already do it
uh another thing is that eof ethereum uh
evm object format introduces the
deployment time code validation and
account obstruction could greatly
benefit from code validation however
without uh EF definitions we would not
be able to do it uh with the um method
selectors and it it can be a problem
that your validation code is a part of
your contract that can be called by
other contracts in some scenarios that
can lead to
vulnerabilities so a reminder in UF uh
the contract is being split into parts
so Legacy uh contract they have the blob
that includes all the code and data of
uh your contract with eof the contracts
are split into the header the code
section and data section what we are
suggesting with the EAP 7701 is to also
split the code section into uh into
parts that have roles assigned to them
so the contract would have an EF
validation code execution code any other
code and uh uh we can verify the code of
the validation section uh before uh
deploying such contracts and U we like
uh this code doesn't have to be
observable on chain from within EF but
it is still executed as part of uh
transaction
validation uh so if we look again on all
the flow the flow remains exactly the
same just instead of uh calling specific
functions uh the evm executes a certain
uh predefined section of your eof
contracts and uh this allows us to like
get away from this magic method
selectors into a more U minut uh level
solution so now uh it's time to talk
about challenges of account obstruction
like people have been talking about it
for 10 years it's still not on mainnet
uh this is because it's actually hard if
you see somebody talking about
validation scope on account substraction
you immediately think about this picture
uh and the main problems for that what
account obstruction creates is the cross
dependencies between transaction and
validations and the the complexity
it you you get in building blocks
efficiently and maintaining a
decentralized peer-to-peer M Pool
efficiently uh so let me try to uh
explain these problems uh so the cross
transactional dependencies look like
that uh you have transaction four if
modifies the state and it makes the
transaction five invalid so when you
receive the transaction five
individually it seemed valid to you
because X was a was uh uh equal to zero
but now you started building a block you
include transaction four first and now a
equals 1 and it's not a valid
transaction uh and in order to work
around this issue in in general we we
just have to to split the uh transaction
into two parts and have the validations
run separately from executions in their
separate place in in the book so these
are still three account abstraction
transactions but their validation parts
are separated from them and they run
before any execution code starts
running now you may ask but what if
validations invalidate each other what
if the validation code changes the state
that another validation uses and in
general it would be possible and in
order to prevent that we need to send
box the validation code to prevent it
from doing certain things that it should
not be allowed to do so what are those
things uh it's accessing other people's
storage and accessing environment of
codes so environment op codes are block
number time stamp base fee everything
that may change from validation and uh
execution or between uh phases and other
people's code is a code in other
contracts unless it is in a mapping uh
mapped to your address and on layer twos
it's also any stateful pre-compiled so
this uh doing this is illegal all other
things are allowed uh in validation and
it allows us to do many great things you
can use tokens you can transfer tokens
you can can uh do all of that uh in
validation
functions uh like there are other small
complexities uh like one example is you
don't need to invalidate a transaction
to make it hard to for a block Builder
to build a block with a account
obstruction like one good example is uh
unused gas and using unused gas as a
vector for example you're building a
block you include five transaction you
see that you still have a lot of
available space because action for
requested 10 million gas limit but
didn't use it so you start adding
another transaction to your block and
what happens is transaction four saw a
change in the state and started using
more gas and now you are like you have
it recursive like chicken neck problem
because now the transaction six doesn't
fit your block and you need to exclude
it and you can get it to um to square
one like we do solve it by introducing
gas charge on a used gas
but I'm just saying using it to showcase
the kind of problems we need to solve uh
when implementing account obstruction
natively uh and another thing is
maintaining an efficient uh mle uh to to
receive a huge number of transactions
simultaneously and validate them you
need to to parallelize their validation
so assuming like here's a block Builder
it has six uh CPU course and it's
performing validation of six uh
transactions in in parallel so it runs
them uh uh individually meaning they
don't access each other state and if it
finds a transaction that is not valid
individually it gets included from uh
blog building and the next step for the
blog Builder is to validate all
transactions that uh that remain that
are remaining in a in a smamp pole and
build an valid block if uh we were not
able to uh separate uh the scope of uh
validation code in one of these
Transaction what could happen is we
could have a mass inv validation event
when one transaction uh changes some
State and makes all other transactions
in your block invalid and uh it provides
a huge d uh DS Vector for mol
participants and blog Builders because
we don't want them propagating uh in
valid
blocks uh now uh developers who are
interested especially if you're working
on layer twos what can you do to make
Native account obstruction happen first
like do get in touch with us on any of
our uh channels Discord Telegram and
let's talk about Native account
abstraction uh do just read and get
familiar with either both RP 7560 and
EAP
7701 uh we're looking for feedback on it
um and you can also go dive into the
code uh this is the link to our
reference implementation of RP
7560 uh there is also a roll call event
for the RP process I guess everybody
knows it just join it add RP 7560 to the
agenda and discuss it with other layers
too and let's uh let's start building it
so here are our websites and uh that's
uh that's it
for thank
you thank thank you so much
Alex let me start with questions the
first one is if 4337 bundles bundlers
don't yet support the aggregation
portion of the spec how can we read how
can we be ready to make it part of the
protocol yeah so uh aggregation is a
part of 4337 it will be part of native
account obstruction uh eventually we
have a draft EAP for that uh however
it's a complex Topic in itself the
aggregated signatures are complex and
there has been little adoption of
aggregation yet uh it does provide
additional challenges in the context of
native account obstruction uh but I
think we will overcome them and again
our approach is to make all these
changes very very modular we don't want
to make one Mega account obstruction
spec and implement it in one fork we
want to make like basically as many eaps
as possible uh reasonably uh so that
chains can uh adopt them meaningfully
but uh uh one by one uh
okay next one how critical and how
centralized
is are the bundled like is is Bund is
the bundled okay can I
see how sorry how critical and how
centralized is the bundle yeah I guess
the bundler uh so in ERC 467 bundler is
critical not very centralized if you use
it correctly so if you're using it with
a M Pool uh that is not uh like you you
don't depend on any centralized bundler
uh with uh
7560 um the RO of the bundler changes it
becomes more of an assistant to to the
block Builder and then it's as
decentralized in the underlying Network
there is no added centralization Vector
uh on on the bunders uh does that make
sense uh yeah okay thank you next one we
have 4337 756
07702 can you can you describe how they
all play nicely with each other and how
can we avoid once again fragmentation
the space in this case with regard to AA
account abstraction Solutions um right
so 7702 does not pose any fragmentation
uh challenges whatsoever because this is
just a new feature of of the evm and I
assume it will get supported like pretty
widely and it's also like it's an
addition to uh account obstruction road
map with 4367 and 7560 we keep the flow
the user flow uh so similar that it it
can have very minimal traction uh like
friction in terms of fragmentation
because if you have two accounts and
their differences are so minimal I
assume just most wallets would support
both and both of them will coexist
peacefully for a period between uh now
and when uh 7701 is implemented on Main
net and and so like they are all still
part of the same ecosystem so it's not
fragmented it's just different flavors
of uh of the same uh same thing that
makes
sense what's your recommended drou map
for metamask to achieve the end goal of
account
obstruction yeah so metamask and other
wallets uh EA wallets they would be like
it would be great if they started
looking into account abstraction like
they can start with uh 7702 with getting
all users to also include some kind of
code uh in their EAS it can be like very
simple like recovery or gas sponsoring
and everything but crucially it will uh
to get a production experience of having
uh and managing a fleet of smart
contract wallets because up until now
like most wallets have only been
managing like the private Keys part and
did not look at users wallets as smart
contracts and uh after that like there
is no reason the for metamask not to use
ERC 4337 wallets uh for people who who
are starting now like you you probably
don't need to steer them into using 7702
if they are newcomers you can just get
them to deploy an upgradable proxy smart
contract wallet and uh as long as long
as it's an upgradable proxy they can
evolve together with uh account
obstruction like versioning and uh and
all that uh
right what do you mean by other code in
Brackets section at
7701 yeah uh this is referring to this
slide I I can I don't have slides uh so
uh you can have and any number of code
sections in an eof account uh so any
code that does not have a role assigned
to it as we described it is just an
external code so it can be called by
like some other contracts or other
addresses can just call into this code
and if the code is assigned a role you
cannot call into this code it has to be
executed as part of a EAP 7701
transaction right it's uh so this is the
difference between like other code and
code with an assigned purpose in terms
of account
obstruction now the last
question what's the point of separating
validation and execution in ethereum's
account obstruction if conflicts can
still arise during execution even after
validation under restricted rules yeah
great question like uh the problem is if
the execution conflicts uh with each
other you can get a state you didn't
initially want for example you can get a
transaction to revert but the
transaction is still valid and another
thing is execution is not limited not
sendbox it can be a 20 million G
operation and it can write all the
storage in the world uh validation is
limited and sandboxed so we extract all
the validations because we assume they
are small functions relatively like I
don't want to say pure but clean
functions that only access accounts own
storage and if they were to collide that
would make block invalid the difference
between the H reverted transaction in
block and invalid block is the
difference between a block Builder being
dosed and somebody having to redo his
action