Time for Native Account Abstraction on L2s

Transcript

[Music] [Applause] hi um hello everyone my name is Alex I work on account obstruction and today I would like to make a case that now is a great time for full native account obstruction across all layer twos so we have been using EAS for better part of like 15 years and the question is is it the best we can do or we can do better uh to answer these questions uh I will ask five more smaller questions they are what are we trying to obstruct away what are we trying to enshrine in theum protocol uh why are we doing it uh what makes the account obstruction solution

complete and why now is a great time to do it uh so my question is what is the worst user experience of having some money in human history so there was an island in Micronesia where people would use like giant Stone discs uh to trade for food I argue it's not a great user experience uh other Islands use seashells they collect it on the beach probably not good for inflation and right now we are using often like metal sheets or just papers with 12 words written on them and this is our store of Val I'm sure this is not a great user experience for a lot of users so what is wrong with externally owned accounts in general uh the most common way to back

them up is to write the seat phrase or private key on a piece of paper and keep it somewhere uh the EAS provide immediate and full control of all your assets there is no kind of control in any gr granular granularity uh it is very hard to replace your private key your secret uh and you just need to move your assets and not all assets can even be moved you can have like voting power delegated to your address on some Dow you can have an air drop coming your your way and they are part of the protocol if you want to change how EAS work we need to change the ethereum protocol itself so for their users if they lose your their private keys they lose their funds if they expose their private keys they lose their funds if they send uh assets to an

incorrect address they lose their funds if they do it on the wrong chain they lose their funds and if they even created their SE phrase with a wallet that has a broken seed generator Randomness they will lose their funds so you do anything wrong lot of funds right away uh we don't have any time to waste in adopting a native account obstruction uh externally own accounts they don't provide the convenience that users are used to get from technology in this day and age uh in my opinion the even existence of externally owned accounts is kind of a technical depth for us it's an implementation detail from early days of blockchains that is still widely used

today uh and we should uh expect to phase out and uh deprecate externally owned accounts but that's not what we are doing instead we are creating more and more dabs that rely on E recover that rely on EA based uh uh transaction types and we adding new transaction types with basically every ethereum update and it is frustrating uh because uh EA become more and more entrenched in ethereum as time goes by and in a short period of time it will probably be impossible to replace them like for for example uh driving on the left side of the road in the United Kingdom and some other countries there is so much

infrastructure built around it that it is impossible uh to reverse this decision and convert to driving on the right side of the road or using a metric system or imperial system the United States people are so used to it that it is impossible to ret 300 million people to use a metric system uh so all that would be kind of theoretical if we could just keep using EAS forever with their bed user experience but that's not the case uh us do have an expiration date uh making a change to how ethereum Works takes very long time transient storage was created in 2018 got main it in 2024 six years to make this change to eum and quantum

computers are known to break uh elliptic curve cryptography and they are expected to go online somewhere next decade so NSA saids 1334 five as a deadline for postquantum cryptography it seems like 11 years are a lot but if you haven't started yet that's not so much time to convert the entire crypto Community to a new kind of cryptography uh so if you don't want to wake up to a news like that with North Korea acquiring uh quantum computers and having to make an emergency hard work we should start start doing something about it right now um so let me dive a little bit into uh what do we need to abstract

so your account consists of four major roles that are assigned to it this is your address this is your identity on change this is what actually holds your assets uh this is what authenticates you the private key authenticates that you can control this asset uh you also pay gas from the account that is sent in a transaction this is the definition of a protocol and the execution uh excuse me can can can you hear me one two one two um yeah great and execution uh is also part of what your account does so uh current uh etherum transactions uh allow you to make one execution frame meaning

like you can call a destination with some kind of call data uh and you if you want to transfer two kinds of tokens you need to create two transactions you cannot badge them uh naturally together uh we want to abstract away all of that uh we want your address to be derived from the smart contract account that you are using you deploy a contract and this is your account now uh you authenticate your transactions by using a method in this wallet called validate transaction uh your account does not need to pay gas for its own transactions you can have a different account uh contract uh that we call it pay master and you call a its validation function and this contract can accept paying gas for your transaction

