The Pulse of Ethereum: Unraveling the Dynamics of Transactions

Photo by Nathan Dumlao on Unsplash

Similar to how a switch dictates the state of a light bulb, transactions play a crucial role in determining the state of the Ethereum blockchain. Every action within the Ethereum network, from altering its state to executing a smart contract, commences with and is termed a transaction.

But what exactly are transactions?

Transactions, in the context of Ethereum, are authenticated messages originating from an Externally Owned Accounts (EOAs) — accounts managed by humans rather than smart contracts. These messages are transmitted to the Ethereum network, and upon validation, become permanently recorded on the Ethereum blockchain. It’s important to note that contracts and the Ethereum platform do not operate autonomously; they rely on the initiation and confirmation of transactions to execute actions.

Ethereum is a singleton state machine — this implies that there is a unified and unchanging state that is consistently maintained across the entire Ethereum network. This shared state evolves as transactions are processed, influencing the overall condition of the system.

Transactions usually require a fee before it can be added to a valid block. When transactions are sent on the Ethereum network, their details are structured using Recursive Length Prefix (RLP) encoding. This encoding method is essential for the efficient transmission of data among network nodes, offering a space-efficient format. It serves as the primary means to format and serialize objects within Ethereum’s execution layer.

RLP encoding streamlines the data transfer process by prioritizing information structure, foregoing explicit labels or symbols in favor of emphasizing the length of each data segment. This method proves efficient in representing transaction details. It’s important to note that, beyond the structured RLP-encoded data, additional components may be included for user interface visualization by client software. These visual enhancements are derived from the transaction but are not inherently part of the transaction message itself. They serve to provide a more user-friendly representation of the transaction data.

TYPES OF TRANSACTIONS

Initially, Ethereum had a single transaction type, but through its ongoing evolution and proposed improvements, it has expanded beyond this singular form.

• Type-0x0: Also known as the legacy transaction, it was the original and supported transaction type introduced when Ethereum was launched in 2015.

Additional transaction types emerged with the introduction of typed transactions in the Ethereum Improvement Proposals (EIP-2718) and the London upgrade of EIP-1559. EIP-2718 introduces an envelope transaction type, presenting an ingenious approach to introducing new transaction types without disrupting existing ones. This involves employing an “envelope” transaction type, maintaining compatibility with older transactions. In its specifications, a transaction is defined as either TransactionType || TransactionPayload or LegacyTransaction.

• Type 0x1: Commonly known as Access List transactions and was introduced through EIP-2930. This proposal outlines a method for sending transactions that incorporate an access list — a detailed list specifying the addresses and storage keys intended for use by the transaction. Notably, Type-1 transactions retain the legacy transaction parameters alongside the inclusion of access lists.
• Type 0x2: Also recognized as the EIP-1559 transaction, it integrates both the access list and fee market changes introduced by the London upgrades.

The distinction between these transaction types lies in their structure, specifically their utilization of access lists or inclusion of the EIP-1559 fee market modifications.

TRANSACTION ARCHITECTURE

Ethereum transaction structure based on types

Transactions are serialized binary messages (or simply, encoded messages in a specific order), structured in a format that is easy to transmit or store, with data represented in binary form. Think of a transaction as a meticulously organized message arranged in a specific order (serialized), composed of 0s and 1s (binary). The structure of a transaction depends on its type, and while various types exhibit both similarities and differences in their components, let’s begin by examining the shared elements.

Chain ID samples

1. Chain ID: Serves as a distinct identifier for various blockchain networks. This unique identifier guarantees the exclusivity of transactions within a specific network, preventing them from being replayed on other networks. This was introduced in EIP-155 as a preventive measure against simple replay attacks.
2. Nonce: Also referred to as a number used only once until a transaction is mined, is a sequentially incrementing counter that prevents transaction duplication. It represents the number of transactions from a specific address, serving as a unique identifier in Ethereum. It acts as a special number that tracks how many times funds have been sent from a particular Ethereum address. If the address is associated with a program, such as a smart contract, the nonce also tallies the number of times that program has created new contracts. Howbeit, the nonce is an attribute specific to the transaction sender’s address and is not explicitly stored as part of an account’s state on the blockchain. Ethereum, utilizing an account-based protocol, relies on the nonce for its functionality, distinguishing it from Bitcoin’s Unspent Transaction Output (UTXO) model.
3. Recipients: Refers to an entity, which can be either an externally owned account or a contract address, identified by a 20-byte Ethereum address typically specified in the ‘to’ field of a transaction. Validation of addresses in Ethereum lacks in-depth scrutiny. Any 20-byte value is deemed valid, even if it corresponds to an address without a matching private key or contract. Sending a transaction to an invalid address automatically burns ethers or forever renders it inaccessible.
4. Transaction value and data: The transaction payload comprises two key fields namely value and data. This payload represents vital information transmitted in a request or received in a response. The “value” field signifies the transaction amount, while the “data” field carries supplementary details or instructions. The data field is for contract related activities such as deployment and execution of a smart contract.

