La Cardano Foundation a publié Cardano Rosetta Java v2.1.0, introduisant une fonctionnalité de gouvernance complète de l'ère Conway via des points de terminaison Mesh API standardisés, permettant aux plateformes d'échange et aux développeurs d'interagir pour la première fois avec l'infrastructure de gouvernance décentralisée de Cardano via l'interface Rosetta.
L'ère du registre Conway, également appelée phase Voltaire, représente la transition de Cardano vers une gouvernance on-chain où les détenteurs d'ADA, les opérateurs de pools de mise (Stake Pool Operators) et les représentants délégués (Delegated Representatives) participent directement aux décisions du protocole. Jusqu'à la v2.1.0, cette couche de gouvernance n'était pas accessible via l'API Rosetta sur laquelle les plateformes d'échange et les intégrateurs institutionnels s'appuient pour l'interaction standardisée avec la blockchain.
Cette version comble cette lacune à travers les points de terminaison de construction et de données.
Les SPO peuvent désormais voter on-chain sur les actions de gouvernance directement via l'API. Les utilisateurs peuvent déléguer leur pouvoir de vote aux DReps via la même interface plutôt que de nécessiter des outils séparés. La prise en charge du CIP-129 a été ajoutée, permettant l'inférence automatique du type DRep à partir d'identifiants préfixés, ce qui simplifie la gestion des identités des participants à la gouvernance lors de la construction des transactions. Les opérations de gouvernance, y compris dRepVoteDelegation, sont désormais correctement identifiées et renvoyées via les points de terminaison block, block/transaction et construction/parse.
Pour les plateformes d'échange en particulier, la couverture standardisée des points de terminaison signifie que les transactions liées à la gouvernance peuvent être analysées, validées et affichées en utilisant la même infrastructure déjà en place pour les transferts ADA standard et les opérations de mise.
Au-delà de la gouvernance, la v2.1.0 inclut plusieurs améliorations d'infrastructure. Les opérations au sein des points de terminaison de données sont désormais triées par index dans l'ordre croissant, améliorant la cohérence pour les développeurs qui analysent les données de transaction de manière programmatique. La gestion des codes d'état HTTP a été corrigée pour aligner les types d'erreurs avec les codes de réponse appropriés : les erreurs non réessayables renvoient désormais 400 Bad Request plutôt que 500 Internal Server Error, un changement qui rend la gestion des erreurs plus prévisible pour les intégrateurs. Une interface d'administration expérimentale pour l'indexeur est désormais accessible à localhost pour les développeurs exécutant des instances locales.
Aucun de ces changements n'est une fonctionnalité phare, mais la correction du code d'état HTTP est le type de correction qui élimine une catégorie de confusion de débogage qui a frustré les développeurs intégrant la version précédente. Les petites améliorations de la gestion des erreurs ont tendance à avoir un impact pratique considérable.
Le chemin de mise à niveau depuis la v2.0.0 est entièrement compatible et ne nécessite aucune resynchronisation des données, ce qui signifie que les plateformes d'échange et les opérateurs d'infrastructure sur la version majeure actuelle peuvent appliquer la mise à jour sans temps d'arrêt opérationnel. Pour les opérateurs exécutant encore la v1.x.x, une resynchronisation complète de la genesis du yaci-indexer est requise, bien que les données existantes du Cardano Node puissent être conservées tout au long du processus.
La distinction compte pratiquement. Les opérateurs qui sont passés à la v2.0.0 lors de sa sortie en février 2026 bénéficient d'une mise à niveau fluide. Ceux qui n'ont pas encore migré depuis la v1.x.x font face à un processus plus complexe avant d'accéder aux fonctionnalités de gouvernance de la v2.1.0.
La version v2.0.0 sortie début février 2026 était la mise à jour significative précédente, qui a réduit le temps de synchronisation du réseau d'environ 30 %, faisant passer la synchronisation de 52 heures à environ 37 heures. Cette réduction était significative pour les plateformes d'échange et les développeurs exécutant une infrastructure de nœud complet, réduisant le temps de préparation opérationnelle de plus de 15 heures pour les nouveaux déploiements.
La v2.1.0 s'appuie sur cette fondation en ajoutant la couche de gouvernance plutôt qu'en remplaçant ou en modifiant les améliorations de synchronisation. Les deux versions ensemble représentent un calendrier raisonnablement compressé d'avancement de l'infrastructure : synchronisation plus rapide en février, intégration de l'API de gouvernance le même mois.
Le modèle de gouvernance on-chain de Cardano est un composant relativement nouveau et encore en maturation du protocole. La capacité des SPO et des détenteurs d'ADA à participer aux actions de gouvernance existe au niveau du protocole, mais les taux de participation dépendent en partie de l'accessibilité des outils sur les plateformes où la plupart des utilisateurs interagissent avec leurs avoirs.
Une plateforme d'échange qui peut désormais présenter la participation à la gouvernance directement via des points de terminaison API standardisés supprime une étape du processus pour les utilisateurs qui auraient autrement besoin d'outils externes pour voter ou déléguer. La question de savoir si cette réduction des frictions se traduit par des taux de participation à la gouvernance significativement plus élevés est une question à laquelle les données on-chain suivant la sortie finiront par répondre.
L'article Cardano Foundation Updates Its Exchange API to Include Full Governance Support est apparu en premier sur ETHNews.


