Cortina : Linéarisation de la X-Chain

Avalanche France
Avalanche fr
Published in
7 min readMar 23, 2023

Le lundi 27 mars, le code de préversion pour la mise à jour d’Avalanche Cortina sera publié. Cette mise à jour sera activée à 11 heures ET (17 heures CET) le jeudi 30 mars. Notez que ce code de pré-version fonctionnera UNIQUEMENT sur Fuji. Si vous exécutez le code sur le Mainnet, il s’arrêtera au démarrage.

Si la mise à jour de Cortina sur Fuji est réussie, l’heure d’activation d’Avalanche Mainnet sera annoncée et la version officielle de Cortina AvalancheGo (v1.10.0) sera publiée.

La mise à jour Cortina comprend des optimisations de protocole qui ne sont pas compatibles avec les versions d’AvalancheGo < v1.10.0. Si vous gérez un nœud sur Fuji, vous devez mettre à jour votre logiciel vers AvalancheGo >= v1.10.0 avant l’heure d’activation sur Fuji. Si vous êtes un opérateur de nœud Mainnet, aucune action n’est requise jusqu’à ce que le code officiel AvalancheGo@v1.10.0 soit publié.

Linéarisation de la X-Chain

La X-Chain utilise le consensus Avalanche, un protocole sans leader, basé sur un DAG, qui permet le traitement simultané d’UTXOs non conflictuelles à haut débit sans établir un ordre total d’activité. La C-Chain, la P-Chain et tous les Subnets d’Avalanche, d’autre part, exécutent Snowman++, un protocole basé sur une chaîne et totalement ordonné qui séquence la production de blocs sans conflit et sans créneaux temporels sur des milliers de participants.

La sémantique existante de la X-Chain empêche ou complique considérablement l’intégration de l’Avalanche Warp Messaging (AWM), l’ajout de transactions X-Chain complexes, l’activation de la synchronisation des états et la prise en charge d’un large éventail d’échanges. L’intégration de l’AWM nécessite que Snowman++ vérifie la multi-signature BLS des messages entrants provenant d’autres Subnets d’Avalanche. Cette limitation signifie que la X-Chain, dans sa forme actuelle, ne peut pas interagir avec les Subnets et que le consensus basé sur le DAG qu’elle exécute ne peut pas être largement appliqué aux Subnets, qui souhaitent massivement communiquer de manière transparente avec d’autres Subnets.

L’absence d’ordonnancement total sur la X-Chain signifie qu’il n’y a pas d’état canonique lors de la vérification des vertex (un vertex est le conteneur pour la mise en lots des transactions sur la X-Chain, un peu comme un bloc dans une blockchain) et que les vertices sont traités dans un ordre différent sur différents nœuds. Sans état canonique, l’interaction avec des objets on-chain partagés (comme un exchange on-chain) et la synchronisation de l’état avec l’extrémité du réseau (pour éviter de retraiter toute l’activité historique) devient un problème non trivial et sujet à erreur à résoudre qui prend du temps que la communauté pourrait consacrer à faire évoluer davantage les Subnets. L’ordre non déterministe de l’activité on-chain empêche, ou entrave considérablement, la capacité des exchanges à s’intégrer à la X-Chain (dans sa forme actuelle), car ils ne peuvent pas réconcilier les soldes à différents moments.

Cortina fait migrer la X-Chain pour qu’elle exécute le consensus Snowman++ et fonctionne comme une blockchain totalement ordonnée au lieu d’un DAG dans un processus appelé “linéarisation”. Lorsque la linéarisation commence, il ne sera plus possible d’ajouter des sommets supplémentaires au DAG de la X-Chain. L’état terminal du DAG, désormais immuable, sera alors utilisé comme état de genèse de la X-Chain linéarisée alimentée par Snowman++. Le format de transaction utilisé sur la X-Chain et les API pour soumettre des transactions, récupérer l’état de la transaction et récupérer le solde ne changeront pas au cours de ce processus, de sorte que la plupart des portefeuilles n’auront pas besoin d’apporter de modifications pour prendre en charge cet événement de linéarisation. Cependant, les explorateurs qui prennent en charge la X-Chain devront migrer pour analyser les blocs de la X-Chain au lieu d’analyser les sommets de la X-Chain, qui ressemblent beaucoup aux blocs de la P-Chain. La linéarisation est transparente et ne devrait pas entraîner de temps d’arrêt sur la P-Chain, la C-Chain ou les Subnets. La X-Chain sera toutefois brièvement inaccessible.

Comme indiqué ci-dessus, cette migration ouvre la voie à l’intégration de l’Avalanche Warp Messaging, à de nouveaux types de transactions qui modifient l’état partagé de la X-Chain, fournit un chemin direct pour permettre la synchronisation de l’état, et permet aux exchanges de prendre en charge la X-Chain (qui contiendra de nombreux tokens utilisés sur les Subnets élastiques). Bien qu’il soit possible d’introduire un ordre total sur un DAG, le faire sur la X-Chain aurait nécessité une réécriture du mécanisme de consensus Avalanche existant et n’aurait pas été utile pour les Subnets. La migration vers un mécanisme de consensus unique pour l’ensemble du réseau Avalanche, qui réduit la taille de la base de calcul de confiance et augmente l’effet de levier des efforts de R&D existants, permettra un développement plus rapide et des innovations plus significatives.

