Ethereum Cat Herders PEEPanEIP, 20 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: PEEPanEIP #100: ERC-4337: Account Abstraction Using Alt Mempool with Yoav Weiss

Description

Topics covered
----------------------------
01:58 - Yoav W Introduction.
02:47 - Dror Tirosh Introduction
03:17 - Shahaf's Introduction.
03:38 - Tom's Introduction
04:00 - What's new in ERC-4337?
08:15 - key Challenges - Why is it so Complicated?
10:19 - UserOperation.
11:40 - Submit UserOperation to bundler
13:47 - Submit UserOperation to bundler with factory
15:41 - Submit UserOperation to bundler with PayMaster
16:14 - Creating HandleOps Transaction.
20:20 - Account API
24:21 - Minimal Account
25:13 - Pay Master
26:09 - Custom Factory
27:15 - Key Challenges - Why is it so Complicated?
27:38 - Protection Rule Principles.
29:36- Code Validation Rules.
30:34- Storage Validation rules.
32:46 - RPC APIs
33:25 - Signature Aggregation.
34:33 - Bundler-Spec - Test.
37:09 - What Kind What do you of Simulation is used for?
42:07 - What do you think 4337 needs something to impact tabs
45-27 - Are you expecting the new kind of depth tooling to Springup.
49:31 - Mean reason for the change.
52:19 - Smaller the Proposal, the greater chance to Coming up as a final Standard Community to use
54:00 - Draft - Review - Published - Explained.
56:04 - Features of external audit
59:23 - Is there a Worker for projects to resolve this issue of incompatibility?
1:00:43 - ERC-4337 will be compatible with EIP-3074?
1:03:08 - Do you think, It will make affect projects, that have already been implemented to EIP-4337?

Resources:
-----------------
Slides - https://hackmd.io/@dror/peep4337#/

EIP-4337 - https://eips.ethereum.org/EIPS/eip-4337

Discussion - https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160

PEEPanEIP - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F

ERCs - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K

Questions for Guests - https://docs.google.com/forms/d/e/1FAIpQLSdsmujnH_ncIlSEJ23s9jzXAKwfpTGNeJqjREWPloBbkJVQTA/viewform

Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2

Follow at Twitter
Yoav W. @yoavw | Pooja Ranjan @poojaranjan19

Client Diversity Survey - http://tiny.cc/ECHsurvey

Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/ethereumcatherders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
Website: https://www.ethereumcatherders.com/

A

Eap, 86 and eap2938 are different, ethereum Improvement proposal for account abstraction in the standard track, Port category, but unfortunately none of them Reach the final status. If you are wondering what the next proposal on account abstraction is stay with us.

A

Hello: everyone I, am Puja ranjan here with the 100th episode on p penny. Today we will learn about eip4337 account abstraction using Altman pool. Eip4337 is a standard track. Erc proposal documented in September 2021 authored by multiple co-authors, including vitalik buteran. This proposal initially proposed to bring account abstraction without making changes to the core protocol. As some of you may know, the earlier version of this ERC proposal offered account abstraction via entry point contract. However, after the merge, the working group behind eip-4337 updated the proposal to provide an overview of The Proposal with latest changes.

A

We are joined by the author yof Wise from ethereum Foundation, along with other members supporting proposal. 4337. Welcome to the show you if.

B

Thank you. We're.

C

Excited. Thank you for having us, especially.

B

On the hundreds on the 100 episode, we are lucky.

A

Yeah, thank you all for joining us today uh for people who aren't really aware of the earlier proposal. You may follow episode 65 with uof and Kristoff um yeah, it's been a while, so um maybe we can start with a quick introduction of you and of rest of the team member working behind this uh proposal.

B

Yeah so uh yeah so I'm your advice, I'm uh I'm, a security, research of the film foundation and I've been working on account obstruction for a couple of years. Now, I will so I will let the other members introduce himself in a moment, but uh briefly, uh I will briefly mention that this proposal, since we are not going to start from a to start from zero, because we have many changes to discuss.

B

I will just mention that this proposal, unlike a previous account obstruction proposals, is in the ELC track, meaning that it does not require consensus changes. It's account obstruction by creating another layer on top of ethereum, to provide the to provide account obstruction through an alternative mempool. So um I draw would like to continue.

D

uh Yes, I'm drawer, I, walk on this proposal early on just after you have started it with vitalik about uh 20 years ago, started creating the initial version a year ago and spent the last year trying to find Partners to work with it and, of course, solidify the protocol and improve it. It will see a.

C

For several years now, we've been working together and so naturally I've been working on account of taken as well with them, and here we are.

E

Going my name is Tom and I recently joined the team and the foundation and before that, I founded porless, which was acquired by shapeshift in 2020.

A

Awesome, thank you so much for the introduction everyone and thank you so much for joining us on this special episode. um Maybe we can just now kick off with the presentation.

C

Okay, yes, so one we've added since last time: okay, yeah! We because we have been here a year ago and we had a presentation where you have mostly uh did the presentation over there. But since then, we've added a few changes, so several changes to the core protocol in order to accommodate uh more useful use cases both from accounts and other entities such as the paymaster. That is, the contact that pays for the gas and basically handles all the gas accounting Logic on behalf of the account if it needs one.

C

