Alex Forshtat / DCxPrague

Transcript

right hello everybody my name is Alex forat I work with the ERC Force resarch 7 team on account abstraction and today I will talk to you about the new uh Pro uh project that we are working on that's called native account obstruction so when you talk about Native account abstraction there are three uh main questions that we want to ask ourselves one is what are we obstructing the second one is what do we enshrine and make Native and the third one is like why are we doing it uh so let's dive into it uh first question is what's even is an account for us when we're talking about it so uh account for us is an entity that represents a user on blockchain we are talking

specifically about currently externally owned account so it represents the user with an address address has uh like it's a 20 byte string uh it is known it the address that holds Val is ether and tokens and this this address is controlled directly by uh the private key of by ecdsa private key uh this is the address that will be executing a transactions which means calling the Target contract with call data that is provided by the user and this is also the address that will be charged for gas uh during the transaction the transaction is paid by this account and this is currently all part of the

ethereum protocol it is encoded and enshrined as a protocol call this kind of accounts uh so the next question is what do we abstract away so basically we abstract all of the things away and when we say abstract we means that we allow contracts to change how these things are done so you still have an address uh this address is controlled by smart contract there is a contract deployed to this address and now this is a contract that holds tokens and value and does that so this is not different from a multi like gnosis or Argent uh however we abstract away authentication entirely

which means the transaction will be valid if the functions that we defined in this contract called validate transaction returns a correct value and not by a given verifying the given private key a signature uh we also obstruct the execution instead of like just Pro user providing a Target and a call data to invoke it we give the the data to the smart contract to decide what to do with it and we also abstract the Gas payment meaning that uh it doesn't have to be the contract that is the an account who pays for gas we allow other contracts to pay for this gas other entities to pay

for the gas of this transaction um there are Limitless endless uh possibilities with a cent obstruction but I would like to give some examples that are not really possible with externally owned account and they are like one authentication we have one way to authenticate the transaction and for some users this the one we have the signing a transaction every time can be way too complex let's say there is a game that wants to introduce a gaming session if uh every action in this game is a transaction you will be constantly clicking your metamask confirm confirm confirm with smart with account obstruction you can generate a Target specific uh like session key that enable

the site to do what it wants with the targets that you approved and for other use cases uh this authentication with the single private key can not be strict enough like a corporation we want all accounted controls to he a multi seek with some threshold uh and uh we also enable that natively currently they would have to still own an operator private key that controls their multi so it creates also a lot of friction uh we natively enable ways to recover these accounts uh we can finally have a native UI for social recovery and another like major

feature that is missing for externally own accounts is replace replacing your key so let's say you had your 12 words written on a piece of paper and you kept it in a book and now you are not sure if anybody saw them so you want to change your key but you also have like positions on exchanges and you don't want to migrate all the assets to new address but you want a different secret to control your account we will enable that with account obstruction but with EA it is not possible uh the great opportunity for to pay for gas for uh dabs that want to onboard new users who may not have a correct asset or any assets on a given chain uh previously in most cases there was still a process of

you need to get this I know girly optimism tokens to make a transaction on this chain if you get an airdrop of our tokens uh with gas abstraction you can pay in other tokens or D can outright sponsor specific actions of an account and with extracted execution we can have use cases that were previously basically impossible like a an account can make a batch of transactions and it can use the results of one transaction as an input to another it can read on chain State during a transaction execution which is almost impossible to achieve with

externally owned accounts uh so we all have that what does it mean to make it natively what does it mean for us to enshrine it when we say that we make an account obstruction native what we mean is that uh an transaction is fully initiated by a smart contract with smart contract account it does not rely on any externally owned account so once a user creates a transaction it's broadcast to mempo it's picked up by a Blog Builder and the ethereum virtual machine itself performs all the actions so we have C 4337 and it already does account abstraction for us however in red you see that uh the bandler servers that are

uh ERC 4337 like workhorses they own and operate and externally owned account when they make a call to the entry point contract this is a legacy transaction this is type two transaction that they sign and the bundler server pays gas for this transaction and an entry point contract compensates this externally owned account with a value on chain however this Ste enshrines and establishes an externally owned account and its private key as part of our account obstruction solution so there are some issues with it so what are the main issues like the first and

