EIP-2733: Transaction Package

Discussion thread for EIP-2733: Transaction Package.

This EIP was inspired by the EIP-2718, native batched transaction, and the need to maintain atomicity of meta-tx inner txs and payment txs.

1 Like

Thinking out loud, and not sold either way, but I wonder if there is value in generalizing this to say that "in any transaction that has multiple child transaction, RETURNDATASIZE and RETURNDATACOPY will initially be seeded with the previous transaction’s return data.

This would allow 2718 batch transactions to gain access to return data in subsequent transactions, as well as future transaction types. We may need to define what is a “batch” though? What if you have multiple transactions from different accounts that are batched by a third party, do those get return data set or not?

One concern I have with this is that it would allow contracts to discriminate on whether or not the transaction was part of a batch. On the other hand, I’m hesitant to prevent useful features just because some contract authors will be bad.

I think generalizing this behavior for any batch of txs makes sense. The two issues you raised are interesting:

  1. Is it okay to get return data for a tx from a different account?
  2. Is it okay that contact authors can discriminate against tx batches?

I don’t have enough context w.r.t. 1), but my intuition is that this is okay since the return values are public anyways. It does seem dirty to leak that information though. I feel stronger about 2) and it seems okay since it brings a lot of functionality. It is also similar to the current ability to discriminate against contracts vs. EOAs.

I’m thinking we define a “batch” as batch in 2711, since it is the only definition that would be known by the protocol. We should be able to extend this definition to other tx types on a case-by-case basis.

1 Like

rlp([N, rlp([nonce, v, r, s, [inner_tx_0, ..., inner_tx_n]])
inner_tx_n = [chain_id, to, value, data, gas_limit, gas_price]

Was checking out the EIP, and I got a thought of pulling the chain_idout. Because is it possible to process multiple chain_ids in a particular chain?

rlp([N, rlp([nonce, 2 * chain_id + 35 + v, r, s, [inner_tx_0, ..., inner_tx_n]])
inner_tx_n = [to, value, data, gas_limit, gas_price]

Is there any flaw in this?

Yep, that is a good point. Thank you for your suggestion. This EIP is overdue for an update - I’m thinking of rewriting it to focus on the cross-tx communication and rely on EIP-2711 for batching semantics (which is extracting the chainid). But if we don’t go down that path I will update with your suggestion.