A history of account abstraction

Transcript

foreign [Applause] okay great so account abstraction has been one of the big ideas that has been making a lot of progress within the ethereum ecosystem lately so quick here has sort of economic abstraction

um who here has heard of a particular wallet that's diplomatic account abstraction who here is building one of those wallets um who is here is building an L2 that's looking into like supporting it okay so okay a lot of good work on account abstractions already happening so today what I wanted to go through is the history of the concept basically from the beginning of ethereum up in up until the protocols and some of the challenges that we have today so before the launch of ethereum when ethereum was uh just to be conceived and the protocol being specified for the

first time one of the big ideas that we settled on is this idea that in ethereum you're going to have two types of accounts there's an account that's called an externally owned account which is an account that you can send transactions from if you have the private key for that account right so if anyone's using a kind of regular ethereum wallet today you're probably using an externally owned account and the second type of account is what's called a spark contract account a smart contract account instead of being controlled by a person someone who holds a private key is controlled by a piece of code right so this is like the big thing that ethereum has that blockchains

before it did not really have right which is that you have these contracts and these contracts have the ability to have their own internal storage they can hold if they can old assets they can make actions they can send like some of their if they can talk to other contracts call functions of other contracts and this is all like what makes ethereum cool right now there is a in Bitcoin there is also a scripted language now it's a very weak scripting language and it's very difficult to use it for all but the simplest applications such as multisig right but it exists so in Bitcoin instead of having like accounts that can take multiple actions

you have utxos which are basically like one-time accounts right if when you have coins that are into utxo if you send a transaction that spends that utxo you're spending the utxo completely it does not exist anymore and the if you want to keep some of your money then you have to put it into a completely new utxo so there is a script with the script handles as it handles verification right so the as part of a transaction there is an input field that's called a signature and this function is able to go over the signature and over the hash of the transaction and it's able to determine whether or not the signature is valid and so whether or not it can spend the money

in ethereum the Asia script was also used for execution right so you can make or code in of a contract account can make that account do different things it can make it sound partial balances so if it has 100 ethic it said 30 eighth or it could set 5.98 can't send 120th but you know maybe consent 80. um you can store and load to storage so every account has its own like mini virtual hard drive that it could read it right from and it can talk to other accounts and call functions of other accounts now in in ethereum the script or so which is

called the evm is used for the execution part of an ethereum transaction it's not used for the verification part for the verification part there is kind of one fixed algorithm that eoas have to use which is ecdsa signatures right these 65 byte signatures you have your r value your s value one bid for the V if you know you've done your coding you've seen these before and it's like what exact signature scheme that gets used to verify whether or not a transaction actually was signed by a particular account now why was uh why did we restrict verification to just be against the DSA signatures instead of letting the

verification part of a transaction the part that determines whether or not the transaction could even be included on chain depend only on ecdsa signatures um probably the biggest reason was that ethereum transactions can contain much more computation than Bitcoin transactions right now in the extreme case this is actually not true in Bitcoin right because of the extreme case you can make very big transactions and there was this quadratic vulnerability by which you could actually make a transaction that has like 200 like hundreds of different inputs Each of which require hashing over the entire transaction and so we actually have to hash and square data and it actually gets pretty annoying but

like in practice big parts of the script are disabled and there are kind of standard transaction rules that make it very difficult to send those kinds of transactions the total capacity of the system is very low right but if you compare ethereum well at launch we had um Pi million gas per block right three one four one five nine two gas per block and you can do a lot in three million yes and so you could basically just if it was possible to make a transaction we are the process of verifying whether or not it's allowed to include that transaction on chain could involve huge amounts of ethereum gas that people could send transactions that require huge amounts of computation to verify

