Native Account Abstraction with EIP-7701 - Alexander Forshtat

Transcript

[Music] Okay, my name is Alex Forstet and I'll talk about native account obstruction and our road map to achieve uh account obstruction endgame for Ethereum. So a quick reminder uh what uh is even an account what we are doing here. So account has four main roles in Ethereum ecosystem. Uh first it is your address meaning it's your onchain identity. It holds all your ether assets, voting rights, whatever you do. And it performs an authentication of your actions. Uh it uses a private keys you have uh to and you sign your actions as the transactions onchain and account perform

them for you. Uh account is responsible for paying your gas because in Ethereum whoever makes the transactions pays its gas and account also performs the execution. There is a target contract that you are calling from your account. uh what we want to abstract is all four of those things basically. So uh an address becomes an address of your smart wallet contract. Uh the authentication is performed by the code of this contract that is deployed on chain and gas payment can be performed by a different contract uh that you specify as part of your transaction and execution is done by your smart wallet contract. So it can interpret your inputs the way it wants. It can execute a batch. Uh it can read some onchain state and so on.

And where do we stand in regards of account obstruction in year 2025? So we actually already have account obstruction live and it is built on out of two components. One is ERC 4337. Uh this is a protocol that is built on top of Ethereum. It does not modify Ethereum protocol itself. It has been live for two years now since March 2023. Uh and we recently released a new version specifically to target uh the new EAP EAP 7702. Uh AP772 in turn does change uh the Ethereum uh mainet consensus rules uh by allowing your EOS to inject smart contract wallet code into their address.

So the account acts as a smart contract for all intents and purposes. And it works great with ERC4337. It can use pay masters to pay for EOA transaction gas. It can use bundlers to put the transactions on chain in a decentralized way. uh and we are seeing quite a lot of adoption of these technologies already. So uh in two years we have seen like exponential growth on account abstraction. Uh we have seen hundreds of millions of user operations made by tens of millions of wallet across the chains we are tracking and there are many chains we are not tracking. 7702 has been live for like 20 days now but we are seeing a very good adoption rate and it's probably going to be one of the most used EAPs in the future. Uh so with

all that said uh what can we actually improve upon by achieving an endgame native account obstruction. So the first is obvious we can improve our adoption rate. Uh we can also minimize the attack surface of this solution and this will increase our security. Uh but one of the most important things I think is that uh current account obstruction solutions uh still rely on EOAs. So our bundlers they must be an EOA to actually put your user operations on chain and 772 accounts why do they do have code now they are still fundamentally EOS they have a private key that controls this account and one of the reason this is very important is that uh EOS do have an expiration date

uh sometime in the future we will have quantum computers and EOS use a cryptography that is known not to be quantum resistant and we'll need to replace them uh anyway and we can also minimize the technical overhead and friction that we have in the current solution. So one thing is we are building uh account obstruction with the tools that are designed to build dabs but account obstruction is not a DAB and we have to cut corners to make things work onchain and offchain and sometimes there are new EAPs and they are breaking something for us and we need to release new versions of entry points or bundlers to accommodate the new hardworks and sometimes important new EIPs uh for example EIP 7805 that's introducing a

censorship resistance uh layer for Ethereum. Uh we cannot benefit from this EAP by being user operations that are not part of the native uh account obstruction. And last but not least uh the gas efficiency by using uh an onchain entry point contract. Uh we have like around 20,000 gas overhead compared to equivalent transaction uh done natively. uh one example of inefficiency I want to highlight specifically is uh bundler front running. So we are seeing it happening more the way user operations work you need uh to keep them secret and uh a bundler needs to provide them directly to block builder to avoid being

frontr run and we are seeing more and more that uh for example on polygon bundlers are not always able to do that and me bots are successfully front runninging them meaning they didn't do the actual bundling but they getting all the profits uh from the 4337 bundle. Uh now that we talked about it, we can start thinking about the design of a native account obstruction solution together. So let's recap what are the onchain contracts that are entities of an account obstructed transactions. So first is the most important one. This is your smart account. This is your wallet contract that's holding your assets and authenticates your transaction. But what if you don't have it deployed yet? In

