Wallets Reimagined: ERC-8286 & EIP-8141 in Production

Transcript

[music] [music] Good morning everyone. I think Mumbai is fun so far. Uh today I saw a lot of talks about wallets and yeah that's particularly my niche as well. So yeah. Hey I'm Chiranjie. Uh I work as an SD at Inco network. I have been contributing to open source uh at Ethereum for 4337 7579 and I have built a lot of wallets with a lot of clients.

So yeah uh let's get right into it. So first questions like why native? Why would we even need native air when we have 4337? So before discussing that like why we need native air let's just first assess like what 4337 got right. First of all it proved that a works without a hard fork. I mean it's a bunch of contracts that works so simultaneously together the 4337 contract and everything is orchested properly and it happened without a hard fork. Second thing uh I think the most important thing that happened it defined the mempool rules that the actual account abstraction standard needs. uh example 7562

validation rules are actually the basis for 8141's public mem pool and it also proved a lot of use cases like gas sponsorship like custom validation schemes like using your pass key to validate transactions and like programmable execution policies like uh 7579's um pre-execution and post-execution hooks. So yeah and it grew a lot of modular account ecosystems as well with 75796900 etc. Yeah. So with 437 as we have seen from like March 2023 when entry point was live there have been over 1 billion user option that have been like processed so far and like when uh 7702 I know that is famous right now after the Binance hack.

So 7702 actually helped onboard a lot of us to actually use smart accounts. Uh I guess more than 50 million. Yeah. So we we clearly see a use case with account abstraction and people are adopting it. And yeah so why not just use 4337? It's already existing. Why do we need to introduce a native account abstraction model? First thing it needs a parallel stack. You can't run 4337 in the public meool as we know right now. We we need an alternate meool which basically batches all your user operations. First of all, it's higher infra. It's again adding more latency to um Ethereum and like higher infra costs as well.

with higher infra cost. It also costs a lot of more gas to use 4337 directly because it's basically you are um actually wrapping your transaction and sending it to us uh a different smart contract which actually executes it for you. Yeah. And the most important it's not postquantum secure because they still rely on EOS to post the transactions on chain. So yeah with the tagline like a belongs in the protocol not on top of it. So here comes EIP8141. So the first time in Ethereum's history, every transaction can start from a smart account. Basically smart contract. You don't need an EOA to do state changes on

Ethereum anymore. So like with 8141, we you uh we are introducing like smart contracts, they can pay for themselves. They don't need a separate EO to do changes for them like a relayer or something. And most important thing, your Ethereum address is isn't tied to a key pair anymore with this EIP. So like to to actually get into the Ethereum ecosystem, you actually need a uh like ECDSA based wallet. You have to create a seed phrase everything and then only you can do state changes on Ethereum. So what is this uh frame transactions?

Basically, it's a new type. It's called type 06 which introduces frames in the RLP payload of the transaction. So it adds three extra fields frames, signatures and fees. So frames like you have like a uh three I I'll get into more details of that. Yeah. So as you can see on the screen this is the RLP payload for that we are introducing with 8.41. So I'll explain how like the what are the types of frames and like what are frames exactly. So in legacy transactions um like we actually can term it like a top level frame with fixed from and two values and the call data that you want to execute. With frame it has a mode modifier which has

three modes. First verify mode which basically decides if the uh transaction is actually valid or not. The default mode it basically invokes any smart contract that you want to um touch any storage slots you want to touch. And sender frame mode. So in sender framework that's interesting because it say uh sets the TX sender of the particular transaction but it calls the target contract directly. It doesn't go through the account. And with 814 we are introducing new op codes as well which actually enables all this. So the flagship op code I would say would be the approve op code. So accounts and pay masters can now approve actions explicitly. So there is three