and a minor would not be able to know whether or not they could even include those transactions without spending a large amount of computation right so in the ethereum context requiring miners to verify these transactions fully before me be getting paid or maybe if it's a Dos attack not getting paid is just not reasonable so one piece of uh thinking in early 2015 that we had is uh like I've been a fan of multisig for a long time right back in 2013 I wrote a an article for Bitcoin magazine talking about how multisagers the future of Bitcoin back in I believe 2012 I wrote an article just listing

examples of people's accounts getting hacked and people losing their accounts that just showed you know how bad the security of single key accounts is and how we desperately need to switch over to something better and so for a short time there was actually a dream of basically launching ethereum in such a way that the average user would actually have a multi-sig wallet that they would hold their coins in and this is what people would use straight from the beginning right now of course as people involved in account obstruction know today doing that would have required people to keep some portion of their eth separately in an eoa because only eoas externally owned accounts are allowed to actually

initiate transactions but like that's fine we can write software to manage it now the problem is there just like wasn't enough time right at the time the ethereum community was breathing down our necks desperate for ethereum to finally launch after one and a half years of delays and so we just cut a huge number of features and we just said ship it and so ethereum was shipped so one unfortunate consequence of this is that the over optimism that we had on everyone using multisigs actually ended up backfiring right so this was some interesting historic trivia basically in

ethereum there's this op code called a log right and when you make a log then that registers data in a separate tree it does not get saved to storage where it can be accessed later it just gets saved to a separate tree where it gets kind of published and then ignored and nodes would be able to read these logs and this would be the way that applications would communicate information about events that happen on chain to their users now we uh one thing that we never did is we never automatically logged eth transfers right we made sure the multi-sig wallets log is transfer so you make sure the erc20 tokens log each transfers but eoas by themselves never did the reason why is

probably because well it was because we expected users to switch over to using multisigs and we even wanted to like create an extra push for users to use multi-cigs um and multisigs would log everything and everyone would read logs the problem is almost nobody used multi-cigs and so exchanges when they were checking for youth deposits they would check transactions like they would go through the transactions they would find the sender they would find the recipients but they would not check logs and so as a result multisigs actually had a harder time getting their deposits uh seen by exchanges for quite a long time than eoas did and this actually we might have tampered multi-sig adoption even more right so a bit of a early

screw-up and tragedy but you know fortunately since then things have improved 2016 this was uh the first attempt at what we call account abstraction this is a EIP 86 which is outdated you're supposed to see two oh wait for current details unfortunately this thing is so outdated but even to await that I believe doesn't actually reaction the 208 is also outdated by now but oh wow um so with this thing basically does is it says if the signature of a transaction is zero zero zero then treat it as this transaction that's a totally different object that is set where the sender address becomes sets to this like entry point address that nobody controls and

then it just becomes a piece of data that gets sent to an account and then if you want to do a creation contract uh transaction then the like basically we add a way to create um right we had a way to create accounts that have a specific piece of code where you know the code the address of a particular contract before you could even like before you even publish it right this is like one of those sort of subtle problems in account abstraction basically like one really big key property that we want blockchains to have is we want it to be possible to give you money before you're registered right because in order to register you have to pay fees and in order to pay fees you need

money yes you know he's supposed to maintain the parallelism in the sentence and uh the ethos money meme was like years old apparently we're like Ultra sales and like maybe we'll be like I don't know like a Nega sound or something but um yeah basically you know it's like if you don't have money you can't register and so you need to be able to have an address that you could use to receive money before you're registered right so the um basically what that requires is that requires the ability to be able to make a piece of code that contains verification logic where you get just given that piece of code you can calculate what the address will be when

that contract later gets published on chain and you can be guaranteed that nothing else can take that spot right um so the default culture creation mechanism does not do that the yeah but this mechanism where the address is the shot three of the code that ends up actually yeah that ends up doing it right so if we do that then basically you're able to create a piece of code that determines how transactions are verified then General hashtag generate the the address based on that give the address to your friend your friend sends you some if the if goes into an account that does not yet exist and then you can send a transaction that actually yeah

