Philip DiSarro signale deux failles critiques dans l’implémentation CIP-113 d’Aiken

Philip DiSarro, fondateur et PDG d’Anastasia Labs et auteur de CIP-143, a déclaré le 24 juillet avoir identifié deux vulnérabilités critiques lors de l’examen de l’implémentation Aiken du cadre de jetons programmables CIP-113 de Cardano. Dans le même fil, il a publié des benchmarks mis à jour comparant la base de code Aiken avec l’implémentation Plutarch originale développée par DiSarro et l’équipe Input Output. Cette divulgation intervient alors que CIP-113 demeure au stade Last Check et que son implémentation poursuit la revue de sécurité.

Plutarch enregistre des coûts inférieurs sur l’ensemble des benchmarks CIP-113

Le fichier de benchmark publié compare les deux implémentations sous le budget maximal de transaction de Cardano de 10 milliards d’unités CPU et 14 millions d’unités mémoire. Aiken et Plutarch compilent finalement en Untyped Plutus Core, le code exécuté par les nœuds Cardano.

Plutarch a enregistré une consommation totale de CPU et de mémoire inférieure dans chacun des cinq scénarios mis en avant.

Dans le test de transfert standard, Aiken a utilisé 1,19 fois plus de CPU et 1,17 fois plus de mémoire que Plutarch. La plus grande différence parmi les scénarios présentés est apparue dans le test combinant une action de saisie, un script externe et 50 entrées à clé publique, où Aiken a consommé 3,23 fois plus de CPU et 2,36 fois plus de mémoire.

Les deux implémentations sont restées dans les limites de transaction de Cardano lors du test 16-swap $NIGHT DEX. Plutarch a utilisé 6,66 % du budget CPU disponible et 11,68 % du budget mémoire, contre 7,59 % et 15,25 % pour Aiken.

La publication de DiSarro incluait également des projections linéaires du nombre d’éléments pouvant tenir dans une seule transaction. Les estimations plaçaient Plutarch à 658 entrées contre 162 pour Aiken, 472 sorties contre 334, 36,489 jetons contre 1,661, et 527 politiques contre 160. Ces chiffres sont des projections de capacité de script dérivées des coûts d’exécution testés plutôt que du débit mesuré sur le mainnet.

La comparaison des scripts compilés a produit des scripts Plutarch plus petits dans six des sept catégories. Le script directoryNodeSpending mesurait 331 octets dans Plutarch et 1,698 octets dans Aiken. L’exception était programmableLogicGlobal, où Aiken a produit un script de 3,157 octets contre 3,437 octets pour Plutarch.

CIP-113 ajoute des règles programmables aux actifs natifs de Cardano

CIP-113 propose un cadre permettant d’ajouter des règles de validation programmables aux actifs natifs de Cardano sans nécessiter de modification du registre ni de hard fork. Les émetteurs pourraient définir des conditions qui s’exécutent lors des transferts, de la frappe et de la destruction de jetons.

Les règles peuvent inclure des allowlists, des denylists, des restrictions de transfert, des verrous temporels ainsi que des fonctions facultatives de gel ou de saisie. Le cadre vise les stablecoins, les titres tokenisés et les actifs du monde réel qui nécessitent des contrôles liés à la propriété et aux mouvements.

Dans l’architecture proposée, les jetons programmables sont détenus à une adresse de contrat intelligent partagée, tandis que la propriété est représentée par des identifiants de stake. Un registre on-chain relie chaque politique de jeton à ses règles de transfert, sa logique d’émission et tout contrôle tiers autorisé.

Les portefeuilles devraient résoudre les identifiants de stake afin d’afficher correctement les soldes. Les échanges décentralisés, les indexeurs, les explorateurs et d’autres applications devraient également prendre en charge le processus de validation supplémentaire avant que les utilisateurs puissent interagir avec des jetons programmables via l’infrastructure Cardano existante.

Aiken et Plutarch offrent des approches de développement différentes tout en compilant vers le même format de code on-chain. La documentation développeur de Cardano présente Aiken comme un point de départ accessible avec des tests intégrés et une syntaxe dédiée. Plutarch est un langage embarqué basé sur Haskell qui donne aux développeurs un contrôle plus fin sur le code généré et les coûts d’exécution.

DiSarro est l’auteur de CIP-143, Interoperable Programmable Tokens, et a travaillé avec l’équipe Input Output sur son implémentation de référence Plutarch originale. Le dépôt de la Cardano Foundation indique que les validateurs Aiken actuels ont été migrés à partir de cette implémentation et adaptés au cadre CIP-113 plus large.

Sa participation directe à l’architecture et à la base de code originales inscrit la nouvelle comparaison de benchmarks dans l’historique de développement du projet. CIP-143 est désormais marqué inactif après avoir été incorporé dans le candidat CIP-113, qui reste au stade de revue Last Check des éditeurs de CIP.

Deux vulnérabilités signalées en attente de divulgation technique

DiSarro a indiqué que son examen de l’implémentation Aiken a mis au jour deux vulnérabilités critiques passées inaperçues durant le processus d’audit. Son fil n’a pas identifié le code affecté, les vecteurs d’attaque possibles, l’impact potentiel ni l’état des correctifs.

Le dépôt contient déjà des constats publics issus de l’audit initial, dont deux tickets clos étiquetés critiques. Issue 56 décrivait une voie par laquelle des jetons nouvellement frappés pouvaient échapper à la garde programmable lors d’une action tierce. Issue 64 traitait de la possible contamination de UTxOs non liés via la même fonction administrative.

Ces constats ont été rapportés durant l’audit initial et ne peuvent pas être identifiés comme les deux vulnérabilités que DiSarro dit avoir trouvées ensuite sans divulgation technique supplémentaire.

Des préoccupations de sécurité ont également été soulevées dans la discussion de revue de CIP-113. Un contributeur a indiqué le 20 juillet que plusieurs vulnérabilités de gravité élevée avaient été manquées et que certaines améliorations proposées en matière d’utilisabilité introduisaient des problèmes de sécurité supplémentaires. Lors de la revue de CIP suivante, les participants ont convenu que la prochaine étape devrait inclure un audit plus complet tandis que la proposition reste à l’étape Last Check.

Le dépôt de la Cardano Foundation indique que les constats de l’audit initial et d’un réaudit de suivi ont été corrigés sur la branche principale. Cependant, le rapport d’audit final n’a pas été publié et le dépôt désigne l’implémentation comme impropre à un usage en production avec de vrais actifs tant que le rapport, des tests plus larges et des revues d’experts supplémentaires ne seront pas achevés.

Avant que l’implémentation de CIP-113 puisse progresser vers des déploiements impliquant de vrais actifs, trois livrables concrets restent en attente : la publication du rapport d’audit final, la divulgation et la remédiation des deux vulnérabilités signalées par DiSarro, ainsi que l’achèvement de la revue de sécurité élargie demandée durant le processus CIP. Ces livrables définiront quels changements de code et de spécification seront intégrés avant que la proposition soit fusionnée et que l’implémentation soit envisagée pour un usage en production.