modes in uh approval op code. First is the payment. So let's say a smart contract calls approve op code at the end of whatever state changes that. So if they return approve payment that means that that particular smart account is smart contract is saying that okay I'm happy to pay for this transaction. And if a smart contract says uh returns with the approve and says I only approve execution then uh what happens is it basically sets the TX sender to that particular contract and then it only says that I exe I am approving this transaction to be executed but not paid and obviously we have like both you can do both a smart contract can say I

approve the payment of this transaction and the execution of it as well. uh with this new AIP like there are like new introspection op codes as well. So basically if a smart contract wants to check like okay if what are the frames involved in this whole transaction I want to see if I want to sponsor it or not if I want to execute it or not. So you can do introspections of frames using these op codes. Yeah. So how everything falls together like it's basically divided into now two prefix one is the validation prefix one is the execution body. Now for a transaction to get included onchain you would need to have the validation prefix

actually approving your whole batch before the execution body begins. And um there is um some mempool policies that we need to be aware of right now cuz uh validation prefix affects the mempool and it has to follow some canonical rules on like what a verify frame can actually touch or like touch as in the storage slots what blocks uh what storage slot it can access during validation and stuff. So this is a shape of a trans a sponsor transaction like how would it look. So if you see there is like a a validation prefix and there is verify frame one.

Now the target for that frame is the account itself and then uh the account runs some validation checks on it and says okay yeah it's approved now. Then if you see a frame two which is actually target to a to a pay master. You can even use your UA to call the approve um a payment op code. So it validate validates the pay master logic and if it's it's willing to sponsor the transaction and deducts gas for it and the execution body will have the uh default and sender frames like uh like subsequent frames that you want to execute basically your main call data that you want to actually execute on chain.

Yeah. So 8141 is a transaction type. It's not an account standard. So who decides how to call approve and when to call approve? So this is the ERC which basically is is based off of ERC 7579 which was made for ERC 4337 but it enables frames now. So this is a modular account standard that I created with uh teams from um Alex he works at EF and Pedro who is the founder of wallet connect. So it's based on ERC 7579 and it introduced a new module type to the ERC 7579 space called 11 one. It's TBD. We can change it afterwards but it uh has a

new in uh interface called I frame validator and it has a new function to it as well. It's called validate frames. 7579 has validate user op because it was based off on 4337. But with this we need validate frame. It returns an approval mode like whatever the uh transaction context has set and that transaction context actually comes from the introspection op course that I was discussing earlier and the account has a privilege to not support a particular approval mode. Let's say a a smart account decides okay I I can only execute things I I don't want to sponsor things. So they can actually pick what mode they want to support if they want to just support execution, if they want to support

payments or if if they want to support both. So yeah, so let's just see an example how a frame transaction actually lands on chain. So first of all you create that RLP payload to and send it to a node and u if you see there is a default frame a verify frame like two verify frames and the uh subsequent sender frames and there is this nons that uh I use a postquantum validator for it and then um the protocol checks if the nuns uh is already not used or something uh like is it pending or something like that and then we check the signatures from the transaction if there are any for in our

example it will be empty cuz because we are using a postquantum secure scheme and yeah so first frame default frame um quick thing as I said validation prefix needs to be executed before execution phase begins but there is an exception the public mele allows a default frame to run before the verify frames basically the validation prefix There is some restrictions through this default frame. So So this default frame can only be used to deploy an account from a factory. That's it. It it's not allowed to do anything else. So the public mele checks if the TX sender has code or not. If it doesn't have the code

like like smart contract code, then uh it basically uh allows a default frame to be called and uh it checks if the after the execution of the default frame did the account get deployed. If yes then yeah we can go ahead with the validation prefix. Now yeah I in frame zero I called the factory contract. The factory basically creates the accounts with the implementation and deploys a proxy smart account. So next phase we need to pick a validator. So there is this uh if you see uh the uh we call the verify functions on the account itself. Now cuz in the previous frame it got deployed. So code exists there. We

