Le test de décentralisation de Cardano va au delà du nombre de nœuds

Nick Regan, cofondateur et animateur de Cheeky Crypto, a publié une analyse de 24 minutes d'un risque moins visible au sein de la décentralisation de Cardano : des logiciels développés de manière indépendante qui peuvent ne pas être d'accord sur les règles du réseau. Cheeky Crypto est une plateforme d'analyse et d'éducation crypto fondée en 2020 par Nick et Chris Regan.

Regan a relié son analyse à CPS-0034, un Cardano Problem Statement ouvert qui propose d'étendre les tests de conformité pour les évaluateurs Plutus Core utilisés par des implémentations alternatives de nœuds Cardano. La discussion va au delà de la distribution des pools de staking, de la participation à la gouvernance et du nombre de machines connectées au réseau.

La multiplicité des clients n'augmente pas automatiquement la sécurité

Regan distingue la distribution physique d'un réseau et la distribution de son logiciel. Cardano peut compter des milliers de nœuds opérés par différentes entités dans plusieurs pays, alors qu'une grande partie de cette infrastructure repose encore sur la même implémentation de nœud cœur.

Si une implémentation commune contient un défaut critique pour le consensus, un grand nombre de nœuds géographiquement distribués pourraient rencontrer le même problème simultanément. Des clients alternatifs réduisent cette concentration en permettant à des équipes distinctes d'utiliser des langages de programmation, des architectures et des choix d'ingénierie différents.

Un autre risque apparaît lorsque ces implémentations interprètent le protocole différemment.

Un client pourrait accepter une transaction qu'un autre rejette. Deux évaluateurs Plutus pourraient traiter le même script mais renvoyer des résultats différents ou calculer des coûts d'exécution différents. Étant donné que la validité d'un bloc peut dépendre de ces résultats, un désaccord entre nœuds pourrait produire une fourche de chaîne plutôt qu'une plus grande résilience.

UPLC, ou Untyped Plutus Core, est le langage d'exécution dans lequel les contrats intelligents Plutus sont compilés. Un évaluateur alternatif n'a pas besoin de reproduire la structure de l'implémentation Haskell établie de Cardano, mais il doit reproduire le comportement pertinent pour le consensus attendu par le protocole.

Regan décrit cette exigence comme un besoin d'accord indépendant.

Des bases de code séparées n'offrent une redondance significative que lorsqu'elles aboutissent de façon cohérente au même résultat pour des entrées valides, des cas limites et des versions historiques du protocole.

Regan utilise le titre « ADA Has a Decentralisation Problem » afin de distinguer ce risque au niveau logiciel des débats sur la décentralisation auxquels la plupart des détenteurs sont confrontés. Son analyse met l'accent sur un travail d'infrastructure préventif plutôt que sur un incident existant sur le mainnet.

CPS-0034 étend les tests de conformité de Plutus Core

L'équipe Plutus Core a ouvert la proposition à l'examen public le 12 août. Les éditeurs CIP lui ont ensuite attribué le numéro CPS-0034 à la suite de son examen initial, tandis que la proposition technique reste ouverte aux retours.

Selon la proposition CPS-0034, Cardano fournit actuellement aux développeurs externes environ 1 000 tests prédéfinis de type golden file. Ceux ci permettent à un évaluateur indépendant d'exécuter un script fourni et de comparer sa sortie avec le résultat attendu.

La suite existante offre une vérification initiale de compatibilité mais présente deux limites identifiées. Elle n'expose pas les tests fondés sur des propriétés utilisés en interne par l'équipe Plutus et elle ne couvre que la dernière combinaison de version du protocole, de version du langage du registre et de modèle de coûts.

Les tests basés sur des propriétés vont au delà d'un ensemble plus restreint d'exemples préparés manuellement. Un générateur peut produire des centaines ou des milliers d'entrées variées, construire des scripts Plutus à partir de celles ci et vérifier si les propriétés comportementales définies continuent de tenir.

Cette approche élargit la couverture à des combinaisons inhabituelles, des valeurs limites et des conditions qui peuvent rarement apparaître lors d'une activité normale. Ce sont aussi les situations dans lesquelles des implémentations développées de manière indépendante sont plus susceptibles de révéler des hypothèses différentes sur le comportement du protocole.

CPS-0034 propose de distribuer des cas de test générés dans un format portable que les implémentations externes peuvent consommer avec un effort d'intégration minimal. Chaque test pourrait contenir le programme, ses entrées, le résultat attendu et, le cas échéant, le budget d'exécution attendu.

La couverture historique est également incluse. Cardano a traversé plusieurs ères du registre, des hard forks, des versions du langage Plutus et des changements de modèle de coûts. Un nœud alternatif doit interpréter correctement cette histoire s'il est censé rejouer la chaîne et valider des blocs antérieurs.

La proposition se concentre spécifiquement sur la conformité des évaluateurs Plutus Core. Elle ne définit pas un cadre de test complet pour chaque composant réseau, registre et consensus à l'intérieur d'un nœud Cardano. Sa pertinence pour la sécurité des nœuds vient du fait que des résultats d'évaluation de scripts différents peuvent modifier la validité d'une transaction ou d'un bloc.

Le code indépendant doit prouver un comportement cohérent

CPS-0034 comporte encore plusieurs questions techniques ouvertes. Les développeurs discutent de la manière de distribuer les tests générés, de la façon de rapporter les écarts entre résultats attendus et réels, de la manière de filtrer les cas par version de protocole et de la façon d'exécuter efficacement des milliers de tests.

Des développeurs liés à Amaru ont déjà rejoint la discussion publique. Amaru est un client de nœud Cardano open source écrit en Rust, offrant aux opérateurs une implémentation développée séparément du cardano-node Haskell établi.

Un contributeur d'Amaru a indiqué que le projet consomme déjà des suites de conformité sémantiques et flat existantes. Les retours ont soutenu des tests plus larges fondés sur des propriétés et sur les versions, tout en demandant des scénarios sur chaîne réalistes, des formats de données neutres par rapport au client et une voie simple pour que des tiers contribuent des cas supplémentaires.

Parmi les approches suggérées figuraient des jeux de tests structurés et l'étiquetage des cas selon les versions de protocole et de langage qu'ils couvrent. La discussion a aussi soulevé des inquiétudes à l'idée d'implémenter le générateur exclusivement en Haskell, car cela pourrait créer une barrière supplémentaire pour des équipes travaillant dans d'autres langages.

Une norme de test partagée n'exigerait pas un code source identique. Chaque équipe pourrait conserver sa propre architecture, son langage de programmation et son approche de développement, tandis que le comportement d'exécution résultant resterait compatible avec les règles de Cardano.

Pour les détenteurs d'ADA, l'enjeu concerne la résilience de l'infrastructure plutôt que la performance du marché à court terme. Les plateformes d'échange, portefeuilles, applications décentralisées et systèmes institutionnels dépendent du fait que différents nœuds parviennent à des décisions déterministes au sujet des transactions, scripts et blocs.

Si CPS-0034 produit une suite de conformité portable et sensible aux versions, un client Cardano alternatif ne démontrera plus sa compatibilité simplement en existant en tant que base de code distincte. Il pourra fournir des preuves reproductibles que des logiciels écrits de manière indépendante aboutissent au même résultat et au même coût d'exécution à travers l'histoire du protocole de Cardano, en exposant les désaccords lors des tests avant qu'ils ne puissent atteindre un bloc en production.