like it's a big one for us is gas efficiency because there are uh rppers and rppers and the layers of abstraction here uh the user operations of ERC 437 they are not very gas efficient there is an overhead of around 20,000 gas for user operation uh and it often gets uh bigger than that and the best way to remove this inefficiency is to actually put all this uh protocol into the consensus layer of ethereum uh another issue is is what we say code bug risk so entry point contract in ERC 4337 is still smart

contract it has been audited and formally verified but still there is a risk of a bug and normally when there is a bug in a smart contract just all uh of the smart accounts that would rely on this entry point uh they would need to migrate there can be a catastrophic event or less catastrophic but that would be a lot of overhead for them to change the implementation of uh ERC 4337 that they are using however if it's a part of a protocol it's implied and it's explicit that uh it works and the core developers of ethereum or other like rollups will be responsible to making sure that this is safe and it stay safe uh going forward uh another thing is uh

some evm op codes don't work well in the context of ERC 4337 for example te's origin Returns the account that made the transaction in the first place however with ERC 4337 it would return an address of a bundler an EA that is not relevant to a transaction in any case it just happens to be a server that created this abstracted uh uh transaction uh another one this is a growing concern is that sensorship resistance like as ethereum is going towards a proposer Builder separation uh it becomes easier to sensor transactions and there are ways

to uh mediate it with uh inclusion lists uh however they all target uh transactions and uh What uh user operations do they are bundled together in a single large blob transaction uh which is not transparent for the inclusion list so so bundlers can sensor individuals in user operations and uh we will not be able to provide the censorship resistance we want with the non-native account abstraction solution and then last one but not least some networks that are starting right now they may decide to go without EOS uh there are I think already

some networks that do that so if you want if you can start now and not have this Reliance on a specific signature scheme and just allow arbitrary validation of transactions some we want to do that and it would not be possible if we would still require a server to sign transactions uh that bundle your operations together you can read uh on this link an article from vitalic uh on this topic uh I'll move on and I'll have it later so what does uh validation of a transaction looks like today so this is a hypothetical code from the previous presentation also of what are the steps uh that the transaction does when it's

being validated if if it was written in solidity it's not but if it was written in solidity this is more or less what it would uh have looked like uh it would uh verify the transaction signature it would uh verify the account knows it would uh verify that account has enough balance to pay for uh the transaction that is happening it would verify that uh the transaction has a sufficient B fee and then would increment in nons and only after that the transaction proceeds this is what current transactions externally owned account transactions do uh in ethereum uh so uh can can we do more so in order to achieve account obstruction

natively the first thing that we do is we separate the code that is running inside the transaction into multiple uh smaller frames so the concept the frame is uh you can think of it as a subtransaction a small transaction that is part of a bigger one or a a separate call to a function that is top level like you have multiple main functions main entry points to your transaction so on the top is how transactions work today there is an validation that is happening in the protocol and on the right you have a single top level execution frame of of a transaction so you have a Target contract and you call it with a value

with some call data and you provide a gas price and gas limit to this call and this is the top frame and all other executions happen from there for for example if you call transfer in the erc20 token so the call data would be a function of like transfer in this token uh and as I said validation includes a signature nons balance gas limits and gas fee payments so when we go to abstr red transaction uh we divide uh it into two big groups of frames the first group is validation frames uh in validation frames uh what we do is uh we validate an increment nons separately on chain and a smart

account if need to be uh we deploy an account so if this is a first transaction the user is doing we deploy code at an address that he said he want wants a code in uh then we provide the details of this transaction to the account uh and the account has run some evm solidity code to decide if transaction is valid and then if if the contract is provided the contract pays for GES provided and we call it a pay Master contract we provide this trans transaction details also to this contract basically to ask him like this is a transaction that is happening are you willing to pay for it

so only if all four of these uh calls uh succeed we proceed to include this transaction in the block the transaction cannot be included in a block in if any of these steps fail and uh once they are complete and theaction is inside the block we actually perform the inner call that is the execution frame and also it's a detail we also allow the pay Master to do some operations after the uh execution so it is also considered to be an execution frame but the main thing here is the uh actual account execution function that is being called uh okay so this is a hypothetical

uh code and hypothetical uh CLI where if you were sending a legacy transaction type to this contract to the execute function only the execute function is actually run but uh this is shows an idea that if you send a account abstracted transaction to this contract it will actually run the validate transaction function and only then it would run run the execute function so it's a single transaction that calls two functions as a top frame right uh so the four uh validation frames that we have in this current state of native account obstruction

