En savoir plus sur Plutus | Partie 1

[Uptodate_Developers]

(1) Introduction sur Plutus

Veuillez noter que Cardano Docs n’est pas la principale source de référence pour la documentation de Plutus. Consultez la prochaine section “Ressources Plutus” pour trouver des liens vers des informations et des ressources essentielles liées à Plutus.

Plutus est le langage de contrat intelligent natif de Cardano. Il s’agit d’un langage Turing-complet écrit en Haskell, et les contrats intelligents Plutus sont en fait des programmes Haskell. En utilisant Plutus, vous pouvez être sûr de la bonne exécution de vos contrats intelligents. Il s’inspire de la recherche sur les langages modernes pour fournir un environnement de programmation complet et sûr basé sur Haskell, le principal langage de programmation purement fonctionnel.

Contrats intelligents Plutus

Les contrats intelligents Plutus se composent de parties qui s’exécutent sur la blockchain (code en chaîne) et de parties qui s’exécutent sur la machine d’un utilisateur (code hors chaîne ou client). Le code hors chaîne peut être écrit à l’aide du Plutus Application Framework (PAF), et ce code est ensuite compilé par le GHC (Glasgow Haskell Compiler), tandis que le code en chaîne est compilé par le compilateur Plutus dans Plutus Core.

Modèle comptable utilisé par Plutus

Cardano utilise le modèle de comptabilité UTXO étendu (EUTXO) qui étend le modèle de comptabilité de sortie (U) de transaction (TX) non dépensé (U) (UTXO) (utilisé par Bitcoin). Dans le modèle UTXO, une transaction a des entrées et des sorties , où les entrées sont les sorties non dépensées des transactions précédentes. Dès qu’une sortie est utilisée comme entrée dans une transaction, elle est dépensée et ne peut plus jamais être utilisée. La sortie est spécifiée par une adresse (une clé publique ou un hachage de clé publique) et une valeur (composée d’un montant ada et de montants de jetons natifs supplémentaires facultatifs).

EUTXO étend le modèle UTXO en permettant aux adresses de sortie de contenir une logique complexe pour décider quelles transactions peuvent les déverrouiller, et en ajoutant des données personnalisées à toutes les sorties. Ce modèle offre des avantages uniques par rapport aux autres modèles comptables. Le succès ou l’échec de la validation de la transaction dépend uniquement de la transaction elle-même et de ses entrées et de rien d’autre sur la blockchain. Par conséquent, la validité d’une transaction peut être vérifiée hors chaîne avant que la transaction ne soit envoyée à la blockchain. Une transaction peut toujours échouer si une autre transaction consomme simultanément une entrée attendue par la transaction. Cependant, si toutes les entrées sont toujours présentes, la transaction est garantie de réussir.

Noyau de Plutus

Plutus Core est le langage de script utilisé par Cardano pour implémenter le modèle EUTXO. C’est un langage simple et fonctionnel similaire à Haskell, et un grand sous-ensemble de Haskell peut être utilisé pour écrire des scripts Plutus Core. En tant qu’auteur de contrat intelligent, vous n’écrivez aucun Plutus Core ; à la place, tous les scripts Plutus Core sont générés par un plugin de compilateur Haskell.

Ces scripts seront exécutés par les nœuds lors de la validation des transactions ‘live’ sur la chaîne. Ils verrouillent les EUTXO sous la forme de scripts de validation ou sous forme de politiques de frappe, qui contrôlent la frappe et la gravure des jetons natifs.

En pratique, lors du développement de contrats intelligents, vous écrirez des scripts de validation dans Haskell, qui seront ensuite automatiquement compilés dans Plutus Core à l’aide d’un plug-in GHC appelé Plutus Tx.

Cadre d’application Plutus (PAF)