that case, you need to use an account deployer which is a factory contract uh that will deploy the account on chain for you. And what if you don't have Gaz to pay for this transaction? Well, then you need to specify a so-called pay master contract. And this contract will look at your transaction and decide to pay for its gas or not. And it pays for gas. This uh contract is optional. But we are seeing that the vast majority of user operations are using a pay master contracts and are actually sponsored. Uh now we need to provide some data to each of these contracts. So we are designing our new transaction type and for this transaction type for Ethereum we need to provide the addresses and inputs for these

contracts. So we are defining uh the following fields for our transaction type. The addresses of an smart account that is sending your transaction. The data that is specific to this account. Same goes for the deployer and for the pay master. We don't define what you put in this data. It can be anything in any format. It can be a signature. It can be an init code for your account. It could be an ERC20 token approval using a permit function. Uh and now we combine all these fields and we end up with this uh transaction uh type. This is a new transaction type and the new fields are involved. So basically all fields uh are new. Uh now that we defined this transaction uh we said that we want to

validate this transaction using a deployed onchain code. We are no longer using uh a consensus protocol to validate a transaction. We need to run some code and that means that this code needs to have access to all of these fields. Uh now previously you had some uh limited uh access with origin op code or call data op code to the inputs of your transaction. But now we need more. So what we are introducing is a set of op codes specifically to read your transaction input. We call them tx param op code family and they are actually very similar to the call data of code family uh with minor difference. They are also accepting as an input the

identifier of a parameter that you want to read. So to be specific for example if you want to read a pay master data we say that pay master data identifier is seven and then you want to see the size of pay master data you do seven par tx param size and then you can read this data into your memory by doing seven tx param copy uh and now assuming that your your contracts looked at this inputs verified all of them and are happy to accept this transaction now we need to design a mechanism M for these contracts to explicitly accept your transaction.

We cannot rely on your these contracts being called and not reverting because you can reach a fallback function or some public function that doesn't revert. So you need to have some very explicit mechanism and what we're adding is an accept ro code. This op code is very similar to return but it takes one more input. It accepts the input as an input a specific role that your contract agrees to perform during this transaction. So for example, if you're running a pay master validation, uh the execution of this call would end with accept ro pay master validation. Uh very well. So now that we define this uh contracts, addresses and

roles, we need to give each of these contracts an opportunity to act on their transaction. So and validate your transaction. So let's look how validation works for EOA contracts. So on top you can see when you're sending a transaction from your EOA, it still needs to be validated. We need to check the signature of this transaction, its nons, its balance, the gas fees and gas limits. And all of it is done before your transaction is loaded or executed. This is done by the protocol by the block builders. And then it performs one single big uh execution frame from your UA to your target with your call data.

Now we have a more elaborate scheme for native account obstruction. Your transaction is actually split into up to five top level call frames. So we start executing your uh specified contracts one by one. We specif we deploy your account. Then we validate uh the transaction using that account. Then we validate that pay master accepts gas fees. And only after these three frames completed successfully and accepted their roles, we proceed to execution. And the critical part here is that if something is not valid, so meaning something went wrong during the validation frames, this transaction cannot be included on chain. Like this is different from a reverted transaction. EA transactions can revert,

but they still paid gas and they still got included onchain. Invalid native account transactions are not inclusible on chain at all. So how complex does it look like? The most complex frame uh flow that we can have looks something like that. you have up to five frames as I said three validation and two execution frames. I'll get to that later. Uh and that means that the validation of your transaction now depends on Ethereum state and storage of the accounts uh involved in the validation. However, the transaction is no longer uh validity is no longer defined by any cryptography as part of the protocol and the cryptography is moved onchain to the EVM layer. And of

course the simplest way if you already have an account if you are not using premaster you will only have uh arrows five and six and only have one uh account in the flow. Uh now speaking about like in a future version of solidity what this might look like this is a pseudo code this doesn't exist in solidity. uh we could use a language feature such as an annotation or some keyword for like payable to specify functions that take a role in account abstraction. So users will not need to use the op codes directly. Of course they would specify which functions are validation functions, which functions are execution functions and they would use like for example TX

roll uh parameters to figure out uh where they are located. And the example on the right is like imaginary terminal of Ethereum. If you try to make the legacy transaction call to this contract, you would reach execution function and you would only run uh one log statement. But if you're doing a native account abstraction by making a call to this contract you have all the frames run. So you have validation executed and then you have execution uh performed as part of your transaction. Uh so there are six main components for transaction validity. The first ones the first two are same for EOS and for native account abstraction.

