Exploring the Future of Account Abstraction in Ethereum

Transcript

[Music] all right hi everyone so thanks for uh coming for staying this late uh and today I'm going to talk about uh the counstruction road map so uh we're going to cover uh we're going to start with h how it how ELC 437 got started and then H discuss uh where we are now and what we learned along the way then talk a bit about the future where we are headed next uh with a focus

on Native account obstruction although it partially overlaps with the previous talk so I might skip ahead a bit and talk about uh how what what are we going to do with EAS and what are we going to do about layer one which is a bit more a long-term topic so where did we where where did it get started uh back back in 2021 more than three more than three years ago vitalic had an interesting idea uh what if instead of instead of trying to uh build account obstruction into the protocol while there are a lot of unknowns maybe

we can start without a protocol change and create a layer above it in order to Start experiment with a count obstruction this led to a few month of brainstorming which resulted in the first version of ERC 437 and the goal with 437 has always been to have a full account obstruction keep it fully decentralized and not compromise on sensorship Resistance so let's see what does it mean uh in order to have censorship resistance uh we must have a decentralized mol we can't rely on anything permissioned we can't rely on any uh we can't rely on a centralized

server because then uh someone may be censored you can't have white lists for implementations everything uh everything needs to be permissionless now uh why is this a challenge so to understand the challenge we need to First understand what is full account obstruction when we say full account obstruction we mean that every aspect of the account is abstracted not just execution uh not just execution but also things like validation so the validation the validation itself becomes a becomes evm execution becomes State dependent and to compare this to ea uh with an EA validation is really simple

and very strict it does exactly it has exactly one valid flow each transaction must be signed with an ecdsa key the the the key is not revocable so it's the transaction that is valid a signature that is valid is always going to remain valid and it's a and then the nons must be correct and the account must have enough if to pay for the transaction that's it it means that validation doesn't take a lot of computing power and if a transaction is currently valid in the M Pool it's very likely going to remain valid uh when you try to include it in the block unless it's being replaced by by another transaction from

the same EA with account obstruction it's a different story because uh now since it's evm execution first of all uh there's you need to spend a lot more computing power in order to um in order to even validate the transaction while propagating it in the M Pool and then also uh it could and also the transaction could become invalid after it was previously valid and and if this happens in large quantities then we have a Dos Vector we have a we have potential denal of service that could take the mol down and make it unavailable and since we don't want to introduce a centralization by starting

to sensor certain addresses or something like this we need to figure out a way to stop this at a protocol level so the first thing we realized that we had to to do is to separate validation and execution we need to know that we need to know up to a certain point the transaction is not valid yet and then we need to to enforce certain restrictions to make sure we don't spend too much uh computing power on it and after a certain point we say okay now it's okay now the transaction can keep going we know it's going to pay we know we know it's going to pay for to pay for its uh for the work so we separated validation execution but that's not enough because uh since transaction can become invalid

we need to make sure it doesn't happen in large quantities and I'll give I'll give a couple of examples of how this could happen since um since when the validation itself is evm execution consider an account that uh where the validation function checks the block number and it requires the block number to to be equal to the current block number and now someone H so someone sends thousands of transactions from different accounts with this implementation to the men pool they send them H with the current block number so now they all get evaluated they got they they all uh when they propagate across the mol they are tested by all by by

every node so every node spends some spend some computing power checking it and they're all valid so they get propagated but then then by the time the next block is built the block number has changed and now all of these thousands of transactions are no longer valid so what would the Builder do so now the block Builder now tries to include the first transaction say oh it's not uh this transaction is actually not valid itth it reverts inv validation so I'm going to drop it I'm going to try the next one and this and the same thing happens over and over so the block Builder actually misses the slot when will not be able to even not be able to uh to even build a block in time and the

entire M Pool did a lot of work propagating these transactions without ever getting paid um so another U another example would be using storage you could have I mean let's say let's say we prevented the access to block number we prevented access to certain op codes but then uh but but then uh we have an we have an we have accounts that all look at a flag in a singl tone contract they require this flag to be equal zero and then so uh the transaction is only valid if this storage slot has zero but then the execution part of that like in every in every transaction it's going to

increment this slot which means that these transactions are actually mutually exclusive they are all when EV valuated separately they all seem valid so they all get propagated but as soon as one of them gets includ included all of the others have to be retested and dropped which means that a single that by at the cost of a single transaction writing to a single slot the attacker can H cause any amount of work to all the nodes in the network so you see we need uh we need to mitigate many such use cases so when we started working on H started working on ERC 457 we spent a long time trying to come up with a rule

set for what you can or cannot do during validation during execution you can do whatever you want but until you validated it and you agreed to pay for the gas you need to um you need to have certain restrictions to prevent such uh such denal of service attacks after spending a long a long time of this H we came we ended up with a protocol it was safe from denial of service but it was also quite restrictive then spent even more time H trying to relax the rules finding ways to make it uh finding ways to uh to enable more use cases while remaining dose resistant and we ended up uh so we ended

