Learn about the new transaction types on Ethereum in one article

This article comes fromMycryptoThis article comes from

, the original author: Maarten Zuidhoorn, compiled by Odaily translator Katie Ku.

• There are different types of transactions on Ethereum, for example, sending ETH to an address, deploying a contract, and so on. Before the Berlin network upgrade, there were four different transaction types on Ethereum:

• Regular transactions with receiving addresses, data fields, etc.;

• For a contract deployment transaction without a destination address, the data field is used for the contract code;

• Transaction with v-value signature method, but not including chain ID (pre-EIP-155);

A transaction with a v-value signature, but including the chain ID.

Different Ethereum clients, libraries and other tools analyze each transaction and understand each transaction type. While there are only four transaction types, there are many complexities and situations to deal with. Technicians should check all the fields in the transaction to figure out what type of transaction it is. This is key for new types of transactions, such as pre-EIP-2718 transaction types such as meta transactions and multisig transactions.

In this article we will detail some of the standards included in the Berlin upgrade, as well as others that may be included in the future.

secondary title

Standard Transaction Envelope

RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

Ethereum has a transaction format. Each transaction includes a nonce, gas price, gas limit, destination address, value, data, v, r, and s. These fields are RLP encoded as follows:

TransactionType || TransactionPayload

EIP-2718 defines a new broad envelope for typed transactions. In the new standard, transactions look like this:

• where the fields are defined as:

• Transaction Type: A number between 0 and 0x7f, there are 128 possible transaction types in total.

Transaction Payload: An arbitrary byte array as defined by the transaction type.

These fields are concatenated and combined to form a typed transaction. The standard does not describe the format of the transaction payload; it can be any arbitrary series of bytes, encoded by the encoders defined by the new transaction types (e.g., RLP, SSZ, etc.). Simple byte concatenation was chosen because reading the first byte of a byte array does not require any libraries or tools: you don't need an RLP or SSZ parser to check the transaction type.

A good example of added complexity is EIP-155, which introduces reply protection by using chain IDs in transactions. Adding a new field to the transaction parameters would break backwards compatibility, so the chain ID is encoded into the recovery parameter (v) of the transaction signature (v). With EIP-2718, we can simply create a new transaction type to maintain backwards compatibility.

secondary title

Backward Compatibility and Raw Transactions

A big theme of EIP-2718 is backwards compatibility. EIP-2718 is in full backward compatibility mode, which means that any existing tools, libraries, (hardware) wallets and transactions can use it, but they will not be able to use the new "features" provided by EIP-2718 and the standard. The old transaction format (now called raw transactions) is still valid for new transactions on the Ethereum network.

The maximum number of new transaction types, 0x7f, was chosen to maintain backward compatibility with these old transactions. RLP-encoded transactions always start with a byte that is l, and the parameter is greater than or equal to 0xc0, so typed transactions will never collide with old transactions, and typed transactions can be distinguished just by checking the first byte and old transactions.

• EIP-2718 itself does not define any transaction types, but there are some proposals for the new standard:

• EIP-1559: ETH1.0 chain market fee changes;

• EIP-2711: Sponsorship, expiration, and batch transactions, also created by developer Micah Zoltu, which is why EIP-2718 was created;

Some of these criteria are further detailed below.

secondary title

Why are new transaction types needed?

EIP-2711 adds this functionality natively to the Ethereum network, while maintaining backwards compatibility with primitive type transactions (as described in the previous section). It does not require smart contracts or dedicated nodes to run. However, currently EIP-2711 is still a draft and it is unclear whether this EIP will join the Ethereum network anytime soon. It may also be split into multiple smaller EIPs (such as EIP-3074).

secondary title

New transaction format for EIP-1559

0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])

In EIP-1559, the way gas works has changed significantly. Instead of paying full gas to miners, a portion of gas is burned. We don't detail all the changes in EIP-1559, but it does specify a new transaction format:

• The most notable changes are:

• Gas price has been replaced by "highest priority fee per gas" and "maximum fee per gas".

• The chain ID is encoded separately rather than included in the signature v-value. This essentially replaces EIP-155 with a simpler implementation.

The signature v value is now a simple parity bit ("signature Y parity") which is either 0 or 1, depending on which point on the elliptic curve should be used.

Since EIP-1559 makes significant changes to how gas fees work, it is not directly compatible with raw transactions. To maintain backwards compatibility, EIP-1559 describes a method for upgrading raw transactions to EIP-1559-compatible transactions. It does this by using the raw gas price as the highest priority fee and highest gas fee per gas.

secondary title

Raw meta transactions and batch transactions

Metatransactions have been around for a few years, but until now have still required smart contracts. As with expiring transactions, this requires sending ETH to a smart contract, which must specifically support meta transactions.

0x02 || RLP([...SenderPayload, ...SenderSignature, ...GasPayerPayload, ...GasPayerSignature])

EIP-2711 enables native meta transactions (called sponsored transactions) and batch transactions without the need for smart contracts. A new transaction format is defined with transaction type 0x02 (although this is subject to change as EIP-1559 uses the same transaction type). The transaction is as follows:

[1, ChildTransaction[], nonce, ChainId, ValidUntil, gasLimit, gasPrice]

Basically, EIP-2711 includes an (optional) payload and signature of the gas payer. This account will be used to pay the gas fee in the transaction. For example, ERC-20 tokens can be sent from an address without the address holding any ETH. The sender payload, signature, etc. are defined based on the transaction subtype. For example, for a transaction with transaction type 1, the sender payload is defined as:

secondary title

Summarize

Summarize

Typed transactions bring many possibilities to the Ethereum network. They can be created without adding a lot of complexity to Ethereum clients, libraries, and other tools available.