EIP-? Native Batched Transactions

There have been many discussions about how to improve the UX when it comes to EOA, such has integrating native transaction delegation, rich transactions and more.

Another approach would be to allow EOA to execute atomic batch transactions, where only one nonce and one signature would be provided for a given batch of transactions. This would allow users to do things like Approve + call (for ERC20) in a single batch, or buy an asset in one dex to send it elsewhere after. This is a pattern that is common in smart contract wallets and has proved very powerful when it comes to UX and cost optimisation.

To support this, the transaction object passed to eth_sendTransaction could be changed from:

export type Transaction = {
  from: string;
  to: string;
  gas?: number; 
  gasPrice?: number; 
  value?: number;  
  data:  string;
  nonce?: number;
} 

to something like this:

export type Transaction = {
  from: string;
  to: string | string[];
  gas?: number | number[];
  gasPrice?: number | number[];
  value?: number  | number[];
  data:  string | string[];
  nonce?: number;
} 

If arrays are provided, they all must of of same length. Could also use default values for the optional fields. There is always a single nonce and a single signature, which ensures that all calls are executed within a transaction, providing atomicity. Nodes can then execute sequentially the calls provided in a given transaction.

That’s about it! I was curious if there was already an EIP for this and what other people thought of this approach.

2 Likes

This is interesting. My concern is that it easily runs out of gas and go beyond the gas limit. We need to approach this issue.

What are the advantages over my proposed scheme? From my perspective, it seems more involved (insofar as it requires changes to a consensus data structure) and less flexible.

@Arachnid

What are the advantages over my proposed scheme? From my perspective, it seems more involved (insofar as it requires changes to a consensus data structure) and less flexible.

To me, the main advantages would be

  1. Less security considerations (no need to worry/debate if EOA should have a state, etc.)
  2. Easier for clients to benefit from since they don’t need to write contracts code to do complex txs, just just put in an array the transactions they want to execute.
  3. Cheaper calls for most use cases (my guess), since you don’t need to pass contract code, just calldata for each tx.

It is indeed less expressive than rich-transactions, but I don’t see them as mutually exclusive proposals.