"Distributed" describes where a system runs: on many machines in different places. "Decentralized" describes who controls it: no single person or organisation can make the decisions. A system can be distributed without being decentralized. A cloud database copied across one company's data centres is an example: the machines are many, but the owner is one. Public blockchains such as Bitcoin and Ethereum are built to be both. Thousands of machines hold the ledger, and no single operator can change the rules or override the record.
The rest of this guide covers where the two words come from, why they are often confused, and how to check whether a given network is only distributed or is also decentralized.
Two words, two meanings
The 1964 network diagram
The words go back to Paul Baran's RAND memorandum On Distributed Communications (RM-3420, August 1964). Baran compared three network layouts for a communications system meant to survive heavy attack:
- Centralized: every node connects to one central hub. Lose the hub and the end stations are cut off.
- Decentralized: several hubs, each serving its own cluster. No single hub is fatal, but each hub is still a weak point for its cluster.
- Distributed: no central switch at all. Each node links to several neighbours in a mesh, so traffic can route around damage.
In this older sense, decentralized is a halfway point between centralized and distributed. Both words describe the shape of the network, not who owns it.
How the words are used in blockchain
Crypto writing uses the two words for different questions. Vitalik Buterin's essay The Meaning of Decentralization (February 2017) separates three independent axes:
- Architectural: "how many physical computers is a system made up of?" This is the sense of "distributed".
- Political: "how many individuals or organizations ultimately control the computers". This is what most people mean by "decentralized".
- Logical: whether the system's interface and data "look more like a single monolithic object" or a loose swarm.
Buterin writes that blockchains are "politically decentralized (no one controls them) and architecturally decentralized", "but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)."
That last point explains much of the confusion. A blockchain spreads its work across many machines and many owners, yet everyone works on one shared ledger.
Side by side
| Question | Distributed | Decentralized |
|---|---|---|
| What it describes | Where computing and data sit | Who has the final say |
| Core property | Many machines, many locations | No single controlling party |
| Can one company run it? | Yes | No, by definition |
| Main failure it protects against | Hardware or site outages | Censorship, capture or collusion by one operator |
| Typical example | Replicated cloud database | Public permissionless blockchain |
Distributed but not decentralized
US standards body NIST's Blockchain Technology Overview (NIST IR 8202, October 2018) describes blockchains as "tamper evident and tamper resistant digital ledgers implemented in a distributed fashion", usually without a central authority. NIST's glossary, which draws on IR 8202, then sets out two models:
- Permissioned: "a system where every node, and every user must be granted permissions to utilize the system (generally assigned by an administrator or consortium)."
- Permissionless: "a system where all users' permissions are equal and not set by any administrator or consortium."
A permissioned ledger can run on many nodes in many countries, which makes it fully distributed. If an administrator or consortium decides who joins, though, control stays with them. That ledger is distributed but only as decentralized as its membership rules allow.
Distributed only, or also decentralized?
Answer five questions from the article's checklist to see whether a network or app is only distributed or is also decentralized.
Does someone have to grant permission before you can run a node or produce blocks?
- Yes, an administrator or consortium decides who joins → Permissioned: control sits with whoever grants access
- No, anyone can join on equal terms → next question
Can one party change the rules or override the records?
- Yes → Distributed, not decentralized
- No, the rules decide which blocks are valid → next question
Does a single party or coordinated group control most of the block-producing power?
- Yes → Decentralization is weak here
- No, the power is spread across parties who do not answer to one another → next question
Do almost all nodes run the same software client?
- Yes, one codebase dominates → Decentralized control, but a single point of failure
- No, several independent clients are in use → next question
Does the app you use keep keys on a company server, or depend on a front end only one team can change?
The ledger can run on many nodes in many countries and be fully distributed, but it is only as decentralized as its membership rules allow.
Many machines may hold the data, but one party has the final say. This is like a cloud database copied across one company's data centres.
The Bitcoin white paper ties security to an honest majority of CPU power. If one party or group controls most block production, the decentralization this relies on does not hold.
Ethereum's documentation warns that a network depending on one codebase is exposed to a single bug, however many machines run it.
Keys held server-side or logic run on central servers bring back the trust the base layer removes, which Ethereum's documentation calls undermining its guarantees.
Many machines do the work and no single party controls them. This is a matter of degree, and it holds only while control stays spread out.
This walks through the article's checklist only. It uses no live node counts, client shares or mining-share figures, so it cannot measure how concentrated a real network is today.
How Bitcoin combines both
The Bitcoin white paper (Satoshi Nakamoto, dated 31 October 2008) opens with the goal: "A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution." It adds that digital signatures alone are not enough "if a trusted third party is still required to prevent double-spending."
Section 5 of the paper describes how the network runs:
- New transactions are broadcast to all nodes.
- Each node collects new transactions into a block.
- Each node works on finding a difficult proof-of-work for its block.
- A node that finds a proof-of-work broadcasts the block to all nodes.
- Nodes accept the block only if all its transactions are valid and not already spent.
- Nodes show acceptance by building the next block on top of it.
The distributed part is that every node keeps and checks its own copy. The decentralized part is that no node has the authority to decide which block is valid. The rules decide, and the security assumption is spelled out: "If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains." Decentralization here is therefore a matter of degree. It holds as long as no single party or coordinated group controls most of the block-producing power.
How Ethereum's documentation frames it
Ethereum's developer documentation defines a node as "any instance of Ethereum client software that is connected to other computers also running Ethereum software." It describes three kinds:
- Full nodes validate every block against the protocol rules.
- Archive nodes also keep all historical data.
- Light nodes download block headers only and cannot take part in consensus.
The documentation makes two points that bear directly on decentralization:
- Full nodes enforce the rules. Full nodes cannot be tricked into accepting invalid blocks. A network where everyone ran light nodes would be easier for validators to attack.
- Client diversity. "Multiple client implementations can make the network stronger by reducing its dependency on a single codebase." A network with thousands of machines all running one piece of software is still exposed to a single bug.
The same documentation is frank about the costs. Decentralized applications (dapps) built on Ethereum are hard to update once deployed, and every node processes every transaction, which limits throughput. It also warns that user-friendly services built on top may store keys server-side or run logic on central servers, "undermining" the guarantees of the base layer.
Why it matters: what each property buys you
Buterin gives three reasons decentralization is worth its cost:
- Fault tolerance: systems built from "many separate components" are less likely to fail by accident.
- Attack resistance: decentralized systems are "more expensive to attack and destroy or manipulate".
- Collusion resistance: it is "much harder for participants in decentralized systems to collude".
Distribution on its own buys mainly the first: uptime when machines or sites go down. The second and third come from decentralization, meaning control is spread across parties who do not answer to one another.
The price is efficiency. A system where every participant checks every transaction is slower and more expensive to run than one company's database. Whether that trade is worth it depends on how much the user needs to avoid trusting a single operator.
A practical checklist
To judge any network or app that calls itself decentralized, ask:
- Who can run a node or produce blocks? If someone has to grant permission, the network is permissioned, and control sits with whoever grants it.
- How concentrated is block production? Bitcoin's own white paper ties its security to an honest majority of CPU power, so concentration matters.
- How many independent software clients are in use? One dominant codebase is a single point of failure.
- Does the app layer reintroduce a centre? Keys held on a company server, or a front end that only one team can change, add back the trust the base layer removes.
- Can the rules or records be changed by one party? If so, the system may be distributed, but it is not decentralized.
Further reading on this site: what blockchains are, how Ethereum smart contracts work and what a decentralised exchange is.
Limitations: the quotes from Buterin's 2017 essay were checked against a published excerpt, not the original page, and this guide gives no live node or mining-share figures.
