On the Road Towards Account Abstraction

Transcript

so now please welcome Richard co-founder of s to share about on the road to Wood a abstraction thank you so much cool thanks for the introduction happy to be here um to be in Tokyo and at atcon yeah I'm Richard I'm one of the founders of the safe project and today I want to talk about account abstraction but before we get into count abstraction I want to iterate a little bit on why are we at safe working on account abstraction and smart accounts and why do we think this is so important and is actually that we think that being able to own something is a fundamental right that everybody has and

that everybody needs to be able to exercise and we're actually not alone with this it's part of the human Declaration of Human Rights that everybody should be able to own property be it alone or together with others and that it should not be possible to arbitrarily derive deprive him of property and this is why we think that it is so important to have Smart accounts to have account obstruction to have blockchain and this is also why we believe that smart accounts are the future they will help us create a world where everybody can exercise this right to ownership but today I want to go actually one step further and I actually want to show you some examples why is this is why is this future is actually

today right like it's already now we have a a lot of tools that allow us to build like applications where the users fully owns the product let's start with some Basics right like at safe we started 2017 we started building multi signature because we believe that with multi signature wallets you already bring a lot of flexibility and security towards the users so that they can really fully own a product there are two parts in multi signature there's um on one side we have the signers and they basically approve which transaction should be executed and then on the other side we have a threshold which basically said How many of these signup do we require to execute one of the transactions let's

take a look at a little bit more concrete example let's say we have um smart account that has three signers represented by the green Keys here and we want to execute a transaction and have a threshold of two and that's where we see that two of these signers confirm this transaction which is then transmitted towards the smart account that executes it um this already brings us a lot of flexibility because if we think about an individual what we can do here is that we say hey let's Implement multiactor authentications that's what we're used to from the web 2 world we want that we have a high level of security and that we require more than one confirmation or that we can also rotate our keys but you

can also utilize this to really build like or manage funds as a team be it a smaller team like a VC fund or bigger team like a DA another thing that smart accounts really enable is that they allow relaying so in the case of relaying what you can do here is that you take the signed transaction and you hand it over to a third party and this third party the relayer then submits it to your smart account in this case the relayer is responsible for how do we create an ethereum transaction how do we pay for the ethereum transaction and in turn they can get refunded by the smart account this allows us to really abstract away a lot of the complexity

that comes with etherium right like we have to understand gas prices gas limits and so on and all of this is now handled by the relayer in turn relays are often very centralized parties that create an additional risk that you have to trust as parties that they submit your transaction ESD 4337 worked a lot on reducing the centralization risk by replacing the relays with bunders and pay masters right like so we have a decent centralized Network where you can just submit your transaction towards two and therefore you have a higher guarantee a higher resilience that your transaction gets executed 437 achieves this by decoupling the submission the verification and the execution so that you can really sign your transaction give it to somebody

else and execute it and you have this really decentralized execution of um smart account transactions most of the smart accounts nowadays support 437 and this giv gives you already one of the Big Adventures where you can choose how do you want to pay for a transaction do you want to pay it with the ease stored in the save do you want to use some esc20 token or do you even want that some de can sponsor your transaction like this flexibility is really what allows us to push the boundaries of your ex another thing a little bit more advanced when we look into the smart accounts is message signing I think most of you if you have used um any of the

deps have come along across this with your metamask account and how it normally works is that you have your private key and when you log into a de for example the de gives you a message saying please sign this message saying I'm logging in into de XYZ and then you basically take the signature and give it to a Deb which then can utilize the signature to recover your public key from it which cor like where you can derive an address from and then you can basically compare as the connected address the same as this recovered address and therefore you are basically then authorized into the step the challenge here is that you cannot do this with smart accounts like smart accounts don't have private keys

and therefore it's impossible to generate like the signature that you can recover from so an alternative was proposed which is called contract signatures and which are like these are defined in ERC 1271 and here here let's go through the flow right like on the left side it actually starts very similar we have our multi signature setup where we have like three keys again where we need two of them sign the message and then we have this aggregated signature that we can give over to the the de but now instead of recovering the owners from the signature basically the Deb is going towards the smart account and asking is this aggregated signature valid for your smart account and here then this smart

