Sponsored transactions—the separation of fee payment from transaction content—have been a long standing feature request. Unlike similar proposals, this EIP specifies a method of implementing sponsored transactions that allows both externally owned accounts (EOAs) and [EIP-2938](./eip-2938.md) contracts to act as sponsors.
With the explosion of tokens built on Ethereum, especially stable coins, it has become common for EOAs to hold valuable assets without holding any Ether at all. These assets must be converted to Ether before they can be used to pay gas fees, but without Ether to pay for the conversion, it's impossible to convert them. Sponsored transactions break the circular dependency.
While it is possible to emulate sponsored transactions (ex. [Gas Station Network](https://www.opengsn.org/)), these solutions require specific support in callee contracts.
`CALLFROM` must increase the call depth by one, in the same way as `CALL`. `CALLFROM` must not increase the call depth by two (as it would if it first called into the sponsee account and then into the callee.)
In a static context (such as the one created by `STATICCALL`), `CALLFROM` with a non-zero `value` must exit the current execution frame immediately (in the same way `CALL` behaves with a non-zero value in a static context.)
Where `cost_of_call(...)` is the cost of a `CALL` (`0xF1`) instruction with the same `gas`, `value`, `argsOffset`, `argsLength`, `retOffset`, and `retLength` arguments.
It is important to differentiate between a failure in `CALLFROM`'s preconditions versus a failure in the callee. Correctly implementing replay protection requires the invoker to change its state (i.e. burn the nonce) even if the callee fails; but doing so if, for example, the signature failed would be nonsensical. Several options exist for encoding these two failure cases: returning two stack elements, reserving a specific revert reason, or choosing different values in a single stack element.
Reserving a specific revert reason, for example `CALLFROM failed`, is a large departure from other instructions. An invoker would need to inspect the revert reason to determine whether the callee reverted, or the `CALLFROM` pre-conditions were invalidated, which implies reading and comparing memory values. Further, to remain sound if a callee were to revert with `CALLFROM failed`, `CALLFROM` would need to replace the return data with some other value.
Returning a single stack element with different values depending on the situation (ex. `0` on success, `1` when the pre-conditions are violated, and `2` when the callee reverts) introduces the opportunity for a subtle bug: it's trivially easy to misinterpret the return value (`CALL` returns non-zero on success), but it's much harder to ignore a whole new stack value.
Including `sponsee` in the arguments to `CALLFROM` is a gas optimization for invoker contracts implementing some replay protection based on the sponsee address. Without the `sponsee` argument, invokers would have to do their own `ecrecover` before calling into `CALLFROM` to verify/adjust any state for replay protection.
### Reserving an [EIP-2718](./eip-2718.md) Transaction Type
While clients should never directly interpret transaction-like packages as true transactions, reserving an [EIP-2718](./eip-2718.md) transaction type for transaction-like packages reduces the likelihood of a transaction-like package being misinterpreted as a true transaction.
Other approaches to sponsored transactions, which rely on introducing a new transaction type, are not immediately compatible with account abstraction (AA). These proposals require a _signed_ transaction from the sponsor's account, which is not possible from an AA contract, because it has no private key to sign with.
Besides better compatibility with AA, an instruction is a much less intrusive change than a new transaction type. This approach requires no changes in existing wallets, and little change in other tooling.
`CALLFROM`'s single purpose is to set `CALLER`. It implements the minimal functionality to enable sender abstraction for sponsored transactions. This single mindedness makes `CALLFROM` significantly more composable with existing Ethereum features.
More logic can be implemented around the `CALLFROM` instruction, giving more control to invokers and sponsors without sacrificing security or user experience for sponsees.
### What to Sign?
Earlier approaches to this problem included mechanisms for replay protection, and also signed over value, gas, and other arguments to `CALLFROM`. Instead, this proposal explicitly delegates these responsibilities to the invoker contract.
As originally written, this proposal specified a precompile with storage to track nonces. Since a precompile with storage is unprecedented, a later revision moved replay protection into the invoker contract, necessitating a certain level of user trust in the invoker, while also opening the door to more creative replay protection schemes in the future. Building on this idea of trusted invokers, the other signed fields in the transaction-like package were eliminated until only `invoker` and `extra` remained.
The motivation for including `invoker` is to bind a particular transaction-like package to a single invoker. If `invoker` was not part of the TLP, a malicious invoker could reuse the TLP to impersonate the EOA.
Finally, `extra` should be used by invoker contracts to implement replay protection and security around calldata, value, and other parameters. For example, an invoker may assume `extra` to be `keccak256(abi.encode(gas, value, nonce))`, guaranteeing that the sponsee intended to set those parameters to those specific values. Without `extra`, invokers would not be able to determine if other values (eg. `gas`, `value`, calldata, etc.) had been tampered with.
The EVM limits the maximum number of nested calls, and naively allowing a sponsor to manipulate the call depth before reaching the invoker would introduce a griefing attack against the sponsee. That said, with the 63/64th gas rule, and the cost of `CALLFROM`, the stack is effectively limited to a much smaller depth than the hard maximum by the `gas` parameter.
It is, therefore, sufficient for the invoker to guarantee a minimum amount of gas, because there is no way to reach the hard maximum call depth with any reasonable (i.e. less than billions) amount of gas.
The following is a non-exhaustive list of checks/pitfalls/conditions that invokers _should_ be wary of:
- Replay protection should be implemented by the invoker, and included in `extra`. Without it, a malicious sponsor can replay a TLP, repeating its effects.
-`value` should be included in `extra`. Without it, a malicious sponsor could cause unexpected effects in the callee.
-`gas` should be included in `extra`. Without it, a malicious sponsor could cause the callee to run out of gas and fail, griefing the sponsee.
- The current chain id should be included in `extra` and checked on every transaction. Without it, a malicious sponsor could replay a TLP on a different chain.
