Cardano Testnets | Partie 1

[Uptodate_Developers]

(1) Vue d’ensemble

Les réseaux de test Cardano sont à l’avant-garde du développement du réseau, fournissant des environnements en bac à sable pour une innovation continue, exploitant la puissance de la communauté Cardano pour itérer et s’améliorer.

Les opérateurs de pools de participations, les échanges, les développeurs de contrats intelligents et les projets peuvent s’engager avec différents réseaux de démarrage et de pré-production pour tester activement les fonctionnalités de base de Cardano avant de les déployer sur le réseau principal.

(2) A propos

Présentation de Vasil

Vasil applique la prochaine mise à jour majeure du protocole Cardano en utilisant l’approche HFC (hard fork combinator) de Cardano. Cette mise à niveau porte le nom d’un membre de la communauté Cardano très aimé et respecté, Vasil St Dabov.

Vasil apporte des modifications qui améliorent la gestion des scripts en chaîne (Plutus), réduisant les coûts d’utilisation et permettant un plus grand débit de script. Les modifications de Vasil constituent les premières étapes d’une série d’améliorations planifiées qui seront déployées au fil du temps.

Plus précisément, cette mise à niveau introduit :

• Canalisation de diffusion
• Plutus V2 (un interpréteur optimisé et un nouveau modèle de coût)
• Nouveaux éléments intégrés Plutus
• Entrées de référence Plutus
• Références en ligne Plutus
• Scripts de référence Plutus
• Adresse de changement de garantie
• Changements concernant les acheteurs de transactions
• Mise en œuvre VRF unique

Pour commencer, assurez-vous de :

• mettre à niveau vos fichiers de configuration, de topologie et de genèse de nœud
• consultez le didacticiel “Mise en route”
• voir les tutoriels Vasil testnet
• voir des exemples de script Babbage

Notez également que :

• Avec le hard fork Vasil sur le réseau principal, le paramètre d est supprimé et la production de blocs est désormais entièrement décentralisée. Cela empêche la re-fédération.
• Si vous êtes un SPO, vous devez maintenant créer votre certificat opérationnel à l’aide de cold.counter +1. L’OpCert doit être exactement un de plus que celui utilisé précédemment.
• La formule minUTxO est maintenant calculée en utilisant les octets d’origine au lieu de lovelacePerUTxOWord.

Aperçu des fonctionnalités de Vasil

• Canalisation de diffusion

Le pipeline de diffusion est une fonctionnalité qui améliore les temps de propagation des blocs et conduit en outre à un débit plus élevé. Essentiellement, il rationalise le processus de partage d’informations sur les blocs nouvellement créés entre les participants au réseau. L’objectif de cette mise à niveau est de garantir que les blocs peuvent être partagés (propagés) sur le réseau dans les cinq secondes suivant leur création. Pour cela, le pipelining de diffusion propage les blocs avant leur validation complète chevauchant ainsi le temps passé à la diffusion avec le temps nécessaire à la validation.

Le pipelining garantit également que l’en-tête de bloc faisant référence au hachage d’un bloc précédent est propagé correctement. Le corps du bloc est conservé dans les métadonnées incluses dans le bloc suivant, ce qui est essentiel pour la résistance aux attaques DDoS même sans confirmation complète du bloc.

Le pipeline de diffusion offre plus d’espace pour l’augmentation de la taille des blocs et les améliorations du script Plutus, ce qui conduit à un paramètre global plus évolutif.

• Changements de Plutus Core

Plutus Core est un langage de script utilisé dans le registre Cardano. Il se compose de constructions de base du langage de base et comprend également des types intégrés (entiers, chaînes, etc.) et des fonctions intégrées (ajout d’entiers, etc.) qui fournissent des fonctionnalités qui seraient difficiles ou coûteuses à implémenter dans le code Plutus Core. Les fonctions intégrées fonctionnent principalement sur des types intégrés. Les types intégrés sont fournis avec une métrique de taille utilisée par les fonctions d’évaluation des coûts. Par exemple, la métrique de taille pour les entiers renvoie la taille en bits de l’entier.