So what's new here, so the account changes, we've added, which we'll discuss a little bit later. But briefly, uh we we added the option. For example, we allowed the use case for adding session keys or changing the or aggregating signatures.

C

If we want to to make the we make the transaction a little bit cheaper by batching it, and we basically allow that all in the next in this version, as opposed to the previous one, and we all we also by having a little bit more relaxed, uh acne storage rules, access, uh basically a little less restrictive on the Paint Masters on and on all entities.

C

We also allowed other use cases that weren't previously allowed, so in the previous, uh in the previous version of the counter production on 457, the paymaster itself couldn't even access its own storage or storage, for example, on on another contacts on that is associated with with the sender, with the account in contact and that, for example, blocked uh blocked, an implementation of of a very common use case. That is a token permaster that basically reach out just the talk, the user with tokens and refunds, the refunds after the transaction finish now.

C

In this version we also allowed that part and that, by allowing by allowing such storage access, we also had different security consideration that we then that needed to mitigate, and that comes the staking and reputations for all entities and which is a huge part of our effort in the past year, and the last part between that. We added is also basically pretty much finalized.

C

The bundles RPC API, both the production code for production and for debug and added as a basically a compatibility test suit for the for the bundles, as well as the reference implementation on SDK.

B

Just them as a I would like to order I would actually frame the changes before we started diving into individual changes that, uh in the previous video that we talked about a year ago, uh our Focus was to get something out to start experimenting. So we focused on security, and we put uh we put many restrictions during validation in order to keep the system secure and since then, since then we collected a lot of feedback.

B

We learned more about use cases, so the focus of most of the changes we're going to discuss today are a usability Improvement area. We want to improve the usability of the protocol, the other ability of the protocol by removing as many restrictions as or relaxing as many restrictions as possible, while remaining secure so.

C

Right just to frame it yeah exactly I mean the last version was while secured was very restrictive in in terms of what use cases were available back then, so, allowing more use cases were pretty much opened up new attack vectors that then we needed to to mitigate and consider- and that was a huge part of our effort here, basically allowing more, but with the same security or as much as we can in order to make it usable and feasible.

C

D

You, okay, a before diving into the actual changes we look. Let's look about the key challenges of account, obstruction and white is so complicated account abstraction come to replace an eoa with a contract based account. Now eoa is execute by the protocol itself, using signature, nonce and gas fees. These are validated by the account and filled by the account and then validated by the node that takes this transaction into the mempool. Once you create a transaction, it is impossible to either for it to get invalidated.

D

It is a agreed to pay to the gas fees and it is impossible for it to pay less. It can be replaced with something that pay more, but it can be get any less. A user operation is a kind of transaction, but it uses evm code for do the validation and snevm code. It uses storage and it can be invalidated. So we lose that property. That user operation is a a a valid and cannot be invalidated.

D

So our goal with the spec most of the spec is how to uh make, since we can't prevent this invalidation how to make such an validation expensive. So if you try to make a Dos attack on the the member you can, but it will cost, it will cost a lot. If you want to block the system by bombard database transaction, you will have to pay for each transaction and we what what we try to prevent is a snap is a single small change that invalidates a large number of transaction.

D

If you will formally or mathematically way to put it is that putting any other transaction into the main pool should cost or removing sorry and use a transaction in that mempool will cost o of n because uh they will have to pay for it. So it's not easy to invalidate them in a snap before we dive into the flows, this is recappa. What the user operation is it's a kind of transaction in many aspects, it's a similar to a normal transaction. You have the call data that you make a call. You have the gas limit.

D

You specify the sender, the account that's in the transaction. We have a signature, but we no longer can assume that the signal to return the sender we are not bound to ecdsa, with the gas limit and with the gas priority and a Max paper gas like normal transactions, but we have some additions since we have verification and verification is a contract, so we also have verification cash limit.

D

There are some things we can't do on chain: it's not a fixed 25 000 that we can assume. So we have what we call a pre-verification gas, something you pay, but the calculated off chain, and we want to allow an external entity to pay for the transaction. So we added a paymaster data into the structure. And, lastly, because it's a contract and contract need to be deployed and we don't know in advance how to deploy it. We have an init code.

D

If you have an edit code, it means it's a user operation that creates a new account on chain.

D

So let's try to see how we, how a user operation is created and sent with the user. The user is the normal user account. It creates a user operation and sign it and use an RPC called send user operation to send it into the bundle. A bundler is the is usually a node. You can think of it as a node. It collects the user operations and then we'll later on right. It collects this operation, put them into the main pool and later on, put into a transaction.

D

So we use the term bundler, because not all nodes will create bundles, but it is very tight to what a bumper is and the extract entry point. The entry point contract. This is the main contract we created. It makes the the protocol tick.

D

So a an account- and this is the account the contract account that will eventually make the call, but we are now just putting it a transaction into the main pool, so we're only validating the transaction.

D

The way the bundle does it it make a simulation, simulate, validation, a view call it's a trace, call we'll see it in a moment. It make a simulate validation to execute this validation function. This validation validates signature, validate the nodes, increment the nodes and pay fees for propane. For this transaction, after this validation, the bundler performs some checks on this just executed transaction to make sure that the code that you've executed is a is good, for example, that it doesn't use opcodes that we know can be used by malicious actors.

