Learning Objectives – after this chapter you will be able to:
  • Define an Ethereum transaction and list its fields.
  • Identify the three kinds of transactions and the typed-transaction formats (types 0–4).
  • Trace a transaction from signing to finality and read a transaction receipt.
  • Distinguish a transaction from a call.
Ethereum Transactions
  • Transactions are the heart of the Ethereum blockchain: the only way to change Ethereum’s state is to execute a transaction.
  • Interacting with Ethereum – sending ETH, deploying a contract or calling a contract function that changes data – means executing a transaction that updates the blockchain state.
  • A transaction is a cryptographically signed data package (instruction) created by an account.
  • Every transaction requires a fee paid in gas (Chapter 12).
  • Only an EOA can produce (originate) a transaction; contracts react to them.
Fields of a Transaction (EIP-1559 type)
FieldMeaning
chainIdIdentifies the network (1 = Ethereum Mainnet). Prevents a transaction signed for one chain from being replayed on another (EIP-155).
nonceSequence number of the sender’s transactions; must be the next unused value.
toRecipient address (EOA or contract). Empty when deploying a new contract.
valueAmount of ETH to transfer, in wei.
data / inputOptional payload: contract bytecode for deployment, or the encoded function name and arguments for a call.
gasLimitMaximum gas the transaction may consume.
maxPriorityFeePerGasTip per gas for the validator.
maxFeePerGasMaximum total price per gas the sender accepts.
accessListOptional list of addresses and storage slots the transaction will touch (EIP-2930).
Signature (v/yParity, r, s)ECDSA signature made with the sender’s private key. The sender’s address is recovered from this signature – there is no separate “from” field in the signed data.
Kinds and Types of Transactions
By purpose
  • Regular transfer – moves ETH from one account to another.
  • Contract deployment – no to address; data contains the contract code.
  • Contract execution – to is a contract address; data specifies the function and arguments.
By envelope type (EIP-2718 typed transactions)
TypeNameKey feature
0LegacySingle gasPrice field.
1Access-list (EIP-2930)Adds an optional access list.
2Dynamic fee (EIP-1559)Base fee + priority fee model; the most common type today.
3Blob (EIP-4844)Carries “blobs” of data used mainly by Layer-2 rollups.
4Set-code (EIP-7702)Lets an EOA authorise contract code for its account.
Life-cycle of a Transaction
  1. Create & sign – a wallet builds the transaction and signs it with the private key.
  2. Broadcast – it is sent to a node and gossiped to peers.
  3. Mempool – it waits in the pool of pending transactions; nodes check signature, nonce and balance.
  4. Inclusion – a validator includes it in a block (normally preferring higher tips).
  5. Execution & receipt – every node executes it; a receipt records status (success/failure), gas used and event logs.
  6. Finality – after about two epochs (roughly 13 minutes) the block becomes finalized under Proof-of-Stake and cannot be reverted without destroying a large amount of staked ETH.
Transaction vs Call
BasisTransactionCall
Changes stateYesNo (read-only)
SignedYes, by an EOANo signature needed
CostGas fee in ETHFree when executed off-chain on a node
Recorded on-chainYes, in a blockNo
JSON-RPC methodeth_sendRawTransaction / eth_sendTransactioneth_call
Key Takeaways
  • A transaction is a signed instruction from an EOA – the only way to change Ethereum’s state.
  • Key fields: chainId, nonce, to, value, data, gas limit and fee fields, signature.
  • Transactions travel: sign → broadcast → mempool → block → receipt → finality.
Question / Answer (15 questions)

Answer : An Ethereum transaction is a cryptographically signed instruction sent by an Externally Owned Account that changes the state of the network – for example transferring ETH, deploying a contract or calling a contract function.

Answer : Because executing a transaction is the only way to change Ethereum’s state. Balances, contract storage and new contracts all change only through transactions.

Answer : chainId, nonce, to, value, data (input), gasLimit, maxPriorityFeePerGas, maxFeePerGas, accessList and the signature values (yParity/v, r, s).

Answer : The sender’s public key, and therefore its address, can be recovered mathematically from the ECDSA signature and the signed data. Including a separate from field is unnecessary.

Answer : chainId identifies the network the transaction is meant for (1 for Ethereum Mainnet). Introduced by EIP-155, it prevents a transaction signed for one chain from being replayed on another chain.