it basically uses that eth as a transaction fee in order to initiate that account now that second part we actually did not yet figure out any ip86 right that actually would take at least a year before we realized properly whether that's necessary but the core idea is basically like you have these transactions where the kind of top level address is this kind of common entry point in this case we use through the 160-1 which would be 0x ffff um and the basically all the transactions would um you know start there um and then that would be a call to what your actual wallet is and then your wallet would have logic so that your wallet can make other calls now the big challenge with account

abstraction is minor strategy right so the problem that I talked about at the very start of this presentation basically if you are a miner and you receive a transaction how can you get a guarantee that you are going to be actually be paid for the transaction without running through potentially hundreds of thousands or even millions of guests and maybe getting an answer that you're actually not getting paid at the end and having wasted a whole bunch of computation now one simple approach white list a set of code hashes right so that way we could just like start off by introducing some basic known types of accounts um another option is having a mechanism where you a trans you could have a

template for an account where if an account follows that an account's code follows that template the template guarantee is that the miner will be paid early on and there's no way later on to make that payment uh get uh get canceled or reverted right so the way this base generally works is you have three calls the first call is well before the three calls you do signature and non-verification then you will I mean incorrect the nodes then the first call is to basically pay the miner then the second call is a call to self and then the call just and then inside that call to self you do whatever you actually wanted to do and the reason why it's a call to self is so that if something fails

within that call to self the you know kind of inner culture to refer but the outer call doesn't refer it until the payment doesn't revert and then the third call would then basically call a contract and get back the refunds for whatever gas you did not use right so we have this template and any accounts contracts that follows the template is guaranteed to pay the minor a third strategy is to just say we're going to restrict account abstraction to transactions that require less than for example 250 000 gas anything that requires more has to be sent through EOS for now and maybe in the future we'll figure out some other way or maybe in the future we'll just convince all the ethereum users to not require more than 250 000 gas except for anything but like

maybe contract creation um so that was the early thinking so problems with early account abstraction as I mentioned if you're a new user you don't yet have coins you'd have to find an existing user to create an account for you problem one problem two requires complex logic inside the accounts to handle paying the miner getting a gas refund all of these complicated things which requires like this complicated template that I just described third problem transaction hashes are not necessarily unique right so in ethereum transaction hashes are unique because a transaction hash depends on the signature it depends on the nonce the nons increments every time an

account sends a transaction and so there's just no mathematically possible way to create two transactions that have the same contents that have the same hash with account abstraction you can make an account that does not have that property right like you can make an account where the nonce automatically resets every 24 hours and if you do that then ta-da if you send one transaction you could send that exact same transaction one day later get it included and hashes are not unique and ether scan and ether Chain break right now we and maybe the get API will have to be totally redesigned to return a set of transactions instead of one transaction so this I mean that stuff is all theoretically manageable but it's like a

pretty large amount of overhead right it's uh actually even the current erc4337 proposal ended up like forcing a particular non-system to make sure the transaction hashes are unique one big and very subtle problem with early account abstraction is what I call the multi-invalidation issue right the multi-validation issue is basically that if you have a piece of arbitrary evm code that's verifying whether or not a transaction is valid then that evm code could go access other accounts and then what if you create a structure where you have a whole bunch of accounts and a whole bunch of transactions and they all access the exact same account and like let's say they just check some

particular flag in that um in that account whether or not it's true right and then if like so first gives you a bunch of computation as much computation as you're allowed to do then you go check the flag and then if the flag is zero then it passes now let's imagine that someone creates a thousands of these accounts and then publishes into the mempool a thousand of these transactions all thousand transactions if the value in the storage over here on the left of this flag is set to zero all thousands of the transactions are valid right but there is a problem only one of them can get included and once only one of them gets included the flags changes to one and then all of the other transactions are invalidated right and so the problem is you could make an

