Section 3.5
Who operates the network?
A full node independently checks the protocol rules for the chain it follows. A miner participates in proof-of-work block production. A validator participates in proof-of-stake duties such as proposing blocks and voting. Running a full node does not necessarily mean mining, staking or receiving rewards.
On Ethereum, node operation involves execution and consensus software. The execution client processes transactions and maintains execution state; the consensus client handles the consensus chain. Validator software performs staking duties when the operator has the appropriate validator arrangement. These roles are related but distinct.1Ethereum documentation, Nodes and clients.Open sourceSee in source list
Users often access a network through a remote procedure call, or RPC, provider. That service accepts queries and transaction submissions. It may be the user's principal view of the chain, but its response is not itself consensus.
| Role | Main contribution | Principal dependency to examine |
|---|---|---|
| Full node | Checks the history against protocol rules | Software correctness and access to network data |
| Miner or staking validator | Participates in block production or consensus | Incentives, availability and concentration |
| RPC provider | Supplies a convenient read and submission interface | Accuracy, censorship, rate limits and outages |
| Block explorer | Presents indexed network information | Indexing correctness and freshness |
| Client developer | Maintains protocol implementation software | Release quality and implementation diversity |
Counting nodes does not reveal who controls voting power, block construction or user access.
Map correlated control, not just entity counts
Imagine 100 apparently separate service operators. If 80 rely on one cloud region, they share an infrastructure failure mode. If 80 run the same defective client release, they share an implementation failure mode. If their transaction flow passes through one gateway, they share an access dependency.
Client diversity can reduce the chance that one implementation defect affects a dominant share of the network. It does not guarantee independence: implementations can share libraries, interpretations of a specification or deployment practices. Ethereum's documentation explicitly treats client concentration as a network resilience issue.2Ethereum documentation, Client diversity.Open sourceSee in source list
For an institution, the relevant dependency map has at least four dimensions:
• Economic control: who directs hash power, stake or delegated voting weight?
• Technical control: who supplies clients, hosting, key management and connectivity?
• Operational control: who can stop submissions, change routing or disable a service?
• Change control: who can deploy upgrades, replace contracts or activate emergency powers?
Two vendors are not necessarily independent if both resell the same underlying service. Equally, a public network may have many independent validators while a particular fund accesses it through one custodian and one API.
An institution does not need to reproduce every part of the network. It does need to understand which observations it verifies itself, which it accepts from providers and how it detects disagreement between them.