Quelle est la vision technologique Polkadot de nouvelle génération « JAM » officiellement annoncée par Gavin Wood ?

Le 19 avril, lors de la conférence Token 2049 à Dubaï, Gavin Wood a annoncé une vision audacieuse pour la prochaine génération de technologie Polkadot. Comme d’autres innovations révolutionnaires que Polkadot a apportées au marché, cette nouvelle vision va révolutionner l’avenir du Web3. Il offrira la vitesse, l’évolutivité, la décentralisation complète et la facilité d’utilisation dont Web3 a besoin pour stimuler une innovation profonde dans le Web3 et dans l’ensemble du domaine technologique.

Au cœur de cette vision se trouve JAM, une nouvelle version de la chaîne Polkadot qui poussera les capacités de Polkadot au-delà des limites actuelles du Web3 tout en permettant de déployer un large éventail de technologies sur Polkadot. Avec JAM, une évolutivité révolutionnaire actuellement visible uniquement via les cumuls est portée à la couche de consensus.

Une fois le développement terminé, JAM sera un ordinateur distribué capable d'exécuter presque n'importe quel type de tâche pouvant être exprimée sous forme de service. JAM pousse Polkadot dans le monde de la composabilité synchrone, ce qui contribuera à réduire la fragmentation et à consolider l'activité afin que les applications sur Polkadot puissent mieux exploiter le réseau à travers l'écosystème. Cela ouvrira de nouvelles possibilités d’innovation en profondeur et fournira aux développeurs un environnement puissant pour créer d’une manière jamais possible auparavant.

