Different types of transactions exist on Ether, for example, sending ETH to an address, deploying a contract, etc. Before the Berlin network upgrade, there were four different types of transactions on Ether.
Regular transactions with a receiving address, data fields, etc.
Contract deployment transactions without a destination address, data fields for contract code;
Transactions with a v-value signature method, but without the chain ID (pre-EIP-155);
Transactions with v-value signature method but including the chain ID.
Different ethereum clients (clients), libraries (libraries) and other tools analyze each transaction to understand each transaction type. Although there are only four transaction types, there are many complexities and situations to deal with. Technicians should examine all the domains in a transaction to figure out what transaction type it belongs to. This is key for new types of transactions, such as meta transaction, multisig transaction, and other pre-EIP-2718 transaction types.
Ethernet now has a new transaction standard, which was defined and created in EIP-2718 by developer Micah-Zoltu. The typed transaction envelope forms the basis for some and other yet to be developed features on Ether.
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.
Standard transaction envelopes
Ether has a transaction format. Each transaction includes a random number (nonce), gas price, gas limit, destination address, value, data, v, r, and s. These fields are RLP encoded as follows.
RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])
EIP-2718 defines a new broad envelope for typed transactions. In the new standard, transactions are shown as follows.
TransactionType || TransactionPayload
where these fields are defined as
TransactionType: A number between 0 and 0x7f, for a total of 128 possible transaction types.
TransactionPayload: An arbitrary array of bytes defined by the transaction type.
These fields are concatenated to form a typed transaction. The standard does not describe the format of the transaction payload; it can be any arbitrary byte series, encoded by an encoder defined by a new transaction type (e.g., RLP, SSZ, etc.). The simple byte concatenation was chosen because reading the first byte of a byte array does not require any library or tool: you do not need an RLP or SSZ parser to check the transaction type.
This new approach allows new EIPs to introduce transaction types without introducing unnecessary complexity in the existing transaction format, and it becomes easier to distinguish between different transactions using different Ethernet tools (clients, libraries).
A good example of the added complexity is EIP-155, which introduces reply protection by using the chain ID in the transaction. Adding a new field to a transaction parameter would break backwards compatibility, so the chain ID is encoded into the recovery parameter (v) of the transaction signature (v). Using EIP-2718, we can simply create a new transaction type to maintain backwards compatibility.
Backward Compatibility and Original Transactions
One of the big themes of EIP-2718 is backwards compatibility. eIP-2718 uses a full backwards compatibility model, 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 standards that use it. The old transaction format (now called original transaction) is still valid for new transactions on the Ethernet network.
The maximum number of new transaction types is 0x7f, chosen to maintain backward compatibility with these old transactions. rlp-encoded transactions always start with a byte of l, with a parameter greater than or equal to 0xc0, so that typed transactions never conflict with old transactions, and only the first byte is checked to distinguish typed transactions from old ones.
EIP-2718 itself does not define any transaction types, but there are some recommendations to use the new standard.
EIP-1559: ETH 1.0 chain market fee changes.
EIP-2711: sponsored, expiration and batch transactions, also created by developer Micah-Zoltu, which is why EIP-2718 was created.
EIP-2930: Optional access list.
Some of these criteria are described in further detail below.
Why is a new transaction type needed?
New transaction types can support the integration of functionality that would otherwise be handled through Solidity contracts or third-party solutions. Take the example of a transaction that is about to expire. In an existing solution, you can send funds to a Solidity contract, sign a transaction, and send that transaction to a dedicated node so that the transaction has additional parameters, such as an expiration date. The node then handles sending the transaction and ensures that it is executed before the set expiration date, otherwise the transaction is not broadcast. Some dApps and contracts (e.g. Uniswap) have this functionality built in, but it is not easy to implement for most transactions.
EIP-2711 adds this feature locally to the Ethernet network while maintaining backward compatibility with the original type of transaction (as described in the previous section). It does not require smart contracts or specialized nodes to run. However, at this time EIP-2711 is still a draft and it is not clear if this EIP will be added to the Ethernet network anytime soon. It may also be split into multiple smaller EIPs (e.g. EIP-3074).
The new transaction format of EIP-1559
In EIP-1559, there are significant changes to how gas works. Instead of paying miners all of the gas, a portion of the gas is burned. we will not go into detail about all the changes in EIP-1559, but it does specify a new transaction format:
0x02 || RLP([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])
The most significant change is that
Gas prices have been replaced by “highest priority cost per gas” and “highest cost per gas”.
Chain IDs are encoded separately, rather than being 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.
EIP-1559 also provides a way to specify access lists based on EIP-2930. This can reduce the cost of gas for transactions.
Because of the significant changes in the way EIP-1559 works with gas costs, it is not directly compatible with the original transaction. To maintain backward compatibility, EIP-1559 describes a method for upgrading the original transaction to an EIP-1559-compatible transaction. It does this by using the original gas price as the highest priority cost per gas and the highest gas cost.
Raw meta transactions (meta transactions) and batch transactions (batch transactions)
Meta transactions have been around for a few years now, but so far have always required smart contracts. As with expiring transactions, this requires sending ETH to a smart contract, which must specifically support meta transactions.
EIP-2711 makes it possible to have native meta-transactions (called sponsored transactions) and batch transactions without the need for smart contracts. A new transaction format is defined with a transaction type of 0x02 (although this may change since EIP-1559 uses the same transaction type). The transactions are as follows :
0x02 || RLP([. . SenderPayload, . . SenderSignature, … …GasPayerPayload, … .GasPayerSignature])
Basically, EIP-2711 includes an (optional) payload and the signature of the gas payer. This account will be used to pay for the gas in the transaction. For example, it is possible to send ERC-20 tokens from an address without that address holding any ETH. sender payload, signature, etc. are defined based on transaction subtypes. For example, for a transaction with transaction type 1, the sender payload is defined as:
[1, ChildTransaction, nonce, ChainId, ValidUntil, gasLimit, gasPrice]
The Child Transaction is defined as: send address, value, data. This allows multiple addresses, values, and data to be specified in a single transaction. For example, this can be used to invoke ERC-20 approval and transfer in a single transaction.
For a detailed description of all transaction subtypes available in EIP-2711, the reader is advised to read the official documentation.
Typed transactions open up many possibilities for the Ethernet network. They can be created without adding a lot of complexity to Ether clients (clients), libraries (libraries) and other available tools.
New transaction types are not yet widely available, as EIP has only recently been included in the network, but there are some exciting EIPs in development, such as EIP-2711, which adds features such as expired transactions, batch transactions and sponsored transactions (aka meta-transactions). New transaction types can now be defined on Ether, so other EIPs can be easily created.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/learn-about-the-new-transaction-types-on-ether-in-one-article/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.