Cardano’s Decentralization Test Goes Beyond Node Count

Nick Regan, co-founder and host of Cheeky Crypto, has published a 24-minute analysis of a less visible risk inside Cardano’s decentralization: independently developed software that may disagree on the network’s rules. Cheeky Crypto is a crypto analysis and education platform founded in 2020 by Nick and Chris Regan.

Regan connected his analysis to CPS-0034, an open Cardano Problem Statement proposing expanded conformance testing for Plutus Core evaluators used by alternative Cardano node implementations. The discussion moves beyond stake pool distribution, governance participation and the number of machines connected to the network.

Multiple Clients Do Not Automatically Increase Security

Regan distinguishes between the physical distribution of a network and the distribution of its software. Cardano may have thousands of nodes operated by different entities across multiple countries, while much of that infrastructure still relies on the same core node implementation.

If a common implementation contains a consensus-critical defect, a large number of geographically distributed nodes could encounter the same problem simultaneously. Alternative clients reduce that concentration by allowing separate teams to use different programming languages, architectures and engineering decisions.

Another risk appears when those implementations interpret the protocol differently.

One client could accept a transaction that another rejects. Two Plutus evaluators could process the same script but return different results or calculate different execution costs. Since block validity may depend on those outcomes, disagreement between nodes could produce a chain fork instead of greater resilience.

UPLC, or Untyped Plutus Core, is the execution language into which Plutus smart contracts are compiled. An alternative evaluator does not need to reproduce the structure of Cardano’s established Haskell implementation, but it must reproduce the consensus-relevant behavior expected by the protocol.

Regan describes that requirement as a need for independent agreement.

Separate codebases provide meaningful redundancy only when they consistently reach the same answer for valid inputs, edge cases and historical protocol versions.

Regan uses the title “ADA Has a Decentralisation Problem” to distinguish this software-layer risk from the decentralization debates most holders encounter. His analysis focuses on preventative infrastructure work rather than an existing mainnet incident.

CPS-0034 Extends Plutus Core Conformance Testing

The Plutus Core team opened the proposal for public review on August 12. CIP editors subsequently assigned it the number CPS-0034 following its initial review, while the technical proposal remains open for feedback.

According to the CPS-0034 proposal, Cardano currently provides external developers with approximately 1,000 predefined golden-file tests. These allow an independent evaluator to execute a supplied script and compare its output with the expected result.

The existing suite provides an initial compatibility check but has two identified limitations. It does not expose the property-based tests used internally by the Plutus team, and it covers only the latest combination of protocol version, ledger language version and cost model.

Property-based testing goes beyond a smaller collection of manually prepared examples. A generator can produce hundreds or thousands of varied inputs, construct Plutus scripts from them and verify whether defined behavioral properties continue to hold.

This approach expands coverage across unusual combinations, boundary values and conditions that may rarely appear during normal activity. Those are also the situations in which independently developed implementations are more likely to reveal different assumptions about protocol behavior.

CPS-0034 proposes distributing generated test cases in a portable format that external implementations can consume with minimal integration work. Each test could contain the program, its inputs, the expected result and, where applicable, the expected execution budget.

Historical coverage is also included. Cardano has moved through multiple ledger eras, hard forks, Plutus language versions and cost model changes. An alternative node must interpret that history correctly if it is expected to replay the chain and validate earlier blocks.

The proposal is specifically focused on Plutus Core evaluator conformance. It does not define a complete testing framework for every networking, ledger and consensus component inside a Cardano node. Its relevance to node safety comes from the fact that different script evaluation results can change whether a transaction or block is considered valid.

Independent Code Must Prove Consistent Behavior

CPS-0034 still contains several open technical questions. Developers are discussing how generated tests should be distributed, how differences between expected and actual results should be reported, how cases should be filtered by protocol version and how thousands of tests can be executed efficiently.

Developers connected to Amaru have already joined the public discussion. Amaru is an open-source Cardano node client written in Rust, providing operators with an implementation developed separately from the established Haskell cardano-node.

An Amaru contributor reported that the project already consumes existing semantic and flat conformance suites. The feedback supported broader property and version testing while requesting realistic on-chain scenarios, client-neutral data formats and a simple path for third parties to contribute additional cases.

Suggested approaches included structured test fixtures and tagging cases according to the protocol and language versions they cover. The discussion also raised concerns about implementing the generator exclusively in Haskell because that could create an additional barrier for teams working in other languages.

A shared testing standard would not require identical source code. Each team could retain its own architecture, programming language and development approach, while the resulting execution behavior would remain compatible with Cardano’s rules.

For ADA holders, the issue concerns infrastructure resilience rather than short-term market performance. Exchanges, wallets, decentralized applications and institutional systems depend on different nodes reaching deterministic decisions about transactions, scripts and blocks.

If CPS-0034 produces a portable, version-aware conformance suite, an alternative Cardano client will no longer demonstrate compatibility merely by existing as a separate codebase. It will be able to provide reproducible evidence that independently written software reaches the same result and execution cost across Cardano’s protocol history, exposing disagreements during testing before they can reach a live block.