Interactive tutorials · Computed in your browser
Blockchain, recomputed
A blockchain is a record you can recheck rather than a database you trust. Interactive tutorials for developers: hash a real Bitcoin header and get the block’s own ID back, then read an Ethereum explorer page knowing which fields are on the chain and which are the explorer’s own. Every claim has a source, every hash on these pages can be recomputed in your browser, and the site’s checks recompute all of them.
A blockchain is not a database you trust; it is a record you can recheck. Tutorial 2, where you hash a real Bitcoin header and get the block’s own ID back, shows that on screen, and every later page is another field you learn to recompute, until an explorer page holds no mysteries.
From the chain to a page
Pick a field on the miniature explorer page. The line back through the pipeline shows where its value comes from, in the colours every page of the series uses: green for a header field, blue for a transaction or receipt, amber for something computed from those, magenta for something the chain never held.
The six fields, as a list
The path runs from the chain, through a node (which has an execution client and a consensus client), across JSON-RPC, into an indexer with its own database, and out as a page. Most fields make that whole trip; one never touched the chain.
- DerivedBlock hash. Not stored anywhere in the block. Whoever reads the header, a node or an indexer or you, hashes it. The indexer got the header from the node and the hash follows from it.
- HeaderParent hash. A field of the header, passed through the node and the indexer unchanged. It is how each block names the one before it.
- HeaderBlock gas used. Also a header field: the gas all of the block’s transactions used, not just this one, copied through.
- ReceiptStatus. In the receipt, which the node makes by running the transaction. The node returns it when asked for the receipt.
- DerivedFee. Computed by the indexer from the receipt by arithmetic: gas used times the price paid. Anyone can redo it.
- Off-chainName tag. Never on the chain. It comes from a label list the explorer keeps or takes from elsewhere, and the chain holds no names. Treat it as the explorer’s opinion.
Redrawn for this series. The blocks, the transaction and every value in the miniature page are from the snapshot committed to this site (Ethereum, fetched 2026-10-23). The pipeline is the usual shape of an explorer, not any one product’s design.
The idea
A blockchain is a shared record that nobody has to take on trust.
Each block names the block before it by its hash, and each hash depends on every byte it covers, so changing anything old changes every hash after it. Which version of the record counts is settled by a rule every node can check for itself: on Bitcoin, the chain with the most proof of work; on Ethereum, the chain validators have voted to finalise.
Smart contracts are programs stored in that record, and every call to one, every event it emits and every fee paid is in it too. A block explorer is a window onto all of this: a website that reads from nodes, indexes what it reads, and lays it out as pages. Most of what it shows is data you could recompute yourself from the chain; some of it is the explorer’s own addition. These tutorials take the pieces apart until you can tell which is which.
The learning map
Arrows run from what a tutorial draws on to the tutorial; a dashed one leads to a page that is still coming. The dotted ones into the large node are what each later tutorial adds to recomputing a header: that one is the hinge, so read it first. Colours are the layer a tutorial mainly explains.
The record
- T1 · Hashesopen
- T2 · Recompute it yourselfopen · the hinge: start here
- T3 · Merkle treescoming · adds to the hinge: Merkle root
Agreement
- T4 · Proof of workcoming · adds to the hinge: work
- T5 · Keys and addressescoming · adds to the hinge: signature
Ethereum’s machine
- T6 · Transactions and statecoming · adds to the hinge: tx hash
- T7 · Gas and feescoming · adds to the hinge: base fee
- T8 · Contracts and eventscoming · adds to the hinge: log
The window
- T9 · Reading an exploreropen
- T10 · How explorers workcoming
If you hold or sign anything
- T5 · Keys and addresses · coming
- T6 · Transactions and state · coming
- T7 · Gas and fees · coming
- T8 · Contracts and events · coming
- T9 · Reading an explorer
- Reading an explorer safely · coming
A track for anyone who holds or signs anything is coming: reading an explorer safely. It will be mechanisms from the standards, shown on this site’s own explorer view, with no loss figures and no advice about buying, selling or holding. Until then, the reading-an-explorer tutorial is its first half.
- Cryptographic primitive
- Header (in the block)
- Receipt and execution
- Derived (computed from the chain)
- Off-chain and tooling
- Dashed: coming
The tutorials
T1 · Open
Hashes: fingerprints that change completely
Type some text and watch SHA-256 and Keccak-256 fingerprint it side by side, then flip one padding byte to see why Keccak-256 is not SHA3-256.
Cryptographic primitive
T2 · Open
Recompute it yourself: a chain of real headers
Hash eighty bytes of a real Bitcoin block header and get the block’s own ID back; change one byte and the next block’s link breaks.
Header (in the block)
T3 · Coming
Merkle trees: one root for every transaction
Pair the transaction IDs, hash each pair and repeat to the top, then prove one transaction is in a block with a handful of hashes.
Header (in the block)
T4 · Coming
Proof of work, and why the past is expensive to change
Mine a toy block, decode a real nBits target, and race an attacker with the whitepaper’s own calculation.
Header (in the block)
T5 · Coming
Keys, signatures and addresses
From a private key to an address, the checksum that catches typos, and what a signature commits to.
Cryptographic primitive
T6 · Coming
Transactions and state on Ethereum
Two ledgers side by side, then a transaction decoded field by field until its hash comes out.
Receipt and execution
T7 · Coming
Gas and the fee market
Drag the gas used in a row of blocks and watch the base fee follow the EIP-1559 rule, then split one fee into burn and tip.
Derived (computed from the chain)
T8 · Coming
Smart contracts: code, calls and events
Decode calldata and event logs by hand, and see why the code at an address may not be the code that runs.
Receipt and execution
T9 · Open
Reading an explorer page
This site’s own block and transaction pages, built from a committed snapshot, with every field tagged and a recompute button wherever the chain can prove it.
Derived (computed from the chain)
T10 · Coming
How an explorer is built
Follow the head with JSON-RPC, store what you read, and handle a reorganisation when a parent hash does not match.
Off-chain and tooling
Track · Coming
Reading an explorer safely
For anyone who holds or signs anything: nine checks, in order, from whether a contract’s source is verified to whether the whole address matches.
Off-chain and tooling
What this series is not
- A product or an endorsement. No page here names a wallet, an exchange, an explorer or a token as a product; the tools are described by category, and the sources are standards, specifications, the projects’ own code and documentation.
- About prices. There are no prices, market figures, returns or fiat values on these pages. The chain does not hold them, and where an explorer shows one, these pages show an empty slot labelled as the explorer’s addition.
- A live view. The Bitcoin headers are from Bitcoin Core’s own source and test data (all but the genesis block are testnet3 blocks), and the Ethereum block, transaction and receipt were fetched once on 2026-10-23 and committed. Every hash in them is recomputed when the site is checked.
Sources
Bitcoin whitepaper Bitcoin: A Peer-to-Peer Electronic Cash System (Satoshi Nakamoto). 2008 (no date printed).
Read 2026-10-23: Whole paper as text: section 2 (transactions), 3 (timestamp server), 4 (proof of work: nonce, moving-average difficulty), 5 (network: the longest chain), 7 (Merkle tree and the 80-byte header), 8 (simplified payment verification), 11 (calculations)
- Sections 3 to 5: the timestamp server, proof of work, and the longest chain as the one with the most work
Ethereum yellow paper Ethereum: A Secure Decentralised Generalised Transaction Ledger (Gavin Wood). Shanghai version efc5f9a, 2025-02-04. Its section 4.4 lists 17 header fields; the blob, beacon-root and requests-hash fields are not in it.
Read 2026-10-23: Section 3 (KEC is Keccak-256, not the final SHA-3), 4.4 (17 header fields, through baseFeePerGas and withdrawalsRoot), 4.4.1 (receipts and logs), Appendix B (RLP, titles)
- Section 4.4: a block’s parentHash is the Keccak-256 hash of its parent’s header
ethereum.org: proof of stake Proof-of-stake (ethereum.org). page updated 2026-10-07.
Read 2026-10-23: 12-second slots, 32-slot epochs, finality when two consecutive checkpoints gather votes from two-thirds of the staked ether
- Finality: two consecutive checkpoints with votes from two-thirds of the staked ether
Solidity: introduction to smart contracts Introduction to Smart Contracts (Solidity docs, latest). read 2026-10-23.
Read 2026-10-23: Logs and events; gas used before a revert is not refunded
- Contracts as code in accounts; logs and events
ethereum.org: block explorers Block explorers (ethereum.org). page updated 2026-03-02.
Read 2026-10-23: The field lists for block, transaction, account and token pages. The page names explorers; none is used here
- The fields a block explorer shows
Explorer indexer docs Indexer architecture overview (documentation of an open-source block explorer). undated.
Read 2026-10-23: Realtime and catch-up indexers; off-chain integrations for prices, verification and labels
- An explorer indexes what a node returns and adds data from outside the chain
ethereum.org: nodes and clients Nodes and clients (ethereum.org). page updated 2026-07-13.
Read 2026-10-23: Execution and consensus clients; why run your own node
- Running your own node lets you check data instead of trusting others
Everything here is paraphrased from the sources, not quoted at length, and every claim is attributed to one. Each entry says which parts of the source were read, and whether the build or the plan read them. Anything illustrative is labelled as such. Where a source is silent or could not be read, the page leaves the fact out.