Update ERC-4337: Add the new changes for v0.9

Merged by EIP-Bot.

Author: forshtat

ERCS/erc-4337.md

@@ -141,6 +141,8 @@ The Smart Contract Account:
   * `aggregator`/`authorizer` - 0 for valid signature, 1 to mark signature failure. Otherwise, an address of an `aggregator`/`authorizer` contract.
   * `validUntil` is 6-byte timestamp value, or zero for "infinite". The `UserOperation` is valid only up to this time.
   * `validAfter` is 6-byte timestamp. The `UserOperation` is valid only after this time.
+  * In order to specify a validity range using block numbers, both the `validUntil` and `validAfter` need to set their highest bit to 1.
+  * **Note:** The validity range can be expressed by two block timestamps or two block numbers, but one timestamp and one block number cannot be mixed in the same UserOperation's validity range.
 
 The Smart Contract Account MAY implement the interface `IAccountExecute`
 
@@ -230,6 +232,7 @@ In the verification loop, the `handleOps` call must perform the following steps
 * **Create the `sender` Smart Contract Account if it does not yet exist**, using the `initcode` provided in the `UserOperation`.
   * If the `factory` address is "0x7702", then the sender MUST be an EOA with an [EIP-7702](./eip-7702.md) authorization designation. The `EntryPoint` validates the authorized address matches the one specified in the `UserOperation` signature (see [Support for [EIP-7702] authorizations](#support-for-eip-7702-authorizations)).
   * If the `sender` does not exist, _and_ the `initcode` is empty, or does not deploy a contract at the "sender" address, the call must fail.
+  * **WARNING**: If the `sender` does exist, _and_ the `initcode` is _not_ empty, then the `initcode` is ignored.
 * calculate the maximum possible fee the `sender` needs to pay based on validation and call gas limits, and current gas values.
 * calculate the fee the `sender` must add to its "deposit" in the `EntryPoint`
 * **Call `validateUserOp` on the `sender` contract**, passing in the `UserOperation`, its hash and the required fee.
@@ -311,6 +314,21 @@ Maliciously crafted paymasters could pose a risk of a DoS attack against the sys
 As a mitigation, bundlers should use a reputation system for contracts they serve, and the paymaster must either limit its storage usage, or deposit a stake in a reputation system.
 Full specification of a reputation system is outside the scope of this proposal.
 
+#### The `paymasterAndData` field encoding and `paymasterSignature`
+
+The `paymasterAndData` field is a byte array that contains a non-standard encoding of the following fields:
+* `paymasterAddress` - 20 bytes — the address of the paymaster contract
+* `paymasterVerificationGasLimit` - 16 bytes - the gas limit for the verification function
+* `postOpGasLimit` - 16 bytes - the gas limit for the postOp function
+* `paymasterData` - the data that the paymaster contract will receive in the `validatePaymasterUserOp` call
+
+The following data can optionally be appended to the `paymasterAndData` field:
+* `paymasterSignature` - the "signature" value byte array to be checked by the paymaster contract; this value can be provided **without affecting the UserOperation hash**
+* `paymasterSignatureLength` - 2 bytes - the exact length of the `paymasterSignature` parameter byte array
+* `PAYMASTER_SIG_MAGIC` (`0x22e325a297439656`) - the magic value that is appended to indicate the use of the `paymasterSignature` feature by the UserOperation
+
+Note that as both the `signature` and the `paymasterSignature` fields do not affect the UserOperation hash, the signing by the Sender and the Paymaster can be performed in parallel.
+
 The paymaster interface is as follows:
 
 ```solidity
@@ -358,6 +376,9 @@ receive() external payable;
 
 // withdraw from the deposit of the current account
 function withdrawTo(address payable withdrawAddress, uint256 withdrawAmount) external;
+
+// get the currently executing UserOperation hash, or 0 if not called during the execution
+function getCurrentUserOpHash() public view returns (bytes32);
 ```
 
 ### Bundler behavior upon receiving a UserOperation