Automatically merged updates to draft EIP(s) 3074 (#3424)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft, Review, or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-3074.md

@@ -116,7 +116,7 @@ A new opcode `AUTHCALL` shall be created at `0xf7`. It shall take eight stack el
  - If `authorized` is unset, execution is considered invalid and must exit the current execution frame immediately (in the same way as a stack underflow or invalid jump).
  - Otherwise, the caller address for the call is set to `authorized`.
 
-The parameter `value` is deducted from the balance of the executing contract. It is not paid by `authorized`. The parameter `valueExt` must be zero, otherwise the instruction must exit the current execution frame immediately. In the future, this restriction may be relaxed to externally transfer value out of the `authorized` account.
+The parameter `value` is deducted from the balance of the executing contract. It is not paid by `authorized`. The parameter `valueExt` must be zero, otherwise the instruction must return 0. In the future, this restriction may be relaxed to externally transfer value out of the `authorized` account.
 
 `AUTHCALL` must increase the call depth by one. `AUTHCALL` must not increase the call depth by two as if it first called into the authorized account and then into the target.
 
@@ -132,9 +132,9 @@ As with `CALL`, the gas cost for the opcode itself (both the static and the dyna
 
 ## Rationale
 
-### Throwing for Unset `authorized` or Invalid `valueExt` During `AUTHCALL`
+### Throwing for Unset `authorized` During `AUTHCALL`
 
-A well-behaved contract should never reach an `AUTHCALL` without having successfully set `authorized` beforehand. Similarly, it should never set `valueExt` to be non-zero. The safest behavior, therefore, is to exit the current frame of execution immediately. This is especially important in the context of transaction sponsoring / relaying, which is expected to be one of the main use cases for this EIP. In a sponsored transaction, the inability to distinguish between a sponsee-attributable fault (like a failing sub-call) and a sponsor-attributable fault (like a failing `AUTH`) is especially dangerous and should be prevented because it charges unfair fees to the sponsee.
+A well-behaved contract should never reach an `AUTHCALL` without having successfully set `authorized` beforehand. The safest behavior, therefore, is to exit the current frame of execution immediately. This is especially important in the context of transaction sponsoring / relaying, which is expected to be one of the main use cases for this EIP. In a sponsored transaction, the inability to distinguish between a sponsee-attributable fault (like a failing sub-call) and a sponsor-attributable fault (like a failing `AUTH`) is especially dangerous and should be prevented because it charges unfair fees to the sponsee.
 
 ### Another Sponsored Transaction EIP
 
@@ -201,7 +201,7 @@ Any non-zero `value` passed into an `AUTHCALL` is deducted from the invoker's ba
 * Transaction pools expect transactions for a given EOA to only turn invalid when other transactions from the same EOA are included into a block, increasing its nonce and (possibly) decreasing its balance. Deducting `value` from the `authorized` account would make transaction invalidation an unpredictable side effect of any smart contract execution.
 * Similarly, miners rely on the ability to statically pick a set of valid transactions from their transaction pool to include into a new block. Deducting `value` from the `authorized` account would break this ability, increasing the overhead and thus the time for block creation.
 
-At the same time, the ability to directly take ether out of the `authorized` account is an important piece of functionality and thus an desired future addition via an additional opcode similar to `AUTHCALL`. For this reason, it is included as `valueExt`, an operand of `AUTHCALL` and may activated in a future fork. The prerequisite for that would be to find satisfying mitigations to the transaction invalidation concerns outlined above. One potential avenue for that could be the addition of account access lists similar to EIP-2930, used to signal accounts whose balance can be reduced as a side effect of the transaction (without on their own constituting authorization to do so).
+At the same time, the ability to directly take ether out of the `authorized` account is an important piece of functionality and thus a desired future addition via an additional opcode similar to `AUTHCALL`. For this reason, it is included as `valueExt`, an operand of `AUTHCALL` and may activated in a future fork. The prerequisite for that would be to find satisfying mitigations to the transaction invalidation concerns outlined above. One potential avenue for that could be the addition of account access lists similar to EIP-2930, used to signal accounts whose balance can be reduced as a side effect of the transaction (without on their own constituting authorization to do so).
 
 ## Backwards Compatibility