Les performances des scripts Plutus Core sont liées au coût d’exécution d’un script dans le grand livre. Le modèle de coût décrit les frais de CPU et de mémoire pour chaque primitive de langage et peut être utilisé hors chaîne pour prédire les frais d’exécution de tels scripts.

Les performances du modèle sont calculées en calculant le coût de l’évaluation en unités de ressources abstraites (exunits) de CPU et de mémoire. Les étapes individuelles de l’évaluation sont chiffrées et les fonctions intégrées doivent également être accompagnées d’une fonction d’évaluation qui leur fournit des informations sur les coûts. La fonction de coût d’une fonction intégrée est une fonction mathématique qui prend les tailles des arguments (telles que calculées par leurs métriques de taille) et renvoie une estimation du budget qui sera utilisé pour exécuter cette fonction.

Par exemple, la fonction de coût pour l’addition indique que les coûts CPU et mémoire sont tous deux proportionnels au maximum des tailles des entiers d’entrée (avec quelques constantes appropriées). La détermination des fonctions de coût se fait de manière empirique en exécutant la fonction en question sur un grand nombre d’entrées et en choisissant une fonction de coût qui correspond bien aux données.

• Scripts dans le registre Cardano

Le grand livre Cardano reconnaît différents types de scripts qui sont identifiés par la version “langue”. Cette balise de langue permet au grand livre de faire la distinction entre différents types de scripts. Lorsqu’un nouveau comportement ou une nouvelle fonctionnalité est introduit, un nouveau langage l’est également. Chaque nouvelle version de Plutus aura sa propre langue, et toutes les versions linguistiques de Plutus Core sont prises en charge pour toujours dans le grand livre. Cela permet de valider indéfiniment l’historique de la chaîne.

Une partie de la spécification d’un langage dans le grand livre explique comment les scripts de langage s’exécutent, quels arguments leur sont donnés et comment ces arguments sont structurés. Les langages ont également un sous-ensemble associé de paramètres de protocole Cardano qui contrôlent certains aspects de l’évaluation du script. Pour Plutus, il s’agit du modèle de coût associé à chaque nouvelle version linguistique

• Améliorations de la vitesse de l’évaluateur Plutus

En raison des améliorations de performances dans l’évaluateur Plutus, les scripts Plutus V1 et Plutus V2 ont des paramètres de modèle de coût inférieurs à ceux d’avant, ce qui entraîne des améliorations de 20 à 30 % dans l’utilisation des ressources de script.

• Paramètres du modèle de coût mis à jour

Les paramètres du modèle de coût mis à jour incluent les modifications suivantes :

1. Étendez l’ensemble des fonctions intégrées en ajoutant le nouveau “serialiseData” intégré.
2. La fonction intégrée “verifySignature” a été renommée “verifyEd25519Signature” pour clarifier sa fonction.
3. Recalibrez le modèle de coût pour la version de l’évaluateur dans le nœud afin de l’aligner sur les modifications des paramètres de la CPU.

• Nouveau Plutus Core intégré

Les types intégrés et les opérateurs de type restent inchangés depuis la version d’Alonzo. Toutes les nouvelles fonctions intégrées sont rétrocompatibles. Leur ajout ne casse pas les anciens validateurs de script. La version Vasil continue de prendre en charge les fonctions intégrées d’Alonzo et ajoute la nouvelle fonction suivante :

serialiseData

Un nouvel intégré Plutus est ajouté pour sérialiser BuiltinData en BuiltinByteString. La fonction serialiseData prend un objet de données et le convertit en un objet CBOR.

Plutus fournit déjà une structure de données de hachage intégrée, par exemple, sha2_256 :: BuiltinByteString -> BuiltinByteString, il ne fournit pas de moyens génériques de sérialiser certains types de données en BuiltinByteString.

