Cardano propose de supprimer la vérification de portée de Plutus

La proposition CIP-0205 de Cardano éliminerait l'une des étapes utilisées pour préparer les scripts Plutus à l'exécution. Son auteur, Jacco Krijnen, propose de traiter les erreurs de variables non liées à une valeur pendant l'exécution plutôt que de vérifier l'ensemble du programme au préalable. Soumise le 25 septembre, la proposition reste à l'étude.

Le coût de préparation des scripts Plutus

Avant d'exécuter un script, un nœud vérifie que ses variables sont correctement définies dans le programme. Appelée vérification de portée, cette opération a lieu durant la deuxième phase de validation des transactions.

Des benchmarks antérieurs cités par la proposition ont constaté que cette vérification représentait environ 20% du temps de préparation des scripts, y compris le décodage et la vérification de version. Dans des benchmarks de validation complète, elle représentait environ 3% du temps total de validation. Ces chiffres mesurent la part de temps de traitement attribuable à cette vérification dans ces charges de test.

La supprimer réduirait le travail de traitement pour les scripts admissibles. Toute diminution des frais de transaction qui en résulterait dépendrait d'ajustements ultérieurs des paramètres de frais, selon la proposition.

Comment Plutus traiterait les erreurs de variables

Plutus Core est le langage utilisé pour exécuter les scripts de contrats intelligents sur Cardano. Son moteur d'exécution, la machine CEK, gère déjà les tentatives d'utilisation de variables sans valeur liée.

Dans la discussion d'examen de la proposition, le développeur Seungheon Oh a noté que CEK ne dépend pas de la vérification préliminaire de portée. Tenter d'évaluer une variable non liée entraîne un échec ordinaire d'exécution.

Selon les règles proposées, un programme pourrait réussir si une variable non liée n'apparaît que dans du code jamais exécuté. Les programmes dont la portée est correctement définie conserveraient les mêmes résultats d'exécution.

Les langages de développement comme Aiken, Plinth et Plutarch imposent déjà la portée des variables via leurs vérificateurs de types avant que les scripts n'atteignent la blockchain, note la proposition.

Une nouvelle version du langage et un hard fork

L'ébauche lie le changement à la version 1.2.0 du langage Plutus Core, ce qui nécessiterait un hard fork. La mise en œuvre comprendrait des mises à jour de la spécification, du code d'exécution, du modèle formel et des tests de conformité.

La proposition a reçu le numéro CIP-0205 le 29 septembre. L'éditeur des CIP, Robert Phair, a demandé une diffusion plus large auprès des groupes de travail avant la poursuite de l'examen, en citant l'ampleur du changement.

Selon l'ébauche actuelle, les scripts existants utilisant les versions 1.0.0 et 1.1.0 du langage conserveraient leur comportement. Après l'activation, les nouveaux scripts déclarant la version 1.2.0 pourraient s'exécuter sans la vérification préliminaire de portée distincte.