# Exploring the Future of Account Abstraction

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 26:39
- Watch: https://streameth.org/watch/yt-hLlFNuqMUAY
- YouTube: https://www.youtube.com/watch?v=hLlFNuqMUAY

## Description

Discover the journey of Ethereum's Account Abstraction (AA) from inception to its current state, challenges tackled by ERC-4337, and future roadmap: modular native AA approach for L2 and L1, and EOA improvement (EIP-7702).

## Transcript

[Music] [Music] hi everyone so yeah today uh so I'm a yav from the etherum foundation I'm a researcher working on account obstruction and today uh with today in this talk and the next two after afterwards we're going to talk about the state of account obstruction where we stand now and uh where we headed right so uh first we're going to briefly look at where it all started so the prehistory it all started in uh so it started at the same time ethereum started actually so uh V when vitalic wrote about ethereum before the launch you already blogged about uh what accounts should actually should ultimately look like so this was the first mention of account obstruction and then H in the year in the following years until 2020 there was a lot of u a lot of research done on this a lot of interesting proposals and data kept evolving then in uh 2021 vital came up with a new idea um trying to get to account obstruction and start EXP experimenting with the counstruction models without protocol changes which uh makes it much easier to get started and uh this has led to ERC 4337 the idea was to get to full account obstruction uh without protocol changes but also without compromising on sensorship Resistance by relying on H by relying on a on centralized Rel layers so that's uh that's what we've been doing with LC 437 now sensorship resistance is it requires having a permissionless m pool because otherwise someone could always sensor you but it's a but it's a challenge and the reason it's a challenge is that uh full account obstruction means also abstracting the validation and when you abstract validation then when you abstract the validation um it means that it depends the Val the validity of the transaction now depends on mutable state so it can so this enables a lot of Dos vectors A lot of denal of service attack vectors that need to be mitigated just to give a quick example of such attack and why we need to uh why we need to solve for this is uh let's imagine an attacker implementing an account and this account depends on this account uh has a dependency on a flag stored in a singl tone smart contract so every account using this implementation looks at the same flag uh in order to determine transaction validity and also flips the flag and now the attacker sends thousands of such transactions on an ongoing basis and every time such transaction gets a when a transaction gets included it immediately invalidates all the other ones so they can't be included in in chain and now they have to be dropped and they have to be dropped without paying for gas because they're not valid so we can't charge them but we but they still caused a lot of validation work for every node in the mol and this can easily escalate to a point where the nodes cannot do any useful work so we need to mitigate for this kind of attacks and uh the way to do it is to separate between validation and execution so that we can limit what can be done by an account before execution before it agrees to pay for the gas now the question is what do we want to uh what do we want to limit what kind of restrictions could we apply the easiest the easiest way the no-brainer is let's not let's not let the account access any state outside the account until it's until the transaction is valid so it can only access its own storage it cannot access any other contracts and it cannot access environment op codes such as a time stamp or a block number so this solves the denial of service problem but it also limits usability quite a bit so for example you cannot support popular use cases such as paying for gas using an erc20 token because you cannot look or modify the balances of that ec20 token during the validation so it so over over a couple of years we H worked on a developing a set of rules a set of validation rules that support as many use cases as possible while still mitigating denal of service and this enables the use cases such as paying us with the tokens and many others that wouldn't have been possible otherwise uh the me so the way it works is H these rules are applied at the mempo level H the mempo will only propagate transactions if two conditions are met one the transaction must be valid and two it must also comply with the rules so a valid transaction in an account that doesn't comply with the rule will still not be propagated now fast forward to the present where are we now so ERC 437 went live last year and it gained quite a bit of H quite a bit of adaption there are now uh there are now over 20 million accounts mainly on different layer tools and a lot of activity what's interesting is that uh most of this transaction the vast majority of the transactions actually you also do gas obstruction using pay masters which greatly improved the ux for situations like onboarding we are obstructing gas and this alone this alone is a great Improvement and over the so um over the past two years we also saw a lot of great projects a lot of awesome stuff being built by the community some of it is H things that we really couldn't imagine before and uh I'm not going to dive deep into this because one of the next two Talks by Tom is is precisely about the diving into the numbers and interesting use cases so be sure to stay for Tom's talk another recent development is that the public account obstruction mle just went live so before uh uh so the idea with the ERC 4337 has always been to have censorship resistance by having all the bundlers connected in one peer-to-peer Network one Mol where transactions get propagated and this way you are pretty much guaranteed that someone will include your user operation but until recently every bundler maintained its own private M poool and they were not really connected while we were still working through the coordination of uh of this mol and recently with a with an effort uh with a coordination effort for the protocol uh three of the bundler imple three of The bundler implementers Ether sport candid and then silius uh managed to uh finally bring the to finally bring it up so now we have this mol and uh thanks I want to thank these three teams and I should also thank uh I also thank fast lane that made it possible to uh to have the mol on polygon so uh thank you and uh this way we have so now we have the mol running on several chains and more are coming soon I hear that also other bundler implementations are going to join the mle soon so we'll see it growing now what does the future hold where do we go from here so one thing we saw is that uh many uh so we started seeing layer twos introducing native account abstraction in order to have a better integration more gas efficiency now the problem is that they enshrined the modified versions of ERC 4337 which are not standardized and this started calling causing a wallet fragmentation so suddenly we see wallets pretty nice wallets that work only on one chain and cannot be used on any other and that's really not great for the ecosystem because uh if you found a great wallet you like you should be able to use it on every chain not only on one chain and then look for another wallet for something else so we realize that this is actually not an account abstraction specific problem but a coordination problem that could cause issues in other fields which led us to start the rollup Improvement proposal also known as roll call that's a coordination effort with all the layer tools to coordinate standards that would benefit the entire ecosystem after we started this uh process and H brought the layer twos on board we started also working on RP 7560 which is a an account obstruction proposal native account obstruction proposal for layer tws and a layer two that that uses this will get uh will get a better better user experience and H better gas efficiency now what about layer one so I said that rip 7560 is an RP it's for layer twos but for for layer one we are thinking more long term because we at ethereum are notorious for taking our time to uh taking our time and H get to get things right on layer one so this is no exception we have a proposal called EAP 771 which is native account native account obstruction using e and the dependency on eof means that it's not going to happen very soon because eof is not included in pectra but once it's enabled it's going to enable a it's going to enable interesting account obstruction models and not limit us to just one and it will enable things like a improved sensorship resistance through inclusion lists which are not uh which are not uh possible to support otherwise with something like 437 so that's something to look forward to and we're working on it um I'm not going to dive H further into native account obstruction but there's a the next talk after mine is by Alex and this is specifically about Native account obstruction proposals so he's going to dive much deeper into this uh we also saw strong demand for for for supporting EAS to give EAS at least some of the benefit of account obstruction now it's not possible for an EA to get the full benefit of account obstruction because ultimately it's an e eoa it still has a single key single ecdsa key that cannot be rotated but we can still give it quite a lot of the benefits and that's exactly what EAP 7702 does it enables adding a code to adding code to an EA without validating its H key so now the account is actually both a smart account and an EA and this works great with ELC 4337 because it allows us to set the code to turn any EA into a into a 4337 account which uses the 457 M poool and this enables the this automatically enables use cases such as pay masters now you can have an EA that uses 437 pay masters so you can H for example pay gas with tokens or get gas sponsorship for an EA transaction and on this one uh there was already a talk by light client that took a deep dive into it so if you're interested you should check out the video for this one now how does it all fit together we have a so we talked about several different account obstruction models which would probably be confusing for a h for someone looking into what to implement so the answer answer is that the account the the account model is identical they all use the same kind of Separation The Kind the same account model same gas obstruction everything so it's actually quite easy to uh build an account that supports all of them so you develop it once you can deploy it everywhere on every chain whether it whether it has some kind of native account obstruction or not you can use it uh you just use it use it everywhere and once it's deployed it's a once it's a deployed if a chain later if a chain on which the account leaves switches to a enables a native account obstruction it will be able to benefit from uh from the improvements now the goal so this seems like moving a bit beyond the account obstruction but it's actually part of the same thing so the goal with the account obstruction has always been to go be to go beyond the individual uh Beyond improving the ux for the individual chain and to also solve the cross chain problem and in a minute you'll see why it makes sense to use a count obstruction for this and anyway now that we have the basis for it it's time to start really solving H solving the chain obstruction problem having great uh cost chain ux so the Cornerstone for this is that the count obstruction enables trustless bridging it's uh so with account obstruction you don't have to trust a bridge operator you no longer need these multi- Bridges and the reason is that H the operator is not in the loop the operator is not a part of the transaction in the sense that the message sender is never the operator the message sender is always the user's account as opposed to the EA case where a message Bridges have to sign the message bridges are a part of the transaction and are trusted in a sense so with this the user create a transaction that actually operates on several chains so we have one transaction running on multiple chains and the bridge operator can execute it on all the chains on behalf of the user and even uh transparently deploy deploy the user's account on chains where it doesn't exist yet but the operator cannot change the account in any way the account because the account self validates its own deployment and this means that now the account can validate the transaction on on each of these chains so once it validates the once it validates transaction it means that the bridge the bridge operator is not at Liberty to mess with the transaction in any way so because it cannot uh because it cannot mess with the transaction we don't need to worry about uh we don't need to worry about the bridge operator so the bridge which leads us to lead us to um to bridging uh like to trustless bridging and to permissionless bridging so you don't need a permissioned bridge operator anyone can join and be the bridge operator including the user uh including the user or anyone else H as for the Gaz with pay masters it means that uh you can have the you can have the account paying for the can have the account paying for the gas using a pay Master on each of the chains so the user only pays on the source chain and uh the bridge operator uses a pay Master deposit to pay for it and and and then ends up getting compensated from the user's deposit on the source chain so that's how we can solve bridging and using a few more standards some of which are being developed and some will need to be developed we can really solve the ux problem and make it making it seem like using one chain the idea is that uh the user will never have to select a chain in the wallet and it will feel like really using a single chain some of these standards are so among them are key stores with key stores the idea is that you can uh run any so with Kyo uh you can you manage your credentials for your account on a single chain whether it's layer one or whether it's a designated ZK layer 2 you can manage it in one place and know and H use the same credentials everywhere if you rotate your keys they get rotated automatically on all chains H another thing thing is that the user can send a single transaction that runs on multiple chains and doesn't even doesn't even need to hold the native coin of each of these chains to pay for the gas so there so it feels like using only the source chain the wallet can also use a for use something like intent solvers for more complex operations so uh using in for example performing a complex uh a complex trade on multiple chains is possible with in intense solver but unlike with the EA case here the account can enforce the result and revert if it uh if it doesn't like it which means that uh the user doesn't have to take risks when using intents another thing is that addresses uh that addresses will become chain specific addresses that's a standard that is is nearly ready with chain specific addresses the uh the address includes the name of the chain the name of the chain on which the address reses sides and uh this chain is uh so and uh it actually uses an ens name of that layer two to give an example let's say we have a user on yes we have a user on polygon and uh that wants to send usdc to a friend but the friend lives on a the friend uses base so with this the friend gives the gives the user an address that looks like 0x1 1234 at uh at base. e and the wallet knows how to deal with it so the wallet uh the wallet can look it up it knows how to bridge to base H so the user pastes the address the usdc gets sent and there's no need to uh there's no need for the user to even notice that they're actually not on the same chain in order to achieve this um the ens name for each of the layer TOS actually refers to a few records that help with chain Discovery the reason we need this is H we're going to live in a world where there are many layer tools and many more coming up like every month so we don't we don't want to configure the wallet to support each of these chains we want we want automatic Discovery so with ens we can get just that we can have for example a we can have a record for a standardized Bridge so now the wallet can look at an address and find out exactly how to bridge to uh how to bridge assets to that chain it can have a record for for RPC provider so if the wallet needs to transact on this uh unknown chain it has an RPC to the to use and then it also have a and it doesn't even need to trust the RPC because there's also going to be a light client implementation a ccip based light client implementation that can validate the chain the chain State against its layer one contract and this is also a record so the wallet is able to communicate with every chain and it can communicate with with every chain without previously knowing about it by just looking at an address and then resolving everything knowing how to trustless transact on this chain from the users's perspective It all becomes one chain so the so account obstruction is already here it's already thriving native account OB suction is coming and uh account OB suction is already improving ux on many chains now but in the future in the near future hopefully it's also going to improve the ux across different chains and in the future it's going to feel like we're using a single chain rather than multiple chains but with the scaling that comes from our Layer Two strategy and all this without sacrificing decentralization and censorship resistance uh all right and I think we passed our time so any questions yes thank you yeah thank you so much for the wonderful session um we start the first question how are we supposed to develop a 433 4337 wallet in the in in the entry point contract keeps changing yeah so the entry point contract will not keep changing the last change the last change was hopefully the last ABI change ever unless some critical secur bug we're unaware of is discovered and forces us to to change something which can always happen but unlikely at this point if not then maybe there will be some minor bug fixes inside entry point but not something that would affect ABI and require changing wallet implementations do you think we will need l2b sty risk dashboards for different wallets to make users aware of what these wallets actually do definitely I think L2 bit is doing a very important work on H on layer tws and we will need this for uh for wallets it's actually not just for wallet we need someone to verify that the wallet does what we expect it to but also when we transact across different chains even though we want to make it transparent to the user these not all chains are equal and some actually are are riskier than others l2b does a great job highlighting these differences and we'll need uh and we'll need to also account for that so yes does 772 require the wallet provider to be okay with upgrading the eoa to a Smart account what happens with a wallet provider of upgrade practical practically ah wait I'm not sure I understand so you so uh maybe the person who I mean I mean yeah they the it does need I mean yes of course uh you need to add the code in order to use it so you need to add 4337 code to the account and then you can start using it as a 4337 account but I'm not sure I understand the last part of the question maybe the person who raised the question do you want to elaborate a little bit oh maybe I mean maybe by saying wallet provider that talk about the wallet as in this the part that runs off chain on the user machine in which case yes the wallet has to be uh the wallet has to be aware of the implementation but the wallet is the one setting the implementation so now the wallet the wallet will determine what code gets set into the EA and we'll use whatever it can also support great let's move on to the next one what is the plan if there is a critical vulner vulner vulnerability on the entry point it would be a black swor that would compromise all wallets at the same time and by definition it can't be revoked in Mass yeah you could ask the same question about uh about something that doesn't use something like entry point because because I mean what happens if there's a critical protocol vulnerability in ethereum and then we also and also a lot of accounts get compromised so hopefully we audited things uh enough to prevent such such occurrence and if it does happen if it does happen then yes we will need to H we'll need to to deal with it at some point where it's where it becomes such a big thing on the network you have to fix such things by hard Fork so let's say EA was compromised somehow we would need a hard Fork to uh to deal to deal with it because we're not going to allow a situation where every account on ethereum gets compromised so it's quite similar whether it's account obstruction or EA what's the main technical challenge of key stores next one the main technical challenge is being able to access layer one state during validation and the way to do it is by uh by having an rip supported by all the layer tools to access layer one state and then you can have a key store on layer one this is a so there are currently two two such proposals one doing a l1s load meaning you're able to load a slot from a layer one contract and there is also remote statical that would let you perform a statical on layer one either of these proposals would enable H would enable key stores efficiently because now the validation will be able to actually use that and this will become a part H so a part of the proof of the proof used by the layer two will prove the correctness of uh this lookup okay the last question should we adopt AA now considering future features you mention might not be backwards compatible I don't recall mentioning features that are not Backward Compatible and actually our goal is to make it Backward Compatible it's uh so if you develop a 4337 account now H you'll be able to easily make it work with a future uh Native account obstruction proposals and I think the time to adapt it is definitely now because otherwise you're not going to get the benefits of uh even things like 7702 let alone H chain obstruction stuff