(1) Gestion du temps sur Cardano
Le temps est nécessairement relatif à chaque participant au système de blockchain et est d’une importance cruciale pour soutenir et maintenir les propriétés de sécurité du protocole de consensus Ouroboros. Les blocs frappés devraient être propagés à tous les nœuds du système en temps opportun, donc le temps nécessite la construction d’une représentation globalement acceptable pour qu’un consensus soit atteint.
Gestion du temps avec Ouroboros
Localement, un nœud calcule le temps qui passe à l’aide d’un système d’horloge murale. Le code de cette horloge est compliqué car la longueur de la fente peut varier à une limite de fourche dure, de sorte que le temps doit être calculé avec soin en tenant compte de cela.
Le code effectue quatre étapes pour obtenir le currentSlot :
- Attend un certain délai correspondant soit au temps restant jusqu’au prochain créneau, soit à un délai arbitraire de 60 s si le créneau actuel est inconnu, ce qui se produit lors de la synchronisation
- Obtient l’heure système actuelle et la traduit en un numéro d’emplacement en fonction de la longueur de l’emplacement pour l’ère actuelle
- Si le nouvel emplacement est supérieur au précédent, il “coche” un nouvel emplacement actuel
- Si ce qui précède n’est pas vrai, il attend un peu plus longtemps ou signale une erreur si l’heure actuelle remonte trop loin.
Le local currentSlot est comparé à l’emplacement signalé par la pointe du registre du nœud. Si ce dernier est plus ancien, il est ignoré car cela signifie que le nœud synchronise son état avec la chaîne.
Étant donné que la longueur des slots peut changer lors d’un hard fork, le consensus ne peut convertir les slots en temps que jusqu’à un point fixe dans le futur - la «fenêtre de stabilité» - dans lequel aucun hard fork ne peut se produire. En pratique, la fenêtre de stabilité est essentielle car elle fournit une mesure du temps nécessaire pour garantir la finalité de la transaction et l’immuabilité de l’état de la chaîne. Pendant la fenêtre de stabilité, le réseau doit produire au moins k blocs, où k est le nombre de blocs après lequel la chaîne devient immuable. La fenêtre de stabilité peut prendre jusqu’à 3k/f, soit 36 heures avec les paramètres actuels, soit environ une journée.
Défis actuels
Il existe une limitation physique fondamentale à la vitesse à laquelle l’information peut voyager : la vitesse de la lumière. Cela implique que la synchronisation temporelle sur un réseau de nœuds prend du temps.
Le protocole NTP (Network Time Protocol) existe pour fournir un mécanisme de synchronisation, qui traite les limitations de temps et les différences de mesure. En revanche, NTP ne garantit pas une augmentation monotone : le temps peut parfois faire des allers-retours de quelques secondes voire des heures. Les systèmes existants fournissant des horloges exactes, précises et fiables à l’échelle mondiale sont centralisés, comme l’horloge globale fournie par Spanner, par exemple.
Actuellement, sur Cardano :
- Les paramètres du réseau sont définis de manière à ce que la granularité des intervalles de temps observables (par exemple, le temps de bloc) sur la chaîne soit de 20 s, ce qui est égal à la longueur de créneau (1 s) divisée par le coefficient de bloc f (la fréquence de bloc attendue, 0,05 ). Il est peu probable que ces paramètres changent à court terme.
- Ces 20 secondes ont été déterminées comme le budget optimal pour garantir la sécurité du protocole, compte tenu des contraintes de réplication de nouvelles transactions et de blocs sur le réseau (délai TCP de 300 ms à travers le monde, avec des milliers de nœuds). Bien que le débit de blocs puisse être augmenté à l’avenir, il est peu probable qu’il réduise la granularité du temps observable sur la chaîne.
- La finalité de la transaction peut être atteinte en environ un jour et ne peut pas se produire en moins d’un jour, selon la conception consensuelle d’Ouroboros. Notez que bien qu’un niveau de confiance élevé soit déjà atteint en quelques minutes ou heures, la probabilité qu’un bloc soit finalement rejeté diminue de façon exponentielle avec sa profondeur et le nombre de nœuds qui doivent adopter ce bloc.
Enfin, à plus long terme, le protocole Ouroboros actuel devrait être remplacé par Ouroboros Chronos. Ouroboros Chronos relève les défis du chronométrage en fournissant la première source de temps cryptographique à haute résilience basée sur la technologie blockchain.
L’importance du déterminisme dans un environnement blockchain
Dans le contexte actuel, le déterminisme signifie qu’une transaction donnée a un « effet fixe » sur l’état du grand livre. Mais il est important de distinguer les concepts de déterminisme historique et prospectif.
Les blockchains reposent sur le principe de répliquer une séquence fixe de transactions (regroupées en blocs) pour parvenir à un consensus sur l’état du monde. Toutes les blockchains ont un déterminisme historique, ce qui signifie que les transactions dans la chaîne ont un effet fixe, sinon les résultats de la validation de la chaîne seraient non déterministes, ce qui romprait le consensus.
Mais peu de blockchains ont un déterminisme prospectif, ce qui signifie qu’une transaction qui n’a pas encore été ajoutée à la chaîne a un effet fixe (ou ne s’appliquera pas). Cardano présente un déterminisme prospectif (à l’exception actuelle des adresses de pointeur, qu’il est proposé de supprimer dans ce CIP).
Sur les chaînes de blocs qui n’ont pas de déterminisme prospectif, les utilisateurs ne peuvent pas savoir combien de frais de gaz ils doivent payer pour les transactions, ce qui fait que ces utilisateurs paient trop pour les transactions. Le manque de déterminisme prospectif est également la raison pour laquelle il existe un risque qu’une transaction sur de telles chaînes de blocs puisse échouer tout en consommant beaucoup de gaz.
Le pouvoir du déterminisme prospectif
Le déterminisme prospectif est une fonctionnalité très puissante de Cardano, pour plusieurs raisons :
- Les utilisateurs savent, à l’avance, ce qu’une transaction va faire, il n’y a donc pas de surprises. Ceci est particulièrement pertinent pour les scripts car les utilisateurs savent exactement : comment les scripts se comporteront, et combien de budget d’exécution est nécessaire.
- Les transactions proposées peuvent être traitées en parallèle en toute sécurité. Ce parallélisme est l’une des raisons de la vitesse d’Hydra.
- Parce que les utilisateurs savent à l’avance si une transaction échouera ou non, les échecs de script peuvent être sévèrement punis (car ils n’arriveront jamais à des utilisateurs non malveillants)
- En gros, cela rend l’interaction et l’évolution de la blockchain plus faciles et plus prévisibles.
Le déterminisme prospectif des transactions nécessite que chaque partie de la validation des transactions, y compris l’exécution du script, soit complètement déterministe. C’est finalement pourquoi Cardano ne peut pas avoir d’opérations non déterministes dans les scripts.
L’un des moyens d’obtenir un déterminisme prospectif consiste à faire en sorte que l’effet d’une transaction soit entièrement déterminé par la transaction elle-même et les sorties auxquelles elle fait référence. Dans le contexte de Cardano, cela s’appelle la localité. La localité est également très avantageuse pour les utilisateurs car cela signifie que n’importe qui peut savoir ce que fait une transaction simplement en regardant la transaction.
Comment les scripts Plutus gèrent-ils le temps ?
Les scripts Plutus ont accès à la plage de validité de la transaction, définie par son créateur. Lors de la définition de la plage de validité, un créateur peut décider qu’une transaction est valide de l’emplacement X à l’emplacement Y, ou laisser une ou les deux limites indéfinies. Cela impose des contraintes dans lesquelles une transaction peut être incluse, ce qui est très utile en chaîne pour définir divers « contrats ».
Le script peut supposer que l’heure réelle de validation se situe dans cette plage. Sinon, la transaction échouera dans la phase 1 avant l’exécution du script. Cela garantit le déterminisme puisque le script verra toujours la même information (la plage de validité) quel que soit le moment où le script est validé, donc le comportement sera le même.
Les limites de l’intervalle de validité sont exprimées en temps réel (POSIXTime), plutôt qu’en créneaux, et la conversion des créneaux en temps réel se fait par consensus, comme discuté dans le post précédent. Il est important d’utiliser le temps réel plutôt que les créneaux, car la longueur des créneaux peut changer lors d’un hard fork, de sorte que les hypothèses basées sur le comptage des créneaux ne sont généralement pas fiables. Le fait que les scripts voient la plage de validité permet aux scripts de faire des assertions comme “l’heure actuelle est avant/après un certain temps”, mais cela ne permet pas à un script de faire un autre type d’assertion ("la seconde dans laquelle cette transaction est validé est pair’, par exemple.)
Dans la conception originale d’Alonzo, la plage de validité couvrait toutes les utilisations connues du temps, tout en s’adaptant parfaitement au champ de durée de vie (TTL) existant. En théorie, il est possible d’appliquer les mêmes principes à d’autres types d’assertions, par exemple - laissez le script s’appuyer sur des assertions vérifiées en phase 1. Cependant, cela ne serait pas facile car cela implique des changements structurels profonds dans diverses parties du Cardano. réseau. Et comme les vérifications de la phase 1 doivent être valides pour chaque nœud du réseau, cela exclut tout type d’assertion qui dépend d’une condition locale, telle que «l’heure actuelle».
Cas d’utilisation pour le temps
Le temps a différentes applications dans l’écosystème Cardano.
Hydra
Le protocole Hydra dépend du temps pour calculer et appliquer le délai de contestation, qui est un élément essentiel du mécanisme de sécurité du protocole. La machine à états Hydra Head suit le passage du temps à l’aide de UTCTime, mais le tick provient de la chaîne, en fonction du numéro d’emplacement observé à partir des blocs produits par la chaîne. La raison de l’utilisation de UTCTime concerne les limitations inhérentes à la conversion de créneau en temps imposée par la fenêtre de validité. On ne peut pas convertir un créneau trop loin dans le futur, ce qui signifie qu’il est plus simple d’utiliser UTCTime hors chaîne et de n’effectuer des conversions que lors de la soumission/réception de transactions vers ou depuis la chaîne.
Cela implique que la granularité du tick est d’environ 20 secondes, car il s’agit de la fréquence attendue à laquelle les blocs sont produits. En utilisant cette mesure de temps, Hydra est disponible pour réagir au franchissement protocolaire du délai de contestation.
Ce qui est important, c’est que l’heure locale dans Hydra Head (et les nœuds) est liée à l’heure en chaîne gérée par Ouroboros. Comme Hydra est un protocole isomorphe, il est souhaitable de traiter les « transactions temporisées » également sur la couche 2 (voir le problème n° 196). Cependant, Hydra ne produit pas de blocs, donc le consensus lui-même n’a pas (encore) besoin d’une notion de temps.
Cela nécessite une compréhension de la précision et du processus de discrétisation du temps sur un registre de couche 2. Bien que les complexités du temps de traitement en chaîne s’appliquent également à la couche 2, la couche 2 peut fournir de meilleures solutions car ces réseaux sont beaucoup plus petits, ont une durée de vie plus courte et n’ont pas besoin d’évoluer à l’échelle mondiale.
Si vous souhaitez vous impliquer dans des discussions et partager les types d’applications que vous avez et le temps de résolution qu’elles nécessiteraient, rejoignez ce canal Hydra Discord.
Marlowe
Marlowe est un langage spécifique au domaine (DSL) pour la rédaction de contrats financiers et transactionnels, qui impliquent presque tous du temps. Une grande variété de contrats financiers standard ont été rédigés dans Marlowe, y compris la plupart des contrats standard ACTUS (par exemple, les prêts, les swaps, les options et les produits dérivés). De plus, Marlowe prend en charge une variété de types de contrats non financiers tels que les enchères, les échanges de jetons et même les jeux. Les mécanismes existants de Cardano pour travailler avec le temps s’accordent bien avec la sémantique de Marlowe et fournissent aux transactions de Marlowe la localité et le déterminisme hérités de Plutus.
Dans Marlowe, le temps du contrat apparaît généralement dans les délais et les délais d’attente qui limitent l’évolution de l’exécution du contrat, et cela fonctionne parfaitement avec les intervalles de validité de Cardano. La logique de temporisation est nécessaire dans un contrat de prêt, par exemple, pour gérer la situation où un paiement de prêt est manqué : alors une logique différente doit être exécutée afin d’imposer une pénalité, d’ajuster le calendrier des paiements futurs, etc. Les contrats peuvent également utiliser directement les points finaux temporels de l’intervalle de validité dans les calculs numériques, peut-être pour ajuster les montants des paiements futurs en fonction du moment où un paiement anticipé a été reçu. Le fait que le temps apparaisse comme un intervalle a peu d’impact pratique sur Marlowe car l’intervalle peut être aussi court que le temps nécessaire entre la soumission d’une transaction et son apparition dans un bloc sur le réseau Cardano - quelques minutes seulement.
Solutions
Cardano pourrait potentiellement fournir des données temporelles plus précises lors de la validation de la transaction, telles que l’horodatage du producteur de blocs auquel le bloc a été créé, converti à partir de son emplacement, ou même l’horodatage réel en UTC avec une précision en millisecondes. Cependant, cela briserait le déterminisme prospectif comme c’est le cas sur les protocoles qui n’incluent pas cette fonctionnalité : un utilisateur ne pourrait plus dire si une transaction peut définitivement s’appliquer au grand livre ou non, car cela dépendrait de l’horodatage exact utilisé par le producteur de blocs. lors de la création du bloc.
Une autre option consiste à ajouter divers types d’assertion aux corps de transaction au-delà de l’intervalle de validité. C’est possible, mais difficile comme déjà indiqué précédemment, il doit donc y avoir un cas d’utilisation pour que ces types d’assertions soient utiles.
Enfin, les réseaux de couche 2 tels qu’Hydra peuvent fournir une précision accrue grâce à une “longueur de créneau” plus courte et à une plage de validité plus courte, ainsi qu’à une latence réduite dans la finalité des transactions. Notez que l’implémentation actuelle d’Hydra Head n’offre pas encore ce niveau de flexibilité.
Conclusion
Le temps est un sujet complexe, en particulier dans un contexte de blockchain décentralisé. Ces articles de blog montrent qu’il existe une notion claire de temps en chaîne sur Cardano avec des contraintes spécifiques et des options d’amélioration disponibles à plus long terme.
Le temps en chaîne se comporte d’une manière quelque peu différente du temps dans les logiciels traditionnels. Cette divergence est définie de manière cohérente pour répondre aux contraintes du système tout en garantissant la sécurité et la convivialité pour les utilisateurs finaux et les opérateurs de pools de mises. De plus, la mesure du temps de Cardano semble être suffisamment bonne pour couvrir plusieurs cas d’utilisation, même par rapport aux utilisations financières traditionnelles.
(2) Documents de recherche et spécifications pertinents
Cardano est une plate-forme blockchain de troisième génération qui vise à fournir à la communauté des fonctionnalités plus avancées que n’importe quel protocole encore développé. En tant que blockchain de preuve de participation, elle est construite avec la rigueur des méthodes de développement formelles à haute assurance et vise à atteindre l’évolutivité, l’interopérabilité et la durabilité nécessaires aux applications du monde réel. Cardano est la première plate-forme à évoluer hors de la philosophie scientifique basée sur la découverte, l’examen par les pairs et la recherche cryptographique.
Construisant une base solide dans l’industrie de la blockchain, Cardano a une philosophie d’ouverture et de transparence. Toutes les recherches et spécifications techniques qui sous-tendent Cardano sont publiées publiquement et mises à la disposition de la communauté.
La feuille de route de développement de Cardano est divisée en 5 ères qui se concentrent sur la fondation, la décentralisation, le déploiement de contrats intelligents et de registres multi-actifs, l’évolutivité et la gouvernance d’un environnement de blockchain pionnier.