Native Account Abstraction in Pectra, rollups and beyond: combining EOF, EIP-7702 an... | Devcon SEA

[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