What Is a Blockchain Transaction?

A blockchain transaction is a cryptographically signed instruction that changes the state of the blockchain. In the simplest case, it transfers value from one address to another. In more complex cases (particularly on smart contract platforms like Ethereum), it can execute arbitrary computational logic, deploy programs, or interact with decentralized applications. Understanding the transaction lifecycle—from creation to finality—is fundamental to working with any blockchain system.

Transaction Fields

While specifics vary by blockchain, an Ethereum transaction (post-EIP-1559) contains the following fields:

Transaction Lifecycle

1. Construction

The sender's wallet assembles the transaction by populating the fields above. The nonce is fetched from the network (it must equal the sender's current transaction count), the gas parameters are estimated based on current network conditions, and the data field is encoded if the transaction involves a smart contract call.

2. Signing

The transaction is serialized (typically using RLP encoding on Ethereum), hashed, and signed with the sender's private key using ECDSA. The resulting signature (v, r, s) is appended to the transaction. At this point, the transaction is a self-contained, tamper-proof packet: any modification to the data would invalidate the signature.

3. Submission and Mempool

The signed transaction is submitted to a node via its RPC interface. The receiving node performs initial validation:

• Is the signature valid?
• Does the sender have sufficient balance to cover value + (gasLimit × maxFeePerGas)?
• Is the nonce correct (equal to the sender's current nonce)?
• Is the gas limit at least the minimum (21,000 for a simple transfer)?

If valid, the node adds the transaction to its mempool (memory pool)—a holding area for pending, unconfirmed transactions—and propagates it to connected peers via the gossip protocol. Each node maintains its own mempool, and the contents may vary slightly between nodes.

The mempool is not a single global queue. Each node has its own mempool, and there are no guarantees about transaction ordering at this stage. Block producers select and order transactions from their own mempool according to their own priorities (typically maximizing fees).

4. Block Inclusion

A block producer (miner or validator) selects transactions from its mempool to include in the next block. Selection is typically based on gas price: transactions offering higher fees per gas unit are prioritized. The block producer executes each transaction in order, updating the state (account balances, contract storage), collecting gas fees, and recording the outcome in a transaction receipt.

Once the block is finalized and broadcast to the network, the transaction is considered included. The mempool removes the transaction (and any now-invalid transactions from the same sender with the same or lower nonce).

5. Confirmation

A transaction gains confirmations as subsequent blocks are added on top of the block containing it. One confirmation means the transaction is in the latest block. Two confirmations means one additional block has been built on top. More confirmations mean it is harder (more expensive) for a chain reorganization to reverse the transaction.

6. Finality

Finality is the point at which a transaction is considered irreversible. Different blockchains achieve finality through different mechanisms:

• Probabilistic finality (Bitcoin): A transaction is never technically "final" in an absolute sense. With each confirmation, the probability of reversal decreases exponentially. After 6 confirmations, the probability of a reversal is considered negligible for practical purposes.
• Economic finality (Ethereum PoS): After two epochs (~13 minutes), a block is "finalized" by the consensus mechanism. Reversing a finalized block would require slashing at least one-third of all staked ETH—worth billions of dollars—making it economically irrational.
• Absolute finality (BFT-based chains): Some consensus mechanisms (like Tendermint, used by Cosmos) provide instant finality: once a block is committed, it cannot be reversed under any circumstances short of a protocol-level failure.

Transaction Types on Ethereum

Ethereum currently supports multiple transaction types, identified by a type prefix:

• Type 0 (Legacy): The original transaction format with a single gasPrice field.
• Type 1 (EIP-2930): Introduces access lists—a way to pre-declare which storage slots and addresses the transaction will touch, potentially reducing gas costs.
• Type 2 (EIP-1559): The current standard, replacing gasPrice with maxFeePerGas and maxPriorityFeePerGas for more predictable fee estimation.
• Type 3 (EIP-4844): Introduced with the Dencun upgrade, these "blob transactions" carry large data payloads for Layer 2 rollups at reduced cost.

The Transaction Nonce

The nonce is a frequently misunderstood field. It is a sequential counter that serves two purposes:

1. Ordering: Transactions from a given sender must be processed in nonce order. If your account's current nonce is 5, the next transaction must have nonce 5. A transaction with nonce 7 will sit in the mempool until transactions with nonces 5 and 6 are confirmed.
2. Replay prevention: Because each nonce can only be used once, a signed transaction cannot be submitted again after it has been included in a block.

Nonce management is a common source of issues for automated systems. If a transaction gets stuck (e.g., gas price too low), all subsequent transactions from that sender are also blocked. The standard remedy is to resubmit the stuck transaction with a higher gas price using the same nonce, effectively replacing it.