ERC4337 Support

[orkunkilic]

We should implement ERC4337 before the mainnet launch. I don’t think it will require much work, and it likely won’t affect the zkVM guest. In Ethereum, this is not a hard fork but a node update. The implementation simply adds new optional fields to the send transaction RPC and introduces another mempool for user_ops transactions. More details can be found in the link provided above. Reth already implements the necessary types for ERC4337.

We should convert this discussion into an issue or issues. I’ll leave that to you after the initial design research.

[eyusufatik]

From what I understand we don't really have to implement much if we want to support ERC4337. Since all the work (and RPCs) is handled at the bundler level. (You can search reth and geth for eth_sendUserOperation, nothing will show up)

Seems like the only thing we are missing is debug_traceCall with JS tracer support.

[orkunkilic]

Not all - we need to implement some stuff on the sequencer level (such as accepting user txs and a seperate mempool for them). Having said that - we should first decide whether we want 4337 or native AA. They have different trade-offs. Let's discuss this week.

[orkunkilic]

Reth and Geth by default not implemented 4337 - yet

[eyusufatik]

Not all - we need to implement some stuff on the sequencer level (such as accepting user txs and a seperate mempool for them)

even those are handled at the bundler level

https://github.com/eth-infinitism/bundler

https://github.com/stackup-wallet/stackup-bundler

I mean I guess the sequencer can also make these program's work too, but we can just set up one of these and be done with it. -- we just need to add support for JS tracer for debug_traceCall.

we should first decide whether we want 4337 or native AA

https://dune.com/niftytable/account-abstraction

unfortunately 4337 usage does not seem to be great...

the hard way, native AA, seems like a better aproach :p