We check the balance and uh and nons. However, the balance is a balance of the contract that is paying for your transaction. So, if you have a pay master, we check the balance of the pay master. If you have uh only account paying for transaction, that's one. But after that, it gets a little more complex. If you are doing your first transaction, you are deploying your account. We check the deployer contract accepted your role. Uh after that, we check that your account is actually deployed. Uh we check that your account accepted its role and performed the validation frame. And then we if you provided a pay master we also let it check and only if all six of these uh perform correctly uh is your transaction considered valid. Uh so these are the main parts of native account extraction.

There are some technical details that we can dive into uh and I wanted to highlight them. So one thing uh pay masters get an extra frame. So you may know that when block builders execute an EOA transaction, first thing they do is they pre-charge the maximum possible gas cost of this transaction from your balance and after the transaction completes, you get a gas refund. So we want to do something very similar with pay masters. So pay masters get an a frame after the execution of your transaction to finish their bookkeeping tasks to see how much gas you actually consumed and it can also be used for pay master to observe the changes that your transaction made and the pay master may decide to revert your execution.

However, do note this is happening after the validation of your transaction. So transaction is already included in a block and is paying as gas. Pay masters cannot retroactively refuse to pay gas for a transaction. And this frame also has access to environment variables that are unique for this frame which is execution status and execution gas cost. Uh uh another aspect uh we wanted to give more uh control to smart accounts over the validity of their transactions. When you sign an EA transaction it becomes valid and it is valid indefinitely until you use the nodes. So the only way if you could cancel theoretically an account uh a EOA transaction uh is to sign another transaction with a

different nons and send it uh first maybe with a higher gas fee. Uh we wanted to provide a way to invalidate transactions and provide the specific range. So we added valid from invalid until parameters to transaction payload. Uh next I want to highlight how we integrate with EAP702 and also EAP 2930. So of course you can use native account obstruction together with 7702. You can uh provide an authorization tpple as they call it and you you can use an EOA as a smart account and your code will be deployed uh using EIP702. However, what brings these two EPs together is they introduce a transaction payload that is a dynamic

list of arbitrary data and previously there was never a need to observe this data on chain. So this data remained uh available only before outside of the EVM. Uh now we need to observe this data to validate the transaction signature. So what we are proposing is to uh provide the hash of this list to TX param op codes so accounts and pay master can validate the data. Uh one more thing is the road map for migration from ERC 433. So uh the architecture is very similar between these two proposals. So we expect only very minor changes between the application layer and uh uh and all that. But we do require an onchain

update for accounts and pay masters. Uh we expect that most pay masters will be able to just support both of these protocols for a foreseeable future during the migration period. Uh and these protocols will probably coexist uh during this period. Bunderslers however get a little bit different role. Uh bundlers will get even closer integrated with blog builders and they will provide uh account obstruction structured transactions to the blog builders. Uh I want to highlight RIP 7560. This is a very similar uh document. However, this is a roll-up improvement proposal. So this is a native account obstruction designed for layer 2 rollups. We were able to make it separate because we have two EAPs that

uh reserve pre-ompile addresses and transaction type specifically for roll-ups. Uh we cannot reserve op codes for roll-ups. There aren't that many available op codes. So we have two designs but 7560 we do have an implementation of it for guest and argon clients and if you have a rollup of if you're interested in implementing it you can do it already. uh and you don't need to wait for Ethereum layer 1 to adopt 7701. Uh another document that I want to highlight it is widely used now with account abstraction. Uh it is ERC 7562.

It provides a standard to send box the validation frames and it prevents this validation frames from randomly invalidating or invalidating each other. H and this is very important for blog builders or bundlers uh to be able to validate uh multiple user operations or native transactions uh in parallel uh without a risk of uh mass invalidation. Uh it's not part of it's not a core AP and it's not part of 7701 but it can be very helpful. Uh now we obviously talked about quite a lot of complexity and we are proposing this complexity to be moved to Ethereum layer 1 and of course we need to justify that somehow we need to elaborate uh can

we actually remove complexity as well when we are adding native account abstraction to Ethereum and I believe that we can uh so first thing that is obvious like ERC 4337 is becoming a bigger and bigger part of Ethereum but it is a fairly complex mechanism So by adding 7701 we can let it supersede ERC437. But looking a little bit further more long term we can see that EOS do have an expiration date. As I said uh in around a decade it is expected that quantum computing will become real and then ECDXA cryptography will need to be replaced and this can be a very painful transition for a blockchain. However, if

