I’ve been working on PrepaidGas, a decentralized, ZK-powered paymaster, and have identified a potential issue while implementing the decentralized paymaster solution. I’d appreciate your thoughts on:
The Challenge: DDoS Vector against Bundlers (without fund loss) When a user effectively acts as their own paymaster service (as in our decentralized model), a malicious actor could theoretically spam bundlers simultaneously with the same valid gas ticket (i.e., a UserOperation with a valid ZKP and paymaster context).
- Result: Bundlers would successfully validate these identical
UserOps(as the ZKP is initially valid), but only the first one to hit the chain would successfully execute (e.g., consuming the nullifier). The subsequent ones would fail during execution. - Impact: While no funds are lost from the paymaster, this wastes significant bundler resources. It’s akin to the
UserOperationnoncepreventing account-level replays, but there’s no equivalent “paymaster nonce” for such concurrent spam. This could damage the paymaster’s reputation and lead to bundlers deprioritizing or censoring itsUserOps.
Why a Solution is Important (and respects separation): I believe introducing a mechanism like a “paymaster nonce” within the UserOperation could mitigate this. This wouldn’t violate the Bundler-Paymaster separation; it would simply be:
- Bundler Infrastructure Protection: A crucial anti-spam primitive for bundlers, protecting their vital infrastructure.
- Enabling Decentralized Paymasters: It would empower truly decentralized paymaster models like PrepaidGas to operate robustly without relying on centralized off-chain components solely for anti-spam.
I’m keen to hear any concerns or thoughts on this. Is this something already considered, or are there existing ideas/solutions in the pipeline for such scenarios without a centralized party?