arbitrarily large number of transactions pollute the mempool with those transactions make miners do a huge amount of work verifying them and then you just like take the simplest transaction let it get in send it with the highest gas price you know maybe the simplest transaction would not even do the two million gas of computation it would just poke straight into the S and then it would just set as you know this uh flag over to one and then this like really huge amount of stuff gets invalidated and so you never actually pay the fees for it right and so this creates a very cheap dos opportunity so this is like the big problem that is responsible for like probably half the complexity of modern account abstraction schemes so moving forward a bit some proposals

from the 2017 era proposal one remove the non-substraction basically do the rest of account abstraction but require the non-style the transaction to still use the existing nonce field require the nonce to be increased by one by the protocol and so by doing that you remove people's ability to do their own non-selogic and so remove the ability for people to make duplicate hashes if they want to right um standard um second idea standardize the signature scheme right so uh basically yeah transactions would have a dedicated field called a signature and then the transactions are in the top level

message the transaction or the call data that you get or in this case the return data it would include the signature and zeroclude the signature hash and basically this kind of grabs up a lot of logic that would otherwise have to be in the contract and it sort of standardizes it for you and it lets you just make the verification account itself much simpler um a breakpoint op code right so the idea of a breakpoint opcode is basically that if a transaction does an exception after the break points it doesn't revert all the way it only reverts back to the break point and then it stops there and the idea there is that you split your trends at your account logic into two parts verification part execution part

after the verification part at the end you pay the miner and then right after paying the miner there's a break point and so if something breaks it only reverts back to the break point and so no matter what happens later on the miner still gets paid now the problem is this is a pretty big change to the evm and especially at this time client teams were pretty allergic to changing the VM so this ended up not happening um a couple of a bunch of other proposals ended up happening there was this uh interesting one called the pay gas op code which basically kind of pays for gas that automatically gets refunded and so the entire gas refund mechanism ends up being handled by the protocol instead of being handled by the account

um you'll see here panic op code that could be used to invalidate the transaction before a break point there's a bunch of different miscellaneous some ideas there's a a proposal where a transaction can include a piece of salt in a piece of code and so we can actually create an account obstructed account at the same time as sending the first transaction from it so there are a bunch of different ideas that we were grappling with I think probably the most challenging trade-off that all of these systems were trying to handle is this question of like how much to enshrine versus how much the weight of the user right I think early account obstruction had this big dream where the dream was that we would reduce the transaction logic such that each transaction and the

call are the exact same thing right a transaction just equals one call and then everything that's required user level for verification or whatever that happens inside the evm right so basically trying to create this like really lean and clean system where the logic that's the for verification is itself all done by the user and everything is done with contract code and ethereum can be like this really clean and a minimal system that specifies basically nothing over time we ended up moving further and further away from that model right so we've you know we became willing to enshrine nonsense we became willing to enshrine certain things about fee payment in the erc43 yeah seven proposed

holders uh actually now a medium-term desire to enshrine erc4337 and then accounts would all have to go through the erc4337 entry points and so there was this thing that makes us basically a set of a whole set of verification calls and then a whole set of execution calls and accounts have to have both of those and then there is the desire to have in a protocol censorship resistance some mechanisms like inclusionalists and inclusion lists would also be aware of the concept of transactions but not the concept of calls and so we're actually moving in the direction of enshrining more because that's uh better for user security but at the very beginning the philosophy was the opposite right and well trying to preserve as much of that Simplicity as possible was a big part of

the motivator that kind of resisted I'm adding um adding some of these extensions so primary goals here handling accounts creation what happens when you're using an account for the first time and the code is not yet on chain making sure that you can put the code on chain as part of your first transaction verification complexity um and basically trying to make sure that the accounts that you the verifying can be simpler if possible and issues around hashtag non-uniqueness basically not making life hell for The Gap API or for etherscan but we were not yet thinking about the multi invalidation problem so ta-da 2018 who here remembers 2018.