Le PAF offre un accès facile aux services couramment utilisés par les applications Plutus. Les applications déployées à l’aide des bibliothèques du framework peuvent être exécutées sur le backend de l’application Plutus, qui fournit un support d’exécution pour l’accès à la blockchain et d’autres problèmes tels que la persistance, la journalisation et la surveillance. Les applications écrites au-dessus du PAF fournissent automatiquement une interface HTTP et WebSocket qui peut interagir avec l’application à partir du navigateur Web.

L’état en chaîne des scripts de validation ne peut être modifié que par des transactions qui dépensent et produisent une sortie de script. Lors de l’écriture d’une application Plutus, nous devons prendre en compte non seulement la partie en chaîne de l’application (les scripts Plutus Core), mais également la partie hors chaîne qui construit et soumet les transactions.

Le code hors chaîne est écrit en Haskell, tout comme le code en chaîne, contrairement à Ethereum où le code en chaîne est écrit en Solidity, mais le code hors chaîne est écrit en JavaScript. De cette façon, la logique métier n’a besoin d’être écrite qu’une seule fois. Cette logique peut ensuite être utilisée dans le script du validateur et dans le code qui construit les transactions qui exécutent le script du validateur.

Backend d’application Plutus (PAB)

Le PAB est actuellement en cours de développement et exécutera le composant hors chaîne des applications Plutus. Il gérera les demandes d’application au backend et au nœud du portefeuille, stockera l’état de l’application et offrira une API HTTP pour gérer les instances d’application.

Plutus et jetons natifs

Chaque jeton natif est livré avec sa propre politique de frappe, qui détermine les conditions dans lesquelles les jetons peuvent être frappés et brûlés. Les utilisateurs peuvent écrire des politiques de frappe dans Haskell et les compiler dans Plutus Core. Pendant le processus de frappe ou de gravure, le script de politique Plutus Core est exécuté dans le contexte de la transaction de frappe ou de gravure, et le script devra approuver ou interdire l’action. Cette fonctionnalité accélère encore la croissance des jetons non fongibles (NFT) sur Cardano en permettant la création de politiques de frappe beaucoup plus complexes et en permettant la création de NFT sans confiance.

Avantages de Plutus

Plutus offre des avantages de sécurité considérables. Il offre un moyen plus simple et plus robuste de montrer que vos contrats intelligents sont corrects et ne rencontreront pas les problèmes rencontrés dans la conception précédente du langage des contrats intelligents.

Plutus permet une nouvelle approche intégrée du développement de contrats intelligents et d’applications distribuées qui est plus pratique et plus sûre que les alternatives précédentes. Le code en chaîne et hors chaîne est basé sur le même langage. Vous utilisez une base de code uniforme, que la chaîne d’outils Plutus sépare ensuite automatiquement en code et packages en chaîne et hors chaîne pour le déploiement.

De plus, contrairement à Ethereum, Plutus prend en charge nativement les jetons définis par l’utilisateur (à la fois fongibles et non fongibles), ce qui ne nécessite pas de contrat intelligent d’accompagnement.

(2) Plutus ressources

Cette section vise à fournir aux utilisateurs un moyen simple de trouver des liens vers des informations et des ressources essentielles liées à Plutus. Cela inclut les référentiels Plutus, les discussions, la documentation, les ressources communautaires, le matériel de formation, les exemples de projets et les références au programme Plutus Pioneer.

Ressources pour les développeurs Plutus

- Noyau de Plutus

Plutus Core est le langage de script intégré au grand livre Cardano. Il constitue la base de la plate-forme Plutus - une plate-forme de développement d’applications pour le développement d’applications décentralisées (DApps) sur la blockchain Cardano.

Ressources développeurs :

Référentiel Plutus Core GitHub : comprend l’implémentation, la spécification et la métathéorie mécanisée de Plutus Core ainsi que de Plutus Tx - le compilateur de Haskell à Plutus Core.

- Outils Plutus

Plutus Tools est une collection de ressources d’infrastructure hors chaîne conçues pour les développeurs externes. Le référentiel Plutus Tools SDK prend en charge les ressources sous-jacentes nécessaires pour écrire des applications utilisant Plutus dans Haskell.

