Transaction (Tx)

A transaction is atomic, meaning it either executes completely or fails entirely, with no partial state changes. This is enforced by the blockchain's execution environment (e.g., the Ethereum Virtual Machine). If any operation within the transaction reverts, all prior operations are rolled back, ensuring consistency and preventing invalid intermediate states.

Every transaction is cryptographically signed by the sender's private key. This signature proves:

• Authenticity: The transaction originated from the holder of the private key.
• Non-repudiation: The sender cannot later deny authorizing it.
• Integrity: The transaction data has not been altered after signing. The signature is verified by network nodes using the sender's public address before the transaction is accepted into a block.

The transaction hash is a unique, fixed-length identifier generated by hashing the transaction data (e.g., using Keccak-256). It serves as a cryptographic fingerprint and is used to:

• Reference the transaction on block explorers.
• Provide immutable proof of the transaction's existence and content.
• Enable light clients to verify transaction inclusion via Merkle proofs. Example: 0x2f9c...b7a1

Transactions consume computational resources, paid for with gas. Key concepts:

• Gas Limit: The maximum units of gas the sender is willing to consume.
• Gas Price (Base Fee + Priority Fee): The price per unit of gas, denominated in the native token (e.g., ETH, MATIC).
• Transaction Fee: Gas Used * (Base Fee + Priority Fee). This mechanism prevents network spam and compensates validators. Insufficient gas causes the transaction to revert.

The nonce is a sequential number tied to an account, representing the count of transactions sent from that address. It ensures:

• Ordering: Transactions are processed in the order they were created.
• Replay Protection: A signed transaction cannot be broadcast again (replayed) on the same network. The network will only accept a transaction if its nonce is exactly one greater than the last recorded nonce for that account.

The transaction payload contains the core instruction data. For a simple transfer, it's just a value field. For a smart contract interaction, it includes:

• To Address: The contract's address.
• Calldata: Encoded function selector and arguments, specifying which function to call and with what parameters. This data is executed by the EVM, and reading it is essential for decoding transaction intent on block explorers.

A transaction in the Unspent Transaction Output (UTXO) model consumes existing outputs as inputs and creates new outputs. Each UTXO is a discrete, indivisible chunk of value, like digital cash.

• Key Concept: A transaction must spend entire UTXOs; 'change' is created as a new UTXO.
• Parallelism: Independent UTXOs can be processed simultaneously, enhancing scalability.
• Example: Spending a 1 BTC UTXO to send 0.3 BTC creates two new UTXOs: 0.3 BTC to the recipient and 0.7 BTC as change back to the sender.

A transaction in the Account-Based Model updates the global state of accounts, which have persistent balances and storage. It's analogous to a bank ledger.

• Key Concept: Transactions reference sender and receiver account addresses, deducting from one balance and adding to another.
• Nonce: Each account transaction includes a sequential nonce to prevent replay attacks and ensure ordering.
• Gas: Execution requires gas, paid in the native token, to compensate for computational work (EVM) or bandwidth (Solana).

An Ethereum Virtual Machine transaction is a standardized RLP-encoded object containing specific fields that validators execute.

Core Fields:

• nonce: Sequence number from the sender.
• gasPrice / maxFeePerGas: Price willing to pay per unit of gas.
• gasLimit: Maximum computational units allowed.
• to: Recipient address (or empty for contract creation).
• value: Amount of ETH to transfer.
• data: Bytecode for contract calls or arbitrary data.
• v, r, s: Cryptographic signature components from the sender's ECDSA.

In Cosmos SDK-based blockchains, a Tx is a wrapper containing one or more Msg objects, each representing a specific intent (e.g., MsgSend, MsgDelegate).

• Bundling: A single signed transaction can contain multiple messages, executed atomically.
• Authentication: The transaction includes signatures from all required signers for the contained messages.
• Fees: Payers specify fees, which are deducted before message execution. Failed messages cause the entire transaction to revert.

Solana transactions are optimized for parallel execution and contain a compact, fixed-length format.

• Structure: Includes a recent blockhash, array of account addresses, a compact instruction, and signatures.
• Account List: Pre-declares every account the transaction will read from or write to, enabling secure parallel processing.
• Native Programs: Transactions invoke instructions on native programs (e.g., System, Token) or deployed smart contracts.
• Fee Markets: Transaction priority is influenced by a priority fee paid on top of the base fee.

Front-running occurs when a network participant (often a bot) sees a pending transaction in the mempool and submits their own transaction with a higher gas fee to execute first, profiting at the original user's expense. This is a subset of Maximal Extractable Value (MEV), the total value that can be extracted from block production beyond standard block rewards. Common examples include:

• Sandwich attacks on DEX trades.
• Arbitrage between liquidity pools.
• Liquidations in lending protocols.

A replay attack happens when a valid transaction signed for one blockchain network is maliciously rebroadcast and executed on another network. This is a significant risk during chain splits or hard forks (e.g., Ethereum/ETC split) if transaction formats are identical. Protection requires:

• Chain ID inclusion in the signing scheme (EIP-155).
• Using distinct addresses or nonces across forked chains.

Every account has a nonce, a sequentially incrementing counter that prevents transaction duplication and ordering attacks. Security risks include:

• Stuck transactions: A pending transaction with a low gas price can block all subsequent transactions (higher nonces).
• Nonce prediction attacks: If predictable, an attacker can pre-sign future transactions.
• Race conditions: Two transactions sent in rapid succession with the same nonce will cause one to fail.

Transaction security relies entirely on cryptographic signatures. Key risks involve:

• Private key compromise: Loss leads to irreversible fund theft.
• Malicious signing requests: Users may sign a seemingly harmless message that is actually a valid transaction (signature malleability).
• Approval exploits: Infinite or excessive ERC-20 approve() transactions can allow drained allowances later.
• Fake signature verifiers: Malicious contracts that mimic legitimate ones.

The mempool (transaction pool) is public by design, exposing transactions before confirmation. This creates vulnerabilities:

• Transaction origination IP leakage: Can link transactions to physical locations.
• Time-bandit attacks: Reorganizing blocks to censor or reorder transactions.
• DoS vectors: Spamming the network with low-fee transactions to bloat the mempool. Solutions include private transaction relays, commit-reveal schemes, and encrypted mempools.

The gas mechanism, which measures computational work, is a core attack surface.

• Gas griefing: An attacker lures a contract into an operation that consumes all its gas, causing the transaction to revert.
• Gas price manipulation: In PoW networks, miners could collude to artificially inflate gas prices.
• Out-of-gas exceptions: Transactions that fail due to insufficient gas can leave state changes partially applied, requiring careful error handling with checks-effects-interactions patterns.

A cryptographic fingerprint (hash) that uniquely identifies a transaction on the blockchain. It is generated by hashing the transaction data and serves as a permanent, immutable reference for lookup and verification.

• Primary Identifier: Used to query transaction status on a block explorer.
• Immutability: Any change to the transaction data results in a completely different hash.
• Example: 0x2a7b...c89d (Ethereum) or a long alphanumeric string in Bitcoin.

A sequence number for transactions originating from a specific account, preventing replay attacks and ensuring order.

• Account-based Chains (Ethereum): A per-account counter that must increment with each new transaction.
• UTXO-based Chains (Bitcoin): Used internally to prevent double-spends within a block.
• Critical for Security: A transaction with an incorrect nonce will be rejected by the network.

The computational pricing mechanism on Ethereum Virtual Machine (EVM) chains. Gas measures the computational work required, while Gas Price is the amount of native token (e.g., ETH) paid per unit of gas.

• Transaction Fee: Calculated as Gas Used * Gas Price.
• Purpose: Compensates validators and prevents network spam.
• EIP-1559: Introduced a base fee (burned) and a priority fee (tip) to improve fee market efficiency.

The waiting area for unconfirmed transactions. Nodes broadcast signed transactions to this network-wide pool, where validators select them for inclusion in the next block.

• Ordering Mechanism: Validators often prioritize transactions with higher fees.
• Dynamic State: Transactions can be replaced or dropped if fees are too low (stuck tx).
• Frontrunning Risk: Public mempool visibility can lead to MEV (Maximal Extractable Value) exploits.

A cryptographic proof generated using the sender's private key, authorizing the transaction and ensuring its integrity.

• Authentication: Proves the owner of the originating address initiated the transaction.
• Data Integrity: Any tampering with the signed transaction data invalidates the signature.
• Algorithms: Common schemes include ECDSA (Bitcoin, Ethereum) and EdDSA (Solana).

The irreversible confirmation that a transaction is permanently settled on the blockchain. Mechanisms vary by consensus model.

• Probabilistic Finality (PoW): Security increases with each subsequent block (e.g., Bitcoin's 6-block confirmation).
• Absolute Finality (PoS/PBFT): Once a block is finalized by the validator set, it cannot be reverted (e.g., Ethereum post-merge, Cosmos).
• Instant Finality: Achieved by some high-throughput chains (e.g., Solana, BNB Chain) via optimized consensus.