Is "front running the factory deployment" an issue?

[Amxx]

I realized that the entrypoint implemented in this repo will fail if a useroperation includes an initCode and if the sender is already deployed.

That means that a userOperation will be seen as valid, and will be propagated in the network, until someone potentially frontruns the deployment (by calling the factory directly). This will invalidate the userOperation. This would cause handleOps or even handleAggregatedOps to revert, if the frontrunning happens while the userOperation is beeing relayed.

Wouldn't it be better to ignore the any initCode if the sender is already deployed? Are we worried that the initCode present in the userOperation might result in a different account then the one deployed at the sender's address?

[drortirosh]

1. handleOps shouldn't be used with a public mempool at all. From day 1, a bundler is considered an extension to a block-builder, and should run on a 1-1 connection with it.
   While it is possible to run a bundler with the public mempool because ERC4337 is not an EIP, and runs on top of existing transactions - it can't be economically feasible. Once private channels are available to get included directly (flashbots, fastlane) they will be used.
   (bundlers already told us that if they accept transaction with a minimal gain - even cents - they get front-ran...
2. The only "gain" someone gets from front-running a transaction and executing the initCode is philantropic - paying the deployment gas to the account, so that its next transaction can just use it.
3. The reason we don't "simply ignore" initcode, is to let us know statically - simply from the content of the UserOpration itself - the flow this transaction took, without looking at the current network state.
4. Lastly, we're always thinking with "future compatibilty" with native AA: I think you'd agree that a native AA transaction that creates an account shouldn't "simply ignore" the creation code if it already exists. We wanted accounts deployed with ERC-4337 to have the same flow as such future native AA accounts, so simplify an upgrade.

[Amxx]

So if I understand correcly the answer is :

There should not be any frontrunning possibility between the second verication and the bundle transaction being included, because the bundle transaction should be included directly by the bundler (that is also a builder), without going through the "normal" transaction mempool.

Is that correct?

[drortirosh]

yes, exactly. If there is a public mempool, then the frontrunning is a problem not only for deployment UserOps, but for all UserOps.