Client diversity: measure shared failure dependencies
Client diversity asks whether nominally separate validators can fail for the same software reason. An operator count alone cannot answer it. Build a dependency matrix across consensus clients, execution clients, versions and operational services, then state which dimensions are observed and which remain estimates.
Ethereum’s client-diversity documentation explains the resilience role of using multiple client implementations. It is a mechanism reference, not a current census of any operator’s installations. Use dated operator disclosures or reproducible measurements for the actual network distribution.
Separate software from organization
Start with the failure being investigated. A consensus implementation bug, execution implementation discrepancy and shared hosting outage do not have the same affected set. Record them as separate scenarios rather than compressing everything into a single decentralization score.
For each observed operator, identify the execution client and consensus client together. Knowing only one side leaves a substantial dependency unresolved. Add version information when available, but distinguish a disclosed version from a version inferred by an external fingerprint. Document the fingerprint’s limitations before interpreting its result as a precise population count.
Treat missing fields as unknown. If a provider says it supports several clients, that statement establishes availability, not the proportion of live validators using each one. A public installation guide similarly does not prove deployment. This distinction prevents a list of supported options from becoming fabricated diversity statistics.
Hypothetical correlated failure
Assume three fictional operators each control 20 units of effective weight. They are independently governed but all use execution client E. Their consensus clients differ. An execution-specific defect can therefore affect 60 units even though no organization controls all 60.
A fourth operator controls 15 units and runs a different execution client, but shares a hosting region with the first two. A regional outage has a different exposure set. The remaining 25 units have undisclosed software. Report the known affected weight for each scenario and keep unresolved weight visible.
Do not add the two scenario totals as if they represented independent losses. They overlap. The purpose of the matrix is to preserve that overlap, allowing a reader to see why adding organizational independence does not automatically remove technical correlation. All weights in this example are hypothetical.
Construct a scenario matrix
| Observation | Software-defect scenario | Infrastructure scenario |
|---|---|---|
| Execution implementation and version | Potential shared code path | Usually indirect |
| Consensus implementation and version | Potential shared consensus code | Usually indirect |
| Region and hosting service | Not evidence of common code | Potential common outage |
| Signing service | Separate dependency to inspect | Potential shared service failure |
| Evidence date | Establishes observed deployment | Establishes observed location |
For each scenario, compute known exposed weight / total observed weight. Report unknown weight beside the ratio. A range can allocate unknowns differently, but its endpoints are assumptions, not measured confidence intervals. Keep the denominator consistent with the validator concentration study.
Test what the evidence can support
Compare snapshots only when measurement methods are comparable. A changed fingerprinting technique can make apparent diversity improve without any validator changing software. Save method descriptions and classify unexplained changes as measurement breaks until investigated.
Ask whether a software dependency is replaceable before a failure, during a failure, or only after manual intervention. The existence of another client is not evidence of instant failover. Operational recovery depends on preparation, compatibility and the actual failure, so avoid inventing a universal recovery time.
A useful memo reports observed combinations, important overlaps and the questions that remain. It should explain whether concentration arises from shared code, shared infrastructure or uncertain measurement. Avoid ranking security audits as substitutes for distribution evidence: a reviewed implementation can still be a correlated dependency when widely used.
FAQ
Do many independent operators guarantee client diversity?
No. Independently controlled validators can run the same implementation and share a software failure mode.
Can I estimate client shares from a provider’s supported-client list?
No. Supported options and deployed proportions are different claims. Obtain deployment evidence or retain an unknown distribution.