we're here was happy in 2018 her here was less happy in 2018 I know it's a good year you know I remember prices dropped right like at the end of the day isn't that what matters right you know maybe if yeah well you know prices are so important right maybe like if we get the price to like under 100 then like that'll be awesome okay so verification time access restriction this is what 2018 was actually good for um and basically yeah the idea here is that during the verification step of an account

um you um or of of a transaction verification there would be a restriction by which the that code execution is not allowed to read or write the state of things as outside of that account right and so that whole mechanism I showed you a few slides ago where you'd have a thousand accounts and those thousand accounts would all read this object called s and then you could send one transaction to invalidate that object or change that object State and then suddenly a thousand transactions are invalid that would not be possible anymore right there would be a hard invariance that the only thing that could invalidate a transaction from account a that looks valid today is itself if account a does has either that

trans action or a different transaction included right so multi-validation would not be possible anymore and so you would have basically the same kinds of invariants and like security properties in the mempool that you have today and so the whole thing would be much more secure against denial of service and this is something that would be verified by miners right so basically like miners would have their evm logic instrumented in such a way that if they're verifying an individual transaction for the purpose of determining whether or not it's okay to include or whether or not it's okay to forward they would run the evm with a special flag and the dot flag basically says okay if during the prepay gas portion uh sorry during the

verification portion of a transaction execution if it hits a like if it reverts or if it hits some off code that triggers a failure then that trans that entire transaction gets thrown out right so this actually plugs the biggest remaining hole and it was a good idea but the problem is that you know as you can see there's like an entire two-year jump between 2018 and 2020. um who here remembers what happened between 2018 and 2020. okay nobody remembers uniswav okay but aside from uniswap the biggest thing that happened uh within those two years is basically the ethereum proof of

stake research kind of ecosystem really kicked into full speed right at the beginning of 2018 we announced that like hey we would love to have some consensus client teams implement the proof of stake side of ethereum and we roughly know what Brew of steak is going to look like and then you know we have that big Workshop in Taipei then we had that Workshop in Berlin and then we had more workshops and uh at some point the actual code started getting were getting written but during this time like you know developers were very busy and we definitely did not want um the East one the execution developers so you know the deaf people at the time the parody people all of you know starting to be and that reminds people all of these I mean wonderful groups to

have any extra stress at a time when they were already busy with maintaining the clients and possibly preparing for having to make the biggest change that ethereum made in its lifetime which would be switching to proof of stake so it's two years later 2020 EIP year 2938 right this is um a concrete proposal that includes all of the different pieces of account abstraction ideas that we had come up with in the Years previously and finally for the first time puts them together into a single package that like actually is an EIP and so it's actually formal enough that you can like go and actually implement it so the pros are it solves the problems the cons are that it's very complex that

the protocol layer devs were still working hard on the merge and so it also ended up not being implemented right but it was progress because it shows that like hey we have a concrete idea um independently built account abstraction Alternatives right so the ethereum foundation is far from the only group that cares about the problems that I talk about and there's other groups that also cared and there's even other groups that had their own problems that they cared about that later on again ended up kind of getting merged into the account obstruction umbrella and ended up getting handled by the proposals that we see today right so Gas Station Network so basically this is a system where you could make an

off-chain message so you could just make a here a message pile of data including a signature whatever and you can pay someone to wrap the message in a transaction and include that transaction on chain right so if for example you have a gnosis safe wallet who here has hypnosis safe wallet okay cool um who here has an eoa wait wait more people have noticed a safe wallets than EOS this sounds wrong do you guys like share EOS to like use circadosa saves okay so basically um you know if you if you have a glass of safe wallet right then to

send a transaction from diagnosis equal you have to like go call the um you know the execute function right and to call it you need to make a call but then a call by itself cannot go into the evm only a transaction can go into the evm and so using the gas station network you would be able to pay someone else to actually make that transaction that then includes a call that goes to your safe and lets you take some money out and the payments could even happen from your gnosis safe right so it kind of it solves the problem it makes it nice the problem with this approach is that it requires every single um you know operation to be wrapped in a separate transaction right and that adds an extra 21 000 gas per transaction