Plutus Tools fournit également des bibliothèques pour travailler avec le Plutus Application Framework (PAF) - la partie hors chaîne de la plate-forme Plutus qui permet le développement DApp et l’interaction avec les contrats intelligents.

Ressources développeurs :

Référentiel Plutus Tools GitHub : comprend des bibliothèques qui implémentent le PAF, une sélection de cas d’utilisation de bout en bout écrits avec le PAF et des détails sur Plutus Playground.

- Implémentation officielle du serveur de langage Haskell

L’implémentation du serveur de langage Haskell est une implémentation d’un serveur pour le Language Server Protocol (LSP). Un serveur de langage parle à un client, qui peut demander au serveur d’effectuer diverses opérations, telles que signaler des erreurs ou fournir des complétions de code.

Ressources développeurs :

Documentation du serveur de langage Haskell

- Cours Haskell

Plutus Core, le langage de script de Cardano, est écrit en Haskell. Pour utiliser Plutus, il est indispensable de connaître les bases de Haskell. Pour faciliter le parcours d’intégration, l’équipe éducative d’IOG a créé le cours Haskell pour les débutants. Vous pouvez trouver le référentiel avec des explications, des liens vers des conférences et bien plus ci-dessous.

Cours Haskell

- Documentation de l’API du nœud Cardano

Ressources développeurs :

Documentation de l’API du nœud Cardano : la documentation générée par Haddock pour l’API du nœud Cardano.

(2) Scripts Plutus

Cardano utilise des scripts pour valider les actions. Ces scripts, qui sont des morceaux de code, implémentent des fonctions pures avec des sorties True ou False. La validation de script est le processus d’invocation de l’interpréteur de script pour exécuter un script donné sur des arguments appropriés.

Que sont les scripts ?

Un script est un programme qui décide si la transaction qui dépense la sortie est autorisée à le faire. Un tel script est appelé un script validateur - il valide si la dépense est autorisée.

Par exemple, un simple script de validation pourrait vérifier si une clé particulière a signé la transaction de dépense - cela reproduirait exactement le comportement des sorties plus simples de pay-from-pubkey. Cependant, avec un peu d’extension prudente, nous pouvons utiliser des scripts pour exprimer une logique plus utile sur la chaîne que cela.

La façon dont le modèle EUTXO fonctionne est que les scripts de validation sont passés en trois arguments :

1. Datum : il s’agit d’une donnée attachée à la sortie que le script verrouille. Ceci est généralement utilisé pour transporter l’état.
2. Rédempteur : il s’agit d’une donnée attachée à l’entrée des dépenses. Ceci est généralement utilisé pour fournir une entrée au script à partir du consommateur.
3. Contexte : il s’agit d’une donnée qui représente des informations sur la transaction de dépense. Ceci est utilisé pour faire des affirmations sur la façon dont la sortie est envoyée (comme “Bob l’a signé”).

Les données contenues dans le contexte sont :

• entrées – sorties à dépenser
• entrées de référence - entrées utilisées à titre de référence uniquement, elles ne sont pas dépensées
• sorties – nouvelles sorties créées par la transaction
• frais – frais de transaction
• valeur frappée - valeur frappée ou brûlée
• certificats – résumé des certificats contenus dans la transaction
• retraits - utilisés pour retirer des récompenses du pool de mises
• plage valide - une plage de temps dans laquelle la transaction est valide
• signataires – une liste des signatures de transaction
• rédempteurs - données utilisées pour fournir une entrée au script à partir du dépensier
• données d’information - une carte des hachages de données à leur valeur de référence
• identifiant - identification de la transaction

Tutoriels et exemples de scripts

• Scripts Plutus
• Écrire des scripts de validation de base
• Rédaction des politiques de frappe de base
• Comment exporter des scripts, des datums et des rédempteurs
• Comment profiler l’utilisation du budget des scripts Plutus
• Exemples de script Plutus à l’ère Babbage
• Exemples de code Plutus Pioneer
• Techniques d’optimisation pour les scripts Plutus
• Changements de langue Plutus (V1 et V2)
• Mise à niveau vers les adresses de script Vasil et Plutus

