Update ERC-4337: Add 'preVerificationGas' estimation explainer

Merged by EIP-Bot.

ERCS/erc-4337.md

@@ -418,6 +418,23 @@ To decode the returned time-ranges, the bundler MUST run the validation using tr
 To prevent DoS attacks on bundlers, they must make sure the validation methods above pass the validation rules, which constrain their usage of opcodes and storage.
 For the complete procedure see [ERC-7562](./eip-7562.md)
 
+### Estimating `preVerificationGas`
+
+This document does not specify a canonical way to estimate this value,
+as it depends on non-permanent network properties such as operation and data gas pricing and the expected bundle size.
+
+However, the requirement is for the estimated value to be sufficient to cover the following costs:
+
+* Base bundle transaction cost. On Ethereum, `21000` gas divided by the number of `UserOperations`.
+* The calldata gas cost related to the `UserOperation`.
+* Static `EntryPoint` contract code execution.
+* Static memory cost when loading the fixed size fields of the `UserOperation` into EVM memory
+* Memory cost (including expansion cost) due to context returned by paymaster `validatePaymasterUserOp` function, if relevant.
+  * External call to the `innerHandleOp()` function which is a major part of the `EntryPoint` implementation.
+  Note that this value is not static and depends on the `UserOperation`'s position in the bundle.
+* EIP-7702 authorization cost, if any.
+
+The bundler MUST require a slack in `PreVerificationGas` value, to accommodate memory expansion costs in the future bundle, and the expected position of the `UserOperation` in it.
 ### Alternative Mempools
 
 The simulation rules above are strict and prevent the ability of paymasters to grief the system.
@@ -602,24 +619,6 @@ Contracts using the [EIP-1153](./eip-1153) transient storage MUST take into acco
 `UserOperations` from different unrelated `sender` addresses to be included in the same underlying transaction.
 The transient storage MUST be cleaned up manually if contains any sensitive information or is used for access control.
 
-### All account contracts
-
-#### Storage layout collisions
-
-It is expected that most of ERC-4337 smart contract accounts will be upgradeable,
-either via on-chain delegate proxy contracts or via EIP-7702.
-
-When changing the underlying implementation, Wallet Applications MUST ensure that there are no conflicts in the storage layout
-of the two contracts.
-
-One common approach to this problem is often referred to as "diamond storage" and is fully described in [ERC-7201](./eip-7201).
-
-### Transient Storage
-
-Contracts using the [EIP-1153](./eip-1153) transient storage MUST take into account that ERC-4337 allows multiple
-`UserOperations` from different unrelated `sender` addresses to be included in the same underlying transaction.
-The transient storage MUST be cleaned up manually if contains any sensitive information or is used for access control.
-
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).