Every application talking to a network does so through a node, and who runs those nodes is a substantial and underdiscussed dependency.
What a node does
Maintains a copy of the chain state, validates blocks and serves queries.
Which requires storage, bandwidth and continuous operation.
Resource requirements have grown steadily on most networks as state accumulates.
Node types
Full nodes validate everything from current state.
Archive nodes retain all historical state and require substantially more storage.
Light clients verify selectively with minimal resources.
Which matters because applications needing historical data need archive access, and that is expensive.
Provider concentration
Most applications use a small number of commercial node providers rather than running their own.
Which is a practical centralisation point that is invisible to end users.
Provider outages have taken large numbers of applications offline simultaneously, demonstrating the dependency concretely.
Why applications outsource
Running reliable infrastructure across multiple networks is a full operations function.
Which includes monitoring, upgrades, scaling and incident response.
For most teams this is not the best use of engineering capacity, which is a reasonable position.
Rate limits and pricing
Providers meter by request volume and by request type.
Which shapes application design, since expensive query patterns become costly at scale.
Caching and indexing layers exist partly to reduce node request volume.
Indexing
Chain data is not organised for the queries applications need.
Which is why indexing services process events into queryable databases.
An application showing incorrect data is frequently experiencing an indexing lag rather than a chain problem.
Running your own
Requirements vary by network and are within reach of a determined individual on most.
Which provides verification independence and removes the provider dependency.
Hardware, bandwidth and the willingness to maintain it are the practical constraints.
Why this matters
A network can be decentralised at the consensus layer while access to it is concentrated among a handful of providers.
Synchronisation
A new node must download and verify history before it is useful.
Which takes hours to days depending on the network and the method used.
Snapshot-based synchronisation shortens this at the cost of trusting the snapshot provider.
State growth management
Storage requirements increase continuously, and pruning removes data not needed for current validation.
Which keeps requirements manageable and prevents serving historical queries.
Archive nodes decline to prune and consequently require substantially more storage.
Failover and redundancy
Production infrastructure runs multiple nodes across locations.
Which handles hardware failure, network problems and regional outages.
Load balancing across nodes with health checking is standard practice.
Client software choice
Multiple implementations exist for most major networks with different characteristics.
Which affects resource usage, synchronisation speed and feature support.
Running more than one implementation protects against implementation-specific bugs.
Cost
Self-hosting has fixed costs; providers charge by usage.
Which means the crossover point depends on request volume.
Many teams run their own nodes for critical paths and use providers for the rest.
Decentralised node networks
Protocols distributing requests across independent operators rather than a single provider.
Which addresses the concentration problem structurally.
Adoption has been limited relative to commercial providers, largely on reliability and latency.
Light client development
Verification with minimal resources would reduce the dependency substantially.
Which is an active development area on several networks.
Embedded light clients in wallets would remove the need to trust a provider for balance information.
Data availability for applications
Historical data access is increasingly a specialised service.
Which concentrates a capability that the technology nominally makes universal.
History expiry proposals would formalise this rather than pretending otherwise.
Monitoring your own node
Synchronisation status, peer count, disk usage and version currency.
Which is straightforward with standard tooling.
Disk exhaustion is the most common cause of individual node failure.
Why it is worth doing
Independent verification is the property the technology offers, and it requires actually running the software.
Getting started
Documentation for running a node is published for every major network.
Which is more approachable than most people assume.
Hardware requirements for the largest networks are within the range of ordinary consumer equipment plus adequate storage.
The dependency worth naming
An application described as decentralised that routes every request through one commercial provider has a single point of failure.
Which is worth knowing about the tools you use.
Several widely used interfaces have gone offline entirely during provider incidents.
Cost of independence
Running infrastructure yourself costs money and attention, and provides verification that no provider can give you.
Which is the trade, stated plainly.
For most users the provider is the reasonable choice, and knowing it is a choice is the important part.
A closing observation
The consensus layer can be admirably decentralised while every application reaching it depends on three companies. That is a real property of the current landscape and it receives far less attention than validator distribution does.
Provider redundancy is the practical mitigation and is straightforward to implement.