D

We will go into that later and then it adds this user protection into the mempool. This is a simple transaction, that of an already existing a contract. But if the account contract is not yet existed on chain, then it the first user operation will include init code and by including init code we mean say it is a contains. The address of a factory contract. This Factor contract will create this account everything within this vehicle, and then we will be able to call the validate on this newly created account.

D

We cannot validate an account before it is created, so we created just for the simulation and then validate it and, as we said, if we want to use a flow that use a different contract to pay for the for the call, then we have a paymaster contract. So again, this user operation specify within the user operation.

D

The address of the paymaster and maybe some extra data that it uses and after validating the user operation that validates signature nodes, as we said, we also contact the paymaster contract to make sure that it agrees to pay for this specific transaction, and if you notice, the account doesn't pay.

D

In this case, Turns Point doesn't ask the user and to pay anything for this transaction because it will be the paymaster that will pay and entry point contract manages the balance in this case, I pay Master face through its previously deposited balance within the entry point again. The validation rules applies for the paymaster and the account because we as the system as the entry point, cannot trust and vendors. We cannot trust any external contract. We don't trust accounts, we don't run paymasters, we validate, they don't try to perform malicious operation on the network.

D

So, okay, the user operations, are in the mempool. We have multiple user operations in the mempool uh as just before that uh this flow just shows that a single user operation can include initialization and a payment and validation by a paymaster and, of course, the mandatory validate user rope. In the slides, all the rest of the slides I will not show all these entities. I will just specify the validate user up, because this is the main one, but any operation can contain a factory if needed and a paymaster foreign.

D

So in the next slide we see a the flow that the a bundler does in order to create a bundle. A normal node collects a a transaction from the main pool and since it validates when they were entered to the main pool, they are still valid. The only small check it has to do is to make sure that the transaction was not already replaced by checking the nuns.

D

um In our case, it cannot do any short circuit. It has to do a full simulation. This is second validation. We call it the second validation. The first validation was when this user operation entered the mempool, and now we are doing the second validation just before putting it into a bundle it scans, the mm pool, whatever order it likes, probably takes the highest paying user impression. First called the validation function and they add them again, including the storage, validation, everything and add them to the bundle.

D

Once it collected enough user operations, it creates a transaction, a single transaction called the handle Ops and send it to the Enterprise contract.

D

They say transaction performs they all the validations on chain and, after all, validations of this bundle succeed. It performs the execution it calls the call data of all these user operations uh in order to execute them on chain a again. The validations are known to succeed because we try them all off chain and the aid execution just like normal transaction, they may or main mail revert or not. But at this point we know that they all paid they're all paid for either by the account itself or by the pay buster after the execution.

D

There is, of course, a loop of refunding the excess fund, just like a normal transaction and paying the collected fees from all the bundles to the.

C

To interject here, as you can see here, this this slide is I believe is very important because it pretty much shows uh the security considerations and the the road blockers that we had during uh doing the development of the CIP. In that we have some several invariants that we have to keep okay, in contrast to uh to a normal, ethereum transaction, as dual said before. That is that the validation between simulation and execution on chain between the first simulation and when it first enters the the mempool and the second simulation right before it.

C

It is included in a bundle. We both have to keep that the validation stays the same, and the validation is exactly the same once it runs inside a button on chain, okay, when when the bundle calls handle. So there is the first simulation which is included in the mempool, then when it is included the in in a bundle that is the second simulation and finally on execution when it runs on on the actual on uh blockchain. Now.

C

The second environment that needs to be uh said here is for, for the. For, with the security of the account of the wallet. Is there is a coupling between the validation and execution, because the entry point is a trusted contact. The validation and execution must be coupled in such a way that only once only one execution and exactly one execution is B is called right after a validation and cannot be called otherwise.

C

So, though, you can continue, click.

D

Okay, thank you. Okay, let's dive into the actual apis and the modification. This is the API of an account. It's an interface called iaccount and it provides a single function, called the a validate user, app validate user up a has one significant change from the previous release. Is it returns, validation data? It receives the user operation itself, it receives the hash of this user operation and it receive a the missing funds. What is needed to be paid to cover this?

D

The max possible, the mass possible cost of this user operation validate user op is expected to return if it succeeds and.

D

D

Any traverts on any failure like nons on other things, it should simply revert. There is a to a major cases in which it should not avert but should insert the return value.

D

The validation data contains a Time range, a which is a way for the user rope to signify that it is valid only in a specific until a specific time or starting from a specific time. As we said earlier, a validation can't use a timestamp or block op codes, because this will allow them to enter the main pool and get invalidated later in Mass. So we don't allow them to use directly these op codes.

D

What we do is allow them to return a range, and then it is a the entry point that will prevent this user operation to be included on chain if it is outside of the range and, of course the bundler will not attempt to put it on chain if it's outside of the range or very close to that, the other return value we add returning return value is a signature check in the first, or at least we use. We reverted on signature check, which is obvious.

D

This is the major thing you want to do in validation, but when discussing with volatile developers, we understood that it prevents a major use case for wallets and that is estimate a transaction. You can't estimate a transaction if it reverts so instead, a the validation returns, a marker whether the signature is succeed. It turns zero, a zero address, meaning yes, I validated the signature. Everything is okay, I'm, saying I checked the signature it for it's wrong signature during estimation, uh the wallet will put some bogus signature that will pass all the size, checks and everything.

