Transaction Lifecycle

A transaction is created by a user's wallet, specifying the recipient, amount, and data. It is then cryptographically signed with the sender's private key, creating a digital signature that authorizes the transfer and proves ownership without revealing the key.

• Key Components: Nonce, gas price, recipient address, value, data payload.
• Example: Using MetaMask to send 1 ETH, setting a gas limit of 21,000 units.

The signed transaction is broadcast to the peer-to-peer network. Nodes validate its basic structure and signature before relaying it. Valid transactions enter the mempool (memory pool), a waiting area of pending transactions visible to network participants.

• Purpose: Enables network-wide awareness and allows miners/validators to select transactions for inclusion.

A miner (Proof of Work) or validator (Proof of Stake) selects transactions from the mempool, orders them, and assembles a candidate block. The block is then validated by other nodes, which check:

• Double-spend attempts.
• Sufficient account balance.
• Correct execution of any smart contract code.
• Adherence to all consensus rules.

During block validation, the Ethereum Virtual Machine (EVM) executes the transaction's logic. This changes the global state of the blockchain:

• Transfer: Deducts balance from sender, adds to recipient.
• Contract Call: Executes smart contract code, potentially updating stored data.
• Gas: Computation fees are paid to the block producer; unused gas is refunded.

Finality is the irreversible confirmation of a transaction. Mechanisms differ:

• Probabilistic Finality (PoW): Security increases with each subsequent block. 6+ confirmations is a common standard.
• Absolute Finality (PoS): Transactions are finalized after a specific checkpoint, often within one or two epochs. Once final, the transaction is permanently settled into the canonical chain's history.

Transactions can fail after being included in a block, resulting in a state reversion. Common causes include:

• Insufficient gas: The gasLimit is exceeded during execution.
• Revert opcode: A smart contract intentionally aborts execution (e.g., a failed condition).
• Invalid opcode: The EVM encounters an unrecognized instruction. Key Note: The sender still pays gas for all computation performed up to the point of failure.

A transaction is a set of inputs (references to unspent outputs) and outputs (new ownership locks). The lifecycle is atomic and stateless:

• Creation: Constructed by a wallet, referencing previous UTXOs.
• Validation: Nodes check cryptographic signatures and that inputs are unspent (no double-spend).
• Finality: Achieved after sufficient proof-of-work confirmations; transactions are irreversible but probabilistic.

Transactions interact with stateful accounts (externally owned or contract). The lifecycle is sequential and gas-driven:

• Creation: Specifies a nonce, gas limit, and target address/data.
• Execution: Validators run the transaction in the EVM, updating global state and consuming gas.
• Finality: Varies by consensus. On mainnet, probabilistic via proof-of-work (historically) or via Gasper (proof-of-stake). Layer 2s may offer faster, softer finality.

Optimized for parallel execution and speed, using a Proof-of-History (PoH) clock.

• Propagation: Transactions are forwarded to the current leader validator.
• Processing: The leader sequences transactions using PoH, enabling parallel execution in Sealevel runtime.
• Finality: Achieved optimistically and rapidly as validators vote on PoH sequences, with confirmation times under 400ms. True finality is reached after a supermajority of stake confirms a block.

Transactions occur within sovereign, interoperable blockchains (zones).

• Lifecycle: Standard Tendermint BFT finality within a zone (1-6 second block times).
• Cross-Chain: An Inter-Blockchain Communication (IBC) packet is a special transaction type. It undergoes:
  1. Proof Creation: A proof of packet commitment is generated on the source chain.
  2. Relaying: An off-chain relayer submits the proof to the destination chain.
  3. Verification & Execution: The destination chain's IBC module verifies the proof and executes the packet's action.

Transactions are executed off-chain but settled on a Layer 1 (L1). The lifecycle has two phases:

• L2 Execution & Compression: User transactions are executed in a rollup sequencer, batched, and compressed into a single state root or proof.
• L1 Settlement & Finality: The batch data is posted to L1 (as calldata or in a blob). For Optimistic Rollups, finality involves a challenge period (e.g., 7 days). For ZK-Rollups, a validity proof (SNARK/STARK) provides near-instant cryptographic finality upon L1 verification.

The point of no return for a transaction varies:

