DappCon 2023: Modular smart accounts - benefits for wallets - Tobias Schubotz

Transcript

all right good morning everyone um my name is Toby I work at safe and um I'll be speaking about modular smart accounts um for this we need um a little bit of an intro to what smart accounts actually are um just also to account for different uh knowledge levels inside the audience then I'm going to be introducing um what um we mean by modular smart accounts the slides will be up in a second and then um I'll be sharing what we are doing um in the area at safe and I conclude this presentation with uh what this actually means for um uh wallet devs and users that's what I was talking about um so um yes smart accounts um what are

they why are they needed actually so I assume most of you have seen one of these slides in one way or the other um web 3 ethereum is not ready for for Mass adoption and um the news uh about compromise Keys lost funds exploits just won't stop coming and it's just a matter of time until the next one uh occurs and smart accounts are crucial um to solve this to prevent this a motivation from a little bit of a different angle is the following um there's this popular article by vitalic um explaining the um um the three transitions that ethereum has to um do in order to migrate from um this this experimental experimental piece of tech towards something more mature um one

trans is um scaling by moving to l2s and rollups the second one is actually the wallet security transition everyone moving to Smart contract wallets smart accounts and the last one the third one is um the Privacy transition uh which which refers to that um all transactions have to be like they need to be done in a privacy preserving manner if the user intends to and actually not only the based transactions but all gadgets that built on top of that so specifically relevant for us here is the second one if ethereum will fail according to that blog post because users would be uncomfortable storing their funds and their non-financial assets um um and everyone yeah would just move or stay um on on on centralized exchanges and this

triangle here is not one of those triangles where you can pick two out of three no you actually need all three of them so smart accounts um the traditional account on ethereum are private key based accounts um they're control by the single secret typically private key seat phrase and they have this all on nothing security model once you hand it out your private key not really a way to take it back um basically you hand it over full access to your account smart accounts on the other hand side they're controlled by code meaning they're customizable so really the the core Advantage here is that you can customize um um your account um yeah via code so you can compare a private key basic account to

an old school traditional mobile phone and then a smart account would be a smartphone so where you have different apps you can write different apps with different with with code and to customize the functionality of the device what do smart accounts enable um first of all easier onboarding um I mentioned on the first slide web 3 is not ready for Mass adoption onboarding is the first step uh with smart accounts you don't need to think about super secure setup right from the get-go which is a problem because if a user just starts their web three Journey um they don't know much right and so with smart accounts you can actually start with

something uh something simple uh and then as you get an experience as potentially um You Secure you want to secure more valuable assets you can add Security on the get-go and for instance two Factor authentication or something uh um more more secure more elaborate um the second second one is exoscope so you can really Define you can actually Grant partial access to your account uh depending on a use case for specific app you might just want to hand over uh that one part of your account uh to have access to for another dep that that's separate or you want to set somehow limits uh more generically so that's all doable with smart accounts you can also uh limit the the temporal Dimension meaning you can hand

out session Keys which are valid for a specific amount of time for a session and once that session is over um you can actually take back access and um yeah that that that that key isn't out there forever but actually only you then can access the account the fourth one I want to mention is uh you can actually replace keys that you use uh or the means that you use to access your account uh for instance um many users do store their secrets their private key to to their accounts and password managers and if you were one of the unfortunate people affected by the lasp pass hack in the last year um you probably had to um you know migrate your

accounts your private keybase accounts over to something completely new that changed your account address that changed your identity because there was this All or Nothing security model there was no way to do that otherwise to be really secure that um that will not be exploited in some way with uh smart accounts u in the best way you could have just replaced um the access or the key used to access your account and so your identity would have stayed the same another advantage of smart accounts which I'll be going to in a little bit more detail is transaction batching in my opinion it's actually one of the most straightforward ones and it's actually in used um out there since quite a while um a typical def interaction is a deck

swap for instance Unis swap but also one on one of the other traditional um exchanges you typically connect your account then you make have to make an approval transaction and then a second transaction to actually swap tokens to you to make actually uh your exchange with a smart account you can batch that together sure you still need to connect your account but then afterwards it's just one action to swap um um tokens now that's rather simple it can become arbitrarily complex for instance if you for instance would like to um take some uh liquidity tokens from um for instance curve put them into a yield aggregator such as Ur uh you require a number of transactions with smart accounts you can