D

But yes, it will fail a signature check, but it is okay. It is estimation all the estimation will continue. It will work only during guesstimation, Because handelope. The actual uh transaction that will put a bundle on chain will of course revert unless it returns a zero. uh There is another special case, and that is a using a signature aggregator.

D

If my wallet is using a signature aggregator, it means there is another contract. He trusts to do the actual signature check. So it returns this as an address instead of saying zero. Everything is okay. It says ask this: one asked a signature aggregate, whether it's correct, and it signifies to the entry point to contact this external contract to the signature check.

D

uh We do provide in our repo some helper classes, like a base account to do the basic logic of a generic to call it. Every wallet does, and we have also a simple account, which is an eoa like minimal proxy contract, but uh I wanted to put the basic, very minimal, validate user app. It is based on our simple account, but packed only into a single method, so it will fit a single screen.

D

So we see the validate user rope, it accepts it validates first, that it is called from the entry point. Then it recover. It calculates a hash and they recover to check whether it is a the owner. Dom is supposed to be a member. If it fails, it's a validation data into zero. This is the simplest way to do a validation. If you don't care about the range we have a helper function, if you do support ranges to pack them into the validation data, he checks the nons.

D

That is, it makes sure that the nonce is valid for the current transaction and increment it for the next ones and pay in case it needed paymaster again. The same change happened for paymaster, in that it returned a validation data. It can return validation data just like an account like if you have a payment that agrees to pay for a coupon for a specific time range or something like that.

D

Another use case is that the a in another use case for a paymaster is what we call a verifying paymaster that uses a an external, a check. So again, it need to skip if it has a signature check um and as we will see later, a payments are used to be in the previous APA whitelist. Now we support paymaster that don't have to be whitelisted.

D

In most cases, they will have a stake and simple paymaster like verify paymaster can go say without using stake.

D

Another change with the factory in the previous CIP we required an entire, create two, a init code to be included in the user operation. We understood this is both limiting and excessive gas-wise. So instead we provide the address.

D

Init code is the address.

C

um The address of the factory plus the call data that is being that the these others will be called with to to create the account okay, that in that way, we also support uh other existing other existing Solutions. Like diagnosis, epoxy factor that.

D

Is mentioned here, it also allows very easy way if you have a factory that is valid on different networks, then also the curated contracts will be the same on different Networks.

D

uh Okay else that this is a sample of animal Factory, a again I repeat her before we go into the changes to the protection rules, we have our key challenges and, yes, what we have tried to do is prevent denial of service on our Network on the network of bundlers, because our validation is more complex, so it's to protect them.

C

So that is a reminder. Yes, as you have said initially, that in the previous, uh in the previous version, we pretty much focused on security, and now we wanted to leave some of the restrictions on the usability part, but also keeping the insecurity in mind. So that comes the Here Comes these the protection words that we see here and why we we were able to relax some of them and to still keep the security intact.

C

D

Yes, uh so the protection rules sandboxing, is validation to learn the same on chain. This is a requiring that the code will not be able to detect that it is a running in validation, mode isolation is user operation should not share State. Each user operation should be on the access itself.

D

We were able to extend this in this version, and staking is a mechanism for us to apply reputation, mechanism to a playmasters and not only to pay masters so that they will be able to use their state and a support. Multiple user operations.

C

By staking, we allowed an even more relaxed storage access and even more use cases.

E

C

With the trade-off of having to stake now, it's worth mentioning that the stake is never slashed on chain, because the damage that can be done is also not not monetary, at least not directly, not by causing reverse unchain, but computational. The CPU time of chain for the bundler, so staking is basically a mechanism to to mitigate the the CPU abuse that any malicious entity here can cause the in the the bundle.

D

If you look at the code, validation rules, these were extended a little bit from the previous version, but again we block any user operation that allows a to understand. You are running in the sandbox, so uh we block multiple op codes. We check the code that you access. We try to block anything that they can cause a difference between the validation and execution. Like you no longer you are not allowed to access any OA.

D

There is no reason for you to make a call into an eua, even though it doesn't revert, because if someone deploys something there to get reverted later, this is a part of the thing that every block. uh This is one thing that we added in this version, but again it's more a blocking malicious attempts that we're trying to keep. What is more interesting is the the storage rules.

D

Account is allowed to access its own storage and also we extended that also entities like a payment. A factory can also access the storage of an account. It can be directly with the account itself or most likely, by a accessor method, of the account itself to access a storage in the account. What we do allow in the this version is, we also allow reference storage, a storage that is a its address is not directly, but it is based on the hash of the account itself.

D

So you are allowed like if I'm a pain, master I am a lot of accounted safe. I am allowed to access a token balance of my account, because a balance of is basically a mapping hashed by my account address. So if my storage, so if my validation rule allows me or for a Time Master, if I only own a specific nft, Auto token bus, you are allowed to access the storage uh State entities a and by stake by entities.

D

We extend it to all entities in the contract, not only pay masters, but also the factory and the uh in accounts and aggregators.

D

