Cardano propose des alertes décentralisées pour les pools de staking et les applications

CIP-0201 propose un réseau de communication décentralisé pour les alertes de sécurité Cardano, les annonces de pools de staking, les mises à jour de gouvernance et les notifications d’application. Les messages circuleraient entre les nœuds participants, les signatures permettant aux destinataires d’en vérifier la source. La proposition est devenue un candidat CIP le 29 septembre et reste en cours d’examen technique.

Alertes signées pour les opérateurs et les utilisateurs de Cardano

Le CPS-0038 associé identifie quatre besoins de communication : des alertes d’incident pour les opérateurs de pools de staking, des annonces de pool pour les délégateurs, des informations de vote pour les participants à la gouvernance et des notifications d’application concernant des positions ou des modifications de protocole.

Un pool se préparant à être mis hors service, par exemple, doit notifier les délégateurs tant qu’ils ont encore le temps de déplacer leur délégation. Une application peut devoir alerter les utilisateurs avant une échéance affectant leurs positions.

Ces messages passent actuellement par des listes de diffusion, des plateformes de communication et l’infrastructure des fournisseurs. CPS-0038 décrit l’absence d’une norme Cardano commune combinant l’authentification de l’émetteur, l’intégrité des messages et une résistance mesurable à la suppression ciblée.

L’authentification seule ne résout pas la livraison. Le document examine des attaques dans lesquelles des participants malveillants contrôlent les connexions réseau d’un destinataire et retiennent des messages. Ce destinataire peut ne disposer d’aucune preuve qu’une alerte a été envoyée, ce qui fait de la sélection des pairs une partie du problème de communication.

Comment CIP-0201 distribuerait les notifications

Le système proposé utilise un modèle publication abonnement. Les émetteurs envoient des messages signés vers des thèmes nommés, et les nœuds abonnés les reçoivent et les transmettent à leurs pairs connectés.

Les nœuds PubSub fonctionneraient séparément des nœuds Cardano. Leurs enregistrements d’inscription résideraient sur la blockchain, tandis que le contenu des notifications resterait hors chaîne.

Pour chaque période de diffusion, un aléa partagé détermine quelles paires de nœuds enregistrés peuvent se connecter. Chaque nœud sélectionne en privé des pairs à partir de cet ensemble éligible. Les connexions tournent périodiquement, offrant à un abonné isolé une autre opportunité d’atteindre des participants qui relaient les messages.

Les numéros de séquence révèlent des lacunes dans le flux de messages d’un émetteur. Les nœuds conservent temporairement des copies afin que des pairs puissent demander les notifications manquantes. Ce mécanisme de récupération offre des opportunités de livraison supplémentaires, même si la rotation ne garantit pas la réception au cours d’une seule période.

Chaque nœud enregistré bloquerait un dépôt ADA remboursable, rendant plus coûteuse la création d’identités en grand nombre. L’ADA bloqué ne génère pas de récompenses de staking et n’accorde aucun poids supplémentaire à l’opérateur dans le réseau de messagerie. Le retrait intervient après la mise hors service de l’inscription et un délai d’attente obligatoire.

Le déploiement nécessite des tests de récupération et une intégration aux portefeuilles

Le prototype de référence permet des expérimentations mais n’implémente pas encore la spécification complète. Le déploiement exige des règles d’interopérabilité finalisées, une source d’aléa choisie et des tests couvrant la rotation des connexions et la récupération. Les critères d’activation exigent aussi deux implémentations interopérantes et des résultats de conformité publiés.

Le fonctionnement lors d’un arrêt ou d’un fork de la chaîne Cardano reste à trancher, car les registres des participants et les paramètres partagés dépendent des données de la blockchain. La proposition n’appelle pas à un hard fork de Cardano.

Les fournisseurs de portefeuilles prendraient en charge l’étape finale de livraison. CPS-0038 distingue l’arrivée d’un message à l’infrastructure participante de son arrivée chez un utilisateur individuel. Dans le scénario de mise hors service d’un pool, le réseau acheminerait l’annonce signée vers un backend de portefeuille ; le portefeuille devrait ensuite rendre cet avis visible aux délégateurs concernés avant qu’ils ne changent de pool.