proposal are nons validation so so there is a smart contract that manages nonsense of every smart account uh and this is the contract who is responsible for verifying and incrementing the nons of a transaction I said about account deployment account validation we Define a function signature this is validate transaction and we pass in the transaction hash and an encoded transaction and it must return a special value to indicate that it accepts a transaction and the same thing happens for a pay Master the function name is different but it accepts the same parameters and it return the same it it can also return context for later we

will get to that uh after uh so next uh abstracting the execution frame I talked about it briefly uh instead of invoking the Target contract directly account provide abstracted transactions provide this call data to the smart account and this allows smart account to interpret the input and perform action that it decides um I don't want to say the word intense but it can be something in that case that you tell your account like what you want to do and account can interpret it arbitrarily uh next so one issue that we have doing it is we need to allow blog Builders to

construct uh good blocks and we need to do it fast secure and efficient uh so the validation function of externally owned account which checks a signature and a Nots and all they are all obviously isolated look at you can look at them separately on different states and they cannot intervene with each other this just one account it has its own Nots and another one that has its own Nots and signature this is not necessarily the case with uh account obstruction because the validation happens on chain and it has access to block chain State transaction can uh change each other's validity uh so and blog Builders don't

have a lot of time to prepare a Blog they cannot spend hours and hours iterating over combinations of transactions that work uh so in order to allow them to find blocks uh we do a couple of things uh the first thing is we uh try to send box each validation function in a way that uh the blog Builder can parallelize validations so it can run uh different transactions on the same state across different CPU clusters so without having to talk to each other and we see the individual validation of a function if the fun if the transaction is valid or not so in this example uh all transactions have

passed validation function successfully except for transaction C so then when the blog Builder builds a block it just does not include the transaction see in a block but now uh what block builder needs to do it needs to validate the entire block it needs to make sure that uh transactions did not interfere with each other because they were validated separately and if the send boxing works and we manage to isolate transactions this is the picture we would get if the transaction passed a validation individually it passes validation inside the block with mixed with other transactions however if the uh sand boxing fails this is an example a

transaction a sets the value of some variable to one and all the other uh transactions in their validation functions revert if x is set to one then these transactions were all valid individually but as a block together only one of them can go through and the others will uh not work and this also presents a denial of service attack Vector because it's it can be very cheap for an attacker to fill the mol with transactions that are mutually exclusive and C bunders spend CPU Cycles validating transactions that are valid individually but are not valid in the block so they need to find a different block uh

indefinitely so we worked hard to uh write this validation rules as we call them so this is a separate ERC ERC 75 62 that Define uh rules or for the code that can be executed in the validation functions so there are limitations that are applied to these functions uh however these are ERC meaning that it is not part of the consensus layer change like if the bundler if blog Builder wants to include a transaction that doesn't satisfy these rules it's allowed to do so however if you populate mol with transaction that validate this violate these rules uh you will not have a function in mol because uh like you

would not know if you can include this transaction in the block uh so uh the the rules are basically they make sense but they become more and more uh complex as you go in so for example we don't uh want to allow uh transactions during the validation to observe the environment we don't want them to observe uh time stamp or block hash or a balance of other contract because this is an easy way to like randomly invalidate your transaction when it's included in a block we restrict uh access from one contract uh storage to another and uh in many ways uh we isolate the storage that

is available to validation function and there are also like things like limiting the number of transactions that uh from the same entities that can be included in the same block so that there is no risk of uh for example a privilege contract like a pay Master invalidating many transactions in your block uh it's still a pull request you see the rules at the link here but they are not very different from what we have they actually will be the same as the rules applied in ERC 4337 account obstruction um now uh there is a thing that the rules the validation rules are applied to the validation function

however there is still the body of a transaction the actual execution that can do what user said it to do like it can do arbitrary action it is not feasible for us to limit the execution of a transaction we cannot say that your transaction is only allowed to change your own storage and not allowed to change the storage of some other contract so what can happen is that uh while the validation function uh did not violate its constraint and in sandbox the execution actually can do whatever it wants uh so here we come to the third realization of what we need to do for account abstraction we split the transaction into two parts and the