we add 7701 now, uh we can duplicate EOS in 10 years of time a lot more painless and easier way and that goes with all the complexity of duplicated legacy transaction types which we have like four of them and we will not need to introduce a new EOA type specifically for a new cryptography and uh specifically EAP701 does not have any specific dependency on EVM. It does not require changes like a eof or anything and it can be ported uh relatively easily to any future virtual machine if uh there is a need to migrate for example a risk 5. So uh yeah I think that's uh that's

it for me. Uh thank you very much and happy to ask here your questions. [Applause] [Music] [Applause] Uh I have two question. One of them is the gas consumption of your modular validation logic. Um how expensive it looks like with modular stuff it could be a little bit more expensive. That's I'm thinking you also talk about the front running risks. I couldn't I didn't realize how you are actually fixing that. uh because at the end of the day the logic is going to be visible and you need you know um kind of advanced cryptographics solutions to mitigate all this. Thank you. Yeah, thank you very

much. Uh so about the gas consumption uh the part where we have like onchain entry point contract that has to manipulate all of the user operations in memory onchain. This is gone. So it's it's not replaced. It's just gone and we don't spend this 20,000 GS on it. Uh, additionally we don't require actually the bundler signature anymore. So that is uh let's say five six thousand gas that we don't need. Uh so we are cutting all the excess gas consumption. This like simplifies it. So you only pay for gas that you actually consume. So your call data it remains the same like the bytes you are putting

on chain this is what you are paying for. you don't have the ropper around it and making multiple frames doesn't cost you extra because the call data is already there. It's already getting into memory. So you just paying guys as you go. uh about the uh front running like the specific mechanism of front running here uh yeah afterwards I wanted to yeah a specific front running I'm talking about here is that the bundler collects all the user operations and it has to include them in the block and but instead of working directly with the block builder the bundler has to broadcast this uh bundle to the mele uh now with 7701 there is no bundle as it appears right now each transaction has

its on validity. There is no bundler that rob them around. So you could frontr run individual transactions same you can frontr run EOA transactions but the bundler is not sending anything to the mele. The modeler is presumably connected to the block builder the way m builder is connected and uh like it cannot be front run unless the block builder specifically chooses to uh uh rock pull it. Uh right y yeah I wanted to add something. So yeah regarding font running as Alex said there is no bundle to be front run. So if there is no bundle there's no front runninging issue. H but regarding gas consumption actually we measured it. We wanted to see what would be the overhead of doing something similar to what you are doing

with an EOA now like let's say you don't use any extra features like pay masters or special uh so wanted to see what would be the overhead of using such transaction type and having all these possibilities. Uh so we implemented an account that behaves just like an EOA. It does easy recover on a on an immutable key. So no storage access which means it's identical to validation of uh and then it executes a token like a token transfer. And uh the Gaz overhead the GU over if I recall correctly I don't remember exactly but I think it was like 2,000 Gaz. It's like 2,000 GS more than you than it would cost you to do the same with EOA which is it's negligible

compared to the value you're getting out of this uh transaction type. So it becomes really like Gaz Gaz becomes a non-issue I think. Yeah. Uh so uh I have two related questions. One is that you say that a invalid transaction does not include is not even included in the blockchain. So who absorbs the computational costs of having to validate and what bounds it because you know it's a contract code that somebody needs to execute and if it's not valid then what happens? So it looks like a avenue of a uh denial of service attack. Uh and the other question which is a little bit related

to this is that uh so if uh so back when so back when we were discussing this stuff in the beginning of Ethereum of why why we didn't have native account abstraction from the very beginning was that even inclusion in the meool is something that needs to be pre-validated. So currently on Ethereum the uh conditions for validity are the nons and the signature which can be validated even before inclusion in the meool. Whereas if you allow like during complete code to be executed just for that on the meool it's not even clear

whether by the time it gets to be included it is going to be valid. So how do you protect the mampoo for being uh so the first question was about uh how uh who validates it. So of course the node that accepts this transaction in the first place will need to run the validation code. Uh like the validation code is limited. You have like 50 100,000 gas uh maybe. So like it's normally just ECDSA signature recovery for in the simplest form. Uh so what uh like this is a cost that is comparable to what nodes need to do now uh more or less plus like storage lookups. uh if it gets more complex the nodes can just