• Probabilistic Finality (Bitcoin, older Ethereum): Security increases with confirmations; reversals are exponentially costly.
• Instant Finality (Tendermint BFT, Algorand): Once a block is committed by validators, it is irreversible.
• Economic Finality (Ethereum's Casper): Validators stake ETH; reversing a finalized block leads to slashing of the entire stake.
• Soft Finality / Liveness (Solana, high-speed chains): Transactions are treated as final by clients after a short, optimistic window, with fallback to social consensus in extreme cases.

Front-running occurs when a network participant (often a validator or bot) observes a pending transaction in the mempool and submits their own transaction with a higher fee to be processed first, profiting from the anticipated price movement. This is a subset of Maximal Extractable Value (MEV), which encompasses all value that can be extracted from block production beyond standard block rewards, often at the expense of ordinary users.

• Common Forms: Arbitrage, liquidations, and sandwich attacks.
• Mitigations: Use of private transaction relays, commit-reveal schemes, and fair sequencing services.

A transaction revert is the reversal of all state changes caused by a transaction, triggered when execution fails. This is a core security feature that prevents invalid state transitions but can indicate failed interactions.

• Causes: Insufficient gas, failed require/assert statements, or calls to non-existent contracts.
• Result: The user pays gas for computation up to the point of failure (except for an out-of-gas error on the Ethereum Virtual Machine), but no state changes are applied.
• Security Implication: Reverts protect users from paying for unsuccessful operations, but failed transactions still incur costs.

A nonce is a sequential number assigned to each transaction from an account, preventing replay attacks and ensuring order. Mismanagement can lead to transaction failures or security issues.

• Stuck Transactions: If a transaction with a lower nonce is pending or dropped, all subsequent transactions (with higher nonces) will be queued and cannot be processed.
• Replay Attacks: On different chains sharing an address format (e.g., Ethereum Mainnet vs. a testnet), a correctly signed transaction could be maliciously rebroadcast.
• Mitigation: Wallets and clients must track nonces accurately, and users should be aware of chain-specific signatures.

Gas is the unit of computational work. Incorrect gas estimation or sudden network congestion can cause transactions to fail or become economically non-viable.

• Out-of-Gas Errors: Transaction runs out of gas before completion, reverting all changes and consuming all gas spent.
• Fee Market Volatility: During high demand, base fees spike in EIP-1559 systems, and users must set priority fees (tips) high enough to incentivize inclusion.
• Security Risk: Underestimating gas for complex interactions (like multi-step DeFi swaps) can lead to partial execution and financial loss, as the transaction reverts after consuming the allotted gas.

The mempool (transaction pool) is a publicly visible waiting area for unconfirmed transactions, creating privacy and censorship vulnerabilities.

• Privacy Leak: Transaction details (sender, recipient, amount, intent) are exposed before confirmation, enabling targeted attacks.
• Censorship: Validators or mining pools can choose to ignore or delay transactions from specific addresses or containing certain data (e.g., Tornado Cash interactions).
• Mitigations: Use of private RPC endpoints or encrypted mempools (e.g., via Flashbots Protect) to submit transactions directly to block builders.

A chain reorganization occurs when a different canonical chain with more accumulated proof-of-work (PoW) or a longer attestation weight (PoS) overtakes the current one, causing previously confirmed transactions to become unconfirmed.

• Failure Impact: Transactions thought to be final (e.g., a confirmed exchange deposit) can be temporarily invalidated, leading to double-spend risks if merchant confirmation times are too short.
• Depth Rule: Exchanges and services often wait for multiple block confirmations (e.g., 6+ blocks on Ethereum) to reduce reorg risk to near zero.
• Security Consideration: Longer reorgs are possible during network attacks or severe consensus failures, though they are rare in stable networks.

The transaction pool, or mempool, is a network node's holding area for pending, unconfirmed transactions. It acts as a waiting room where transactions are broadcast, validated, and prioritized before being included in a block by a miner or validator.

• Nodes verify digital signatures and check for double-spending.
• Miners select transactions from the pool based on gas fees or transaction fees to maximize revenue.
• The size and congestion of the mempool directly impact network fees and confirmation times.

A nonce (number used once) is a sequential counter attached to every transaction from a specific account. It ensures transaction order and prevents replay attacks.

• The first transaction from an account has a nonce of 0, incrementing by one for each subsequent transaction.
• The network rejects transactions with an incorrect nonce, enforcing sequential processing.
• It is a critical component for maintaining state consistency across the network.

Gas is the unit measuring computational work required for transaction execution. Users pay transaction fees (gas price * gas used) to compensate validators.

• In Ethereum, users specify a max priority fee (tip) and max fee per gas unit in a dynamic fee market (EIP-1559).
• In Bitcoin, fees are typically set as a satoshi-per-byte rate, competing for block space.
• High network demand leads to fee auctions, where users bid higher to get faster inclusion.

Finality is the guarantee that a validated block and its transactions are irreversible and permanently added to the blockchain. The mechanism varies by consensus.

• Probabilistic Finality (Proof-of-Work): Confidence increases with each subsequent block. Reversing a transaction requires a chain reorganization.
• Absolute Finality (Proof-of-Stake, BFT): Once a block is finalized by a supermajority of validators, it cannot be reverted except by a coordinated attack.
• Instant Finality is a goal of many modern protocols to reduce settlement risk.

A state transition is the process by which a transaction changes the global state of the blockchain. The state is a snapshot of all account balances, contract code, and storage.

• Executing a transaction applies a deterministic function: NEW_STATE = APPLY(OLD_STATE, TRANSACTION).
• Invalid transactions (e.g., insufficient balance) cause the state transition to fail, reverting all changes.
• This mechanism is core to the functionality of smart contracts and decentralized applications.

Event logs are inexpensive, non-executable data emitted by smart contracts during transaction execution. They are stored separately from the blockchain state but are cryptographically linked to it.

• Used to record outcomes (e.g., a token transfer, a governance vote) for off-chain applications to query.
• DApps and indexers like The Graph rely on logs to track contract activity efficiently.
• Logs are immutable and provide a verifiable history of contract interactions.