batch them together and um there's plenty of examples out there um essentially the answer is always the same you can batch that together I'm also well aware that Ur or in that case make they have since improved it's not that you actually need five transactions but only two or three but still um um it's all they did that by customizing their platform whereas smarter accounts actually provide a standard on the wallet side to make this in a to do this in a more generic way and so by doing that we're able to um focus on the actual user step so the user action the business action that the user wants to do and we don't let ourselves and our users be kept hostage by to a certain extent um by the technical shortcomings

of the um underlying well blockchain because there was a reason why did many transactions have been required um but we're able now to actually reduce that and really focus on the step on the user action that that someone actually wants to do um yes the smart account ecosystem is growing it's not a thing of the future it's actually right here um safe is doing work in the area there's plenty others out there and um I would say it's not only the smart account ecosystem it's actually also the account abstraction ecosystem which you can use in a synonymous manner um account abstraction is this phrase or term which has gained abstraction this year tremendously V one ERC ERC 4337 that was mentioned in the first talk today but

also via other initiatives and um it's really in my definition or in our definition um that that um decoupling from the account so the identity from the way you authorize transactions from access control and um um so essentially it's the same like a smart account where you can customize the way you access your account you authorize transactions um even just looking at safe so I know this slide has meant a little bit to overwhelm you um uh we're seeing some growth um we have lots of projects building uh integrating on all levels of our stack from the protocol layer via infrastructure all the way to the

interface and so this just as an example that smart accounts are actually used they are here now with all that great um what what's still missing so why haven't they really taken off inte great scheme of things because if we look at ethereum or evm based chains private key based accounts are still the standard um and it's it's yeah smart accounts just have still a long way to catch up there are a number of challenges one is vendor lockin and fragmentation so um safe provides a smart account there are other smart accounts out there they're usually not compatible because um everyone didn't make um compatibility a priority that leads to fragmented and incompatible

ecosystems and generally a lack of of reusability and so hence duplicate work which is a problem if you actually want to scale if you actually want to build on top of the work that others have done before a second challenge um is Discovery so I shared a slide with the many number of projects that uh work with safe but uh we don't have like we have such an ecosystem map but on a more technical level we don't have a c place for all the extensions all the customizations that one could do with smart accounts and so that lack of discoverability um is yeah originated in in leads to a lack of of distribution and also generally the curation

mechanisms that um don't exist that we have to work on but it is a problem for uh adoption um because even inside the safe ecosystem um there is duplicate work being done and there is a a lack of um um reusability and last but not least um smart account is code so we're introducing additional security risks by um additional smart contract risk and so um smart accounts are in a way can be in a way more complex than the traditional accounts and so you just have to think more carefully about security um to ensure really all the assets are secure that brings us to uh modular

smart accounts um we had three challenges b a log in Discovery challenges additional security risks and um modular smart accounts uh propose a solution for this first on a rather abstract level here um the first one is interoperability um this one's really particular feature of um private keybase accounts you create them once and you can use them on any evm or compatible uh chain um you can use the same identity everywhere with smart accounts that's not a given so um we have to ensure that in one other way um um they are portable they're compatible with each other in order to really double down on the composability opportunities that we have

there open source is for sure definitely a requirement here as well because um smart accounts are security critical and so um you need to be able to verify what's actually going on in the code second one Discovery we just have to find um distribution mechanisms curation mechanisms because um we it's really hard for definitely for user but also for wall ad depth to really well first of all find work that has been done before it's first step but then also you need to be able to evaluate is it suitable for my use case is it secure who else is using it and uh all these these these these these questions and so we need curation mechanisms and last but not least the

security components um smart accounts are well or modular smart accounts um like the name says they modular so we need to find a way to encapsulate uh security uh properties as much as possible in order to really build for a diverse extension landscape because we have this advantage of of of of um of of extensions and so um we need to definitely find a way some kind of a pipeline to ensure um the security can be assessed um because otherwise um it it won't work um so I compared uh previously a private key based account to a um a mobile phone an old school mobile phone and a smart account to a smartphone so if we now have a classic smart account

um and a modular smart account aren't they both smartphones I would say yes and no um yes also the I call the T analyics smart account is customizable but in reality they stay rather static um after creation yes it can be customized and they are adapted to the specific use case but um then afterwards uh we don't take advantage of of what can be done with them whereas a modular smart account um yes they're also customizable but um we are ready for regular upgrades they don't have to happen it definitely depends on the context and on the user if um one should or wants to do that but we're prepared for this and so this is really like the left hand side is um a smartphone without the App Store um the right hand