(3) Développement d’applications Plutus

Cette section fournit un aperçu de haut niveau de ce qu’est une application décentralisée (DApp), de son fonctionnement sur Cardano et d’une liste de ressources pour créer une DApp à l’aide de Plutus.

Qu’est-ce qu’un DApp ?

Une DApp est une application décentralisée qui interagit avec la blockchain. La différence entre un DApp et une application commune est que le code backend d’un DApp s’exécute sur un réseau peer-to-peer décentralisé alors que le code backend de l’application est généralement exécuté sur un serveur centralisé.

Les catégories DApp peuvent inclure des produits DeFi (par exemple, des protocoles de prêt, des échanges, etc.), des marchés NFT, des applications de jeu, des produits de santé et des portefeuilles (souvent utilisés pour se connecter à tous ces éléments), entre autres.

Développement Plutus DApp

Les DApps sont construits sur des outils open source. Pour qu’un DApp fonctionne, il doit avoir un contrat intelligent sous-jacent qui exécute automatiquement la transaction pour les utilisateurs. Tous les enregistrements opérationnels sont ensuite suivis sur le registre de la blockchain. En général, un DApp se compose généralement d’un frontal convivial, d’un backend (généralement basé sur le cloud) avec un contrat intelligent d’exploitation, et est également connecté à un registre blockchain pour suivre les enregistrements en chaîne. Les avantages de DApp incluent une communication sans confiance, une résistance à la censure, la confidentialité et un temps d’arrêt minimal.

Un contrat intelligent (qui se compose de différents scripts) est le moteur de la fonctionnalité d’un DApp. Les scripts Plutus sont écrits en Haskell (à l’aide de la bibliothèque et des outils Plutus) et sont ensuite compilés sur Plutus Core pour être exécutés sur la blockchain Cardano. Le diagramme ci-dessous décrit le processus de développement DApp, du code au déploiement en chaîne :

1. Tout d’abord, les développeurs écrivent le code source du DApp.
2. Écrit en Haskell, ce code passe par le processus de pipeline du compilateur . Le code est d’abord transformé en Plutus IR (représentation intermédiaire) pour le rendre plus efficace puis optimisé en termes de performances. Typed Plutus Core est la prochaine étape du pipeline du compilateur, ce qui permet d’effectuer des vérifications supplémentaires et de déboguer le code. Enfin, le code est transformé en Untyped Plutus Core - une variable de calcul lambda. Plutus Core non typé, ou l’application compilée, est exécuté en chaîne.
3. Une fois le processus d’optimisation terminé, les scripts sont placés sur la chaîne. Les développeurs peuvent utiliser la bibliothèque d’outils Plutus ou d’autres outils open source développés à ces fins. Il est également essentiel d’avoir le composant off-chain (une application), qui formera correctement les transactions pour interagir avec le code on-chain.
4. Enfin, les scripts en chaîne sont traités par l’API Plutus Ledger, puis exécutés et exécutés par l’évaluateur Plutus Core.

(4) Cas d’utilisation de Plutus

Les cas d’utilisation typiques de haut niveau pour les implémentations de Plutus incluent, mais ne sont pas limités à :