we target the verify frame on the account and you see I do some frame introspections from there. So I is basically the index of the frame that we are executing right now. Mode is basically the mode that we are running maybe an approval payment mode or like u execution mode. Yeah. And you see the key thing right? Key TX param0x10. So it's a new EIP EIP 8250 which is based off on 8141. It basically has keyed nons. So we can actually populate what validator we want to use in that key param itself. So if you see uh first we have a require statement that says okay the mode should be a verify mode. Then we fetch the validator address from the key and it comes from the transaction

context itself. Then we check if the validator is installed or not for this particular account. And then we delegate call to the validator saying okay now we should check um if the validation data is correct or not. And here's a nuance to it. You can't do static calls. You have to do a delegate call. Um cuz um 8141 only allows storage slots of the account itself to be touched so that there is no DOS vectors that can exist in the me pool. And uh the validator says okay and then we decode the approval mode it granted.

So let's now see what happens inside the validator. Now if you see the the validate frame that we discuss of uh from the uh 8286 standard. Now we basically get the target frame that's involved and the allowed uh frame mode that it can execute. We then uh do the signature check. Uh I'm using a spin example here. And then we basically return the approved context. So if it's approving uh if the if this frame um scope is to approve payment or to approve um execution and then in the account side we check uh what was granted and if it was allowed

so we do an and operation and basically nullify the bits if it's not allowed or something by the account and there is this new nuance called root is equal to is equal to contract I will get into that later why it exists and then if we check uh if it's um the granted mode is actually supported by the account or not and then uh at the end we return with approve 00 granted. So it will have the approve op code with uh the the mode that it approves. So in this example we just approved execution. We didn't approve the payment. As you can see I called the approve code 0x02 uh sorry 0x2. And now the next verify frame targets the pay

master. Now it's a very simple example of yeah I haven't implemented any like you know complex pay master math or something. So we just check what mode it is. Is it a verify mode and uh if the allowed scope of that frame per is um approve payment or not? If it's something else like approve execution I'm not going to do it. So pay master denies. It can only support approve payment and it returns with approval context 0x1. So the validation prefix is now over. We'll come to the sender prefix now like uh execution prefix now.

So here's the nuance I want to talk about. As I said uh sender frames uh sender frames they execute directly. They don't need to contact to the account beforehand like for to check execution policies or anything like that. So you see the function execute execution route right? So it's a function that we expose of the 8286 account and it basically says that okay if calls from this should go directly through the protocol or it should always go through the contract. What do I mean by always go to the contract? It basically means that the sender frame should always target the accounts execute function and not directly the target.

And then we can apply all the 7579 hooks whatever policies we execution policies we need. And at the last um the protocol checks how much gas was used, how much gas was actually charged. And if this uh there was like uh uh some refund to be done to the payer, it basically refunds that back to the pay master. And then you get this new uh receipt type which has a frames encoding and it gives you the status of status of execution of each sender frames if it got reverted, if it got accepted, anything like that. Yeah.

So the security assumption that I was making earlier like protocol versus contract dispatched um what it means is that um so ex so approve execution is a blank check for the whole transaction. So once approve execution is called from an account context you you can't stop it from executing uh sender frames or anything or yeah so that's why we need to fix like what execution route the frame transaction should take. So if the execution route protocol uh is protocol basically meaning that sender can directly call the target no hooks no execution policies here but if you want like to establish some uh execution policies on the account and we we we

need to make sure if it's uh you know enforced properly then you need to target the sender frame to the accounts execute function and all the self call 7579 hooks um everything applies and This mode enforces sender frames to target the account else it will revert in the validation phase itself. So 8141 is uh trying to be coming in the hegota folk. I I think we are tight with the timelines and it's getting extended now but um wallet teams are deciding now on how to implement this frame transaction type and uh I would love to have feedback from all the wallet teams that what do they think of this u