side in my opinion can be compared to a smartphone with the app store because then there is a way for developers um to add more code while it's it's you know being run there's there space for upgrades and there's also the appstore has a review process also there is a review process required for modular smart accounts um this is a bit of a a more elaborate summary of what I've been uh mentioning so far um we need to be able like smart accounts um enable composability so developers re components second um they need to be customizable to the specific use case um the third one is um we need to find a way uh to keep things still secure

despite the additional smart contract risk and last but not least uh they need to be adaptable upgradeable in a way uh to whatever new use cases will arise because um yes ethereum may potentially in one uh part has um achieved um a product Market fit with some defi applications but um here and at other events plenty of people suggest more and more use cases and um wallets or smart accounts have aren't like they can be prepared but they will need customizations in the future so we need to be prepared with that and we think we can be prepared with that uh via modular smart accounts all right modular smart

accounts um at safe safe is at its core a modular smart account framework uh we've been working on this since 2017 with the first public release in 2018 and just as a rough overview besides the safe core contracts you have um roughly three main areas of of of extensions uh one is is guards it's essentially um hooking into um the transaction logic um by adding um checks um uh before or after transaction takes place these could be for instance risk checks or could also be me protection um mechanisms uh for instance the yearn

team is doing work in the area here as well um the second area are modules they actually extend um they theyve they they they are able um to create a um transaction logic besides the transaction logic of the core contracts um so they essentially extend functionality of the smart account from the ground La examples here are recovery if you lose access or um also specific um role um hierarchies for instance and last but not least um there is a thing called fallback manager which allows to handle um arbitrary function calls inside a safe that one is required for um some signature schemes and um to to

validate if um yeah a safe actually has been um authorizing um a specific action I've been mentioning that uh beginning of this presentation that um smart accounts enable a number of things but there's a reason why they haven't been taken off yet and we actually have the same issues just looking at safe um our killer feature here with safe has been um the multix so essentially as a group of people you can um um together create a save and then um depending on what you want a number of people are required to authorize transactions this is how we got traction this is how we got a product Market fit this is how the

safe got popular safe enabled so much more though I me mentioned a couple of things here um below the waterline um some things such as spending policies they actually life in our product um some other um things are are being developed um others are still thing of the future um some of these um opportunities are done via um um actors in in the safe ecosystem but um yes we have those challenges that smart accounts on a general level have inside the safe ecosystem as well and uh we need to uh solve for this so what we are proposing as one piece um to make this better is a

modular smart account protocol it's called safe core protocol on the one hand side on the left hand side here we have users and their accounts of course we believe that the safe smart account is best uh suited for this but um we think the protocol uh needs to be open to any um vendor um account on the other hand side we have all the extensions all all the customizations plugins hooks function handlers there can be many many more and we need to bring them together and um we believe there needs to be some Registries onine Registries uh to make this happen um first of all to make them discoverable but also um to uh curate them for instance um there can be a

registry that just um uh lists audited super secure um customization and Integrations another registry which is more experimental um and there can be many many more um actually we don't intend to uh write or maintain these Registries ourselves at safe but we the protocol is actually set up to be uh agnostic on all all um all Dimensions so yes um there was a slide with the iceberg um we actually want to establish safe core safe core protocol at the center of it and then find a way wire Registries um to make it um discoverable um and uh basically yeah

reusable what does this mean for wallet deps wallet users before I get into that I just want to highlight um some details about the safe uh project um because we have on the one hand side safe core it's actually um our smart account development Suite with the core contracts with a number of s some uh basic um not so like like some some basic um um apis also that are required to actually get going to um if you want to build on top of safe as um a a project as uh maybe even a third party wallet on the other hand side and this I think what makes uh safe unique here it's we have the user interface as well it's called safe wallet it's actually

trusted by a number of users by um um quite some some some asset assets as well and um so so so we have both um so once we ideally established that safe core protocol we also have or we at at least can showcase uh via safe wallet how it can be used what are advantages it brings um for for um wallets um so we can actually Kickstart or this can be one puzzle piece to Kickstart um um the protocol so the first one was uh security um you can already um benefit from the security of safe by just reusing the safe core contracts they have been around since quite a while

fortunately uh no high or critical um um vulnerabilities found um yet and um so yeah their trusted you can reuse them however I was talking about that customizations they always bring additional risk and so we're working on um also some kind of an audit pipeline audit tool chain um for new extensions that these extensions can or need to go through uh one piece was the um publication of an an an ERC for for onchain audits it's just the first step uh there will be many more um because yeah we we cire some standards there and need to collaborate um with uh the audit and security firms

