Cardano cherche une norme pour le logiciel des producteurs de blocs

Un Cardano Problem Statement recherche une méthode partagée pour identifier le logiciel utilisé pour produire des blocs individuels. La discussion CPS-0036 a été ouverte le 2 septembre et a reçu l’étiquette Confirmed le 16 septembre, mais la proposition reste ouverte et n’établit pas de norme technique.

Son objectif est de définir le problème avant qu’une Cardano Improvement Proposal distincte ne précise le format de signalisation, le registre des logiciels et les règles d’implémentation.

Cardano s’étend au delà d’une seule implémentation de nœud

Historiquement, Cardano s’est appuyé sur cardano-node, basé sur Haskell, tandis que d’autres implémentations sont désormais en cours de développement selon les mêmes règles de consensus. CPS-0036 cite Amaru et Dingo, et la discussion de la proposition mentionne aussi Gerolamo.

Dans ce contexte, un client est le logiciel de nœud qui valide le protocole Cardano et peut participer à la production de blocs. Il est distinct des portefeuilles et des autres applications utilisées pour interagir avec le réseau.

Des implémentations indépendantes peuvent améliorer la résilience, car un défaut qui affecte une base de code peut ne pas exister dans une autre. Cet avantage dépend de l’adoption. Si un client continue de produire la plupart des blocs, le réseau demeure opérationnellement dépendant de cette implémentation même lorsque des alternatives sont disponibles.

Cardano ne dispose actuellement d’aucun champ standardisé qui attribue chaque bloc au logiciel qui l’a créé. Les chercheurs, les explorateurs et les plateformes de supervision doivent estimer indirectement la répartition des clients, ce qui produit des jeux de données pouvant être incomplets ou difficiles à comparer.

L’activité sur le réseau a rendu la question plus pressante. Le relecteur yHSJ a indiqué que Dingo et Gerolamo ont déjà produit des blocs en utilisant le champ de version mineure du protocole comme identifiant logiciel, tandis qu’Amaru prévoit d’adopter la même approche.

CPS-0036 décrit une signalisation logicielle volontaire

CPS-0036 préconise un mécanisme compact, volontaire et neutre vis à vis du consensus. Les blocs dépourvus d’identifiant logiciel resteraient valides, et chaque opérateur de pool de staking déciderait de publier ou non l’information.

La discussion décrit deux approches existantes. L’une utilise quatre octets du champ de version mineure du protocole dans l’en tête de bloc. L’autre utilise une transaction marqueur d’environ 60 octets. Sans spécification commune, les implémentations pourraient adopter des formats différents et contraindre les fournisseurs d’infrastructure à maintenir des règles de décodage distinctes.

La proposition appelle aussi à un registre à gouvernance ouverte qui attribue un identifiant reconnaissable à chaque implémentation. Les explorateurs, les chercheurs et les tableaux de bord pourraient alors interpréter le signal de manière cohérente à l’échelle du réseau.

L’identification du client est le premier cas d’usage envisagé. Le mécanisme pourrait ensuite prendre en charge des déclarations sur la disponibilité de fonctionnalités ou la préparation logicielle avant des mises à niveau du protocole.

Plusieurs questions de conception restent non résolues. Un identifiant auto déclaré peut être usurpé, tandis que le lier cryptographiquement à des identifiants KES ou VRF ajouterait de la complexité. La publication de versions logicielles détaillées pourrait également exposer des opérateurs exécutant des versions vulnérables. Toute spécification devrait rester compatible avec Leios et sa structure de blocs en évolution.

Les données clients pourraient renforcer la supervision du réseau Cardano

Un identifiant standard permettrait à Cardano de mesurer la diversité déclarée des clients directement à partir des blocs produits. Les opérateurs réseau et les chercheurs pourraient calculer la part associée à chaque implémentation, identifier une dépendance excessive à une base de code et suivre l’entrée de clients alternatifs dans l’infrastructure active.

Ces données pourraient aussi soutenir les mises à niveau du protocole. Si la norme inclut plus tard la préparation des fonctionnalités, l’écosystème pourrait obtenir une vue à l’échelle du réseau avant un hard fork ou une publication logicielle majeure. Les tests et la coordination resteraient des processus distincts, tandis que le signal sur chaîne fournirait un jeu de données opérationnel commun.

La discussion indique qu’une convention pratique pourrait déjà se former autour du champ de version mineure du protocole. L’éditeur de CIP Robert Phair a déclaré qu’une CIP axée sur la solution, fondée sur la pratique actuelle, pourrait offrir une voie plus directe que la simple documentation du problème.

La signalisation logicielle ne peut ni créer une diversité de clients ni prévenir les défaillances, mais elle peut rendre l’infrastructure de Cardano plus facile à mesurer. Si elle est adoptée, la norme permettrait aux explorateurs et aux outils de supervision de remplacer des estimations fragmentées par des données cohérentes au niveau du bloc indiquant quel client déclaré produit les blocs du réseau.