 Today, I have the pleasure of moderating a panel that is going to technically challenge me, so I'm just going to be really good at asking questions, hopefully. This is about account abstraction, which has been a part of Ethereum as a topic for a very long time. And now that we are post-merge, maybe we can actually redistribute some developer resources to building something that has always been talked about as something that is fundamentally crucial to the future of Ethereum. And every time I talk to somebody who's technically minded, they all say that we need account abstraction. It's not an option. We have to have it. So we're going to explore why everyone who's more technical to me are always like, yes, account abstraction, good. So we have Julian, Julian Nisa, the co-founder of Argent. He is here in the middle. There we go. And then on the far end, we have Yoav Weiss, the security researcher at the EF. And then in the middle here sitting next to Vitalik is Light Clients, aka Matt. He's on the guest team. And then there's also Vitalik. What's up, guys? Yo. Yeah. It's great to be here. So you guys can each introduce yourself better than I can. So Yoav, we'll start with you. I want to give a little bit of your background and your relationship with account abstraction and why you think it's so important. Well, I think, yeah, sorry. I think account abstraction is something that we must have, both for some technical reasons, such as obstructing signatures for a future quantum resistance. But more importantly, for usability. If you want to really go bankless, then you need to get to a usability where the user never sees a private key. User never sees a seed phrase so that my mother can use it. And if she loses access to it, she has a way to recover. And you need to have different security policies in the account, such as, for example, you wouldn't expect your bank account to be the same if you are a large corporation or an individual customer. Maybe you want to have some different spending policies. So all of these things become possible. Anything that a bank account can do for you and more can be done using account abstraction. I think this is a must for UX purposes. Certainly. And then going down the line, of course, we have Julian from Argent. Julian, can you explain a little bit about what Argent is for those who aren't familiar and how it relates to account abstraction? Sure. So Argent is a smart contract. We're a company. We've been building smart contract-based wallet since 2010. And basically, we started on a mission to actually solve exactly what our kind of abstraction is trying to solve, recognizing that the user experience of UA is basically never scale. And so, if we keep that paradigm, I think, we'll remain in the bubble that we are in, but we'll be unable to reach the next, you know, hundred million users or billion of users because the user experience of SELQ studies is too complicated. And so we started building Argent based on, you know, to try to fix that. And we did that at the application layer on Ethereum. So trying to build a smart contract-based wallet, enabling different security flows to actually fix the issues that you have mentioned. So, for example, we introduced social recovery, which is a way to get rid of seed phrase. We introduced some kind of fraud monitoring and so on. That has been a great experience. But of course, we built that at the application layer, meaning that smart contract wallet are second-class citizens because the entire ecosystem, it's still built around this paradigm of UA's. I mean, the developers, the tooling, everybody is thinking in terms of UA's, which means that there's some compatibility issues if you're a smart contract wallet. We would like to say that we've been second-class citizens. And so, of course, the goal of our kind of abstraction is to make smart contract-based wallet first-class citizens. And of course, that gets us very, very excited. Matt, I've got a special question for you, but also feel free to introduce yourself and tell us what you do at Geth. But also, could you, after you do that, explain why do we call it account abstraction? What are we abstracting? Why is the abstracting word here? Just to really get things at the very basement level. Sure. So I recently joined the Geth team, actually. So I'm kind of like looking for my home amongst the Geth team. I think that there's many different things that the Geth team has focuses on. And so I'm trying to find where my very specific focus will end up being. So before that, I was part of this team called Quilt. And we did a lot of research and development on future ideas in Ethereum. And the first place that I became involved with the account abstraction was back in the earlier days when we called the Beacon Chain ETH2. And we talked about the different phases of the ETH2 deployment. And so the Quilt team was working on phase 2 for ETH2 for a while. And we were trying to think about how to define execution environments in a way that you could abstractly define all of the execution semantics about the virtual machine that was executing on Ethereum. And of course, one of those things that you needed to define abstractly was the account logic. And so this is where we first started running into this problem that Vitalik had already talked about in the relation to the EVM earlier on in 2016 and so. And so I guess for me, the meaning of account abstraction is actually maybe not the perfect way of defining what account abstraction actually is. It's a term that has many meanings for many different people. And for me, whenever I understand account abstraction, I think of it more as validation abstraction. I think of it like, we're trying to abstract what it means to validate an account in Ethereum. And so today, if you want to validate a transaction in Ethereum, you're going to recover some address from a signature, look at that address in the state to determine if the nonce is OK for the transaction that's been sent and that the account has enough balance. And so that's one way of validating a transaction. But there's many different ways. You can have a multi-signature. You could use different cryptographic primitives to validate a transaction. And so when I think of account abstraction, that's what I first and foremost think about. But I also understand account abstraction is used more generally now to think about smart contract wallets. And how can we add more functionality to the protocol or give users a better user experience when they're interacting with the protocol? And so now I understand that there's many ways of thinking about it. Vitalik, every time you introduce yourself, you always come up with a new, funny, different way of doing it, depending on what era of Ethereum you are. So I'd love for you to introduce yourself and how you relate to Ethereum these days. And also, answer the question for you, why does everyone say that account abstraction is inevitable? Yeah, yeah. So hi, guys. I'm Vitalik. I'm a fashion influencer and travel blogger at the Ethereum Foundation. Yeah. So account abstraction has been a topic I've been really trying to push for almost since the beginning. Like you think even actually when Ethereum launched, the original vision I had been hoping for was to try to get people to use smart contract wallets by defaults, right? Because we wanted people's money to be secure. And we thought it would be really nice if people could just have the default type of account be a two of three multi-sig wallet, right? And that ended up not happening, I think, in part because the community was just so fed up by incessant delays on top of delays for the Ethereum 1.0 launch that at some point we just put our foot down and said, OK, no more features. Unfortunately, we have to just cut everything and launch something. But then since then, we've been trying very hard to come up with the right way to actually get to the point where smart contract wallets can be the default type of wallet that people can use and try to get all these benefits, like security for multi-sigs, social recovery, other types of cryptography, if only one quantum resistance. More recently, thanks to Yoav Andrew and the others, the topic of trying to get aggregation to be in there as well to try to save gas and save data. So basically trying to find the way to bring smart contract wallets in and make them actually be as convenient and have all of the properties. Assessorship resistance is another important property that externally owned accounts, so the default type of accounts that most people use now have today. And it turns out that there's actually quite a bunch of challenges and there have been a whole bunch of various efforts. There was like EIP, I think it was 86, and then 210, and then 2938, and then a kind of grab bag of different proposals. Separately the strand of enabling a kind of delegation, which is basically allowing people to pay for transactions on behalf of other people, which I think is part of the motivation of both 3074 and some other proposals. Basically there's been this really long strand of research of trying to optimize and figure out what is the cleanest and like what is the most sensible and secure design to get to, you know, what's actually satisfying these goals, and you know that's what we're trying to implement and roll out today. I wanted you to check my understanding on this because I actually had to do some homework to prepare for this panel, because this is technically challenging for me. After kind of figuring out, when people explain account abstraction, they were like, oh it enables you to do this, and then it unlocks this feature, and it lets us do that. But it kind of feels like we're feeling that elephant metaphor where somebody's feeling the tail, and it's like a snake, and somebody's feeling the leg, and it's like, oh, it's like a tree, without actually seeing the whole thing. So I wanted you to check this metaphor with me. An externally owned account. There's only two types of accounts on Ethereum. You have an externally owned account, which is probably what you use when you buy your NFTs. You have a private key, and it unlocks a wallet, and then there's a smart contract. And account abstraction is putting what we currently use, which is our ledger or our private keys that unlocks a specific wallet, and it makes that wallet a smart contract which is more programmable. My mental model for this is that an account abstraction is like putting a chip into a wallet. And what I mean by that is that we have like Bitcoin, which the meme is like Bitcoin is a calculator, Ethereum is a smartphone. And I kind of apply that to externally owned accounts and smart contract wallets or account extraction wallets, where externally owned accounts are like Bitcoin, they don't really do too much. And then externally, and then account extraction wallets are like Ethereum, where there's a chip in it. Is that metaphor land? Yeah, no, no, that's a really fine metaphor, I like it. Is there anything incomplete about that? And Matt, I want to throw this one to you, where you were talking about validation abstraction. Can you connect these two metaphors? How do those things relate? Right, so I think, you know, if you're thinking of the concept of like putting a chip into a wallet, there's like two important pieces that the wallet is doing. And the way that I think about it is that the chip is dealing with the validation logic. Like I mentioned when I spoke a minute ago, it's determining like, is this message and signature that's coming from account valid in the context of this account? You could also imagine the chip did other things. After you do the validation, you would have like the execution portion. And so a lot of times when we think about accounts abstraction as like a general concept, we also think it's doing a lot of other stuff now and so that chip is now determining like, I want to send a bunch of transactions from this account or I want to send a bunch of calls from this transaction or from this account all in one transaction or I want to recover using like some social recovery group that I've come up with. So that's like another part of the chip. Beautiful, beautiful. And I want to throw this one to Julian as somebody who's responsible for actually putting some smart contract wallets in people's hands. Thank you for your service. How do you think this is going to get rolled out? People generally, and we'll get into the topic as to why people think that everyone will have a smart contract wallet rather than externally undercount in the future. But what's your idea for how this gets rolled out into how do we replace private keys with externally under, with account extracted wallets? So that's a very good question. I think the way I see it is that I think, I mean Vitalik has been pushing for account abstraction for a long time and every single proposal has some, you know, enabled some of the features of account abstraction but none of them I think is the end game. And personally, for example, I like the last proposal 43.37, but the problem is that it's still, it's at the application layer. So we are not fixing what I think is the real problem is getting rid of OAs. And I understand that on Ethereum, there's so much at stake that such a drastic change will take time. I think people are recognizing that account abstraction is the future. I think it will happen. But on Ethereum, I think it will take time. What we've been pushing at Arjen is that I think now we are seeing the emergence of Layer 2s. And I think Layer 2s are an amazing opportunity to actually try to test some of these, you know, and try to fix some of these limitations of the EVM that we have on L1 because they're much less at stake. And then each Layer 2s, they may favor a different type of trade-off. So we can explore on different pattern and actually bring account abstraction at the Layer 2s right now. So this is what we are pushing and that will enable us to better understand, you know, the limitations, what we can do. And following that, I think then we'll have everything in hands to actually bring that to Layer 1 and push for account abstraction at really the protocol level on Layer 1. That's the way I see the roadmap of account abstraction on phoning. Beautiful. And Yoav, you're a security reacher at EF, so I want to tap into your security mind. Why are smart contract wallets more secure? Like what security benefits from a user perspective or whoever might else, whatever entity might also use a smart contract wallet? Why is it more secure than our current wallets? Well, there are many different ways in which it makes you more secure. First of all, is a key management. Users don't know how to manage keys, even expert users. And just, I think that five years from now, if we recall that we used to secure our assets by writing 12 words on a piece of paper, it will seem unreal to us. So I think, for example, being able to add devices to your wallet. So the wallet is no longer associated with some seed phrase. You never actually see it, but instead, you add your phone, you add your computer, then if you lose your phone, you remove it and add a new one using your computer. So this obviously improves the security because you don't need to manage keys. And then there are things like, for example, you could say that your wallet is, that you can have good usability and spend small amounts easily using your phone. But if you are doing something out of the ordinary, such as sending a very large amount, in that case, you have to go get your ledger or something. You have to add another signature. So it allows you to have security policies to protect yourself. And there are the security benefits of switching to a better signature scheme, which we're going to have to do in the future anyway. And since it's programmable, you can add any security mechanism you come up with. And different users will have different requirements. So having just a single security policy for accounts, which is what we have with EOAs, the security policy for an EOA is if you have the key, do anything. If you don't have the key, do nothing. This is not granular enough. So I think being able to have personalized security policies will make Ethereum overall more secure. And I think the way that I see account-obstracted wallets, smart contract wallets, there's this unique relationship with devices. And we all have a bajillion devices in our homes. Like when I sit at my computer, I have my computer in front of me, I got my phone, and then maybe there's an iPad. And there's three devices. Each with different levels of security assumptions around them, like my computer is at home. It doesn't go anywhere. My mobile phone can go anywhere in the world. But all of these things, can you talk about the relationship between a device and the wallet, and how that can relate to a different level of security of control of access, right? So maybe I only want to send $100 with my phone, but I can send all of my money with my computer. Can you talk about the relationship with a device and a smart contract wallet? Yes, this should definitely be a part of the security policy for your wallet. So yes, you could say that you can use your phone to do small things, but your computer for bigger things. I'm actually not sure. Sometimes your phone could actually be more secure because your computer may or may not have the capability of secure enclaves, but modern phones usually do. Now the problem is that at the moment, you couldn't use it with an EOA because it doesn't support the signatures that Ethereum uses. It doesn't support the same curve, but with account obstruction, it becomes possible and someone actually just built a nice demo of such wallet at the hackathon here in Bogota. So if you can associate the fingerprint of a specific device, and you can have a fingerprint on your device which is actually verified by a secure enclave on your phone, and then the signature happens inside it, so your phone actually gives you a pretty good security, but in any case, you have to evaluate that, for example, your phone is coming with you, your computer stays at home, so you have to evaluate that your unique situation and set up a policy where you decide which device can do what and maybe sometimes you need to use two of the devices, maybe sometimes you need to go also get your ledger from the safe. So it's up to you to decide how each device is going to be used in your wallet. I think the important thing to take note from here is that we're using devices to relate to a wallet differently rather than having a different wallet on every single device. And so, Julien, I wanna throw this one to you and now you guys are thinking this at Argent and check my understanding here. It's like, I've got a wallet here on my phone, I've got a wallet on my MetaMask on my computer, I've got a wallet on my ledger, there's three different wallets. But now we're talking about three different ways of interfacing with the same wallet, which is a different kind of just organizational structure. So do you think that we're just gonna be able to kill most of the wallets, all these throw away wallets that we use instead of having a little bit of cash in some wallet and a medium amount of cash in another wallet and then cold storage? It's actually gonna be the same wallet and we just have different levels of security of how to access these things. How are you designing Argent to work inside of this paradigm? I think the first thing for me and the beauty of account abstraction is that you can choose as a user. So I don't think there's one model that fits for anyone. There are users that may want to have different accounts for privacy reasons, for example. So I think there's not one model that fits all, but of course in terms of Argent, we like to see the Argent wallet, the main account if you want as your identity on chain. And so yes, having the ability to choose the security associated to the key that's in a different device is of course very, very important. And so at Argent, we are researching a lot of different ideas. For example, now we're exploring something called session keys, is the idea to have an ephemeral keys to which you can attach very strict policies. So you can literally say this key is valid for 24 hours and it can only call a certain metal and a certain contract. And so you can imagine, for example, if you consider that your phone is more secure because I agree with you, I think my phone is more secure than my laptop, but maybe I can actually have a key on my laptop that has restricted policies. And so that key, yes, can do certain action, but I define exactly the type of actions and the rules that are associated to that key. But to answer your question, for me it's really about giving the choice to users. And I think that's again, the beauty of account abstraction is that it opens a completely new design space for what an account can be. And I think we are only scratching the surface of what can be done at Argent. We see it as your identity, it's your core account. You may have multiple accounts with different rules. For example, it's a good example. If I'm playing an on-chain game, I may not want to play an on-chain game on which I'd save $50 in a certain token. I don't want to play that game with the same account on which I have all my savings, for example. So I think having the ability to have different account with different rules and different logic is actually what account abstraction brings. I think, I just wanted to add that for privacy reasons, you want to have multiple wallets because you don't want to dox yourself everywhere. It's still, the fact that we decouple the device and the keys from the wallets means that you can have all of them associated with a fingerprint on your same phone. So you choose which one you're using based on whatever privacy you want to have, but you still use the same device. You don't need a different device for each wallet. I want to turn this conversation to how we actually get account abstraction implemented at the layer one, because this is going to take an EIP. This is going to take a hard fork to get this into Ethereum. And I want to throw this one to Vitalik, our resident crypto philosopher here. Crypto loves tribes. We got the layer one tribes, we got the layer two tribes. Are there account abstraction tribes? And if there are, what do they fight over? I mean, I kind of feel like the tribe-ness of account abstraction is a bit overstated in that I don't really see many competing camps of approaches for, like, let's say, how to solve the problem of I have a smart contract wallet and I want to be able to send things from that smart contract wallet without needing some third party to wrap my transaction and pay 21,000 gas overhead or whatever, right? But the different camps, I think, are more kind of just groups of people that came into the space of improving accounts with different emphases, right? So, like, the emphasis that I came with is solving the problem of, like, how to make it easier for people to have smart contract wallets with arbitrary validation. Other people came in with the emphasis of solving the problem of how to let people pay for other people's accounts or how to let someone who has USDC only pay other fees in USDC instead of paying fees in ETH. So, and then there's also the problem of how to let an account do many operations in one transaction and though these are not really, they're not competing goals, right? I think they're goals that, like, everyone here agrees that we need a solution that covers all of them, right? And I think, you know, there's different ideas that are slowly kind of converging toward some architecture that actually does is getting better and better at actually fitting together. And in terms of, like, how to get from here to there, like, one of the differences between EIP 2938 and ERC 4337, right? Is that 4337 is an ERC, 2938 is an EIP. And 2938 is a kind of boil the ocean, let's change the protocol now and, like, let's, you know, set things right in the protocol sort of solution. 4337 is an extra protocol solution, right? And it's kind of analogous to sort of the roll-up centric roadmap in some way, right? Which is, you know, part of the motivation there is, like, the core developers are busy, you know, there's the merge and there's the surge and there's the splurge and the purge. And, you know, some people want to call a single slot finality of the George. But, you know, the, and then, you know, because 4337 is an ERC, we can kind of work on it separately, get it in, you know, have a small amount of usage, just start fairly quickly, get it into L2s and improve it from there over time. But I guess the one kind of big difference here is that I think over time, like, especially over the last year, there has been this realization that, like, we do want EIPs, like, as in things that hard work, change the Ethereum protocol eventually, because, like, we do want to upgrade existing EOAs, like, we want to let existing users that don't want to, you know, go through the expense of just completely moving everything from their current account to, like, we want to let them enjoy the benefits of the GNU system. And we might, you know, we want benefits, like, say, you know, since any censorship resistance guarantees that we get from inclusion lists, like, we want that to apply to account-obstracted operations. And, you know, if we want these different things to, like, happen, then that does require making protocol changes, right? But the good news is that kind of the ERC comes first and the EIPs come later and there's a lot of these kind of great proposals for how to do these EIPs. And, like, there is definitely a kind of a deep multi-year, multi-stage roadmap involved where, like, it starts off in kind of making it friendly for the EIP people that kind of wants to pioneer and, you know, really care about getting these properties early and then, you know, expanding more and more until finally, you know, EOAs may actually, like, you know, finally kind of go away and we really do just have smart contract while it's in all the benefits are available for everyone. So if I'm understanding correctly, like, the current state of account-obstraction development is that we haven't yet come to consensus as to what the EIP that we want to put into the Ethereum base layer is. Like, we know EIP 1559. We totally wanted that. I don't think there is an equivalent EIP for account-obstraction that we have. There is an ERC and it's to be clear, right? It's important to remember that, like, with just the ERC, we can already get to the point where, you know, if people want to, like, replace their entire activity and, like, run it off of account-obstracted wallets instead of regular ones, like, they can do it and it works reasonably well, right? But the EIP is for the second stage of the roadmap, indeed. Like, there are, like, we didn't, there's, we did not have those EIPs yet. They're under development. There's lots of different, there's lots of different ideas and it's still solidifying. If I can add to that, I think I was saying some of your tools are actually experimenting on that. For example, if you look at StarCnet and ZKC, they are launching with native account-obstraction, which is actually inspired by ERC 4337. So even if it's just an ERC for the Ethereum, it's actually inspiring Layer 2s that can actually try to implement the next step, which I think will come in the later EIP when we will change that at the protocol level on Layer 1. But I think it's interesting to realize that it's already there on certain Layer 2s. If you look at StarCnet, it's still in alpha, but actually it launched with native account-obstraction. So there's no more ERAs. It's actually trying to be the end goal. And I think that we learn a lot on the StarCnet ecosystem that we can then bring back to the next EIP that will put, hopefully, 4337 to the one layer down to the protocol level. If it's okay for me to just make a comment on this, I think that this idea of Layer 2s experimenting with future potential core changes to the Ethereum protocol is really interesting. And I think things like StarCnet is a very interesting place for it to happen, because it's very different than what the EVM actually looks like. And I think it's probably the right place for those things to happen. But I'm still hesitant about understanding how this is going to play out across all of the different Layer 2s. Because we've seen over the last 18 months, there's been a huge push for things like EVM equivalence and having something that's exactly like Ethereum and trying to bring things like 4337 into the protocol, I'm not sure how it's going to play out on those different types of systems. Yeah, that's a very good question. But I mean, we're discussing with some of the team, like Arbitrum Optimism, who want to have that EVM equivalence, but they all recognize that they'll also need to have account abstraction at some point. And so they want to capture the EVM ecosystem, but at the same time they would want to have account abstraction. And so that conversation is on right now. And hopefully we can find a path to make that happen on these Layer 2s that want to be as close as possible to the EVM equivalence. You have ZKCV2, for example, that wants to be EVM equivalent, but also wants to have account abstraction. So I think even if you're going for the EVM equivalence, I think it's good to try to modify the EVM a little bit so that you can still capture that compatibility and the fact that you have a common standard with different Layer 2s, but still try to fix some of these issues if you can. So I think this conversation is on right now. There's no clear path yet, for sure. But I do think it will probably happen on Layer 2s before it will happen on Layer 1s. One way to look at how much equivalence you need is from the point of view of the user. So I have my Ethereum wallet like 0xDA, DA, blah, blah, blah. And one of the nice things that the EOAs offer is that one with just the same wallet, the same code, the same key scheme, the same everything, I can just switch to Optimism and with the same transaction on Optimism, switch to Arbitrum, send transaction on Arbitrum, and so forth. The other benefit is that I get the exact same address. You can go and send things to 0xDA, DA, blah, blah on Optimism and I'm gonna have them, right? Or you could send things to 0xDA, DA, blah, blah on Arbitrum and I'm gonna have them, right? And EAP4337, it does try hard to make that possible. It definitely makes it possible to use the same code and have the same type of contract wallet on all of these rollups. And because the Singleton is created with Create2, the Singleton's gonna have the same address on all the rollups and so you're gonna be able to, like anything derived from the Singleton, including people's individual wallets, are also going to kind of have the same addresses, right? So like one thing that people, ZK, StarkNet and similar systems could do is like try to achieve kind of like that code and address equivalence. So for example, even while experimenting, was trying to like make the way they handle operations much cleaner and different. And just to, I wanna go back to what Matt was saying and just to really drive this point home about how Layer2s are gonna be like the testing bed for account abstraction. Matt, can you just kind of walk us through into the future about how you think this may play out? Like ZK Sync does some sort of flavor of account abstraction, StarkNet does a different one, the market decides what they like, we sort of come to consensus as to what features should be pushed down to the Layer1. How is this gonna work out in the future? I mean, honestly, I'm just really curious to see how it plays out in the future. I think, my perspective is I'm very worried about fragmentation of different approaches. And I think if we think about maybe on the longer time scales, 10 years maybe, eventually we'll come to some solution that's great and everybody will do it just because all of the other, all of the other companies will have run out of money and left the ecosystem. But I think I'm very worried about the shorter term, like three to five years. How are we going to be able to bring millions of people into this ecosystem and have like really good experiences using applications if every single protocol has a different way of doing account abstraction? I can't imagine trying to support like 10 different ways of doing account abstraction in Ether's JS or Web3 JS. And so that's kind of like my perspective is like, how can we do this in a way that we avoid the fragmentation and that's why my perspective is that we should really consider using the EVM on the Ethereum mainnet as the shelling point for coordination amongst all of these different protocols. Is there going to become a moment where at some point this turns from like, oh, we'll talk about account abstraction and we'll ideate on it to like, oh, we need to pull the fire alarm and ship this thing. Is there like a fire alarm event potential in the future where like we need to get this done? It's starting to ship already. Yeah, I think, I mean, we've had no safe for a long time as well. So the Spark contract wallets have existed. We want to like improve the experience of using them. And I wanted to say like early, like I think it's really cool understanding all the different security perspectives of account abstraction and the different policies of different devices. But the way that I think about it a lot more is how can we improve the user experience of using Ethereum? And that's something that I think like we're still really lagging behind. And to me, the reason that we're lagging behind is because there is fragmentation across different wallets, different protocols. From my point of view, I do see some kind of urgency because I and for me to relate to self-custody, I think self-custody today because of your is is really hard. We all know that. And because of that, a lot of people are actually turning to centralized solution. I mean, if we ask the audience, most of us here, we have a Binance or an FTX or a Coinbase account, even though we are the builders and the early adopters. So my fear is that if we don't find a way to have a good user experience for self-custody, then my fear is that the next wave of users may turn more and more to centralized solution. And then we'll fail as an ecosystem. And in my opinion, our kind of traction is actually the only way to enable this user experience that can be a self-custody, but still make it simple for user. So I do feel a certain sense of urgency. That's a good point. And I feel like for me, the urgency is like, how do we make smart contract walls the default everywhere? Because defaults are sticky. And so if I go to Menta NFT on OpenC and I create a MetaMask following some tutorial, that's the default that I'm stuck with for a long time. It's very hard for me to migrate to the smart contract world. And so figuring out how to make that the first thing that people see whenever they come onto all of the different protocols is very important. I fully agree. OK, so to my knowledge, the current state of DeFi is unfriendly to account infrastructure in smart contract wallets. Can one of you guys explain why that's the case? Why is that the case and how do we fix it? So I wouldn't say that DeFi in general is unfriendly. There are some dapps that make it difficult. For example, they assume that you can sign directly with the address. And contracts cannot sign. Contracts do not have a private key. So if you need to log in, for example, to OpenC, by using, if you need to log in, by signing a message with your address, then you're unable to log in. And we have an ERC to solve that, a very old one actually, 1271, which defines how a contract can validate, that I can say is signature valid. So some dapps support it, some don't, and assume an EOA. We need developers to stop doing this sort of thing and assume that some of the addresses are actually contracts. That's the minimum requirement in order to make it the first class citizen. So I want to run through some potential use cases just to make things really concrete in the imagination of the people in the audience here and the listeners. So I want each of you to think of the most powerful use case that account abstraction unlocks and how that onboards new people, new utility into Ethereum. You each get one, and whoever is going to go first is going to have the opportunity to have the best one. You all are going to give it to you. What's the best use case that account abstraction unlocks? Well, you know, there are millions of use cases, some of them quite exotic. I'm tempted to talk about them, but instead I just repeat that being able to obstruct the signature and to have authentication and authorization obstructed and let the user control it, that's the single most important thing, in my opinion. I think just to make the concept of abstraction more concrete for people, one of the big use cases is multi-seg wallets and social recovery wallets. So multi-seg wallets, pretty simple. You have n keys, and you need some n over 2 or some number of them. For example, you have six keys, and you need four of them in order to sign a transaction. Most of my money is in a 4 of 6, I know it's as safe. It's public info, it's on ether scan. But then the social recovery wallet is a wallet where you can sign things with instant transactions with one key. But if you lose your key, then there is some other mechanism, which itself probably could be a multi-seg. So one thing you could do is choose five friends and three and three of them can make it up. And that mechanism can change the key of your account if you lose it, right? So the philosophy there is in practice, people's accounts getting lost, it happens much more often. It's a bigger problem than accounts getting stolen. And so you can solve that problem without sacrificing any convenience. And that makes sense for a lot of smaller and medium value use cases, right? So the challenge, though, is that if you want the benefits of either the security, the protection against theft and the really hardcore security of multi-seg wallets or the easier recovery of social recovery wallets, you have to put your funds into a smart contract wallet, right? And smart contracts exist, and you can do this today, but the problem is that if you want to actually send a transaction, then you have to also have money in an EOA, and the EOA has to pay gas, or you have to work through an intermediary, then you have to rely on that intermediary, and then what if that intermediary starts censoring and that, or even just disappears or whatever. And you end up wasting gas, and there's just a lot of extra complexity involved, which is basically what we're trying to get rid of here, right? So I think multi-segs and social recoveries are one easy use case of abstraction, but then another one is being quantum proof, right? Like when quantum computers come, we all have to get out of ECDSA entirely. And- Is there a timeline on that? Unknown. It's unknown, but what's great about our current process, even with the ELC, is that we can start moving away from it. We don't have to do it one day. We can start moving gradually, and over time, you'll see less and less wallets relying on ECDSA. So we can start moving there. It's not a one-day thing. Matt, any utilities that Vitalik and Yoav didn't mention that come to mind about account abstraction? Batch transactions. Why is that such a big deal? Why do we need that? Have you ever used the blockchain? A few times, I've been known. Yeah, can you give us a user story about how this is a UX improvement? As a good core developer, I don't use the blockchain very often, but when I do use the blockchain, I have to sign so many messages to send anything. I have to prove my tokens to go to a contract. I have to send them, then I have to prove more tokens to go to a different contract, all for the same application. And to me, it's like we could be making this all a single message to go on chain. So you're saying that account abstraction allows us to produce the UX that people kind of expect there to be in the long-term that we don't have today, more or less. I don't think it's just account abstraction. I think that we could be living in this world today. What I would really like to see is some sort of mechanism for dApps to let the wallet know that I would like to send a batch of operations, and the wallet can determine whether or not it has the capability of sending those in an atomic batch. And so I would imagine that you go to Uniswap and you need to approve and then do a swap. Rather than having that pop up as two dialogues, if you have MetaMask, it could show and say, I want you to sign two different transactions to do these two things, to complete the operation that you would want. And MetaMask would send off those two transactions and verify that they both happened. If you have a notice say for an Arjen wallet, it would get that message and would say, I want you to do two operations, but you have the ability to send them all in one transaction. So now you just sign one transaction and send that off. That's something that we could just have today that I think we're totally missing. And actually a good example of that in practice is on the stagnate ecosystem. There's like NFT marketplace. And there they've introduced the concept of a shopping cart. So when you go, you can actually do your shopping in a sense, you want to buy that NFT, that one, that one, and you will pay different token. And at the end of your session, you go to your shopping cart and you say, buy these items now. And your smart contract will orchestrate all these operations. So it will do all the approve on the AC20 token that are needed and then purchase all these NFTs. So exactly, I think the multi-code is a great example. Social recovery is another great example. So I come last. But I still think something that I find very interesting is the idea of front monitoring. Because I think the problem with the blockchain is that, I mean, we make users or there are bad actors and it's sometimes very complicated to know exactly what you are doing as a transaction. Typically you'll see some, you know, some cold data or something that is very obscure. And it's very complicated for us as a human to actually know the actions that we are making. And with a smart contract or account abstraction, you can imagine, for example, that you program a second key on your account that must cosine every transaction. So you turn your account in the two of two multi-seq. But then you can choose to give that key to a service that may monitor the operation that you are about to do. And so that service, if it detects that the cold data is legit, it's something that, you know, is secure. It can cosine automatically. It's transparent to the user. But now you're making a large transfer to an address that you've never interacted with. Maybe it can just ask you to confirm who you are with a second factor like email and SMS or Google or something. So using account abstraction, we can actually bring the flows that user, normal user are expecting, you know, bring the best of Web 2 or the banking world, but actually reproduce that purely on chain. So I think, yeah, for me, it's really multicoll social recovery and fraud monitoring are three ways that we can greatly improve the user experience for users. One thing I'm still uncertain of is how we want everyone to have a smart contract wall. We assume that everyone will eventually have a smart contract wall as everyone that's in this room and also all future users of Ethereum. How does that actually happen? As in, who are the service providers? We have somebody like Argent who's producing a smart contract wallet. But what are the other categories of how smart contract wallets get into the hands of users? Like I could imagine, for example, like I'm logging into some Web 3 game and I need to use a wallet for that. Where does that wallet come from? Who provides that wallet? And maybe that's what knows it safe is, but maybe not like what are the categories of who's providing all of these wallets to us, all the users. Like are there different categories out there? I think my philosophy on this is that like one of the really strong ideas here is that we want to be as a kind of active intermediary minimized as possible, right? To the point of like basically, you know, in an ideal world not requiring any active intermediaries that don't already exist in EOA land, right? So there are kind of acts once in that intermediary is what that could do their thing and then disappear, which are smart contract wallet authors, wallet developers and people like that. But we don't want to depend on active, a kind of relaying actors of some kind, for example, right? Which is the status quo is that you do need to talk to a specific relaying actor if you don't have your own EOA and you want to use a transaction through a smart contract wallet, right? And I think, you know, censorship resistance is a good reason to minimize active intermediaries just kind of simplicity, but it's like it takes a while to get there, right? So ERC-4337, it works through an MEV ecosystem, so it kind of acts, makes it relies on builders to act as intermediaries and then, you know, the goal of the various kind of longer term EIP is to kind of constricts that more and sort of protocolize that more and more over time. So we are, okay, five minutes. We're gonna try and find some time for questions, so if you have questions, start thinking of them now. But as we wrap this up, I want to do some call to actions. And there's various different stakeholders in the world of account abstraction. We got core devs, application devs, layer two teams and users. Each of these people have their own sort of responsibility for getting account abstraction out into the world. So let's start with the core devs. What do the core devs need to do to get account abstraction done? What do they need to pay attention to? Vitalik, I'll throw that one to you. L1 core devs, I would say not much yet. L2 core devs I think are important for them to be kind of on the ball earlier because I think there's a lot of reasons why L2s are a very natural kind of testing ground for account abstraction. I mean, first, because there's just lower fees on L2s and lower fees especially for computation. So the overhead of account abstraction matters less. They can iterate and they can develop and build a lot of things more quickly. Also, one thing we didn't touch on in this panel yet is that ERC4337 has this aggregation feature in it, which allows basically different signatures of different transactions to get aggregated together into one. It's the same sort of stuff as the aggregation technology that powers the Ethereum and Beacon chain and that allows so many validators to make their attestations and for those attestations to be kind of packaged together into one little thing that can be verified very quickly. And that's super important on L2s, right? Because on L2s, computation is, data is even more expensive than computation and aggregation like really saves on data, right? So for those reasons that L2s are an even more natural kind of first use case for abstraction than L1s. And there's a lot that L2s can do, right? Like L2s, they run sequencers and they're in the process of figuring out how to decentralize those sequencers and as part of those processes making their L2s support account abstraction or account abstracted transactions and accounts natively is something that's really important, right? So, and then in the longer term, once the L1 EIP is started coming in, then Minocore developers need to start paying more and more attention to it. Matt, what's your big call to action to the world? What do we need to do to move the needle forward on this one? There's two things I would really like to see. My colleague Sam Wilson has started a bi-monthly call called All Wallet Devs. I think that if wall developers are not aware of it, it's an awesome thing to see what the current discussions around improving wallets are and account abstraction is obviously one of them. And I think the second thing is something that we can be doing today to improve the user experience of DAPPS, is this is like creating a new interface for DAP developers to define that they're trying to do a batch of operations together and then allowing the wallet on the back end to decide whether to send that as an individual transaction or as multiple transactions. I think if we do that, then we start to show the core developers that we're really serious about batch transactions and smart contract wallets. And I think that that will really improve their feelings about changing the protocol to support that type of technology. Julian, what's your big call to action? Yeah, I agree with that. I was going to say, I think DAP developers, as well of course Leo too, I've mentioned that and Vitalik mentioned that. But I think DAP developers today could start to embrace patterns like EIP 1271 just to verify off-chain signature. I think just making sure that your DAP today is compatible with smart contract wallet. And as you mentioned, we can extend that to Miltico, but I think that would give already a good sign. And that also means that if ERC4337 picks up and people build more and more wallet on top of that, they will become more and more first class citizen, even on L1. I think they've never reached the point of having full first class citizen, but making sure every single DAP is compatible with smart contract wallet, I think we'll make it easier to go on that journey towards full account abstraction. Yoav, take us home. And also Yoav is the person that actually helped educate me a lot for this panel because I was definitely not prepared more than a week ago. So Yoav, thank you for your help. What's the big call to action that you have to how we get account abstraction into the hands of everyone? Yeah, so the first thing is what everybody here already said, that DAPs need to be compatible with it and not get in the way by requiring signatures. And they can start thinking about ways, of course, batching as Matt already explained, but even beyond batching, start thinking about ways in which a contract wallet could improve the UX of your application and work with the wallet developers in places like old wallet dev, the Discord, start working with the wallet developers to add the features that become possible with this. And for wallet developers to start thinking about interesting ways to use this to improve the life of your users, such as using gas abstraction models, maybe allow users who do non-financial stuff to pay with a credit card and not buy crypto at all. And there are many things that the wallet could be doing using account abstraction to make the user's life easier. So start thinking about that. And there's a, so I posted a presentation with many cool use cases that you could build using it. So I could, so I think going through this list and seeing what could help your wallet become better may be interesting. And I think just again, to really just drive this point home, Ethereum is a technology that is working on expressing itself. Starting in 2015, it was limited and now we have proof of stake, now we have layer twos. We have Ethereum can express itself a little bit better. But it's not gonna be done expressing itself until wallets themselves are expressive as the turing complete nature of Ethereum itself. And so we will actually not see a complete Ethereum until we all have smart contract wallets. And that is how I will finish this panel. Panelists, thank you so much for helping me explore this world. I assumed that we actually did not have time for questions, but apparently we do. So I'm gonna let somebody else steward that. Hey, thanks. I'm just wondering when is Origin planning to become ERC4337 compliant? I guess that's a question for me. So for the moment, that's something that we're exploring, that we want to research, but our focus is really on, I would say on native account abstraction on layer twos and that's why we're building on StarkNet and ZKC. And I think we kind of have our hands full with that already, still discussing with other layer twos to see if we can convince them to move forward with that as well. So for the moment, we are exploring with 4337. But again, just to highlight that on StarkNet and ZKC, it's actually heavily inspired by 4337. So it's actually what we are already supporting but on this chain. So at the moment, no plans, but that's for sure something that we are discussing internally and researching. Yoav, this question is for you. I tried reading ERC4337 the other day and could you explain a bit why it's such a hard read? First of all, because we're not very good writers, I guess, but we could have written it in a clearer way and maybe even split it to more than one ERC. But the other reason is that it really is complicated. So it really is complicated because we paid a lot of attention to keep things decentralized by having a mem pool and keeping the mem pool protected. So to prevent a DOS attacks that would bring the system may on his knees. So yeah, this made a difficult read, I understand that. Hi everyone, I work at Diagon and we're working on bringing subscriptions on Ethereum. We're currently using meta transactions. Do you think meta transactions will be less relevant when account abstractions will go live? So the issue with meta transactions is one, you need some kind of mechanism to figure out who's going to pay on your behalf and connect you to the person paying on your behalf. And if this depends on specific actors, then that becomes a censorship vector and they might disappear in all of these things. And also a meta transaction requires like this extra gas cost of 21,000 per transaction on top of a smart contract overhead. So I think it's important to remember that ERC-4337, it is similar to meta transactions in a lot of ways and it uses very similar ideas, but it does add this open mem pool to solve to remove dependence on specific actors and it adds this kind of like batching up problem to like basically cut the 21,000 overhead to one per block. So I view it as a kind of iteration on the same idea. If I can just add on that, I think with native account abstraction there's no more meta transaction because the account can pay transaction fee by itself. So the day if we bring 4337 to the protocol level there's no more meta transaction because you just sign with the keys, you send your transaction and then the account will automatically validate. And if it validates the transaction we'll pay the fee directly to the miners. So if you go to full account abstraction there's no more need to have meta transaction and with ERC. Hey everybody. Yeah, firstly thanks David. I'm a big fan of Bankless. These are great conversations and Vitalik, I'm a fan of Ethereum so thank you for that. Also a fan of Ethereum. Somebody mentioned that like more wallets are lost than are stolen. So I kind of want to zoom in on like the social recovery aspect. I think if we're gonna onboard the next wave of users we can't expect them to have crypto friends or hardware wallets already, right? So I know that Argent has some functionality where you can kind of back up a share of your key to Google Drive. I'm from Ultimate, Adopt Money. We do something similar with Apple iCloud accounts because we've read that 95% are 2FA encrypted. So like do we as a community kind of accept that we're gonna stand on one leg of like either Google Drive or Apple iCloud for trying to onboard people that are really like new to crypto? Is that something we accept? Yeah, so I think once you have recovery built into the wallet you could use different mechanisms. First of all, if you don't have crypto friends and you don't mind some centralization you could have for example, you could have a service like a professional guardian, someone who can verify your identity and then recover your wallet. And you could use a centralized solutions like Google Drive or Apple. That's also fine. But if you had to use this within EOA it means that Google has control over your account and maybe they lock you out of it at some point. But since you can have as many keys as you want for the recovery you can actually have, you can use a centralized way for login like log in with Google or anything of this sort. And then and still keep a more complex recovery mechanism for the case where they decide to send you for example. So you can benefit from both worlds here. Oh, my question was for Julian. Yeah, so the way we see social recovery is kind of, in a sense it's a protocol. So every user will want to use different mechanism to get back access to the wallet. So yeah, we don't expect people to have crypto friends and to rely on your friends. But maybe if you're a more crypto expert you may just want to use a hardware wallet that you control. And you can put that in a safe in a bank and if something bad happens you can use that hardware wallet. So that's one option. You can actually give that key to a centralized service that you trust but the day you don't trust it you can just remove it or you can actually combine. So you can use a centralized service and a hardware wallet. I think it really depends on the user. If you have $50 it's probably okay to give that recovery key to ask a centralized service that you trust to act as your guardian. But of course if you have millions that may not be acceptable. So you may want to use two, three hardware wallets that you put in different states. So the way we see is that recovery is really a protocol and depending on users we can build on top of that the user experience that they need depending on the use case and where they are in their crypto journey. Hi, my question is for Julian about the fraud detection option for the urgent wallet. And my question is, does it apply to MVV type of tax like bot sweeps for example where if a user has engaged with a phishing attempt and then every transaction after that goes to a multiplicity of different wallets with that feature be able to detect things on the MVV level in the pool and in the pool? That's honestly a very good question and something we haven't really thought about. So just to make sure I understand your question you're saying if we enable this co-signer for example can this co-signer anticipate some kind of MVV extraction? I guess the answer is probably yes but to be honest we haven't researched that. So that's a good question. I don't see why not because based on the type of transaction you can probably assume that some MVV will happen but yeah that's an interesting point of view and something interesting to research. I don't know if someone else is actually a smarter answer than mine to that question. Feel free to shoot. Really quick one about MPC wallets. So the use cases that you described the main ones with multi-sigs, social recovery can be solved in a bit of a hacky way with MPC EOAs like the one that I think Coinbase wallet is working on. Is that good or bad? And if it's bad what do we do about it? So one specific thing that the MPC approach can't solve is key changes so they can't really solve social recovery well. And the reason is that even if you take your key and you split it into five secret shares and you give each share to one of your friends the problem is that if your friends get hacked even five years later there's basically no time limit you have no way to revoke. Once enough of them get hacked they'll be able to take control of your key and your account, right? So that's one very big problem. And then another problem is that just from a UX perspective that kind of approach would require the users who participate in like basically it will require your recovery partners to have custom software. And account abstraction done with smart contracts is like cleaner because it doesn't require custom software, right? Like to add a bunch of recovery partners you just like put in what their addresses are. And so like whether they don't need to like hold some separate thing and then make sure that some separate thing is kept safe and like accidentally lose it because the only thing they ever use it for is helping you recover your accounts and they just forget. This is something that once you know literally happened to even me each one I was using the HTC wallet that was using MPC recovery by the way, right? Like I even you know I almost lost it because a couple of my recovery friends just like upgraded their phones and you know forgot to upgrade forgot to carry over the recovery app. So like those are the two problems that you know at least I think the smart contract based approach just always better. And then also just like theoretical cleanness, right? Like ECDSA is just a fundamentally bad algorithm. The only reason it has any prominence at all in this world is because of stupid stuff involving a Schnur patent. And you know as ECDSA it was invented to just get basically get around the patents and that patent has expired years ago and there's an ECDSA has a lot of like bad mathematical quirks to it to make it much harder than needed to MPC and you know much more complicated than needed and like we really should be upgrading to Schnur or other things anyway. So you know just from that kind of theoretical I mean you know trying to kind of make the ecosystem a cleaner over time perspective I think a smart contract approach is better. So like for solving dealing with people's needs now you know it's definitely valuable in some cases but I do think there's value in and like there are serious value ads that a smart contract based approach and adds on top. Yeah and in order to add that an MPC aims to solve maybe recovery or managing the keys but it doesn't give you things like adding policies I mean it helps you with the authentication of the account but nothing else and there are actually MPC there are some MPC wallets that use that run a policy on a centralized server so you have a server participating in the MPC and the server will make sure that you don't do certain things but this means that the policy management is done off chain in a centralized way and I think being able to enforce a policy on chain is a powerful thing that MPC cannot achieve. Hey real quick question. I've been informed that that's actually all the time that we have so we have to sadly... Can I just ask two seconds? Just real quick. Just wanted to ask... I'm not the one writing rules, I don't know. One more, all right cool, we're good. We can appreciate that, that's love. I'm Russ from 40 Acres now. We're trying to create self-sustaining communities of color utilizing blockchain and obviously there's a lot of big brains in the building right now but for the people that have no idea what you're talking about I'm super curious there was a wallet out and you could aggregate you could use DeFi, NFT marketplaces. I'm curious, is there space for things and products like this in the Ethereum space and how do we kind of aggregate that information for people who don't even know what a smart contract is? Of course, so basically there was a wallet out right and you could put, there was DeFi protocols in it, there was NFT marketplaces all in one stop shop and so I'm curious, are there other products or anything like this being built again to help those who have no idea what smart contracts are those who just need this information the most? Yeah, I think smart contract wallets are how we get to a point where we have just intuitive UX and so you can just like there's something called like the grandma test where if you can give your grandma the thing and she can do it then it passes the UX test and smart contract wallets are how we get there and so just like things, to make things intuitive to get rid of the whole signing with a private key and making wallets behave in the way that we expect them to just as humans, smart contracts wallets are how we get there and so I'd say that smart contracts wallets are kind of how Ethereum kind of fits into every single corner of the internet and it's because we find ways to hook Ethereum into some sort of web three app game NFT marketplace and it doesn't feel like Ethereum, it just feels like the internet and smart contract wallets are definitely how we get there. I hope that answered your question. Cool, thanks guys.