um They are allowed to access their own storage. They are still not allowed to access a arbitrary storage, but they are allowed to access their own and again, reference storage. Slash like the account storage so a token paymaster, for example, it can access its own storage and access the a account storage, which means it can move value from one to the other.

D

So this rule allows a having a token payment being whitelisted. Anyone can create such a a contract. Yes, it has to be staked, but again it's not something that we ever slash. It only validate that a the logic runs a really doesn't attempt to attack the system. A set of RPC apis send you. This operation was a there from the beginning, because this is the way to send the user operation.

D

We also added a equivalent user operation to the normal transaction, like you can estimate user percent gas which run your transaction and perform an estimation for all the gas parameters you need and you can receive it from the network. The user operation itself and its receipt and supported entry points is needed to understand whether you can work with the this bundle.

D

One of the features we added to this version is a support for aggregation. Aggregation means a there is an entity that a check holds a single, a signature for the entire bundle.

D

The flow become a bit different that immediately after validating a singular user operation, we validate the signature of a of data user operation, but just after collecting the all the user operation, we aggregate them using the aggregator and collect all the user operations and sorry all the signatures into one signature and the on chain. Just before running this bundle, we call this a signature aggregator to validate all these signatures.

D

uh This mode will be useful on l2s, where they CPU cost is far far cheaper than a cold data cost. So saving the size of a signature for each user operation will add greatly to the transaction. Lastly, something we walked away is that not only we created the reference bundler, we also created the spec tests. It's a set of python tests that a test a bundler to validate that it runs all these rules and that is compatible with each other. This is still a work in progress.

D

We are currently I believe seven bundler implementations all trying to make sure that there won't run production and be able to pass all these tests. This is still work in progress, but still adding a rules with this uh with the community.

D

So hopefully, soon we'll be able to release them, they only made it final warranty.

B

Of um yeah, so, regarding the bundle of spec test, uh there is a the reason. It's important is that there is now a work group in a with the EAP and the AP aims to have a main pool, and we did everything in order to make this future mempool uh secure against dos attacks, but they're.

B

But currently the the peer-to-peer protocol is not ready yet, and there is now a world group of bundlers of bundlers working on this protocol, but if they will, if they would be incompatible, uh if they apply the rules a bit differently, it would cause fragmentation, because then these bundles would not be able to talk to each other in the main pool, because they would not agree on the. They would not agree on the validity conditions of user operations.

B

So the purpose of this test is to enable having a having a unified mempool and then all the bundlers, all the bundles that pass the test know that they can be a part of fairies. Member so I think we covered all the we covered, all the changes we made, or at least all the major changes and I think if we have a if we have enough time, we can go through some questions.

A

Great presentation, nice talk. It is interesting to learn about the changes since we last talked addition of pay master and also the proposal provides. Security from dos attacks and attacks by malicious parties are good to have a unified vample glad to know the proposal is at a better position to be moved forward. I think we do have some questions for you, um maybe William. If you would like to start with the question you have yeah.

F

Sure that'd be great sure I wanted to ask a couple of questions specifically around simulation. um It could be. This is stuff that was covered previously um that year, since it seems like the focus here was more on changes 4337, um but in general, when looking at, like General on-chain transactions, oftentimes, one of the things that happens with simulation is that conditions change in between the time that the transaction is simulated and where it's executed, sometimes even in the same block.

F

You know I simulate, hitting a view function and then I throw in a transaction, but earlier in the block, something that changes the conditions happens.

F

um So what what have been your findings as to when simulation is useful and how useful it is, and also also I, I guess I should put on a little bit more to that, because it sounds like in 4337. There's a lot of effort being put in to make sure that the transactions that are getting executed are ones that have the exact same conditions that they were originally um originally simulated under, which also affects ux, though there are a lot of things that will be very hard to put 343.37 then.

F

um What's your approach to when simulation is useful and how it's useful and like, and what kind of a simulation is useful? Yes,.

D

When you talk about simulation, we talk about simulation of the validation. We are not simulating the entire section, because we don't care and the validation is covered, just the account validation to accept this transaction into the mempool. So it checks against replay. It checks that the signer of the transaction is allowed to perform the operation any check any pays for the gas. So if there are some execution-specific limitations, they don't have to fit into the what's with a simulate validation.

D

That said so, it doesn't really limit. It limits the validation to use storage specific to the account. Yes, the owner, the signature, the nons aura, things related to the account so the yes, there is a limitation I agree, not everything you will think of as a validation can fit in into a validate a user app. But everything that does relate to the acceptance of the owner or the rightful executor from this account is there.

B

So just to make it automatic concrete, since when we say simulation, we talk about validation simulation, it means that let's say you have a transaction. uh You haven't you you're, using an operation to perform a trade on a DEX, and maybe the trade will fail, because the price has changed. That's fine! It's that's! Fine! We don't care about it. We don't care. If this state has changed. The only state we care about is the state of the account meaning the nons, the keys.

B

So unless, unless somehow, the keys of your account has changed or the nonsense changed, then the rest of the state doesn't matter. It doesn't matter, fall simulation foreign.

C

An account can invalidate its own uh user operation by sending a transaction even without uh without the entry point, just direct it to the account uh it can invalidate its own user okay.

C