Les coûts globaux de mémoire et de CPU sont réduits en ayant un nouveau intégré pour sérialiser n’importe quel Plutus ‘BuiltinData’ en ‘BuiltinByteString’ de sorte que les validateurs peuvent tirer parti d’implémentations plus optimisées et de constructeurs de chaînes d’octets via des intégrés que ce qui est disponible sur la chaîne.

• Adresses de script Plutus

Un script Plutus V2 n’aura pas la même valeur de hachage qu’un script Plutus V1.

Étant donné que les scripts doivent correspondre exactement à leurs hachages en chaîne, il est important que les scripts utilisés par une application ne changent pas accidentellement. Par exemple, la modification du code source ou la mise à jour des dépendances ou des outils peut entraîner de petits changements dans le script. En conséquence, le hachage va changer. Dans les cas où les hachages doivent correspondre exactement, même les changements qui n’altèrent pas la fonctionnalité du script peuvent être problématiques.

À la lumière de cette considération, certains développeurs DApp peuvent s’attendre à ce que lors d’une migration de scripts Plutus V1 vers des scripts Plutus V2, le même code source, une fois recompilé, génère la même valeur de hachage de cette adresse de script. Cependant, il est impossible pour un script V2 compilé d’avoir le même hachage et la même adresse qu’un script V1 compilé.

L’utilisation exacte du même script avec différentes versions linguistiques entraînera des hachages différents. Le même script (comme dans UPLC.Program) peut être utilisé comme script Plutus V1 ou Plutus V2, et puisque la version linguistique fait partie du hachage, les deux hachages seront différents.

• Un script Plutus V1 n’aura pas nécessairement la même valeur de hachage lorsqu’il sera recompilé avec une version ultérieure du compilateur Plutus

Supposons que vous écriviez votre code source Haskell (Plutus Tx), que vous le compiliez en code Plutus Core (PLC), que vous génériez sa valeur de hachage, puis que vous l’utilisiez dans une transaction. Si vous n’enregistrez pas votre code compilé, puis décidez d’utiliser le même script à l’avenir, vous devrez le recompiler. Cela pourrait entraîner une valeur de hachage différente de l’adresse du script même sans mise à niveau des scripts Plutus V1 vers Plutus V2. En effet, le hachage est calculé en fonction de la sortie du code compilé.

Compte tenu des changements de version du compilateur Plutus, des changements dans les dépendances et de plusieurs autres améliorations, il est prévu que la valeur de hachage de l’adresse du script change après la recompilation du code source.

• Quand exporter et enregistrer la sortie d’un script compilé

Une fois que vous vous attendez à ne pas modifier la partie en chaîne de votre application et que vous ne voulez pas que la valeur de hachage de votre adresse de script change, la meilleure façon de la conserver est de sauvegarder la sortie de votre Plutus compilé final. Code de base (PLC) dans un fichier.

• Entrées de référence (CIP-31)

Les sorties de transaction portent des données, qui permettent d’accéder aux informations sur la blockchain. Cependant, ces données sont contraintes de plusieurs façons. Par exemple, pour accéder aux informations dans le datum, vous devez dépenser la sortie à laquelle le datum est attaché. Cela nécessite la recréation d’une sortie épuisée. Tout utilisateur qui souhaite consulter les données ne peut pas dépenser l’ancienne sortie (qui a disparu), mais doit dépenser la nouvelle sortie (dont il ne saura rien avant le bloc suivant). En pratique, cela limite certaines applications à une « opération » par bloc, diminuant ainsi les performances souhaitées.

CIP-31 introduit un nouveau mécanisme d’accès aux informations dans les données - une entrée de référence. Les entrées de référence permettent de regarder une sortie sans la dépenser. Cela facilitera l’accès aux informations stockées sur la blockchain sans qu’il soit nécessaire de dépenser et de recréer les sorties de transaction non dépensées (UTXO).

