What a Chain Is For

By the end of this session you will be able to:

• State exactly what an Ethereum node replicates, and what that replication costs in throughput and privacy
• Write down the trust assumptions a transaction actually rests on, and name three things those assumptions do not cover
• Read latest, safe, and finalized off a live node and decide which one your application should wait for
• Decide, for a given problem, whether a chain is the right tool or whether a database with an audit log would do the job better

A chain is a machine that re-runs everything

Ethereum is not a database in the cloud. It is a few thousand computers, each holding a full copy of the same state (account balances, contract code, contract storage), each independently re-executing every transaction in every block in the same order, and each checking that it arrived at the same result as everyone else. Agreement is not negotiated. It is recomputed.

The output of that arrangement is not speed. Having every machine repeat the same work is the slowest imaginable way to compute anything. What you get instead is the removal of one specific party: the administrator who could quietly edit a row. To change a past block you would have to convince thousands of independent nodes to accept a state they can each prove is wrong.

That is the trade, and it is worth stating in numbers before anyone gets excited. At the time of writing, mainnet produces one block every 12 seconds, each carrying roughly 200 to 450 transactions, capped at 60 million gas per block against a 30 million gas target. That works out to about 20 transactions per second for the entire world at once. A single Postgres instance on a student laptop beats that by three orders of magnitude. If your reason for choosing a chain is performance, you have already chosen wrong.

Trust assumptions, written out in full

"Trustless" is a marketing word. Every system has trust assumptions. A blockchain does not delete them, it moves them somewhere you can inspect. Here is what an Ethereum transaction actually rests on:

1. An honest supermajority of stake. Finality holds as long as validators controlling more than two thirds of staked ETH follow the protocol. That is an economic assumption, not a mathematical one.
2. A path to at least one honest node. If every node you can reach is lying to you, you see a false chain and cannot tell. This is why "check two independent providers" is a habit and not paranoia.
3. Your private key stays yours. The network cannot distinguish a theft from a legitimate transfer. A valid signature is the whole story.
4. The code does what you believe it does. The network faithfully executes a buggy contract, bug and all, and then faithfully refuses to undo it.

Now the part most course material skips. Those assumptions do not cover: whether data someone pushed on chain is true, whether the deployer kept an upgrade key or an admin role that can rewrite the logic tomorrow, whether the web page you clicked is showing you the transaction you are actually signing, or whether the token you hold has a blacklist function. In practice, most value lost in this industry is lost to stolen keys, compromised operators, and poisoned dependencies rather than to clever attacks on the protocol itself.

Finality: three different answers to "is it done"

A new block is not permanent. Ethereum divides time into 12 second slots and groups 32 slots into an epoch, so an epoch is 6.4 minutes. A block becomes finalized once checkpoints spanning two epochs collect attestations from more than two thirds of staked ETH, which lands around 13 to 15 minutes after the block was proposed. Single-slot finality is still a research item on the roadmap, not something shipping this year.

That gives you three heads to ask for, and every JSON-RPC method that takes a block parameter accepts all three:

• latest: the most recently proposed block. It exists, it may be reorganized away, and it carries no settlement guarantee at all.
• safe: the latest justified checkpoint. Reverting it would take an unusual consensus event.
• finalized: reverting this would require an attacker to burn at least a third of all staked ETH. The protocol will not reorganize past it.

Ask a live node yourself:

RPC=https://ethereum-rpc.publicnode.com
for tag in latest safe finalized; do
  printf '%s ' "$tag"
  curl -s -X POST "$RPC" -H 'content-type: application/json' \
    --data "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"eth_getBlockByNumber\",\"params\":[\"$tag\",false]}" \
    | python3 -c 'import sys,json; b=json.load(sys.stdin)["result"]; print(int(b["number"],16), int(b["timestamp"],16))'
done

A run while writing this lesson returned block 25681256 for latest, 25681219 for safe, and 25681188 for finalized. The timestamps differ by 828 seconds, so the finalized head was 68 blocks and just under 14 minutes behind the tip. An exchange crediting a deposit at latest is taking a risk it has chosen to accept. A contract reading a price at latest may be reading a block that never happened.

The short list of things this actually fits

Good fits, and the list really is this short:

• Bearer assets moving between parties who do not trust each other and share no legal system
• An append-only public record with no operator: registries, attestations, timestamped proofs of publication
• Code that must hold and release value with no human able to intervene
• Rules several organizations must agree on but none of them should host
• Censorship resistance for someone who can be cut off by a bank or a platform

Bad fits, which is a much longer list: throughput, private data (every storage slot is readable by anyone, private in Solidity is a compiler rule, not a secret), deletion and any right-to-erasure obligation, large files, anything depending on real-world facts, anything you might need to patch quickly, and any interface where users expect a sub-second response.

The honest default: if exactly one organization runs the system and every user already trusts that organization, a normal database with an append-only audit log and signed receipts gives you most of the property you want for a tiny fraction of the cost and effort.

Try it

Query the finalized head from two providers that share no infrastructure and compare them:

for rpc in https://ethereum-rpc.publicnode.com https://eth.drpc.org; do
  printf '%s ' "$rpc"
  curl -s -X POST "$rpc" -H 'content-type: application/json' \
    --data '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["finalized",false]}' \
    | python3 -c 'import sys,json; b=json.load(sys.stdin)["result"]; print(int(b["number"],16), b["hash"])'
done

Success condition: both providers return the same block hash, and if the block numbers happen to differ by a slot or two, re-running gives you a matching pair. Then run the three-tag script above and subtract: your latest minus finalized gap should be between 64 and 96 blocks. Write both numbers down. You have just observed replication and finality directly, with no explorer and no wallet in the way.

Common mistakes

• Treating latest as settled. It is the default block tag in almost every library, so you get it without asking. Decide per feature: display can use latest, but anything that releases value or credits an account should wait for finalized.
• Believing the chain makes data true. Consensus guarantees that everyone agrees a value was written, not that the value is correct. A lie recorded on chain is a permanently agreed lie.
• Calling something decentralized because it is deployed on a chain. Check for an owner address, an upgrade proxy, or a pause function first. One key held by one person is one administrator, exactly the thing you were trying to remove.
• Reaching for a chain because the requirements mention "immutable" or "auditable". Those words describe an append-only log, and you can build one in an afternoon. Reach for a chain only when the operator itself is the thing nobody trusts.
• Assuming a private variable is hidden. All contract storage is public. Anything secret must never reach the chain in readable form.

Where this goes next

You now know what the network guarantees and what it charges you for those guarantees. Next session, "Keys, Accounts, and Signatures", takes apart the one assumption everything else depends on: hashing, keypairs, addresses, and what a wallet is genuinely holding on your behalf.