Transactions
An Ethereum transaction is a cryptographically signed instruction from an EOA that changes the blockchain state — carrying a nonce for ordering, gas parameters for execution costs, and calldata for smart contract interaction.
A transaction contains: nonce (sender's sequence number, prevents replay), to (recipient or empty for contract creation), value (ETH to transfer), data (calldata for contract interaction), gasLimit (max gas units), maxFeePerGas and maxPriorityFeePerGas (EIP-1559 fee parameters), and a signature (ECDSA v, r, s). The lifecycle: creation → signing → broadcast to mempool → inclusion by a block proposer → execution by EVM → receipt generation. Post-EIP-1559, fees split into a burned base fee (algorithmic, targets 50% block fullness) and a priority fee (tip to the validator). Transaction types: Type 0 (legacy), Type 1 (EIP-2930 access lists), Type 2 (EIP-1559), Type 3 (EIP-4844 blob transactions).
Tradeoffs
Strengths
- Cryptographic signing provides strong authentication without centralized identity
- Nonce system prevents replay attacks and enables ordered execution
- EIP-1559 provides predictable fees and deflationary pressure on ETH
- Blob transactions dramatically reduce L2 data posting costs
Weaknesses
- Failed transactions still consume gas, wasting user funds
- Nonce gaps can block all subsequent transactions
- Gas estimation is imperfect — state can change between estimation and execution
- Transaction finality takes ~13 minutes on Ethereum PoS
Likely Follow-Up Questions
- How does EIP-1559 improve fee estimation compared to legacy gas pricing?
- What happens when a transaction runs out of gas mid-execution?
- How would you handle nonce management for a high-throughput dApp backend?
- Explain the difference between eth_call and eth_sendTransaction.
- How do blob transactions reduce costs for Layer-2 rollups?
- What is transaction replacement and when would you use it?
Related Concepts
Source: editorial — Synthesized from Ethereum Yellow Paper, EIP-1559, EIP-4844, and transaction pool implementations