Update eip-7702.md

Add an optional "hash" field to the auth tuple, to support single signature when submitted through a wrapper protocol (such as ERC-4337's UserOperation)

EIPS/eip-7702.md

@@ -41,7 +41,7 @@ We introduce a new [EIP-2718](./eip-2718.md) transaction, "set code transaction"
 ```
 rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])
 
-authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]
+authorization_list = [[chain_id, address, nonce, hash, y_parity, r, s], ...]
 ```
 
 The fields `chain_id`, `nonce`, `max_priority_fee_per_gas`, `max_fee_per_gas`, `gas_limit`, `destination`, `value`, `data`, and `access_list` of the outer transaction follow the same semantics as [EIP-4844](./eip-4844.md). *Note, this means a null destination is not valid.*
@@ -64,7 +64,7 @@ The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([sta
 
 #### Behavior
 
-At the start of executing the transaction, after incrementing the sender's nonce, for each `[chain_id, address, nonce, y_parity, r, s]` tuple do the following:
+At the start of executing the transaction, after incrementing the sender's nonce, for each `[chain_id, address, nonce, hash, y_parity, r, s]` tuple do the following:
 
 1. Verify the chain id is either 0 or the chain's current ID.
 2. Verify the `nonce` is less than `2**64 - 1`.
@@ -78,6 +78,8 @@ At the start of executing the transaction, after incrementing the sender's nonce
     * As a special case, if `address` is `0x0000000000000000000000000000000000000000` do not write the designation. Clear the accounts code and reset the account's code hash to the empty hash `0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470`.
 9. Increase the nonce of `authority` by one.
 
+The `hash` value of the auth tuple is not checked in any way. It is used by outer transaction.
+
 If any of the above steps fail, immediately stop processing that tuple and continue to the next tuple in the list. It will in the case of multiple tuples for the same authority, set the code using the address in the last valid occurrence.
 
 Note that the signer of an authorization tuple may be different than `tx.origin` of the transaction.
@@ -193,6 +195,7 @@ Specifically:
 * Hence, it avoids the problem of "creating two separate code ecosystems" because, to a large extent, they would be the same ecosystem. There would be some workflows that require kludges under this solution that would be better done in some different "more native" under "endgame AA", but this is relatively a small subset.
 * It does not require adding any opcodes, that would become dangling and useless in a post-EOA world.
 * It allows EOAs to masquerade as contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing `EntryPoint`.
+* The auth tuple contains a `hash` value, which is unused by [EIP-7702] itself, but can be used to authenticate the wrapping UserOperation. This way, a single signature by the user is required, for both eip-7702 and the outer UserOperation.
 
 ### Clearing Delegation Designations