validation frames are not run together with execution we put them in a separate place in a block and the executions run uh separately so all the validations are executed first and only then we we start applying the execution functions uh so if you are developing a smart contract you need to be uh wallid you need to be aware that uh between the validation of your function and the execution then there can be a different code running it's not necessary the transaction is not Atomic per se there is an atomic validation part an atomic execution part so here is the example uh let's say we have three transactions a

green a blue and a yellow one and uh we want to isolate uh access to the same state by validation frames so what we do is we apply them in this order we apply the green transaction validation part then the blue transaction validation part then the yellow one and then we start applying the changes that happen in the execution of a given transaction uh right so this is how it would look like in this hypothetical uh CLI if you were to call three transactions uh like three different wallets execute function what

you would see output is that you are inside the validation frame three times in a row and then you are inside an execution frame three times in a row they are not linearly applied um right so if that is clear there are a few things that are not per se a part of account obstruction but they are exts that we added to this uh uh Pro um Improvement proposal based on the feedback we received from the community one part of feedback uh that we received is that uh 64 bytes nons are not enough for many applications especially when we are talking about smart contract

accounts that can be uh used by groups of people and if there are only using a sequential incremental integer nons uh they can like step on each other's toes and like invalidate each other's transactions while they are being prepared and signed so uh smart contract account developers wanted to enable unique transaction nones that are not sequential so we decided to increase a knows uh parameter size to 256 bits and we dedicate 192 bits to the key part which can be arbitrary value and the 64bit value part that is actually an

monotonically increasing integer uh nons uh so if transaction wants to use unique nons every time it just leaves the Val part empty and creates a unique 192 by key for every transaction that is being signed or if you want to use a just sequential notes you can use a key field empty and just increment the Val part of a transaction you can have like Lanes like Lane one lane two lane three uh right another part that we added to account abstraction proposal is uh gas abstraction so uh the thing is here like we want to allow uh also externally

owned accounts that exist today to benefit from a gas abstraction and smart contract accounts so uh we allow uh external own accounts to sign um account abstracted transactions which would mean that uh the gas for the transaction is charged from the pay Master contract and not from the sender regardless if it's a smart contract wallet or regular uh account uh right and another thing that we introduced is uh transaction validity time ranges so in regular ethereum transaction once you sign it it's probably valid and until it is mind on

other transaction with the same nonsense mind it will remain a valid transaction indefinitely so if you sign a transaction broadcasted it and it wasn't included in a block it can be included in a block anytime in the future in a year in 10 years tomorrow uh regardless if you still have the same intent to do it you don't remember you sign it uh and you cannot delay the execution you cannot say that you sign a transaction that will be valid like starting next week uh what account abstraction adds to the core protocol is that transaction has a valid for and valid until uh parameters so you can uh sign a transaction at any time you want in any way you want uh as a smart contract account uh and Define the validity of

transaction uh explicitly and very specifically and this is also applied to externally owned accounts they are allowed to sign such transactions so in in order to achieve that we introduce a new transaction type uh this uh is like following the transaction type one that added access Le transaction type two added fees base fer gas priority Feer gas uh transaction type three will add a blob transactions and uh hopefully transaction four will add uh account abstracted transactions so the fields that are new to this transaction type are actually the sender uh which means that in the transaction you derive the address of a sender from

the signature by doing the E recover this is not possible with an arbitrary signature format so we tell explicitly which address is the sender uh we allow a builder fee uh which is a little bit technical but we allow to pay an explicit fee to the Builder that is not tied to gas this is this may be relevant to Layer Two uh rollups where gas is so cheap that it may not compensate some computation uh we still provide the call data but in addition we have what we call pay Master data and deployer data this is a these are optional fields that are used if you include a pay Master a

contract who pays for a gas or a deployer which means you don't have code in your uh sender account and you want to inject it and also these uh separate frames they have their own uh validation gas limit and pay Master gas limit so they have their own gas limits and that's uh basically it other fields are remain same from uh other transaction types uh so account abstraction on ethereum is not new like it was the one of the first like the first account abstraction mention in the EAP repo is EAP 86 by vitalic ban uh so it talked about abstracting transaction origin signature like that was not a mature

state for count obstruction uh EAP 1014 the one that added create two op code was actually uh aimed at insuran account obstruction in the future in the first like actual account obstruction EAP was EAP 2938 it is very Advanced na AP and a lot of our uh decisions are based on it however uh in uh my view uh it relies on a payas code to transition a single transaction from a validation phase to an execution phase uh which does not explain how a block Builders would produce the blocks that uh include such transactions how would they prevent

