Conditional Transactions
Video
Original
Abstract
This EIP proposes to add a new transaction format for "conditional transactions", that are only valid at a specified slot and index within the block. A new opcode TXINDEX
is introduced to expose the conditional transaction index onchain.
Motivation
The proposal aims to improve support for encrypted mempools. Transactions in an encrypted mempool are ordered while the transactions are encrypted, before being decrypted and included onchain at the top of the block. If the builder does not respect the order when including the decrypted transactions then they could frontrun decrypted transactions. The new transaction type can be used to make this impossible; if a decrypted transaction is not included at the correct index, it will be invalid.
Specification
Parameters
Constant | Value |
---|---|
COND_TX_TYPE | Bytes1(0x05) |
TXINDEX_OPCODE_BYTE | Bytes1(0x4c) |
TXINDEX_OPCODE_GAS | 2 |
Conditional Transaction Type
We introduce a new type of EIP-2718 transaction, "conditional transactions", where the TransactionType
is COND_TX_TYPE
and the TransactionPayload
is the RLP serialization of the following TransactionPayloadBody
:
[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, conditional_slot, conditional_tx_index, y_parity, r, s]
The fields chain_id
, nonce
, max_priority_fee_per_gas
, max_fee_per_gas
, gas_limit
, to
, value
, data
, access_list
, max_fee_per_blob_gas
follow the same semantics as EIP-4844. The field blob_versioned_hashes
is the same except that the list may be empty for a conditional transaction.
The fields conditional_slot
and conditional_tx_index
are both uint64
and specify the slot and transaction index in which this transaction should be considered valid respectively. In order to verify that conditional_slot
is correct, EIP-7843 is a dependency, as this adds the slot number to the header. For both fields -1
is used as a sentinel value for which the slot or transaction index check will not take place.
Signature
The signature values y_parity
, r
, and s
are calculated by constructing a secp256k1 signature over the following digest:
keccak256(COND_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, conditional_slot, conditional_tx_index]))
.
TXINDEX opcode
A new opcode TXINDEX
is introduced at TXINDEX_OPCODE_BYTE
.
Output
One element TransactionIndex
is added to the stack. TransactionIndex
is a uint64
in big endian encoding. It is equal to conditional_tx_index
if the current transaction is a conditional transaction, and -1
otherwise.
Gas Cost
The gas cost for TXINDEX
is a fixed fee of TXINDEX_OPCODE_GAS
.
Rationale
Transaction Type
An alternative design could simply return the current transaction index without adding a new transaction type. Adding a new transaction type is favoured as it means that the expected transaction index must be declared statically upfront, rather than allowing dynamic behaviour based on the returned transaction index. This prevents complex constraints being imposed that makes it difficult to build a block.
Gas Price
The opcode is priced to match similar opcodes in the W_base
set.
Backwards Compatibility
No backward compatibility issues found.
Test Cases
N/A
Security Considerations
None.
Copyright
Copyright and related rights waived via CC0.
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all