But what we wanted to keep to keep, then is that, in order to to invalidate this uh the user op, which can happen again and it it will only cost gas for the bundler, it will only cause the CPU usage once trying to include in a block okay in a bundle, and what we wanted to keep is that one change or one transaction with uh they can only cause like one esto, basically can only cause invalidation of a constant amount of user operation. It cannot invalidate uh like an arbitrary and number of these operations.

C

Now it is possible still to, as you said, if a transaction right inside a block like before before the bundle is executed, it can still invalidate it on chain, but that's why our bundlers basically need to walk closely to uh to Ace to a block, Builder or basically, for example, a service like like flash Watts or any kind of block wheel of the. Can that basically can guarantee that the transaction will not uh the the validity will not change between the simulation and the execution.

F

Got it got it um one more question for me: maybe before I hand it back to pucha um 4337 in addition to the actual EIP, the actual smart contract implementations. There's, probably more that we need to see before we can actually I would say, like you know, as looking from a user's perspective until a user is interacting with four with four three three seven.

F

um In addition to figuring out, you know the P2P protocol um the contracts, what additional tooling do you think that uh 4337 needs to actually be delivered to something? That's impacting dapps, that people are interacting with whether they know they're, interacting with it or not, and how far out do you think we are from tooling like that.

D

Like many wallets are trying to implement and support account obstruction, either solely for with account obstruction or, in addition to supporting UA accounts like I, think it's a new way type and in most cases application will work just the same with the yeah I can't obstructed accounts as they work with any other account.

D

That said, there are applications that don't work well with accounts. If you have an application that you fail to run a easily with glossy safe, it will probably uh be hard to use with the wallet that, based on the account abstractions. So there are a the first thing that they need to be done is a to have accounts, sorry to have wallet applications, so either browser extensions or a mobile applications that will work with account obstruction, and the next thing once there are such a wallets is educating applications to understand how to fix these issues.

D

These incompatibility issues, because again applications usually will not have to support account abstraction. They will have to support contract accounts and there are several others in the ecosystem and account obstruction goes into this category, and hopefully there will be many of them.

D

So it will help to to make them make the require the adaption to support such accounts. That said, after the application enough applications out there, there are some features of account, obstruction, of course, that application will be able to support. So once there is adoption, uh we want to see a tooling that we that will be defined somehow in communication, with the a wallet accounts like an application that want to use a specific pay. Master, like you, have an application that what to provide its own payment for these users, so it provides a payment.

D

So this requires an API between the application front, end to the wallet extension to provide a payment so to put into this request. So these are some things that need to be added later they and to Define standard for them between a standard API for them. Yeah.

F

If I I might not be understanding you right so I I'd like to just maybe try and work with an example, then um so I mean the first that you mentioned is wallet tooling.

F

That wallets will know how to enable users to have contract accounts kind of unlock the potential of those accounts, um so that would either be kind of like the current wallets in the ecosystem, or even completely new applications springing up based on 4337 styled accounts um when you're talking about the way applications kind of interface with 4337, I I, wasn't I, wasn't sure what you meant, though, do you mean like let's say we take something like ethers, which is a very commonly used library in JavaScript for interacting with the blockchain so a lot of times when there's a front end a lot of times it's using either ether's, JS or web3js to make calls to the chain to get the wallet to pop up for a transaction querying data.

F

Whatever the case is, um are you expecting the debt, like you know, as a developer, trying to develop up a front end for adapt? I I wasn't sure if you meant that you're expecting the same kind of functionality, that's used right now to get overloaded to also include four three three seven accounts so that as say, a JavaScript developer using ether's.

F

Maybe the ethers, implementer or implementers need to work like you know, behind the scenes to kind of overload functions to also include 4337, or are you expecting kind of new Dev tooling to spring up to kind of like, and how thoughtful do you expect at Dev at the other end of this to have to be about it? I.

E

D

F

That clear, I'm not sure I'm asking that clearly.

D

Yeah I think what I'm saying is that a wallet I expect wallet to provide a an API to provide a standard API and so that application will be able to continue and work just as they are and support account obstruction, uh so some applications will be able to use it. Some application requires new API uh like permit. Permit is something that you cannot do with a contract account. You need something else. So if you are want to swap tokens, you need some way to provide the the approval, then I think about contract account.

D

Is that in a single transaction you can do both approve and transfer, but you need a new API for that. So yes, for that, you will need tools, like authors, web 3 or external tool to be able to support a account obstruction uh for the basic functionality. Applications can a walk just with the a account and continue to work. So, yes, there is a need for tooling to support in order to support a some interesting scenarios like and we'll be able to have specific support for account obstruction. Of course, 467.

B

So um I will just I will just add that, uh regarding the uh regarding the adding support, adding support for 4337 for a for some development tools, uh we are working on adding this support. But it's a community effort. So uh so we expect that other projects will also help, and we also uh and uh in the film foundation, will also consider grants for uh uh for projects that adds up support to existing tools or developing uh new tools.

B

For this so uh feel free to reach out to us and I would love to support any such project.

A

Thank you. Thank you, William uh and yeah I'm talking about grants. I would just like to share this information that ethereum Foundation is currently considering grants. uh They have over one million dollars for education and tooling support. They have a wish list. So if anyone interested, they can probably um make their application before 27th of February um I have a few more questions here uh for the guests today.