Le cas d’utilisation clé de CIP-31 est de prendre en charge les scripts de référence (CIP-33). D’autres cas d’utilisation incluent :

1. Inspecter l’état (donnée ou valeur verrouillée) d’une application en chaîne sans avoir à consommer la sortie. Par exemple, vérifier l’état actuel d’une machine à états stablecoin.
2. La possibilité de référencer des fournisseurs de données en chaîne qui stockent des données dans les sorties d’autres scripts.

• Systèmes de référence en ligne (CIP-32)

Les données transportant des informations de transaction sont généralement mises en œuvre en attachant des hachages de données aux sorties. C’est assez gênant pour les utilisateurs. Les données ont tendance à représenter le résultat du calcul effectué par la partie qui crée la sortie, et en tant que tel, il n’y a presque aucune chance que la partie dépensière connaisse la donnée sans communiquer avec la partie créatrice. Cela signifie que soit la donnée doit être communiquée entre les parties hors chaîne, soit en chaîne en l’incluant dans la carte des témoins de la transaction qui crée la sortie (“données supplémentaires”). Un tel cas oblige le dépensier à surveiller toute la chaîne pour trouver la donnée, ce qui est également gênant.

CIP-32 suggère une solution qui permet aux données elles-mêmes d’être attachées aux sorties au lieu des hachages de données. Cela permettra une communication beaucoup plus simple des valeurs de référence entre les utilisateurs.

Les cas d’utilisation incluent :

• Créer un seul UTXO avec des données à utiliser dans plusieurs transactions ultérieures, mais ne payer qu’une seule fois le coût pour le soumettre.

• Stocker peu d’informations sur la chaîne. Par exemple, les oracles peuvent en bénéficier en ajoutant simplement des données hors chaîne à la chaîne principale.

• Scénarios de référence (CIP-33)

Lorsque vous dépensez une sortie verrouillée avec un script Plutus, vous devez inclure le script dans la transaction de dépense. Par conséquent, la taille des scripts contribue à la taille de la transaction, qui influence directement le débit de Cardano.

Les grandes tailles de script posent des problèmes aux utilisateurs car :

• Les transactions plus importantes entraînent des frais plus élevés.
• Les transactions ont des limites de taille. Les gros scripts peuvent atteindre les limites. Même si un script convient, plusieurs scripts dans une transaction peuvent ne pas convenir. Cela rend difficile l’exécution de transactions complexes qui reposent sur plusieurs scripts.

CIP-33 introduit la possibilité de référencer un script sans l’inclure dans chaque transaction. Cela réduit considérablement la contribution des scripts à la taille de la transaction.

• Rachats de transactions

Deux éléments importants dans Plutus sont les données et les rédempteurs. La donnée est une information qui peut être associée à un UTXO et est utilisée pour transporter des informations d’état de script. Il est fréquemment utilisé en combinaison avec un rédempteur, qui est comme une instruction ou une commande au contrat.

Avec le hard fork Vasil, les développeurs pourront voir les rédempteurs pour toutes les entrées plutôt que seulement celle transmise au script en cours d’exécution.

• Adresse de changement de garantie

La garantie de script est la garantie monétaire qu’un utilisateur donne pour s’assurer que la transaction qui utilise un contrat a été soigneusement construite et testée de manière approfondie avant d’être soumise aux validateurs. Il est utilisé pour garantir que les nœuds sont indemnisés pour leur travail en cas d’échec de la validation de phase 2. Le montant de la garantie est spécifié au moment de la construction de la transaction et est réservé pour permettre l’exécution du script en chaîne.

Actuellement, sur le réseau principal de Cardano, le montant de la garantie est fixé à 150 % des frais de transaction, et aucun changement n’est apporté à la garantie UTXO. Cela signifie que si un script échoue à la validation de phase 2, l’utilisateur DApp perdra tous les fonds stockés dans l’UTXO choisi pour la garantie.

