(1) Cardano entropy
L’évolution de Cardano vers une entité entièrement décentralisée
La blockchain Cardano est passée d’un système fédéré géré uniquement par 8 nœuds en juillet 2020 à son état actuel où la production de blocs est entièrement décentralisée. La dernière partie de cette transition s’est déroulée le 31 mars 2021 (J = 0 jour), une étape majeure dans le parcours de Cardano. A partir de cette date, 100% de la production de blocs est à la charge des opérateurs de pools de participations (SPO).
Le paramètre d’entropie
Un État véritablement décentralisé signifie que nous ne pouvons ni prédire ni influencer les événements de la blockchain à l’avenir. En d’autres termes, tous les futurs événements en chaîne doivent être complètement imprévisibles. Pour garantir cela, Cardano fournit un mécanisme d’entropie supplémentaire qui peut être utilisé pour garantir le véritable caractère aléatoire du système. Le véritable hasard est au cœur de tout système cryptographique complexe. Pour qu’un environnement cryptographique tel que la blockchain de Cardano fonctionne et que la communauté lui fasse confiance en tant que véritablement décentralisé et équitable, il doit exister une source d’aléatoire véritable et imprévisible qui garantit que l’orientation future de la chaîne ne peut être manipulée par quiconque ayant des connaissances. du passé.
La source aléatoire de Cardano est donnée par le paramètre d’entropie. Cela représente quelque chose d’imprévisible en dehors de l’écosystème Cardano et garantit que personne ne pourrait “truquer” le caractère aléatoire de la blockchain. La valeur de ce paramètre a été calculée sur la base d’événements qui ne pouvaient pas être connus à l’avance, ou sur lesquels n’importe qui aurait pu avoir des informations privilégiées.
Le paramètre sera mis à jour pendant l’époque commençant le 5 avril 2021 et déterminé par le hachage du dernier bloc avant le mercredi 7 avril, 15:44:51 UTC = slot 151200 de l’époque 258 ; avec cette valeur de hachage apparaissant dans le premier bloc de l’emplacement 151200 ou ultérieur.
Mécanisme d’addition d’entropie de Cardano
Pour comprendre comment fonctionne le mécanisme d’ajout d’entropie, il est essentiel de comprendre d’abord comment fonctionne la production de blocs entièrement décentralisée et comment le nouveau nonce de transition affectera ce processus.
Le protocole Ouroboros détermine quels pools sont élus comme producteurs de blocs via une séquence évolutive de nonces de leadership (graines cryptographiques utilisées pour générer une séquence de valeurs à l’aide d’un algorithme de génération de nombres aléatoires reproductibles). Ces nonces fixent le calendrier de production des blocs. Chaque nonce leader détermine ce calendrier pour une époque complète de 120 heures, au cours de laquelle le nonce régit le choix des pools de mises pour diriger la création de chaque bloc. Les nonces de leadership et les distributions de participation évoluent à l’unisson pour fournir les propriétés de registre fondamentales requises.
Le nonce de la transition
Juste après le 31 mars, nous avons ajouté un nonce de transition au nonce de leadership en cours d’exécution. Le nonce de transition doit s’appuyer sur des valeurs aléatoires (qui sont introduites via des transactions en chaîne) qui ne peuvent pas être prédites avec précision lorsque la répartition des enjeux pour l’époque du 10 avril est réglée. Cela met un accent particulier sur les transactions apparaissant dans la blockchain entre la marque de 12 heures – lorsque la répartition des enjeux est fermement établie – et la marque de 42 heures, lorsque la valeur de hachage sera levée.
Le nonce de transition reflète l’entropie d’une variété de sources externes imprévisibles. Plus précisément, toutes les transactions publiées sur la blockchain avant le mercredi 7 avril à 15:44:51 UTC (slot 151200 de l’époque 258) joueront un rôle notable et privilégié dans l’histoire de Cardano : la valeur de hachage accumulée des transactions (reflétée dans le "précédent -block hash’ à partir du premier bloc créé sur la chaîne à ce moment ou après) déterminera le nonce de transition et contribuera donc directement au cycle perpétuel de génération aléatoire d’Ouroboros.
Le mécanisme d’addition d’entropie
Dans Cardano, le mécanisme d’ajout d’entropie fonctionne comme suit : le système ajoute des chaînes de bits spécifiques sur la blockchain aux nonces de leadership suivants (qui sont les cibles prévues du nonce de transition). Cela nécessite une déclaration publique de la chaîne de bits et une approbation explicite et sécurisée par chiffrement. Plus précisément, seule une poignée de votes signés numériquement des délégués de la genèse peuvent terminer le processus, et ont un délai spécifique pour le faire : les votes doivent apparaître avant la marque des 48 heures dans l’époque.
L’époque commençant le lundi 5 avril à 21:44:51 UTC (époque 258) a invoqué le mécanisme : en particulier, le hachage de bloc précédent apparaissant dans le premier bloc le mercredi 7 avril ou après à 15:44:51 UTC ( slot 151200 de l’époque 258) déterminera le nonce de transition ; cela aura lieu environ 42 heures après le début de l’époque et laissera donc six heures aux délégués à la genèse pour voter. Rappelant la structure de la chaîne de hachage de la blockchain Ouroboros, cette valeur de hachage dépend de l’ensemble de la blockchain jusqu’à ce point.
(2) Cardano fee structure
Cardano utilise un système de frais de transaction qui couvre le coût de traitement et de stockage à long terme des transactions.
L’environnement Cardano est unique dans la manière dont il gère les frais, car les frais ne vont pas directement au producteur de blocs. Au lieu de cela, ils sont regroupés puis distribués à tous les pools qui ont créé des blocs au cours d’une époque.
Il n’y a actuellement aucun frais pour le coût de la mémoire de suivi de l’état de la chaîne accumulée, en particulier UTXO.
Prévenir les attaques économiques
L’événement Hard Fork de Shelley a signifié que la blockchain Cardano est passée d’un environnement fédéré à un environnement entièrement décentralisé, ce qui pourrait inciter les acteurs malveillants à perpétrer des attaques économiques.
Une attaque économique peut se produire lorsque les coûts encourus par les opérateurs d’un système ne sont pas couverts par les redevances imposées aux utilisateurs d’un système donné. Ces situations permettent aux utilisateurs d’imposer des coûts aux opérateurs sans payer eux-mêmes l’intégralité des coûts, ce qui pourrait potentiellement conduire à une forte baisse de la participation des opérateurs et pourrait finalement conduire à l’effondrement du système lui-même.
Pour éviter que cette situation ne se produise, il est d’une importance cruciale de s’attaquer à la fois aux coûts existants non comptabilisés de l’opérateur et aux nouveaux coûts.
La structure tarifaire de Cardano est assez simple.
Les frais sont construits autour de deux constantes (a et b). La formule de calcul des frais minimaux pour une transaction (tx) est a * size(tx) + b, où :
- a/b sont des paramètres de protocole
- size(tx) est la taille de la transaction en octets
Paramètres de protocole (a et b)
Les paramètres de protocole sont des valeurs qui peuvent être modifiées par le système de mise à jour de Cardano pour réagir et s’adapter aux changements du volume des transactions, des prix du matériel et de l’évaluation ada. La modification de ces paramètres constitue un hard fork, car elle influence les transactions acceptées par le système.
- Paramètre de protocole a
Le paramètre a reflète la dépendance du coût de transaction à la taille de la transaction. Plus la transaction est importante, plus il faut de ressources pour la stocker et la traiter.
- Paramètre de protocole b
La valeur de b est une commission payable, quelle que soit la taille de la transaction. Ce paramètre a été introduit principalement pour empêcher les attaques par déni de service distribué (DDoS). b rend ces attaques d’un coût prohibitif et élimine la possibilité qu’un attaquant génère des millions de petites transactions pour inonder et planter le système.
- Paramètre de protocole x
x représente la taille de la transaction en octets.
(3) Cardano monetary policy
Cardano vise à réaliser une véritable décentralisation avec l’introduction de l’ère Voltaire plus tard en 2020. Voltaire inclura des systèmes de vote et de trésorerie décentralisés pour permettre à la communauté d’influencer l’évolution de Cardano et fournira un mécanisme de financement pour transformer Cardano en une société autofinancée et autofinancée. environnement durable.
La véritable décentralisation s’accompagne de son propre ensemble de défis, car des facteurs tels que la sécurité, la performance, la stabilité, la durabilité, l’équité et, surtout, la viabilité économique entrent en jeu.
Maintenir, développer et améliorer un projet blockchain nécessite un soutien financier continu. Lorsque Voltaire sera mis en œuvre, le Trésor remplira cette fonction et le financement des nouvelles fonctionnalités, améliorations, etc. sera alloué via un système de vote décentralisé.
Piscines de mise
Les principes de décentralisation et d’équité guident le développement de Cardano. Cardano veut offrir des opportunités égales à tous ceux qui souhaitent faire partie du réseau en gérant un pool de participations. Mais la liberté même de participer ouvre la possibilité d’un avantage injuste posé par les opérateurs de pools de participation plus importants. Cela présente le défi de maintenir l’intégrité de la chaîne tout en incitant les gens à créer des pools et à soutenir la chaîne.
Mécanisme d’incitation
L’expansion monétaire de Cardano repose sur un engagement à long terme des opérateurs de pools de participations pour fournir un soutien continu à la chaîne. Cet engagement nécessite un mécanisme d’incitation solide et stable pour les opérateurs, de sorte que ce mécanisme doit garantir que le système d’incitation ne change pas de manière significative dans le temps d’une manière qui pourrait affecter négativement les revenus des opérateurs.
Le système d’incitation de Cardano pour les opérateurs de pools de mises est conçu pour équilibrer k pools entièrement saturés (où k est le nombre de pools souhaités), de sorte que cet équilibre signifie que les récompenses seront optimales pour tout le monde lorsque toutes les mises seront déléguées uniformément aux k pools les plus attractifs.
Politique monétaire
La politique monétaire de Cardano aborde deux problèmes :
- La nécessité d’offrir des récompenses aux personnes qui participent au réseau
- Financement du trésor
Récompenses
L’expansion et l’amélioration future de la blockchain de Cardano seront grandement influencées par sa communauté, qui doit être incitée par des récompenses à participer au développement de Cardano.
Les récompenses de mise pour les délégants et les opérateurs de pool de mise proviennent de deux sources :
- Frais de transaction - les frais de chaque transaction de tous les blocs produits à chaque époque vont dans un «pot» virtuel. Un pourcentage fixe (ρ) des réserves ada restantes est ajouté à ce pot.
- Expansion monétaire - un certain pourcentage (τ) du pot est envoyé au trésor, et le reste est utilisé comme récompense d’époque.
Ce système est conçu pour garantir que la part des récompenses prélevées sur les réserves est élevée au début, lorsque le nombre de transactions est encore relativement faible. Cela incite les premiers utilisateurs à agir rapidement pour bénéficier de récompenses initiales élevées. Au fil du temps, et à mesure que le nombre de transactions augmente, des frais supplémentaires compenseront les réserves plus petites.
Ce mécanisme garantit également que les récompenses disponibles sont prévisibles et ne varient pas considérablement. Au lieu de cela, les récompenses changent progressivement. Le pourcentage fixe prélevé sur les réserves restantes à chaque époque garantit un déclin exponentiel en douceur.
Financement du Trésor
L’objectif du Trésor est de fournir des fonds pour développer les activités de Cardano par le biais d’un processus de vote. Cela nécessite un processus par lequel des fonds sont régulièrement envoyés au Trésor pour s’assurer que les fonds sont toujours disponibles.
Justification politique des valeurs ρ et τ
On a beaucoup réfléchi à la détermination des valeurs de ρ (pourcentage fixe) et τ (fonds versés au Trésor).
- Calcul de ρ
Lors de la recherche de la bonne valeur de ρ, l’équipe a été confrontée à un dilemme : une valeur plus élevée signifierait initialement des récompenses plus élevées pour tout le monde, et le Trésor se remplirait plus rapidement. Mais des valeurs plus élevées de ρ signifieraient également que les réserves s’épuiseraient plus rapidement. Payer des récompenses élevées et inciter les premiers utilisateurs est une considération cruciale, mais il en va de même pour offrir une perspective à long terme à toutes les parties prenantes. Par conséquent, la solution à ce dilemme nécessite un compromis entre ces deux problèmes.
Adopter une approche de décroissance exponentielle pour empêcher la réserve de Cardano de s’épuiser est logique dans cette situation.
Le calcul de la «demi-vie de la réserve» (c’est-à-dire le temps nécessaire pour que la moitié de la réserve soit épuisée) permet de visualiser l’impact du choix d’une valeur spécifique de ρ plutôt qu’une autre. Cela a fait l’objet de nombreuses discussions et, finalement, la valeur attribuée a été de 0,3 %. La raison en est que les projections mathématiques ont montré qu’une valeur de ρ (le pourcentage fixe d’ada entrant dans le pot virtuel à chaque époque) de 0,3 % signifierait une demi-vie de réserve de quatre à cinq ans. En termes simples, seulement la moitié de la réserve restante serait utilisée tous les quatre à cinq ans.
- Choisir τ
Déterminer la bonne valeur pour τ (le pourcentage de récompenses non réclamées allant automatiquement dans les réserves à chaque époque) était tout aussi difficile. Après discussions, délibérations et projections, la valeur choisie était de 20%, ce qui signifie qu’initialement, 20% de l’expansion monétaire et des frais de transaction sont envoyés au Trésor après chaque époque.
(4) Explanation of the nonce value
Problème:
Lors de l’utilisation de l’interface de ligne de commande Cardano (cardano-CLI), un utilisateur fournit un nonce pour une transaction, mais lorsqu’il affiche le contenu de la transaction, le nonce renvoyé est différent.
Étapes à reproduire
La commande cardano-cli governance create-update-proposal crée une proposition de mise à jour :
cardano-cli governance create-update-proposal --epoch 258 --extra-entropy d8b0ee71c3eab43750882bdc0880cf0b46a488d82e5bc9fd5b2fb3e7297bdbd4 --out-file mainnet-258-entropy.proposal $(for i in {1..7}; do echo "--genesis-verification-key-file genesis-keys/genesis$i.vkey "; done)
La commande cardano-cli transaction build-raw crée une transaction :
cardano-cli transaction build-raw --tx-in b2bdbe07d5cd4da8b8dbef9eee67ff6fb1877055d0b8309fbd4718591389eac5#0 --tx-out addr1q9jytwcggewzdn6rtfp8fwx6mlm48vae4pl5428cs3u5x82wkertsmcc7m6zve5y7dlmeaqz03jsw37ug5nc4v9l3j8q54uy5u+$((5000000 - 217553)) --fee 217553 --ttl $(cardano-cli query tip --mainnet | jq '.slot + 5000') --update-proposal-file mainnet-258-entropy.proposal --out-file tx-entropy.txbody
La commande cardano-cli transaction view affiche le contenu de la transaction :
cardano-cli transaction view --tx-body-file tx-entropy.txbody
Dans la sortie, le nonce est différent :
>>`{
"auxiliary_data": null,
"auxiliary_data_hash": null,
"certificates": [],
"era": "Mary",
"fee": 217553,
"inputs": [
"b2bdbe07d5cd4da8b8dbef9eee67ff6fb1877055d0b8309fbd4718591389eac5#0"
],
"mint": {
"lovelace": 0,
"policies": {}
},
"outputs": [
{
"address": "016445bb08465c26cf435a4274b8dadff753b3b9a87f4aa8f88479431d4eb646b86f18f6f4266684f37fbcf4027c650747dc45278ab0bf8c8e",
"amount": {
"lovelace": 4782447,
"policies": {}
}
}
],
"update": "Update (ProposedPPUpdates (fromList [(KeyHash \"162f94554ac8c225383a2248c245659eda870eaa82d0ef25fc7dcd82\",PParams
{_minfeeA = SNothing, _minfeeB = SNothing, _maxBBSize = SNothing, _maxTxSize = SNothing, _maxBHSize = SNothing, _keyDeposit = SNothing, _poolDeposit = SNothing, _eMax = SNothing, _nOpt = SNothing, _a0 = SNothing, _rho = SNothing, _tau = SNothing, _d = SNothing, _extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\"), _protocolVersion = SNothing, _minUTxOValue = SNothing, _minPoolCost = SNothing}),(KeyHash \"2075a095b3c844a29c24317a94a643ab8e22d54a3a3a72a420260af6\",PParams {_minfeeA = SNothing, _minfeeB = SNothing, _maxBBSize = SNothing, _maxTxSize = SNothing, _maxBHSize = SNothing, _keyDeposit = SNothing, _poolDeposit = SNothing, _eMax = SNothing, _nOpt = SNothing, _a0 = SNothing, _rho = SNothing, _tau = SNothing, _d = SNothing, _extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\"), _protocolVersion = SNothing, _minUTxOValue = SNothing, _minPoolCost = SNothing}),(KeyHash \"268cfc0b89e910ead22e0ade91493d8212f53f3e2164b2e4bef0819b\",PParams {_minfeeA = SNothing, _minfeeB = SNothing, _maxBBSize = SNothing, _maxTxSize = SNothing, _maxBHSize = SNothing, _keyDeposit = SNothing, _poolDeposit = SNothing, _eMax = SNothing, _nOpt = SNothing, _a0 = SNothing, _rho = SNothing, _tau = SNothing, _d = SNothing, _extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\"), _protocolVersion = SNothing, _minUTxOValue = SNothing, _minPoolCost = SNothing}),(KeyHash \"60baee25cbc90047e83fd01e1e57dc0b06d3d0cb150d0ab40bbfead1\",PParams {_minfeeA = SNothing, _minfeeB = SNothing, _maxBBSize = SNothing, _maxTxSize = SNothing, _maxBHSize = SNothing, _keyDeposit = SNothing, _poolDeposit = SNothing, _eMax = SNothing, _nOpt = SNothing, _a0 = SNothing, _rho = SNothing, _tau = SNothing, _d = SNothing, _extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\"), _protocolVersion = SNothing, _minUTxOValue = SNothing, _minPoolCost = SNothing}),(KeyHash \"ad5463153dc3d24b9ff133e46136028bdc1edbb897f5a7cf1b37950c\",PParams {_minfeeA = SNothing, _minfeeB = SNothing, _maxBBSize = SNothing, _maxTxSize = SNothing, _maxBHSize = SNothing, _keyDeposit = SNothing, _poolDeposit = SNothing, _eMax = SNothing, _nOpt = SNothing, _a0 = SNothing, _rho = SNothing, _tau = SNothing, _d = SNothing, _extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\"), _protocolVersion = SNothing, _minUTxOValue = SNothing, _minPoolCost = SNothing}),(KeyHash \"b9547b8a57656539a8d9bc42c008e38d9c8bd9c8adbb1e73ad529497\",PParams {_minfeeA = SNothing, _minfeeB = SNothing, _maxBBSize = SNothing, _maxTxSize = SNothing, _maxBHSize = SNothing, _keyDeposit = SNothing, _poolDeposit = SNothing, _eMax = SNothing, _nOpt = SNothing, _a0 = SNothing, _rho = SNothing, _tau = SNothing, _d = SNothing, _extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\"), _protocolVersion = SNothing, _minUTxOValue = SNothing, _minPoolCost = SNothing}),(KeyHash \"f7b341c14cd58fca4195a9b278cce1ef402dc0e06deb77e543cd1757\",PParams {_minfeeA = SNothing, _minfeeB = SNothing, _maxBBSize = SNothing, _maxTxSize = SNothing, _maxBHSize = SNothing, _keyDeposit = SNothing, _poolDeposit = SNothing, _eMax = SNothing, _nOpt = SNothing, _a0 = SNothing, _rho = SNothing, _tau = SNothing, _d = SNothing, _extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\"), _protocolVersion = SNothing, _minUTxOValue = SNothing, _minPoolCost = SNothing})])) (EpochNo 258)",
"validity_interval": {
"invalid_before": null,
"invalid_hereafter": 26253029
},
"withdrawals": []`
}
Les champs comparés sont :
--extra-entropy d8b0ee71c3eab43750882bdc0880cf0b46a488d82e5bc9fd5b2fb3e7297bdbd4
Et
_extraEntropy = SJust (Nonce \"d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa\")
Explication
En interne, l’argument --extra-entropy est haché à l’aide de Blake2b-256 avant d’être placé dans la transaction de proposition de mise à jour. Ce hachage est appliqué à la représentation binaire, plutôt qu’à la représentation base16 fournie. Ce hachage supplémentaire n’affecte pas la qualité de l’entropie fournie. Par exemple, la sortie de l’exemple ci-dessus peut être répliquée en Python avec la séquence de commandes suivante :
import hashlib >>> hashlib.blake2b(bytes.fromhex( … “d8b0ee71c3eab43750882bdc0880cf0b46a488d82e5bc9fd5b2fb3e7297bdbd4”), … digest_size=32).hexdigest() ‘d982e06fd33e7440b43cefad529b7ecafbaa255e38178ad4189a37e4ce9bf1fa’
Source : https://docs.cardano.org/explore-cardano/cardano-entropy