--- url: /academy-handbook/foundation/week-2/part-4-transactions-and-gas.md --- # Week 2 · Part 4 — Transactions, state, gas and RPC [Part 3](./part-3-why-ethereum-and-evm.md) established that Ethereum is a state machine and transactions are the way on-chain state changes. Before following one transaction, start with the doorway: **how does your wallet reach the blockchain at all?** ## Learning objectives * Trace a transaction from signature to finality and name each stage * Explain gas, gas limit and base fee, and why fees rise when the network is busy * Explain what an RPC endpoint is and why reading is free but writing is not * Explain what events are for, and why applications rely on them ## Core ### RPC — how your wallet reaches the chain MetaMask does not keep a full copy of Ethereum. So how does it show your balance or send a transaction? It asks a **node** to do that work for it. ::: important The doorway to the network Your wallet sends requests to a node through an interface called **JSON-RPC**. That node does the actual talking to the network. ==Your wallet is a convenient window onto Ethereum, not the chain itself.== ::: ```mermaid flowchart TD W["Your wallet
MetaMask"] <-->|JSON-RPC| N["A node
Infura · Alchemy
or your own"] N <--> B["The network"] ``` An **RPC endpoint** is just a URL that accepts these requests. MetaMask ships with defaults, which is why it works immediately — you are quietly relying on a provider. Three consequences are worth knowing: | Trust consideration | What it means | |---|---| | **You are trusting that provider** | To report state honestly and relay your transactions. They cannot forge your signature or steal funds — but they can show you wrong data or drop your transaction | | **They can see your requests** | Including which addresses you ask about, and from what IP | | **When wallets "go down", it is usually the RPC provider** | The chain is fine; your window onto it is not | You can run your own node and remove this dependency. Almost nobody does — worth knowing this is a convenience trade, not how the system has to work. ### What happens after you press Confirm? When you press **Confirm**, the transaction does not jump straight from your wallet onto the chain. The wallet prepares and signs a request, sends it through RPC to a node, waits for inclusion, and then the network executes it and updates the shared state. The technical names for that journey are: ```mermaid flowchart TD A["1 · Construct
wallet builds the transaction"] B["2 · Sign
private key · local · free"] C["3 · Broadcast
sent to a node via RPC"] D["4 · Mempool
waiting, visible to everyone"] E["5 · Included
a proposer puts it in a block"] F["6 · Executed
every node runs it and updates state"] G["7 · Finalised
about 15 minutes · economically irreversible"] A --> B --> C --> D --> E --> F --> G ``` ::: warning Step 4 is public Between broadcast and inclusion, your pending transaction is visible to everyone. Someone can see what you are about to do **before it happens**. This is the root of MEV — Further Exploration, but the reason it exists is right here. ::: **Step 6 happens on every node**, not just the proposer's. Week 1 Part 2's verification, now applied to contract code as well as transfers. ### Gas Before looking at individual fee fields, keep one plain-English model in mind: \==**gas measures how much computational work Ethereum has to perform.**== A transaction fee is roughly: ```text work done × price of that work ``` The fields below describe the work, its limit and its price: | Term | What it is | |---|---| | **Gas used** | Units of computation actually consumed. A plain ETH transfer has traditionally used 21,000 under the current fee schedule | | **Gas limit** | The maximum you authorise. Protects you from a runaway contract | | **Base fee** | Set by the protocol, rises and falls with demand. **Burned** | | **Priority fee** | Your tip to the proposer for including you sooner | | **Max fee** | The most you are willing to pay per unit | ```text fee = gas used × (base fee + priority fee) ``` **Why fees spike.** The base fee adjusts automatically — blocks fuller than target push it up, emptier blocks push it down. It is a congestion price, and it is not set by anyone. It is set by how many people want in. **Gas limit versus gas used.** You authorise a limit; you pay for what is used and the rest is returned. But if execution needs *more* than your limit, it runs out of gas, reverts, and **you still pay**. ::: warning Two things beginners find unfair — worth understanding rather than resenting **Failed transactions still cost gas**, because nodes really did the computation. **For the same transaction type, fees depend on computational work rather than the dollar value being moved.** Sending more ETH does not inherently cost more gas than sending less ETH. ::: ### Reading versus writing Start with the human action: * **“Show my USDC balance”** is a read. * **“Send USDC”** is a write. The formal distinction is: | Request type | **Read** (call) | **Write** (transaction) | |---|---|---| | Changes state | No | Yes | | Costs gas | **No** | Yes | | Needs a signature | No | **Yes** | | Speed | Immediate | Wait for a block | | Executed by | One node, for you | Every node | **Reads are free** because one node computes the answer from its own copy. Nothing is broadcast, nothing changes, so nobody else needs to care. \==**Writes cost because they change state for everyone.**== ::: warning A wallet pop-up is not automatically a transaction Loading a page and seeing your balances, prices and positions — those are reads, and they happen silently. But when your wallet **does** open, stop and read what it is asking for. It may be an on-chain transaction, or it may be an off-chain signature. Both matter. | Permission form | On-chain transaction | Off-chain signature | |---|---|---| | Sent to the blockchain | Yes | No — at least not by you, not yet | | Changes state immediately | Usually | No | | Costs gas | Yes | Often nothing | | Can still grant permission | Yes | **Yes** — someone else may submit it later | \==**"No gas" does not automatically mean "safe."**== ::: ::: details A subtle point that pays off in Week 3 Before sending a write, wallets often perform a **simulation** — a read that runs the transaction against current state to estimate gas and predict success. That is how your wallet warns you a transaction is likely to fail before you pay for it. ::: ### Events and logs Contracts can emit **events** — records written to the transaction's log alongside the state change. Two facts explain why they exist: * Events are much **cheaper** than storing data in contract storage * Contracts **cannot read** logs — logs are for the outside world only So events are a contract's way of **announcing what it did**, for applications watching from outside. Standard ERC-20 token transfers are typically surfaced through `Transfer` events, which wallets and explorers index, rather than by anyone reading contract storage directly. Without events, an application showing your transaction history would have to re-execute the entire chain. With them, it subscribes to a filtered feed. ::: tip That is enough for now **Week 3 covers events properly**, alongside the ABI — the description that makes a contract's functions and events readable. ::: ## Landscape * **EIP-1559** — the 2021 change that introduced a base fee which is burned and a separate priority fee. It made fee estimation more predictable, not fixed * **gwei** — 10⁻⁹ ETH, the unit gas prices are quoted in. A gas price in gwei is multiplied by gas used to determine the fee * **Nonce** — the per-account counter that makes transactions unique and orders them. A stuck lower nonce can hold up later transactions * **Mempool** — the public waiting room for transactions a node has received but not included. Seeing a transaction there does not mean it has succeeded * **Speed up / cancel** — resubmitting with the same nonce and a higher fee. It replaces or competes with the earlier request; it does not undo a confirmed transaction * **Revert** — execution failing and state changes being undone. Gas used before the failure is still consumed * **Node providers** — Infura, Alchemy, QuickNode and others that give applications access to nodes. Their availability and data handling add an infrastructure dependency * **MEV** — profit that can come from seeing pending transactions and choosing their order. Another trader may move first and change the execution or price a user receives ## Worked example The same swap, with every read and write labelled. | # | What happens | Read or write | Gas | Signature | |---|---|---|---|---| | 1 | Page loads, shows your USDC balance | Read | Free | No | | 2 | You enter an amount; it quotes a rate | Read | Free | No | | 3 | It checks whether the DEX may spend your USDC | Read | Free | No | | 4 | **Approve the DEX to spend your USDC** | **Write** | Paid | **Yes** | | 5 | It re-checks the allowance | Read | Free | No | | 6 | It simulates the swap to estimate gas | Read | Free | No | | 7 | **Execute the swap** | **Write** | Paid | **Yes** | | 8 | Contract emits `Swap` and `Transfer` events | — | In 7 | — | | 9 | Interface updates from those events | Read | Free | No | ::: important Nine steps. Two cost gas, and both interrupted you. That is the shape of nearly every DApp interaction. The reads are free because they do not change state — but note carefully that **"free" is about gas, not about safety**. A signature request can cost nothing and still authorise something that matters. The rule is not *"free is harmless"*; it is **every time your wallet opens, read what it is asking before you approve.** ::: Note also that step 4 is [Week 0 Part 4](../../getting-started/safety.md)'s approval in its natural habitat. It costs gas, changes nothing you can see, and grants a permission that outlives the swap. ::: details Further exploration — optional, not assessed * [ethereum.org — Gas and fees](https://ethereum.org/developers/docs/gas/) — full mechanics * [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) — the actual specification. Surprisingly readable, and a good introduction to what an EIP is * Open a busy contract on Etherscan and look at its **Events** tab. You are watching announcements meant for applications * **MEV** — why the public mempool creates an entire industry ::: ::: details Sources and attribution * [ethereum.org — Transactions](https://ethereum.org/developers/docs/transactions/) — Reuse (CC BY 4.0), adapted * [ethereum.org — Gas and fees](https://ethereum.org/developers/docs/gas/) — Reuse (CC BY 4.0), adapted * [ethereum.org — Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) — Reuse (CC BY 4.0), adapted * [ethereum.org — Events and logs](https://ethereum.org/developers/docs/smart-contracts/anatomy/#events-and-logs) — Reuse (CC BY 4.0), adapted * [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) — Reuse (CC0), referenced :::