 Okay, thank you. My name is Drotirosh. We work on the OpenJSN gas station network, but recently we're working with Jove Weiss, which was supposed to pass this presentation, but he's sick in the hotel, so we are covering him up. We'll talk about account obstruction and what can be done with it. First of all, what is account obstruction? But before we talk about what is account obstruction, what is an account? Account comes in two flavors. One of them is externally on account, that we all know, and the other are contract-based accounts. And if you have a wallet, you're probably using an EOI account. EOI accounts are very easy to start to work with, but they have quite a few limitations. First of all, key management is very, very problematic. The private key is tightly coupled with the address, which means you can't change it. You have to keep it secret because if you lose it, you lose everything, but if you make copies in order not to lose it, someone can find it, and then he will get everything and you will lose everything. So key management is hard. There's also one, one fits all access control. You can do everything. It might be good for you, for personal usage that you can do everything, but it is very, very limiting if, you know, all these operations, by abstracting away, we mean it is not the node that performed operation that checks the signature, that checks the security of the node, checks the balance, perform the payment, but we abstract it away and make a contract. The wallet contract being responsible for all of these. So the key management becomes simpler because the wallet can do a key management by itself. Access control mechanism, if we want, the gas payment he does, a lot of things become easier, but just the easiest way to think about this is making contracts, wallet contracts, first class citizens. They are no longer second class citizens of Ethereum and that you don't need an EOA in order to operate your contract wallet. You can start from a contract wallet and you'll never need to have an EOA. Okay. From now, when we're talking about the contract, now we're talking what can be done with it. Now with the next slide, with all the features, none of them are implemented by us. They are about to be implemented by you. We only open the door with accounts in order to be able to add all these cool features. So the first use case is recovery. Right now the recovery sucks. You can't recover. Private key can't really recover. You have to save this private key somewhere as multiple funny words or otherwise. With account obstruction, you can implement into your wallet social recovery or other recovery mechanism. You can add a dead man switch, like if I'm unfortunately someone is about died and you don't want to lose all the assets he has, it can set a dead man switch that is after a period of time, that he's not using the account, someone else will inherit this account. Like a multi-seg that your family controls. But it only becomes active a year after your key is not active. Yes, we're talking about recovery. But multi-seg, of course, when you're talking about signature cases, multi-seg is something that we see we want to have for accounts. Another option is private device keys. You might want your phone. Your phone is a very strong hardware to protect keys. So it might be very easy that, you know, the protection of your phone, whether it's fingerprint or whatever, or other biometric check, this is the way to control your account. And if you lose this device, yes, we have recovery. I will sign another device as my wallet signer. These are private device keys. Other signature scheme you can use, BLS signature has a very cool feature which can be compressed very nicely and which reduce gas on L2 networks. So it's an extension that can be added on top of account obstruction on those networks to reduce the gas fees. And if you are looking into the future, we know that ECDSA signatures sometime in the future will become weaker, that is, the attack will become stronger. And with the quantum machines, eventually within 5, 10, or 20 years, they will be able to be cracked. We want to be able to upgrade our accounts, at least our important ones before them. So quantum resistant signatures might be away. And again, each of those cool features we are talking is not a systematic change of all accounts. Is a specific account, want to experiment or want to add a feature, okay, upgrade your accounts and now you have those features, like any of those on the slides around. Sorry, did I miss anyone? Okay, now we're talking about some roles you have. Right now, as I said, with EOAs you have a signature and you can do everything. When you use smart account, you can put roles, you can allow different roles to do different things. Maybe on your home, on your personal account, you want to do the master to do it all. But if it's a corporate account, you might say that you want the legal department to be able to vote but not move tokens, you want an auditor to be able to cancel pending events but not generate events, is set to a, I don't know, set to a payroll system to be able to submit to known addresses. Again, the sky's the limit to what you can do and it is still, you can add it to this account. Wait, maybe a little bit about session keys? Ah, sorry. Okay, we talked about the high end of accounts, that is, accounts, corporate account. There is also the lower end. You know, you have your personal account but you also want to play games. With games, even the single accept per request might be annoying. You don't want to accept each operation. So, for games you might assign your account a session key. This key is allowed to make transaction for specific targets, specific game. And now, you are wallet free, you free the UX from accepting each transaction and you know it is limited. It's only this game. So, it can be your own wallet but you didn't sacrifice for this game your entire security. Yes, okay, we talked about the security, about the roll access. Now let's talk about the gas, gas abstraction. With normal accounts, the account has to have ETH in order to pay for a transaction. With account abstraction, we want to abstract away the gas. We want to be able for a third party to pay for a transaction, which is very, very good for onboarding. Like, a DAP want to pay for transaction for its deployment of its client or client that use its own account. If you have a token, it might be useful to use your own token. So the user will be able to pay with your DAPs token for transactions. And for traders, if a trader want to trade on Uniswap with a die, why should he have ETH to pay for gas? He has died. Why not pay with that? So paying with token is a cool use case that we really want to have in the system. Privacy, if you think about it, if you go and you want to protect privacy and use a mixer, like Tornado Cash or other, and yes, you put the money in. Now you want to get the money out. But you have to have gas in order to withdraw this amount. How did you get that gas from some KYC account? So you're not really anonymous. When you withdraw funds from a mixer, you are not anonymous. Even though you would like to be. So if you're using a cant absorption model, you can use part of the amount that you withdraw from the mixer as a gas payment. So this way you can withdraw completely anonymous from a mixer. One thing quick to add is the gas sponsorship model is very flexible. First of all, gave an example of onboarding where you're subsidizing the fee entirely. But you can have arbitrary logic. It's implemented by a contract. You can limit that in any way you want. You can subsidize if you want only some transactions. You can make users authenticate in some way. You can decide only to subsidize governance actions. I mean, it's arbitrary logic. So anything you want, you can do with this. Just you decide what the conditions are, including asking for repayment in another token. As I said, all of these are features that you have to implement. We implement the infrastructure. I'm only suggesting. Cross-chain operation, since you are protecting gas, you have a contract. You have a contract that can pay for its own deployment. And you have a mechanism that can pay for the deployment and for execution transactions. The next thing to think about is that I want to make operation on multiple networks. I am on the first network. I can pay on there. But I want to use my account on other networks. So it is possible to create a payment mechanism that I will be able to perform that operation on those other networks. It used my signature. I approve these transactions. So it's not some other party acting on my behalf. It's me acting on those networks. But I don't have any balance on this. I don't have to have any ETH balance or native token balance on those networks. It's a system that can move the payment between the networks. And lastly, we have a wallet. So there's a link for the entire presentation and everything at the end. As we said with the EOA accounts, I'm limited for performing a single operation at a time. Which cannot be batched and requires an exception on each operation. It's very easy to add to a wallet account performing a batch and doing atomically a sequence of operation. Another use case we can see is that you want an atomic operation or a delayed operation that is I create an operation and I want it to be executed later. A service can do it. And again, it is my account that performs this operation because I gave some service the rights to do it at a later time. Okay. These are all cool ideas. Some of them are very old. The role is regarding just the event-driven flows because they're very interesting. Maybe a couple of examples. One, let's say there's an NFT that means at a certain time. Then you don't have to wait in front of your computer. And then you just create the transaction. Then you could pre-register the transaction into a registry contract of pending transactions. And then searchers, you provide them an incentive to execute the transaction when the time comes and they're competing with each other. Another use case would be let's say you want to perform some trade in the future pending on certain conditions, price, whatever you want. So all this becomes possible and doesn't require any trust. Why do I keep it? Okay. With the ERC-4337, we wanted to create an implementation of account abstraction that can be executed today. Not something we have to change the protocol, but something we can add today. So we define a mempool of what we call a user operation. User operation is a transaction in our terminology. So just like the normal user mempool of transaction, there is the mempool of user operation that nodes can resort transactions from. They collect them to send them on the network. The key thing about this separate mempool, it's not a private mempool like FlashBots. It's just separate because it's accepting this user operation instead of a regular transaction. But the key thing that's different about this is just it doesn't require you to have like an EOA to interact. It doesn't require you to have the ETH to pay for it because what you're doing is you're specifying within the user operation the conditions that will make it worthwhile for bundlers to submit your transaction on chain. And they make sure they get refunded for gas, so it works out. Okay, so our implementation, what it does, it takes these user operations. You no longer need an EOA to send this user operation. The nodes themselves take the user operation, collect them into batches and put them on chain, perform the validation, that is validation is the signature, nonce, and the payment, and then perform the execution that you want to make. If you read the AP, most of the AP is not about usability, about how wallets work, but how we protect the network. It is very important that those nodes that handle operations like when they handle transactions are not susceptible to denial of service attacks. So we had a lot of mechanism to make sure that they cannot be attacked. So we batch them together so that they will be cheaper and sending them on chain. Since it is contract-based, it can work on any EVM-based network today. What would you see? We want to take it to the next level. Right now, when you create an account-obstructed wallet, we want to make it a first-class citizen on the network, a first-class account on the network. Right now, it isn't. It is second-class because there are some differences between EOA accounts and some applications require EOA accounts in the way they work, in the way they require signature. Think of permit. You cannot do permit directly with a wallet account. We do want to make them first-class citizens. So the next stage after what we have done today, which is having a contract-based mechanism to deploy them on chain, we want to add them into the network, to what we call enshrine 4337 into the network so that account-obstructed accounts will be accounts and transactions in the system just like normal accounts. And then, to make it possible to convert any EOA account into a smart account-obstructed. That is, there's going to be a way. It is not fully hashed yet. It will take some time until we finish it and until we approve it into the network. But there's going to be a way that you have a normal account and you want to have those extra features so you will be able to enable this account. There are several ways how to do it. One of them is that you will actively have to convert your EOA account into a smart account-obstructed account. The other way is that there's going to be some point in time where all EOA accounts will become abstracted but with a default implementation that emulates completely the normal EOA account. And from that point, yes, you can keep the same implementation or you can switch to a different implementation if you want extra features like all of those that we described earlier. One thing to maybe refine a little bit is we believe EOAs will need to go away at some point. So right now they are enshrined into the protocol and we've discussed some of the limitations around that. So at some point, EOAs, even if there's backwards compatibility, they will not be part of the protocol anymore. We don't necessarily think that it makes sense to enshrine any specific alternative like this is an ERC, maybe there will be improvements in the future because that could be dangerous, but what's clear is abstract accounts are going to be enshrined into the protocol. There are going to be accounts that can do all the things that we discussed out of the box for new deployments and for older deployments so otherwise you would need to transfer all your assets from one EOA to another and that's very expensive and cumbersome and potentially risky. So that's where we're headed and in terms of the implementation, like Droll said, there are various ways of going about it to be determined. Okay, what can we do? You can start experimenting with the ERC 4337 now. I see people who experimented here in the hackathon. Yes, over there also. You can add useful features to your accounts, innovate, do whatever you like and if you find something that you think is good for the public, you can apply for an EF grant and if you're building a DAP, as we said, wallet accounts are a bit different from EOA accounts. So even today when you're working with DAPs, this is not strictly related to account abstraction but to wallet account in general. Make sure that you are not forcing the user to use accounts. Like if you're checking signatures, there is an extension, the 1271, that allows a wallet account to check a signature because it doesn't have a signature by itself. When we say wallet account, just to be clear, we're talking about contract wallets. If you have a token and want to have permit, be aware that permit, as it is today in USDT and DAI, does not support a wallet account. You cannot use it from a wallet account. Again, because it uses the signature. There are some other tweaks like TX Origin and stuff. Again, in general, try to be supportive for wallet accounts because these are the future, not only the GNOSSI Save Today but also account abstracted in the future. Also, if you're using gas sponsorship models, you should also think about how to interact. This probably will need an interaction between the application and the wallet to provide the UX, how to provide it to your users. And the last item would be regarding wallets. If you're developing DAPs, then maybe there's some space. If you find that wallets are not supportive enough of contract wallets, then you can voice your concerns and try to lobby for that as a DAP developer that really helps. Getting everyone on board is a process that you could use your help on. Okay, it is before the last. The QR code is missing here. If you want the link to all this, I can give you it, but it doesn't appear on this version of the presentation. Any questions? Yes? I have two questions. One is related to how currently account abstraction exists as of today as an implementation. Can you provide an example of how it can be potentially used as it is in present form? The second question is related to the next step. They're curious about smart contracts containing code. Is there a distinction between operation that involve the smart wallet calling its own code versus calling the code from a different contract? Is it like on code becomes like a proxy for other contract call while interacting with other contracts in that ecosystem? Okay. For the first question, how to add it? Account abstraction is an interface or basic implementation that we have in our source code. Your wallet needs to inherit, provide a method or two, and then the contract wallet supports account abstraction. There's also a sample of how we add on top of existing IgnosiSafe without attaching the code, adding a module to make it account abstract enabled. You do need a wallet application or browser extension that will be able to use it. We have the basic SDK, how to write it. There are several wallets, soul wallet described behind you, demonstrated in the hackathon, and also a portal wallet, a hackathon project that's tried to use. There are no implementation in existing wallet like MetaMask doesn't support it currently. You have to use some other wallets, but this is now in the work. There are several wallets that are adding account abstraction support. Regarding how the call is done, this is the basic solidity. A wallet is a contract. When someone makes a call, it validates, it is allowed to make the call that is either the owner or through account abstraction validation method, and then it makes a call outside, so any other contract sees this contract as the account that makes the operation, like whether it's a token transfer or voting or whatever. We have another question. Yes, so regarding smart contract wallets, can you comment on the situation when you need to use L2 solutions? Because in most of the cases, you cannot, because you have a smart contract wallet deployed on Mainnet, and you cannot deploy it on every L2, like RVTrum or Optimus. It's, for instance, sorry. It will become a different address, that's what you mean? So you will need to represent the exact deployment to get the same address in order to do things like claim address. Of course, yes. The short answer, yes, we built it in a way that it will create the same address, so you can have the same address on multiple networks. Yes, as a wallet developer, it requires some work from you but for that to be possible. But it is not that difficult, and it can be done. Even the minimal implementation of that is happening when you're just funding your wallet the first time. Think of it, you open your wallet software, you see the address, it is not deployed anywhere. You see your address, you go to index and you move ETH or whatever into it, and then you make a transaction with that wallet. So if you think of it, this wallet contract will pay for its own deployment and then execute. Yes, that's how account abstraction implementation works today. So it works. Any more questions? Thanks. Thank you for your presentation. I guess we all agree about the importance of account abstraction, and this is what Luxo was working on starting from 2018 and starting with ERC 725 standard. I was checking the ERC way before and I couldn't understand because it was way too complicated. But I have just two questions. Can you explain more about how users can choose the implementation and about the cross-chain execution? Just an open question, maybe we can discuss that later. Don't you think that the standardization of the account, need more standardization of other stuff? I will give you an example. If you have your account needs to receive token, it needs to implement on ERC 721 received, on ERC 1155 received and token received for ERC 223. But what if we come up with a new standard in the future? We need on ERC 6700 maybe, and maybe also we need something related to followers. I don't know why, because now it's related to token, now the hype is token, maybe in the future it's not. We can discuss that later if you want. I'll try from the beginning. Yes, there were wallet accounts before account abstraction. They exist from the beginning of Ethereum, sorry, but they exist. We didn't invent the will. We created a standard which allows the framework, which allows nodes to support such accounts, accounts to be able to behave as close as possible to your accounts, like pay for the own deployments. It's a bit tricky, it's possible. Again, we didn't invent the will. We created the will there. We standardize on a way to perform, to separate validation from execution in order that validators, what we call bundlers, can be self-sustained and can be DOS protected. Yes, the IP is complex, but most of this complexity comes from these protection mechanisms. We should rewrite it in a way that is more account-friendly because most people don't implement a bundler. They want to implement an account, so they need to know what they have to do. Maybe some of the limitations they have on what they do, and they don't care about low-level implementation. Yes, editorial work is required for this spec. I agree. Cross-chain execution. Cross-chain execution, let's take it off-chain. Again, nothing of it is in the core of the EIP, like BLS. There's no BLS in the core. What there is in the core, for example, is the ability to do signature aggregation, that you check the aggregation in one place for entire batch. This is in the core. BLS is merely implementation of that. We nerd several interface. You add another contract to perform it, but it's separate from the core. So it is modular. All the features like specific features of wallets. You suggest some callback that exists today and maybe a callback that will exist in the future. The wallets will have to implement them. Right now, your EOA doesn't support them anyway. The idea is that when you deploy an account of such a contract, I don't think it's even written in the spec, but we expect it to be an upgradeable proxy that the owner can upgrade. And if it is an upgradeable proxy, we have a basic implementation, and then the owner can change it. Don't you think we're sacrificing security like we're going with upgradeable? What you do need to do is to make sure that on your first upgrade, you upgrade it in a way that now you add security. For example, after the first upgrade, you can only... a specific mechanism will be able to upgrade. Okay, account abstraction can be abused. I will not prevent you from creating an insecure wallet. I think you can create a secure wallet with it. Thank you. Yoav is watching us and sending us messages trying to participate in the question and answer session. Yoav just said, hey, what happens post-validation is not part of the standard. It's not part of ERC 4337, and anything can happen. We can talk about ideas on how to make it happen, but it's not specifically related to the standard that we're working on right now. It's kind of outside of the core, because we want to make the core as general purpose as possible, because maybe we don't have all the best ideas yet. By the way, if you think there is a security breach and something we can add to this definition, I'll be glad to talk and we'll be glad to add it. We are over time, however, this is a break time, so if you guys have lots of questions, we're happy to yield them. If you guys are happy to have more questions, anybody else? How can you make sure that a smart contract wallet will be able to prove that it's, for example, only controlled by one individual versus multi-six, such that the receiving contract can make a judgment call on whether it should reject or accept that call? For example, if I have... We have a separation. The model we have is like this. A smart contract has a separation between validation and execution. Execution is anything it calls out. You execute external counter whether it's a token or not. Validation gets the user operation and validates whatever it likes. The minimum is validated signature and validated nonce, that it's not a replay and it's a valid signer. But it can do more. It can check the actual executed method and say, okay, I restrict access to this destination or if it's a complex rule, I restrict access to this destination for this signer because I have multiple signer and each one has a different role and is allowed only specific method. The target contract like a token, a USDC token, a USDC token doesn't receive all this information. USDC receives transfer from a sender and it will accept it. It is the wallet logic, the logic inside the wallet within its validation, whether to allow or disallow specific, the operation we are now trying to make. Did I make myself clear? I'm not sure. Yes, it's complex. Yes, if your target smart contract does not have, you know, additional computational things going on that require it to, for example, take royalties, for example. Right? If I can circumvent royalty payments if I transfer an asset from Alice to Bob, right? And right now, with an EOA, I actually have to transfer the private key to circumvent the royalty payment. If I allow a smart contract doing that, I can change ownership of that smart... No, because the owner of the tokens is the smart contract. Yeah, I understand. But the point is, if I can transfer the ownership of the wallet address from Alice to Bob... You can transfer. That's exactly the problem. So it's like, that is exactly the problem. If you're in a royalty situation, that cannot be. So if you want a wallet, it's just a second. Otherwise you're circumventing royalty payments and you're doing something illegal. I'm not saying that we support it. I'm saying that a contract may support it. For example, if you want a soulbound wallet that you can't transfer the owner at all, go ahead, create such a wallet. If you want a wallet that doesn't support set implementation, then create a wallet that will refuse to change implementation. When you fix that implementation, you don't allow to change it. You can create such an implementation. We don't block such an implementation, but we support others. Understood. Is there any standard way to communicate what type of wallet implementation it is, such that the targeting contract can check whether... Because you don't know, right? It's like whether the targeting contract needs to know the context of the wallet implementation to make a judgment call about the owner. Okay, first of all, target contracts out there in the wild don't know anything about the caller, except that it is a message center. They can check the code if they like, but you are talking about the use cases that don't exist with EOAs, so they really knew also for smart contract calls, for any operation you are talking about. The other thing, you talk about standardization, how to know. Yes, it is required. We are providing right now the infrastructure for account abstractions, for wallets to be built about on top of it. Standardization between the account contracts and for example, the wallet application is something that the ecosystem will benefit, but it doesn't exist yet, because neither the wallet nor the contracts exist today. So usually it will be a siloed, like a given application with a given wallet contract with a given UX for it, but we won't... We will try to push and try to find innovations from the community to support such integration with such APIs. Your scenarios are interesting, but I don't think they exist at all in the ecosystem. The short answer is NFD can just check the code of the caller, and if they want to restrict themselves to primitive wallets, they can certainly do that. All of this will happen on a layer above what we are doing. Did you have some questions? No, I won't put the answers. You wanted to present the answers. Are you guys okay for a couple more? Oh, hi. Thanks for the talk. I believe you're also an author of EIP 2771. Is that right? Yes. This is the basis of meta transactions with OpenGSN. I was just curious what you see the role of EIP 2771 having in an account abstraction world, and also for those who don't know it, just explain it a little. It doesn't. It doesn't. It's not needed anymore. OpenGSN tried to do a gas abstraction, which we later implemented into account abstraction, for existing EOA accounts, and the requirement of the gas station network and network of relayers, which are the actual senders of transactions, meant that the target contract being token or other real sender, so they had to be modified, support EIP 2771 at the method so they can tell the real sender, which is a pain. It cause adaptation of this requires the target contract to be changed, doesn't support existing tokens, for example. If you want your token to be meta transaction enabled, you have to rewrite it. So yes, it was problematic. It was good to add support for existing users to sponsor the gas. Account abstraction has much higher goals to replace the accounts, and it supports almost all existing contracts. As I said, with the limitation of contracts that limit them to EOAs, it supports any contracts on the chain. All tokens, for example. So yes, with the limitation, you need to add support for some tokens in your account. That's right. I agree. So the target here is not helping adapt building subsidizing gas with account abstraction, though you can do it. The target is letting the user have control of his own account and do it in a better way. Thank you, George. Do you have another one? I mean, last one maybe. Thanks. So I haven't looked at 4337, so it might be a basic question. But how does ownership of the account work, the abstracted account, is it private key held? So it's kind of like an externally owned smart contract account. Is it single owner? Is it multi owner? And the other question I have is is this like a complimentary standard to off and off call? Or how would that work with when off call is implemented? The first question is all of the above or any of them because each wallet can decide. As I said, we had a wallet here that demonstrate how to use zero knowledge proof instead of signatures. Another wallet that implements RSA signatures from your phone. You want EOA? Yes. Our simple implementation uses EOA as an owner, but it's just one implementation. The other question regarding off and off call, it is possible to do some of the features with off and off call. They basically do the abstracting payment. We believe that it is far too complex feature just to justify these two op codes because they don't do anything else of the account attraction. They don't change. They enshrine the ECDSA for example. So they can be combined, they can be used together, but we hope for other alternatives. A huge round of applause for Syrian drawer. Thank you very much. Thank you everyone. Thank you so much.