Transactions, state, gas and RPC
About 1808 wordsAbout 6 min
Part 3 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.
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.
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:
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:
work done × price of that workThe 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 |
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.
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.
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."
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.
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 |
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's approval in its natural habitat. It costs gas, changes nothing you can see, and grants a permission that outlives the swap.
Further exploration — optional, not assessed
- ethereum.org — Gas and fees — full mechanics
- 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
Sources and attribution
- ethereum.org — Transactions — Reuse (CC BY 4.0), adapted
- ethereum.org — Gas and fees — Reuse (CC BY 4.0), adapted
- ethereum.org — Nodes and clients — Reuse (CC BY 4.0), adapted
- ethereum.org — Events and logs — Reuse (CC BY 4.0), adapted
- EIP-1559 — Reuse (CC0), referenced