• Oracles - oracles entièrement fonctionnels qui apportent des données hors chaîne sur la chaîne pour interagir avec et alimenter les contrats intelligents. De plus, les oracles créent un flux de données hors chaîne centralisé et fiable pour les applications Plutus (par exemple, pour interagir avec les flux de prix de divers échanges centralisés).
• Échanges de jetons DEX - création d’une implémentation qui permet aux utilisateurs d’échanger entre les jetons pris en charge sur un échange décentralisé. Les utilisateurs peuvent créer des pools de liquidités (ou ajouter des fonds à ceux existants), fournissant les pièces nécessaires à l’échange. En retour, ils peuvent gagner de petits frais pour toutes les transactions qui utilisent leurs fonds. Les utilisateurs peuvent également contribuer aux pools de liquidités pour tout jeton pris en charge et donc gagner des commissions sous forme de frais de change pour le faire. Lorsque la liquidité est fournie à un pool, l’utilisateur reçoit un jeton de liquidité représentant ce dépôt. Le contrat doit calculer les commissions qui sont ensuite réparties entre les fournisseurs de liquidité en fonction de la part de chaque fournisseur dans le pool de liquidité.
• Prêt et emprunt - création d’un protocole de prêt qui permet aux utilisateurs de prêter et d’emprunter les crypto-monnaies de leur choix de manière fiable tout en offrant des taux d’intérêt stables et variables. Les utilisateurs peuvent participer en tant que déposants ou emprunteurs. Pour effectuer des transactions, les prêteurs doivent déposer leurs fonds dans des pools de liquidités, afin que les emprunteurs puissent emprunter auprès de ces pools de liquidités. Les déposants reçoivent en retour des jetons portant intérêt. Chaque pool est mis de côté en tant que réserves pour se prémunir contre la volatilité.
• NFT ; frappe, achat et vente de NFT - création de fonctionnalités de base pour la frappe, l’envoi et la réception de NFT dans un portefeuille, avec d’autres scénarios ouverts et extensions possibles.
• Outils de financement décentralisé (DeFi) - création de tableaux de bord polyvalents (basés sur le Web ou mobiles) qui s’intègrent aux contrats intelligents pour apporter de la valeur aux commerçants de jetons natifs. Ces produits peuvent avoir plusieurs tableaux de bord fonctionnels pour afficher les soldes des jetons et des pools de liquidités, etc. Ils peuvent également regrouper plusieurs fonctions telles que l’échange et la fourniture de liquidités en une seule transaction, ce qui facilite l’adoption de DeFi.
• Pièces stables sécurisées par crypto - création d’une nouvelle implémentation de pièces stables basée sur des garanties de chaîne utilisant le système d’identité Atala sur Cardano. Cette mise en œuvre peut inclure des restrictions de transfert, le gel des avoirs, etc.

(5) À propos du mécanisme de garantie

Le mécanisme de garantie est une caractéristique importante qui a été conçue pour assurer une exécution réussie des contrats intelligents.

S’appuyant sur les garanties fournies par la conception déterministe du grand livre, Cardano met en œuvre un schéma de validation en deux phases. La raison principale de l’introduction de la validation en deux phases est de limiter la quantité de travail de validation non rémunéré par les nœuds. Chaque phase a un but dans la réalisation de cet objectif :

• La première phase vérifie si la transaction est correctement construite et peut payer ses frais de traitement
• La deuxième phase exécute les scripts inclus dans la transaction

Si la transaction est phase-1 valid , les scripts de phase-2 s’exécutent. Si la phase 1 échoue, aucun script ne s’exécute et la transaction est immédiatement supprimée.

La garantie est utilisée pour garantir que les nœuds sont indemnisés pour leur travail en cas d’échec de la validation de la phase 2. Ainsi, la garantie est la garantie monétaire qu’un utilisateur donne pour s’assurer que le contrat a été soigneusement conçu et testé de manière approfondie. Le montant de la garantie est spécifié au moment de la construction de la transaction. Pas directement, mais en ajoutant des apports collatéraux à la transaction. Le solde total dans les UTXO correspondant à ces entrées spécialement marquées est le montant de la garantie de la transaction. Si l’utilisateur remplit les conditions de la garantie et qu’un contrat est exécuté, la garantie est en sécurité.

Le scénario

Sans garantie, l’utilisateur n’est pas facturé en cas d’échec d’un contrat intelligent. Cependant, au moment où la transaction échoue, le réseau a déjà encouru des coûts pour initier et valider la transaction. Cela signifie qu’un acteur malveillant pourrait inonder le réseau de transactions invalides, refusant le service aux autres utilisateurs à peu de frais.