there and yes depending on your registry there are different security attestations depending on what security level you actually want or need as a Dev or as a provider portability um you we are working on portability on different dimensions uh just to highlight a few um you can tap into the existing safe user base if you're compatible with safe um there's nothing that uh prevents a safe user to for a specific use case um work work with another wallet because um we expect wallets to be use case specific um but the account the underlying identity needs to be portable also following a standard will help with

depth compatibility what I mean here is um deps built still primarily for private key based accounts and uh we noticed that or we had to learn it the hard way that um some use cases the classic one is signing messages just don't work with smart accounts because there is no single private key there are solutions for this um this instance uh um IP 1271 but um uh yes deps slowly are um adapting to that um based due to our work due to the work of all like many other smart account providers in the space as well but um by ensuring that you um use something that has that's that's used already you can benefit from

that discoverability I was mentioning that term a lot of times um there are existing components you definitely want to reuse them if they cover the use case you have in mind um I was mentioning the spending limit um that we have in our UI as well we actually planning in safe wallet to add more and more onchain um extensions as well uh there is the Zodiac suit of modules zodiac is a project inside theosis ecosystem as well um they wrote a number of safe modules for specific use cases which can be uh used they are mostly audited as well and um yes all this uh can be like we try to enable that via these mentioned

Registries and um the last one I want to mention here is versatility um we believe it's safe that security and Trust exists on the Spectrum there is no one solution to all the problems here because there's this wide range of use cases there's this wide range of different users of um different knowledge levels of even different security requirements and assumptions and so smart accounts really allow how to um build for the Spectrum depending on the needs to make this more specific something we are mentioning regularly is hybrid custody um this means that um sometimes actually partially

centralizing um um a part of the system can actually be beneficial for a user what I mean is you as a user you still hold primary access and um it's a self like self custodian real wallet ultimately however for a specific use case for instance or maybe a part you might want to interact um to certain extent with a more centralized actor for instance custodian if that's okay for your um security model and and your trust level um you could work together with them to approve transactions for instance above a specific spending um um limit or probably more important for retail users uh would be that they would be able to recover your account in case

um you lost access second one is Insurance um transactions verifying that what verifying um that a transaction really does what you intend it to do is is a hard problem and so um a centralized actor could help with fraud monitoring and could block malicious transaction I think it's important that they cannot initiate transactions on their own but it's more of a rer right that they have and so um yes this could help you as well uh just explaining what what what we mean there by by hybrid cross and last but not least um it's probably an example less tangible but still um you have your assets on chain but um some

exchanges might want to facilitate trades via an offchain order book and they need to have a way to be able to then settle your order with the assets that that exist in in in a self custodial way on chain so um temp temporarily you could um hand over um some access um to assets as a collateral then the trade can be settled before um the access um moves back really important to mention here is um the user can always cut courts with counterparties so um we would recommend always that any centralized counterparty only has a v right they they shouldn't be able to initiate transactions on their own or in case of recovery for

instance that they can only do so after a specific delay because um um it's really important for the the the kind of like the the power balances here that a user has ultimate control and um yes I guess it's part of it's task of safe and other wallets to make sure um that users um can do that in a way that is easy to understand all right um I uced safe core protocol here uh it's an op open modular framework to make smart accounts more secure more portable more composable if you're the that left uh Q crate is for

you um there we share uh uh the current status of um the specs um there's also some code already available we're very open um to hear feedback uh to make sure this is really um satisfying the needs and the requirements I've been um sharing here um for anyone who doesn't have a save the right QR code is for you here um um yes please create a save um we integrated um um for instance also gelato um on gnosis chain uh where we sponsor transactions so it's um if you haven't tried safe yet that's a way to try it out and to really um experience that uh disadvantage of of smart accounts via the step- by-step um

onboarding um because yeah this this can be the foundation um for your um web 3 account on on ethereum thank you thank you so much we have time for questions and we have some microphones yes over there in the back please yeah um thanks for the talk I think I finally understood why smart accounts are such a big deal after hearing what you said um my question is that I know a lot of daps are building like reputation management protocols based on the public key of wallets uh like an example as gitcoin passport so I read somewhere

that with smart accounts your public key keeps changing so I was wondering how reputation management and reputation scores would work in a world of smart accounts okay um I think I most of it um I your question in way that there are some systems who still use the public key of of an account uh to base reput on right and so um I think I'm I'm not familiar with the with the details of for instance G gitcoin passport however I think as smart accounts ultimately are better suited for this because reputation I assume is not transferable because otherwise yeah it is there's no way I think then it defies the purpose