Récompense des délégations par lots

Depuis le lancement du réseau Avalanche, les validateurs ont la possibilité de facturer des frais à tous ceux qui délèguent sur leur nœud. Si leur validateur est en ligne pendant 80 % d’une période de délégation, ils reçoivent un pourcentage de la récompense (les frais) gagnée par le délégué. La P-Chain distribue ces frais sous la forme d’une UTXO distincte par période de délégation.

Comme le nombre de délégués sur le réseau a considérablement augmenté au cours des derniers mois (jusqu’à ~80k au 3/20/23), le nombre d’UTXOs qu’un validateur peut recevoir comme paiement a également augmenté de manière substantielle. Cela signifie souvent qu’un validateur se retrouve avec des milliers de petites UTXO qui doivent être agrégées pour pouvoir être utilisées. Le suivi de milliers d’UTXOs dans les explorateurs et les portefeuilles rend également la fourniture d’une bonne UX plus difficile qu’elle ne devrait l’être.

Cortina modifie la façon dont ces frais de délégation sont distribués pour tous les validateurs qui commencent à staker après l’activation de Cortina (les validateurs précédemment stakés ne verront aucun changement). Au lieu d’envoyer un UTXO de frais pour chaque période de délégation réussie, les frais sont désormais regroupés pendant toute la période de validation d’un nœud et sont distribués lorsqu’il finit sa période de staking.

Augmentation de la limite de gaz de la C-Chain

Depuis la phase 1 d’Apricot, la limite de gaz des blocs de la C-Chain a été fixée à 8 millions de gaz. Les blocs de la C-Chain sont produits toutes les ~2s, ce qui limite la quantité maximale de gaz pouvant être consommée toutes les 10s à ~40M de gaz. La cible de gaz pour chaque fenêtre roulante de 10s est cependant fixée à 15M de gaz. Cela signifie que lorsque plus de 15 millions de gaz sont utilisés dans une fenêtre de 10s, le prix du gaz augmente (et diminue lorsque moins de 15 millions de gaz sont utilisés). Pour en savoir plus sur le fonctionnement des frais dynamiques sur la C-Chain, cliquez ici.

En plus de limiter la quantité de gaz qui peut être consommée dans une fenêtre donnée, quel que soit le prix du gaz, la limite de gaz par bloc limite également la complexité des transactions qui peuvent être émises dans un seul bloc. Comme différents développeurs sur Avalanche ont commencé à déployer des dApps plus complexes, ils ont exprimé que 8M de gaz par bloc n’était pas suffisant pour leur cas d’utilisation. Cortina augmente la limite de gaz par bloc de C-Chain à 15M de gaz. Pour éviter d’augmenter la quantité de ressources nécessaires à la validation du réseau primaire, la cible de gaz restera inchangée à 15M de gaz par 10s.

FAQ

Comment mettre à niveau mon nœud ?
Le processus de mise à jour vers AvalancheGo v1.10.0 est le même que pour toute autre mise à jour. Si vous compilez à partir des sources, exécutez le script de compilation comme auparavant. Si vous utilisez les binaires précompilés, invoquez-les comme auparavant. Si vous utilisez le script d’installation, utilisez-le comme auparavant.

Une fois que vous avez démarré AvalancheGo v1.10.0, vous n’avez plus rien à faire. Vous trouverez plus d’informations sur la mise à jour d’un nœud ici. Pour rappel, il est recommandé de sauvegarder votre clé/certificat de staking.

Dois-je mettre à jour mon nœud ?
Si vous ne mettez pas à jour votre validateur vers la version 1.10.0 avant la date d’activation de l’Avalanche Mainnet (qui sera communiquée dans les prochains jours), votre nœud sera marqué comme étant hors ligne et les autres nœuds signaleront que votre nœud a un temps de disponibilité plus faible, ce qui peut compromettre vos récompenses de staking.

Y a-t-il un changement dans les exigences matérielles ?
Non.

La mise à jour diminuera-t-elle le temps de disponibilité de mon validateur ?
Non. Pour rappel, vous pouvez vérifier le temps de fonctionnement estimé de votre validateur à l’aide de l’appel API info.uptime :

Je pense que quelque chose ne va pas. Que dois-je faire ?
Tout d’abord, assurez-vous d’avoir bien lu la documentation et consulté les FAQs. Si vous ne trouvez pas de réponse à votre question, rendez-vous sur notre serveur Discord et cherchez votre question. Si elle n’a pas déjà été posée, posez-la dans le canal approprié.

À propos d’Avalanche :

Avalanche est la plateforme de smart contracts la plus rapide et la plus fiable au monde. Son protocole de consensus révolutionnaire et ses nouveaux Subnets permettent aux développeurs Web3 de lancer facilement des solutions hautement évolutives. Déployez sur l’EVM, ou utilisez votre propre VM personnalisée. Construisez ce que vous voulez, comme vous le voulez, sur une blockchain écologique conçue pour les développeurs Web3.

Telegram Francophone | Twitter Francophone |Site Web |Papier blanc | Twitter | Discord | GitHub | Documentation | Explorer | Avalanche-X | Telegram | Facebook | LinkedIn | Reddit | YouTube

--

--