up with a rule base that actually enables the quite a lot of use cases some of which we didn't think it would be possible with the count obstruction validation and still hopefully it's h and hopefully it's safe we have yet to uh we have we have yet to see a reason to believe it's not so uh I hope so and um we have and all these rules ended up in an ERC the ELC 7 uh 7562 this ERC contains the rules that are used for that are used for ERC 437 as well as um um as well as RP 7560 uh the reason we we actually we

separated it for a we separated it to a different ERC for two reasons one reason is that um one reason is that um we we needed to serve multiple implementations of account obstruction the rules are actually similar whether it's native account obstruction or or ERC 437 so it's the same rules and another reason is that uh the account obstruction U both ERC 437 and 7560 could actually be used without these rules because these rules are prot they protect offchain entities in this case the MEO nodes or bundlers but uh it's an but they are not

needed on chain if somehow a transaction ends up on chain with an account that violates these rules that's fine it doesn't put the chain or anyone else at risk the only risk was during propagation so there are there are actually use cases the valid use cases where you want to use the account obstruction on chain part without these rules for example intent uh intent solvers intent solvers are typically a centralized server and so they can mitigate denal of service in different ways uh with using a centralized methods and they don't need these rules they also cannot really obey the rules because they need to H do certain things

in validation that would not be possible so being a separate ELC makes it uh uh makes it possible so where are we now um we so we launched uh H we launched ERC 457 on H on mayet of most all major evm chains back in March 20 23 at uh e Denver and since then it gained quite a bit of ction so last time I checked we had like 5.3 million accounts deployed 22 million user Ops user absent and dozens of

projects being built on it ranging from H different wallets with different focuses to um uh pay Master services to many other things and including some interesting privacy protocols so it's quite exciting to see what people are bu are building on it and uh right so sorry yeah so over the so we learned a few things uh observing this uh observing all of these transactions uh the most interesting thing for us was to see how much gas obstruction is used we we started with the assumption that gas obstruction is really important we

learned that it's even more so because H almost all of the transaction almost all of the user Ops H actually have they specify pay Master which means that they use some form of gas obstruction and this gas obstruction it it could be gas sponsorship such as a gas such as a DB sponsoring the gas for its users it could also be things like the user paying for the gas using an ec20 token using a token pay master so almost all of these user Ops use that H use some form of gas obstruction and it validated the design choice we made early on to make pay masters a a core component of this uh

system uh recently we released the version uh version 0.7 which unfortunately was a breaking and an AI breaking change because we needed to mitigate for a security for a potential security risk that uh the previous ver version didn't cover now hopefully this is the last breaking change so I hope soon we'll be able to move the elc2 final and we also recently launched launched the the mol the peer-to-peer part of the mol the actual Network we launched it on test net it's being tested and after some more uh testing and fuzzing it's going to launch on a

main net across different chains another thing we learned is that uh there is a demand for layer tools to donate account obstruction uh we knew that at some point it would have we would have to have an EAP or something to to somehow get to Native account obstruction but uh we didn't think it will happen so early and then we saw layer twos uh we saw some layer tws implementing their own they took ERC 437 modified it in some non-standard ways and enshrined it into their protocol and while this was exciting to watch it also had negative side effect as it turns out these

networks example ZK sync or star or starnet that implemented modified version of 437 they started getting a really nice wallets with great ux such as Argent or braavos but these wallets only work on one or two chains and that's not great for users we don't want this kind of fragmentation we want user we want H wallets to compete on a to compete on better ux on better security not on who supports which chains users should be able to use the same wallet across every chain so we realize that we need some sort of standardization here and that we can't wait a few years before doing that then we also realize that uh this

problem is not unique to account obstruction we since we strongly believe that the way to evolve evm is through layer tws we want layer twos to innovate and to uh to make modifications to evm but if uh but but we still need to standardize the way that it's being used because otherwise uh contract developers wallet developers developers generally have to start developing separately for each chain and this will not be great for the ecosystem because most of of them will Target the most popular chain or two and ignore everything else so we started working on rip rollup Improvement propos

proposal uh with the idea of standardizing certain things across uh across the layer to ecosystem while letting them innovate freely uh Within These uh within certain standards and then we started working on H RP 7560 which Alex already talked about now uh RP 7560 is basically ERC 4537 in an enshrined way and it started as very big and monolithic RP then we then we started making it more modular we stripped it down to its uh stripped it down to to the bare

minimum usable part which only separates validation execution and then started moving everything else to separate uh to separate U separate RPS which are optional and can be used by different chains as needed uh we're going we are working on a GU based implementation and I know that other clients are also working on their own implementations so we we hope to launch uh the first devet uh the first devet soon and then people will start uh be able to start experimen with this model and of course we would love to get the communities H feedback on this from

layer twos from layer ones from the community in general so where do we go from here U so we have this uh minimal version of RP 7560 then we um we are working on different uh when working on different RPS Alex talks about them a bit talked about them already such as H doing all the validations without uh uh before doing any execution which is actually not needed for a single sequencer uh chains that don't have a mol uh because uh it mitigates an attack that they do not H that they do not have