It’s crucial to emphasize that transactions in Ethereum can encompass both value and data, termed as payment and invocation. Payment, involving only value, is typically initiated by an externally owned account. On the other hand, invocation, consisting solely of data, is managed by a contract account, with the data interpreted by the Ethereum Virtual Machine (EVM) as a contract invocation. Transactions may also involve neither value nor data, constituting a potential waste of resources; however, each of these combinations is considered valid in the Ethereum network.

The Hex-Serialized Structure of the Data Payload

• Function selector: This is a specific piece of information used to identify and differentiate functions within a contract. However, in the context of transaction it is broken down to be the first 4 bytes of the keccak-256 hash — a cryptographic hash function. When you apply this function to the prototype of a function, you get a unique and fixed-length sequence of characters (a hash) of a prototype — the string that includes the function name along with the data types of its arguments, presented within parentheses and separated by commas.
• Function arguments: This refers to a structured representation of the function’s input parameters. This organized format adheres to the rules specified by the Application Binary Interface (ABI), ensuring a standardized and interoperable encoding that promotes smooth communication between different software components.

5. Signature - v, r, s: In Ethereum transactions, the signature variables r and s are values generated from an Externally Owned Account’s (EOA) private key using the Elliptic Curve Digital Signature Algorithm (ECDSA). These digital signatures act as virtual stamps, providing proof of authorization for a transaction and ensuring the integrity of the associated data. The r and s are signature values that are numerical and produced during the process of creating a digital signature, both are essential as they form the complete signature. v - this component indicates the odd or even parity of the y-coordinate involved in the signing process. It is used during signature verification. This property serves a crucial role in enhancing security within the signature mechanism

Different component structure

1. Transaction Gas: This represents the computational effort required to execute and validate a transaction.

• Gas price: It refers to the amount of cryptocurrency, known as Ether (ETH), that a user is willing to pay for each unit of gas used to execute a transaction.
• Gas limit: The maximum amount of gas the originator is willing to buy for this transaction.
• Max priority fee per gas: Represents the maximum tip a user is willing to pay to validators, making their transaction more appealing for inclusion in a block. This priority fee increases the likelihood of faster processing, but doesn’t guarantee immediate execution.
• Max fee per gas: It denotes the highest amount a user is willing to pay per unit of gas to secure confirmation for their transaction.

You can learn more about gas here.

TRANSACTION STATUS

An Ethereum transaction progresses through distinct stages until it is successfully mined. These stages include:

Screenshot of some transaction statuses

• Pending: Transactions in this state reside in the mempool (memory pool), awaiting inclusion in a validated block. This delay can occur due to several factors, including network congestion and the gas fee offered. Increasing the gas fee may increase the likelihood of faster processing, but it’s not guaranteed as other factors are also involved.
• Failed: This indicates that an error occurred during its execution. This could be attributed to poorly scripted conditions, insufficient funds, or encountering a revert error in the smart contract.
• Canceled: This indicates that the transaction was withdrawn or overridden before it could be processed. This typically happens when a user submits a new transaction with the same unique identifier (nonce) and a higher gas fee, effectively canceling the original one.
• Confirmed: It signifies that a transaction has been successfully validated, indicating that a validator has accepted the transaction and included it in the next block on the blockchain.
• Replaced: These transactions are no longer eligible for inclusion in a block because they have been superseded by another transaction. This can happen for several reasons, such as: a new transaction with the same unique identifier (nonce) and a higher gas fee is submitted or the original transaction details are modified, such as the amount or recipient.
• Dropped: Transactions that are no longer eligible for processing because nodes on the blockchain have ceased broadcasting them. This situation arises when a node reaches its maximum capacity for pending transactions, a limit that can vary based on different configurations. In such cases, the node prioritizes higher gas fee transactions, potentially leading to the dropping of those with lower fees.
• Queued: This situation arises when a transaction with a lower nonce value has not been confirmed yet. Consequently, subsequent transactions will remain in a queued state until the initial transaction receives confirmation.

CONCLUSION

Just like businesses rely on transactions in the real world, Ethereum depends on them in the digital world. Transactions are the lifeblood of the Ethereum network, going through different stages from waiting to be confirmed, each step telling the story of their journey.

Whether contending with network congestion, fine-tuning gas fees, or overcoming errors, the transactional landscape mirrors the dynamic and resilient nature of the blockchain ecosystem. Insight into these states not only equips users to navigate Ethereum efficiently but also highlights the indispensable role transactions play in upholding the integrity and functionality of this decentralized platform.