Cardano schlägt ein Softwareregister für Blockproduzenten vor

Josh Marchand hat ein gemeinsames Register vorgeschlagen, das Cardano-Explorern ermöglichen würde, nachzuverfolgen, welche Knotenclients Blöcke produzieren. Eingereicht am 24. September, baut CIP-0203 auf einer Signalmethode auf, die bereits von Dingo und Gerolamo verwendet wird. Der Vorschlag wird weiterhin geprüft.

Softwarekennungen in Cardano Blöcken

Jeder teilnehmende Knotenclient würde eine Kennung erhalten, die mit seinem Namen, den Maintainern und dem öffentlichen Repository verknüpft ist. Blockproduzenten würden diese Kennung im Blockheader vermerken, wo Explorer sie der registrierten Software zuordnen könnten.

Der Vorschlag nutzt das vorhandene Feld für die Minor Protokollversion, das die Gültigkeit von Blöcken nicht bestimmt. Das ermöglicht Identifizierung, ohne die Konsensregeln zu ändern oder einen Hard Fork zu erfordern. Zusätzlicher Platz würde Informationen wie Softwareversionen aufnehmen, in Formaten, die von den jeweiligen Entwicklungsteams dokumentiert sind.

Ausgemusterte Kennungen würden im Register verbleiben und innerhalb desselben Schemas nicht erneut vergeben werden, wodurch die Bedeutung historischer Blöcke erhalten bleibt.

Messung der Clientvielfalt in Cardano

Knotenclients sind die Softwareimplementierungen, die es Rechnern ermöglichen, Netzdaten zu validieren und Blöcke zu produzieren. Wenn unabhängig entwickelte Clients in Gebrauch kommen, benötigen Explorer eine einheitliche Methode, um ihren Beitrag zur Blockproduktion zu messen.

Die frühere Problemstellung CPS-0036 benannte zersplitterte Signalisierungskonventionen als Hindernis für diese Messung. Ihre Autorinnen und Autoren beschrieben die Clientvielfalt als eine relevante Messgröße für die Resilienz des Netzwerks. Ohne ein abgestimmtes Format müssen Explorer und Forschende die Konventionen jeder Implementierung gesondert interpretieren.

CIP-0203 würde dieses gemeinsame Format bereitstellen. Laut Marchand würde die Kernkennung es Beobachtenden ermöglichen, den Anteil jedes Clients an den produzierten Blöcken zu berechnen, unabhängig von zusätzlichen Daten, die er veröffentlicht.

Vom Register zur Unterstützung durch Explorer

Die Teilnahme wäre freiwillig, einschließlich einer ausdrücklichen Option, Softwareinformationen zurückzuhalten. Statistiken würden die von Produzenten selbst gemeldeten Kennungen widerspiegeln, ohne die von ihnen verwendeten Programme unabhängig zu verifizieren.

Begutachtende diskutieren weiterhin, wie Werkzeuge optionale Informationen wie Versionsnummern dekodieren sollten. Der Vorschlag überlässt diese Formate den einzelnen Teams und verlangt zugleich, dass sie deren Bedeutung dokumentieren.

Der vorgeschlagene Weg zum Status Active erfordert die Einführung auf beiden Seiten: mindestens zwei unabhängige Clients, die auf Mainnet oder einem öffentlichen Testnet Blöcke mit registrierten Kennungen produzieren, und mindestens ein öffentlicher Explorer oder ein Dashboard, das diese Kennungen dekodiert.