Potential attack from staked account for token paymaster
huaweigu opened this issue · 3 comments
Terminology
account - a smart contract wallet usually hold by the user
Scenario
Two userOps from the same sending account are in the same bundler. 1st userOp is trying to withdraw all the token from the sender.
During a discussion with 4337 team (@drortirosh @yoavw @shahafn ), we found that if the sending account is staked with entry point contract, there's a chance that paymaster could get attacked by that staked account. For example, the bundler could accept two userOps from the same account (if they're staked), both userOps would pass the 1st simulation before they're added into mempool. However, the 2nd validation (before bundling) would potentially revert when 2nd userOp is being validated.
Even if the paymaster exit via sigFailed via a hacky way of handling attack, the code would still revert.
(note: the real sigFailed would fail in 1st simulation)
Both reverts would attribute the fault to paymaster, so paymaster could potentially get banned by the bundler's reputation system.
Theoretically, paymaster could build its own reputation system just like bundler service to prevent the account from using it again, but we're also wondering if the entry point/bundler could do something to prevent the account from using paymaster again, e.g. by allowing graceful exit from paymaster for certain reason code.
Staked accounts are a seldom used use case. And since the account is staked and has a reputation, it can be blamed for the failure instead of the paymaster. It'll be the staked account's responsibility to defend its reputation against malicious paymasters by either blocking paymasters altogether (require(op.paymaster==address(0))) or by maintaining a whitelist of trusted paymasters.
TL;DR: we should add a reputation rule for staked accounts, assigning the blame of any failure to the account itself.
Staked accounts are a seldom used use case.
Shouting out that as an implementer i'm pursuing an idea that relies on staked accounts. was talking with @shahafn about it recently. i'd like to know whether multiple userOps from same sender in same bundle will be possible or get deprecated.
Staked accounts will be able to send multiple UserOps in the same bundle. It's not getting deprecated. The only change is that they'll be responsible for invalidations even if they happen in a paymaster, so your account should restrict the use of paymasters to only whitelisted ones. Otherwise an authorized-but-malicious user could use a malicious paymaster to get your account throttled. If all the users of the account are trusted, there's no risk.