La proposition Plutus de Cardano vise à réduire la surcharge d’exécution des scripts

La chaîne de développement Plutus de Cardano a ajouté deux propositions axées sur la manière dont les contrats intelligents traitent les données du registre. CIP-0194 introduit une correspondance de motifs intégrée pour UPLC, tandis que CIP-0195 précise comment les types Plutus V4 tels que ScriptContext et TxInfo doivent être encodés en tant que Data. Toutes deux restent en cours d’examen.

CIP-0194 dispose déjà d’un prototype fonctionnel, avec de premiers benchmarks locaux montrant un temps d’exécution CEK nettement inférieur pour plusieurs schémas d’accès aux données. Ces mesures ne sont pas calibrées sur les unités d’exécution sur chaîne, et les paramètres de coût en production ne sont pas encore finalisés.

CIP-0194 ajoute la correspondance de motifs à Plutus Core

Les contrats intelligents Cardano inspectent fréquemment des Data structurées, y compris les informations de transaction au sein de ScriptContext. Les programmes UPLC existants peuvent déconstruire ces structures au moyen de fonctions telles que unConstrData, chooseData et des opérations sur listes, chaque étape ajoutant du travail dans l’évaluateur CEK.

CIP-0194 propose une nouvelle opération Match capable d’inspecter directement des valeurs imbriquées et de ne capturer que les champs requis par un script. Elle couvre les entiers, les chaînes d’octets, les listes, les paires et les Data structurées, tandis que le mécanisme existant Case reste disponible pour des opérations plus simples.

Cette évolution vise principalement les validateurs qui inspectent à répétition le contexte des transactions, y compris des logiques DeFi, de trading et de prêt plus complexes.

Un prototype opérationnel existe déjà dans la base de code Plutus. Une utilisation en production nécessiterait encore des tests de conformité, des paramètres de coût calibrés, la prise en charge par le registre et une version du nœud Cardano.

Les premiers benchmarks montrent un temps d’exécution CEK plus faible

Le CIP inclut des benchmarks locaux comparant Match aux méthodes existantes de déconstruction de Data.

Lors de la récupération d’une valeur fortement imbriquée unique, l’exécution CEK mesurée était entre 6.38 et 13.74 fois plus rapide dans les scénarios testés. Un test impliquant 64 couches de Data imbriquées a enregistré 2.297 microsecondes avec Match, contre 31.068 microsecondes avec l’approche existante.

L’écart de performance se réduit lorsque les scripts capturent plusieurs valeurs, avec des améliorations testées allant d’environ 1.67 à 6.10 fois selon la structure et la méthode de référence.

Ces chiffres mesurent les performances locales du CEK en temps réel plutôt que les unités d’exécution finales de Cardano. Le modèle de coûts reste non calibré. Les budgets préliminaires CPU et mémoire dans la proposition se sont améliorés de 10% à 90% selon les charges de travail, avec des scénarios typiques de contexte de script montrant environ 40% à 60% d’amélioration sous les paramètres initiaux.

La proposition assigne Match à la version 1.2.0 du langage Plutus Core, ce qui nécessiterait la prise en charge par le registre et une activation via le processus de hard fork de Cardano avant que les scripts ne puissent l’utiliser sur le mainnet.

CIP-0195 définit le modèle Data de Plutus V4

CIP-0195 traite l’autre versant de la pile Plutus en spécifiant comment les types de l’API de registre Plutus V4 doivent être représentés en tant que Data.

La proposition couvre le ScriptContext V4 et les structures associées, y compris un TxInfo étendu. Elle remplace l’approche plus informelle utilisée dans les premières versions de Plutus, où les développeurs et les outils alternatifs devaient souvent déduire le comportement d’encodage à partir du code d’implémentation plutôt qu’à partir d’une spécification dédiée.

La conception V4 proposée continue d’utiliser des listes pour l’encodage des types de données. CIP-0195 soutient que les opérations UPLC plus récentes rendent l’accès aux listes efficace tout en évitant les constructeurs additionnels et l’intégration au registre qu’exigerait un modèle plus large basé sur des tableaux.

CIP-0194 et CIP-0195 peuvent progresser indépendamment, mais ensemble ils traitent la manière dont la prochaine génération de Plutus structure et accède aux données du registre. S’il est adopté, CIP-0195 normaliserait la façon dont Plutus V4 expose ces données, tandis que CIP-0194 offrirait aux validateurs une manière à plus faible surcharge de les inspecter. Les deux nécessitent encore l’approbation des spécifications, des modèles de coût calibrés et une intégration au registre avant d’atteindre le mainnet Cardano.