New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
A network diagram covered with dots can suggest independence without showing who controls any of the dots. The recovered Blockchains Manager introduction to blockchain uses the language of shared records and reduced reliance on third parties. To examine that idea in practice, a reader needs more than a machine count. Independence depends on which decisions can be made separately, which failures can happen together and which powers remain concentrated elsewhere in the application. This new guide uses hypothetical systems to build a dependency map. It does not publish a ranking or claim to have measured the current decentralisation of a named network.
Distinguish machines from decision-makers
Imagine ten servers displaying the same record. If one organisation controls their software, credentials and hosting account, the ten machines may improve capacity or resilience without creating ten independent authorities. Now imagine several organisations operating separate systems under a shared protocol. Their independence may matter, but it still needs a definition. Can they choose different software, reject an invalid update or continue operating if another organisation leaves? The useful unit of analysis depends on the decision under examination. Counting hardware alone does not answer every question about control.
Write down the powers that matter to the application. Someone may admit participants, order transactions, verify records, change a contract, operate an interface or authorise a recovery action. These powers need not belong to the same actor. A system can be distributed in one dimension and concentrated in another. That is a reason to produce a more detailed description, not to force the whole system into a single yes-or-no label. The map should show where independent decisions exist and where several components still rely on a shared authority.
Separate verification from block production
Ethereum's documentation distinguishes the work performed by execution and consensus clients and describes how node software participates in the network. Those distinctions help explain why the word node should not silently mean every possible network role. Checking a record, supplying data to an application and participating in block production are different activities. A count associated with one role cannot automatically be used as a count of another. A careful system description names the role and explains what capability its participants actually have.
In a hypothetical review, compare the question who can check the result with the question who can influence which results become part of the accepted history. The evidence needed for each will differ. A public verification path can be valuable even when production has its own constraints. Conversely, a large production count does not tell a particular application whether its chosen gateway verifies the responses it displays. Keeping the roles separate makes the discussion more precise and prevents one favourable metric from becoming a substitute for the whole operating model.
Follow the user's actual access path
An application can rely on a distributed underlying network while all of its users reach that network through one hosted gateway. If the gateway fails, the network may continue operating while the application appears unavailable. This is not a contradiction. It is a dependency at a different layer. The user's practical experience depends on the interface, name resolution, connectivity and data-access path as well as the ledger itself. A resilience claim should identify which of these layers it covers rather than imply that network distribution automatically distributes the entire user journey.
Map a hypothetical read request from the interface to the source of the displayed data. Then map a transaction request in the opposite direction. Identify any common provider shared by several apparently independent applications. The exercise can reveal a concentration that is invisible in a diagram showing only the base network. It can also reveal meaningful alternatives, but alternatives should be tested rather than assumed. A fallback mentioned in a document is not yet evidence that the application can switch correctly while retaining the right network identity and user context.
Look for correlated failures
Independence is easiest to discuss through a specific failure. Suppose several operators use separate machines but the same hosting account, update mechanism or software implementation. A failure in the shared dependency could affect them together. The question is not whether sharing any component is forbidden. The question is whether the system's claimed diversity actually reduces the failure being considered. Geographic distribution, organisational separation and implementation diversity address different concerns, so none should be presented as a complete substitute for the others.
Use a hypothetical failure table with one event per row: an access provider becomes unavailable, a software update contains a defect or an administrator loses a credential. For each event, identify the components affected and the functions that remain possible. Avoid assigning invented probabilities or numerical safety scores. A qualitative map can still be rigorous if its dependencies and assumptions are explicit. It directs attention to evidence that can be gathered and tests that can be run, rather than producing a precise-looking number from an undefined notion of independence.
Inspect change and recovery powers
A system's ordinary operation is only part of its authority structure. Upgrade, pause and recovery mechanisms can introduce powers that become decisive during an incident. A network might process transactions across many participants while an application contract remains changeable through a small approval group. These are separate facts. A useful description identifies which layer can change, what approval process applies and how users can observe the change. It should not imply that a distributed base protocol automatically determines the governance of every application built on top of it.
For a hypothetical application, ask who can replace its implementation and what happens before a change becomes effective. Is there a published delay, a visible proposal or a mechanism for users to leave? Then examine the recovery process under stress. The answers may reveal deliberate trade-offs between rapid intervention and constrained authority. Describing those trade-offs is more useful than hiding the intervention powers behind a decentralisation slogan. Readers need to know which decisions remain independent when the system departs from its normal operating path.
Make a claim that another person can test
Replace a broad claim with a statement about a specific capability. For example, a hypothetical system might allow participants to verify records without depending on the application's hosted database, while its public interface still relies on one access provider. That description gives the reader two testable propositions. It also suggests an improvement target without pretending that one dependency invalidates every useful feature of the design. Precision makes the analysis actionable because it connects a claimed property to the boundary where it can actually be observed.
The practical method is to identify roles, follow access paths, examine correlated failures and inspect change powers. Retain the map as a dated observation and revise it when operators, providers or governance mechanisms change. A count can support the analysis once the thing being counted is defined. It should not replace the analysis. The result is a clearer way to discuss decentralisation: not as the visual density of a network diagram, but as an account of which decisions remain independent, under which assumptions and through which failures the relevant capability can continue to operate.
Technical references
From the recovered archive
- Blockchain is changing the world! · captured 6 October 2024