Sponsored Transaction Precompile

Simple Summary

Creates a new precompile, analogous to CALL, that sets msg.sender based on an ECDSA signature.

Abstract

We propose adding two precompiles:

CALL_PRECOMPILE - forwards a CALL, setting msg.sender according to an ECDSA signature, using a relayer-sponsee nonce for replay protection.
NONCE_PRECOMPILE - provides access to relayer-sponsee nonces expected by CALL_PRECOMPILE.

Motivation

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 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), these solutions require specific support in callee contracts.

Specification

We propose adding two precompiles to implement sponsored transactions:

The first, at address 0x13, would function like a CALL instruction that additionally sets the caller address based on an ECDSA signature.
The second, at address 0x14, would provide access to the current nonce for the given relayer-sponsee pair.

Definitions

CALL_PRECOMPILE - the specific precompile at address 0x13, introduced by this EIP, which implements the CALL analogue.
NONCE_PRECOMPILE - the specific precompile at address 0x14, introduced by this EIP, which exposes relayer-sponsee nonces.
Transaction-like Package - the signed arguments passed to CALL_PRECOMPILE.
Sponsor - the account which is responsible for paying gas fees and sending the transaction. May or may not be the same as the relayer.
Sponsee - the account which signed the transactions-like package.
Relayer - the account or contract which directly calls into CALL_PRECOMPILE. May or may not be the same as the sponsor.
Callee - the target of the call from CALL_PRECOMPILE.

API

`CALL_PRECOMPILE`

CALL_PRECOMPILE requires the following eight arguments:

nonce - the next nonce value, as described below;
to - the address of the callee (not CALL_PRECOMPILE);
gaslimit - the minimum gas limit which must be provided with the call into CALL_PRECOMPILE;
value - the exact amount of Ether in wei to transfer from the relayer to the callee;
data - the calldata for the call into to; and
v, r, s - signature for the package, including chain id as specified in EIP-115.

The arguments to CALL_PRECOMPILE are encoded as rlp([nonce, gaslimit, to, value, data, v, r, s]).

The signature (v, r, s) arguments are computed from secp256k1(keccak256(rlp([nonce, gaslimit, to, value, data, relayer]))).

CALL_PRECOMPILE returns a failure without changing the nonce in the following situations:

Invalid signature
Future or past nonce
Gas limit supplied with the call into CALL_PRECOMPILE is less than the signed gaslimit
The relayer's balance is insufficient to pay for the supplied gas plus value

CALL_PRECOMPILE returns a success in all other cases.

The return data of CALL_PRECOMPILE will be a single byte to indicate the status of the call into callee followed immediately by the return data from that call.

`NONCE_PRECOMPILE`

NONCE_PRECOMPILE requires the following two arguments:

relayer - the relayer address; and
sponsee - the sponsee address.

Assuming the calldata is the correct length, NONCE_PRECOMPILE will return a success, and place the nonce associated with the address pair in the return data.

Nonces

The two precompiles will maintain a nonce for each pair of relayer address and sponsee address, in essence:

{
    (0x1234...5678, 0xEEEE...EEEE) => 55,
    (0x1122...3344, 0xBBBB...BBBB) => 89,
}

Where:

0x1234...5678 and 0x1122...3344 are the relayer addresses;
0xEEEE...EEEE and 0xBBBB...BBBB are the sponsee addresses; and
55 and 89 are the current nonce values for their respective pairs.

The nonce shall be incremented whenever a correctly signed transaction-like package containing the next nonce is submitted to CALL_PRECOMPILE with a sufficient gas limit.

Gas Fees

`CALL_PRECOMPILE`

TODO: Probably something like the sum of:

The cost of a normal call, including calldata and signature size, etc.
An SLOAD to read the current nonce
An SSTORE to write the updated nonce
Cost of an ecrecover

`NONCE_PRECOMPILE`

TODO: Probably something like the sum of:

An SLOAD to read the current nonce

Rationale

Another Sponsored Transaction EIP

Other approaches to sponsored transactions, like EIP-2711 and EIP-2733, are incompatible with EIP-2938 flavored 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, a precompile 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.

CALL_PRECOMPILE's single purpose is to set msg.sender. It implements the minimal functionality to enable sender abstraction for sponsored transactions. This single mindedness makes CALL_PRECOMPILE significantly more composable with existing Ethereum features.

More logic can be implemented around the call into CALL_PRECOMPILE, giving more control to relayers and sponsors without sacrificing security or user experience for sponsees.

Nonces

Other nonce schemes either do not provide enough security, or are too inefficient/inconvenient to be practical.

Use sponsor nonce: every transaction from the sponsor's account invalidates every transaction-like package.
Use relayer nonce: every sponsored transaction from the relayer's account invalidates every other transaction-like package. Also interacts with SELFDESTRUCT.
Use sponsee nonce: the sponsee could attack the sponsor by submitting another transaction with a conflicting nonce at a higher gas price.

Instead, by creating an independent nonce per relayer-sponsee pair, we get some attractive properties:

A transaction package can only be invalidated if both the relayer and sponsee cooperate, which is nice for EOA sponsors, and necessary for AA contracts.
The SELFDESTRUCT operation doesn't introduce replay attacks.

Backwards Compatibility

No known issues.

Test Cases

TODO

Implementation

TODO

Security Considerations

First precompiles that require persistent storage.
Potential impersonation attacks if there is a bug in the signature verification.
Potential replay-attack problems if there is a bug in the replay protection, or if two chains share chain ids.

Copyright

Acknowledgments

Largely inspired by EIP ? - CallWithSigner as a potential fix for the msg.sender problem and EIP-2711.