of reputation smart accounts really allow you to replace the access control right so I think in a way smart accounts are better suited for this because there is a way to keep that identity um from from changing and so it's a better place to actually keep your reputation and um I assume some of the steps use classic private key based account or at least the public key part of that um um in their depth because it is it seems easier in the beginning um to to to to work with that because of the way you you can I guess easier use offchain signing for this and I assume

this is what the steps primarily um um um leverage um however there are solutions for smart accounts um some um terms here or one b word uh buw is um counterfactual deployment um won't be able to explain it right here but um you can actually use an address like the account address of a smart account before it's actually deployed because you already know where it uh will end up with and so this is just one example on how we can um actually make um the account creation even with smart account easier or another option would be to use a cheaper chain um so basically anything other than ethereum to to set up an

account so applications could sponsor um the account creation thereby reducing just that um the friction that exists and um yes so I believe for reputation systems I think smart accounts are a better solution long term I saw a question over there Y in white hello thanks for the talk um I have a technical question and a bit of background at Aragon we are also building like a plug-in system for onchain organizations to plug in different governance capabilities in and out and we thought about the life cycle of plugins and the challenging thing are dependencies that users might want to

create between plugins or uh guards as you call them how do you deal with these dependencies and like how you deal with the setup in the installation uninstallation if you could elaborate on this um there's no single suc answer um yet I mean one way is um we keep we try to keep these these guards extensions um um like we keep try to keep the interface in a standardized way um there's probably the like some substandards there as well depending on the input and output that everyone like each of these extensions um uh require um but I think here this one is really more on the on

the on the technical side of things where um then the wallet deps or or wallets can ex like discover these these plugins and then um the user facing part on how to make sure that the user still understands what does it mean to um um actually install this plugin now that's something that's that's so use case specific like so far actually we don't have a great idea on how to standardize that would be very interested to hear your thoughts there as well and maybe also your experience um at at Aragon um there are some initiatives to make generally transactions more human readable um we at safe also recently did some work there um for plugins that's actually much much more complex because

um just the the space that basically the ways how it can affect your account is just way bigger and um that part basically above the technical level to the user and how to explain what a plugin actually does basically supporting that life cycle of a plugin um we don't have a good answer that I could you know confidently share here on stage than we have time for another question and I see one uh over here yep in the front we might have time for another one so hi there yeah uh great presentation

um as someone that's been batching transactions for a couple of years now um programmatically I've always kind of thought that there was a better retail use case on the UI um I don't know if you're familiar with through a combo but is there something on the product pipeline where you can kind of have something similar on the safe UI for more of a kind of your retail offering um not not something imminent I mean we have something in DUI for um rather experienced users where you can actually somehow like in a way collect transactions um if you want to do all your uh defy interactions like in in one batch uh there's a way um to do that um for retail I believe we just I don't think it's wise to even expose that term

batching there um in a way it's we'd have to focus more on this this well that user step let the step that the user wants to do and um anything else should just happen under that hood so um I mean for combo is is great obviously uh you can plug and play um different different um building blocks into one transaction I think ultimately for retail usage it this is too much already so um yeah okay perfect thank you we have time for one more question actually thank you for the talk um now regarding the security for a typical private key account the only risk we're talking realistically is the leakage of

the private key which rarely happens all right now for the smart contract for the smart account um we're talking about so many plugins and extensions so the risk surface is enormous is it even realistic to expect Security in that regard a fair question H something we will have to prove that this is possible um I think you're right there is for private keybase accounts is that that one part however that's that that's a big one because um or actually maybe a different angle um since this is the only one if you are not comfortable stirring that yourself um you have to work with some third

party and that already impacts the self- sovereignty of your account and um there is I mean yes there's other Solutions we saw talk about MPC there as well but really just talking about this private key based accounts um if you really want to maintain self sovereignty um you need to make sure to store it on your own and that's also unrealistic um fa Fair Point um can we actually make sure that these customizations are secure I would say we have to and um but it remains to be seen or it remains on on us and everyone contributing to um provide um an overview of the different um just path of of of possib

um um threats and then finding mitigation issues because then yeah over I mean safe any smart account in itself has a challenge as well right so why do you even want to uh store Assets in a smart account you still do that because um the the the functionality you want multi but any other is what is more important to you so you were a like many users made the choice they're fine to take that risk because it enables um so much more but the details yes it's definitely not an easy um question to to solve for unfortunately that's all what we have time for so please thank Toby for his

talk