Ce qui suit est une explication détaillée de Polkadot1, Polkadot2, et comment ils ont évolué en JAM. (Pour plus de détails, voir:https://www.navalmanack.com/almanack-of-naval-ravikant/how-to-think-clearly. Cet article s'adresse aux lecteurs techniques, en particulier à ceux qui ne sont peut-être pas profondément familiers avec Polkadot mais qui ont des connaissances des systèmes de blockchain et sont probablement familiers avec les technologies d'autres écosystèmes.
Je crois que cet article sert de bon précurseur à la lecture du JAM Gray Paper. (Pour plus de détails, voir:https://graypaper.com/)

Connaissances de base

Cet article suppose que le lecteur est familier avec les concepts suivants :

• Décrire la blockchain comme une fonction de transition d'état.
• Comprendre ce que signifie "état". (Pour plus de détails, voir: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/blockchain_state_machines/index.html)
• Sécurité économique et preuve d'enjeu. (Pour plus de détails, voir:https://polkadot-blockchain-academy.github.io/pba-book/economics/economics-of-polkadot/page.html#staking-concept,https://www.youtube.com/watch?v=suyram9vaFc)

Introduction : Polkadot1

Commençons par revisiter les fonctionnalités les plus innovantes de Polkadot1.

Aspects sociaux :

• Polkadot est une organisation autonome décentralisée (DAO) massive. Le réseau met en œuvre une gouvernance entièrement on-chain et auto-exécutante, y compris des mises à niveau du runtime sans fork.
• La SEC a reconnu DOT comme un logiciel, et non comme une sécurité. (Pour plus de détails, voir :https://polkadot.com/newsroom/press-releases/web3-foundation-announces-polkadot-blockchains-native-token-dot-has-morphed-and-is-software-not-a-security)
• La plupart des travaux de développement sur le réseau sont gérés par la bourse Polkadot (Pour plus de détails, voir: https://polkadot-fellows.github.io/dashboard/) plutôt que par Parity Technologies, une entreprise soutenant financièrement le projet (https://www.parity.io/).

Aspects techniques :

• Polkadot a mis en œuvre une sécurité partagée et une exécution fragmentée.
• Utilisation d'un métaprotocole basé sur WASM (Pour plus de détails, voir:https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/wasm_meta_protocol/index.html) , le code de la blockchain est stocké dans l'état sous forme de bytecode. Cela permet à la plupart des mises à niveau de se produire sans forks et permet le sharding hétérogène. (Voir les sections pertinentes pour plus d'informations sur le « sharding hétérogène ».)

Exécution éclatée : Points clés

Actuellement, nous discutons d'un réseau de couche 1 qui héberge d'autres réseaux de "blockchain" de couche 2, similaire à Polkadot et Ethereum. Par conséquent, les termes Couche 2 et Parachain peuvent être utilisés de manière interchangeable.

Le problème fondamental de la scalabilité de la blockchain peut être formulé comme suit : Il existe un ensemble de validateurs qui, en utilisant la cryptographie-économie de la preuve d'enjeu, garantit que l'exécution de certains codes est fiable. Par défaut, ces validateurs doivent réexécuter tout le travail les uns des autres. Tant que nous imposons que tous les validateurs réexécutent toujours tout, le système entier reste non-scalable.

Veuillez noter que, tant que le principe de la réexécution absolue reste inchangé, augmenter le nombre de validateurs dans ce modèle n'améliore pas réellement le débit du système.

Cela démontre un blockchain monolithique (par opposition à un blockchain éclaté). Tous les validateurs du réseau traitent les entrées (c'est-à-dire les blocs) un par un. Dans un tel système, si la couche 1 souhaite héberger plus de couches 2, alors tous les validateurs doivent réexécuter tout le travail des couches 2. Clairement, cette méthode ne permet pas de mettre à l'échelle.

Les rollups optimistes abordent ce problème en ne réexécutant (preuves de fraude) que lorsque la fraude est réclamée. Les Rollups basés sur les SNARK abordent ce problème en tirant parti du fait que le coût de validation des preuves SNARK est significativement inférieur au coût de leur génération, permettant ainsi à tous les validateurs de vérifier efficacement les preuves SNARK. Pour plus de détails, reportez-vous à l'annexe : Diagramme de l'espace de scalabilité.

Une solution simple pour le sharding consiste à diviser l'ensemble des validateurs en plus petits sous-ensembles et à faire réexécuter ces sous-ensembles de Layer2. Quels sont les problèmes liés à cette approche ? Nous divisons essentiellement à la fois l'exécution et la sécurité économique du réseau. Une telle solution Layer2 offre une sécurité moindre par rapport à Layer1, et sa sécurité diminue encore plus lorsque nous divisons l'ensemble des validateurs en plus de shards.

Contrairement aux rollups optimistes, où les coûts de ré-exécution ne peuvent pas toujours être évités, Polkadot a été conçu en gardant à l'esprit l'exécution shardée. Il permet à une partie des validateurs de ré-exécuter les blocs de la couche 2 tout en fournissant suffisamment de preuves cryptéconomiques à l'ensemble du réseau pour prouver que le bloc de la couche 2 est aussi sécurisé que si l'ensemble du jeu de validateurs l'avait ré-exécuté. Cela est réalisé grâce à un mécanisme novateur (et récemment formalisé) connu sous le nom d'ELVES. (Pour plus de détails, voir:https://eprint.iacr.org/2024/961)

En bref, ELVES peut être considéré comme un mécanisme de "rollups suspects". À travers plusieurs rounds de validateurs interrogeant activement d'autres validateurs sur la validité d'un bloc Layer 2 donné, nous pouvons confirmer avec une forte probabilité la validité du bloc. En cas de litige, l'ensemble complet des validateurs est rapidement impliqué. Le cofondateur de Polkadot, Rob Habermeier, a expliqué cela en détail dans un article. (Pour plus de détails, voir:https://polkadot.com/blog/polkadot-v1-0-sharding-and-economic-security#approval-checking-and-finality)

Les ELVES permettent à Polkadot de posséder à la fois une exécution éclatée et une sécurité partagée, deux propriétés qui étaient auparavant considérées comme mutuellement exclusives. Il s'agit de la réalisation technique principale de Polkadot1 en termes de scalabilité.

Maintenant, avançons avec l'analogie du « Core ». Une blockchain d'exécution fragmentée ressemble beaucoup à un CPU : tout comme un CPU peut avoir plusieurs cœurs exécutant des instructions en parallèle, Polkadot peut traiter des blocs de couche 2 en parallèle. C'est pourquoi la couche 2 sur Polkadot est appelée une parachain, et l'environnement où des sous-ensembles de validateurs plus petits ré-exécutent un seul bloc de couche 2 est appelé un « core ». Chaque cœur peut être abstrait comme « un groupe de validateurs coopérants ».

Vous pouvez penser à une blockchain monolithique comme traitant un seul bloc à la fois, tandis que Polkadot traite à la fois un bloc de chaîne de relais et un bloc de chaîne parallèle pour chaque cœur dans la même période de temps.

Hétérogénéité

Jusqu'à présent, nous n'avons discuté que de la scalabilité et de l'exécution shardée offertes par Polkadot. Il est important de noter que chacun des shards de Polkadot est, en fait, une application complètement différente. Cela est réalisé grâce au métaprotocole stocké sous forme de bytecode : un protocole qui stocke la définition de la blockchain elle-même sous forme de bytecode dans son état. Dans Polkadot 1.0, WASM est utilisé comme bytecode préféré, tandis que dans JAM, PVM/RISC-V est adopté.

C'est pourquoi Polkadot est appelé un blockchain fragmenté hétérogène. (Pour plus de détails, voir: https://x.com/kianenigma/status/1790763921600606259) Chaque couche 2 est une application totalement différente.

Polkadot2

Un aspect important de Polkadot2 est de rendre l'utilisation des cœurs plus flexible. Dans le modèle Polkadot initial, les périodes de location de cœurs allaient de 6 mois à 2 ans, ce qui convenait aux entreprises riches en ressources mais était moins réalisable pour les petites équipes. La fonctionnalité qui permet d'utiliser les cœurs Polkadot de manière plus flexible est appelée "Agile Coretime." (Pour plus de détails, voir:https://polkadot.com/agile-coretime) Dans ce mode, les termes de location de base peuvent être aussi courts qu'un seul bloc ou aussi longs qu'un mois, avec un plafond de prix pour ceux qui souhaitent louer pour des périodes plus longues.

Les autres fonctionnalités de Polkadot 2 sont progressivement révélées au fur et à mesure de notre discussion, il n'est donc pas nécessaire d'élaborer davantage ici.

Opérations In-Core vs Sur-Chain

Pour comprendre JAM, il est important de d'abord saisir ce qui se passe lorsque qu'un bloc de la couche 2 entre dans le noyau Polkadot. Ce qui suit est une explication simplifiée.

Rappelez-vous qu'un cœur se compose principalement d'un ensemble de validateurs. Ainsi, lorsque nous disons que des données sont envoyées au cœur, cela signifie que les données sont transmises à cet ensemble de validateurs.

1. Un bloc de couche 2, ainsi qu'une partie de l'état de cette couche 2, est envoyé au cœur. Ces données contiennent toutes les informations nécessaires pour exécuter le bloc de couche 2.

2. Une partie des validateurs principaux va ré-exécuter le bloc de la couche 2 et continuer avec des tâches liées au consensus.

3. Ces validateurs principaux fournissent les données réexécutées à d'autres validateurs en dehors du noyau. Selon les règles des ELVES, ces validateurs peuvent décider de réexécuter ou non le bloc de la couche 2, ayant besoin de ces données pour le faire.

Il est important de noter que, jusqu'à présent, toutes ces opérations se déroulent en dehors du bloc principal de Polkadot et de la fonction de transition d'état. Tout se passe au sein du cœur et de la couche de disponibilité des données.

1. Enfin, une petite partie du dernier état de la couche 2 devient visible sur la chaîne principale de relais de Polkadot. Contrairement aux opérations précédentes, cette étape est beaucoup moins chère que la réexécution du bloc de la couche 2, et elle affecte l'état principal de Polkadot. Elle est visible dans un bloc Polkadot et est exécutée par tous les validateurs de Polkadot.

À partir de cela, nous pouvons explorer quelques opérations clés que Polkadot effectue :

• À partir de l'étape 1, nous pouvons conclure que Polkadot a introduit un nouveau type d'exécution, différent des fonctions traditionnelles de transition d'état de la blockchain. Normalement, lorsque tous les validateurs du réseau effectuent une tâche, l'état principal de la blockchain est mis à jour. C'est ce que nous appelons exécution sur chaîne, et c'est ce qui se passe à l'étape 3. Cependant, ce qui se passe à l'intérieur du noyau (étape 1) est différent. Cette nouvelle forme de calcul de blockchain est appelée exécution en cœur.
• À partir de l'étape 2, nous déduisons que Polkadot a un natif Disponibilité des données (DA)la couche, et les Layer 2 l'utilisent automatiquement pour garantir que la preuve de leur exécution reste disponible pendant une certaine période. Cependant, les blocs de données pouvant être publiés dans la couche DA sont fixes, ne contenant que les preuves nécessaires pour la réexécution de la couche 2. De plus, le code de la parachain ne lit pas les données de la couche DA.

Comprendre cela constitue la base pour saisir JAM. Voici un résumé :

• Exécution In-CoreIl s'agit des opérations qui ont lieu à l'intérieur du noyau. Ces opérations sont riches, évolutives et sécurisées grâce à la cryptéconomie et aux ELVES, offrant la même sécurité qu'une exécution sur chaîne.
• Exécution sur chaîne: Fait référence aux opérations exécutées par tous les validateurs. Elles sont économiquement garanties comme étant sécurisées par défaut, mais elles sont plus coûteuses et restreintes car tout le monde effectue toutes les tâches.
• Disponibilité des données: Fait référence à la capacité des validateurs de Polkadot de garantir la disponibilité de certaines données pendant un certain temps et de les fournir à d'autres validateurs.

JAM

Avec cette compréhension, nous pouvons maintenant introduire JAM.

JAM est un nouveau protocole inspiré de la conception de Polkadot et entièrement compatible avec celui-ci, visant à remplacer la chaîne relais de Polkadot et à rendre l'utilisation principale entièrement décentralisée et non restreinte.

Construit sur Polkadot 2, JAM s'efforce de rendre le déploiement de Layer 2 sur le cœur plus accessible, offrant encore plus de flexibilité que le modèle agile-coretime.

• Polkadot 2 permet un déploiement de la couche 2 sur le cœur plus dynamique.
• JAM vise à permettre à n'importe quelle application d'être déployée sur le cœur de Polkadot, même si ces applications ne sont pas structurées comme des blockchains ou des solutions de couche 2.

Cela est principalement réalisé en exposant les trois concepts fondamentaux discutés précédemment aux développeurs : l'exécution on-chain, l'exécution in-core et la couche DA.

En d'autres termes, dans JAM, les développeurs peuvent:

• Programmez pleinement les tâches à la fois en interne et sur la chaîne.
• Lisez à partir et écrivez sur la couche DA de Polkadot avec des données arbitraires.

Cela forme un aperçu de base des objectifs de JAM. Inutile de dire que beaucoup de choses ont été simplifiées, et le protocole est susceptible d'évoluer encore.

Avec cette compréhension fondamentale, nous pouvons maintenant approfondir certains des aspects spécifiques de JAM dans les chapitres suivants.

Services et éléments de travail

Dans JAM, ce qui était auparavant appelé des Layer 2s ou des parachains est maintenant appelé Services, et ce qui était précédemment appelé blocs ou transactions est maintenant appeléÉléments de travailouPackages de travailPlus précisément, un élément de travail appartient à un service, et un lot de travail est une collection d'éléments de travail. Ces termes sont volontairement larges pour couvrir des cas d'utilisation au-delà des scénarios de blockchain/couche 2.

Un service est décrit par trois points d'entrée, dont deux sont fn refine() et fn accumulate(). Le premier décrit ce que le service fait pendant l'exécution en mémoire, et le second décrit ce qu'il fait pendant l'exécution sur chaîne.

Enfin, les noms de ces points d'entrée sont la raison pour laquelle le protocole s'appelle JAM (Join Accumulate Machine).Rejoindrefait référence àaffiner(), qui est la phase où tous les cœurs Polkadot traitent un grand volume de travail en parallèle à travers différents services. Après que les données sont traitées, elles passent à la prochaine étape.Accumulerfait référence au processus d'accumulation de tous ces résultats dans l'état principal JAM, qui se produit pendant la phase d'exécution on-chain.

Les éléments de travail peuvent précisément spécifier le code qu'ils exécutent en interne et sur la chaîne, ainsi que comment, quand et d'où ils lisent ou écrivent du contenu dans le Distributed Data Lake.

Semi-Consistency

En examinant la documentation existante sur le XCM (langage sélectionné par Polkadot pour la communication entre parachains), toute communication est asynchrone (pour plus de détails, voiriciCela signifie que dès qu'un message est envoyé, vous ne pouvez pas attendre sa réponse. La communication asynchrone est un symptôme d'incohérence dans le système, et l'un des principaux inconvénients des systèmes à fragmentation permanente comme Polkadot 1, Polkadot 2 et les écosystèmes Layer 2 existants d'Ethereum.

Cependant, comme décrit à la Section 2.4 duGraypaper, un système entièrement cohérent qui reste synchrone pour tous ses locataires ne peut évoluer qu'à un certain degré sans sacrifier l'universalité, l'accessibilité ou la résilience.

• Synchronisé ≈ Cohérence || Asynchrone ≈ Incohérence

C'est ici que JAM se distingue : en introduisant plusieurs fonctionnalités, JAM parvient à un état intermédiaire novateur appelé système semi-cohérent. Dans ce système, les sous-systèmes qui communiquent fréquemment peuvent créer un environnement cohérent les uns avec les autres, sans contraindre l'ensemble du système à rester cohérent. Cela a été mieux décrit par le Dr Gavin Wood, l'auteur du Graypaper, lors d'une interview : https://www.youtube.com/watch?t=1378&v=O3kRAVBTkfs&embeds_referring_euri=https%3A%2F%2Fblog.kianenigma.nl%2F&source_ve_path=OTY3MTQ

Une autre façon de comprendre cela est de voir Polkadot/JAM comme un système sharded, où les frontières entre ces shards sont fluides et déterminées de manière dynamique.

Polkadot a toujours été shardé et entièrement hétérogène.

Maintenant, il n'est pas seulement fragmenté et hétérogène, mais ces limites de fragment peuvent être définies de manière flexible - ce que Gavin Wood appelle un système "semi-cohérent" dans ses tweets et le Graypaper. (voir :https://x.com/gavofyork?ref_src=twsrc%5Etfw、https://graypaper.com/)

Plusieurs caractéristiques rendent cet état semi-cohérent possible :

1. Accès à l'exécution parallèle sans état en cœur, où les différents services ne peuvent interagir qu'en synchronisation avec d'autres services au sein du même cœur et du bloc spécifique, ainsi qu'à l'exécution on-chain, où les services peuvent accéder aux résultats de tous les services sur tous les cœurs.
2. JAM ne impose aucune planification de service spécifique. Les services avec une communication fréquente peuvent fournir des incitations économiques à leurs planificateurs pour créer des lots de travail contenant ces services communiquant fréquemment. Cela permet à ces services de s'exécuter dans le même cœur, rendant leurs interactions synchrones, même s'ils sont distribués.
3. De plus, les services JAM peuvent accéder à la couche DA et l'utiliser comme une couche de données temporaire mais extrêmement rentable. Une fois les données placées dans la DA, elles se propagent finalement à tous les cœurs, mais sont immédiatement disponibles dans le même cœur. Par conséquent, les services JAM peuvent atteindre un degré plus élevé d'accès aux données en planifiant leur exécution dans le même cœur à travers des blocs consécutifs.

Il est important de noter que bien que ces capacités soient possibles au sein de JAM, elles ne sont pas imposées au niveau du protocole. Par conséquent, certaines interfaces sont théoriquement asynchrones mais peuvent fonctionner de manière synchrone en pratique en raison d'abstractions sophistiquées et d'incitations. CorePlay, qui sera discuté dans la prochaine section, est un exemple de ce phénomène.

CorePlay

Cette section présente CorePlay, un concept expérimental dans l'environnement JAM qui peut être décrit comme un nouveau modèle de programmation de contrat intelligent. Au moment de la rédaction, CorePlay n'a pas été entièrement défini et reste une idée spéculative.

Pour comprendre CorePlay, nous devons d'abord introduire la machine virtuelle (VM) choisie par JAM : la PVM.

PVM

PVM est un élément clé à la fois dans JAM et CorePlay. Les détails de bas niveau de PVM dépassent le cadre de ce document et sont mieux expliqués par des experts du domaine dans le Graypaper. Cependant, pour cette explication, nous mettrons en évidence quelques attributs clés de PVM :

• Comptage efficace
• La capacité de mettre en pause et de reprendre l'exécution

Ce dernier est particulièrement crucial pour CorePlay.

CorePlay est un exemple de la façon dont les primitives flexibles de JAM peuvent être utilisées pour créer un environnement de contrat intelligent synchrone et évolutif avec une interface de programmation très flexible. CorePlay propose que des contrats intelligents basés sur des acteurs soient déployés directement sur les cœurs JAM, leur permettant de bénéficier d'interfaces de programmation synchrones. Les développeurs peuvent écrire des contrats intelligents comme s'ils étaient des fonctions simples fn main(), en utilisant des expressions comme let result = other_coreplay_actor(data).await?communiquer. Siautre_acteur_de_CorePlayest sur le même noyau JAM dans le même bloc, cet appel est synchrone. S'il est sur un autre noyau, l'acteur sera mis en pause et repris dans un bloc JAM ultérieur. Cela est rendu possible par les services JAM, leur ordonnancement flexible et les capacités de PVM.

Service CoreChains

Enfin, résumons la principale raison pour laquelle JAM est entièrement compatible avec Polkadot. Le produit phare de Polkadot est ses parachains agile-coretime, qui se poursuivent dans JAM. Les premiers services déployés dans JAM seront probablement appelés CoreChains ou Parachains, permettant aux parachains de style Polkadot-2 existants de fonctionner sur JAM.

D'autres services peuvent être déployés sur JAM, et le service CoreChains existant peut communiquer avec eux. Cependant, les produits actuels de Polkadot resteront robustes, ouvrant simplement de nouvelles portes aux équipes de parachain existantes.

Annexe : Fragmentation des données

La majeure partie de ce document traite de la scalabilité du point de vue du sharding d'exécution. Cependant, nous pouvons également examiner ce problème du point de vue du sharding de données. Fait intéressant, nous constatons que cela est similaire au modèle semi-cohérent mentionné précédemment. En principe, un système entièrement cohérent est supérieur mais non scalable, tandis qu'un système entièrement incohérent évolue bien mais est suboptimal. JAM, avec son modèle semi-cohérent, introduit une nouvelle possibilité.

• Systèmes entièrement cohérents: Ce sont des plateformes où tout est synchronisé, comme Solana ou celles exclusivement déployées sur Ethereum Layer 1. Toutes les données de l'application sont stockées on-chain et facilement accessibles par toutes les autres applications. Cela est idéal d'un point de vue de la programmabilité mais pas scalable.
• Systèmes incohérents: Les données d'application sont stockées hors de la couche 1 ou dans des fragments isolés différents. Cela est très évolutif mais fonctionne mal en termes de composabilité. Les modèles rollup de Polkadot et Ethereum entrent dans cette catégorie.

JAM offre quelque chose au-delà de ces deux options : il permet aux développeurs de publier des données arbitraires sur la couche DA de JAM, qui sert d'intermédiaire entre les données sur chaîne et hors chaîne. De nouvelles applications peuvent être développées qui exploitent la couche DA pour la plupart de leurs données, tout en ne persistant que les données absolument critiques dans l'état de JAM.

Annexe: Paysage de la scalabilité

Cette section revoit notre perspective sur la scalabilité de la blockchain, qui est également discutée dans le Graypaper, bien que présentée ici sous une forme plus concise.

La scalabilité de la blockchain suit largement les méthodes traditionnelles des systèmes distribués : mise à l'échelle verticale et mise à l'échelle horizontale.

L'escalade verticale est ce sur quoi des plates-formes comme Solana se concentrent, maximisant le débit en optimisant à la fois le code et le matériel à leurs limites.

L'extensibilité horizontale est la stratégie adoptée par Ethereum et Polkadot : réduire la charge de travail que chaque participant doit gérer. Dans les systèmes distribués traditionnels, cela est réalisé en ajoutant plus de machines en réplication. Dans la blockchain, l'“ordinateur” est l'ensemble du réseau des validateurs. En distribuant les tâches entre eux (comme le fait ELVES) ou en réduisant de manière optimiste leurs responsabilités (comme dans les Optimistic Rollups), nous réduisons la charge de travail pour l'ensemble de l'ensemble de validateurs, réalisant ainsi une extensibilité horizontale.

Dans la blockchain, l'évolutivité horizontale peut être assimilée à "réduire le nombre de machines qui doivent effectuer toutes les opérations".

En résumé :

1. Mise à l'échelle verticale: Matériel haute performance + optimisation des blockchains monolithiques.
2. Mise à l'échelle horizontale:
   • Optimistic Rollups
   • Rollups basés sur SNARK
   • ELVES: Rollups cyniques de Polkadot

Annexe : Même matériel, mise à niveau du noyau

Cette section est basée sur l'analogie de Rob Habermeier de Sub0 2023 :Polkadot: Noyau/Espace utilisateur | Sub0 2023 - YouTube (see:https://www.youtube.com/watch?v=15aXYvVMxlw) , présentant JAM comme une mise à jour 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 :

1. Matériel
2. Noyau
3. Espace Utilisateur

Dans Polkadot, le matériel, l'infrastructure de base fournissant calcul et disponibilité des données, a toujours été les cœurs, comme mentionné précédemment.

Dans Polkadot, le noyau se compose jusqu'à présent de deux parties principales :

1. Le protocole Parachains: une manière fixe et opinée d'utiliser les cœurs.
2. Un ensemble de fonctionnalités de bas niveau, comme le jeton DOT et sa transférabilité, le jalonnement, la gouvernance, etc.

Les deux existent dans la Relay Chain de Polkadot.

D'autre part, les applications de l'espace utilisateur sont les parachains eux-mêmes, leurs jetons natifs et tout ce qui est construit au-dessus d'eux.

Nous pouvons visualiser ce processus comme suit :

Polkadot a depuis longtemps envisagé de déplacer davantage de fonctionnalités de base vers ses principaux utilisateurs - les parachains. C'est précisément l'objectif du Minimal Relay RFC. (Pour plus de détails, voir :RFC de relais minimal)

Cela signifie que la chaîne de relais Polkadot ne s'occuperait que de fournir le protocole de parachain, réduisant ainsi l'espace noyau dans une certaine mesure.

Une fois cette architecture mise en œuvre, il sera plus facile de visualiser à quoi ressemblera la migration de JAM. JAM réduira considérablement l'espace noyau de Polkadot, le rendant plus polyvalent. De plus, le protocole Parachains passera à l'espace utilisateur, car c'est l'une des rares façons de construire des applications sur le même cœur (matériel) et noyau (JAM).

Cela renforce également pourquoi JAM est un remplacement pour la chaîne de relais Polkadot, et non pour les parachaînes.

En d'autres termes, nous pouvons considérer la migration JAM comme une mise à niveau du noyau. Le matériel sous-jacent reste inchangé, et une grande partie du contenu de l'ancien noyau est déplacée dans l'espace utilisateur pour simplifier le système.

Avertissement：

1. Cet article est repris de [ Institut de recherche écologique Polkadot], Tous les droits d’auteur appartiennent à l’auteur original [Institut de recherche écologique Polkadot]. Si des objections existent à cette réimpression, veuillez contacter lePorte Apprendreéquipe et ils s'en occuperont rapidement.
2. Responsabilité de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, copier, distribuer ou plagier les articles traduits est interdit.