The future of Account Abstraction is modular

Transcript

foreign I'm Conrad thank you for sticking around to some of the last talks of each CC on this Thursday afternoon and today I'll be talking about account obstruction and more specifically modular account obstruction and why at least to me it will be the future of how smart contract wallets also called smart accounts will operate so I won't go too much into depth about like what account obstruction is why we need it there's been so many talks already not least of which vitalik's history on the metallics talk on the history of account obstruction on ethereum we all know there's terrible user experience today and account abstraction promises to fix

that so like very roughly for people that haven't heard about it yet um today how you interact with ethereum is through an externally owned account which means you have a private key from which there's a public key derived to it and probably the best definition I've heard about account abstraction is that on ethereum and the execution phase so what happens after your transaction or during the execution of your transaction is kind of programmable and smart contract developers can decide what happens but the validation phase that determines whether your transaction will be executed is fixed to a specific key signature algorithm ecdsa and kind of what account abstraction does is it allows for that validation phase so also become programmable which means that

people can decide on using different signature algorithms or different kind of ways of verification or verifying a transaction in general so I'm sure everyone has seen there was a talk a few talks ago about using web of N and to drastically increase the user experience of using ethereum so kind of the the ideal goal of account abstraction is to drastically reduce the friction and just make using ethereum and evm blockchains a lot more simple um however we think that um the infrastructure today and how smart accounts are built today is still very much lacking so there's a couple of big problems um such as vendor lock-in so what what

that means is when you create a smart account on one platform um usually it's very hard to Port that account over to another front end and use it there and for example developers might use different terminology for calling the functions so a front-end might actually not be compatible with a specific smart account that you've created somewhere else there's also fragmentation which means that users might be onboarded through adapt that creates a smart contract wallet for them but then they might not be able to offer like off-board that off that specific UI and over time you might use 10 different apps that create 10 different smart accounts for you and then all of a sudden managing all of these accounts is even more of a headache than having 10 different accounts in metamask there's also a lack of customization for the

users so what that means is that you don't really have a control over how your smart account works so the developer kind of decides like I said which key signature algorithms to use um kind of like whether they're optimizing for more for security whether optimizing more for gas and all kind of all stuff around that and finally you also think that there's a lot of duplication of engineering work and where people really only want to build certain additions that make smart accounts um better or in some cases a lot better but actually because of how smart accounts are built today they have to then go and rebuild an entire account rebuild the wallet UI and then compete with all the other like thousands of wallets that are out there already

and that just doesn't make sense most of the time because the engineering time should be spent and actually building those features that make smart accounts overall better so what is modular account obstruction so we kind of think of it as smart accounts today are built in a very static and rigid fashion which means that development Cycles are very slow upgrades are very expensive um and also audits are very costly because after the team has kind of made some upgrades to a Smart contract wallet changed a lot of its functionality they then have to get their entire code base re-audited but we think that tomorrow smart accounts will look more like Lego blocks where either developers or users can

construct um the functionality of their smart accounts through simple pieces um this might be kind of like exposed to them through a no code fashion but it might also be kind of developers building those pieces themselves and putting them together so for example a developer of a wallet might want to build a wallet that's very specifically focused for a use case such as gaming and then take these different Lego pieces that they themselves or other people have built and build that gaming wallet with all of these features that are either really out there or that they build themselves and why is that kind of as we think of it a strictly better way of building smart accounts um so first of all the smart account becomes kind of a very versatile

primitive in the future that we see there might only be a few accounts out there that are very kind of like battle tested very trusted and people can build around those and don't have to reinvent the wheel or a wheel over and over again it also enables flexible feature design like I said before with no code customization so that even users can decide how their wallets work and they don't have to rely on developers to tell them now you get this feature and now you get that feature and it also means that upgrades and changing how those features work might be um way less costly and also potentially in some cases might kind of like be less complex on the security side in terms of

auditing because you might only need to audit specific pieces rather than have everything kind of like you audited like I said before so here are some of the modules that we personally and also some of the people that we've not been talking about have been pretty excited about we've kind of just like um grouped them into some rough rubrics obviously there's there's a lot more both categories and ideas for for modules um but these are some that um like I said we've been pretty excited about so some examples might be you might want different roles in your wallet um such as admin rights token voting spending limits different ways of doing recovery um so social recovery is being talked a

lot about but some users might just prefer to have a custodian that does recovery for them which is equally fair you might have the equivalent or even a traditional bank that holds um a keyshard or even the entire key and kind of like does recovery for you um there's also a lot of features you can build around protection either around like kind of exploits of the account such as being able to to freeze the account and having an allow And Delay deny list of um kind of like contracts that the account can interact with but you can also have um build really cool features around Mev protection and finally you might have kind of like more miscellaneous kind of like modifiers um but we also think that Innovation

