Demystifying the Ethereum Transactions

Hello everyone..

Welcome to another day of exploring Web3 Engineering. Since we are diving deep into the Ethereum protocol in our series, today let us understanding the type of transactions that we can make on the network and which is better for what and when. So, without any further ado, let’s get started.

Transaction

In the context of the blockchain world, a transaction is the fundamental cause of change in the state of the network which means a transaction is supposed to update the blockchain from one state to another like a finite machine.

As we all know, a group of transactions are picked up to form a block with the latest state, and this block is added to progress the network. And the miners get rewarded for executing the user’s transactions.

Types of Transactions

If this sounds all simple, why bother having differ types of transactions ? Actually what type of transactions that users can make on the Ethereum blockchain ?

The main goal of having different types of transactions is obviously to save Gas.

Ethereum so far, have introduced 5 different types of transactions which have different kinds of estimations to save users gas fee and to make the network more approachable.

1. Type 0 (Legacy)

   • It is the primary transaction type that Ethereum introduced to calculate the gas fee for a transaction.

   • The transaction schema is as follows

   •     {
           "from": "0x...",              // Sender's address
           "to": "0x...",                // Recipient's address (optional for contract creation)
           "gas": "0x...",               // Gas limit
           "gasPrice": "0x...",          // Gas price per unit (in wei)
           "value": "0x...",             // Amount of Ether to send (in wei)
           "data": "0x...",              // Input data (for contract interaction or deployment)
           "nonce": "0x..."              // Number of transactions sent from the sender's address
         }
     

2. Type 1 (EIP 2930) - Access list Transaction

   • Type 1 transactions are introduced with EIP 2930 in the Belin upgrade which introduced a new parameter to the request object called access_list.

   • This access_list contains the list of addresses and the storage keys of the data that the transaction is going to interact with, so that the EVM can prefetch them into the execution memory which reduces the gas costs while executing the transactions.

   • These access list is introduced warm and cold memory. Warm data is the part of the state tree which is already brought into the execution environment for the transaction while on the other hand the cold data is yet to brought into the execution space. Warm data read/write takes 100 gas while the cold storage (or first time retrieval) takes 1900 gas. With this, he access_list helps to reduce gas costs on complex transaction which uses same memory multiple times.

   • The transaction object of the EIP 2930 transaction looks like below:

       {
         "type": "0x1",                      // Explicitly specify type 0x1 (optional in some clients)
         "from": "0x...",                    // Sender address
         "to": "0x...",                      // Recipient (null for contract creation)
         "gas": "0x...",                     // Gas limit
         "gasPrice": "0x...",               // Price per unit of gas (same as legacy, no base/priority fee here)
         "value": "0x...",                   // Value to send in wei
         "data": "0x...",                    // Input data
         "nonce": "0x...",                   // Sender's nonce
         "chainId": "0x1",                   // Chain ID for replay protection
         "accessList": [                     // New in EIP-2930
           {
             "address": "0x...",            // Address being accessed
             "storageKeys": [              // Array of storage slot keys (as hex strings)
               "0x...",
               ...
             ]
           },
           ...
         ]
       }
     

3. Type 2 (EIP 1559) - Dynamic Fee Transaction

   • In the London hard, a new gas calculation scheme has been introduced that has 2 new attributes called base fee and priority fee. Base fee is the amount of the gas that we are willing to pay for the actual execution and then the priority fee is the amount we are willing pay to prioritize our execution. Higher the priority fee, faster the transaction gets executed.

   • The transaction object for the Type 2 transaction looks like below

       {
         "from": "0x...",                   // Sender address (required)
         "to": "0x...",                     // Recipient address (optional for contract creation)
         "value": "0x...",                  // Amount of ETH to send (in wei, hex)
         "gas": "0x...",                    // Gas limit (in hex)
         "maxPriorityFeePerGas": "0x...",  // Tip to the miner (in wei)
         "maxFeePerGas": "0x...",          // Max total fee (tip + baseFee, in wei)
         "nonce": "0x...",                 // Transaction count of the sender
         "data": "0x...",                  // Optional input data
         "accessList": []                  // Optional EIP-2930 access list
       }
     

   • We can notice that there are two new parameters called maxPriorityFeePerGas which is the maximum gas fee we are willing to pay as priority and maxFeePerGas is the amount of gas we are willing to pay for execution.

   • And it also contains access list for the backward compatibility.

4. Type 3 (EIP 4844) - Blob Transactions

   • In the Dencun upgrade of the Ethereum blockchain, a new type of storage system is introduced to the network to store data as BLOBS. And to upload these blobs, a new transaction type is also introduced. Even though a regular day to day user won’t be using this, it is used by projects that need to store huge amounts of data onchain like layer 2 networks which provides big amounts of storage in cheaper prices.

   • The transaction object for the blob transaction is as follows:

   •   {
         "type": "0x3",
         "chainId": "0x1",                          // Mainnet (hex)
         "nonce": "0x0",                            // Sender's transaction count
         "maxPriorityFeePerGas": "0x59682f00",      // Tip to the validator
         "maxFeePerGas": "0x59682f080",            // Max total fee
         "to": "0x3535353535353535353535353535353535353535",  // Recipient
         "value": "0x0",                            // ETH to send (in wei)
         "data": "0x",                              // EVM calldata
         "accessList": [],                          // Optional (usually empty)
         "maxFeePerBlobGas": "0x1e8480",            // Maximum blob gas fee (new)
         "blobVersionedHashes": [                   // References to blobs (KZG commitments)
           "0x010203...32-bytes"
         ]
       }
     

   • There are 2 new fields in the object. they are maxFeePerBlobGas and blobVersionedHashes. The versioned hashes contains the KZG commitment hashes of the blobs included in the transaction. And the maxFeePerBlockGas contains the maximum block gas can be spent for storing the blobs.

   • It is also backward compatible with EIP 1559 and EIP 2930.

5. Type 4 (EIP 7702) - Set Code Transactions

   • The Pectra upgrade has brought a new type of transactions called Set Code transactions that are used to temporarily / persistently provide smart contract behavior to a EOA address.

   • This is on testing phase right now and on Hoodi testnet of the Ethereum network. It contains a new attribute called authorizationList which contains the smart contract address that we want our EOA to mimic.

   •   {
         "type": "0x04",
         "chainId": "0x1",
         "nonce": "0x0",
         "maxPriorityFeePerGas": "0x59682f00",
         "maxFeePerGas": "0x59682f080",
         "gas": "0x5208",
         "to": "0xRecipientAddress",
         "value": "0x0",
         "data": "0x",
         "accessList": [],
         "authorizationList": [
           {
             "contractCode": "0x6001600101...",
             "yParity": "0x0",
             "r": "0x...",
             "s": "0x..."
           }
         ]
       }
     

   • As we can that the EIP 7702 transaction is backward compatible with EIP 1559 transaction

There is always a possible for transaction types to emerge in the Ethereum ecosystem to optimize the transaction execution and save gas costs.

Please comment down if you have questions.

That’s all for this article. Thank you