You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`MIN_UNSTAKE_DELAY`| 86400 | 1 day, which provides a sufficient withdrawal delay to prevent most sybil attacks |
61
+
|`MIN_STAKE_VALUE`| Adjustable per chain value | Equivalent to ~$1000 in native tokens, which provides a sufficient capital requirement to prevent most sybil attacks |
62
+
|`SAME_SENDER_MEMPOOL_COUNT`| 4 | Maximum number of allowed userops in the mempool from a single sender. |
63
+
|`SAME_UNSTAKED_ENTITY_MEMPOOL_COUNT`| 10 | Maximum number allowed in the mempool of UserOperations referencing the same unstaked entity |
64
+
|`THROTTLED_ENTITY_MEMPOOL_COUNT`| 4 | Number of `UserOperations` with a throttled entity that can stay in the mempool |
65
+
|`THROTTLED_ENTITY_LIVE_BLOCKS`| 10 | Number of blocks a `UserOperations` with a throttled entity can stay in mempool |
66
+
|`THROTTLED_ENTITY_BUNDLE_COUNT`| 4 | Number of `UserOperations` with a throttled entity that can be added in a single bundle |
67
+
|`MIN_INCLUSION_RATE_DENOMINATOR`| 100 (client) \ 10 (bundler) | A denominator of a formula for entity reputation calculation |
68
+
|`THROTTLING_SLACK`| 10 | Part of a reputation formula that allows entities to legitimately reject some transactions without being throttled |
69
+
|`BAN_SLACK`| 50 | Part of a reputation formula that allows throttled entities to reject some transactions without being throttled |
70
+
|`BAN_OPS_SEEN_PENALTY`| 10000 | A value to put into the opsSeen counter of entity to declare as banned |
71
+
|`MAX_OPS_ALLOWED_UNSTAKED_ENTITY`| 10000 ||
72
+
|`PRE_VERIFICATION_OVERHEAD_GAS`| 50000 | Gas used by the `EntryPoint` per `UserOp` that cannot be tracked on-chain |
73
+
|`MAX_VERIFICATION_GAS`| 500000 | Maximum gas verification functions may use |
74
+
|`MAX_USEROP_SIZE`| 8192 | Maximum size of a single packed and ABI-encoded `UserOperation` in bytes |
75
+
|`MAX_CONTEXT_SIZE`| 2048 | Maximum size of a `context` byte array returned by a paymaster in a single `UserOperation` in bytes |
76
+
|`MAX_BUNDLE_SIZE`| 262144 | Maximum size of an ABI-encoded bundle call to the `handleOps` function in bytes |
77
+
|`MAX_BUNDLE_CONTEXT_SIZE`| 65536 | Maximum total size of all `context` byte arrays returned by all paymasters in all `UserOperations` in a bundle in bytes |
78
+
|`VALIDATION_GAS_SLACK`| 4000 | An amount of gas that must be added to the estimations of `verificationGasLimit` and `paymasterVerificationGasLimit`|
74
79
75
80
### Validation Rules
76
81
@@ -98,6 +103,8 @@ Thus, The bundler that sent the violating UserOperation should not suffer a p2p
98
103
2. The slot value was calculated as `keccak(A||x)+n`, where `x` is a `bytes32` value, and `n` is a value in the range 0..128
99
104
6.**Using an address**: accessing the code of a given address in any way.
100
105
This can be done by executing `*CALL` or `EXTCODE*` opcodes for a given address.
106
+
7.**Spammer** - a P2P peer bundler that attempts a DoS attack on the mempool by sending other peers with a large number of invalid UserOperations.
107
+
Bundlers MUST detect and disconnect from such peers, as described in the [Mempool Validation Rules](#mempool-validation-rules) section.
101
108
102
109
### Reputation Definitions
103
110
1.**opsSeen**: a per-entity counter of how many times a unique valid `UserOperation` referencing this entity
@@ -108,7 +115,7 @@ Thus, The bundler that sent the violating UserOperation should not suffer a p2p
108
115
appeared in an actual included `UserOperation`. \
109
116
Calculation of this value is based on UserOperationEvents and is only counted for `UserOperations` that were
110
117
previously counted as `opsSeen` by this bundler.
111
-
3. Both values are updated every hour as `value = value * 23 // 24`\
118
+
3.**Refresh rate**: Both of the above values are updated every hour as `value = value * 23 // 24`\
112
119
Effectively, the value is reduced to 1% after 4 days.
113
120
4.**inclusionRate**: Ratio of `opsIncluded` to `opsSeen`
114
121
@@ -125,7 +132,7 @@ The reputation state of each entity is determined as follows:
125
132
126
133
Note that new entities start with an `OK` reputation.
127
134
128
-
To help make sense of these params, note that a malicious paymaster can at most cause the network (only the p2p network, not the blockchain) to process `BAN_SLACK * MIN_INCLUSION_RATE_DENOMINATOR / 24` non-paying ops per hour.
135
+
Because of the reputation `refresh rate`, note that a malicious paymaster can at most cause the network (only the p2p network, not the blockchain) to process `BAN_SLACK * MIN_INCLUSION_RATE_DENOMINATOR / 24` non-paying ops per hour.
129
136
130
137
### Running the Validation Rules
131
138
@@ -257,13 +264,17 @@ The following reputation rules apply for all staked entities, and for unstaked p
257
264
* Bundler should not accept a new `UserOperation` with a paymaster to the mempool if the maximum total gas cost of all userops in the mempool, including this new `UserOperation`, is above the deposit of that `paymaster` at the current gas price.
258
265
***[EREP-011]** REMOVED
259
266
***[EREP-015]** A `paymaster` should not have its opsSeen incremented in case of a failure of factory or account
260
-
***[EREP-016]** An `aggregator` should not have its opsSeen incremented in case of a failure of factory, account or paymaster
261
-
* When running 2nd validation (before inclusion in a bundle), if a UserOperation fails because of factory or account error (either a FailOp revert or validation rule), then the paymaster's opsSeen valid is decremented by 1.
267
+
* When running 2nd validation (before inclusion in a bundle), if a UserOperation fails because of factory or account error (either a FailOp revert or validation rule), then the paymaster's opsSeen valid is decremented by 1.
268
+
***[EREP-016]** An `aggregator` should not have its opsSeen incremented in case of a failure of a factory, an account or a paymaster
269
+
* When running 2nd validation (before inclusion in a bundle), if a UserOperation fails because of a factory, an account or a paymaster error (either a FailOp revert or validation rule), then the aggregator's opsSeen valid is decremented by 1.
262
270
***[EREP-020]** If a staked factory is used, its reputation is updated for the account violating any of the validation rules accordingly. \
263
271
That is, if the `validateUserOp()` is rejected for any reason in a `UserOperation` that has an `initCode`, it is treated as if the factory caused this failure, and thus this affects its reputation.
264
272
***[EREP-030]** If a staked account is used, its reputation is updated for failures in other entities (`paymaster`, `aggregator`) even if they are staked.
265
273
***[EREP-040]** An `aggregator` must be staked, regardless of storage usage.
266
274
***[EREP-050]** An unstaked `paymaster` may not return a `context`.
275
+
***[EREP-055]** A context size may not change between validation and bundle creation. \
276
+
If a bundle creation reverts, and a paymaster's context size was modified, that paymaster \
277
+
is BANNED, regardless if the UserOperation that reverted used that paymaster or not.
267
278
* Staked factory creation rules:
268
279
***[EREP-060]** If the factory is staked, either the factory itself or the sender may use the CREATE2 and CREATE opcode
269
280
(the sender is allowed to use the CREATE with unstaked factory, with OP-032)
@@ -310,6 +321,18 @@ Alt-mempools are served by the same bundlers participating in the canonical memp
310
321
***[AUTH-020]** An account with EIP-7702 delegation can only be used as the Sender of the UserOperation.
311
322
Using authorized account as any other kind of UserOperation entity is not allowed.
312
323
***[AUTH-030]** An account with EIP-7702 delegation can only be **accessed** (using `*CALL` or `EXTCODE*` opcodes) if it is the Sender of the current UserOperation.
324
+
***[AUTH-040]** If there are multiple UserOperations by the same sender with an authorization tuple in the mempool, they all MUST have the same delegate address.
325
+
326
+
### Limitations
327
+
328
+
The validation rules attempt to guarantee a degree of isolation between individual `UserOperations`' validations.
329
+
In order to prevent hitting the memory expansion limitations (imposed by ethereum EVM) when creating a bundle, `UserOperation`s must meet the following limitations:
330
+
331
+
***[LIM-010]** Maximum size of a single packed and ABI-encoded `UserOperation` in bytes MUST not exceed `MAX_USEROP_SIZE`
332
+
***[LIM-020]** Maximum size of a `context` byte array returned by a paymaster in a single `UserOperation` in bytes MUST not exceed `MAX_CONTEXT_SIZE`
333
+
***[LIM-030]** The `verificationGasLimit` and `paymasterVerificationGasLimit` parameters MUST exceed the actual usage during validation of the `UserOperation` by `VALIDATION_GAS_SLACK`
334
+
***[LIM-040]** Maximum size of an ABI-encoded bundle call to the `handleOps` function in bytes SHOULD not exceed `MAX_BUNDLE_SIZE`
335
+
***[LIM-050]** Maximum total size of all `context` byte arrays returned by all paymasters in all `UserOperations` in a bundle in bytes SHOULD not exceed `MAX_BUNDLE_CONTEXT_SIZE`
0 commit comments