A place for talking about the Ethereum Virtual Machine on Farcaster.

We really need to come to a standard on how bundlers simulate transactions for account abstraction.

It’s critical for features like pay fee in ERC20 that open up new models into tokenomics.

The ethereum foundation won’t take a stance on this. A leader must rise up to this challenge.

I’m not sure I understand. What do you see as missing with the current 4337 bundling spec https://eips.ethereum.org/EIPS/eip-4337#bundling. What’s missing from the bundler implementations we have today like alto https://github.com/pimlicolabs/alto and voltaire https://github.com/candidelabs/voltaire?

Working on building products with zkTLS, and subverting web2 systems by encouraging client diversity. A ruthless empiricist.

http://opacity.network

https://hackmd.io/@Vid201/aa-bundler-rust

Take a look at the write up for this implementation of AA.

Building pods.media to help you collect conversations.

I don’t get the issue though: why does simulation need more standards? UserOps are valid or they aren’t. Why do you say there’s an issue with ERC20 paymasters?

I never said there was an issue. Just that there needs to some better standards for the bundler layer to take off.

I never said there was an issue. Just that there needs to some better standards for the bundler layer to take off.

https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists

Refering to this quote:

> For a user operation, there must be a defined way to validate the operation, and a defined way to execute the operation, such that if an operation is validated, an attempt to execute it is guaranteed to pay fees, unless the state that was read during validation is modified.

Sorry, I still don't get it. Isn't the standard "call the verifyUserOp function"
The eip makes sure the function cannot access opcodes which are related to time or can change state

20. hacking @ https://www.spire.dev/ 
previously intern Nethermind, epns.io

For signature aggregation, a bundler would have to:

1. Validate UserOps in the mempool
2. Aggregate UserOps that support BLS
3. Revalidate the aggregated signature bundle UserOps

If #3 fails it becomes annoying from a system design perspective.

There’s a lot of room for a malicious SCW to mess with bundlers.

Yeah, but I think it’s too generic for the vision of AA. Take supporting aggregated BLS signatures (mentioned a lot because it offers gas optimizations).

You can only aggregate it if the SCW supports BLS keys.