Cardano sucht Standard für Software der Blockproduzenten

Eine Cardano Problemstellung sucht nach einer gemeinsamen Methode um die Software zu identifizieren mit der einzelne Blöcke erzeugt wurden. Die Diskussion zu CPS-0036 wurde am 2. September eröffnet und erhielt am 16. September das Label Confirmed doch der Vorschlag bleibt offen und legt keinen technischen Standard fest.

Ihr Zweck ist es das Problem zu definieren bevor ein separates Cardano Improvement Proposal das Signalisierungsformat das Software Register und die Implementierungsregeln spezifiziert.

Cardano geht über eine einzelne Node Implementierung hinaus

Historisch hat sich Cardano auf die Haskell basierte cardano-node gestützt während zusätzliche Implementierungen nun unter denselben Konsensregeln entwickelt werden. CPS-0036 nennt Amaru und Dingo und die Vorschlagsdiskussion verweist außerdem auf Gerolamo.

In diesem Zusammenhang ist ein Client die Node Software die das Cardano Protokoll validiert und an der Blockproduktion teilnehmen kann. Er ist getrennt von Wallets und anderen Anwendungen die zur Interaktion mit dem Netzwerk verwendet werden.

Unabhängige Implementierungen können die Resilienz verbessern weil ein Fehler der eine Codebasis betrifft in einer anderen nicht vorhanden sein muss. Dieser Vorteil hängt von der Verbreitung ab. Wenn ein Client weiterhin die meisten Blöcke produziert bleibt das Netzwerk betrieblich von dieser Implementierung abhängig selbst wenn Alternativen verfügbar sind.

Cardano hat derzeit kein standardisiertes Feld das jeden Block der Software zuordnet die ihn erzeugt hat. Forscher, Explorer und Monitoring Plattformen müssen die Client Verteilung indirekt abschätzen wodurch Datensätze entstehen die unvollständig sein oder sich nur schwer vergleichen lassen.

Aktivität im Netzwerk hat das Thema dringlicher gemacht. Reviewer yHSJ sagte dass Dingo und Gerolamo bereits Blöcke produziert haben indem sie das Feld der Minor Version des Protokolls als Software Kennzeichen verwenden während Amaru plant denselben Ansatz zu verfolgen.

CPS-0036 skizziert freiwillige Software Signalisierung

CPS-0036 fordert einen kompakten, freiwilligen und konsensneutralen Mechanismus. Blöcke ohne Software Kennzeichen blieben gültig, und jeder Stake Pool Betreiber würde entscheiden, ob er die Information veröffentlicht.

Die Diskussion beschreibt zwei bestehende Ansätze. Einer nutzt vier Bytes aus dem Feld der Minor Version des Protokolls im Block Header. Der andere nutzt eine Marker Transaktion von ungefähr 60 Bytes. Ohne eine gemeinsame Spezifikation könnten Implementierungen unterschiedliche Formate übernehmen und Infrastruktur Anbieter dazu zwingen, separate Dekodierregeln zu pflegen.

Der Vorschlag fordert außerdem ein offen verwaltetes Register das jeder Implementierung einen erkennbaren Bezeichner zuweist. Explorer, Forscher und Dashboards könnten das Signal dann im gesamten Netzwerk einheitlich interpretieren.

Die Client Identität ist der erste vorgeschlagene Anwendungsfall. Der Mechanismus könnte später Erklärungen zur Verfügbarkeit von Funktionen oder zur Einsatzbereitschaft von Software vor Protokoll Upgrades unterstützen.

Mehrere Designfragen bleiben ungelöst. Ein selbst deklarierter Bezeichner kann gefälscht werden während seine kryptografische Bindung an KES oder VRF Anmeldedaten zusätzliche Komplexität einführen würde. Die Veröffentlichung detaillierter Softwareversionen könnte außerdem Betreiber offenlegen die verwundbare Releases einsetzen. Jede Spezifikation müsste mit Leios und seiner sich weiterentwickelnden Blockstruktur kompatibel bleiben.

Client Daten könnten das Cardano Netzwerk Monitoring stärken

Ein standardisierter Bezeichner würde es Cardano ermöglichen, die deklarierte Client Vielfalt direkt aus erzeugten Blöcken zu messen. Netzbetreiber und Forscher könnten den Anteil jeder Implementierung berechnen, eine übermäßige Abhängigkeit von einer Codebasis erkennen und nachverfolgen, ob alternative Clients in aktive Infrastruktur übergehen.

Die Daten könnten auch Protokoll Upgrades unterstützen. Wenn der Standard später die Bereitschaft für Funktionen umfasst, könnte das Ökosystem vor einem Hard Fork oder einer großen Softwareveröffentlichung eine Sicht auf Netzwerkebene erhalten. Tests und Koordination blieben getrennte Prozesse, während das On Chain Signal einen gemeinsamen operativen Datensatz liefern würde.

Die Diskussion deutet darauf hin, dass sich bereits eine praktische Konvention rund um das Feld der Minor Version des Protokolls herausbildet. CIP Editor Robert Phair sagte, ein lösungsorientiertes CIP auf Grundlage der aktuellen Praxis könne einen direkteren Weg bieten als nur das Problem zu dokumentieren.

Software Signalisierung kann keine Client Vielfalt schaffen oder Ausfälle verhindern, doch sie kann die Messbarkeit von Cardanos Infrastruktur verbessern. Wenn sie angenommen wird, würde der Standard es Explorern und Monitoring Werkzeugen ermöglichen, fragmentierte Schätzungen durch konsistente Daten auf Blockebene zu ersetzen, die zeigen, welcher deklarierte Client die Blöcke des Netzwerks produziert.