Why account abstraction on L2 is critical for mass adoption
ETHCC 5 · July 2022 · 28:15
Julien Niset examines account abstraction on Layer 2 networks, including Starknet and ZKsync. Examples such as multicall, social recovery and fraud monitoring illustrate possible changes to wallet usability and self-custody.
Speakers
Topics
From ETHCC 5, hosted by Ethereum France.
Transcript
[Music] okay can you guys hear me cool let's get started so uh today i will be speaking about scaling self-custody for some reason while converting from dark to pdf my title got mixed up but the second part of the title is why icon abstraction on l2 is critical for mass adoption so i'll be talking about icon abstraction layer two and basically the end goal is to scale self-custody i'm julianizer i'm one of the co-founder of of arjun and i will illustrate what i'll you know present through arjun x which is a new product that we have released on starknet so let me start with the obvious
obviously hopefully we all agree that self-custody matters i mean one of the benefit of blockchain is actually to enable through ownership and of course if you don't really own an asset if you give custody over that asset to another party you don't really own it so self-custody really matters and that's something even if it's pretty obvious that's something i believe we tend to forget in our ecosystem and of course the recent events have reminded us why self-custody is important because of the market being done i mean i'm sure you've all followed that but some centralized exchange became insolvent and that means that users could not withdraw their funds so again some users that give custody of their
funds to centralized parties certainly cannot access their funds anymore so obviously they don't have ownership so i think that's a good reminder that that self-custody is important but of course the question is why do people you know rely on on custodian solution i'm sure if i ask the audience most of us will have a non-custodial wallet but we also all have a coinbase a binance or ftx account so even though we all believe in self-custody we all make the trade-off of using custodial solution and the reason for that is because self-custody is hard even though we've been working on you know on this ecosystem for for many years self-custody is really really hard and i mean just looking at crypto
twitter every day will remind us that of that fact there's everyday people losing access to their phone having their wallet being compromised and so on even crypto experts i mean the example on top right is huge from nexus mutual he's a well-known founder of a d5 project and he got hacked just i mean all this illustrates that self-custody matters but self-care study is really hard so the question is why why is self-study so hard and why haven't we been managed to actually fix self-case study and scale custody because if you want to bring blockchain to billion of users it's not only sufficient to scale the base layer the protocol to enable you know cheap transaction we all also
need to scale the user experience and that's why i like to talk about scaling self-custody and personally at me and at arjun we believe the reason why self-custody is still so hard lies in how account works in ethereum i i like to call them the original sin it's just an analogy so you probably all know that but i think it's good to remind you know how ethereum account works and try to have a new perspective on that and trying to see how we can actually fix this problem so as you probably all know there's two types of accounts on ethereum you have externally on account that typically use or zone and then you have contract account which can contain
bytecode an eoi has an address announced and a balance and and a user owns an eoa through a pair of cryptographic keys that we also call a signer and what's the link between the signer and the account well the link is through the address of the account which is derived from the public key of the signer and only the private key of the signer can actually trigger transaction and is authorized to make transaction on the account and on ethereum this logic is very well defined to authorize the transaction the signature scheme is well defined it's hardcoded it's ecdsa and even the elliptic curve that you need to use is also hardcoded in dvm it's sec p256k1 so all these details are not that
important but what matters is that everything about accounts on ethereum is hard coded there's nothing that can be changed and so taking a step back we can actually visualize account in the signer which lies in the user which is the user part of the account and then on the other side we have the eoa account defined on ethereum in the evm which contains the address denotes the balance and all the logic to validate and execute transaction and as i mentioned these two objects there are actually two sides of the same con right we can say that the signer which is the object that should only be there to authorize to move your token is actually tightly coupled to the account the
object that holds your token but that's not it's not a necessary condition right the signer should just be there to authorize transaction while on ethereum there are really two sides of the same coin and what i mean by that is because the signer is kind of the account and the account is kind of the signer that means that if you lose your signer you lose everything if i have your signer i have everything and so the the real problem with account it's because of that coupling between the two because the signer is basically the account and so we can say that in ethereum we are building a system whose entire security relies on user protecting a single
secret at all cost a secret that cannot be lost and cannot be compromised and there's no safety net if you make one mistake and of course we all know that humans never make mistake everything is gone and so of course we believe that arjun and i think people are starting to realize that we will never i mean we will never scale blockchain and reach mainstream adoption based on this paradigm so something has to change right and so the question is can we do better is there a way to actually build accounts in a different way that would enable us to build these safety nets and to build that experience that is needed for users and of course for those who know argent we believe there is a
solution that's why we've been focusing for the past almost four years now on building smart contract wallets smart contract wallets actually enables you to put logic at the account or at the the wallet level the account level but the problem is that on ethereum account or smart contract wallet are second class citizen the ecosystem is still built for eos so even though there's a lot of stuff we can do there's also a limitation to being a smart contract wallet on ethereum and so what we believe is that actually layer twos are an amazing opportunity to fix this problem i think we've learned a lot with ethereum the past six years and so going to layer two is actually the right moment to fix the few things that should be improved
and so of course we believe that there is a solution to that it's called abstraction interestingly icon abstraction has been on the roadmap of ethereum from the beginning if you look at vitalik is basically publishing an eip for account abstraction every year the problem is that there's so much at stake on ethereum that it's actually such a big change that it becomes difficult to push but so the idea of account abstraction is exactly that is to decouple the signer from the account in practice what that means is that the account every account on chain is now a smart contract which can have its own logic to validate and execute transaction okay so that means that if you want you can use a different signature scheme maybe you don't want to use ecdsa or maybe you
want to use a different elliptic curve or maybe you want to have multiple signer by default and have a native multisecond in your chain or maybe you want to have an account where your signer can be replaced or rotated based on on some logic all these become possible because with account abstraction every account is a smart contract and what i think is is very exciting is that there's actually two leading layer two solutions stockwear with starcnet and mata labs with zk singh that have decided to launch with native account abstraction so we actually have very soon in in production two systems that are both zk roll up so that can scale and that enable native icon abstraction which means that we can also scale the user
experience and of course that's why arjun we've been very excited about these two projects and that's why we started building on them so of course if every account is a smart contract that's fantastic but it cannot be any smart contract of course there needs to be some a certain interface that the operating system the evm dkr os whatever understand to interact with accounts and so we've been working with with open zeppelin and starkware on defining that interface in starknet so i will illustrate the rest of this talk with starknet but of course a lot of it applied to to zk sync and so we came up with the following interface that every account needs to to satisfy
so having a quick look again pdf are not a great idea but anyway there's two important method on the interface of your account is a method to validate and a method to execute transaction the goal of the validate method is actually it's a way for the operating system the os or the sequencer to quickly validate that a transaction will be valid and that it will be paid on ethereum this is typically done by dvm by just checking the signature checking the nons and making sure that you have enough ease to pay the miner fee and that's why you typically pay 21 000 gas to that for that validation execution and so with account abstraction you can actually program the rules of that validation and once the
transaction is validated there's a second method to execute so typically when you submit a transaction the upper the os the krs in this case we'll call validate and then we'll call execute so these are the two central method of an account there's a third one which i believe is very important it's a way to verify offchain signatures if your account defines the logic of what a valid transaction is or what a valid signature is of course if you sign an off chain message like an eip712 for example you cannot verify the validity of that signature locally using say ec recover if you build it up the only person or the only object that knows if the signature is valid is the account itself and so you need a way to contact
the account and that's why we build a method called doing is valid signature for those who know it it's exactly eip-1271 in ethereum so this has been designed for smart contract wallet but on starknet it will be really at the interface of every single account and the last thing that i found pretty exciting is because we're starting from a blank page we actually convinced starknet to put multicalls by default so that means that on starknet every transaction can be a multical and i believe that's very very exciting and i'll come back to that later so if you're a devs there's a few things that you need to remember about all the stuff that i've been talking so far the first one is that on a chain without an abstraction account
are smart contracts which means they need to be deployed that's something that while it will take care of but of course if you build it up in a flow you need to take that into account the address of the account will no longer be derived by whatever signer is authorized on the account but it's because it's a smart contract the address will be computed as the address of a smart contract transaction can have multiple signatures so you shouldn't assume just one signer for your account maybe it's a native multisig and of course if you want to validate offchain signature you should use his valid signature and ping the accounts directly and finally you can and you should use multiples and that's basically all you need to remember about an account abstraction so
far okay now let me be a little bit concrete and show some examples of the cool stuff that we can do leveraging account abstraction and of course i am biased but i will illustrate them with arjun x which is the wallet we've been building on on starknet so in a nutshell argen x is the first wallet on the stacknet ecosystem it comes as a browser extension you can have multi account it works on testnet mainnet and it does everything you expect from a normal wallet you can send and receive you know tokens nfts you can unwrap funds you can interact with dapps and it's 100 open source a last slide of chilling actually it's been an amazing ride right
stack net is still in alpha and we already have more than 200k download so i think that's pretty pretty exciting there's actually no a bridge to from layer one to start net so you can actually unrave real funds ease die and so on and so there's already more than a million being secured in argent wallet so this is you know growing growing very very fast okay now how does arjun x works again it works like you would expect from a wallet while typically in ethereum when you think of a wallet you think about the the extension the ui and then the key that can sign transaction of course in a world with icon abstraction you need to think about the account contract that's actually being managed by by that
interface so when we talk about arginx you need to picture these different components the ui that the user uses the account being unchained and then the keys that are the signer that had authorized to sign transaction and okay very straightforward if you go to adapt you connect your wallet you click on a button it will trigger the wallet to open just like metamask you can approve the transaction in this case it will send the transaction execute the transaction on the account which will validate if whatever signature has been provided is okay according to the custom logic of the account and if yes it will execute the transaction so multicalls multicol is something that enables you to execute a sequence of of
transactions a sequence of calls again actually all the id that i present we've developed them on l1 with the arjun vault but now they become native on stack net and that's why it's it becomes really really powerful sorry that's an example of a simple multi-core right you adapt you want to do actually three action you want to chain a sequence of three operations when you can bundle that in a multicall and the wallet will execute them in one transaction so the account contract will orchestrate the execution of all these calls why is that really cool because first of all for the user it's only one signature so the ux is much simpler if you think of the painful you know approve and call that we have an
ethereum with multi-call it just happens in one transaction you can just tell the user i need to consume 20 die and you will make a multi call which will approve 20 die on the user's account and then execute whatever operation and pull these dice so for the user it's much simpler to understand so the ux is much better but there's also a nice corollary is that on stark net the main cost of a transaction is actually publishing the state difference to l1 so if you do a multi-core and along the multi-core the state reach an intermediary state that is rollback before the end of your transaction you don't pay for that state change if you think about the approve and call you'll see that the allowance storage slot is modified but it's rollback at
the end when the funds are consumed if you manage to price it correctly so actually leveraging that you can make complex operations that are actually much cheaper than what it would cost on l1 because you can play intelligently with the modification to your state okay and here is just a simple example without gen x you can actually trade some bat for some die and then in one transaction i can trade them send part of it to a friend and the other part to another account another so multi-core really cool another thing that you can do with account abstraction that was mentioned in the previous talk is social recovery the idea of social recovery or the goal of social recovery is to get rid of seed phrase
how do we do that because your account can be customized you can have a main key that is the the sign or the owner but you can actually add a second key to your account and you can actually program your account such that that second key cannot execute transaction but it can actually do only one action is give you back access to your account if you've lost the main key so say you've lost your computer what you can do if you have a guardian what you call a guardian you can contact that guardian and say hey i've lost my computer can you reprogram my account and reset the ownership to this new key that i've generated of course this account this guardian needs to be someone that you that you trust
on arjun vault so it's a protocol it can be nfm person but you can also give that to a simple recovery service that you trust and so now when you lose access to your arginx wallet you can contact that recovery service authenticated with email sms whatever voice you can go to the counter there and they will give you back access to your account what's interesting is that you remain in control this guardian this recovery service is there because you've selected you've chosen to add it you can remove it at any point you can choose to go to another service it can actually be you with a hardware wallet if you want so it's a great way to get rid of seed phrase while maintaining self custody
playing with these ideas of customizing your account you can again imagine that you add a second key to your account so you still have the main signer which i represent in yellow but you can decide to add a second key and give that key to a service that will need to co-sign every transaction that you make i know that service every time your rgx wallet needs to make a transaction you can send the call data to that service which can inspect that call data because of course we humans even though we know that we should inspect and review every transaction we usually don't go to the smart contract and the smart contract of the smart contract being called this is for human it's complicated but service can orchestrate that much better so now you
can imagine that every time you make a transaction you send the role called data to the service that will inspect the transaction based on some business rules that you have defined maybe you've decided to have a hundred dollar daily limit that service can know already you're looking at unchained data you've already spent 100 so you know this is maybe a bit weird or you usually spend 15 and now you're transferring half a million this is maybe weird or maybe you're pinging a contract that has been blacklisted so this service can depending on the context of the transaction the risk that he sees for the transaction can decide to auto sign automatically can decide to do nothing or actually can decide to block the transaction and when it does nothing maybe it can
ask you to prove who you are with 2fa so using this concept you can actually reproduce the experience that you you have in the modern you know online banking application except that again this is fully non-custodial because you control who you use as a fraud monitoring service so this is what i will illustrate you're making call on adapt you believe that you're doing something that is legit but actually the dap is calling a malicious contract the fraud monitoring service will detect and block and if the service doesn't know what you're doing maybe it's the first time you interact with that party it will just ask you to confirm who you are with the second factor that you've chosen another idea that we are developing on
our gen x which i believe is really cool is the concept of session keys again we've introduced that three years ago on ethereum we called them dab keys way too early but now we believe that the timing is probably much better the idea of session key is again customizing your account so imagine that you want to play a game if you play blockchain game one of the main problem is that every time you make a transaction you need to sign the transaction and that makes the user experience very clumsy now imagine that the game at the beginning of a session generates a key locally in the dap and associate that key to some policies so it says this key will only be valid for 20 minutes and it can only call contract a and contract b and method one and two of this contract you can actually take
all that information send it to your account and store that on your account so now that key is authorized to make transaction directly under only under the perimeter of the policies that you have defined why is that cool because now you can play your game you don't need to have a wallet anymore every time the game needs to make a transaction it can actually directly send a transaction on chain and you have the guarantee that the transaction it makes is within the perimeter that you have defined and that your funds are still safe because the key can only execute the few things that you have approved another cool idea i think i only have a few minutes is you can imagine because your account is customable you can choose to use a different elliptic curve so now you can
start to use put the key on your phone in the secure enclave of your phone we choose a different elliptic curve approved by the nist and now you can turn your phone into a hardware wallet and actually your key is in your phone but you can put the logic to verify this kind of transaction on your account on argen x so now you can have an experience where you sign with your phone the secure enclave of your phone which makes the experience amazingly secure and if you combine that with social recovery i think you are on par to have an amazing experience use a hardware wallet but you still have the benefit of social recovery if you happen to lose your phone one last thing that we are building is the concept of plug-in is to make the arjun account a bit more modular so
letting third-party developers build plugin that can bypass the validation so that you can create and customize your your arjun account yes so in conclusion i believe that account abstraction is really a game changer for the usability of cell custody i believe that it's the only way to scale self-custody and we desperately need to because if we don't users will continue to rely on centralized parties layer 2 is a great opportunity to actually fix that and push for icon abstraction we are very lucky that starknet and zkc have decided to launch with native icon abstraction but i do think we should lobby to all other layer twos to make them adopt that technology because i think that's the only way to scale the ecosystem and of course
argenex which i encourage you to give it a try it's the first wallet with native account abstraction and with this i thank you [Applause] hi my name is asta a quick question about the argent guardian which is used as a recovery mechanism um can you clarify whether the argent guardian that you know argent provides by default has access to actually uh be able to retrieve keys like say if you were subpoenaed and you know in that case if it were possible then um whether you can still say it's
non-custodial yes so if you have one guardian if you if you still own the honor key you are still in control so yes of course this if you use a centralized service as your guardian so you can use a hardware wallet but if you give custody of that guardian key to a service someone can force that service to actually either block you or do an operation but if you still control your account that's fine because you can revoke that key actually if that key is trying to do a recovery you can still cancel that recovery so i went a bit fast but it's actually a complete protocol with a seven days time delay during which if you still own the key you can actually cancel whatever
operation the guardian is trying to trigger and you can revoking and put another guardian so yes if you control the on the key it's fully self-custodial you are in control of course if you only have one guardian and you lose access to the key and the day you contact them they decide to be rogue at that point you have a problem but that's why on arjun on the ones users which have a lot of funds they choose to have three guardians or four guardians or combine a centralized service for convenience with the hardware wallet that they use as a backup so it really depends of where you want to put the threshold and how you want to configure your account very interesting presentation thank you have you looked into scenarios where the
user starts with a custodial wallet that's managed by the company that's going to welcome the user into web3 and then the account is actually transitioned into a non-custodial wallet yes that that's definitely something that we are considering except that we don't want to start with something that's custodial at the beginning i think that's something that we should avoid the way we see thing is that actually what matters is the form factor that you use to manage your keys so your keys can be on phone they can be on mobile actually an experience that we are thinking is what we call a cloud wallet it's the idea that the user will go to a website and he can log in with email and password for example because in the end users don't care about
blockchain they just want to you know they just want to have access to an application so maybe there are people that will come to the blockchain for a game what you can do is that they can log in with email and password for example and then you can encrypt the key you know with the password and then store that backup somewhere there's other ways when we can own a key and the users can have the backup file encrypted that they control so there's ways to make that non-custodial which are very simple it's it may be self-custodial but it may not be censorship resistant so there's of course always trade-offs in what you do but if you start to only play a game maybe it's okay because you only pay 10 dollars you don't want to know its blockchain and so you can start with
that experience but what's interesting is that you already have an urgent account an urgent smart contract a full large and smart contract that is deployed so we think exactly about this kind of experience he's making a small libraries that you say games can use and then when a user has been playing the game for quite some time maybe has on some nfts and now it's the right time to actually tell him you know what this nft you can bring it to a marketplace and maybe you can actually list it and sell it at that point is a good moment to make them move towards a more secure and a stronger censorship resistant wallet which may be the browser extension or the urgent uh app on mobile so yes we really want to actually enable that flow for users yes um when are we going to see
uh micropayment direct debits utilized um by well web 2 companies utilizing micro payment direct debits that's a very good question and i don't think i'm the best qualified person to answer that i i do believe that it's coming payment we all feel that payment is an important application of of blockchain i think for many reasons it was not doable up to now i think with you know with layer twos and maybe layer threes which are stack net is building for example with starkx i think we are approaching a system where micro payments can become interesting because they can be very
very very cheap which i think is necessary so you can still have payment and transfer of on-chain which become very very fast and very very cheap so i do think we are getting there and that's something that we are monitoring at argent but so far it was it was clearly too early the technology wasn't there yes [Applause]