erc-7562.md - define "accountable"

[drortirosh]

add a definition for the term "accountable", used in some EREP rules...

[yoavw]

"Accountable" only applies to banning, and not throttling cases? According to this definition a paymaster that returns "valid" for two UserOps separately and then causes a bundle revert, it is "accountable" but a paymaster that just causes a UserOp (or any number of UserOps) to become invalid separately after being valid in 1st simulation (e.g. by flipping a flag in its own storage) is not "accountable". Is that the intention here?

[drortirosh]

there are 2 separate mechanisms

1. opsSeen/opsIncluded on every entity in the userop, that collects "reputation" over time. over a long time, too many opsSeen (w/o opsIncluded, for whatever reason) eventually throttle and ban the entity.
   1a. special case for PM [EREP-015]: its opsSeen is not included for any 2nd validation failure caused by account/factory
2. [GREP-040] Direct ban, by failing bundle creation (which sets opsSeen=10000, opsIncluded = 0 - a ban for few days)

the question: are there any other case?

[yoavw]

I think these are currently the only cases. My question was about the "accountable" definition. Is an entity accountable for any invalidation it causes, or only for the 2nd case?

[drortirosh]

• the original idea was to manage opsSeen/opsIncluded separated for each entity, regardless of who caused the error (as in some cases, we couldn't really tell)
• then we added a specific rule (EREP-015) for paymaster
• maybe we should try to do it for other entities too. That is: with "accountable" entity, we "undo" the increment of other entities.

the flow:

• sendUserOp: increase opsSeen count for sender, paymaster, factory
• 2nd validation: depending on staked entity and error cause, undo some opsSeen (need to create a table...)
• createBundle: if crashes, perform the opsSeen undo above, but also ban the offending entity.

[drortirosh]

is this correct?

• when adding a UserOp, increase opsSeen of all entities
• when handling 2nd validation error:
  • when an error is in factory or account, undo the pm opsSeen

In the table below:

• n/a - impossible cases
• There is always "blame": if not in table, then its current column
• (can't have both factory and sender staked)

staked:	AA1 fact	AA2 acct	AA3 pm
no fact, no stake	n/a	undo PM
no stakes	undo PM	blame fact undo PM
fact	undo PM	blame fact undo PM
acct	n/a	blame acct undo PM	blame acct
fact + pm	undo PM	blame fact undo PM
acct + pm	n/a	undo PM

[drortirosh]

@yoavw , @shahafn , @forshtat - comments?