Cardanos Dezentralisierungstest geht über die Anzahl der Knoten hinaus

Nick Regan, Mitgründer und Host von Cheeky Crypto, hat eine 24 Minuten lange Analyse eines weniger sichtbaren Risikos innerhalb der Dezentralisierung von Cardano veröffentlicht: unabhängig entwickelte Software, die über die Regeln des Netzwerks uneins sein könnte. Cheeky Crypto ist eine Krypto Analyse- und Bildungsplattform, die 2020 von Nick und Chris Regan gegründet wurde.

Regan verknüpfte seine Analyse mit CPS-0034, einem offenen Cardano Problem Statement, das erweiterte Konformitätstests für Plutus Core Evaluatoren vorschlägt, die von alternativen Cardano Node Implementierungen genutzt werden. Die Diskussion geht über Stake Pool Verteilung, Governance Teilnahme und die Anzahl der mit dem Netzwerk verbundenen Maschinen hinaus.

Mehrere Clients erhöhen die Sicherheit nicht automatisch

Regan unterscheidet zwischen der physischen Verteilung eines Netzwerks und der Verteilung seiner Software. Cardano kann Tausende von Knoten haben, die von unterschiedlichen Einheiten in mehreren Ländern betrieben werden, während ein großer Teil dieser Infrastruktur dennoch auf derselben Kernimplementierung des Nodes basiert.

Wenn eine gängige Implementierung einen konsenskritischen Fehler enthält, könnten viele geografisch verteilte Knoten gleichzeitig auf dasselbe Problem stoßen. Alternative Clients verringern diese Konzentration, indem sie getrennten Teams erlauben, unterschiedliche Programmiersprachen, Architekturen und technische Entscheidungen zu nutzen.

Ein weiteres Risiko entsteht, wenn diese Implementierungen das Protokoll unterschiedlich interpretieren.

Ein Client könnte eine Transaktion akzeptieren, die ein anderer ablehnt. Zwei Plutus Evaluatoren könnten dasselbe Skript verarbeiten, aber unterschiedliche Ergebnisse zurückgeben oder unterschiedliche Ausführungskosten berechnen. Da die Gültigkeit eines Blocks von diesen Ergebnissen abhängen kann, könnte Uneinigkeit zwischen Knoten statt größerer Resilienz eine Aufspaltung der Kette erzeugen.

UPLC, oder Untyped Plutus Core, ist die Ausführungssprache, in die Plutus Smart Contracts kompiliert werden. Ein alternativer Evaluator muss nicht die Struktur der etablierten Haskell Implementierung von Cardano reproduzieren, er muss jedoch das vom Protokoll erwartete konsensrelevante Verhalten reproduzieren.

Regan beschreibt diese Anforderung als Notwendigkeit unabhängiger Übereinstimmung.

Getrennte Codebasen bieten nur dann eine sinnvolle Redundanz, wenn sie für gültige Eingaben, Randfälle und historische Protokollversionen konsistent zur gleichen Antwort gelangen.

Regan verwendet den Titel "ADA Has a Decentralisation Problem", um dieses Risiko auf der Softwareebene von den Dezentralisierungsdebatten zu unterscheiden, mit denen die meisten Holder konfrontiert sind. Seine Analyse konzentriert sich auf präventive Infrastrukturarbeit und nicht auf einen bestehenden Mainnet Vorfall.

CPS-0034 erweitert Plutus Core Konformitätstests

Das Plutus Core Team eröffnete den Vorschlag am 12. August zur öffentlichen Begutachtung. CIP Editoren wiesen ihm nach der ersten Prüfung anschließend die Nummer CPS-0034 zu, während der technische Vorschlag weiterhin für Feedback offen bleibt.

Laut dem Vorschlag CPS-0034 stellt Cardano externen Entwicklern derzeit ungefähr 1.000 vordefinierte Golden File Tests bereit. Diese ermöglichen es einem unabhängigen Evaluator, ein bereitgestelltes Skript auszuführen und seine Ausgabe mit dem erwarteten Ergebnis zu vergleichen.

Die bestehende Suite bietet eine erste Kompatibilitätsprüfung, weist jedoch zwei identifizierte Einschränkungen auf. Sie macht die intern vom Plutus Team verwendeten Property Based Tests nicht zugänglich und deckt nur die neueste Kombination aus Protokollversion, Ledger Sprachversion und Kostenmodell ab.

