# 08 — Nodes, RPCs, and Indexers Here's an exercise that changes how you see every crypto app: pick a balance displayed in one, and trace the number backward, hop by hop, until you reach actual chain state. Count how many parties along the way could have altered it. The count is usually higher than expected — because while the chain itself is trustless, almost nothing that touches your app is. This module is about that gap. ## Nodes Different node types make different trust tradeoffs: | **Node type** | **What it does** | |---|---| | Full node | Verifies blocks and state transitions; holds current state | | Archive node | Like a full node, but keeps every historical state snapshot (e.g. "balance at block N") | | Light client | Verifies headers/proofs, not full state | | Validator | Participates in consensus | | RPC node | Serves application queries over HTTP/JSON | | Sequencer | Orders L2 transactions | | Prover | Generates validity proofs | | Indexer | Builds queryable offchain views | An **RPC** (Remote Procedure Call) is the HTTP/JSON API your app uses to read chain state and submit transactions — convenience, not verification. Among all the distinctions in this table, one earns its keep daily: > RPC access is not trustless verification. If your app relies on a third-party RPC provider, that provider can lie, censor, lag, or fail — and your app will faithfully render whatever it's told. Nobody signs RPC responses. All the verification machinery from [[02 Cryptographic Primitives]] exists, but calling `eth_getBalance` against someone else's server uses none of it. It's worth letting that sink in: most "decentralized apps" are, on their read path, ordinary clients of ordinary servers. See [[Trust Assumptions]]. Light clients are the honest middle ground — verify headers, check proofs against them, skip storing the world. Underused today, improving steadily, worth keeping an eye on. ## Indexers Try asking a node for "all of Alice's NFTs" and you'll discover something: blockchains are terrible query databases. Deliberately so — they're optimized for verifiable state transitions, not for `SELECT * FROM transfers WHERE user = ?`. The node has no index for your question, because answering product queries was never its job. So real products build the queryable view themselves. Contracts emit **events (logs)** when things happen — indexers subscribe to these rather than replaying all execution: ```text Chain events -> indexer -> Postgres/Elastic/ClickHouse -> API/UI ``` Indexers power activity feeds, balances, NFT galleries, analytics, notifications, compliance monitoring — nearly everything a user actually sees. Which leads to a slightly deflating realization: when you use a crypto app, you're mostly reading someone's Postgres. The chain is the write path, and the court of appeal. What makes indexing genuinely interesting as an engineering problem is one property of the upstream: it can rewrite its recent past. [[Reorgs]]. The naive design looks harmless — ```text insert event forever ``` — and it credits deposits that later un-happen. The workable shape treats recent history as provisional: ```text insert event with block_hash mark canonical after confirmations/finality handle rollback if reorg ``` Add the familiar production litany — backfills, idempotency, event decoding, partial failure, schema migrations, multi-chain normalization, RPC retries — and you have the full job. If you've built **CDC** (change-data-capture) pipelines, you already have most of the instincts; the one new wrinkle is that the log can fork. ## Oracles One more gap to close, and it's one we left open in [[05 Execution and Smart Contracts]]: contracts can't reach the internet. A contract cannot do: ```solidity price = fetch("https://api.exchange.com/eth-usd") ``` Determinism forbids it. So here's a puzzle: how does a lending protocol — which must liquidate positions when prices move — ever learn the price of ETH? Someone has to put the price on-chain, as an ordinary transaction. That someone is an **oracle** — a bridge from the world to the chain. Because the EVM can't fetch external data, someone must post it as a transaction the contract trusts. And with that, the trust question returns wearing its sharpest clothes. The contract will believe whatever the oracle writes — it has no other way to know. Manipulate the feed for even one block, and liquidations fire on phantom prices, collateral drains, markets break, all while the code executes flawlessly. Hence a rule of thumb that has held up depressingly well: > A DeFi protocol is often exactly as secure as its oracle assumptions. Oracle manipulation has a permanent seat in the exploit hall of fame — we'll visit in [[12 Security and Incentive Design]]. ## Learning outcomes Questions worth trying on: - Could you trace a balance from pixels back to chain state, naming every party who could corrupt it along the way? - Could you explain to a data engineer why indexing a blockchain is CDC with a forking log — and what that forces onto the schema? - Why do blockchains make terrible query databases, and why is that actually the right design choice? - When a lending protocol trusts "the price," what is it actually trusting? Could you name the parties? - And the thread to pull forward: everything so far assumed one chain with limited blockspace. What happens when the machine needs to grow? ## Checkpoint 1. Full node, light client, RPC consumer — what does each verify, and what does each take on faith? *(If unsure, revisit "Nodes" and [[Trust Assumptions]].)* 2. Why must an indexer store `block_hash` with every event? Walk through the failure without it. *(If unsure, see [[Reorgs]].)* 3. Why can't the EVM fetch a price itself? One word answers it; a paragraph explains it. *(If unsure, revisit [[05 Execution and Smart Contracts]].)* **Exercise.** Build the small indexer: pick an ERC-20, stream its Transfer logs via RPC into Postgres, expose one endpoint for balance-by-address. Then do the parts that make it real — backfill from deployment, dedupe on retry, and a reorg drill (drop and replay the last N blocks). This one project teaches more practical blockchain engineering than any course; the full spec is in [[Projects to Build]]. ## Resources - **Ethereum.org docs: Nodes and clients** — node taxonomy and client architecture. - **Run a node, or use RPC providers critically** — the difference between the two is itself the lesson. - **The Graph documentation** — how the ecosystem industrialized indexing; worth reading for the data model even if you build your own. --- Next: one chain, finite blockspace, growing demand. How does the machine scale without giving up verification? → [[09 Scaling - Rollups and Data Availability]]