Nodes, validators and network roles

A starting question

Your friend says: "My app queries a node, so it trusts nobody." Is that true? It depends entirely on the node. To answer, ask two questions about every role in the network:

1. What does it store? (the whole history, only recent state, only block headers)
2. What does it verify by itself? (every transaction and state transition, or only proofs and signatures)

Reminder from workshop 110: a block has a header (height, previous block hash, Merkle roots) and a body (the transactions). The state is the table of balances and data after each block; the header contains a fingerprint of it, the state root.

The roles, one by one

• Full node: downloads blocks, replays every transaction and checks the protocol rules. It rejects an invalid block even if everyone else signs it. It keeps recent state and, depending on configuration, may prune (delete) old state.
• Archive node: a full node that deletes nothing: it can answer "what was this account's balance at block 1,200,000?". It is therefore much larger.
• Light client: keeps only headers (or even just one recent trusted header). For a specific piece of data it asks a full node for a Merkle proof and compares it with the header's root. It does not replay transactions.
• Validator (proof of stake) or miner (proof of work): takes part in producing and voting on blocks. For its own safety and the network's, it should be a full node: it should not vote on what it has not verified (the protocol does not always enforce this: some pool miners work on a block template supplied by the operator). It also holds a signing key that puts its funds at stake.
• Collator: a term specific to Polkadot and its parachains. It gathers a parachain's transactions and prepares the candidate blocks that the relay chain's validators check. It does not secure the relay chain itself. Elsewhere the word does not exist or means something else: check each network's vocabulary.
• RPC node: a full (or archive) node whose JSON-RPC interface is opened to applications. It is a use of a node, not a data type.

Summary table

Worked example: who can answer?

A fictitious network has 2,000,000 blocks. Three questions: (a) "Is this payment in block 1,999,990?" (b) "What was account X's balance at block 500,000?" (c) "Does this transaction obey the rules?"

• (a) A light client can answer with a Merkle proof against the header.
• (b) Only an archive node has the state of block 500,000 immediately available; a pruned full node deleted it (if it kept the blocks, it could recompute it by replaying them, slowly). A light client can only ask, and must believe the answer unless it comes with a proof against the state root of that header.
• (c) Only a node that replays the transaction (full, archive, validator) truly verifies it.

What this does NOT guarantee

• Running a full node does not make you a validator: there is no vote and no reward without a validation key and, in proof of stake, without deposited stake.
• A full node does not protect you from a chain that is validly built but wrong: if it is connected only to malicious peers (an eclipse attack), it can follow a false branch. It checks the rules, not the truth of the world.
• Names are not standardised: two projects can call two different things "light".

Recap

A role is defined by what it keeps and what it verifies. The less it verifies, the more trust it delegates; the less it keeps, the less it costs.

The problem

Four teams in Douala and Yaoundé each need a "node". They should not all run the same thing. To choose, start from the need, not from the technology.

Decision grid

Ask these four questions in order:

1. Must I verify the rules myself? If a source error costs money (crediting a deposit, signing a payment), yes.
2. Do I need old history? Past balances and old execution traces → archive. Old event logs are often available on a full node that keeps blocks (check the chain's documentation). Otherwise a pruned full node is enough.
3. How many requests per second? A public application needs several nodes behind a load balancer, not one big one.
4. What machine and network do I have? A phone on a connection billed by volume cannot follow a chain continuously.

Four cases

Worked example: a node's bandwidth

The following numbers are fictitious (no real network is described): a network produces one block every 6 seconds, each block weighs 80 KB.

• Blocks per day: 86,400 s ÷ 6 s = 14,400 blocks.
• Block data per day: 14,400 × 80 KB = 1,152,000 KB ≈ 1.15 GB.
• A node also receives pending transactions and peer messages. Suppose, for the example, an overhead of ×5: ≈ 5.76 GB per day, about 173 GB per month.

On a mobile connection billed by volume, 173 GB a month is beyond many budgets. Practical conclusion: host the node with a provider that does not meter volume, or in a data centre, and connect to it from your phone. The ×5 factor is an assumption of the example: measure yours with the network interface counters over 24 hours.

Sync time: two distinct limits

Bringing a node up to date requires downloading then verifying. Download follows the model of workshop 101: duration ≈ round trips × latency + size × 8 ÷ bandwidth. But verification — replaying transactions, computing hashes — depends on CPU and disk, not on bandwidth. Fast fibre does not make a node sync faster if its disk is slow.

What this does NOT guarantee

• A free public RPC service is neither a full node of your own nor an availability commitment: it may rate-limit, filter methods or return stale data.
• "Bigger" does not mean "safer". An archive node verifies exactly the same rules as a full node; it just keeps more.
• The bandwidth figures above are a calculation method, not a measurement of a real network.

Recap

Choose a node starting from the need: who bears the error? is the past needed? what request volume? what machine? And write down the trust assumption you accept.

The problem

Your team wants an archive node for a regional service. The director asks: "How much disk, and how much money, for three years?" A serious answer is a calculation with written assumptions, not a number found on a forum.

Four-step method

1. Blocks per year = (seconds per year) ÷ (time between blocks).
2. Bytes kept per block = block body + state changes + indexes. An archive keeps past state: the delicate point is how much state changes in each block. You measure it on a real node of the target chain.
3. Size per year = blocks per year × bytes per block.
4. Margins: free space so the disk is never full (at least 20 to 30%), traffic growth, backup.

Worked example (FICTITIOUS network)

Assumptions: one block every 6 s; on average 50 KB of block body and 30 KB of state changes and indexes per block, i.e. 80 KB.

1. Blocks per year: 14,400 per day × 365 = 5,256,000.
2. Size per year: 5,256,000 × 80 KB = 420,480,000 KB ≈ 420 GB per year (decimal GB).
3. Over 3 years, with no traffic growth: 3 × 420 = 1,260 GB ≈ 1.26 TB.
4. With a 30% free-space margin you need at least 1,260 ÷ 0.7 = 1,800 GB usable, so you buy 2 TB.

If traffic doubles after a year, the "no growth" assumption is wrong: redo the calculation by slice. An estimate that does not say how it could be wrong is not an estimate.

Cost: a disk is more than a capacity

A node reads and writes in random order. Input/output throughput (operations per second) matters as much as terabytes: a spinning disk may be too slow to keep up with the chain. Node clients generally recommend SSDs, often NVMe; your client's documentation gives the minimum.

In this workshop, "estimating the storage cost" means estimating the disk size to plan for; the cost in money comes from multiplying by a rate. For the budget, add: disk × the provider's price per GB (you read the price at purchase time: it changes), bandwidth, backup, and a person's time for maintenance. In this workshop we use no real price: the point is the structure of the calculation.

Why not everyone runs an archive

Compare with a pruned full node. Suppose it keeps only 100,000 recent blocks of state: 100,000 × 30 KB = 3 GB of state, plus blocks 5,256,000 × 50 KB ≈ 263 GB if all are kept. Pruning old state therefore brings the order of magnitude from 420 to about 266 GB per year in this example, and above all it caps the state part. The full node verifies the same rules; it has only forgotten the state's past. Caution: this toy counts only the per-block state changes; the full current state (all accounts) comes on top, and its size is something to measure, not to deduce from those changes.

What this does NOT guarantee

• The calculation does not tell how long the initial sync takes: that depends on CPU, disk and network.
• Size does not always grow linearly: a protocol change, a usage spike or a spam attack can make it jump.
• A bigger archive node is not more "decentralised": if few people can afford the hardware, there are few independent archives, and you fall back on trusting a few providers (see workshop 114).

Recap

Size = blocks × bytes kept per block, with a free-space margin. Write your assumptions, measure them on a real node, and redo the calculation when they change.

The problem

A mobile wallet shows "Balance: 25,000". Where does that number come from? If the app asked a server and trusted the answer, that server decides what you see. A light client tries to reduce this trust, but not to remove it.

The validator: a full node that signs

In a Byzantine-fault-tolerant network (workshop 108), n validators decide by supermajority (strictly more than two thirds of the votes). With n = 3f + 1 the network tolerates f Byzantine validators and requires a quorum of 2f + 1 votes. Example: n = 10, so f = 3, quorum = 7. If 3 validators are offline or malicious, 7 remain: the quorum is reachable. With 4 faulty validators it no longer is. If they are 4 crashes, liveness is lost but safety holds; if they are 4 Byzantine nodes, safety itself is no longer guaranteed (it holds only up to f = 3 Byzantine nodes).

Try the quorum simulator: set n, mark some validators faulty and watch when the quorum stops being reachable.

A validator must satisfy two opposing constraints:

• Availability: offline, it misses votes and may be penalised.
• Key prudence: its signing key is used continuously, so it sits on a connected server. Running the same key on two machines "for redundancy" can produce two contradictory signatures; in many proof-of-stake networks this behaviour (equivocation, or double signing) is penalised, sometimes by destroying part of the stake. The exact rules depend on the network.

Common practice: put the validator behind "sentry" nodes that alone talk to the rest of the network, and never expose its own RPC interface.

What a light client delegates

The light client follows headers. To learn "my balance is 25,000" it asks a full node for the value and a Merkle proof that links that value to the header's state root (workshop 106).

What it verifies:

• that the value received is indeed the one contained in the state whose root appears in the header (the proof is recomputed);
• depending on the protocol, that the header is signed by enough validators (proof of stake) or carries enough work (proof of work).

What it delegates, hence assumes:

1. The starting header is the right one. A trusted starting point is needed: a header embedded in the app, or the validator list at a given moment. If this header is false, everything after it is false.
2. The validators who signed did verify. The light client did not replay the block; it believes an honest quorum did. A malicious majority of validators could sign an invalid block, which only a full node would catch.
3. It is shown the latest chain. A dishonest full node can hide recent blocks (the up-to-date value is missing) or, if it is the only peer, eclipse you.
4. The starting header is recent enough. Validator sets change: a header that is too old may be signed by keys that no longer put any stake at risk.

If the app gets no proof and simply takes the server's answer, it does not delegate "a little": it delegates everything to that server.

Example: reading a proof

In the Merkle explorer, build a tree of eight "account" leaves, click a leaf and verify the proof. Then edit a leaf's value: the root changes, and the proof no longer leads to the old root. That is why a valid proof against the trusted header protects against a lying server about that data. It does not protect against a false header.

What this does NOT guarantee

• A valid Merkle proof does not prove the header is final: on a chain with probabilistic finality it can still be reorganised (workshop 109).
• Running a validator does not guarantee its peers' honesty; only the 2f + 1 threshold over n = 3f + 1 bounds how many faulty are tolerated.
• A light client is not "trustless": it replaces trust in a single server with trust in the starting header and in the validator quorum.

Recap

The validator signs and should therefore verify; the light client verifies proofs and delegates the rest. Every delegation is a trust assumption that must be named.