execution and validation from like interrupting with each other another one that is in uh account obstruction realm is EAP 3074 this one uh suggest to add two op codes out and sou call uh what they do in two words is it allows a an externally owned account to make a delegate call to another account so instead of just calling another account you allow a smart contract to uh take over the context and be the message sender of your transactions uh this have two issues in my opinion one is it enshrines the ecdsa signature like this is an EA that's

controlled by ecdsa signature and now it can sign an approval for another contract with this private key but it still uh has an no regular account and so we don't see it as an alternative to ERC 4337 or native account obstruction and we see it as solving another like additional problem to uh what we are trying to solve which is mostly a validity of a transaction all right so this is a very huge change and it's a breaking everything change uh so it's very complex and it makes sense for us to first aim it to layer twos and rollups so we will be introducing a rollup Improvement proposal process so instead of doing an

ethereum improvement proposal uh we are publishing this as a an AIP rollup Improvement proposal so we want to do that because um side chains in our opinion and layer TOS they will all benefit from following the single uh standard for Native account obstruction instead of everyone trying to reinvent their own and uh there are already some layer tools that added account obstruction based on ERC 4337 natively to their protocols but there are differences in incompatibilities and we want to work with all uh layer TOS to implement the same standard uh so this is the rep already exists you can go there we are the first

rollup Improvement proposal uh and it will be properly announced uh later uh so there is a question obvious question like what does this uh RP what does this proposal mean for the broader like ERC 437 ecosystem so the first thing uh that we must say that uh our aim is to have a cross compatibility between ERC 4337 and Native account abstraction so uh it will go both ways so we will make sure that if it works for one it works for another in terms of uh contracts pay masters uh deployers and any component

uh the um we expect that some networks will be quick to adopt native account abstraction and we expect that others es especially etherum main it will take more and more time to adopt this Breakin change so there will be a lot a lot of interoperability and times when uh uh it's support what like one solution works for one chain and then another is using used for other chains uh once the chain approves uh and adopts native account obstruction we want to make sure that there is a clear and straightforward migration uh path for contracts and other players in the

ecosystem to move to Native account abstraction and there is a question of a role of a bundler so right now with uh ERC account abstraction uh bundlers need to maintain a special relationship with the blog Builder uh they cannot broadcast their bundles to the me pool because they will be griefed uh so this similar Dynamics stays in action for Native account obstruction so we expect that there will be bundlers who will uh act uh as a kind of maav Searchers who will provide blog Builders with uh valid batches of type four transactions going forward and this is how they will interact uh with

Builders this is why uh the progress that's made being made by bundlers is still very relevant uh for the native account abstraction okay so join us for uh all the discussions provide feedback uh track our development in our Discord and these are the links the uh RP itself is R 7560 uh available at this link and the new RP repo not EAP repo and please join our Discord to provide feedback and hear back from us any questions uh um given the restrictions on access

to the environment like time in the validation in the validation phase to prevent um some of the the griefing issues how did how did you do the uh valid before valid from and until right so your uh solidity code is not allowed to access time but the the evm is allowed to access time so instead of checking time yourself you provide the time range to to the machine like this is a return value of your validation function it says that this transaction is valid and when it is valid and uh in the evm checks it so you cannot do weird things like be valid on a even second

but you can be valid in a in a Time range yeah how do you how do you prevent um Bots from calling the pay master and just draining the pay Master yes so the pay Master uh is a smart contract so it must maintain an onchain logic to Define if it want wants to pay for transaction or not so it can maintain like per user counter like some kind of white list Black List they can have uh like uh uh Co signature required for a transaction so they can have a server that also approves a transaction uh there it's provided with some extra data uh so any

onchain mechanism that you can come up with uh or offchain as well uh to uh to prevent the like Cil do tax uh on Smart contract basically works here uh yeah I want I just wanted to add that uh it's I mean people often think about pay Master only as something sponsoring the gas but it's not always the case it may be a bit misleading for example there is token pay master that the token pay Master doesn't really sponsor anything it's the user paying it's just that the user is paying with a paying with an ec20 token so so the pay Master actually pre- charges the user

the maximum amount uh the maximum amount that the transaction would cost in let's say usdc and then U and then the contract pays for the eth but it's actually the user paying just with a different currency yeah right no more questions uh okay so that's it thank you very much