and for execution you just pass some data to your wallet and your wallet can do whatever it wants on chain to execute multiple transfer swaps whatever you come up with uh so for for all of you who are uh following ethereum development all core Dev calls eaps you may ask yourself didn't we just solve account obstruction with EAP 7702 so it's a fairly new AP but the answer is yes but actually no if we look at the table uh we didn't change how address works it's still controlled by your private key you still authenticate spending even a 77 or two transaction with signing an ecdsa private key uh you do obstruct away Gas payment but not in

generic way you allow one EA to pay for the other transactions EA which is kind of glorified meod transaction but not a natively uh abstracted solution but you have full uh execution abstraction you inject your code into to your EA and execute uh this code as part of your transaction this is very interesting E I suggest you read up on it if you didn't um so having a gas abstraction being done by a second EA is like putting a car inside a car uh and trying to implement some kind of spending limit uh for an address that still has a private key behind it is like putting a door in a field you can still take your private

key and overcome all your spending limits or anything um for those who know our work on ERC 4337 you may ask yourself didn't we solve account obstruction with ERC 4337 and my answer to this is yes but there is Nuance uh ERC 4337 right now provides account obstruction to anybody who opts into using it uh but the ethereum ecosystem and the protocol itself don't seem to favor it and there are downsides of using a non-native uh solution the first and foremost it's um increased gas cost using uh user operations robbed by a bundler it adds

uh uh at least 20,000 gas overhead uh on top of what your transaction is doing and often more and sometimes it's critical for users to have the cheapest way possible and the best one is EA right now uh there is a philosophical issue of increased evm code trust surface because uh entry point is a solidity code there is a single implementation and it's like your wallet and pay Master they need to have a full trust in it and even though it was thoroughly audited it's still a solidity code that you trust um a lot of adbs don't uh support smart contract wallets right now and uh there is a some kind of censorship resistance risk because we see clearly that in protocol

inclusion lists require in protocol account obstruction uh so building in out of protocol account obstruction is like building a house on top of a office building and getting everyone to use account obstruction by keep while keeping the barriers is like not very good for the users many users will just give up and order for the default EA path uh and my next argument is that layer twos need to take charge here and implement it first uh layer twos will be the first one to adopt many changes and they will be the ones to shape the fut future of evm and ethereum and there is a number of reasons for that uh I believe first one is that uh blob and

blob transactions have brought a huge scaling breakthrough to ethereum recently uh for L2 specifically uh and other is that um l2s are becoming more safe bottle tested decentralized and there are less and less downsides or trade-offs for using layer TOS uh there is also now A Rip r rollup Improvement proposal process within the AF that allows them to coordinate upgrades to the their Network the way eaps were used for three main net and layer tws are competitive there are a lot of layer tws and they compete against each other while etherum Manet uh struggles to oscillate and not to innovate uh what is inspiring that some layer TOS already today uh don't support

e they start as smart account only and they are having no issues with it being in production we already see that the vast majority of account obstruction uses is is on side chains or rups there are not on eum mainnet um so first of all we need to leave gas relays bundlers uh servers in the past in ERC 4337 uh the account obstruction is achieved by actually keeping a bundler server who actually sends that ethereum transaction to the entry point contract so you still have an EA in your account obstruction system and you stuck with it this is part of your account obstruction

now uh what we should do is to eliminate this step and make sure that transactions are abstracted by Design so smart contract accounts they can initiate uh a transactions without any EA being involved a user creates an account abstracted transactions it gets to the mempo it gets included in a block it gets executed uh let me remind you what steps the ethereum transaction validations uh take right now so there are five major steps uh signature verification uh account nons uh verification balance verification that you have enough balance to pay for the G of this transaction uh base fee check that you