La solution

Lorsqu’un utilisateur initie une transaction, il engage suffisamment d’ada pour couvrir son coût d’exécution. À Alonzo, les transactions qui appellent et utilisent des contrats intelligents non natifs (appelés contrats de phase 2) ont également besoin de suffisamment de garanties pour couvrir les coûts liés aux échecs potentiels des transactions. Ce montant peut être faible, mais il est suffisant pour rendre une attaque par déni de service (DOS) d’un coût prohibitif.

Les frais de garantie ne sont perçus que si une transaction échoue à la validation. Si le contrat passe la validation, les frais de transaction sont perçus, mais pas la garantie.

Le raisonnement

Un utilisateur honnête ne risque jamais de perdre sa garantie.

La blockchain Cardano est déterministe en ce qui concerne les coûts de transaction car ces coûts ne dépendent que des valeurs locales et de l’état local. Cela signifie qu’un utilisateur peut calculer le coût d’exécution (en ada) d’une transaction avant de la soumettre. Cette fonctionnalité est différente des autres blockchains, y compris Ethereum, où d’autres activités de réseau peuvent influencer le coût du gaz. Le montant de garantie requis dépend uniquement du coût d’exécution.

Le réseau de test Cardano fournit un environnement sûr avec un ada de test gratuit, afin que les développeurs d’applications distribuées (DApp) puissent tester en profondeur leurs contrats intelligents avant de les déployer sur le réseau principal. Si les transactions réussissent sur le testnet, le développeur peut être parfaitement sûr que tous les scripts réussiront effectivement.

Si les conditions de la chaîne ont changé depuis la construction de la transaction, cette transaction sera entièrement rejetée et aucun frais ne sera facturé. S’il manque une signature, par exemple, aucune garantie ne sera facturée.

Détails techniques

Le terme garantie fait référence à l’ada total contenu dans les UTXO référencés par les entrées de garantie. Une transaction utilise des intrants de garantie pour couvrir ses frais si un script de phase 2 échoue.

La spécification formelle Shelley a introduit le concept de scripts « multi-signatures ». Les scripts de phase 1, tels que ceux-ci, sont entièrement capturés par les règles du grand livre. Les coûts d’exécution peuvent donc être facilement évalués avant qu’ils ne soient traités par l’implémentation, et tous les frais peuvent être calculés directement dans l’implémentation de la règle du grand livre, en fonction de la taille de la transaction qui inclut le script, par exemple.

En revanche, les scripts de phase 2 peuvent effectuer des calculs arbitraires (et, en principe, complets de Turing). Nous exigeons que les transactions qui utilisent des scripts de phase 2 aient un budget en termes de nombre d’ExUnits abstraites. Ce budget donne une limite quantitative sur l’utilisation des ressources en termes d’un certain nombre de métriques spécifiques, y compris l’utilisation de la mémoire ou les étapes d’exécution abstraites. Le budget est ensuite utilisé dans le cadre du calcul des frais de transaction.

Avec la mise à niveau Vasil, les développeurs DApp ont également la possibilité de spécifier une adresse de changement pour la garantie du script. Cela signifie qu’en cas d’échec de la validation de la phase 2 du script, seul le bon montant sera prélevé et les fonds restants seront envoyés à l’adresse de changement fournie.

(6) Coûts de transaction et déterminisme

L’approche de Cardano en matière de fixation des prix repose principalement sur la demande du marché plutôt que sur l’offre réelle. Avec le lancement des contrats intelligents, il existe plus d’un type de demande en concurrence pour l’offre commune. Ainsi, il est crucial de considérer à la fois les prix relatifs et absolus . Une façon d’y parvenir est d’inspecter les effets de la tarification des contrats intelligents, des opérations de jeton non fongible (NFT), etc., par rapport à une valeur commune - dans notre cas, la consommation de la puissance de traitement de Cardano.

