Un guide complet sur la sécurité de Marlowe : résultats d’audit, restrictions fonctionnelles intégrées et fonctionnalités de sécurité du grand livre.
Avis de non-responsabilité : le contenu de cet article de Marlowe Security est fourni « TEL QUEL » sans aucune garantie d’aucune sorte. Rien dans ce document n’est destiné à constituer un conseil professionnel, y compris, sans s’y limiter, des conseils financiers, d’investissement, juridiques ou fiscaux. Input Output Global n’est pas responsable de votre utilisation ou de la confiance accordée aux informations contenues dans ce document.
Introduction
Dans la plupart des blockchains, un contrat intelligent est un programme informatique qui s’auto-exécute une fois certaines conditions prédéfinies remplies. Dans Cardano, c’est un peu différent, car l’exécution d’un contrat intelligent se produit dans une transaction soumise en externe au nœud Cardano. Mais quelle que soit la manière dont ils fonctionnent sous le capot, les contrats intelligents sont utiles dans de nombreux secteurs : financier, immobilier, commerce et bien d’autres.
Les transactions utilisant des contrats intelligents peuvent impliquer le mouvement et le transfert d’une valeur substantielle, ce qui peut constituer une cible privilégiée pour les mauvais acteurs. De même, cette valeur peut être verrouillée, voire complètement perdue, en raison de défauts ou de vulnérabilités dans le codage.
Éviter tout résultat indésirable nécessite la mise en œuvre d’un cadre de sécurité robuste, qui implique une combinaison de principes de conception, d’audits et de meilleures pratiques de la part des développeurs, des bourses et de toute autre partie gérant les contrats intelligents.
S’ajoutant à une gamme toujours croissante de ressources provenant de la communauté technique de Cardano, Marlowe est un écosystème d’outils et de langages créés par Input Output Global (IOG) pour permettre le développement de contrats intelligents financiers et transactionnels sur la blockchain Cardano.
La suite Marlowe a été conçue et développée en mettant l’accent sur la sécurité. Les créateurs de Marlowe ont intégré des limitations fonctionnelles qui garantissent que les contrats sont limités et prennent toujours fin, par exemple. Marlowe évite également certaines constructions de programmation pour éviter des résultats indésirables, par exemple la récursivité et les boucles. Un tiers, Tweag , a effectué un audit statique et dynamique avant le déploiement de Marlowe sur le réseau principal. Le résultat de toutes ces fonctionnalités de sécurité, et bien d’autres, est une plateforme de création et de développement de contrats intelligents sûre et sécurisée.
Cet article se penche sur la sécurité de Marlowe, expliquant les résultats de l’audit de sécurité et la manière dont l’équipe y a répondu , les limitations fonctionnelles intégrées, les outils d’analyse de sécurité inclus dans le déploiement, ainsi que certaines précautions et considérations à prendre lors de l’utilisation de Marlowe.
Structure de ce document
Ce document est divisé en six sections clairement définies :
- Audit de contrats intelligents
- Attaques basées sur des contrats intelligents
- Audit Tweag
- Limitations fonctionnelles intégrées améliorant la sécurité dans Marlowe
- Validation des transactions
- Politiques monétaires
Dans son ensemble, ce document vise à fournir une compréhension globale de l’importance de l’audit des contrats intelligents et des différents types d’attaques basées sur les contrats intelligents qui existent aujourd’hui, avant d’approfondir spécifiquement la façon dont la suite d’outils Marlowe utilise l’audit et des principes de sécurité solides pour maintenir un environnement de développement de contrats intelligents sûr et sécurisé.
Audit de contrats intelligents
Aperçu
L’autonomie inhérente aux contrats intelligents et les enjeux relativement élevés impliqués dans certaines transactions signifient qu’il est primordial d’assurer la cohérence et la sécurité. Cela nécessite de savoir exactement comment un contrat intelligent se comportera lors de son exécution afin que toute faille potentielle ou code malveillant intentionnel puisse être détecté et traité. L’audit des contrats intelligents du point de vue de la sécurité est le meilleur moyen de prévenir des pannes ou des dommages ultérieurs. Un audit examine minutieusement le code et les conditions du contrat intelligent avant le déploiement, pour garantir que le contrat se comporte comme prévu.
Méthodes d’audit
Bien que les approches d’audit des contrats intelligents puissent différer et varier d’un projet à l’autre, les contrats intelligents peuvent être analysés à l’aide de méthodes manuelles ou automatisées. Habituellement, la plupart des projets utilisent une combinaison des deux.
Collecte de documentation
Avant le début du processus d’audit, les auditeurs peuvent consacrer un certain temps à rassembler toute la documentation relative au projet. Cela peut inclure des documents techniques, des livres blancs, une base de code et tout autre matériel pouvant être pertinent et utile dans le processus d’audit.
Audit manuel
Cette forme d’audit de contrat intelligent implique un groupe de personnes analysant chaque ligne de code, la logique du contrat, l’architecture du contrat et toutes les mesures de sécurité intégrées pour garantir une conception efficace et correcte. En plus de révéler des erreurs de codage, un audit manuel peut également découvrir des défauts de conception. L’audit manuel a tendance à être considéré comme une méthode très approfondie et précise.
Audit automatisé
Contrairement à l’audit manuel, l’audit automatisé adopte normalement une approche de test centrée sur le logiciel. Des outils d’audit logiciels propriétaires ou disponibles dans le commerce peuvent aider à détecter les bogues, mais certaines vulnérabilités peuvent ne pas devenir apparentes.
En raison de la nature complémentaire de ces méthodes, les meilleures pratiques d’audit impliquent une combinaison d’audit manuel et automatisé pour garantir que tous les défauts, bugs et vulnérabilités potentiels sont détectés et corrigés.
Actions post-audit
Une fois le processus d’audit terminé, le ou les auditeurs produiront un rapport détaillant leurs conclusions. Celles-ci peuvent inclure une classification des erreurs par gravité et une série de recommandations.
Les erreurs contractuelles peuvent être classées comme suit :
- Critique : ce type de faille empêchera probablement le bon fonctionnement d’un contrat et/ou d’un protocole.
- Majeure : certaines erreurs de codage ou de logique peuvent entraîner une perte de fonds, ou un état du protocole incontrôlé.
- Moyen : même si les fonds ne sont pas menacés, ces types d’erreurs peuvent affecter la performance ou la fiabilité du contrat.
- Mineur : cette classification inclut généralement du code inefficace ayant peu ou pas d’impact sur la sécurité. Informatif : fait généralement référence à des problèmes de style de codage ou de meilleures pratiques.
Avantages de l’audit des contrats intelligents
Bien que l’audit soit important pour toute application, il est particulièrement crucial pour les contrats intelligents et les applications décentralisées (DApps) fonctionnant sur blockchain en raison de la nature immuable de ces registres décentralisés.
Les avantages de l’audit des contrats intelligents incluent l’identification proactive des risques, l’évitement d’erreurs potentiellement coûteuses, un meilleur environnement de développement global et l’obtention d’informations sur les vulnérabilités et sur la manière de les éliminer.
Identification proactive des risques
Le déploiement de contrats intelligents non audités est un pari qu’aucun développeur ou entreprise ne devrait jamais prendre. Certains contrats intelligents peuvent impliquer des fonds importants qui, s’ils sont perdus ou compromis, peuvent entraîner des responsabilités encore plus importantes. En travaillant de manière proactive pour remédier à ces risques, la possibilité que quelque chose tourne mal est considérablement réduite.
Évitement d’erreurs potentiellement coûteuses
Les fonds bloqués à jamais en raison d’erreurs de codage/de logique ou d’interférence malveillante dans un contrat sont quelque chose qu’aucun client ou développeur ne souhaite expérimenter. La perte financière n’est qu’un aspect du problème. Il peut également y avoir de graves conséquences juridiques.
Un meilleur environnement de développement dans l’ensemble
Un logiciel d’audit n’est pas seulement recommandé, c’est une exigence. Garantir la sécurité d’une application ou d’une suite d’applications et suivre les bonnes pratiques renforce l’offre et crée un environnement de développement plus sain.
Obtention d’informations sur les vulnérabilités et comment les éliminer
Dans le développement de logiciels, mieux vaut prévenir que corriger. Et lorsqu’il s’agit de contrats intelligents, il n’y a aucune chance d’apporter des correctifs en raison de la nature immuable de la blockchain. Un audit approfondi fournira de nombreuses informations sur le code, la logique du contrat, l’architecture et de nombreux autres paramètres, permettant aux développeurs d’affiner et de produire le meilleur contrat possible.
Attaques basées sur des contrats intelligents
Attaques de réentrée
Dans cette attaque, une fonction de contrat intelligent abandonne temporairement le contrôle d’une transaction en appelant un deuxième contrat, qui commence à effectuer des appels de retrait récursifs vers le premier contrat, drainant ainsi ses fonds avant que le premier contrat ne mette à jour son état. Ces types d’attaques deviennent possibles en raison de bugs dans le codage des contrats intelligents. L’ événement DAO 2016 impliquait une attaque de réentrée.
La conception de la blockchain Cardano rend impossible les attaques de réentrée. Parce que Cardano utilise le modèle EUTXO , les contrats intelligents sont atomiques et ne s’appellent pas entre eux, ce qui rend la réentrée impossible.
Des invasions de premier plan
Certaines conceptions de blockchain permettent aux contrats et transactions intelligents d’être visibles publiquement pendant un certain temps, avant d’être confirmés en chaîne. Ces transactions en attente sont partagées dans les pools de mémoire du réseau, ce qui permet à un adversaire de voir le résultat attendu d’un contrat. Un tel adversaire ayant une visibilité sur les transactions en attente peut introduire une nouvelle transaction ou une nouvelle transaction en sachant que cela générera un profit basé sur la transaction en cours, aux dépens des bénéfices des autres utilisateurs. Essentiellement, un adversaire manipule l’ordre d’exécution des transactions à son propre avantage.
Bien que ce type d’événement constitue un problème majeur sur d’autres blockchains, rien ne prouve que Cardano (et par extension, Marlowe) serait vulnérable à des invasions de premier plan.
Manipulation des oracles
Les oracles connectent les blockchains aux systèmes externes et les contrats intelligents peuvent s’exécuter sur la base des données reçues des oracles. Cette fiabilité vis-à-vis des systèmes externes signifie que si les entrées reçues par l’oracle ont été manipulées avant d’être transmises à l’oracle, la sécurité et l’intégrité de l’exécution du contrat intelligent pourraient être compromises.
D’autres vulnérabilités de sécurité courantes basées sur les contrats intelligents incluent les erreurs arithmétiques, les dépassements et dépassements d’entiers, les paramètres de visibilité des contrats intelligents et la manipulation de l’horodatage.
L’audit Tweag
Cette section se concentre sur les résultats de l’audit de sécurité de Tweag, la réponse de l’équipe de Marlowe et les principes de sécurité intégrés dans la conception de Marlowe.
Principales conclusions de l’audit de sécurité de Tweag et réponses internes
Tweag a réalisé un audit manuel et automatisé du langage Marlowe, qui a révélé plusieurs problèmes.
Les résultats de haute gravité comprenaient le traitement des dépôts négatifs, la prévention de la « double satisfaction », l’application d’invariants d’état, une différence de mise en œuvre entre la spécification formelle et la mise en œuvre de Plutus, et la preuve du théorème de préservation de l’argent.
Traitement des dépôts négatifs
Les revenus des dépôts sont calculés en additionnant les entrées de dépôt, qu’elles soient négatives ou non, tandis que la sémantique les considère comme des dépôts nuls. Combiné à l’absence de vérification du solde sur l’état final de Marlowe, cela permet au solde final de différer de la valeur payée au validateur Marlowe. Cela pourrait être exploité par un contrat Marlowe autorisant les dépôts négatifs.
Réponse interne
Ce problème a été résolu en ajoutant une protection contre les dépôts négatifs dans le validateur sémantique Marlowe. Cette garde garantit que la sémantique du validateur pour les dépôts négatifs correspond à la sémantique Isabelle de Marlowe. Plus précisément, un dépôt d’une quantité négative est traité comme un dépôt de zéro. Ainsi, un dépôt négatif ne diminuera aucun des soldes de compte dans la donnée Plutus, et le total des soldes internes fera correspondre la valeur détenue dans l’UTXO à l’adresse du script sémantique de Marlowe.
Prévention de la double satisfaction
Bien que le validateur Marlowe ait empêché la double satisfaction entre plusieurs copies du script du validateur Marlowe exécuté dans la même transaction, il ne l’a pas empêché dans les cas où le validateur Marlowe s’exécutait aux côtés d’un autre validateur Plutus dans la même transaction.
Réponse interne
La double satisfaction est désormais évitée en faisant en sorte que le validateur Marlowe soit le seul script Plutus qui s’exécute lors des transactions qui effectuent des paiements aux parties. Cela permet aux contrats de Marlowe de se coordonner avec d’autres scripts de Plutus, mais uniquement dans des conditions où la double satisfaction est impossible. Certains tests basés sur les propriétés ont été ajoutés pour vérifier l’exactitude de cette atténuation.
Application des invariants d’état
A l’origine, le validateur Marlowe avait fait des hypothèses optimistes sur son propre fonctionnement correct et n’avait pas vérifié certains invariants afin de réduire les coûts d’exécution de Plutus.
Réponse interne
Le validateur sémantique de Marlowe applique désormais rigoureusement les invariants pour les états initial et final, garantissant que les trois invariants d’état des comptes positifs, la non-duplication des entrées d’état (comptes, choix et valeurs liées) et une valeur interne totale correspondent aux scripts UTXO. valeur.
Différence d’implémentation entre la spécification formelle et l’implémentation de Plutus
L’audit a révélé certaines différences entre la spécification formelle et la mise en œuvre réelle de Plutus. Plus précisément, les différences linguistiques et les considérations d’efficacité par rapport à Isabelle, Haskell et Plutus Tx.
La spécification formelle est écrite en Isabelle, un langage pour les méthodes formelles, tandis que l’implémentation réelle de Marlowe est écrite en Haskell et Plutus Tx. L’équipe Marlowe s’est efforcée de suivre au plus près la spécification Isabelle, mais certains écarts étaient inévitables en raison des différentes langues. Par exemple, certains aspects de l’implémentation de Marlowe seraient inefficaces dans Isabelle, des changements étaient donc nécessaires pour une implémentation Haskell plus efficace.
Réponse interne
Ce problème a été atténué grâce à l’analyse du code et aux tests basés sur les propriétés.
Preuve du théorème de la préservation de l’argent
Le théorème de la préservation de la monnaie ne prenait en compte que le montant des actifs mais pas leur type. Cela signifiait que la preuve ne considérerait pas le cas où un contrat pourrait, par exemple, recevoir 20 ada et 15 Djed et rembourser 20 Djed et 15 ada.
Réponse interne
Une révision du code Isabelle a remédié à ce problème. Concrètement, l’ajout d’un nouveau type MultiAssets et le refactoring du code Isabelle (sans modifier l’interpréteur) pour prouver que les actifs sont préservés.
Limitations fonctionnelles intégrées améliorant la sécurité dans Marlowe
Marlowe présente plusieurs limitations pour garantir que certains risques de sécurité ne peuvent pas survenir.
- Les contrats sont limités
- Les contrats prendront fin
- Les contrats ont une durée de vie définie
- Aucun actif n’est conservé à la clôture du contrat
- La valeur est conservée
Outre ces limitations, certaines constructions du langage de programmation sont absentes de Marlowe pour garantir la sécurité :
- La récursivité n’est pas autorisée
- La boucle n’est pas prise en charge
- Les fonctions ou macros peuvent ne pas être définies
- Les délais d’attente doivent être des constantes numériques
- Seules les suites de cas peuvent être merkleisées. Le langage de programmation Faustus assouplit certaines des limitations ci-dessus, mais il compile pour sécuriser Marlowe.
Outils d’analyse de sécurité
L’outil d’analyse conçu par l’équipe Marlowe marlowe-cli run analyzevérifie la compatibilité d’un contrat Marlowe avec les règles du grand livre Cardano.
Le grand livre Cardano comporte des restrictions intégrées qui pourraient empêcher un contrat Marlowe de s’exécuter en chaîne, même si le contrat lui-même était valide par rapport au langage Marlowe. Par exemple, le grand livre impose des restrictions sur la longueur des noms de rôles et de jetons, et limite également les coûts d’exécution de Plutus. Tout contrat violant l’une de ces règles ne fonctionnerait pas en chaîne, même si le contrat pouvait être correctement construit. De même, même si les contrats peuvent être exécutés sur Playground, ils ne seront pas exécutés en chaîne si le contrat enfreint les restrictions du grand livre. En savoir plus sur les restrictions de conception de grand livre intégrées .
À retenir : alors que Playground concerne le langage, Runtime concerne spécifiquement la mise en œuvre du contrat Marlowe sur la blockchain Cardano. Si quelqu’un implémente Marlowe sur une autre blockchain, vous pouvez toujours utiliser Playground, mais vous ne pouvez pas utiliser Runtime sur une autre blockchain.
Remarque : un contrat peut être verrouillé si la donnée ne rentre pas dans la chaîne, mais la suite Marlowe comprend des outils pour évaluer ce risque. Ces outils doivent être utilisés avant de déployer un contrat.
Validation des transactions
Deux types de scripts de validation Plutus sont impliqués dans la validation des dépenses UTXO :
- Validateur sémantique
- Validateur de paiement
Les pratiques de sécurité imposent que les transactions ne soient pas signées à moins que le contenu et les implications de la transaction n’aient été examinés et bien compris. Dans l’environnement Marlowe, cela signifie vérifier le contrat Marlowe, ses entrées et son état. Cela signifie également s’assurer que la politique de création de rôles (le cas échéant) et le validateur Marlowe utilisé sont les bons.
Les considérations de sécurité ci-dessous s’appliquent aux deux types de scripts de validation.
Validateur sémantique
Les concepts suivants doivent être bien compris avant de signer une transaction Marlowe :
- La transaction opère-t-elle un contrat Marlowe ?
- Quel est son rôle en matière de politique de frappe (le cas échéant) ?
- Comment les jetons de rôle ont-ils été distribués (le cas échéant) ?
- Quel est le contrat actuel et son état ?
- Quelle contribution est appliquée au contrat ?
- Que se passe-t-il d’autre dans la transaction ?
La transaction opère-t-elle un contrat Marlowe ?
Les scripts du validateur Plutus sont des interprètes universels pour tous les contrats Marlowe d’une version spécifiée, ce qui signifie que l’UTXO d’un contrat Marlowe réside dans un hachage de script. Vérifier qu’une transaction est dépensée à partir d’une adresse qui a le hachage du script Marlowe comme partie de paiement confirme que le véritable validateur Marlowe s’exécutera pour valider les dépenses de cet UTXO spécifique. Il est possible de calculer le hachage de script du validateur Marlowe à partir des premiers principes en compilant le validateur et en calculant son hachage, en supposant que le code source du script Marlowe dans ce référentiel est fiable.
Quel est son rôle en matière de politique de frappe (le cas échéant) ?
Une politique de frappe est l’ensemble de règles pour la création de jetons d’un type de jeton donné, qui est identifié par le hachage de leur politique de frappe. C’est ce qu’on appelle l’ID de politique de frappe. Une politique de frappe détermine si de nouveaux jetons peuvent être créés ou si les jetons créés seront les seuls qui existeront un jour.
Par exemple, les parties à un contrat Marlowe, comme le prêteur et l’emprunteur, peuvent être représentées de deux manières :
- Par une adresse : chaque partie du type adresse correspond à une instance d’un couple de clé publique et privée qui est vraisemblablement détenue par un wallet de l’une des parties. Utiliser des adresses pour représenter des parties est plus simple et moins coûteux que d’utiliser des rôles. Pour s’authentifier, les parties représentées par une adresse doivent simplement signer les transactions qui nécessitent leur authentification (c’est-à-dire celles qui exécutent des dépôts ou des choix pour la partie).
- Par un jeton de rôle : chaque partie de type rôle correspond à un jeton stocké en chaîne. Pour qu’un contrat utilise des jetons de rôle comme authentification, le contrat doit déclarer que son ID de politique de frappe de jeton de rôle est l’ID de politique de frappe du jeton qu’il souhaite utiliser comme jeton de rôle. Dans ce cas, chacun des noms d’actifs du jeton identifié par l’ID de politique de frappe représente une partie différente. Pour authentifier une transaction, il suffit au propriétaire du jeton de rôle de l’inclure dans la transaction qui nécessite l’authentification du propriétaire du jeton de rôle. Il peut potentiellement y avoir plusieurs jetons avec le même nom d’actif, vous ne possédez donc techniquement pas de partie de rôle à moins que vous ne possédiez toutes les instances du jeton de rôle qui porte le nom d’actif de la partie.
Comment les jetons de rôle ont-ils été distribués ?
Si un contrat utilise uniquement des adresses pour représenter les parties, les politiques de création de rôles ne sont pas un problème. L’inconvénient des adresses est qu’elles ne peuvent pas être transférées de manière prouvée. Ainsi, une fois que la clé privée d’une adresse est connue, vous ne pouvez pas montrer que vous l’avez oubliée et supprimée. Du point de vue du destinataire de l’adresse, l’adresse n’est toujours pas sécurisée. La seule façon d’avoir une adresse sécurisée est de la générer vous-même.
L’avantage ou le rôle est que, comme les jetons sont traités comme des actifs natifs sur la chaîne, ils peuvent être transférés comme ada ou tout autre actif. Mais toute personne possédant un jeton avec le bon identifiant de politique de frappe et le bon nom d’actif peut agir en tant que partie qu’il représente, vous devez donc vous assurer que vous êtes le seul à posséder un tel jeton, sinon vous ne contrôlez pas vraiment le faire la fête.
Vous pouvez bien sûr vous assurer que vous êtes le seul à posséder ce jeton en créant vous-même les jetons de rôle (Marlowe Runtime le fait de manière sécurisée dans le cadre du processus de création du contrat). Si quelqu’un d’autre a créé les jetons de rôle ou créé le contrat, vous devez vous assurer que :
- Vous disposez de tous les jetons existants qui contrôlent le groupe
- De tels jetons ne peuvent plus être créés (car la politique de frappe ne le permet pas)
Si la politique de frappe est assez simple, le moyen le plus simple de vérifier cela est d’utiliser un scanner Marlowe pour connaître l’ID de la politique de frappe du rôle du contrat. Ensuite, utilisez un explorateur Cardano pour vérifier quelle est la politique derrière la politique de création (pour vous assurer qu’aucun autre rôle ne peut être produit) et pour vérifier la répartition actuelle des rôles existants déjà créés (qui a quels jetons, en d’autres termes).
Quel est le contrat actuel et son état ?
L’état pré-transaction du contrat est défini dans la donnée Plutus associée à l’UTXO dépensé à partir de l’adresse du script Marlowe. Cette donnée doit être fournie dans la transaction et doit contenir les éléments suivants :
- les soldes des comptes internes au contrat
- l’historique des choix effectués jusqu’à présent dans l’exécution du contrat
- les valeurs actuelles des variables liées du contrat
- la partie du contrat qui reste à exécuter
Les données peuvent être extraites du corps de transaction non signé et désérialisées à Language.Marlowe.Core.V1.Semantics.MarloweDatal’aide de la fonction Plutus.V2.Ledger.Api.fromData.
Alternativement :
- le
marlowe log --showcontrat de l’outil de ligne de commande affichera l’historique en chaîne du contrat. - Cet outil en ligne permet également de visualiser les contrats et l’état en chaîne
- Une API REST fournit les mêmes informations obtenues via
marlowe log --show
Quelle contribution est appliquée au contrat ?
Le rédempteur Plutus associé à la dépense de l’UTXO à partir de l’adresse du script Marlowe définit l’entrée appliquée au contrat, ainsi que l’intervalle de validité du créneau pour la transaction spécifiée dans le corps de la transaction. L’entrée est une séquence de zéro ou plusieurs dépôts, choix et notifications. À l’aide d’outils comme Marlowe Playground ou marlowe-cli run prepare, il est possible d’analyser les conséquences de l’application de cette entrée au contrat.
Le rédempteur peut être extrait du corps de transaction non signé et désérialisé à l’ Language.Marlowe.Scripts.MarloweInputaide de la fonction Plutus.V2.Ledger.Api.fromData. L’outil de ligne de commande marlowe-cli util slottingcalculera la relation entre les créneaux mentionnés dans l’intervalle de validité et les heures POSIX du contrat.
Que se passe-t-il d’autre dans la transaction ?
La transaction non signée peut contenir d’autres dépenses et paiements au-delà de ceux spécifiés pour le contrat Marlowe. Cela peut être examiné avec l’outil cardano-cli transaction view.
Politiques monétaires
En règle générale, les politiques monétaires (comme celles prises en charge dans Marlowe Runtime) imposant un seul événement de frappe et des jetons uniques pour chaque rôle doivent être utilisées. Ces politiques garantissent que les jetons de rôle sont de véritables jetons non fongibles (NFT), de sorte que les détenteurs de jetons de rôle sont de manière vérifiable les seuls à pouvoir agir en tant que parties au contrat.
Les politiques monétaires qui créent plusieurs copies d’un jeton de rôle particulier, ou les politiques avec une politique de frappe ouverte, prennent en charge des cas d’utilisation non standard. Par exemple, créer deux copies de chaque jeton de rôle et les distribuer à la même partie permet à cette partie de placer un jeton dans un entrepôt frigorifique en guise de sauvegarde si le portefeuille contenant le jeton de rôle « chaud » devient inaccessible. Certains nouveaux contrats de crowdsourcing pourraient impliquer l’attribution du rôle (via des jetons de rôle identiques qui peuvent être créés même après le début du contrat) à de nombreux participants. Enfin, la politique de frappe d’un contrat Plutus pour les jetons de rôle peut se coordonner avec le fonctionnement d’un ou plusieurs contrats Marlowe.
Jetons de rôle
Les jetons de rôle peuvent autoriser les dépôts et les choix dans les transactions Marlowe. Autoriser l’utilisation d’un jeton de rôle est plus flexible que l’autoriser avec une clé publique, car un jeton de rôle (et donc la participation à un contrat Marlowe) peut être transféré entre portefeuilles ou vers quelqu’un d’autre.
Les scripts du validateur Marlowe n’appliquent aucune politique monétaire particulière pour les jetons de rôle, afin de permettre de nouveaux cas d’utilisation. Cependant, la sécurité des autorisations dans un contrat Marlowe basé sur les rôles dépend essentiellement de la politique monétaire du jeton de rôle. Cela signifie que la politique monétaire et le décaissement en chaîne des jetons doivent être soigneusement examinés avant de participer à un contrat Marlowe. Vérifier la politique monétaire d’un simple script implique de récupérer le script de la blockchain et de l’étudier. Vérifier la politique monétaire d’un script Plutus implique d’obtenir et d’étudier le code source Plutus du script et de hacher le code source pour vérifier l’ID de la politique monétaire.