overhead which is uh not very nice right so um then there is also the Argent wallet um they were you know I mean amazing group working on social recovery before social recovery was cool um and you know they're also your smart contract wallets and so they had very similar problems and so they Implement something very similar um there is also a new goal that was being introduced which is uh this goal of letting people pay fees with erc20 tokens or more rarely sometimes letting application developers pay fees for their users right so if you imagine you want to make a wallet that's targeting

users in Latin America and you use this in Latin America at the time do not deeply understand cryptocurrency and so you want to make the user experience simpler and you know you want them to that like them when they receive usdc to be able to send that us this year the problem is if you just use ethereum directly if you receive 10 usdc and you receive nothing else you don't have any if to pay for gas you have no way to spend that in usdc right and so what you'd want is a system where people actually could use the usdc to pay a third party and then the third party includes the transaction and the youth gets paid right so this is the sort of thing that can also be built using these kinds of

wrapper mechanisms right also if you want applications to be able to pay fees for their users also use wrapper mechanisms but the problem in all this is that every single operation requires a separate transaction wrapper that's an extra 21 000 gas and so it's uh it's pretty high overhead EIP 3074 is a lovely proposal by Sam Wilson onscarditrix Matt guarded and Micah zoltu that basically um targeted some problems that ended up going under the account obstruction umbrella but that were somewhat different from the account obstruction concerns that I had which is that I want everyone to move to multi-sig wallets

and be able to move both use multisig wallets super easily and cheaply right so the and also one of my other goals by the way is uh when quantum computers come I want people to be able to upgrade their existing accounts to Quantum safe cryptography and without us having to be opinionated about which Quantum safe algorithm you use right so you know there's a lot of things in there and so sponsored transactions um including um so the ability to use usdc to pay for gas if all you have is usdc was a goal being able to make multiple actions per transaction this is like a really important goal for for user experience purposes right like who here remembers the experience where you

have to um base like on you and swap if you want to convert usdc to Ether you want to convert whatever else to if you have to first send a transaction to approve usdc and then later on you have to send a second transaction to actually perform the trade so that it can grow at which point it can grab uscc because you've approved it but quickly remembers this okay who here remembers doing this back during the dark old era before the margin before eap1559 when transaction an individual transaction would often take five minutes to get included on chain okay so a lot of problems get solved if you can just make one transaction that includes multiple calls one transaction

first call approved second call execute easy right so this was um I think a big part of the dream that also motivated the AP 3074 modern account abstraction includes both the reasons why I've wanted account obstruction since the beginning and it also includes these you know newer user experience concerns that are you know very valuable in some different directions right so um 2021 a year later erc4337 or EI yes it's uh it's an EIP and there's a or it's an ERC and um there's a long-running technocratic debate about whether ercs are a subset

of eips or not I guess right now according to like eips.etherium.org they are um I mean my preference would be for those to be two separate categories but like whatever um basically 4337 tries to do the exact same thing as 2938 but instead of changing the ethereum protocol it all does this with layers on top without needing to make any changes to the ethereum protocol at all so the way that it works is we it makes a contract called the entry point contract and then the way that wallets work is wallets trust the entry point contract so they basically give the entry point contract root access to

authorize operations from their account now there is an actor called A bundler and A bundler creates a transaction that can wrap many different user operations right so there's still the 21 000 gas overhead but you only really need to pay the 21 000 gas overhead once per block this uh so what happens is then there's this really interesting thing where you split up the phases right so first you go verify every wallet you go verify every transaction and then you go execute every transaction right now why do we do this well I mean one reason is that we don't want execution to be able to interfere with verification

