Update EIP-7702: add "hash" to tuple, to allow single-signature for first eip-7702 tx initialization.

[drortirosh]

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)

[eth-bot]

File EIPS/eip-7702.md

Requires 1 more reviewers from @adietrichs, @lightclient, @SamWilsn, @vbuterin

[lightclient]

I don't really understand this change. How do you observe the hash from within the execution of the transaction?

[drortirosh]

I don't really understand this change. How do you observe the hash from within the execution of the transaction?

During ERC-4337 validation, the account's method is called with the signature
validateUserOp(UserOperation userop, bytes32 userOpHash, ...)
The hash is a keccak over the userop packed structure (excluding the signature field)
The userop.signature field can be used to pass authentication info in addition to the actual signature.
For EIP-7702 signature, it should include the nonce and chainId.
Thus the validation function looks something like:

function validateUserOp(UserOperation userop, bytes32 userOpHash) { 
   (bytes32 nonce, bytes32 chainid, bytes32 r, bytes32 s, uint8 v) = abi.decode(userop.signature, (bytes32,bytes32,bytes32,bytes32,uint8));
   bytes32 hash = keccak256(eip7702_rlp_encode(nonce, address(this), chainid, userOpHash));
   if ( address(this) == ecrecover(hash, v,r,s) ) return 0;
   return SIG_FAILED
}

This way we achieve the UX goal: a single signature by the end user for this transaction is used to validate both the eip-7702 tuple, and also outer transaction (erc-4337) for gas sponsorhip.

[github-actions]

The commit 72213fb (as a parent of 8f3465a) contains errors.
Please inspect the Run Summary for details.

[drortirosh]

Another use-case for hash: applying initcode to initialize a proxy:
We want to deploy a delegate, and then run some "initcode" to initialize it, without letting a frontrunner separate the two, and perfrom rogue initialization.
The normal flow for that would be a 2nd signature just for this initcode flow.
But using the hash in tuple, we can re-use the same eip-7702 signature to apply the code - so a user signs only once.
Now even if a front-runner ran the eip-7702 tuple in a separate transaction, it can't initialize it for itself, and our transaction will succeed to initialize our delegate (and pay slightly less, since the delegate was pre-installed by the front-runner..)

_fallback() {
  if (_implementation() != address(0) {
    _delegate(_implementation());
    return;
  }
  //this is the first call, so calldata contains implementation, target calldata and everything to reuse eip7702 signature)
  (address impl, bytes memory data, bytes32 nonce, bytes32 chainid, bytes32 r, bytes32 s, uint8 v) = abi.decode(msg.data, 
  (address, bytes, bytes32,bytes32,bytes32,bytes32,uint8));
  bytes32 datahash = keccak256(abi.encodePacked(impl,data);
   bytes32 hash = keccak256(eip7702_rlp_encode(nonce, address(this), chainid, datahash));
   require(address(this) == ecrecover(hash, v,r,s) );
   _setImplementation(impl);
   _deletate(data);
}