Answer : A deployment transaction has an empty to field and carries the contract’s creation bytecode in the data field. A normal transfer has a recipient address and usually an empty data field.

Answer : The ABI-encoded call: a 4-byte function selector (derived from the Keccak-256 hash of the function signature) followed by the encoded arguments.

Answer : Type 0 legacy (single gasPrice); type 1 access-list transactions (EIP-2930); type 2 dynamic-fee transactions (EIP-1559 base fee + tip); type 3 blob transactions (EIP-4844, data for rollups); type 4 set-code transactions (EIP-7702, an EOA authorises contract code).

Answer : The mempool is the set of valid, pending transactions that nodes have received but that have not yet been included in a block.

Answer : A receipt records whether the transaction succeeded or failed (status), the gas used, the cumulative gas used in the block, the logs (events) emitted, and a bloom filter for quickly searching those logs.

Answer : Finality means a block can no longer be reverted unless an attacker is willing to have a very large amount of staked ETH destroyed by slashing. On Ethereum, blocks usually become finalized after about two epochs, roughly 13 minutes.

Answer : Only one of them can be included. Validators typically choose the one with the higher fee, which is how users “speed up” or “cancel” a pending transaction.

Answer : A transaction is signed, costs gas, can change state and is recorded in a block. A call (eth_call) is executed locally on a node, does not change state, needs no signature and costs the user nothing.

Answer : Yes. If a transaction reverts or runs out of gas after being included in a block, its state changes are undone but the gas consumed is still paid to compensate the network for the computation.

Answer : The nonce enforces a strict sequence. A transaction with nonce 5 cannot be included until the transaction with nonce 4 from the same account has been included, which prevents replay and ensures predictable ordering.
MCQ Test : Check Your Understanding (5 questions)

Select an option and press Check Answer, or answer all questions and press Submit Test to see your score. Each answer comes with an explanation.

Q1. Which field is EMPTY in a contract-deployment transaction?

Show Answer

Correct Answer : C. to
Deployment transactions have no recipient; the data field carries the bytecode.

Q2. Which EIP introduced chainId-based replay protection?

Show Answer

Correct Answer : A. EIP-155
EIP-155 added the chain ID to the signed data.

Q3. Blob transactions used mainly by Layer-2 rollups are transaction type:

Show Answer

Correct Answer : D. 3
Type 3 transactions (EIP-4844) carry data blobs.

Q4. A read-only request to a contract that changes no state is made using:

Show Answer

Correct Answer : B. eth_call
eth_call executes locally without creating a transaction.

Q5. Where are pending transactions held before they are included in a block?

Show Answer

Correct Answer : A. Mempool
The mempool stores valid transactions waiting to be included.

Bibliography/References

The notes, questions and MCQs on this page are original explanations written for this course. The works listed below were consulted and are cited for attribution and further reading. Product names, logos and trademarks belong to their respective owners. Short quotations, where used, are marked and attributed.

  1. ethereum.org. (n.d.). Transactions. Ethereum Developer Documentation. https://ethereum.org/en/developers/docs/transactions/
  2. Ethereum Improvement Proposals. (2016). EIP-155: Simple replay attack protection. https://eips.ethereum.org/EIPS/eip-155
  3. Ethereum Improvement Proposals. (2020). EIP-2718: Typed Transaction Envelope. https://eips.ethereum.org/EIPS/eip-2718
  4. Ethereum Improvement Proposals. (2020). EIP-2930: Optional access lists. https://eips.ethereum.org/EIPS/eip-2930
  5. Ethereum Improvement Proposals. (2019). EIP-1559: Fee market change for ETH 1.0 chain. https://eips.ethereum.org/EIPS/eip-1559
  6. Ethereum Improvement Proposals. (2022). EIP-4844: Shard Blob Transactions. https://eips.ethereum.org/EIPS/eip-4844
  7. Ethereum Improvement Proposals. (2024). EIP-7702: Set Code for EOAs. https://eips.ethereum.org/EIPS/eip-7702
  8. ethereum.org. (n.d.). Proof-of-stake (PoS). Ethereum Developer Documentation. https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/
  9. Wood, G. Ethereum: A Secure Decentralised Generalised Transaction Ledger (Ethereum Yellow Paper). https://ethereum.github.io/yellowpaper/paper.pdf