Bundler support

[dcposch]

Goal

Make it easy for any app or wallet to use bundle compression.

Prototypes

Prototyping with Pimlico. If all goes well, this new API endpoint would eventually become an eth_... endpoint proposed via ERC.

V0

pimlico_sendCompressedUserOperations. Takes a complete compressed bundle, passes to BundleBulker

(So the bundler is not bundling, just forwarding--but useful to test integration.)

V1 / Option A

This lets you bundle compressed ops from multiple users into a single compressed bundle.

• pimlico_sendCompressedUserOperations
  • input: CompressedOp[], where each op is {"opInflatorAddr":"0x...", "compressedOp":"0x..."}
  • output: op hashes, + optionally the containing bundle tx hash
  • suggested semantics...
    • loop thru ops
      • inflate each one calling the provided opInflatorAddr.
      • validate op using normal op validation
      • get inflator ID from Pimlico's PerOpInflator by calling inflatorToID(opInflatorAddr)
      • ...if inflatorID is 0, register the op inflator on your PerOpInflator first
    • finally, submit a bundle to BundleBulker

Whenever you want to change your beneficiary address, set the beneficiary on your PerOpInflator.

If you ever observe a submitted bundle revert (and rule out bundler errors such as not passing enough gas), it means one of the inflators changed its behavior between (validation offchain call to inflate) and (onchain submit) a second or two later.

Could temporarily flag/block API users that do this.

V1 / Option B

Same as above, but with a pimlico_sendCompressedUserOp singular. (If sending multiple ops, user just calls more than once.)

Separately, as an optimization, it's possible to do the inflator-registering and bundle-submitting in a single atomic multicall.

V1 / Option C

User is responsible for registering their own IOpInflator with bundler's PerOpInflator ahead of time. Then,

• pimlico_sendCompressedUserOp(uint256 opInflatorId, byte[] compressedOp)
  • as above, but skip the steps related to registering an op inflator
  • instead, just look up an existing op inflator via idToInflator(opInflatorID), then use its inflate(), then validate the resulting UserOp

[mouseless0x]

Looks good! Options A & B have a much cleaner api interface, personally I would lean more towards them. Much better to let the bundler/compressor-endpoint handle registration of inflators, this also means less work/overhead for the people that want to use the endpoint.

"Separately, as an optimization, it's possible to do the inflator-registering and bundle-submitting in a single atomic multicall." this is a interesting observation on your end, very useful property.

Curious to hear your thoughts on Issue #4 (Make a compress view function for each inflator), if done correctly the implications would mean that you can send uncompressed UserOp/s to the bundler and the bundler can compress the request before sending it to the BundleBulker. This is even less overhead/templating on the users/dapps end as they no longer need to self compress their userOps.

Extending on issue #4:

Would it make sense to let the BundleBulker handle compression/decompression of common fields like sender, maxFeePerGas, maxPriorityFeePerGas, and nonce_key. This reduces code copy across each inflator implementation. This also means that each inflators just needs methods to handle the compression/decompression of calldata, signature, and paymaster.

Although going this route does kill composability as a template is forced onto users that want to use the BundleBulker.

[dcposch]

• A/B sounds good to me. B matches the 4337 standard eth_sendUserOperation API call, so I'd lean toward that.
• Idea: Make a compress view function for each inflator #4 might be a nice implementation choice for many IOpInflators, but I would definitely recommend having the API take compressed ops. Fewer moving parts, and leaves it optional.
• Valuable for BundleBulker to stay very simple & unopionated. In our prototype so far, we get a lot of mileage out of eliminating fields entirely in the compressed representation, then templating them in with constants. I don't think there's a one-size way to handle these. See for example: https://github.com/daimo-eth/daimo/blob/master/packages/daimo-api/src/network/bundleCompression.ts#L47-L135

...however, we could write a generic IOpInflator that's a reasonable default for a lot of apps. This would make it easy for other apps to adopt compression.

[dcposch]

V1 / Option D

Shipping:

pimlico_sendCompressedUserOperation(
   compressedCalldata, // hex bytes
   targetOpInflatorAddress, // hex address
   entryPointAddress // hex address
)

Returns userOpHash, or a descriptive error message.

For now, user registers their IOpInflator ahead of time.