La conception du registre Cardano est axée sur une assurance élevée, la sécurité et une vérification formelle éprouvée. Conformément à cette stratégie, il est également important de s’assurer que le traitement des transactions est déterministe , ce qui signifie qu’un utilisateur peut prédire l’impact et le résultat d’une transaction avant son exécution réelle.

La capacité à garantir le coût d’exécution de la transaction et le comportement de la transaction dans le grand livre avant sa soumission devient encore plus importante avec l’introduction de la prise en charge des contrats intelligents. Cette fonctionnalité est différente des autres blockchains, y compris Ethereum, où d’autres activités de réseau peuvent influencer le coût du gaz. Cette capacité est également garantie par la nature déterministe des scripts Cardano et Plutus.

Déterminisme

Le déterminisme , dans le contexte du traitement des transactions et des scripts, est synonyme de prévisibilité. Cela signifie qu’un utilisateur peut prédire localement (hors chaîne) l’impact de sa transaction sur l’état en chaîne du registre, sans rencontrer les éléments suivants :

• résultats ou échecs de validation de script inattendus
• frais imprévus
• mises à jour inattendues de l’état du registre ou du script

Validation

Un aspect important du traitement d’une transaction consiste à valider les actions qu’elle entreprend. Une transaction exécute une action lorsqu’elle contient des données dans le champ spécifique à cette action. Par exemple, une transaction dépense UTXO U lorsqu’elle contient une référence à U dans son champ de saisie, et elle frappe un jeton X lorsque son champ de frappe contient X.

Cardano utilise des scripts pour valider les actions. Ces scripts, qui sont des morceaux de code, implémentent des fonctions pures avec des sorties True ou False . La validation de script est le processus d’invocation de l’interpréteur de script pour exécuter un script donné sur des arguments appropriés.

La validation du script peut être effectuée pour les actions suivantes :

• Dépense d’un UTXO verrouillé par une adresse de script : le script exécuté est celui dont le hash forme l’adresse.
• Frappe d’un jeton : le script exécuté est celui dont le hachage forme l’ID de politique du jeton en cours de frappe.
• Retrait de récompense : le script qui est exécuté est celui dont le hachage forme l’adresse de jalonnement.
• Application d’un certificat : le script exécuté est celui dont le hash forme les informations d’identification de l’auteur du certificat.

En plus de faire savoir au nœud quel script exécuter, toutes les actions de transaction indiquent comment assembler les arguments passés à ce script. Alonzo introduit une nouvelle approche de la validation des transactions sur Cardano grâce à la mise en œuvre des scripts Plutus.

Mises à jour du grand livre

Alonzo a modifié les données du grand livre comme suit :

1. Les scripts Plutus peuvent verrouiller les UTXO.
2. Un nouveau composant, ajouté au contenu des parties de sortie des UTXO, active la fonctionnalité de type état de script. En plus des actifs et d’une adresse, un UTXO verrouillé par des scripts Plutus contient également une donnée. Une donnée est une donnée qui peut être considérée comme une interprétation de l’état du script.
3. Il existe un certain nombre de nouveaux paramètres de protocole utilisés pour imposer des exigences de validation supplémentaires aux transactions. Celles-ci incluent les limites supérieures des ressources de calcul que les scripts peuvent consommer.

Pour prendre en charge les scripts Plutus, les transactions ont été mises à niveau comme suit :

1. Pour chacune de ses actions, la transaction porte désormais un argument spécifié par l’utilisateur, appelé rédempteur. Selon le script, un rédempteur peut servir un objectif différent. Par exemple, il peut agir comme l’enchère que l’utilisateur place dans une vente aux enchères, ou la supposition de l’utilisateur dans un jeu de devinettes, parmi de nombreuses autres fonctions.
2. La transaction spécifie les budgets d’exécution de calcul pour chaque script.
3. Pour s’assurer qu’une transaction peut payer ses frais d’exécution, Alonzo introduit une garantie.
4. Les transactions contiennent un hachage d’intégrité, nécessaire pour s’assurer qu’il n’a pas été compromis, obsolète, etc.