A

In brief, if you have to say that what would be the main reason for motivation to change the approach of account abstraction, it seems like it is an extension to the earlier version. But what would you consider the main reason for the change.

B

Then the primary reason is that we wanted to move to keep improving the usability in the first version in the first version we we wanted to get something out, since it was already taking a long time. So we decided that so we decided to uh to put all the restrictions in playlist in order to keep it secure initially, because the next thing's relaxing security requirements is easier than adding them later from for compatibility reasons.

B

If someone develops a wallet that relies on a feature and later we have to take the picture away, because we discover a product of vulnerability that cannot allow it that's a problem, so we started with a more restrictive version and then the focus in this version was to uh was was to find ways to stay secure, while removing, while removing some of these restrictions.

B

So that's the that's the part and and beside that uh we walked a lot on uh adding on adding some new features, such as the signature aggregation, which is uh which initially we didn't consider, but it turns out to be uh to be important on the wall apps. In order to reduce the code, the L1 call data cost.

B

It is the primary cost for roll-ups, so we added the so we needed to add some of this and in general, we needed to make uh we it's going through a maturity process, so I think the EAP and the code is much more mature today than it was a year ago.

A

That sounds interesting, uh so is there a possibility of seeing some more sex changes to the current proposal? Maybe to add the signature aggregation.

B

So signature aggregation has already been added and we and we also have a sample aggregator for BLS signature, so this doesn't require additional changes, but uh but it's still, uh but it's still possible- that in the future, we'll add more We'll add more capabilities, whether whether it would be through the same ELC if it is a core part or more likely through a future elc's on top of it. So um so we're going to keep we're going to keep working on it.

B

This is not a this is not the last release, but it, but we are going to release it and make it uh make it possible for a for project to start using it to start using it and experimenting.

A

That's right uh from a proposal point of view, like from an EIP, slash, ERC, point of view. um It's a general recommendation that the smaller the proposal is that the greater chances it has to be um coming up as a final, like as a standard for Community to may be able to use. However, we can always keep proposing new changes which could be the extension of the present EIP.

A

So uh if we do not see anything like right now to be immediately getting in probably we can move this proposal from draft status to review status and other statuses, followed by a review.

B

Yes, so I think I think you are right. We shouldn't add any more functionality to this ELC and there are several functionalities, we're already considering, but will be added as separate ones.

B

However, uh before uh before trying to finalize ELC I think we would still want to collect some feedback into a and and to keep and to keep testing for a security even abilities so that when we decided when we decide to uh to set it as final, we know that it's really that the protocol is really secure, I think we say I, think uh and since we are also not in a rush uh not in a rush to get there, because since it's not uh since it doesn't require consensus change, there is no hard Fork Nothing Stops the community for uh for you from using it right now.

B

So uh so I think it's okay to take a little bit more to make sure that it's really secure before finalizing.

A

Absolutely absolutely that's a very good idea to have uh the Assurance of sending out a proposal to the community when we are confident that it is safe to be used when it comes to uh wallet, specific use cases. However, uh the present status of this proposal is draft. So draft is something like when proposal is in very early stages and it's not ready for even getting the implementation uh like uh it's not ready for project. So recently, what we have done is like.

A

We have started sharing warning messages along with the proposal uh depending upon the status as it is so for a proposal in drug. It is like in very early stages, even not ready for review, but it seems like this is already ready for review a lot of things going on in the background lot of implementers. Are there so I probably think that it would be good to have it in review, so we get more eyes to it.

A

Even EIP editors will pay extra attention and when we move from review to the last call last call is the duration where it stays for 14 days and there we get the final feedback. So obviously we can move to the review, I think and we'll keep it there for some more time till authors get confidence and then move it to the last call.

B

Why thank you yes, so uh so we should consider that that makes sense.

A

That would be great, so we generally try to push proposal to move to the final status. Obviously, when authors are comfortable, so we can start promoting that EIP to the community to be implementing in their projects before it reaches to the final status. There is always a message that it is not fully ready to be implemented in the project and because um I am aware that many wallets have started implementing this, so yeah I think it's a good idea to keep it moving.

B

A

All right uh talking about uh the security and the confidence that we would need. I have heard about uh an audit, an external audit for this particular proposal. If you would like to take a few minutes and talk about what were the important features for consideration and were there any significant recommendation from the audit team.

B

um Yes, so uh so they so uh the latest version is, uh is going through an audit. It's actually a finishing finishing the audit now and there are no way there are no critical findings. We did make some. We did make some changes to accommodate the commodity things that came up during the audit, but nothing, nothing, critical and the focus is on.

B

The focus has been on both the contract security to make sure that uh that wallets, that use it are safe and also on the mempool security on preventing dos attacks, so uh so the auditor. So the auditor spent a lot of time. Thinking about such attack, vectors ways to cause massive validations, so I think uh I think that's pretty much it the door. Was there anything any other Focus that you think we should mention yeah.

C

No I think you covered it pretty much. What we obviously uh put emphasis. The most was the core contracts and they there were no critical or high severity, even issues on in there, and only some some issues on on our samples that we already addressed and yeah so and that's it. We are currently finishing our security audit.

A