account can take apart the signature again checks it against the owners and returns to the Deb yes it's either valid or no it's not valid the magic part is actually that you do not have to follow this multi signature scheme here right like you could have your smart account Implement any arbitrary signature validation logic which allows you to say for specific depths I utilize different signature validation logic than my default a very nice example that I want to present for this is is um time weighted average price orders used with CW so what we're doing here is like these t-w T orders are like used to reduce the price slippage on very very

large orders right like let's say I want to buy 1 million cow to 1 million no I want to buy cow tokens versus 1 million usdc So to avoid that this changes the price too much I say I want to buy them over a time period of 2 hours in an interval of 20 minutes and each of these smaller trades I only want to spend like 27 cents per C token so now what I do in the past I would have to do this very manually but with smart accounts you can basically automat this by you go to your t-w contract you tell the t-w contract hey these are my parameters as I defined some before and then by publishing it to the TB contract this can be packed up by

the solers inside the C and this the cow protocol then basically takes these smaller orders that happen six times every 20 minutes um where we buy roughly 7 67,000 tokens uh used cow tokens where of usdc um and they submitted to cwap and cwap now can th then go to the smart contract and ask hey did you verify this order and now since we have this custom verification logic we can go to our um tab contract and this tab contri can just tell us hey yes this is part of my

TB order um it you still have not completed your full package of the t-b order and therefore we can verify this very smart part this way instead of having the user to sign six times for like the smaller orders or having to put their funds into an estro contract here we sign once and the funds are still only moving out of our smart account once we actually like fulfill the smaller traits cwap was actually writing this in a way that you can Implement all other kinds of orders and you can even use it outside of cwap so you can also build your own protocol that uses these custom signing Logics so recommend to check this

out another thing where you can use signature verification is actually not only when it comes to to signing messages but when it also comes to signing signature uh transactions right like here I'm same example as before we have three owners but now one of these owners is a smart account it's not a p private key now when we want to verify a safe transaction we can see that the smart account actually validates this signature against the smart account why this is cool is because this allows us to implement custom logic here and then we have in the smarter ground for example we can Implement a P250 six verifier that allows us to use pass Keys when execute normal transactions so now we have a special smart account like the

implementation of the p256 um verifier and solidity that is utilized in this flow and whenever the user has to sign a transaction they actually get presented with this very common web 2 like experience where they have to confirm it why are their pass keys and since pass Keys is one of these technologies that is being pushed in web to by Google and apple it actually allows us to onboard a huge chunk of new users with Hardware wallets this allows us to really tap into existing Hardware Key devices Hardware security devices this might be passwort managers but also UB keys but essentially and most importantly it's

mobile phones basically everybody of you who is running around with a modern mobile phone has a Hardware Key in inside their pockets but it's hard to utilize them since we are not really optimized on the right cryptographic curves also here if you want to play around with it I recommend you to check out the demo because it just showcases you how easy it is to onboard right now into crypto another thing that I want to look at because it's in my opinion the most powerful feature of smart accounts is guards and modules modules are a form that you can have ex um additional execution flows outside of multi signature flow that I mentioned before so here we can have session keys where we allow third

parties to execute transaction wi smart accounts or allowances where we have lower security assumptions and guards are way where we can basically limit what transaction can be executed so that we can perform additional Security checks or compliance checks before a transaction can gets executed there's a very nice example where you can see how powerful these two can be used together and that is actually cwap uh gnosis pay so gnosis pay what they provide is like this little credit card with which I can use the funds that are stored on my safe account right like so it's a normal safe account I have two out of three owners and um the only special thing is that

there is a guard enabled that delays all transactions so I can I have to wait 3 minutes before I can execute any transactions and why this is important you will see in a second so when I now go to a shop and I use my credit card what actually is happening is that this terminal at the shop will utilize the Visa Network um to go to gnosis pay and ask like hey do you like pay for the users because they they have to guarantee that the store gets their fund the challenge here is that they have to respond to this request in a very short time in like sub seconds in the best time and this is normally where blockchain cannot is not that fast yet right like even on the layer ones we