right but there's actually a bunch of other reasons why it um it ends up being super Elegance right but the way this works is this is all done without changing the ethereum protocol so they pushed out the entry point the entry point contract on chain wallets would individually choose to trust the entry point and then users that have their operations would send their operations through a separate dedicated mempool a separate peer-to-peer Network where bundlers will be able to listen to it bundles will be able to grab up a whole bunch of these operations and they would include them in a block this also ends up depending on the Mev ecosystem right so the ideal thing would be if a bundler just ends up being the

same actor as what we call a builder basically those actors that like grab up the transaction or identify transactions that um contain Mev and claim Mev and like they would also be able to run this other specialized Logic for this other subprotocol and they would be able to create this account right so basically using the Mev ecosystem at the time flashbots now Mev boost in the future in protocol Insurance PBS as a way to create this open relayer market right so this resolves the other big criticism that I had of like the gas station network approach which is like hey you know they're just one entity and if there's a small one entity or even a small number of entities and like they

could disappear they could you know be made to disappear lots of things could happen and so like it's not really stable to create a ecosystem of wallet users that rely on it right but if you have an open market then like in if one provider disappears any other person could come in and become a provider to take their place right so the key Innovations here are the trusted entry point mechanism the idea of like a rapid transaction that wraps many operations and not just one the Mev ecosystem and this idea of like first verifying everything then executing everything now this is all done again without making any modifications to the ethereum protocol itself and so this makes sure that you know Peter salagi and all of the wonderful Dev folks don't have to do

any extra work to make for a erc4337 happen one big extension to er34337 is pay masters pay masters are like an extra mechanism that goes on top of your 337 and is actually part of the EAP that basically allows for kind of other actors actually smart contracts to do things like converting usdc into eth or verifying signatures and releasing it things that can be used to allow people to do things like paying fees with usdc or use it with whatever coin they're transferring and like allowing applications to sponsor transactions for their users another more recent extension is

signature aggregation right basically the idea here is if there are these techniques that allow you to take mold many signatures from any transactions combine them into one object which is much smaller and which can be much more quickly verified than you know verifying all of the AI transactions individually and by doing so you can save data and you can save gas this is actually especially a big deal on Roll-Ups because in a roll-up a big or well because a big part of the size of a transaction is a signature on a roll-up computation is cheap but you still have or sorry data is but right but but data all still has to go on chain and so computation becomes 100 times cheaper data has the exact same

cost and so we have to find some way to compress data this is a diagram I published about I think last year in a tweet and you see our signature is a big part of the data right and so if you can get rid of the signature by replacing the signatures of all the transactions with a single aggregate then you can like actually save people a huge amount of data and if you combine it with all the other techniques it can get like an 8X cost to decrease or maybe 7x which is super amazing BLS is one very simple way of doing it I have a post here on how to do it from a few years ago more recently you can also try snork aggregation which is more generic and works with everything so account abstraction challenges today right one is that the

pendulum is swinging back toward enshrining more things because enshrining is more efficient enshrining reduces the risk of bugs and also we have to enshrine if we want the censorship resistant mechanisms like inclusionalists to be able to cover account obstructed operations in addition to regular eoa transactions and so there's actually ideas to enshrine erc4337 over time we also need an EIP to allow existing EOS to upgrade into contracts because lots of people don't like changing their accounts a cat abstraction on all tears standardization making sure the uh protocol works in the same way across some l2s just like eoas work the same way across l2s integration

into existing technology um included one interesting thing I heard um I was uh so there's a biometric signers there's this company I think their name like I forget like sounds like ozampic uh alembic um right they're doing a biometric signers um and basically you know you provide like some biometric and then like you know provides your key right so if users have multi-sig wallets like we have to actually decide what those individual multi-factors are right and so we need huge amounts of innovation on that too and like integration to that side of things and finally integration into existing wallets but you know account obstruction has made a lot of progress and I'm excited about all of the

progress that they'll continue making in the future so thank you thank you foreign [Music]