ORC-0001: Sequencer-sponsored Transactions

·Proposal

Table of Contents

Abstract

Introduces a new odyssey_sendTransaction RPC method that allows a consumer to defer transaction execution to a Sequencer (subject to validity checks).

Motivation

The introduction of EIP-7702 enables an Externally-owned Account (EOA) to sign over an Authorization Tuple to designate a Smart Contract as its implementation. This Authorization Tuple can then be passed to an EIP-7702 Transaction and executed to assign the delegation. Since anyone can execute an EIP-7702 Transaction with a valid Authorization Tuple, this means that either the EOA or a third-party (e.g. a Sequencer) can sponsor the gas fee.

After a Smart Contract has been delegated to an EOA, it is also possible for a third-party to sponsor subsequent EIP-1559 Transactions, provided that the Transaction has passed certain validity checks (e.g. no value, to points to the delegated EOA address, etc.).

This proposal outlines the specification for an odyssey_sendTransaction RPC method that allows a Sequencer to sponsor a:

  1. EIP-7702 Transaction that delegates a Smart Contract to an EOA, or
  2. EIP-1559 Transaction that executes a call on a delegated EOA.

Specification

odyssey_sendTransaction

Submits a transaction to the Sequencer. A Transaction will only be accepted if it passes Sequencer-defined validity checks.

Parameters

{
  method: 'odyssey_sendTransaction',
  params: [
    {
      // Optional EIP-7702 authorization list to designate 
      // a Smart Contract to an EOA.
      authorizationList?: {
        address: `0x${string}`,
        chainId: number,
        nonce: number,
        r: `0x${string}`,
        s: `0x${string}`,
        yParity: number,
      }[],
      // Optional calldata to be executed on the EOA.
      data?: `0x${string}`,
      // Address of the delegated EOA.
      to: `0x${string}`,
    }
  ]
}

Returns

`0x${string}` // The transaction hash.

Examples

The two main use cases for odyssey_sendTransaction, as described earlier, are:

  1. Designating a Smart Contract to an EOA, and
  2. Executing a call to a delegated EOA.

Let’s walk through a trivial example of each.

Designating a Smart Contract to an EOA

The diagram below demonstrates how an EOA can build & sign an Authorization List that includes the delegation contract’s address, and utilize a Sequencer-sponsored Transaction (odyssey_sendTransaction) to execute the designation.

Below is an example odyssey_sendTransaction request that executes an EIP-7702 Transaction to designate a contract to the EOA (via authorizationList), as well as executing a function on it (via data):

curl 'https://odyssey.ithaca.xyz/' --data '{
  "jsonrpc":"2.0",
  "id":0,
  "method":"odyssey_sendTransaction",
  "params":[{
    "authorizationList":[{
      "address":"0x35202a6E6317F3CC3a177EeEE562D3BcDA4a6FcC",
      "chainId":"0xde9fb",
      "nonce":"0x0",
      "r":"0xc9e930f2051c331b994ca1ec5d398379923dc1aae3b1aaaccf4242e872b8ce79",
      "s":"0x182672f89807a836962b0f29ce566f30b1588bd8b6bd4f9a8e24b3675ed11c3e",
      "yParity":"0x0"
    }],
    "data":"0xdeadbeef00000000000000000000000000000000000000000000000000000000cafebabe",
    "to":"0xFC7b76a8cA893f00976a14559D08b77aa4e4Bf2e"
  }]
}'

Executing a Call to a Delegated EOA

The diagram below demonstrates how a delegated EOA can use a Sequencer-sponsored Transaction to execute a call on its behalf.

Below is an example odyssey_sendTransaction request that executes an EIP-1559 Transaction to execute a function on a delegated EOA (via data):

curl 'https://odyssey.ithaca.xyz/' --data '{
  "jsonrpc":"2.0",
  "id":0,
  "method":"odyssey_sendTransaction",
  "params":[{
    "data":"0xdeadbeef00000000000000000000000000000000000000000000000000000000cafebabe",
    "to":"0xFC7b76a8cA893f00976a14559D08b77aa4e4Bf2e"
  }]
}'

Rationale

Sequencer-defined Validity Checks

The Sequencer is responsible for enforcing the validity of Transactions that are sponsored by it.

A Sequencer should only process Transactions that:

  1. are type EIP-7702 that designates a Smart Contract to an EOA, OR type EIP-1559 to an EOA with a designation
  2. do not exceed the Sequencer’s defined per-transaction gas limit
  3. do not include a value field (or set to 0)
  4. do not include a nonce field (managed by the Sequencer)
  5. do not include a from field (managed by the Sequencer)

Transaction Properties

It is important to note that some Transaction properties are managed by the Sequencer, and are ignored if passed by a consumer.

These include:

  1. gasPrice/maxFeePerGas/maxPriorityFeePerGas
  2. gas
  3. chainId

Backwards Compatibility

The API design of odyssey_sendTransaction at surface is intentionally identical to eth_sendTransaction’s API. Consumers can use odyssey_sendTransaction as a drop-in replacement for eth_sendTransaction when performing JSON-RPC requests.

Examples

EXP-0001: Account Delegation with EIP-7702 showcases the ability to designate a WebAuthn-enabled Delegation Contract to an EOA that effectively allows the EOA to use a WebAuthn key to sign calls to be executed on its behalf.

Reference Implementation

A reference implementation of the odyssey_sendTransaction RPC method can be found on the Odyssey’s GitHub repository.

Security Considerations

Arbitrary Transaction Abuse

Without the Sequencer-defined validity checks mentioned earlier, a malicious consumer could trivially abuse the Sequencer to submit arbitrary Transactions to the network, and drain the Sequencer’s funds. It is important that the Sequencer has a well-defined set of validity checks to prevent such abuse.

Denial of Service Attacks

A Sequencer could be prone to Denial of Service (DoS) attacks. DoS attacks can be partially mitigated by Sequencer-defined validity checks, however, a Sequencer could still be overwhelmed by a large number of Transactions by a malicious consumer. The Sequencer should implement rate-limiting and other anti-DoS measures to mitigate the risk of being overwhelmed.

Discussion

Third-party Sequencers

It should be possible for anyone to be able to host their own Sequencer service pointing to a specific Node, with the same implementation and level of security as the native Sequencer.

In the future, it is anticipated that there will be a streamlined process for cloning and deploying a third-party Sequencer.

Centralization

A malicious Sequencer could choose to censor specific consumers, effectively denying them service. It is important to note that this proposal does not change the way Transactions are facilitated by a consumer as they could submit to an alternative third-party Sequencer (as mentioned above), or self-sponsor the Transaction and just use eth_sendRawTransaction.

Gas Sponsorship

A valid concern of the current proposal is how gas sponsorship is enforced. Currently, the Sequencer is responsible for covering the gas cost of the Transactions that it sponsors. Realistically, this wouldn’t work in a Mainnet environment. In the future, it will be possible for a third-party to sponsor Transactions by deploying their own Sequencer service (as mentioned above). This would enable App Developers, Wallets, or even RPC Providers, to host their own Sequencer service.

Does odyssey_sendTransaction need to be a separate method?

There are also open questions about the necessity of odyssey_sendTransaction being a separate method, and whether it can be subsumed into eth_sendTransaction.

We chose to have a separate method for clarity of intent, but it is not a fundamental requirement for the implementation.