Kian Paimani, développeur principal de Parity, explique le protocole JAM de Polkadot du point de vue technique pour aider les gens à mieux comprendre comment JAM apporte une nouvelle évolutivité à l'écosystème Polkadot.
Auteur: Kian Paimani, développeur principal de Parity
Compilation : Polkadot Labs
"Le schéma de connaissances de Polkadot"* est notre article d'initiation à partir de zéro pour Polkadot. Nous essayons de partir des bases les plus fondamentales de Polkadot pour fournir à tous une compréhension complète de Polkadot. Bien sûr, c'est un projet énorme et plein de défis, mais nous espérons, à travers cet effort, que chacun pourra avoir une compréhension correcte de Polkadot, et que ceux qui ne le connaissent pas pourront rapidement en acquérir une connaissance approfondie.**** Aujourd'hui marque la 148ème édition de cette rubrique, et cet article est une interprétation technique du protocole JAM le plus récent de Polkadot par Kian Paimani, un développeur principal de Parity, visant à aider les gens à mieux comprendre comment JAM apporte une nouvelle extensibilité à l'écosystème de Polkadot. Cet article est écrit du point de vue de l'auteur.
*Voici une explication détaillée de Polkadot1, Polkadot2 et de leur évolution vers JAM. (Voir les détails sur ***). Ce document s'adresse aux lecteurs techniques, en particulier à ceux qui ne sont pas très familiers avec Polkadot mais qui ont une certaine connaissance des systèmes de blockchain et qui peuvent avoir une compréhension des technologies connexes dans d'autres écosystèmes.
*Avant de lire le livre blanc JAM, je pense que c'est une bonne prélude à la lecture de cet article. (Voir détails: ***)
Connaissances de base
Ce document suppose que le lecteur est familier avec les concepts suivants:
Décrire la chaîne de blocs comme une fonction de transition d'état.
Comprendre ce qu'est un "état". (Voir les détails à l'adresse suivante: _sdk_docs/reference_docs/blockchain_state_machines/index.html)
Sécurité économique et Preuve d'enjeu. (Voir les détails : 、)
Introduction: Polkadot1
Tout d'abord, revenons sur ce que je considère comme la caractéristique la plus innovante de Polkadot1.
La Securities and Exchange Commission (SEC) des États-Unis considère DOT comme un logiciel et non comme un titre (voir de plus amples informations : )
La plupart des travaux de développement de réseau sont effectués par Polkadot Fellowship (voir les détails à), plutôt que par des entreprises soutenues par des fonds (comme Parity :) .
Au niveau technique :
Polkadot réalise la sécurité partagée et l'exécution de Sharding.
Stocke le code de la blockchain sous forme de bytecode dans l'état à l'aide du protocole Meta basé sur WASM (voir: _sdk_docs/reference_docs/wasm_meta_protocol/index.html). Cela permet la plupart des mises à niveau sans fork et prend en charge le Sharding hétérogène.
Pour plus d'informations sur le "Sharding hétérogène", veuillez vous référer aux sections correspondantes.
Sharding : ce qu’il faut retenir
Actuellement, nous discutons d'un réseau de couche 1 qui héberge d'autres réseaux de couche 2 "blockchain", similaire à Polkadot et Ethereum. Ainsi, les termes couche 2 et chaîne parallèle (Parachain) peuvent être utilisés de manière interchangeable.
Le problème central de l'évolutivité de la chaîne de Bloc peut être décrit comme suit : il existe un groupe de validateurs qui peuvent garantir la fiabilité de l'exécution de certains codes via l'économie cryptographique de Preuve d'enjeu (Proof-of-Stake). Par défaut, ces validateurs doivent réexécuter tout le travail les uns des autres. Par conséquent, tant que nous obligeons tous les validateurs à réexécuter tout le travail tout le temps, le système entier ne peut pas être mis à l'échelle.
Veuillez noter que l'augmentation du nombre de validateurs dans ce modèle ne permettra pas réellement d'augmenter le débit du système tant que le principe absolu de réexécution susmentionné reste inchangé.
Ce qui est présenté ci-dessus est une chaîne de blocs mono (par opposition à une chaîne de blocs fragmentée). Tous les validateurs du réseau traiteront chaque entrée (c'est-à-dire chaque bloc) un par un.
Dans un tel système, si la couche 1 veut héberger plus de couche 2, alors tous les validateurs devront maintenant réexécuter tout le travail de la couche 2. Évidemment, cette approche n’est pas évolutive. Les cumuls optimistes sont un moyen de contourner ce problème, car la preuve de la fraude n’est réexécutée que si quelqu’un prétend qu’une fraude a eu lieu. Les cumuls basés sur SNARK contournent ce problème en tirant parti du fait que le coût de vérification d’une preuve SNARK est beaucoup plus faible que celui de sa génération, il est donc logique de permettre à tous les validateurs de valider les preuves SNARK. Pour plus d’informations à ce sujet, consultez l’annexe : Diagramme spatial d’évolutivité.
Une solution simple pour Sharding est de simplement diviser l'ensemble des validateurs en plus petits sous-ensembles et de permettre à ces sous-ensembles plus petits d'exécuter à nouveau le Bloc de la couche 2. Quels sont les problèmes avec cette méthode? Nous effectuons le Sharding de l'exécution du réseau et de sa sécurité économique. La sécurité de cette couche 2 est inférieure à celle de la couche 1, et plus nous divisons l'ensemble des validateurs en plusieurs Shardings, plus sa sécurité sera réduite.
Contrairement à Optimistic Rollups, qui ne peut pas être réexécuté en permanence, Polkadot a pris en compte l'exécution de Sharding lors de sa conception, ce qui permet à certains validateurs de réexécuter le bloc de la couche 2 tout en fournissant suffisamment de preuves économiques cryptographiques à tous les participants du réseau pour prouver l'authenticité de ce bloc de la couche 2 et sa sécurité lorsqu'il est réexécuté par l'ensemble des validateurs. Ceci est réalisé par le biais d'un mécanisme novateur (récemment publié officiellement) appelé ELVES (voir détails: 01928374656574839201).
En bref, ELVES peut être considéré comme un mécanisme de type "Rollups de suspicion". En demandant activement à d'autres validateurs si un bloc Layer2 est valide pendant plusieurs tours, nous pouvons confirmer avec une grande probabilité la validité de ce bloc Layer2. En fait, en cas de litige, l'ensemble des validateurs sera rapidement requis. Rob Habermeier, co-fondateur de Polkadot, a expliqué cela en détail dans un article (voir: ).
ELVES permet à Polkadot d'avoir simultanément deux propriétés auparavant considérées comme mutuellement exclusives : "Sharding" et "sécurité partagée". Il s'agit là de la principale réalisation technologique de Polkadot1 en matière de scalabilité.
Maintenant, continuons la discussion sur la comparaison avec "CORE".
Un réseau Bloc qui exécute le Sharding ressemble beaucoup à un CPU : tout comme un CPU peut avoir plusieurs cœurs pour exécuter des instructions en parallèle, Polkadot peut traiter en parallèle les Bloc de la couche 2. C'est pourquoi la couche 2 sur Polkadot est appelée parachain, et l'environnement où un sous-ensemble plus restreint de validateurs re-exécute un seul Bloc de la couche 2 est appelé « CORE ». Chaque CORE peut être abstrait comme un « groupe de validateurs collaborant ».
Vous pouvez imaginer une chaîne de blocs individuelle comme ne capturant qu'un bloc à tout moment pendant une période de temps donnée, tandis que Polkadot capture un bloc de chaîne de relais et un bloc de chaîne parallèle pour chaque noyau à chaque période de temps.
Hétérogénéité
Jusqu'à présent, nous avons seulement discuté de la scalabilité et de l'exécution de Sharding offerts par Polkadot. Il convient de noter que chaque Sharding de Polkadot est en réalité une application complètement différente. Cela est réalisé en utilisant un protocole métier stocké en bytecode : une manière de stocker la définition de la chaîne de blocs en tant que bytecode dans l'état de la chaîne de blocs elle-même. Dans Polkadot 1.0, le WASM est utilisé comme bytecode préféré, tandis que le PVM/RISC-V est utilisé dans JAM.
En résumé, c'est pourquoi Polkadot est appelé une blockchain à fragments hétérogènes. (Voir les détails à: 01928374656574839201) Chaque couche 2 est une application totalement différente.
Polkadot2
Une partie importante de Polkadot2 est de rendre l'utilisation du noyau plus flexible. Dans le modèle Polkadot d'origine, la durée de location du noyau peut varier de 6 mois à 2 ans, ce qui convient aux entreprises riches en ressources, mais pas aux petites équipes. La fonctionnalité qui permet au noyau Polkadot d'être utilisé de manière plus flexible est appelée "agile coretime". (Voir les détails:) Dans ce mode, la durée de location du noyau Polkadot peut être aussi courte qu'un Bloc, ou aussi longue qu'un mois, et offre une garantie de prix maximum pour les utilisateurs qui souhaitent louer à long terme.
Les autres fonctionnalités de Polkadot 2 sont en cours de discussion et seront progressivement dévoilées, il n'est donc pas nécessaire d'en dire plus ici.
Les opérations internes du noyau et hors chaîne
Pour comprendre JAM, il faut d'abord comprendre ce qui se passe lorsqu'un Bloc Layer2 entre dans le cœur de Polkadot.
Le contenu suivant a été considérablement simplifié.
En résumé, le noyau est principalement composé d'un groupe de validateurs. Ainsi, lorsque nous disons que les données sont envoyées au noyau, il s'agit en fait de ces données étant transmises à ce groupe de validateurs.
Un bloc Layer2 ainsi qu'une partie de l'état de ce Layer2 sont envoyés au cœur. Ces données contiennent toutes les informations nécessaires à l'exécution de ce bloc Layer2.
Certains validateurs au sein du noyau re-exécuteront les Blocs de la couche 2 et continueront à traiter les tâches liées au Consensus.
Les validateurs principaux fourniront à nouveau les données nécessaires aux autres validateurs (à l'extérieur du noyau). Les autres validateurs peuvent décider en fonction des règles ELVES s'ils doivent ou non réexécuter ce bloc de couche 2, et ils ont besoin de ces données pour le faire.
Attention, jusqu'à présent, toutes les opérations se sont déroulées en dehors du bloc principal de Polkadot et des fonctions de transition d'état. Tout se passe au sein du cœur et de la couche de disponibilité des données.
Enfin, une petite partie du dernier état de Layer2 sera visible sur la chaîne de relais principale de Polkadot. Contrairement à toutes les opérations précédentes, cette opération est beaucoup moins chère que de réexécuter réellement le bloc Layer2, elle affectera l'état principal de Polkadot, sera visible dans le bloc Polkadot et sera exécutée par tous les validateurs de Polkadot.
À partir du contenu ci-dessus, nous pouvons discuter de certaines des actions que Polkadot est en train d'exécuter :
Tout d'abord, à partir de l'étape 1, nous pouvons conclure qu'il existe un nouveau mode d'exécution dans Polkadot qui diffère de la fonction de transition d'état de la blockchain traditionnelle. Normalement, lorsque tous les validateurs du réseau effectuent un travail, l'état de la chaîne principale est mis à jour. Nous appelons cela une opération hors-chaîne (on-chain operation), c'est ce qui se passe à l'étape 3. Cependant, ce qui se passe à l'intérieur du noyau (étape 1) est différent. Nous appelons cela une exécution interne du noyau (in-core execution).
Ensuite, à partir du point 2, nous pouvons déduire que Polkadot a déjà fourni une couche de disponibilité des données native (Data-Availability, ci-après DA), et que Layer2 l'utilise automatiquement pour garantir que ses preuves d'exécution sont disponibles pendant un certain temps. Cependant, les blocs de données pouvant être publiés sur cette couche DA sont fixes, et ils sont toujours les preuves requises pour exécuter à nouveau le Bloc Layer2. De plus, le code de la parachain n'a jamais lu les données de la couche DA.
Comprendre le contenu ci-dessus est la base de la compréhension de JAM. Résumé ci-dessous:
Exécution en interne du CORE (in-core ution) : se réfère aux opérations effectuées à l'intérieur du CORE. Elle se caractérise par sa richesse, sa scalabilité, et assure la même sécurité que l'exécution off-chain grâce à l'économie cryptographique et à ELVES.
Avec une compréhension préalable de la première partie, nous pouvons facilement passer à la présentation de JAM.
JAM est un nouveau protocole inspiré de Polkadot et entièrement compatible avec lui, conçu pour remplacer le relais de chaîne de Polkadot et rendre l'utilisation principale complètement décentralisée et illimitée.
JAM est construit sur Polkadot2 dans le but de rendre le cœur de Polkadot plus accessible, mais de manière plus flexible et sans restrictions fixes par rapport à agile-coretime.
Polkadot2 rend le déploiement de Layer2 plus flexible au niveau central.
JAM vise à permettre à n'importe quelle application de se déployer sur Polkadot, même si ces applications ne sont pas comme des blockchains ou des Layer2.
Cela est principalement réalisé en exposant aux développeurs les trois principaux concepts primitifs discutés précédemment : l'exécution on-chain, l'exécution hors-chaine et la couche DA.
En d'autres termes, dans JAM, les développeurs peuvent accéder à :
Complètement Programmabilité化核心内和off-chain的工作。
Autoriser l'écriture et la lecture de données arbitraires dans la couche DA de Polkadot.
Il s'agit d'une description de base du protocole JAM. Pas besoin de trop parler, beaucoup de simplifications ont été faites ici et le protocole pourrait encore évoluer.
Avec cette compréhension de base, nous pouvons maintenant explorer plus en détail certains aspects de JAM dans les prochains chapitres.
1 Service et éléments de travail
Dans le contexte de JAM, ce qui était autrefois appelé Layer2/parachain est maintenant appelé « service », ce qui était autrefois appelé Bloc/transaction est maintenant appelé « élément de travail » ou « lot de travail ». Plus précisément, un élément de travail fait partie d'un service, tandis qu'un lot de travail est un ensemble d'éléments de travail. Ces termes ont été délibérément conçus pour être suffisamment génériques pour couvrir une variété de cas d'utilisation au-delà de la chaîne Bloc / Layer2.
Un service est décrit par trois points d'entrée, dont deux sont respectivement fn refine() et fn accumulate(). Le premier décrit le contenu exécuté dans le cœur du service, le second décrit le contenu exécuté off-chain.
Enfin, le nom des deux points d'entrée est également appelé protocole JAM (Join Accumulate Machine). Join se réfère à fn refine(), qui est appelé Join lorsque tous les cœurs Polkadot traitent en parallèle une grande quantité de travail pour différents services. Les données sont filtrées avant de passer à la prochaine étape. Accumulate fait référence au processus d'accumulation de tous les résultats mentionnés ci-dessus dans l'état principal JAM, c'est-à-dire la partie off-chain.
Les éléments de travail peuvent spécifier précisément le code à exécuter à l'intérieur du cœur, hors de la chaîne, et indiquer comment / si / où lire et écrire le contenu du lac de données distribué (Distributed Data Lake).
2 Semi-consistence
En examinant les informations existantes sur XCM (le langage de communication parachain choisi par Polkadot), toutes les communications sont asynchrones (voir les détails ici:). Autrement dit, il n'est pas possible d'attendre une réponse après l'envoi d'un message.
L'asynchronisme est une manifestation d'incohérence du système et constitue le principal inconvénient des systèmes de Sharding permanents tels que Polkadot 1 et Polkadot 2, ainsi que de l'écosystème Layer2 existant d'ETH.
Cependant, comme décrit dans la section 2.4 du livre blanc, un système entièrement cohérent qui reste synchronisé pour tous ses locataires ne peut hausser qu'à un certain niveau sans compromettre l'universalité, l'accessibilité ou l'élasticité. (Voir plus: )
C'est également un autre domaine dans lequel JAM se distingue : en introduisant diverses fonctionnalités, JAM parvient à un nouvel état intermédiaire, à savoir un système de semi-consistance. Dans ce système, les sous-systèmes en communication fréquente ont la possibilité de créer un environnement cohérent entre eux, sans contraindre l'ensemble du système à rester cohérent. Cela a été le mieux décrit par le Dr Gavin Wood, auteur du livre gris, dans une interview : (voir détails :_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Une autre façon de comprendre est de considérer Polkadot / JAM comme un système de Sharding, où les frontières de ces Sharding sont fluides et dynamiquement déterminées.
Polkadot a toujours été Sharding, et complètement hétérogène.
Maintenant, il sera fragmenté et hétérogène, et les frontières de ces fragments peuvent être flexibles, comme le système de « semi-consistance » que Gavin Wood a appelé sur Twitter (voir détails : _src=twsrc%5Etfw, ).
Les fonctionnalités qui rendent tout cela possible incluent :
Accès à une exécution de noyau sans état et parallèle, où différents services ne peuvent interagir de manière synchrone qu'avec d'autres services dans le même noyau et dans un Bloc spécifique, ainsi qu'une exécution off-chain, où les services peuvent accéder aux résultats de tous les services sur tous les noyaux.
JAM ne force l'exécution d'aucune planification de service spécifique. Les services avec une communication fréquente peuvent fournir des incitations économiques à leurs planificateurs, créant des lots de travail contenant ces services de communication fréquents. Cela permet à ces services de s'exécuter sur le même cœur, avec une communication entre eux comme s'ils étaient dans un environnement synchrone.
De plus, le service JAM peut accéder à la couche de données DA et l'utiliser comme une couche de données temporaire mais extrêmement bon marché. Une fois que les données sont placées dans DA, elles se propagent finalement à tous les cœurs, mais sont immédiatement disponibles dans le même cœur. Par conséquent, le service JAM peut bénéficier d'un accès aux données de niveau supérieur en planifiant son propre calendrier dans le même cœur dans des blocs consécutifs.
Il convient de noter que bien que ce qui précède soit possible dans JAM, il n'est pas obligatoire au niveau de la couche de protocole. Par conséquent, il est prévu que certaines interfaces soient théoriquement asynchrones, mais grâce à des abstractions astucieuses et des incitations, elles peuvent se comporter de manière synchrone en pratique. La prochaine section discutera de CorePlay, qui est un exemple de ce cas.
3 CorePlay
Cette section présente CorePlay, une idée expérimentale dans l'environnement JAM, qui peut être décrite comme un nouveau modèle de programmation de smart contracts. Au moment de la rédaction de cet article, CorePlay n'a pas encore été expliqué en détail et reste une hypothèse.
Pour comprendre CorePlay, nous devons d'abord présenter la Machine virtuelle choisie par JAM : PVM.
4 PVM
PVM est un détail important dans JAM et CorePlay. Les détails de bas niveau de PVM dépassent le cadre de cet article, il est préférable de consulter la description des experts du domaine dans le livre blanc. Cependant, pour les besoins de cet article, nous devons simplement expliquer quelques attributs de PVM :
Mesure efficace
La capacité de suspendre et de reprendre l'exécution
Cela est particulièrement important pour CorePlay.
CorePlay est un exemple de création d’un environnement de Smart Contract synchrone et extensible à l’aide des primitives flexibles de JAM, avec une interface de programmation très flexible. CorePlay recommande de déployer des contrats intelligents basés sur des acteurs directement sur les cœurs JAM, ce qui leur permet de profiter d’une interface de programmation synchrone où ils peuvent être écrits comme des fn main() normaux et communiqués via let_result=other_coreplay_actor(data).await ?. Si d’autres_coreplay_actor se trouvent sur le cœur dans le même bloc JAM, l’appel est synchrone ; S’il est sur un autre cœur, l’acteur est mis en pause et repris dans un bloc JAM suivant. Cela est rendu possible précisément par le service JAM et sa planification flexible, ainsi que par la nature de PVM.
5 CoreChains service
Enfin, permettez-nous de résumer les principales raisons pour lesquelles JAM est entièrement compatible avec Polkadot. Le principal produit de Polkadot est les parachains qui fonctionnent selon le principe du temps de base agile, et ce produit est également présent dans JAM.
Les services déployés en premier dans JAM pourraient être appelés CoreChains ou Parachains. Ce service permettra aux parachains existantes de style Polkadot -2 de fonctionner sur JAM.
Les services supplémentaires peuvent être déployés sur JAM et les services CoreChains existants peuvent communiquer avec eux, mais les produits existants de Polkadot resteront robustes et ne feront que ouvrir de nouvelles portes aux équipes de Parachain existantes.
Annexe : Sharding de données
Une grande partie de cet article examine la scalabilité du point de vue de l'exécution du Sharding. Nous pouvons également aborder le même problème du point de vue des données. Il est intéressant de noter que cela ressemble à la situation de semi-consistance mentionnée précédemment : en principe, un système complètement cohérent est préférable mais il n'est pas extensible ; un système complètement incohérent est extensible mais il n'est pas idéal, et JAM propose une nouvelle possibilité avec son modèle de semi-consistance.
Système de conformité totale : Ceci est ce que nous voyons sur une plate-forme de contrat intelligent entièrement synchronisée, telle que Solana ou celles qui sont courageusement déployées uniquement sur la couche 1 de l'ETH. Toutes les données d'application sont stockées hors chaîne et peuvent être facilement accessibles à toutes les autres applications. C'est une propriété parfaitement programmable mais non évolutive.
Système incohérent : les données d'application sont stockées en dehors de la couche 1 et dans des Sharding différents et isolés. Très extensible, mais de mauvaise performance en termes de combinaison. Le modèle Rollup de Polkadot et d'Ethereum relève de ce cas de figure.
En plus des deux fonctionnalités mentionnées ci-dessus, JAM permet également aux développeurs de publier des données arbitraires sur la couche JAM DA, ce qui constitue en quelque sorte une zone intermédiaire entre les données hors chaîne et les données hors chaîne. Il est possible de créer de nouvelles applications qui utilisent la majeure partie des données d'application de la couche DA, en ne persistant que les données essentielles absolues dans l'état JAM.
Annexe : Carte de l'espace de scalabilité
Cette section réinterprète notre point de vue sur le domaine de la scalability de la blockchain. Cela est également expliqué dans le livre blanc, et une version plus concise est fournie ici.
La scalabilité de la blockchain suit largement les méthodes utilisées dans les systèmes distribués traditionnels : l'évolutivité verticale (scaling up) et l'évolutivité horizontale (scaling out).
L'extension vers le haut est le travail effectué par des plateformes telles que Solana. Il s'agit d'optimiser au maximum le code et le matériel pour atteindre un débit maximal.
L'extension vers l'extérieur est une stratégie adoptée par Ethereum et Polkadot: réduire la charge de travail de chaque personne. Dans les systèmes distribués traditionnels, cela est réalisé en ajoutant plus de machines de réplication. Dans la chaîne de Bloc, les « ordinateurs » sont l'ensemble des validateurs du réseau. En leur attribuant du travail entre eux (comme le fait ELVES), ou en réduisant de manière optimiste leurs responsabilités (comme le font les Rollups optimistes), nous réduisons la charge de travail de l'ensemble des validateurs, ce qui permet l'extension vers l'extérieur du système.
Dans la chaîne de blocs, l'expansion vers l'extérieur est similaire à la «réduction du nombre de machines nécessaires à l'exécution de toutes les opérations».
Résumé:
Extension vers le haut : optimisation de la blockchain monolithique + matériel haute performance.
Expansion externe :
Rollups optimistes
Rollups basés sur SNARK
ELVES: La satire de Polkadot Rollups (Rollups cyniques)
Annexe: Même matériel, mise à jour du noyau
Cette section, basée sur l'analogie fournie par Rob Habermeier dans Sub02023 : Polkadot : Noyau/Espace utilisateur | Sub02023-YouTube (voir détails : ), présente JAM comme une mise à niveau de Polkadot : une mise à jour du noyau sur le même matériel.
Dans un ordinateur typique, nous pouvons diviser toute la pile en trois parties :
Matériel
2.Noyau
Espace utilisateur
Dans Polkadot, le matériel, c'est-à-dire l'essence qui fournit le calcul et la disponibilité des données, a toujours été au cœur des cœurs, comme mentionné précédemment.
Dans Polkadot, le noyau est en fait[9]Jusqu'à présent, cela comprend deux parties :
parachain (Parachains) protocole: une manière d'utiliser le cœur de manière opinionée et fixe.
Un ensemble de fonctionnalités de base telles que DOT Jeton et leur transférabilité, stake, gouvernance, etc.
Les deux existent tous deux sur la chaîne de relais de Polkadot (Relay Chain).
Les applications d'espace utilisateur sont des instances de parachains, leurs jetons natifs et tout autre contenu construit dessus.
Nous pouvons visualiser ce processus comme suit :
Polkadot a toujours envisagé de déplacer davantage de fonctionnalités essentielles vers un type spécifique d'utilisateur - parachain. C'est précisément l'objectif que vise le Minimal Relay RFC. (Voir détails : )
Cela signifie que la chaîne de relais Polkadot ne traite que les parachainprotocoles fournis, ce qui réduit dans une certaine mesure l'espace du noyau.
Une fois cette architecture mise en place, il sera plus facile de visualiser la migration vers JAM. JAM réduira considérablement l'espace du noyau de Polkadot, le rendant plus polyvalent. De plus, le protocole de Parachains sera déplacé vers l'espace utilisateur, car c'est l'une des rares façons de développer des applications sur le même cœur (matériel) et noyau (JAM).
Cela montre une fois de plus pourquoi JAM n'est qu'une alternative à la chaîne de relais de Polkadot, et non une alternative à la parachain.
En d'autres termes, nous pouvons considérer la migration de JAM comme une mise à niveau du noyau. Le matériel sous-jacent reste inchangé, la plupart du contenu de l'ancien noyau est déplacé vers l'espace utilisateur pour simplifier le système.
Si vous souhaitez participer à la discussion de cet article, n'hésitez pas à exprimer votre opinion dans le forum :
Pour savoir comment participer aux discussions sur le forum, veuillez consulter notre guide d'utilisation du forum Polkadot que nous avons publié :
« Comment participer aux discussions sur Polkadot : Guide d'utilisation du forum officiel de Polkadot »
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Découvrez le JAM de Polkadot du point de vue technique
Auteur: Kian Paimani, développeur principal de Parity
Compilation : Polkadot Labs
"Le schéma de connaissances de Polkadot"* est notre article d'initiation à partir de zéro pour Polkadot. Nous essayons de partir des bases les plus fondamentales de Polkadot pour fournir à tous une compréhension complète de Polkadot. Bien sûr, c'est un projet énorme et plein de défis, mais nous espérons, à travers cet effort, que chacun pourra avoir une compréhension correcte de Polkadot, et que ceux qui ne le connaissent pas pourront rapidement en acquérir une connaissance approfondie.**** Aujourd'hui marque la 148ème édition de cette rubrique, et cet article est une interprétation technique du protocole JAM le plus récent de Polkadot par Kian Paimani, un développeur principal de Parity, visant à aider les gens à mieux comprendre comment JAM apporte une nouvelle extensibilité à l'écosystème de Polkadot. Cet article est écrit du point de vue de l'auteur.
*Voici une explication détaillée de Polkadot1, Polkadot2 et de leur évolution vers JAM. (Voir les détails sur ***). Ce document s'adresse aux lecteurs techniques, en particulier à ceux qui ne sont pas très familiers avec Polkadot mais qui ont une certaine connaissance des systèmes de blockchain et qui peuvent avoir une compréhension des technologies connexes dans d'autres écosystèmes.
*Avant de lire le livre blanc JAM, je pense que c'est une bonne prélude à la lecture de cet article. (Voir détails: ***)
Connaissances de base
Ce document suppose que le lecteur est familier avec les concepts suivants:
Introduction: Polkadot1
Tout d'abord, revenons sur ce que je considère comme la caractéristique la plus innovante de Polkadot1.
Niveau social:
Au niveau technique :
Pour plus d'informations sur le "Sharding hétérogène", veuillez vous référer aux sections correspondantes.
Sharding : ce qu’il faut retenir
Actuellement, nous discutons d'un réseau de couche 1 qui héberge d'autres réseaux de couche 2 "blockchain", similaire à Polkadot et Ethereum. Ainsi, les termes couche 2 et chaîne parallèle (Parachain) peuvent être utilisés de manière interchangeable.
Le problème central de l'évolutivité de la chaîne de Bloc peut être décrit comme suit : il existe un groupe de validateurs qui peuvent garantir la fiabilité de l'exécution de certains codes via l'économie cryptographique de Preuve d'enjeu (Proof-of-Stake). Par défaut, ces validateurs doivent réexécuter tout le travail les uns des autres. Par conséquent, tant que nous obligeons tous les validateurs à réexécuter tout le travail tout le temps, le système entier ne peut pas être mis à l'échelle.
Veuillez noter que l'augmentation du nombre de validateurs dans ce modèle ne permettra pas réellement d'augmenter le débit du système tant que le principe absolu de réexécution susmentionné reste inchangé.
Ce qui est présenté ci-dessus est une chaîne de blocs mono (par opposition à une chaîne de blocs fragmentée). Tous les validateurs du réseau traiteront chaque entrée (c'est-à-dire chaque bloc) un par un.
Dans un tel système, si la couche 1 veut héberger plus de couche 2, alors tous les validateurs devront maintenant réexécuter tout le travail de la couche 2. Évidemment, cette approche n’est pas évolutive. Les cumuls optimistes sont un moyen de contourner ce problème, car la preuve de la fraude n’est réexécutée que si quelqu’un prétend qu’une fraude a eu lieu. Les cumuls basés sur SNARK contournent ce problème en tirant parti du fait que le coût de vérification d’une preuve SNARK est beaucoup plus faible que celui de sa génération, il est donc logique de permettre à tous les validateurs de valider les preuves SNARK. Pour plus d’informations à ce sujet, consultez l’annexe : Diagramme spatial d’évolutivité.
Une solution simple pour Sharding est de simplement diviser l'ensemble des validateurs en plus petits sous-ensembles et de permettre à ces sous-ensembles plus petits d'exécuter à nouveau le Bloc de la couche 2. Quels sont les problèmes avec cette méthode? Nous effectuons le Sharding de l'exécution du réseau et de sa sécurité économique. La sécurité de cette couche 2 est inférieure à celle de la couche 1, et plus nous divisons l'ensemble des validateurs en plusieurs Shardings, plus sa sécurité sera réduite.
Contrairement à Optimistic Rollups, qui ne peut pas être réexécuté en permanence, Polkadot a pris en compte l'exécution de Sharding lors de sa conception, ce qui permet à certains validateurs de réexécuter le bloc de la couche 2 tout en fournissant suffisamment de preuves économiques cryptographiques à tous les participants du réseau pour prouver l'authenticité de ce bloc de la couche 2 et sa sécurité lorsqu'il est réexécuté par l'ensemble des validateurs. Ceci est réalisé par le biais d'un mécanisme novateur (récemment publié officiellement) appelé ELVES (voir détails: 01928374656574839201).
En bref, ELVES peut être considéré comme un mécanisme de type "Rollups de suspicion". En demandant activement à d'autres validateurs si un bloc Layer2 est valide pendant plusieurs tours, nous pouvons confirmer avec une grande probabilité la validité de ce bloc Layer2. En fait, en cas de litige, l'ensemble des validateurs sera rapidement requis. Rob Habermeier, co-fondateur de Polkadot, a expliqué cela en détail dans un article (voir: ).
ELVES permet à Polkadot d'avoir simultanément deux propriétés auparavant considérées comme mutuellement exclusives : "Sharding" et "sécurité partagée". Il s'agit là de la principale réalisation technologique de Polkadot1 en matière de scalabilité.
Maintenant, continuons la discussion sur la comparaison avec "CORE".
Un réseau Bloc qui exécute le Sharding ressemble beaucoup à un CPU : tout comme un CPU peut avoir plusieurs cœurs pour exécuter des instructions en parallèle, Polkadot peut traiter en parallèle les Bloc de la couche 2. C'est pourquoi la couche 2 sur Polkadot est appelée parachain, et l'environnement où un sous-ensemble plus restreint de validateurs re-exécute un seul Bloc de la couche 2 est appelé « CORE ». Chaque CORE peut être abstrait comme un « groupe de validateurs collaborant ».
Vous pouvez imaginer une chaîne de blocs individuelle comme ne capturant qu'un bloc à tout moment pendant une période de temps donnée, tandis que Polkadot capture un bloc de chaîne de relais et un bloc de chaîne parallèle pour chaque noyau à chaque période de temps.
Hétérogénéité
Jusqu'à présent, nous avons seulement discuté de la scalabilité et de l'exécution de Sharding offerts par Polkadot. Il convient de noter que chaque Sharding de Polkadot est en réalité une application complètement différente. Cela est réalisé en utilisant un protocole métier stocké en bytecode : une manière de stocker la définition de la chaîne de blocs en tant que bytecode dans l'état de la chaîne de blocs elle-même. Dans Polkadot 1.0, le WASM est utilisé comme bytecode préféré, tandis que le PVM/RISC-V est utilisé dans JAM.
En résumé, c'est pourquoi Polkadot est appelé une blockchain à fragments hétérogènes. (Voir les détails à: 01928374656574839201) Chaque couche 2 est une application totalement différente.
Polkadot2
Une partie importante de Polkadot2 est de rendre l'utilisation du noyau plus flexible. Dans le modèle Polkadot d'origine, la durée de location du noyau peut varier de 6 mois à 2 ans, ce qui convient aux entreprises riches en ressources, mais pas aux petites équipes. La fonctionnalité qui permet au noyau Polkadot d'être utilisé de manière plus flexible est appelée "agile coretime". (Voir les détails:) Dans ce mode, la durée de location du noyau Polkadot peut être aussi courte qu'un Bloc, ou aussi longue qu'un mois, et offre une garantie de prix maximum pour les utilisateurs qui souhaitent louer à long terme.
Les autres fonctionnalités de Polkadot 2 sont en cours de discussion et seront progressivement dévoilées, il n'est donc pas nécessaire d'en dire plus ici.
Les opérations internes du noyau et hors chaîne
Pour comprendre JAM, il faut d'abord comprendre ce qui se passe lorsqu'un Bloc Layer2 entre dans le cœur de Polkadot.
Le contenu suivant a été considérablement simplifié.
En résumé, le noyau est principalement composé d'un groupe de validateurs. Ainsi, lorsque nous disons que les données sont envoyées au noyau, il s'agit en fait de ces données étant transmises à ce groupe de validateurs.
Un bloc Layer2 ainsi qu'une partie de l'état de ce Layer2 sont envoyés au cœur. Ces données contiennent toutes les informations nécessaires à l'exécution de ce bloc Layer2.
Certains validateurs au sein du noyau re-exécuteront les Blocs de la couche 2 et continueront à traiter les tâches liées au Consensus.
Les validateurs principaux fourniront à nouveau les données nécessaires aux autres validateurs (à l'extérieur du noyau). Les autres validateurs peuvent décider en fonction des règles ELVES s'ils doivent ou non réexécuter ce bloc de couche 2, et ils ont besoin de ces données pour le faire.
Attention, jusqu'à présent, toutes les opérations se sont déroulées en dehors du bloc principal de Polkadot et des fonctions de transition d'état. Tout se passe au sein du cœur et de la couche de disponibilité des données.
À partir du contenu ci-dessus, nous pouvons discuter de certaines des actions que Polkadot est en train d'exécuter :
Tout d'abord, à partir de l'étape 1, nous pouvons conclure qu'il existe un nouveau mode d'exécution dans Polkadot qui diffère de la fonction de transition d'état de la blockchain traditionnelle. Normalement, lorsque tous les validateurs du réseau effectuent un travail, l'état de la chaîne principale est mis à jour. Nous appelons cela une opération hors-chaîne (on-chain operation), c'est ce qui se passe à l'étape 3. Cependant, ce qui se passe à l'intérieur du noyau (étape 1) est différent. Nous appelons cela une exécution interne du noyau (in-core execution).
Ensuite, à partir du point 2, nous pouvons déduire que Polkadot a déjà fourni une couche de disponibilité des données native (Data-Availability, ci-après DA), et que Layer2 l'utilise automatiquement pour garantir que ses preuves d'exécution sont disponibles pendant un certain temps. Cependant, les blocs de données pouvant être publiés sur cette couche DA sont fixes, et ils sont toujours les preuves requises pour exécuter à nouveau le Bloc Layer2. De plus, le code de la parachain n'a jamais lu les données de la couche DA.
Comprendre le contenu ci-dessus est la base de la compréhension de JAM. Résumé ci-dessous:
JAM
Avec une compréhension préalable de la première partie, nous pouvons facilement passer à la présentation de JAM.
JAM est un nouveau protocole inspiré de Polkadot et entièrement compatible avec lui, conçu pour remplacer le relais de chaîne de Polkadot et rendre l'utilisation principale complètement décentralisée et illimitée.
JAM est construit sur Polkadot2 dans le but de rendre le cœur de Polkadot plus accessible, mais de manière plus flexible et sans restrictions fixes par rapport à agile-coretime.
Cela est principalement réalisé en exposant aux développeurs les trois principaux concepts primitifs discutés précédemment : l'exécution on-chain, l'exécution hors-chaine et la couche DA.
En d'autres termes, dans JAM, les développeurs peuvent accéder à :
Il s'agit d'une description de base du protocole JAM. Pas besoin de trop parler, beaucoup de simplifications ont été faites ici et le protocole pourrait encore évoluer.
Avec cette compréhension de base, nous pouvons maintenant explorer plus en détail certains aspects de JAM dans les prochains chapitres.
1 Service et éléments de travail
Dans le contexte de JAM, ce qui était autrefois appelé Layer2/parachain est maintenant appelé « service », ce qui était autrefois appelé Bloc/transaction est maintenant appelé « élément de travail » ou « lot de travail ». Plus précisément, un élément de travail fait partie d'un service, tandis qu'un lot de travail est un ensemble d'éléments de travail. Ces termes ont été délibérément conçus pour être suffisamment génériques pour couvrir une variété de cas d'utilisation au-delà de la chaîne Bloc / Layer2.
Un service est décrit par trois points d'entrée, dont deux sont respectivement fn refine() et fn accumulate(). Le premier décrit le contenu exécuté dans le cœur du service, le second décrit le contenu exécuté off-chain.
Enfin, le nom des deux points d'entrée est également appelé protocole JAM (Join Accumulate Machine). Join se réfère à fn refine(), qui est appelé Join lorsque tous les cœurs Polkadot traitent en parallèle une grande quantité de travail pour différents services. Les données sont filtrées avant de passer à la prochaine étape. Accumulate fait référence au processus d'accumulation de tous les résultats mentionnés ci-dessus dans l'état principal JAM, c'est-à-dire la partie off-chain.
Les éléments de travail peuvent spécifier précisément le code à exécuter à l'intérieur du cœur, hors de la chaîne, et indiquer comment / si / où lire et écrire le contenu du lac de données distribué (Distributed Data Lake).
2 Semi-consistence
En examinant les informations existantes sur XCM (le langage de communication parachain choisi par Polkadot), toutes les communications sont asynchrones (voir les détails ici:). Autrement dit, il n'est pas possible d'attendre une réponse après l'envoi d'un message.
L'asynchronisme est une manifestation d'incohérence du système et constitue le principal inconvénient des systèmes de Sharding permanents tels que Polkadot 1 et Polkadot 2, ainsi que de l'écosystème Layer2 existant d'ETH.
Cependant, comme décrit dans la section 2.4 du livre blanc, un système entièrement cohérent qui reste synchronisé pour tous ses locataires ne peut hausser qu'à un certain niveau sans compromettre l'universalité, l'accessibilité ou l'élasticité. (Voir plus: )
Synchronisation ≈ cohérence||Incohérences ≈ asynchrones
C'est également un autre domaine dans lequel JAM se distingue : en introduisant diverses fonctionnalités, JAM parvient à un nouvel état intermédiaire, à savoir un système de semi-consistance. Dans ce système, les sous-systèmes en communication fréquente ont la possibilité de créer un environnement cohérent entre eux, sans contraindre l'ensemble du système à rester cohérent. Cela a été le mieux décrit par le Dr Gavin Wood, auteur du livre gris, dans une interview : (voir détails :_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ)
Une autre façon de comprendre est de considérer Polkadot / JAM comme un système de Sharding, où les frontières de ces Sharding sont fluides et dynamiquement déterminées.
Polkadot a toujours été Sharding, et complètement hétérogène.
Maintenant, il sera fragmenté et hétérogène, et les frontières de ces fragments peuvent être flexibles, comme le système de « semi-consistance » que Gavin Wood a appelé sur Twitter (voir détails : _src=twsrc%5Etfw, ).
Les fonctionnalités qui rendent tout cela possible incluent :
Accès à une exécution de noyau sans état et parallèle, où différents services ne peuvent interagir de manière synchrone qu'avec d'autres services dans le même noyau et dans un Bloc spécifique, ainsi qu'une exécution off-chain, où les services peuvent accéder aux résultats de tous les services sur tous les noyaux.
JAM ne force l'exécution d'aucune planification de service spécifique. Les services avec une communication fréquente peuvent fournir des incitations économiques à leurs planificateurs, créant des lots de travail contenant ces services de communication fréquents. Cela permet à ces services de s'exécuter sur le même cœur, avec une communication entre eux comme s'ils étaient dans un environnement synchrone.
De plus, le service JAM peut accéder à la couche de données DA et l'utiliser comme une couche de données temporaire mais extrêmement bon marché. Une fois que les données sont placées dans DA, elles se propagent finalement à tous les cœurs, mais sont immédiatement disponibles dans le même cœur. Par conséquent, le service JAM peut bénéficier d'un accès aux données de niveau supérieur en planifiant son propre calendrier dans le même cœur dans des blocs consécutifs.
Il convient de noter que bien que ce qui précède soit possible dans JAM, il n'est pas obligatoire au niveau de la couche de protocole. Par conséquent, il est prévu que certaines interfaces soient théoriquement asynchrones, mais grâce à des abstractions astucieuses et des incitations, elles peuvent se comporter de manière synchrone en pratique. La prochaine section discutera de CorePlay, qui est un exemple de ce cas.
3 CorePlay
Cette section présente CorePlay, une idée expérimentale dans l'environnement JAM, qui peut être décrite comme un nouveau modèle de programmation de smart contracts. Au moment de la rédaction de cet article, CorePlay n'a pas encore été expliqué en détail et reste une hypothèse.
Pour comprendre CorePlay, nous devons d'abord présenter la Machine virtuelle choisie par JAM : PVM.
4 PVM
PVM est un détail important dans JAM et CorePlay. Les détails de bas niveau de PVM dépassent le cadre de cet article, il est préférable de consulter la description des experts du domaine dans le livre blanc. Cependant, pour les besoins de cet article, nous devons simplement expliquer quelques attributs de PVM :
Cela est particulièrement important pour CorePlay.
CorePlay est un exemple de création d’un environnement de Smart Contract synchrone et extensible à l’aide des primitives flexibles de JAM, avec une interface de programmation très flexible. CorePlay recommande de déployer des contrats intelligents basés sur des acteurs directement sur les cœurs JAM, ce qui leur permet de profiter d’une interface de programmation synchrone où ils peuvent être écrits comme des fn main() normaux et communiqués via let_result=other_coreplay_actor(data).await ?. Si d’autres_coreplay_actor se trouvent sur le cœur dans le même bloc JAM, l’appel est synchrone ; S’il est sur un autre cœur, l’acteur est mis en pause et repris dans un bloc JAM suivant. Cela est rendu possible précisément par le service JAM et sa planification flexible, ainsi que par la nature de PVM.
5 CoreChains service
Enfin, permettez-nous de résumer les principales raisons pour lesquelles JAM est entièrement compatible avec Polkadot. Le principal produit de Polkadot est les parachains qui fonctionnent selon le principe du temps de base agile, et ce produit est également présent dans JAM.
Les services déployés en premier dans JAM pourraient être appelés CoreChains ou Parachains. Ce service permettra aux parachains existantes de style Polkadot -2 de fonctionner sur JAM.
Les services supplémentaires peuvent être déployés sur JAM et les services CoreChains existants peuvent communiquer avec eux, mais les produits existants de Polkadot resteront robustes et ne feront que ouvrir de nouvelles portes aux équipes de Parachain existantes.
Annexe : Sharding de données
Une grande partie de cet article examine la scalabilité du point de vue de l'exécution du Sharding. Nous pouvons également aborder le même problème du point de vue des données. Il est intéressant de noter que cela ressemble à la situation de semi-consistance mentionnée précédemment : en principe, un système complètement cohérent est préférable mais il n'est pas extensible ; un système complètement incohérent est extensible mais il n'est pas idéal, et JAM propose une nouvelle possibilité avec son modèle de semi-consistance.
Système de conformité totale : Ceci est ce que nous voyons sur une plate-forme de contrat intelligent entièrement synchronisée, telle que Solana ou celles qui sont courageusement déployées uniquement sur la couche 1 de l'ETH. Toutes les données d'application sont stockées hors chaîne et peuvent être facilement accessibles à toutes les autres applications. C'est une propriété parfaitement programmable mais non évolutive.
Système incohérent : les données d'application sont stockées en dehors de la couche 1 et dans des Sharding différents et isolés. Très extensible, mais de mauvaise performance en termes de combinaison. Le modèle Rollup de Polkadot et d'Ethereum relève de ce cas de figure.
En plus des deux fonctionnalités mentionnées ci-dessus, JAM permet également aux développeurs de publier des données arbitraires sur la couche JAM DA, ce qui constitue en quelque sorte une zone intermédiaire entre les données hors chaîne et les données hors chaîne. Il est possible de créer de nouvelles applications qui utilisent la majeure partie des données d'application de la couche DA, en ne persistant que les données essentielles absolues dans l'état JAM.
Annexe : Carte de l'espace de scalabilité
Cette section réinterprète notre point de vue sur le domaine de la scalability de la blockchain. Cela est également expliqué dans le livre blanc, et une version plus concise est fournie ici.
La scalabilité de la blockchain suit largement les méthodes utilisées dans les systèmes distribués traditionnels : l'évolutivité verticale (scaling up) et l'évolutivité horizontale (scaling out).
L'extension vers le haut est le travail effectué par des plateformes telles que Solana. Il s'agit d'optimiser au maximum le code et le matériel pour atteindre un débit maximal.
L'extension vers l'extérieur est une stratégie adoptée par Ethereum et Polkadot: réduire la charge de travail de chaque personne. Dans les systèmes distribués traditionnels, cela est réalisé en ajoutant plus de machines de réplication. Dans la chaîne de Bloc, les « ordinateurs » sont l'ensemble des validateurs du réseau. En leur attribuant du travail entre eux (comme le fait ELVES), ou en réduisant de manière optimiste leurs responsabilités (comme le font les Rollups optimistes), nous réduisons la charge de travail de l'ensemble des validateurs, ce qui permet l'extension vers l'extérieur du système.
Dans la chaîne de blocs, l'expansion vers l'extérieur est similaire à la «réduction du nombre de machines nécessaires à l'exécution de toutes les opérations».
Résumé:
Annexe: Même matériel, mise à jour du noyau
Cette section, basée sur l'analogie fournie par Rob Habermeier dans Sub02023 : Polkadot : Noyau/Espace utilisateur | Sub02023-YouTube (voir détails : ), présente JAM comme une mise à niveau de Polkadot : une mise à jour du noyau sur le même matériel.
Dans un ordinateur typique, nous pouvons diviser toute la pile en trois parties :
2.Noyau
Dans Polkadot, le matériel, c'est-à-dire l'essence qui fournit le calcul et la disponibilité des données, a toujours été au cœur des cœurs, comme mentionné précédemment.
Dans Polkadot, le noyau est en fait[9]Jusqu'à présent, cela comprend deux parties :
parachain (Parachains) protocole: une manière d'utiliser le cœur de manière opinionée et fixe.
Un ensemble de fonctionnalités de base telles que DOT Jeton et leur transférabilité, stake, gouvernance, etc.
Les deux existent tous deux sur la chaîne de relais de Polkadot (Relay Chain).
Les applications d'espace utilisateur sont des instances de parachains, leurs jetons natifs et tout autre contenu construit dessus.
Nous pouvons visualiser ce processus comme suit :
Polkadot a toujours envisagé de déplacer davantage de fonctionnalités essentielles vers un type spécifique d'utilisateur - parachain. C'est précisément l'objectif que vise le Minimal Relay RFC. (Voir détails : )
Cela signifie que la chaîne de relais Polkadot ne traite que les parachainprotocoles fournis, ce qui réduit dans une certaine mesure l'espace du noyau.
Une fois cette architecture mise en place, il sera plus facile de visualiser la migration vers JAM. JAM réduira considérablement l'espace du noyau de Polkadot, le rendant plus polyvalent. De plus, le protocole de Parachains sera déplacé vers l'espace utilisateur, car c'est l'une des rares façons de développer des applications sur le même cœur (matériel) et noyau (JAM).
Cela montre une fois de plus pourquoi JAM n'est qu'une alternative à la chaîne de relais de Polkadot, et non une alternative à la parachain.
En d'autres termes, nous pouvons considérer la migration de JAM comme une mise à niveau du noyau. Le matériel sous-jacent reste inchangé, la plupart du contenu de l'ancien noyau est déplacé vers l'espace utilisateur pour simplifier le système.
Si vous souhaitez participer à la discussion de cet article, n'hésitez pas à exprimer votre opinion dans le forum :
Pour savoir comment participer aux discussions sur le forum, veuillez consulter notre guide d'utilisation du forum Polkadot que nous avons publié :
« Comment participer aux discussions sur Polkadot : Guide d'utilisation du forum officiel de Polkadot »