That is good to know like when anything related. Any proposal dance comes up with an audit. It always gives more Comfort to implement it as well as to the end user. So all the best I hope that it goes with like um good result and no more further changes needed for the original specs.

B

But I would I would add regarding the audit, despite us having the spine. Despite having the protocol, the contacts audited I think that any any wallet developer any wallet developer that relies on it should also be audited and should take our contracts into into account, because you know the more uh the more the more eyes on the crow, the better so I would urge. I would urge anyone who develop something on top of our contracts, to also uh to also audit.

A

Yeah, that would be even better um any project like any D5 project, if that is audited by a third party to ensure that it is uh properly done on contract level, uh that is additional layer of security that we are providing to users yep um two more questions.

A

um One is related to the backward compatibility and changes with future ethereum proposals.

A

um So the EAP suggests that the proposal does not have any issues of backward compatibility for ethereum as a whole because it is not changing any anything at the core level, but unfortunately it is not easily compatible with pre uh 4337 accounts. Is there a workaround for projects to resolve this issue of incompatibility.

B

uh In what sense is it not compatible with existing accounts? Okay with EOS the.

D

Only thing it isn't compatible with the EOS is that EOS can't easily become a account obstructed because they are not contracts. That's true, eoa is currently uh bound to be an eoa.

D

Yes, we are thinking, and we have in the pipeline some work to try to enshrine it the 4327 into the protocol and eventually add a way to convert existing EOS into account obstructed. This is a very early work and there are many many issues regarding it regarding cross chains and other aspects. We don't have any conclusion about that. I cannot say that it will happen anytime soon or if at all, we do want it to be able to be a heavier though yes,.

A

All right, not a problem, um I'm I'm sure that there is another similar proposal like not exactly the account abstraction, uh but the eap3074 ought an article art call op code. So it's another popular proposal for like wallet and um part of it is also helper for account obstruction. Do you see the wallet supporting four three three seven will be compatible with EAP 3074. If that is approved on core protocol level and Future.

D

No I I it's these are first of all, they are not contradictory. Second of all, they are not. They are not a kind of abstraction, the main feature of a kind of section. They don't do. They aim at a gas obstruction and they have some cool feature for that. But and actually, if and when uh 30 74 gate accepted, it will allow working slightly cheaper uh four through seven accounts, they can work together, but it is not required because uh you have a look preservation about it and.

B

I think I mean I, know myself my reservations about it were a security related. They were not related to account obstruction, but actually having said that, if, if a chain has a EAP 3074, then it becomes, then it actually becomes easier to to implement the ELC 457 accounts because uh it would be, it would become easier to become easier for an existing eoa to refer to this code. So I'm I, don't think we'll have the time to to dive into the pros and cons of this approach right now, but it could actually be used.

B

So there will be some interesting use cases on a chain that uh on a chain that supports this EAP. So um so, if, uh if it is, uh if it is merged, we would love to explore it to explore this. uh uh The Synergy between the two.

A

That is good to know. I mean like if a proposal which is proposed in future may be becoming a part of etm minute is going to help the existing proposal. That is at an added Advantage for implementers for the proposal. 4337..

A

um One final question related to the Future compatibility is about the uh deactivation of self-destruct, like it is a proposal for future consideration of blockchain. Do you think it will make any effect to uh projects who have already implemented 4337.

B

Yes, it will make our life easier. We really we don't like this op code, I, think few people do uh so selfish. uh Many of the attack vectors. We had to mitigate our deal to a audio to self-destruct, whether it happens during validation, which, of course, we banned. So we had to ban the op code. So in that sense, uh in that sense, uh the competitor there is no compatibility.

B

There can't be a compatibility issue around it, because the EAP already bans the use of self-destruct during validation, but it's, uh but we had to take into account attacks where the code of an account changes between the first and the second simulation, for example, or some Library, as some Library gets self-destructed. So a lot of mitigations were put into place and the bundler has to implement them in order to uh in order to protect itself against the self-destruct attacks.

B

So once it's removed the once it removed the bundlers can become simpler. We can just remove some Security checks.

A

So we are already getting more support to the deactivation of self-destruct proposal. Oh yeah good, to know all right, it's time to wrap up. Is there anything that you would like to add or share with the EIP implementers or the ethereum community in general? No.

B

I, don't think so.

A

Very well I think the presentation and the question and answer session has already covered most of the important aspects related to this proposal and we hope to see uh the audit result and the testing the build respect testing that is currently in progress uh to get it completed and we'll be happy to move. uh This proposal to the next status.

A

Eip4337 defines the RPC and protocol used by users and nodes to communicate and make sure user operations are decentralized as normal ethereum transaction. It is a useful feature for decentralized projects to provide flexibility, to wallet, depth and end users, with many advantages being brought to wallet developers related audit. Duns I see this proposal to be in a place to be moved towards final.

A

Thanks for joining us today to talk about account, abstraction eip4337 and its future plan, I suppose that's helpful for many hackathon participants and projects considering implementation of this proposal, and on this note, thanks to everyone watching or listening to this episode, should you have any question. Let us know in the form available in description or leave a comment or reach us at this Discord check out description for link to useful resources and guest Twitter to follow we'll be back with another interesting ethereum topic, so stay tuned and keep sharing your love with ethereum Caterers cheers.

A