Ethereum Transactions
In Ethereum, a transaction is a digitally signed message sent from one account to another. It changes the state of the Ethereum blockchain and may:
- Transfer ether (ETH) between users.
- Trigger execution of a smart contract (message call).
- Deploy a new smart contract on the blockchain (contract creation).
2. Types of Ethereum Transactions
| Transaction Type | Description |
|---|---|
| Message Call Transaction | Sends a message (function call or value transfer) to an existing contract or account. |
| Contract Creation Transaction | Used to deploy a new smart contract on the blockchain. |
3. Fields in a Standard Ethereum Transaction
All Ethereum transactions contain the following common fields:
| Field | Description |
|---|---|
| Nonce | A counter to keep track of the number of transactions sent by the sender. Prevents replay attacks. |
| Gas Price | Amount of Wei the sender is willing to pay per unit of gas. Acts as a transaction fee. |
| Gas Limit | The maximum gas units allowed for the transaction execution. |
| To | 20-byte address of the recipient. Empty for contract creation transactions. |
| Value | Amount of ETH (in Wei) to be transferred. |
| Data / Init | Data: input for a message call; Init: initialization bytecode for contract creation. |
| V, R, S | Components of the ECDSA digital signature used to verify the sender and authorize the transaction. |
4. Specific Fields Based on Transaction Type
A. Message Call Transaction
Used to interact with existing contracts or EOAs (Externally Owned Accounts).
| Field | Meaning |
|---|---|
| To | Address of the recipient or contract |
| Data | Encoded input data for contract function |
| Value | ETH to send (optional) |
✅ Results in state change and is stored on-chain.
B. Contract Creation Transaction
Used to deploy a new smart contract.
| Field | Meaning |
|---|---|
| To | Left empty (null) |
| Init | Initialization code (runs once, then removed) |
| Value | ETH to fund the contract with |
After successful execution, creates a new contract at a deterministic address based on sender and nonce.
5. Signature Fields (V, R, S)
Every transaction must be signed with the sender’s private key.
| Field | Description |
|---|---|
| V | Recovery ID (27 or 28), helps derive the public key |
| R | Part of the ECDSA signature (X-coordinate of a curve point) |
| S | Part of the ECDSA signature (calculated with private key and R) |
These ensure that the transaction was authorized by the sender.
6. RLP (Recursive Length Prefix)
Ethereum transactions are serialized using RLP encoding (Recursive Length Prefix). This allows data like transactions, blocks, and accounts to be stored and transmitted consistently.
RLP ensures deterministic encoding — even the smallest mismatch would break the chain’s consensus.
7. Transaction Execution and Validation
Before execution, a transaction must be:
- Well-formed and RLP-encoded.
- Properly signed (valid V, R, S).
- Have a nonce matching the sender’s account.
- Contain enough ETH to cover
Gas Limit × Gas Price.
8. After Execution: Transaction Receipt
After a transaction runs, Ethereum produces a transaction receipt, which includes:
| Field | Description |
|---|---|
| Post-transaction state | World state after execution |
| Gas used | Total gas consumed |
| Logs | Events emitted (can be used by frontends) |
| Bloom filter | Compressed search structure for logs |
| Status | 1 (success) or 0 (failure) — added after Byzantium fork |
Diagram – Ethereum Transaction
