The network behind the screen
Begin with “Nodes and the shared state” and work toward “Network architecture knowledge check”. Each available lesson includes a visual explanation and a quick knowledge check.
Read in order or choose a topic below. Completion marks stay in this browser. All 20 lessons in this track are available.
- 01
Nodes and the shared state
Computers that check the rules instead of trusting someone else’s copy.
5 MIN READ - 02
How Ethereum agrees
Validators propose and vote; nodes check that the rules hold.
6 MIN READ - 03
Execution clients and consensus clients
Two cooperating roles check execution and follow proof-of-stake consensus.
3 MIN READ - 04
Nodes versus validators
Verifying the chain and participating with stake are distinct roles.
3 MIN READ - 05
What does a full node verify?
It applies protocol rules rather than accepting a provider’s labels as proof.
3 MIN READ - 06
What an archive node retains
Historical state access differs from merely retaining block history.
3 MIN READ - 07
Peer-to-peer networking basics
Nodes exchange data through many connections rather than one universal message queue.
3 MIN READ - 08
What happens in a slot?
The consensus schedule gives an opportunity for a block proposal.
3 MIN READ - 09
What happens in an epoch?
Groups of slots provide a larger structure for consensus duties and checkpoints.
3 MIN READ - 10
Block proposers explained
The selected proposer offers a candidate block; the network checks it.
3 MIN READ - 11
Attestations explained
Validators publish structured votes about chain and checkpoint views.
3 MIN READ - 12
Fork choice in plain language
A node needs a rule for choosing its current valid chain head.
3 MIN READ - 13
Checkpoints and finality
Consensus can make a stronger commitment to accepted history.
3 MIN READ - 14
Validator rewards and penalties
The protocol gives incentives for correct participation and costs for failures.
3 MIN READ - 15
What slashing means
Some conflicting validator actions can be proven and penalized by the protocol.
3 MIN READ - 16
Why client diversity matters
Independent implementations can reduce dependence on one shared software bug.
3 MIN READ - 17
What a light client checks
A lighter verification design uses authenticated summaries and proofs under stated assumptions.
3 MIN READ - 18
Trusting an RPC provider
A convenient access point adds assumptions about answers, privacy and availability.
3 MIN READ - 19
Read calls versus write transactions
Simulation, submission and accepted state updates are separate operations.
3 MIN READ - 20
Network architecture knowledge check
Connect verification, consensus, providers and local tools without mixing their roles.
3 MIN READ