are paying a sufficient gas fee and non incrementation so if we were to write it its solidity we could write a function like that and that would be our validation functions but right now it's not part of your transaction it's part of what protocol does for you outside of the transaction uh instead what we are suggesting is an RP 7560 which splits uh ethereum transaction into two parts uh validation and execution so on top you see a legacy transaction and validation is uh a part of the protocol defined outside of the evm context in Native account abstraction transaction the validation is part of your transaction it is a code that runs in your evm and read State

write to state but but its execution defines if your transaction is valid or not if this Frame reverts or returns in valid value this transaction cannot be included in the Block it's not reverted it's just not a valid transaction to be included like you send a transaction with the wrong signature and Nots it's not part of uh valid uh transaction set um so an example if you were to run this code in solidity uh in with a terminal uh and you had like login function aable or something if you were to send regular transaction you would never touch the validation frame function you have one frame and this is your only top frame with validation if you uh call execute function the validation has to run and

it is executed and if it Returns the correct magic value only then your transaction gets included in a block uh there are three possible frames uh one optional frame is account deployment if you don't have any code deployed in your address yet uh for the first transaction you are making uh your fact account fact is being called and your code is being deployed the second step is required uh it is a validation step where your smart wallet is given the information of the transaction including signature and Fields and it makes a check that uh somebody actually initiated this transaction and signed it in a correct way and an optional step of providing a pay Master validation which means using a separate contract to pay gas for this

transaction uh and I want to reiterate that execution frame is not Target that you call you give this data to your wallet and it can do whatever it wants it it is comparable to EAP 77 or2 however with true native account obstruction there is one implementation that you permanently have and uh in your code as opposed to a ephemeral uh code that you can inject and uh G obstruction I reter it here uh mean that uh can you hear me one to no still okay uh gas abstraction means that there is a separate contract that is uh acting as your gas tank and

it can accept or reject the charges for a transaction that is not related for example an app can sponsor its own transaction uh we achieve this by creating a transaction type as most of the Innovation right now in theum uh that has some fields that are specific to account obstructed type so you need to specify the other of your wallet because it's not derived from signature anymore you need to specify the contract that you are using as as entries in your transaction so if you are using a pay Master you can provide the pay master and data that it will receive if you are using a deployer you can provide a deployer address like a factory and data for it and you need to specify limits

not only for the execution but also for the validation frames of your transaction uh what does this RP mean for existing ERC 4337 ecosystem well uh most importantly uh our main goal right now is to make sure that native account obstruction uh is fully compatible or as compatible as possible with the existing apis and existing ecosystem uh we fully expect that some chains will go for it and Implement native account obstruction soon While others will take years or just opt out of it so both ecosystems are expected to stay live for a long time and coexist uh peacefully uh and

for chain that uh do adopt native account obstruction we want to make sure that uh they have a straightforward migration path uh also and it is important that uh ERC 437 bundlers uh keep their role in RP 7560 we accept them to uh take a role of me Searchers who will build uh bundles of account obstructed transactions and provide them to blog builders on their respective chains uh a bit of context ERC 4337 has become pretty big itself so it includes some things that are crucial and it includes some things that are quality of life improvements and we didn't want to uh pile on uh protocol

developers so we split the specification into M multiple modules uh for like grad adoption and like optional adoption across the chains so RP 7560 is the core of the protocol this is where the most important changes are defined and there are like plugins for it um RP 7711 defines a version of it that is friendly for decentralized public uh permissionless mols uh 7712 reintroduces the 256bit wide multi- uh dimensional nonsequential nones these are part of the ear for7 specification right now and we are also working to bring back the

signature aggregation there is an RP in draft right now uh I want to dive a little bit into the uh decentralized public mle issue uh I have a couple of minutes here so the problem with using evm code to validate your transaction is when the block Builder is trying to build a block if your transactions validity depends on the state of ethereum transaction in the same block previously can have an effect on your transaction validity meaning that it is impossible to build a block because transaction the green transaction uh change the state and the blue transaction depends on the state to be valid so now this block is invalid and you need to repeat this process uh