Property Based Testing geht über eine kleinere Sammlung manuell vorbereiteter Beispiele hinaus. Ein Generator kann Hunderte oder Tausende variierter Eingaben erzeugen, daraus Plutus Skripte konstruieren und prüfen, ob definierte Verhaltenseigenschaften weiterhin gelten.

Dieser Ansatz erweitert die Abdeckung über ungewöhnliche Kombinationen, Randwerte und Bedingungen, die während normaler Aktivität selten auftreten. Das sind auch die Situationen, in denen unabhängig entwickelte Implementierungen eher unterschiedliche Annahmen über das Protokollverhalten offenbaren.

CPS-0034 schlägt vor, generierte Testfälle in einem portablen Format zu verteilen, das externe Implementierungen mit minimalem Integrationsaufwand konsumieren können. Jeder Test könnte das Programm, seine Eingaben, das erwartete Ergebnis und, wo zutreffend, das erwartete Ausführungsbudget enthalten.

Historische Abdeckung ist ebenfalls enthalten. Cardano ist durch mehrere Ledger Epochen, Hard Forks, Plutus Sprachversionen und Änderungen am Kostenmodell gegangen. Ein alternativer Node muss diese Historie korrekt interpretieren, wenn er die Kette nachzeichnen und frühere Blöcke validieren soll.

Der Vorschlag konzentriert sich ausdrücklich auf die Konformität von Plutus Core Evaluatoren. Er definiert kein vollständiges Testframework für alle Netzwerk-, Ledger- und Konsenskomponenten innerhalb eines Cardano Nodes. Seine Relevanz für die Sicherheit eines Nodes ergibt sich daraus, dass unterschiedliche Skriptbewertungsergebnisse ändern können, ob eine Transaktion oder ein Block als gültig gilt.

Unabhängiger Code muss konsistentes Verhalten nachweisen

CPS-0034 enthält noch mehrere offene technische Fragen. Entwickler diskutieren, wie generierte Tests verteilt werden sollten, wie Unterschiede zwischen erwarteten und tatsächlichen Ergebnissen gemeldet werden sollten, wie Fälle nach Protokollversion gefiltert werden sollten und wie Tausende von Tests effizient ausgeführt werden können.

Mit Amaru verbundene Entwickler haben sich bereits an der öffentlichen Diskussion beteiligt. Amaru ist ein in Rust geschriebener Open Source Cardano Node Client und bietet Betreibern eine Implementierung, die getrennt von der etablierten Haskell cardano-node entwickelt wird.

Ein Amaru Beitragender berichtete, dass das Projekt bereits bestehende semantische und Flat Konformitätssuiten konsumiert. Das Feedback befürwortete breiteres Property und Version Testing und bat um realistische On Chain Szenarien, client neutrale Datenformate und einen einfachen Weg für Drittparteien, zusätzliche Fälle beizusteuern.

Vorgeschlagene Ansätze umfassten strukturierte Test Fixtures und das Taggen von Fällen entsprechend der Protokoll- und Sprachversionen, die sie abdecken. In der Diskussion wurden auch Bedenken geäußert, den Generator ausschließlich in Haskell zu implementieren, da dies eine zusätzliche Hürde für Teams schaffen könnte, die in anderen Sprachen arbeiten.

Ein gemeinsamer Teststandard würde keinen identischen Quellcode erfordern. Jedes Team könnte seine eigene Architektur, Programmiersprache und Entwicklungsweise beibehalten, während das resultierende Ausführungsverhalten weiterhin mit den Regeln von Cardano kompatibel bliebe.

Für ADA Inhaber betrifft das Thema die Resilienz der Infrastruktur eher als die kurzfristige Marktperformance. Börsen, Wallets, dezentrale Anwendungen und institutionelle Systeme sind darauf angewiesen, dass verschiedene Knoten deterministische Entscheidungen über Transaktionen, Skripte und Blöcke treffen.

Wenn CPS-0034 eine portable, versionsbewusste Konformitätssuite hervorbringt, wird ein alternativer Cardano Client seine Kompatibilität nicht mehr lediglich dadurch demonstrieren, dass er als separate Codebasis existiert. Er wird reproduzierbare Nachweise liefern können, dass unabhängig geschriebene Software über die Protokollhistorie von Cardano hinweg zum selben Ergebnis und zu denselben Ausführungskosten gelangt, sodass Uneinigkeiten während des Testens sichtbar werden, bevor sie einen Live Block erreichen können.