to care about but once you have a m pool it becomes critical to have this for those mitigation other things are like 2D non say that uh are not absolutely needed although they uh they enable some interesting use cases ranging from a sending transactions in parallel when they order doesn't matter H to more complex things such as a privacy oriented multi-tenant account where the nons can actually be a ZK nullifier and we've seen some interesting use cases it's also needed in order to be fully compatible with ERC 4337 which has this feature uh yet another one is aggregation signature

aggregation uh which means that we could end up with a block that uh we could end up with a block block that only has one signature verifying the entire block and this could save a lot of uh data cost for layer twos uh another one is related to layer one I'll get to that later and there's a so and there are a few other areas of research we are working on I think the most interesting one is inclusion lists so inclusion list is uh is something that I think is very important in in the ethereum ecosystem uh we have a problem with sensorship uh and it's not uh it's not

getting better the way ethereum is going to fix it is using inclusion list which basically forces block Builders to include certain transaction after they they've been waiting the mol now doing it with EA is difficult and therefore it hasn't it hasn't happened yet the are teams working on it doing it with a count obstruction is a much bigger challenge because now transactions can become invalid in infinite ways and if a transaction ends up in a inclusion list but then gets invalidated then it's impossible to build the next block so we need to be very careful about that so that's an area of research we've been working

on now what about layer one so there is a uh there is value in enshrining C obstruction layer one as well such as a gas saving because layer one gas is quite expensive and of course things like inclusion list can't be done if the protocol is not aware of coun obstruction so uh so we need it and in the future we also need things like Quantum resistance so it's uh so the protocol needs to start moving away from ecdsa and account obstruction is the way to get there but we know it's going to take a lot longer making any change to a l layer one is a very lengthy process um so we also we are also okay

with it taking a long time because of the way we designed the 7560 it is fully compatible with the count model of 4337 and therefore it's easy to write an account that is a an account that is both a 4337 account and a 7560 account which means that users can deploy this account across different chains whether they have a native account obstruction or not and on chains that don't if later they get uh if later they get a native account obstruction if later they decide to adopt it the account just becomes more efficient but doesn't need to be redoy the address stays the same so that's why it's okay

if it takes a if it takes a long time now why now why is layer one different why can't we just use 75 60 there are there are some different tradeoffs one is uh uh one is solidity ABI in uh ELC 437 we had to enshrine certain we had to enshrine certain ABI for the account we had to because it's an ELC so you have a validate user op function that they account must Implement and on layer twos it's okay to also enshrine it at the protocal level because layer TOS already and Shrine abis for different reasons they have for example pre-compiled with an AI on layer ones cord devs are not okay with that

and they won't have different system so we um so we have EAP 7701 which uses eof instead so on one hand it introduces an eof dependency meaning that uh that we have to wait longer until it can be included on the other hand it uses a validation section so we so it doesn't need to know anything about function names about abis and for eways uh for eways there is also a lot of demand for doing some account obstruction uh for for doing some C obstruction features such as batching or a gas obstruction and while we know that H it will never be a full substitute for

account obstruction because for example you cannot rotate the keys you cannot turn it into a multi or something like this but uh but you can have certain features and E7 702 does just that it's um it's a way to use it's a way to make the account behave at the EA behave like a 4337 account for the duration of a transaction which means that now it can use the account obstruction M Pool as is it doesn't require any changes to entry point and then for gas obstruction it can use pay masters exactly the same pay Master without any modifications so just like account obstruction H just like smart contract accounts now eways will

be able to use the same gas obstruction um we are talking about how to do future migration uh and why it would be needed but uh I think we don't have time to cover that now so um so in conclusion um so in conclusion we've been working for the past three years on a on a count obstruction for ethereum both for layer one and Layer Two without compromising sensorship resistance and uh we we see this as the path to make ethereum future proof in multiple ways we'd like to keep collaborating with u both layer one cord devs layer twos and with the rest of the community so if you

have any feedback uh feel free to reach out to us here or on every on telegram or any other Channel all right thank you [Applause] thank you so so much for amazing talk unfortunately we are running a little bit behind schedule so we'll have time for just one question the most curious one so is it hi thanks um regarding the 77 uh 02 we all know that it was quite like rushed right the proposal uh the recent one um was there any thought through

regarding the blind signing aspect of of that blind signing for the users when they sign the you know transaction in metamask or anything like that and back they just see the hex codes so they do not understand the implications and what is going to be done so just whether it was like s through or discuss this kind of things yes it was discussed quite a bit and I can't and I can't say that I'm happy with the current uh with the current design I think that uh it would it would have been best if if the signature was over the over the code and the address rather than the address itself cuz then at least you know what you're signing currently with the currently signing an address it is

entirely possible that on different since it doesn't also cover chain ID it's entirely possible that you'll have a different code on different chain or maybe no code on some chain then something else gets deployed but the way the authors look at it is that uh you're supposed to on so it becomes part of the wallet so the wallet should never sign something that itth does not agree with the wallet developer is the one who deployed it across different chains in the wallet developer should also make sure that the code checks for chain ID basically it delegates all the thrust to the wallet thank you thank you so much uh so please thanks to your

[Applause] viice okay now we need two minutes just for switching the uh yeah for the technical break and I know that you are looking forward to seeing Mario hav so give us 2 minutes [Music]