will happen at the product level so not necessarily or maybe in conjunction with smart contracts um like modules um so you could have for example a lot more peer-to-peer interactions when assets stays in your wallet and never actually leaves your wallet but an ephemeral key is created given to someone else and that key only has the ability to kind of prove ownership of that specific asset but it can never kind of transfer that asset out um so that kind of like kind of turns how um learning is done today a bit kind of like upside down and there's also kind of like stuff around automated trading which is why a lot of people still kind of like stay on centralized exchanges today because you

can much more easily do stuff like dollar cost averaging or triggered buys and sells um so we really think those kind of like multiple levels of innovation that can happen using modular and smart accounts so how do we envision this ecosystem of modular smart accounts to kind of like work what are the different components that we think will are being built and need to be built um in order for this to actually be be ready to be used kind of like by the mainstream of webview users um so obviously kind of like this is kind of like a chart you can read it from both sides on the left side is kind of like the user facing um stuff so obviously like a user has an action they use everything infrastructure such as

provided by eoc437 which is kind of like standardizes how um user Ops as it's called um kind of on in the terminology of uc437 are used to to trigger um smart accounts and then you might have your modular smart account so you might be using a safe or you might be using um zero depth kernel that has some native functionality but that is also extended by modules and then kind of starting from the other side you have a developer that builds a module and like I said before like they might build a module for a dollar cost averaging um and then the final piece that I kind of haven't talked about so far but but which we think is is pretty necessary to

make this ecosystem feasible especially from a security perspective is some sort of entity that regulates um and kind of like validates how modules work and how they can be added added to and kind of like used by smart accounts um so we advise them call this a registry and essentially that registry the function of that registry is to allow for users to more easily trust um like I said like how modules work and how they can be added into your account um yeah so for the rest of the talk I'll kind of like Zone in on on that registry um on which there's a lot of work um being done today I believe Lucas in the in the next talk will also talk

about kind of like how safe is thinking about and the security aspect of these modules um but this is kind of like a rough idea of how we've um been kind of like thinking about it and and been kind of like talking with different teams in the space and trying to get feedback on yeah kind of like the architecture and and some of the constraints that you need to think about when you're building um essentially this registry um and kind of for easier understanding like one way that you could like kind of describe this this registry on a high level is that it's essentially an app store for uh modules that are added to your smart account and that app so like I said it kind of surfaces these modules and their functionality to users but it also kind of enables them to actually

trust and what these modules do and whether you should or shouldn't add them um so this is like a very rough and also kind of somewhat opinionated um kind of like idea of how this this registry could work um so kind of on the one hand you you have users um that interact with this registry and there might be a free module or there might be a paid module um that they use and in order to kind of add this to their account um they're choosing kind of who to trust um so there might be some Auditors there might be kind of protocols that are marketplaces of Auditors um that kind of like verify um these modules and the permissions that these modules are given and kind of surface this to the users

and then on the other hand like I said there's kind of these developers that build these features that are then embedded into the smart accounts um and kind of like the final aspect which I haven't touched on yet is the equivalent of modularity on the smart account level also needs to be built and needs to be surfaced on the UI level so what that means is that if I were to build a module for example to D to do dollar cost averaging from within a smart account um a normal kind of like wallet front end wouldn't really know how to use that module it wouldn't really like know how how to let you set up different strategies how to kind of like surface to you when these strategies are being

executed what price you're getting for different swaps so in order to actually surface that to the user a developer would also need to build a front-end component that's essentially like kind of creates this UI that lets the user interact with specific modules in that certain way um and that kind of within that that also brings up a lot of like security issues um of kind of like modules operating within the same Dom in the front end and kind of like using um the same account and kind of like interacting with each other um so a lot of kind of work um I believe is is being done on that front as well um for example by Soul wallet who've been thinking about domain specific

languages for modular front-ends um so yeah I encourage you to check that out as well um and yeah I think there's some like there are a few minutes left for some questions um is that right okay I think so um so are there any questions about anything that I've talked about so far and is there anyone with a microphone I don't think we have questions okay so no time for questions please cool okay yeah so uh yeah if if there's any questions like like you said uh

please come find me and thank you for your attention here's a QR code where you can find more um about what we're doing and also how the space is evolving we recently wrote up a blog post that kind of very extensively describes the developments in this ecosystem so far and where we think it's headed in the future thank you [Applause] [Music]