 All right, so thank you all for being here first talk of the day after ravi is kind of a challenge, but Hopefully we'll make it fun so my name is Julian is a I'm one of the three co-founder at Arjen and This morning. I'll be talking about account abstraction why it's it's a game changer for the UX of dApps But I think an alternative title of my talk could have be how to scale self-guest study so let me start with a pretty obvious statement and I hope we all agree in this room that self-guest study matters, right? Blockchain is an amazing technology that for the first time can enable true digital ownership But of course you don't really own an asset if you give custody to someone else to a third party And I think the recent event of this summer with the problem with Celsius is kind of a good wake-up call of what Bad things can happen if we rely on custodial solutions But of course we all know that self-guest study is hard right if we look at crypto Twitter We'll see every day users, you know Explaining how they lost access to their assets or how the assets got got stolen And I mean sometimes these people are expert if you look at the tweet on the top right It comes from huge you got the founder of a well-known d5 project So even experts are making mistake and are basically struggling with with self-guest study So the question is why self-guest study is so hard right and We believe that urgent that the problem lies in how ethereum accounts were designed At the beginning of ethereum. It really lies at the heart of the EVM So let me dig a little bit into ethereum account to try to understand Why there are a problem and then see how we can fix that. So this is pretty basic I'm sure all of you know about ethereum accounts, but I think sometimes it's always good to take a step back and see things with a different perspective So we all know that on ethereum. There's two type of account Externally on accounts or eoA is in short that can initiate transactions And then you have contract accounts that can contain logic and we know that an eoA as an address for identification Announced to make transaction unique And a balance to in ease to pay transaction fees and we say that a user owns an account Through a pair of cryptographic keys also called a signer, right and what's the link between the two? Well the address of the account is derived from the public key of the signer and Transaction from the account can only be initiated by the private key of the signer So there's really a link between the two and on ethereum that link is not is not random You will need to use a very specific signature scheme cause you see the essay on a very specific elliptic curve Secp to 56k1 the details are not that important But what matters is that all of this is outcoded all of that logic is outcoded in the eoM And so if we take a step back We see that in the user space We have the signer the key pair and then on ethereum We have the eoA with all the eoM logic to validate and execute transactions And we see that there's really a type coupling between the two right these are basically two side of the same coin and That's kind of the problem because on ethereum We have merged the concept of the signer the object that's authorized to spend your token with the concept of the account The object all did your tokens on ethereum They are basically two side of the same coin and that's of course a problem Because if the signer is the account and vice versa that means that if you lose your signer you've lost everything If I have your signer I have your tokens right that basically means that on ethereum the entire security relies on users Managing a secret this private key designer are all cost and as a user you cannot make a mistake if you make a mistake you lose everything And I mean if there's one thing we've learned from 40 years of the internet is that we humans We suck at managing passwords and we humans we make mistake So of course I mean this is absurd and and this This concept this paradigm will never work for mainstream users I mean do we really expect the next billions of users to basically being able to manage that single secret at all cost? I mean we're pretty convinced that the answer is no so can we do better and Fortunately, yes, we can do better and there's something called account abstraction The idea of account abstraction is is really to decouple that relation between the signer in the account With account abstraction every account is a smart contract that can contain its own logic For example, you you may want to use a different signature scheme Or you may want to use a different elliptic curve Or maybe you want to use multiple signers to validate transaction think of a native multi-seq or maybe you want To rotate your signer based on some logic that you've defined with account abstraction all of this is possible Another way to see it is that on a complete account abstraction every account is a smart contract with custom logic that can initiate transaction So no smart contract Can become top-level accounts and the good news is that with true account abstraction There's no more EOS right because every single account is a smart contract And you may have heard about account abstraction lately But actually it's not a new concept if we look back we see that Vitalik started talking about account abstraction as early as 2016 with the first EIP been proposed early 2017 EIP 86 We are Arjen and people like Gnosis with the Gnosis safe We started building smart contract quality in 2018 which basically were a form of account abstraction The idea was really to solve these these UX problem for self custody using smart contract But we did so at the application layer and we came with idea like social recovery fraud monitoring and so on In 2020 there was a new EIP again Led by Vitalik EIP 29 38 where the idea was to add a new type of transaction to let smart contract become First top-level accounts so enabling smart contract to basically make transaction and pay for transaction fees Soon after there was the IP 30 74 Which took actually the opposite approach which was trying to enable some of the smart contract feature on existing EOS And then recently there was a new EIP again led by Vitalik EIP 43 37 Which basically is a generalization of smart contract wallet the idea is to Decentralize some of the infrastructure that is needed to make To to to write and to operate or kiss a smart contract wallet And I think EIP 43 37 is very interesting For different reasons first of all it does not require a fork So it lacks my contract wallet it works at the application layer and and it's actually a good architecture. I think which can Let us in what native account abstraction should be in the future So let me dig a little bit into 43 37 rapidly. So on 43 37 users They send they don't make transaction They send user operation and they send this user operation to a highly level mempool on which you have Bundlers like miners that can basically take a bunch of these user operation and burden them into a normal L1 Transaction and that transaction is sent to a specific contract a single term called the entry point When that transaction reach the entry point contract the entry point will basically orchestrate the validation and the execution of these user operation and it does so by calling two methods of the on the Wallet a first method to validate the transaction basically asking the wallet Are you okay to execute that operation and will you pay? You know will you pay the fee to do so and then a second call to execute So we see that with 43 37 there's a clear separation between validation and Execution okay, I mean all this is great, but is this really the end of account abstraction? I mean every reach the holy grail of course the answer is no each of these EIPs that have been proposed over the years They all bring some of the features of account abstraction, but they also all have limitation If we look at EIP for 337 The main limitation is that it leaves at the application layer So basically EIP for 337 wallet lacks my contract wallet There are second-class citizens because they still live on the chain which relies on the OAs Every single dApps the tooling I mean the way developer things about account We all think in terms of you as and that makes my contract wallet or for 337 wallet second-class citizen And that's actually a blocker for their adoption So what can you know? What can we do next well? What would be ideal of course is to bring for 337 one layer down to bring it from the application layer To the protocol and actually the people who propose for 337 are working on that right now But what we think at Arjen is that we shouldn't wait for that to happen on L1? I mean we are knowing an era where layer day a little twos are picking up It's actually an amazing opportunity to fix some of these limitation of of Ethereum I mean the EVM is a great VM, but we know that there are stuff There are some limitation there are stuff that we know know can be improved And so we believe that layer two is actually the great moment to do so and that's why I mean We've been really excited lately because two of the major layer two providers namely Stockland and ZK sync F committed to ship with native account abstraction And so at Arjen we've been working with them quite closely for the past year trying to bring our experience as a smart contract Wallet company and making sure we can really design account abstraction the way It's needed for for users and for the next wave of of users So in the remaining of the talk I'll basically focus on stock net and give you some some example in the stock net ecosystem But just remember that everything I will say applies to ZK sync as well So with account abstraction every account is a smart contract But of course it cannot be any smart contract right the protocol or the VM needs to know how to interact with that Account contract that means that the account must comply to a certain interface And so we've been working with stock net and an open zeppelin on Defining that interface for stock net and we came up with the following Interface it's written in Cairo So don't worry is that you know the style might be a bit a bit surprising But what's important to note is that just like in the IP 4337 we have a method to validate a transaction So every account must expose a method to say to to validate and decide What kind of signature schemes it wants to use you know what kind of nonce mechanism and so on and there's a method to Execute to really execute the call and interact with other contract and because we are starting with a blank page on stock net We did something very cool is that We introduce multi-call natively so on stock net every transaction is actually a multi-call by definition natively and I'll come back on why that is exciting in a few minutes on Top of these two methods. We also have a method to Validate the deployment of an account that means that no account contract on stock net can pay for their own deployment That again, it's something that enables a great user experience and finally we have one last important method call is valid signature In the idea of is that it signature is to basically verify off-chain transactions, right? Again, I'll come back to that but smart contract They cannot sign but they can delegate signature to signers to keys But they must expose a way to say okay This signature is actually valid for myself and on on Ethereum. This is the equivalent of VIP 1271 Okay, since this is a developer conference There's basically five things that you need to remember as a developer if you want to build for account abstraction The first one is that accounts are smart contract and so they need to be deployed Thankfully, this is something that wallet will take care of but you still need to think that there is an account behind every Every wallet the address of these account is computed like a smart contract So there's no link between the signer like on Ethereum. It's it's a new address for a smart contract being deployed Transactions can have multiple signature So we need to think that you cannot assume that for an account as only one signer Maybe it's a native multi-seq. So you shouldn't make any assumption and signatures can basically be an array and Then if you want to verify off-chain signature You cannot use a local easy recover that you've been used to you need to actually ping the account and say is this signature valid and Finally you can and you should use multi-codes because it improves the user experience by a 10x factor at least And that's basically all you need to remember So if you are the developer if you come out of this talk by remember remembering this five point I think we are in good position. Okay So as I said, we've been you know working with stark net on the defining account abstraction there And of course we built a wallet because that urgent. That's what we do. And so we actually built the first Wallet with native account abstraction co-argin X. I promise you this is the only slide where I will chill Argent But it's still needed since I'm on main stage So our genetics first wallet on stark net native account abstraction, which is quite of amazing Works as a browser extension. So it works on chrome and firefox. You can have multiple accounts It works on stark net test net and stark net main net and it does the usual of a wall of a wallet You can send and receive token. You can interact with dApps But as I will show it does much more than that also and it's 100% open source So if you are interested, please check the repo feel free to contribute And if you haven't tried the wallet do so as well And it's been actually an amazing ride. You may not know All the stagnant ecosystem is going but actually since we started our gen X in January We've had more than 250k downloads So that I think that's quite of impressive and we are securing more than 90% of the funds on stark net main net today so others are Gen X work so Typically when you think of a wallet for example like metamask you think about the client and you think about a key that Can sign transactions well with account abstraction you need to think about the account contract as well So our gen X is really these three things a client front-end keys that can sign transactions And then account contracts that live on chain And it works from a user or dApp developers point of view It works exactly like like you would expect from your metamask for example When you connect your wallet and you do an action the wallet will pop up you can review the action Approve the extension will use a key to sign the authorization All this is sent to the account contract on chain Which will validate and then execute the operation and call the target contract Okay, so now let's Get to the interesting part the unique features that are enabled by account abstraction So I mentioned that on stark net we have native multi-call the idea of a multi-call is that you can actually Make a sequence of operation at as one atomic transaction Think for example of the infamous ERC 20 approve and call right on Ethereum if you want to interact with the dApp that requires a token You need to first make a first transaction to approve your token Wait for that transaction to be mined then you can actually make your call Well with multi-call because your account is a smart contract He can orchestrate these different operation in sequence So you can actually in one transaction do your approve and your call or maybe you can do your approve and then five Calls and we're seeing on stark net DApp developers are experimenting with that for example if you if you go on aspect which is an NFT marketplace on stark net When you want to buy NFTs you can add them to your shopping cart Which is an experience that we all know and so you see all the NFTs that you want to buy you finish your session Then you go and you actually buy these NFTs in one transaction because your account will orchestrate the buying all of these NFTs so in terms of UX, it's an amazing improvement Another thing that we are doing on stark net that you can do because of account abstraction is social recovery The idea of social recovery in a nutshell is to get rid of seed phrases Or do you do that because your account is a smart contract? You can program it to support a second key and you can define that that key Cannot transfer token it cannot interact with that You can actually only do one thing which is to replace the signer key in case of a problem And you can imagine that now you give that recovery key to a party that you trust that we call a guardian think of it for example as a service and The day you lose your computer you lose access to your wallet Well instead of having to think about a seed phrase private key now You just contact your guardian this service you authenticate with whatever mean you've agreed with him and the service will Make the only transaction it can do on your account and reprogram your account with a new key and Of course you can use a service, but you can decide to be your own guardian You can use a ledger to do so for example, and we are working on ledger to enable exactly that So social recovery is really a way to get rid of seed phrase to provide the UX that users Normal users can understand and it's 100% non custodial because you as the owner of them The main key you can decide who's your guardian and you can change that guardian at any point if you want to So that's really cool. What what else can we do? Well, we can do fraud monitoring with 2FA Imagine that again now on your account your program is second key and you decide that that second key must cost Okay, so I was talking about the new cool feature the idea to do fraud monitoring with 2FA I think I was explaining that you can add a key to your account And that key must cosign every transaction So you turn your account into a two of two multi-sig and you can decide you can choose to give that key to a service Now imagine that every time you make a transaction With your RGNX wallet the call data So the raw call that will be executed on-chain can be sent to that service for analysis And that service based on some business rules that you may have decided, you know Maximum daily limit or you know trusted app and so on so it can use whatever logic you've decided to decide if the Transaction is secure. It's something that we know is legit or if it doesn't know if we if it knows the transaction It can cosign automatically transparent to the user, right? You've just made one approve automatically the transaction is sent But if for some reason the service detects that it's a call to a contract that it doesn't know For example, he may ask you to confirm who you are using a second factor Just to make sure that no one is abusing your account So suddenly you can bring fraud monitoring with 2FA on-chain thanks to account abstraction What else this one is something that I'm very excited about the idea of session keys And I think it's particularly relevant now for on-chain games. So if you've played an on-chain games You've I guess all been frustrated by the need to sign Transaction every time you make an action having your wallet pop up you approve and then you come back to the game So on-chain games today is basically going on and off of the game to approve transaction Well, the idea of session keys is to say no Imagine that your game the DAP the client generates a temporary key in your browser and ask you to approve that key But he asked you to approve that key with a set of constrained policies For example, the DAP will say I want to sign transaction But only for 25 minutes the duration of a session and I will only call This contract and that contract and this and that method That's the only thing that I want to do as a user you can approve So yes, that's one confirmation with your wallet to say yeah I want to start a session on that game under this condition and next when you start playing the game every time You click on a button you make a game action the DAP can send the transaction directly to your account And the transaction will be approved So you no longer need to sign you no longer need to confirm you can actually focus on playing the game But you know that your account and your tokens are secure Because the key you approve can only do a very constraint set of actions that you have approved that's something that Several games are actually now integrating into their logic on stock net So I do believe that that's a pattern that will come and that you really will enable the UX of of on-chain games Another things that we are Experimenting and it's a collaboration with cartridge and ledger is the idea to make the account much more modular So imagine that your account is kind of a base contract on top of which you can add plugins And each plug-ins can have a different logic to validate and execute transaction So you can imagine that there's a plug-in which contain the session keys that I just showed There's another plug-in that may work as a new way just a signer But then there's another plug-in which much stronger security that will use that will be a multi-seq or that will use social recovery as a User you can actually pick and choose the plugins that you want for your wallet and really design your wallet For the purpose the use case that you want to use it if a wallet for gaming where you know You will spend maximum $50 does may not need the same security Requirements as your the wallet you use for trading on DeFi for example And by making the account modular a user can really choose pick and choose the experience that that they want And finally one last feature that we are exploring is the ability to use the secure enclave of your phone Because your account can be programmed you can actually program it to verify signature on a different elliptic curve and for example you can Use it to verify signature on a curve That's approved by the NIST and that is implemented in the secure enclave of your phone and Suddenly you are turning every single smartphone into a hardware wallet and that's actually something that someone has done on stock net So he built an account that uses that logic to verify signature So you can really now turn Smartphone into hardware wallet the use cases that I showed you are the stuff that we are you know building and exploring our Urgent, but I believe that account abstraction opens a completely new design space for for user experience And so we're only scratching the surface of what can be done So I hope that I've convinced you that account abstraction is needed for the UX of the blockchain But I think more importantly to really scale the user experience of self custody And the thing is that if we don't do that and if we stick to the EO a model that we have today My bet is that the next wave of users they will turn to centralize solutions I mean most of us in this room We are using already a coin base or an FTX or you know finance account because yes, it's simpler So can we really expect the next wave of billion users to not do that? Of course, they will so we need to find a way to build a user experience that is on power with these centralize Exchanges so that we big self custody at the heart of every interaction on the blockchain and and I'm personally convinced that only Account abstraction can do that So let's make it up and then build that together. Thank you Julian thank you very much for this I also was looking at your twittering jokes actually wrote a what the fuck is account abstraction So that's super cool. If you want to read more about it. Yes. Yes If you want to know more there's a three part series called what the fuck is account abstraction You can find it on Twitter and also if you're interested We are actually having a panel on this main stage at 5 p.m. Today with Vitalik Dan Finlay from Metamask and then you have which has been pushing for a IP for 327 So if you want to know more, please stick around and come at 5 p.m. Perfect Julian Thank you very much co-founder of art and giving a round of applause again. Thank you Julian. Thank you very much