Avec la mise à niveau de Vasil, les scripts Plutus ont été mis à niveau vers la fonctionnalité V2 avec un modèle de coût amélioré et de nouveaux éléments intégrés. L’utilisation d’entrées de référence, de données en ligne et de scripts de référence permet un débit efficace et des performances considérablement accrues.

Le nœud effectue de nouvelles vérifications qui garantissent que la transaction est construite correctement. Par exemple, il ne doit pas dépasser le budget maximal des ressources d’exécution. Il appelle également l’interpréteur de script Plutus pour exécuter les scripts.

Le modèle de gaz non déterministe peut facturer aux utilisateurs des frais imprévisibles. Dans les scripts Cardano, cette source d’indéterminisme est traitée en exigeant que le budget des ressources lui-même, ainsi que les frais nécessaires pour couvrir ce budget, soient inclus dans la transaction. L’exécution du script renvoie nécessairement True ou False et ne bouclera pas indéfiniment. La raison en est que chaque opération effectuée par un script utilise une quantité non nulle de ressources, qui sont suivies par l’interpréteur. Si le budget spécifié par la transaction est dépassé, l’exécution du script se termine et renvoie False .

Les points clés suivants rendent prévisibles les résultats de la validation des scripts et des transactions :

• l’interpréteur de script se terminera toujours et renverra le même résultat de validation lorsqu’il est appliqué aux mêmes arguments.
• une transaction fixe nécessairement tous les arguments qui seront passés à l’interpréteur de script lors de la validation.
• une transaction spécifie toutes les actions qu’elle entreprend et qui nécessitent une validation de script.
• les signatures obligatoires sur une transaction garantissent qu’elle ne peut pas être modifiée par un adversaire d’une manière qui entraînerait l’échec des scripts.
• l’application d’une transaction dans le modèle de registre EUTXO est déterministe.

L’échec ou le succès de la validation du script affecte le traitement d’une transaction. Cependant, le résultat Vrai ou Faux , ainsi que les modifications de grand livre associées à l’un ou l’autre des résultats, sont prévisibles pour une transaction donnée.

(7) Meilleures pratiques en matière de contrats intelligents

Voici quelques bonnes pratiques générales que vous devriez suivre lors du développement de contrats intelligents avec Plutus.

Connaître l’objectif de votre contrat intelligent

Sachez exactement ce que votre contrat intelligent doit faire et testez-le pour vous assurer qu’il remplit l’objectif attendu.

Vérifiez s’il existe des contrats similaires antérieurs

Existe-t-il déjà un contrat qui fait la même chose ? Si oui, qu’est-ce qui est différent dans votre contrat intelligent ?

Nommage

Choisissez un nom clair et significatif pour votre contrat intelligent. Soyez bref et simple, et essayez d’utiliser le nom pour exprimer ce que fait le contrat.

Revue de code par les pairs

Les avantages de la revue de code sont bien connus ; le code révisé conduit à une cohérence dans l’ensemble du projet, sans défaut et à un code optimisé pour les performances. La connaissance du code est partagée entre les développeurs, ce qui réduit le temps et les coûts de maintenance à l’avenir. Pour les contrats intelligents, l’exactitude est absolument cruciale.

Test sur un testnet

Vous devez toujours tester vos contrats intelligents sur un environnement testnet avant de les exécuter sur le réseau principal. Écrivez autant de scénarios de test que possible et exécutez plusieurs itérations de vos tests.

Documentation des scénarios de test

Conservez une liste des scénarios de test que vous exécutez afin de les avoir à des fins de référence et de vérification.

Envisagez la vérification formelle

Le sujet de la vérification formelle est trop vaste pour être traité de manière adéquate ici. Vous pouvez supposer que votre code s’exécutera dans un environnement hostile où des acteurs hautement qualifiés, disposant de ressources suffisantes et sans scrupules attendront pour se précipiter sur toute vulnérabilité.

Source : https://docs.cardano.org/plutus/learn-about-plutus/