JAM est actuellement en phase de recherche et développement. Actuellement, la communauté Polkadot a une proposition à voter (Référendum 682 https://polkadot.polkassembly.io/referenda/682) pour confirmer cette nouvelle direction et autoriser la communauté technique à approuver JAM.

Afin de soutenir le développement de JAM et de garantir qu'il soit construit dans un esprit de véritable décentralisation, Gavin a annoncé conjointement la mise en place du bonus JAM avec la Fondation Web3 dans son discours. Un total de 10 millions de DOT sera versé. être utilisé pour stimuler d’autres implémentations de développement JAM.

Pendant son discours, Gavin a également publié un papier gris technique. Si vous souhaitez approfondir la vision et les détails techniques du projet, le document est disponible sur le nouveau site Web de JAM Graypaper : https://graypaper.com/.

Ensemble, Gavin et Polkadot dirigent la création de technologies innovantes visant à concrétiser la vision de créer un réseau libre et ouvert. JAM est le prochain chapitre de l'histoire évolutive de Polkadot.

Ce qui suit est la dernière introduction à JAM du Polkadot Wiki, écrite par Gavin Wood.

Le nom complet de JAM est Join-Accumulate Machine, qui est une nouvelle conception prévue pour remplacer la chaîne de relais existante. Le nom JAM est dérivé de CoreJAM, qui signifie Collect Refine Join Accumulate et décrit le modèle informatique incarné par la machine, initialement décrit dans une RFC de Gavin Wood. Cependant, dans la chaîne réelle, seuls les processus Join et Accumulate sont effectués, tandis que les processus Collect et Refine se déroulent hors chaîne.

Contrairement à l'approche itérative actuelle, JAM sera présenté comme une mise à niveau unique et complète. Voici quelques raisons pour cela :

• Les mises à niveau uniformes peuvent contraindre précisément les opérations post-mise à niveau, ce qui est difficile à réaliser dans une approche itérative.
• Cela réduit les petites mises à niveau et les changements majeurs qui se produisent souvent régulièrement au fil des semaines ou des mois.

Bien que cette transition nécessitera des changements révolutionnaires importants, nous travaillerons dur pour réduire son impact à un niveau gérable. Il est préférable de consolider plusieurs changements de rupture plus petits en une seule transition, qui introduit un nouveau concept de blockchain et intègre diverses idées existantes.

Une chaîne Rollup

JAM sera une chaîne spécifique à un domaine utilisée pour traiter les problèmes dans un domaine spécifique. Dans ce cas, il s’agit d’un rollup, que la communauté Ethereum appelle un rollup optimiste. Le rollup de JAM est très limité en termes de sécurité. C'est ce que Polkadot fait depuis cinq ans, et c'est devenu une chaîne de cumul hautement spécifique à un domaine. JAM le rend essentiellement plus polyvalent avec moins de préférences prédéfinies.

La chaîne JAM prend la sortie du rollup, et plus généralement les bits de calcul effectués ailleurs, intégrant la sortie dans un état partagé, similaire à la fonctionnalité de la chaîne relais Polkadot.

Le travail de la chaîne JAM est de fournir l'équipement nécessaire pour garantir que la sortie reflète correctement l'entrée après avoir été transformée.

Similarités avec les chaînes de contrats intelligents

JAM présente plusieurs similitudes avec les chaînes de contrats intelligents :

• La chaîne JAM elle-même exécute directement du code sans autorisation.
• L'état de la chaîne JAM est organisé en différents packages.
• En plus de l'encapsulation du statut, cela inclut également l'encapsulation du code et du solde.

L'encapsulation de ces états est appelée un service. Par conséquent, le statut de JAM est divisé en services. La création de nouveaux services se fait sans autorisation, comme le déploiement de contrats intelligents sur une chaîne de contrats intelligents. Par conséquent, l'ajout de nouveaux services à une chaîne JAM ne nécessite aucune approbation faisant autorité ou respect des mécanismes de gouvernance, contrairement aux chaînes basées sur des substrats, qui nécessitent une approbation de gouvernance pour l'ajout de nouvelles palettes. Les services incluent du code, des soldes et certains composants d'état, similaires aux structures couramment observées sur les chaînes de contrats intelligents.

Points d'entrée du service

Le code du service JAM est divisé en trois points d'entrée différents :

• Refine est la fonction qui effectue la plupart des calculs sans état. Il définit les transformations pour les cumuls de services spécifiques.
• La fonction Accumulate prend la sortie et l'intègre dans l'état global du service
• OnTransfer gère les informations provenant d'autres services.

Les packages de travail sont l'entrée du service. Un package de travail peut contenir de nombreux éléments de travail. Chaque élément de travail est associé à un service et reflète l'entrée réelle dans ce service. Pour les services parachain, c’est là qu’interviennent les transactions et toutes les entrées de la blockchain.

Le dispositif de sécurité de JAM consiste en un traitement en deux étapes, où la fonction Affiner accepte les éléments de travail en entrée et produit les résultats du travail en sortie, puis entre dans la fonction Accumuler (d'abord Affiner, puis Accumuler). Les éléments de travail sont raffinés en résultats de travail. Par conséquent, un lot de travaux contenant de nombreux éléments de travail est raffiné en un rapport de travail. Le rapport de travail est le résultat correspondant à plusieurs éléments de travail. Un lot de travaux peut être chargé d'utiliser un noyau pendant une période de temps spécifique (généralement 6 secondes).

JAM est sans transaction

JAM se distingue des chaînes de contrats intelligents par des opérations sans transaction. Il n'y a aucune transaction dans JAM ; toutes les actions sont sans autorisation et passent initialement par la phase Affiner. A ce stade, le service pré-affine les données d'entrée et les convertit en un rapport de travail contenant les résultats des travaux. Les résultats de ces efforts sont ensuite transférés en chaîne.

Malgré aucune transaction, JAM accepte toujours les informations externes dans des formats spécifiques. Il existe cinq types d'informations externes :

1. Garanties

2. Assurances

3 Jugements

4. Billets

Les trois premiers types font partie du cadre de sécurité de la chaîne JAM. Les « Garanties » et « Assurances » impliquent des validateurs prouvant collectivement qu'un résultat de travail reflète fidèlement le résultat de l'élément de travail correspondant lorsqu'il est transformé via la fonction « Affiner » du service.

Le jugement intervient lorsque l'intégrité d'un résultat de travail est remise en cause, lorsqu'un grand nombre de validateurs attestent de sa validité ou de son absence. Dans ce cas, des éléments de travail non valides peuvent avoir été incorporés à l’état du service et devoir être annulés. Le jugement doit être rendu dans l'heure qui suit la remise du rapport de travaux à la chaîne, période pendant laquelle le blocage est temporairement suspendu.

La préimage est une fonctionnalité fournie par la chaîne JAM pour la fonction Affiner. Bien que la fonction Refine soit généralement sans état, elle peut effectuer une opération avec état : rechercher une préimage hachée. Cette fonctionnalité est le seul aspect de la fonction Affiner qui possède une préférence par défaut.

Les billets entrent dans le mécanisme de production de blocs en tant qu'entrées anonymes. Il ne s’agit pas d’exigences directes pour la production de blocs ; le système fonctionne plutôt deux époques à l’avance. Ce mécanisme fait partie de l'algorithme SAFROL, une version raffinée de l'algorithme original SASSAFRAS.

Fonction Affiner

Dans JAM, l'étape de traitement Affiner peut accepter jusqu'à 15 Mo de données par période de temps, chaque période durant 6 secondes. Cependant, les données produites par Refine peuvent atteindre 90 Ko, ce qui nécessite une compression de données importante en raison de la nature distribuée du système de disponibilité. Par exemple, dans le cadre des parachains, 15 Mo de données représentent une Preuve de Validité (PoV), tandis que 90 Ko de données correspondent à un récépissé de candidat.

Refine peut utiliser jusqu'à 6 secondes de gaz PVM, ce qui équivaut à la période de blocage complète de la chaîne de relais. Ce temps d'exécution prolongé, par rapport à la limite actuelle de deux secondes de PVF, est obtenu grâce à des mesures de sécurité et à d'autres optimisations.

Refine peut également effectuer une recherche d'images originales. Si l'on pense qu'un hachage et sa pré-image associée sont disponibles sur la chaîne JAM, la pré-image peut être demandée en fournissant le hachage. Cette capacité permet un stockage et une récupération efficaces du code, par exemple en stockant le code parachain sur la chaîne JAM et en référençant son hachage dans le package de travail.

Refine est la principale puissance de traitement, gérant la plupart des tâches qui sont des opérations sans état.

Fonction Accumulate

La fonction Accumulate est chargée d'intégrer la sortie générée par la fonction Refine dans l'état de la chaîne. Accumulate peut accepter plusieurs sorties de Refine, toutes provenant du même service. Affiner et Accumuler servent tous deux de points d’entrée à partir d’un bloc de code de service spécifique.

Le temps d’exécution par sortie d’Accumulate est beaucoup plus court que celui de Refine, généralement seulement 10 millisecondes au maximum. Cependant, la durée dépend du nombre d'éléments de travail dans le lot de travaux. Si un lot de travaux contient plusieurs éléments, le temps disponible est réparti entre eux.

Contrairement à Refine, Accumulate est avec état et peut accéder à l'état de la chaîne JAM. Il peut lire le stockage de n'importe quel service, écrire dans son magasin clé-valeur, transférer des fonds et inclure des mémos lorsque les fonds sont transférés. De plus, Accumulate peut créer de nouveaux services, mettre à niveau leur code, demander la disponibilité de préimages, etc.

De plus, Refine peut appeler des sous-instances de PVM. Cela permet la création de sous-instances ou de machines virtuelles où le code et les données peuvent être déployés, les configurations de mémoire et de pile personnalisées et les calculs effectués dans un cadre flexible.

Fonction onTransfer

La fonction onTransfer du système JAM est également avec état, ce qui lui permet de modifier l'état du service. Il a la capacité de vérifier l'état des autres services et de modifier son propre état. Cette fonctionnalité facilite la communication entre les services, mais de manière asynchrone.

Contrairement à de nombreuses plateformes de contrats intelligents où les interactions se produisent de manière synchrone, dans JAM, les interactions entre les composants encapsulés (tels que les contrats ou services intelligents dans ce cas) se produisent de manière asynchrone. Les messages et les jetons sont envoyés ensemble et, à un moment donné au cours du même cycle d'exécution de six secondes, ils sont traités par le service de réception. Il n'y a pas de chemin de retour immédiat ; si un chemin de retour est requis, le service émetteur doit lancer un autre transfert ou modifier son état d'une manière que le service récepteur peut interpréter ultérieurement.

Accumulate et onTransfer sont tous deux conçus pour être exécutés en parallèle, permettant à Accumulate et au transfert de différents services de se produire simultanément. Cette conception ouvre la possibilité d'améliorations futures, telles que l'attribution d'un apport de gaz au-delà des 10 millisecondes actuelles. En théorie, un noyau secondaire pourrait être utilisé pour réaliser certaines accumulations, leur donnant ainsi plus de gaz à exploiter.

Généralisation des chaînes JAM

Comme indiqué dans le livre blanc original de Polkadot, Polkadot est principalement personnalisé pour un profil de service spécifique : la fourniture de parachains. Pour mettre en œuvre ce service, Polkadot a développé deux sous-composants importants :

• Système de disponibilité des données distribuées
• Un système qui fournit un audit et une assurance pour les calculs (c'est-à-dire un système de cumul optimiste avec de solides garanties de sécurité)

Avec Polkadot En comparaison, JAM a moins de préférences prédéfinies et offre un niveau d'abstraction et de généralisation plus élevé. Cela facilite l’exploitation des composants sous-jacents en fonction de vos préférences personnelles.

JAM fonctionne sans autorisation, similaire à une chaîne de contrats intelligents, permettant les téléchargements individuels et l'exécution du code prévu. De plus, il héberge des données, permet des recherches de pré-images et gère l'état, à la manière d'un système clé-valeur. Étant donné que JAM ne dispose pas d'un mécanisme pour accepter directement les transactions, le bloc Genesis de JAM contient un service qui facilite la création de nouveaux services.

Les services au sein de JAM n'ont pas de limites prédéfinies sur la quantité de code, de données ou d'état. Leurs capacités sont déterminées par des facteurs cryptoéconomiques : plus il y a de jetons DOT déposés, plus la capacité de données et d'état est grande. Par exemple, le service parachain sur JAM consolide toutes les fonctionnalités de Polkadot 1.1 en un seul service, et d'autres services peuvent également profiter du système de disponibilité distribuée de Polkadot, ainsi que des systèmes d'audit et d'assurance pour le calcul.

Machine virtuelle Polkadot (PVM)

PVM est conçu sur la base de l'architecture de jeu d'instructions RISC-V (ISA), connue pour sa simplicité et sa polyvalence. RISC-V ISA offre plusieurs avantages :

1. Traduction facile vers les formats matériels courants tels que x86, x64 et ARM.

2. Bien pris en charge par des outils comme LLVM.

PVM lui-même incarne la simplicité et la sécurité, a la capacité d'être mis en sandbox et offre diverses garanties d'exécution. Il est déterministe, sensible au consensus et facile à mesurer. Comparé à d’autres machines virtuelles, PVM manque de complexité et de préférences prédéfinies excessives.

WASM, bien qu'optimisé pour les cas d'utilisation Web, présente également des défis de gestion de la pile, notamment lorsqu'il s'agit de gérer la continuité. RISC-V résout ce problème en plaçant la pile en mémoire, facilitant ainsi naturellement le traitement séquentiel sans ajouter de complexité.

De plus, PVM démontre une vitesse d'exécution supérieure lorsqu'il est exécuté sur du matériel existant, en particulier sur X64 et ARM, offrant des avantages tels qu'un comptage gratuit, qui se compare favorablement à WASM.

La prise en charge de la continuité RISC-V établira une nouvelle norme pour le codage évolutif sur les plates-formes multicœurs comme JAM. Les architectures parallèles asynchrones sont de plus en plus importantes pour l’évolutivité des plates-formes matérielles et logicielles, une tendance qui devrait s’étendre aux blockchains et aux algorithmes de consensus.

SAFROLE

SAFROLE est un algorithme de production de blocs qui simplifie SASSAFRAS. Il exclut certains composants qui peuvent être utiles pour les parachains. Les parachains peuvent donc s'en tenir à SASSAFRAS au lieu de SAFROLE. SAFROLE est aussi simple que possible :

• S'assurer qu'il y a le moins de préférences prédéfinies possible pour maximiser les futurs cas d'utilisation potentiels.
• Suivez les traces du livre jaune Ethereum et essayez vraiment d'obtenir autant d'implémentations que possible pour essayer de diffuser l'expertise.

Comprendre comment Polkadot 1.0 fonctionne de bout en bout est un défi. Avec JAM, quelqu'un qui sait lire et comprendre le papier jaune devrait être capable de lire et de comprendre le fonctionnement de JAM très rapidement. La simplicité est donc cruciale.

SAFROLE est un algorithme de production de blocs basé sur SNARK. Il utilise les SNARK en raison de leurs propriétés anonymisantes. Et il permet une production de blocs à temps constant presque entièrement sans fourche. Les rares cas où un fork peut se produire ne se produisent essentiellement qu’en cas de division du réseau ou lorsque quelqu’un agit intentionnellement et de manière malveillante. La grande valeur de l'anonymat n'est pas de garder secrète l'identité des validateurs ; en fait, lorsqu'ils produisent un bloc, ils révèlent quand même leur identité, et cela est fait pour assurer la sécurité du mécanisme de production de blocs lui-même, essentiellement pour éviter le spam. attaques de transactions.

Network

Le réseau de JAM utilise le protocole QUIC. Cela permet des connexions directes peer-to-peer entre un grand nombre de validateurs. En conséquence, les plus de 1 000 validateurs de Polkadot peuvent maintenir des connexions persistantes les uns avec les autres sans avoir à se soucier d'éventuels problèmes de socket. Puisque JAM ne gère pas les transactions, il n’y a pratiquement aucun besoin de commérages. Dans les situations où une distribution autre que point à point ou au sein d'un très petit sous-ensemble de validateurs est requise, la diffusion en grille est utilisée, les validateurs sont disposés en grille, les paquets sont envoyés en lignes, puis chaque nœud l'envoie à tous. de ses colonnes membre.

Pipeline pour un traitement efficace des blocs

Dans les blockchains basées sur l'état comme Ethereum, l'en-tête du bloc contient généralement la racine post-état, qui résume l'état calculé de tous les blocs. Par conséquent, l’en-tête de bloc ne peut pas être envoyé tant que tous les calculs ne sont pas terminés. Cependant, certains calculs peuvent être effectués avant d'envoyer l'en-tête du bloc, car leurs résultats déterminent la validité du bloc.

Cependant, JAM adopte une approche différente et place les racines pré-état dans l'en-tête du bloc au lieu des racines post-état. Cela signifie que l'état affiché dans l'en-tête est retardé d'un bloc. En conséquence, des calculs légers représentant environ 5 % de la charge de travail des blocs ou du temps d'exécution peuvent être effectués et les blocs peuvent être distribués immédiatement. Les 95 % restants des calculs de blocs, principalement les tâches d'accumulation, peuvent être effectués ultérieurement. Cela permet de démarrer le bloc suivant avant que le bloc actuel ne soit exécuté.

Cette approche permet une utilisation plus efficace du temps entre les blocs. Dans une configuration traditionnelle, telle que le temps de bloc de six secondes de Polkadot, la racine post-état doit être fournie et ne peut être calculée qu'une partie du temps. Cependant, grâce au pipeline dans JAM, la totalité du temps de blocage peut être utilisée efficacement pour les calculs, maximisant ainsi l'efficacité.

Bien que l'utilisation de la totalité du temps de bloc pour les calculs ne soit peut-être pas idéale car cela peut entraîner un rattrapage permanent et des importations de blocs retardées, l'approche de JAM peut prolonger considérablement les temps de calcul par rapport aux configurations traditionnelles. Cela signifie que des temps de calcul de bloc effectifs d'environ trois à trois secondes et demie peuvent être obtenus, ce qui représente une énorme amélioration par rapport aux configurations actuelles.

Différence architecturale : JAM et chaîne de relais

Une différence architecturale entre JAM et la chaîne de relais est le degré de fonctionnalité fixe. Si la Relay Chain corrige certains éléments, comme le langage utilisé pour définir le protocole (WASM), JAM va plus loin sur ce point. Par exemple, il dicte les types utilisés pour coder les en-têtes de blocs et les schémas de hachage, ce qui rend difficile la modification de ces aspects.

Cependant, JAM conserve une flexibilité grâce à son modèle de service comparable à celui réalisé par le méta-protocole WebAssembly dans la chaîne de relais. Dans ce modèle, la responsabilité de l’évolutivité est transférée au service, libérant ainsi la chaîne elle-même du fardeau des mises à niveau. Trois raisons principales soutiennent cette décision :

1. Prioriser la simplicité. Le maintien de chaînes non évolutives réduit considérablement la complexité.
2. Les chaînes de relais ont tendance à introduire des fonctionnalités complexes sans supprimer les anciennes fonctionnalités, ce qui complique les choses. Étant donné que les mises à niveau sont faciles à mettre en œuvre, il n’y a guère d’incitation à simplifier le SDK Substrate. Par conséquent, reproduire Polkadot devient peu pratique. Les paramètres fixes de
3. JAM offrent un potentiel d’optimisation. En ayant une compréhension claire des tâches spécifiques que la chaîne JAM doit effectuer et en étant capable de définir des paramètres fixes, l'optimisation dans des domaines tels que la topologie et la synchronisation du réseau devient réalisable. Cela contraste avec la nature hautement évolutive de la chaîne de relais, où ces optimisations sont plus complexes en raison des changements fréquents susceptibles d'être apportés à chaque mise à niveau.

Malgré ces différences, JAM conserve une flexibilité dans les fonctionnalités au niveau de l'application telles que les ventes de temps de base, le jalonnement et la gouvernance, le tout géré au sein du service. De plus, JAM introduit un nouveau concept en associant les soldes de jetons aux services, offrant des opportunités d'ajustements du modèle économique qui ne sont pas faciles à réaliser dans des chaînes purement évolutives telles que les chaînes de relais.

JAM Toaster

Pour garantir que JAM soit à la hauteur de ses attentes initiales, un effort continu comprend la création d'un environnement de test complet pour la chaîne JAM. Plutôt que d’exécuter un réseau de test à petite échelle sur du matériel peu fiable pour gérer les coûts du cloud computing, cette initiative implique un investissement important.

JAM Toaster est présenté ici, qui est essentiellement une plate-forme de test pour des expériences à grande échelle et l'évaluation des performances. Cela répond aux défis antérieurs rencontrés lors du développement de la chaîne de relais Polkadot, lorsque nous avons appris qu'exploiter les effets et la dynamique émergents du réseau à une telle échelle s'est avéré difficile. Les tentatives précédentes se limitaient à quelques dizaines de nœuds sur le réseau de test et sur le réseau Kusama, qui manquaient de capacités de surveillance complètes en raison du manque d'accès aux nœuds de validation. En revanche, les réseaux de test à petite échelle ne parviennent pas à simuler avec précision la dynamique du réseau lors de déploiements à grande échelle.

JAM Toaster vise à combler cette lacune en fournissant un aperçu approfondi de l'ensemble du réseau JAM, y compris 1023 nœuds. La plate-forme facilite l'étude du comportement du réseau et des caractéristiques de performances, fournissant aux développeurs des informations précieuses sur les performances attendues des parachains.

JAM et substrat

Benchmarking vs Metering

Dans JAM, l'analyse comparative ou les tests de performances peuvent être facultatifs. Bien qu'une analyse comparative puisse encore être nécessaire dans certains cas, le système de mesure de JAM élimine généralement le besoin d'effectuer des analyses comparatives fréquentes. JAM fonctionne sur un système de mesure qui permet aux utilisateurs d'évaluer la charge de travail de calcul une fois terminé. De plus, il existe un mécanisme théorique pour contrôler le calcul lors de la construction des blocs.

Cependant, dans certains cas, une analyse comparative est toujours nécessaire. Par exemple, lorsque la mesure est trop conservatrice pour certains cas d’utilisation, une analyse comparative peut être nécessaire pour améliorer les performances. De plus, les tests de performance sont utiles pour les tâches qui nécessitent des temps d'exécution prolongés afin de garantir qu'elles ne s'exécutent pas trop longtemps.

XCMP

La prochaine étape est la messagerie croisée (XCMP), et JAM nécessite une prise en charge complète de XCMP. En effet, dans une chaîne de relais, si toutes les parachaines transmettent toutes les données à tout moment, davantage de données peuvent être transmises via les reçus candidats. JAM suit des règles strictes, même pour les services parachain, y compris des restrictions sur le transfert de données entre les étapes « Affiner » et « Accumuler ». Actuellement, en utilisant la messagerie par chaîne de relais horizontale (HRMP), tous les messages traversent la chaîne de relais, limitant la charge utile des données à 4 Ko ou moins, ce qui peut ne pas être pratique. En conséquence, XCMP relaie uniquement les en-têtes de message à travers la chaîne tandis que les données réelles du message sont transmises hors chaîne, une amélioration nécessaire et attendue depuis longtemps.

Accords

Les accords encapsulent essentiellement l'état et la logique, similaires aux contrats intelligents, avec plusieurs instances de chaque parachain. Ils facilitent l'échange de messages entre instances et permettent une interaction synchrone avec les parachains. Le protocole est utile dans les scénarios où il y a un manque de confiance entre les parachains, comme les transferts de jetons. Contrairement aux approches existantes impliquant des intermédiaires de réserve, Accords simplifie les transferts directs de jetons entre parachains, éliminant ainsi le besoin d'intermédiaires compromettant la confiance. De plus, Accords peut agir comme un mécanisme de transfert XCM pour garantir l'intégrité des messages même lorsqu'ils sont relayés par des intermédiaires tiers, éliminant ainsi le besoin d'un marquage explicite de l'origine.

Améliorer l'efficacité

Enfin, JAM adopte une approche plus large et moins privilégiée pour tirer parti du mécanisme de consensus sous-jacent, aidant ainsi à mettre en œuvre des solutions plus innovantes. Par exemple, pour des tâches complexes telles que les preuves sans connaissance, la disponibilité distribuée devient plus pratique et efficace. De plus, JAM prend en charge un modèle de consommation de ressources mixte, dans lequel les packages de travail peuvent contenir à la fois des tâches gourmandes en calcul et des opérations gourmandes en données. En associant des services gourmands en calcul à des services nécessitant une haute disponibilité des données, JAM optimise l'utilisation des ressources du validateur, réduisant ainsi les coûts. Cette approche flexible rend la combinaison des charges de travail parachain telles que la disponibilité distribuée et la vérification SNARK moins coûteuse tout en augmentant l'efficacité.

Améliorations et compatibilité JAM

JAM a été conçu pour donner la priorité à la compatibilité avec les parachains Polkadot 1 existantes. Bien qu'elle conserve la compatibilité avec le SDK Polkadot, la fonction Polkadot Validator (PVF) a été déplacée. Il ciblera la machine virtuelle Polkadot (PVM), et non WebAssembly. Cette transition est facilitée par le fait que PVM est une légère modification de RISC-V, qui a été formellement identifié comme une cible de LLVM. Par conséquent, PVM peut devenir une cible officielle de LLVM avant le déploiement de JAM.

En plus d'héberger des parachains, JAM introduit des améliorations significatives. Il offre la possibilité de simplifier les efforts d’analyse comparative et d’atténuer les besoins futurs en matière d’analyse comparative. De plus, JAM introduit le concept de protocoles, de contrats intelligents multi-instances et multi-shard pour gérer et exécuter des protocoles d'interaction spécifiques entre les parachains. De plus, la prise en charge complète de la messagerie inter-chaînes (XCMP) est cruciale, permettant de supprimer les restrictions sur le transfert d'informations entre les parachains, qui sont généralement facilitées par la messagerie inter-chaînes (XCM).

Concernant Agile Coretime, JAM maintient la compatibilité avec les paramètres existants. Cependant, il introduit la possibilité de localiser les temps de base non seulement sur les parachains, mais aussi sur des groupes arbitraires de packages de travail. Cette flexibilité améliore la polyvalence et l’efficacité de l’allocation des ressources au sein de l’écosystème JAM.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!