standard and how can we make it so that there is no more fragmentation that happened with 4337 with 7579 and 6900. So yeah and I actually created an ERC 8286 playground which uses a postquantum secure validator and you can actually check for yourself like how the frames look like how the whole transaction structure looks and what approval modes we can use and yeah all the policies like that. Um yeah, thank you so much and you we can connect me on Twitter if you have any questions about it and I guess yeah we we can answer some of the questions that we get got.

>> Perfect. Chanjie, thank you so much. That was a great talk. So we already have pretty interesting questions. I'm going to start with the first one. How does 81841 remove or replace the 7702 issue in the Binance hack or does it not? If you use an EOA, it won't because uh the whole thing is that we want to separate the account model from the transaction model. So your account isn't tied to a key pair anymore. That's what 8141 brings. So no, if you directly um use an EO and then use a ERC8286 smart account. Uh no, it can't. But there is an interesting EIP which we are building on top of 8141. It's called EIP 7906

which basically has transaction assertions. So at the end of frames execution, it can check, okay, um did I do something wrong? Um did did this transaction move $1 million to some other wallet or something? And we can revert it from there. >> Yeah, >> cool. Thanks. Uh the next one is some institutions are interested in 437 because of the alt meool. Uh if we eliminate that, how will adoption be? >> Yes. um 437 alternate meool um was there because of um the DOSS vector that mempools can face the mass invalidation attacks that the mempool can face. Um there is some benefits to alt mempool as

in like you get to access a different type of storage slots if you stake some amount of in the entry point. um we are still discussing what how the adoption will be but I feel uh personally it's my personal take that it doesn't matter like the canonical rules also like improve a lot from the 7562 rules so yeah >> cool uh interestingly enough no speaker is safe today from quantum questions yeah >> so I'm going to throw one at you right now how are you planning to make this post quantum secure >> so as I said uh The validation scheme isn't rely on the ECDC key that you own anymore. It's on the postquantum secure

scheme that you that your account owns. So you don't use an EOA to do transactions anymore. So that's how you achieve postquantum security. With 4337 we also had like u like uh postquantum secure the spin validator. But then there's the question of um like the bundlers are still like prone to the postquantum secure attacks. So 8141 solves it by basically delegating the validation prefix to the account itself and not the protocol. Perfect. Thank you. There's an interesting one. So with 7702 upgrading EOAS and 8141 making an account obstruction native in 5 years does the word EOA still exist? What are your thoughts on that? Um I mean I would love if the word EO doesn't exist anymore but

we do need to consider that there is a lot of volume still relying on EOS. It will it will take time but I I think yeah it won't exist anymore after five two three years three years maybe. Yeah. Yeah. >> Okay. Perfect. So again one interesting one. So I'll merge two questions into one. Oh sure. Do you have any thoughts on wallets for AI agents? And basically what it means is this question which is AI agents are becoming wallet users as well. So does frame transaction make it easier for them as well to for tightly >> exactly exactly that's what I'm talking about like um your agent doesn't need to have a key pair or like you know have to keep a wallet funded with gas anymore.

It can have custom validation logics and custom um gas payment logics as well. we can set up a pay master that says okay oh if this AI agent is coming then I'll sponsor the transaction for them they don't need to set up any EOS or key pairs of some sort so there is no security assumption that exists anymore for that yeah perfect I can take one more question uh after this protocol change which is the 8141 will this existing 4337 contracts be affected at protocol level or if not on the application level >> it won't be affected but they are not backward compatible is what I'm trying to Okay. Um uh the bundlers will still exist but like um if the adoption grows more for 8141 there is a chance that um

no would preferably run a bundler. Now organizations or institution may need to run their own bundler to submit the uh the user operations to the block. But yeah that that's true that uh that might affect yeah >> so like just out of curiosity so basically people who already use these accounts 4337s they will have to sort of migrate if this become >> there is a migration that can happen with 4337 yes but we we are trying it's still in draft 8141 is still in draft we are still active