Update EIP-3074: allow authorized to send value

Merged by EIP-Bot.

EIPS/eip-3074.md

@@ -128,11 +128,10 @@ A new opcode `AUTHCALL` shall be created at `0xf7`. It shall take eight stack el
 | `top - 0` | `gas`        |
 | `top - 1` | `addr`       |
 | `top - 2` | `value`      |
-| `top - 3` | `valueExt`   |
-| `top - 4` | `argsOffset` |
-| `top - 5` | `argsLength` |
-| `top - 6` | `retOffset`  |
-| `top - 7` | `retLength`  |
+| `top - 3` | `argsOffset` |
+| `top - 4` | `argsLength` |
+| `top - 5` | `retOffset`  |
+| `top - 6` | `retLength`  |
 
 #### Output
 
@@ -149,8 +148,7 @@ A new opcode `AUTHCALL` shall be created at `0xf7`. It shall take eight stack el
  - If the `gas` operand is equal to `0`, the instruction will send all available gas as per [EIP-150](./eip-150).
  - If the gas available for the subcall would be less than `gas`, execution is invalid.
  - There is no gas stipend, even for non-zero `value`.
- - `value` is deducted from the balance of the executing contract. It is not paid by `authorized`. If `value` is higher than the balance of the executing contract, execution is invalid.
- - If `valueExt` is not zero, the instruction immediately returns 0. In this case the gas that would have been passed into the call is refunded, but not the gas consumed by the `AUTHCALL` opcode itself. In the future, this restriction may be relaxed to externally transfer value out of the `authorized` account.
+ - `value` is deducted from the balance of `authorized`. If `value` is higher than the balance of `authorized`, execution is invalid.
 
 `AUTHCALL` must increase the call depth by one. `AUTHCALL` must not increase the call depth by two as it would if it first called into the authorized account and then into the target.
 
@@ -264,12 +262,11 @@ It is, therefore, sufficient for the invoker to guarantee a minimum amount of ga
 
 ### Source of `value`
 
-Any non-zero `value` passed into an `AUTHCALL` is deducted from the invoker's balance. A natural alternative source for `value` would be the `authorized` account. However, deducting value from an EOA mid-execution is problematic, as it breaks important invariants for handling pending transactions. Specifically:
+In previous iterations of this EIP, it was thought that deducting value from an EOA mid-execution was problematic. This was due to an invariant of pending transactions which allows tx pools to statically determine the validity of a given transaction.
 
-- 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.
+However, after further investigation we found that breaking the invariant is safe. This is mostly due to the fact that the worst case is similar in both instances.
 
-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`, which may be 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](./eip-2930.md), 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).
+Currently an attacker can queue many transactions in the tx pool, across many accounts, and invalidate them all at once with a block where each of the queued accounts send a tx moving their entire balance. This attack will become easier and cheaper after this EIP, because it will no longer require direct access to the block builder and will not cost a full 21000 gas to originate each tx. However, the attack does not have a substantial impact on the network, so reducing the difficulty and cost are not of concern.
 
 ### Allowing `tx.origin` as Signer