Merge pull request #403 from eth-infinitism/rep-rules-fix

Fixing reputation rules

erc/ERCS/erc-7562.md

@@ -171,6 +171,8 @@ There are two types of rules:
 | `INCLUSION_RATE_FACTOR`              | 10                          |                                                                                 |
 | `THROTTLING_SLACK`                   | 10                          |                                                                                 |
 | `BAN_SLACK`                          | 50                          |                                                                                 |
+| `BAN_OPS_SEEN_PENALTY`               | 10000                       |                                                                                 |
+| `MAX_OPS_ALLOWED_UNSTAKED_ENTITY`    | 10000                       |  
 
 ### Validation Rules
 
@@ -317,19 +319,24 @@ Local storage rules protect the bundler against denial of service at the time of
   This means that `Paymaster` and `Factory` contracts cannot practically be an "account" contract as well.
 * **[STO-041]** `UserOperation` may not use associated storage (of either its account or from staked entity) in a contract that is a "sender" of another UserOperation in the mempool.
 
-### Staked Entities Reputation Rules
 
-* **[SREP-010]** The "canonical mempool" defines a staked entity if it has `MIN_STAKE_VALUE` and unstake delay of `MIN_UNSTAKE_DELAY`
-* **[SREP-020]** A `BANNED` address is not allowed into the mempool.\
+### General Reputation rules
+The following reputation rules apply for all staked entities, and for unstaked paymasters. All rules apply to all of these entities unless specified otherwise.
+
+* **[GREP-010]** A `BANNED` address is not allowed into the mempool.\
   Also, all existing `UserOperations` referencing this address are removed from the mempool.
-* **[SREP-030]** A `THROTTLED` address is limited to:
+* **[GREP-020]** A `THROTTLED` address is limited to:
     * `THROTTLED_ENTITY_MEMPOOL_COUNT` entries in the mempool.
     * `THROTTLED_ENTITY_BUNDLE_COUNT` `UserOperations` in a bundle.
     * Can remain in the mempool only for `THROTTLED_ENTITY_LIVE_BLOCKS`.
-* **[SREP-040]** An `OK` staked entity is unlimited by the reputation rule.
+* **[GREP-040]** If an entity fails the bundle creation after passing second validation, its `opsSeen` set to `BAN_OPS_SEEN_PENALTY`, and `opsIncluded` to zero, causing it to be `BANNED`.
+
+### Staked Entities Reputation Rules
+
+* **[SREP-010]** The "canonical mempool" defines a staked entity if it has `MIN_STAKE_VALUE` and unstake delay of `MIN_UNSTAKE_DELAY`
+* **[SREP-020]** An `OK` staked entity is unlimited by the reputation rule.
     * Allowed in unlimited numbers in the mempool.
     * Allowed in unlimited numbers in a bundle.
-* **[SREP-050]** If a staked entity fails the second validation or fails bundle creation, its `opsSeen` set to `10000`, and `opsIncluded` to zero, causing it to be `BANNED`.
 
 ### Entity-specific rules:
 
@@ -342,17 +349,17 @@ Local storage rules protect the bundler against denial of service at the time of
 * **[EREP-030]** A Staked Account is accountable for failures in other entities (`paymaster`, `aggregator`) even if they are staked.
 * **[EREP-040]** An `aggregator` must be staked, regardless of storage usage.
 
-### Unstaked Entities Reputation Rules
+### Unstaked Paymasters Reputation Rules
 
 * Definitions:
     * **`opsSeen`, `opsIncluded`, and reputation calculation** are defined above.
     * `UnstakedReputation` of an entity determines the maximum number of entries using this entity allowed in the mempool.
     * `opsAllowed` is a reputation-based calculation for an unstaked entity, representing how many `UserOperations` it is allowed to have in the mempool.
-* **[UREP-010]** An unstaked sender is only allowed to have `SAME_SENDER_MEMPOOL_COUNT` `UserOperation`s  in the mempool. A staked sender is only limited by the SREP rules.
-* **[UREP-020]** For other entities: \
-  `opsAllowed = SAME_UNSTAKED_ENTITY_MEMPOOL_COUNT + (inclusionRate * INCLUSION_RATE_FACTOR) + (min(opsIncluded, 10000)`.
-    * This is a default of `SAME_UNSTAKED_ENTITY_MEMPOOL_COUNT` for a new entity
-* **[UREP-030]** If an unstaked entity causes an invalidation of a bundle, its `opsSeen` is set to `1000`, effectively blocking it from inclusion for 24 hours.
+  * Rules:
+    * **[UREP-010]** An unstaked sender is only allowed to have `SAME_SENDER_MEMPOOL_COUNT` `UserOperation`s  in the mempool. A staked sender is only limited by the SREP rules.
+    * **[UREP-020]** For an unstaked paymaster only that is not throttled/banned: \
+      `opsAllowed = SAME_UNSTAKED_ENTITY_MEMPOOL_COUNT + inclusionRate * min(opsIncluded, MAX_OPS_ALLOWED_UNSTAKED_ENTITY)`.
+    * This is a default of `SAME_UNSTAKED_ENTITY_MEMPOOL_COUNT` for new entity
 
 ### Alt-mempools rules:
 
@@ -362,7 +369,7 @@ The alt-mempool "topic" is a unique identifier. By convention, this is the IPFS
 * **[ALT-010]** The bundler listens to the alt-mempool "topic" over the P2P protocol
 * **[ALT-020]** The alt mempool rules MUST be checked only when a canonical rule is violated
     * That is, if validation follows the canonical rules above, it is not considered part of an alt-mempool.
-*  **[ALT-021]** Such a `UserOperation` (that violates the cannonical rules) is checked against all the "alternate mempools", and is considered part of all those alt-mempools 
+*  **[ALT-021]** Such a `UserOperation` (that violates the canonical rules) is checked against all the "alternate mempools", and is considered part of all those alt-mempools 
 * **[ALT-030]** Bundlers SHOULD forward `UserOperations` to other bundlers only once, regardless of how many (shared) alt-mempools they have. \
   The receiving bundler validates the `UserOperations`, and based on the above rules (and subscribed alt-mempools) decides which alt-mempools to propagate it to.
 * **[ALT-040]** opsInclude and opsSeen of entities are kept per alt-mempool. That is, an entity can be considered throttled (or banned) in one mempool, while still active on another.
@@ -373,7 +380,7 @@ Alt-mempools are served by the same bundlers participating in the canonical memp
 
 * **[AREP-010]** each alt-mempool manages "opsSeen" and "opsIncluded", much like entities. The opsSeen is incremented after `UserOperation` initial validation, where it is considered part of this mempool.
     The "opsIncluded" is incremented after this UserOperation is included on-chain (either by this bundler, or another)
-* **[AREP-020]** the alt-mempool becomes THROTTLED based on the [Reputation Calculation](#reputation-calculation) 
+* **[AREP-020]** the alt-mempool becomes THROTTLED based on the [Reputation Calculation](#reputation-calculation)
 
 ## Security Considerations