decide on what they just don't want to accept. If you get a native transaction with like 10 million of validation guys, it's very reasonable for a node to just refuse it without running the code. And this is one of the things that uh 70 5762 is defining like you should not accept uh transactions with more than uh a few thousand. And yeah, I I think Y wants to answer this. Yeah, I wanted to um yeah, I wanted to give um an answer about the meool about the DOS because that's like most of the work that we've been doing on 437 which also applies here. So the transaction the transaction has validation frames. Now each frame has its own gas limit. So let's say you are sending a 5 million gas transaction but uh you only need 100,000 gas for

validation which is more than enough for uh for almost any validation. So you're going to set the gas limit for validation to 100,000 and now and the meool and the mempool will have a rule saying that okay we don't even accept like I mean even though the transaction would be valid with any amount of validation guys the meool will not propagate it. So in the me pool you limit the amount of unpaid work to a certain to a certain fairly low number. That's so that's one thing is that uh I you limit the amount of work and the other thing is that uh the ERC 7562 the mele uh the mele restrictions the mele validation rules uh apply many apply

many restrictions where the goal is to make the cost the invalidation cost of a transaction high enough with an onchain cost so that you cannot have a mass invalidation you cannot invalidate a large number of transactions for free which would be a do vector. So for example, you have things like uh you can't access any storage during validation. You can access it later after you agree to pay for the transaction, but until you pay the gas, you can only access your own storage slots or storage slots that are associated with your address like a catch of your address with something which is the way mapping works. This means that uh for each like in order to invalidate transactions for multiple accounts, you need to write to multiple

slots. In addition, environment op codes are banned. For example, you cannot check the block number or the time stamp during validation because that would be that would make it easy to have transactions that invalidate at the same time. So we have a so we have rules that ensure that it's order of n like if you in order to invalidate n transactions you have to spend onchain gas in the order of n. And this is the so this is the dos mitigation here combined with limiting the amount of uh gas spent right uh once uh EOA uh accounts are deprecated what will be the approval

mechanism for transactions because like even even now if we go to multistics or even to native uh AA implementations like in Empire wallet right uh it's still in the end there is still a signature from by your private key. Right. So uh so it still goes back to AOA like in the end like uh and the second question what will be the level of native programmability of access rights to account like who like who can who can do what basically can we like go like to some like really atomic level so to say like okay if there is no transaction in one year from this account then there will be like this guy who can sign transaction instead. Yeah I

can ask for that. So first like the postquantum cryptography it's an active research field but there are signature algorithms that are not based on quantum that are based on quantum resistant uh assumption. They are not based uh on elliptic curve or anything that is known to be uh broken by quantum computing in theory right now but in in practice uh presumably in the near future. But this is like we we have like years like to do that. But I think um like the US government like NIST says that in 2030 the government should not be using uh quantum like pre-quantum cryptography and they certified a certain number of like

cryptographic primitives to use. So I assume that this is what the contracts will do but they will do it with their EVM code. They will do it on chain that we will not need to introduce any of that cryptography to to the Ethereum blockchain. And the second question uh like your validation is a tur incomplete code. So you can do basically everything but it has a very like we it is restricted if you want to use a mele as we just discussed it is restricted to what kind of storage it can use. So as long as you keep the storage for this algorithm in your account, you can do anything again as long as you consume the number of an amount of gas that block builders are happy to risk with like just run the validation with a

chance that it reverts in the last op code after like 100,000 GS and they get nothing for running this code. Uh then like you can uh you can do the access control that you want. Yeah. So basically that's why it's called account abstraction. We abstract it from the protocol to your code. So you can implement the dead man switch for example what we what you described. It's uh it's not something that the protocol will implement. We are agnostic to it. You can add this code to your own account as part of a validation function. You can say in a validation function like if if the last transaction was more than a certain time ago like you know I mean you can't check the time during validation because of the mele

rule but you can return at a validity time which the protocol will then enforce. So you can save the time in each transaction during validation and then return and then if if something if another key is used you can have an extra key that you give someone and this key only works if the time between the current transaction the last one is beyond one year. So this is this is something that is really easy to implement in your own account. That's because we abstracted it. We're out of time guys. Uh seems like Alex managed to wake up the crowd but feel free to uh catch him after the talk and ask any additional questions. Okay, great. We are applause. Thanks, Alex.

[Music]