indefinitely under denial service attack so instead for uh for mempo networks you would need to split the transactions into two part they are not Atomic and validations need to go in a separate space in the block where they are all executed together in a kind of sandbox where they not allowed to uh touch each other storage there is ERC 7562 that defines the sandbox and it is fully compatible with the sandbox we did uh for ERC 4337 um okay there is a great talk by vitalic ban on history of account obstruction some APS he mentioned uh

account obstruction discussion started in EAP 86 two letter EAP uh very long ago a full fledged account obstruction was proposed in EAP 2938 however it used an OP code to separate validation and execution of a transaction meaning that uh RP 7711 would not be possible uh we would not be able to split the transaction into two parts in a block and recently there was a hotly debated 3074 versus 7 7 or2 uh debate in allore Dev that ended in 77 or2 being considered for inclusion for prag update uh that I mentioned already allows a transaction to inject temporary

code in an EA address and execute it um what do we expect for L2 developers to do right now uh we expect them to get in touch we expect them to check out the RP to provide feedback uh to check out the draft implementation of it uh take Parts in roll calls and just build it build it in their networks uh an inspirational quote a year from now you will wish you had started today we need to start now uh we need to implement account obstruction before that is too late and some links uh our GitHub where the actual text of the RP is uh held and our Discord which is the

best way to contact us uh thank you thank you so much Alexander amazing talk and beautifully handled technical small technical issues so guys now we have some time for Q&A let's say two three questions so ask anything you want to the topic of course so ah there please hi uh great talk quick question I

don't understand how when you create the sandbox so you've you validate the yeah that' be great if you can go back okay right here so you do the validation first so that you know that these are valid transactions but is the ordering of the execution now in important how do you how do you figure out the ordering yeah so the ordering is important it stays the same so validations and executions they do run in the same order uh and there are no transaction in between here but the validation parts of the transactions they are all executed before the first execution of the first transaction starts because this code is

sandboxed it only can access the storage in itself in a wallet or in a pay master so they cannot overlap so we know that validations don't uh invalidate each other but execution code is free so do you mean that by validation it's not validation as in is this transaction I mean maybe it's the same thing valid does validation mean will execute that like it doesn't um will it be included in a block you might want to have some extra checks in execution frame and revert for example in validation you checked your signature Nots and general intention

that it is the right thing but then in execution you find out that you don't actually have these tokens and and then you just revert your transaction but this transaction was valid in terms that you agreed to pay gas for it and you agreed it for it to be included in a block Okay so execution right if transaction five reverts it doesn't block the whole block no it doesn't block the validation frame remains in a block and the changes you made to your own storage inv validation block remain there yeah and the execution did revert got it thank you okay thank you guys oh yeah okay one more

question thanks a lot um so um are there are there any is potential issues or obstacles you have saw through with relation to the execution Shing um could you repeat the plus um if if there are any potential issues you need to you need it to address with relation to execution Shing like the separate this uh kind of thing yeah or any anything related to the native account obstruction yeah the big issue with that is that most transactions kind of assume that once you start you are in your transaction and will have to finish uh but uh it has to change and like ERC 437 wallets already know that this is

actually how entry point in ERC 4337 works right now you we execute validations and then we execute executions but for Native transactions there are things like transient storage uh gas refunds uh warm cold storage access that are defined on a pair transaction level and then uh for us it is an issue so if you write a transient storage in a validation frame you will get it again in the execution but it's not visible in between so it is a kind of like strange state but uh yeah I I think that because of we had couple of years to experiment

with uh entry point in ERC 4337 I expect that many developers are already like familiar with the U peculiarities of this uh thing thank you so much for uh nice curious questions and special thanks to Alexander fad please Applause to him thank you thank you and we'll quickly skip to the next talk we'll stay at uh the account abstraction will in 5 minutes I'm just being sad okay so let's wait five 5 minutes

hopefully maybe the rain will come over somehow so see you in four or five minutes