Avec le hard fork Vasil, les développeurs DApp auront 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.

• Mise en œuvre VRF unique

Sur Cardano, la fonction aléatoire vérifiable (VRF) détermine quel SPO crée le bloc suivant. Avant Vasil, il y avait deux fonctions VFR exécutées sur chaque saut de réseau pour valider un bloc. Avec le hard fork Vasil, l’une de ces fonctions est abandonnée, ce qui accélère la validation des blocs et les temps de synchronisation réseau globaux.

Mise à niveau de Valentine (SECP)

La mise à niveau de Valentine (ou SECP) est le hard fork intra-ère de Cardano qui suit la mise à niveau de Vasil. Valentine est une petite modification sémantique ciblée du grand livre, qui apporte de nouvelles fonctions intégrées à Plutus pour prendre en charge les courbes elliptiques SECP (ECDSA et Schnorr). Bien qu’un hard fork intra-ère nécessite un événement de combinateur de hard fork, cela ne change pas l’ère du grand livre, ce qui signifie qu’il s’agit d’une mise à niveau vers l’ère Babbage (fonctionnalité Vasil).

• À propos du CEC

ECC est une primitive populaire pour le développement de protocoles cryptographiques et d’applications sécurisées utilisant des algorithmes de chiffrement et de déchiffrement personnalisés validés par des signatures numériques. ECC offre le même niveau de sécurité que les autres mécanismes tout en utilisant des clés et des signatures plus courtes.

Il existe différentes courbes elliptiques que l’on peut utiliser, avec secp256k1 comme l’une des options. Chacune de ces courbes diffère dans ses paramètres. La courbe secp256k1 fournit deux schémas de signature communs - ECDSA et Schnorr.

Cardano utilise l’algorithme de signature numérique à courbe d’Edwards (EdDSA) avec la courbe elliptique Curve25519 comme courbe de base (Ed25519). Ed25519 est conçu pour résister à certains types d’attaques cryptographiques, ce qui en fait un choix sûr.

Ed25519 fait partie de la famille des safeCurves, dont secp256k1 ne fait pas partie. La variance des algorithmes signifie que les développeurs de Plutus DApp qui souhaitent travailler avec d’autres blockchains et doivent valider les signatures ECDSA et Schnorr devraient consacrer du temps, des efforts et des fonds pour mettre en œuvre de tels algorithmes sur les courbes elliptiques Standards for Efficient Cryptography (SECP) dans Plutus. Cette implémentation supplémentaire augmente considérablement les risques de sécurité potentiels.

Étant donné que seul l’algorithme de signature principal de Cardano, Ed25519, est fourni en tant que fonction intégrée Plutus, les opérations ECDSA et Schnorr seraient plus coûteuses et plus longues à moins qu’elles ne soient également fournies en tant que fonctions intégrées.

Qu’apporte la mise à jour SECP ?

La mise à niveau Valentine de Cardano ajoute de nouvelles fonctions intégrées à Plutus pour prendre en charge les signatures ECDSA et Schnorr ainsi que la signature native de Cardano.

Ces fonctions intégrées deviendront natives de Cardano, et puisqu’elles seront implémentées et auditées par des experts, elles offriront le plus haut niveau de sécurité. Cette normalisation permettra à tout développeur Plutus DApp d’élargir le choix de conception de signature multi-signature ou de seuil à utiliser.

CIP-49 fournit une surveillance plus approfondie de la motivation et des spécifications pour la nouvelle implémentation des fonctions intégrées.

Après la mise en œuvre des nouvelles primitives cryptographiques, Plutus pourra facilement vérifier les transactions d’autres blockchains en utilisant les normes ECDSA et Schnorr. Par exemple, Plutus pourra vérifier nativement les signatures générées dans les sidechains EVM, ce qui améliorera l’expérience des développeurs en termes de simplicité de processus, de coût et de sécurité avancée.

Source : https://docs.cardano.org/cardano-testnet/overview