take some time to submit the transaction and to settle it so here that three minutes come into play where we really say some gnosis pay know that for three minutes the smart account cannot change its date and they can now say according to the current state we can cover it and then they have three minutes time to bring this transaction on chain and actually settle my depth that I created with my credit card so this is really where you can see that the this flexibility of smart accounts allows us to connect the web 2 and the web 3 world and that we can utilize like our crypto funds also in the web 2 world but this is only one of the many examples I think in general smart

accounts can give you anything when it comes to automation but they can also like represent complex hierarchies inside smart accounts and it will also be one of the important tools when it comes to postquantum Signature scheme where we really want to push forward and can utilize smart accounts but to really make sure that we as an ecosystem Can Build Together in the smart accounts we have to make sure that we align on certain standards and this is also where one of these standards is ERC 7579 where it's really around okay we have validators that allow us to for the signature schemes we have hooks that are where we can have Security checks executors to provide additional execution pass and also fullback handers to exe um to extend our account

so if this all is so cool and if I saying hey look we have projects building this why why is not everybody using smart accounts why is not everybody outside in the world using blockchain it is because there's actually some fine print I mean I'm not sure if you can oh you can actually read it on screen but like there are a couple challenges there are some conditions attached to it one of them is that most of this only works with very selected interfaces right now it's actually not that easy that you can just take your smart account go to any Deb and intake with this um but also these are things that the teams are working on and there are two areas here the first area is that it's being pushed that existing erc's gain more adoption ERC 1271 has been around for a long time but it took

a lot a lot of effort to really push projects to adopt towards 1271 and now with also the continued adoption of 437 the pattern of counterfactual accounts is becoming more and more used which increases the challenge to push depth to support these patterns and to really support these accounts another challenge is how do you connect really the the depth towards the smart accounts in a way that they can utilize all of this AA functionality like this smart account functionality and this is really where also there there has been a lot of erc's around for while ERC 5792 really was working on this connection where how can I send

batches of transaction how can I understand what features does the wallet that I connect to actually support one of the recent um erc's in this regards is ERC 7715 which basically allows Debs to request this permission that I can basically execute transaction without having to do per um a confirmation every time a second problem is that all of these are only erc's so these are more recommendations it's not enforced in the um consensus layer and this is really where we have to push forward further one of the things that is being currently discussed and is a candidate for the next hard for is EIP 12 uh 7212

which basically introduces a new cryptographic curve as a pre-compiled to etherum which will make it a lot cheaper to use um pass keys but will also make it a lot safer and since we have one canonical solution now that we have to use and we do not have to um deploy our own solidity contract solution another one is EIP 7702 where really this is an AP that will bring EAS and smart accounts closer together it will make some of the smart account features available to EAS and these can therefore then be used by The Depths more commonly because they do not have to choose between hey do we want to support EAS as an existing user base or do we want to fully utilize the powers

of smart account um on the other side how this works is that basically your a can set implementation Del they can delegate their logic towards the smart account and then each time somebody interacts us with EA they basically behave like that smart account and last but not least now that we bring EAS and um smart accounts closer together we also have to continue push native AA it is really important here we have seen for 37 as a tool that builds on top of the existing etherum layer but we should not stop there we really have to make sure that the rules that are um set by 437 are really enforced by the consensus layer and here

we really want to push forward that with r 7560 where this is enforced first on um on the rollups and the layer twos where then the sequences en Force these rules and push this forward but this will also enable that when n of the layer two show case that this is viable that we can push native AA also towards the iso main net account but even if we solve all of these coordination issues and all of these standardization issues we are still in an ecosystem where we are constantly evolving where we're constantly changing and we're currently in a state where the users and the liquidity moves from a handful of networks where it's supported towards a

landscape where we have hundreds if not even thousands of networks where users are currently active and are spreading their liquidity and there it's really important that we work together as a team and that we work together as an ecosystem to utilize smart accounts to make this a good experience I hope I could show you a little bit like why smart accounts are cool and why we should push further for account abstraction and also why account abstraction already enables nowadays A lot of the things that we might think are still far off in the future and I I also hope that some people take this as an initiative to get engaged into account abstraction research so yeah

feel free to reach out a lot of people I see a couple icon abstraction developers in the audience also so yeah let's push together forward thank you so much Richard thank you