JAM sera livré dans 12 à 20 mois ? Trois développeurs principaux dévoilent le modèle économique M1, PoP et l’avenir du ZK !

JAM, ce nom est discuté depuis longtemps au sein de la communauté Polkadot. Avec la série d'annonces majeures faites par Gavin Wood lors du Web3 Summit, les attentes et les questions autour de JAM ont atteint un nouveau sommet : Qu'est-ce que JAM exactement ? Quels changements apportera-t-il à Polkadot ? À quelle distance sommes-nous de son lancement officiel ?

Pour permettre à la communauté de mieux comprendre, PolkaWorld a invité trois invités directement impliqués dans le développement central de JAM : Bryan de l'équipe Acala, Junha, développeur de l'implémentation Rust de JAM appelée “FastRoll”, et Boy Maas, développeur de l'implémentation Zig “JAMZig” et cofondateur du projet Polona.

Non seulement ces trois invités participent activement à la mise en œuvre technique de JAM, mais ils explorent également le potentiel de JAM dans différentes directions : de la réalisation de clients multilingues à la migration de la toolchain cross-chain, en passant par les futures applications du PVM, ils représentent le mieux l'état d'avancement actuel de JAM.

Dans cette interview, ils nous feront découvrir le monde de JAM à travers leur propre expérience :

• Que signifient réellement les mises à jour majeures de JAM annoncées par Gavin ?
• Comment le plafond du token JAM (π × 1,000,000,000) et le mécanisme PoP (Proof of Personhood) vont-ils modifier le modèle économique de Polkadot ?
• Quels sont les objectifs techniques et les progrès du Milestone 1 ? Quand le testnet sera-t-il lancé ?
• Comment le ZK (Zero-Knowledge Proof) sera-t-il intégré à JAM à l'avenir ?
• Comment le mécanisme de gouvernance de JAM et le comité de rédaction du Gray Paper influenceront-ils l'évolution à long terme du protocole ?

Si vous souhaitez comprendre l'avenir de JAM et comment il va remodeler l'infrastructure de l'écosystème Polkadot, cet épisode est à ne pas manquer.

Présentation des trois équipes de développement JAM

Kristen : Bonjour à tous, je suis Kristen. Aujourd'hui, nous avons invité trois développeurs principaux de JAM, qui participent directement au développement de JAM. Si vous suivez PolkaWorld ou les dernières actualités de Polkadot, vous savez sûrement que le Web3 Summit a lieu en ce moment, et Gavin y a fait d'importantes annonces concernant JAM. La communauté nous a déjà envoyé de nombreuses questions, c'est pourquoi nous avons organisé ce live à la dernière minute, en espérant que les partages de nos invités aideront la communauté à mieux comprendre les annonces de Gavin sur JAM lors du Web3 Summit.

Pour commencer, j'aimerais que chacun des trois invités se présente brièvement, explique la partie du projet JAM dont il est responsable et l'état d'avancement du développement. Même si certains sont déjà des habitués de notre émission, il y a toujours de nouveaux spectateurs, donc je vous demanderai de bien vouloir vous présenter à nouveau. Commençons par Junha.

Junha : Merci Kristen pour l'invitation. Bonjour à tous, je suis Junha, c'est la première fois que je participe à cette émission.

Actuellement, je développe l'implémentation en Rust du protocole JAM, appelée “FastRoll”. Pour l'instant, je suis le seul membre de mon équipe, je travaille donc en tant que développeur indépendant.

Je travaille sur ce projet depuis environ un an, je prépare actuellement la revue du premier jalon, tout en commençant à avancer sur certains travaux de la deuxième phase.

Kristen : Bienvenue Junha ! Passons maintenant à Bryan pour sa présentation.

Bryan : Bonjour à tous, je suis Bryan, de l'équipe Acala. Je dirige actuellement une petite équipe qui développe une autre implémentation du protocole JAM, appelée “Boka”.

• Nous travaillons également à l'achèvement de la première phase, tout en mettant à jour certains composants off-chain pour préparer la deuxième phase.
• Nous venons également de commencer le développement du recompiler PVM, mais nous en sommes encore aux tout débuts, il reste beaucoup à faire avant d'aboutir.

Kristen : Merci Bryan d'être à nouveau parmi nous. Bryan a d'ailleurs été notre tout premier invité à présenter le projet JAM, c'est un plaisir de te revoir. Enfin, accueillons Boy Maas, que nous avons déjà interviewé auparavant.

Boy Maas : Oui, oui, bonjour à tous, je suis Boy Maas. Je suis le développeur indépendant de l'implémentation Zig du protocole JAM, notre client s'appelle “JAMZig”.

Je suis également cofondateur d'un projet de l'écosystème JAM, dont l'objectif est de migrer entièrement la toolchain et la machine virtuelle Solana (SVM) sur JAM. Nous avons déjà terminé la phase de preuve de concept, c'est-à-dire que nous avons déjà pu faire fonctionner certaines fonctionnalités de base.

JAM sera-t-il livré officiellement dans 12 à 20 mois ?

Kristen : Bienvenue Boy Maas, Polona est effectivement un projet pionnier, visant à attirer les développeurs Solana dans l'écosystème Polkadot, c'est une excellente idée ! Merci à vous trois d'être là.

Pour commencer, j'aimerais poser une question à Boy Maas. Tu as participé au Web3 Summit, nous avons déjà vu beaucoup d'informations sur le discours de Gavin sur Twitter, mais j'aimerais que tu nous partages ton ressenti en tant que témoin direct. As-tu assisté au discours de Gavin ? Peux-tu nous dire ce que tu as retenu d'important ?

Boy Maas : Bien sûr, c'était vraiment génial d'être sur place. On peut rencontrer de nombreux membres de la communauté Polkadot, il y a beaucoup de partages intéressants qui permettent de ressentir la dynamique de la communauté, l'ambiance est très positive et pleine d'énergie, ce qui donne beaucoup d'espoir pour l'avenir. Aujourd'hui, c'est le dernier jour, et j'ai hâte de ramener cette expérience pour continuer à faire avancer notre développement.

Kristen : Tu as vu le discours de Gavin ?

Boy Maas : Oui, je l'ai vu.

Kristen : Y a-t-il des points marquants que tu pourrais partager ? Nous avons vu quelques informations écrites sur Twitter, mais nous aimerions que tu nous expliques, avec ton regard de développeur, de façon plus simple et compréhensible.

Boy Maas : Bien sûr. Gavin a abordé de nombreux sujets dans son discours. C'est quelqu'un de très visionnaire, avec beaucoup d'expérience, donc certaines de ses décisions et nouvelles idées ont un impact majeur sur la direction future de la communauté.

Le point le plus important, c'est qu'il a annoncé que l'offre totale de tokens JAM serait plafonnée à “π multiplié par 1,000,000,000” (π × 1,000,000,000), ce qui est une décision très importante et aura de nombreuses conséquences.

Un autre point clé, c'est qu'il a essayé de clarifier pour la communauté Polkadot ce qu'est réellement JAM. JAM est essentiellement conçu pour renforcer et soutenir l'écosystème Polkadot, il est positionné comme un moteur d'infrastructure pour l'ensemble de l'écosystème. En fait, tout le monde est encore en train d'explorer et de s'adapter : Qu'est-ce que JAM ? Que peut-il faire ? Comment coopère-t-il avec le réseau principal Polkadot ? Comment est-il mis en œuvre ?

En tant que développeurs, nous comprenons les détails techniques de JAM, mais je comprends aussi que pour la plupart des gens, on est encore à l'étape où l'on ne sait pas vraiment quels changements JAM va apporter. Tout le monde essaie de se représenter à quoi pourrait ressembler ce futur monde propulsé par JAM.

Kristen : Ça a l'air très intéressant. J'ai aussi remarqué que Gavin a mentionné que JAM serait livré officiellement dans 12 à 20 mois. Votre projet Polona dépend-il aussi de ce calendrier ? Votre rythme de développement sera-t-il synchronisé avec celui de JAM ?

Boy Maas : Oui, Kristen, tu as tout à fait raison. Nous n'avons pas spécialement prévu d'être prêts dès le lancement du testnet, mais selon le calendrier annoncé, notre plan s'aligne parfaitement : dès que le testnet JAM sera en ligne, nous pourrons l'utiliser immédiatement. Et une fois le réseau officiellement opérationnel, nous serons parmi les premiers à suivre.

Qu'est-ce que le M1 de JAM ?

Kristen : Très bien, c'est super d'entendre ces avancées. Je voudrais maintenant poser une question à Junha.

JAM a récemment publié une mise à jour technique majeure et a clarifié les objectifs de livraison du premier jalon (milestone 1). Mais certains auditeurs ne comprennent pas bien ce qu'est le milestone 1, ce qu'il implique et où il en est. Peux-tu nous expliquer ce que comprend exactement le milestone 1 ? Où en est le testnet ? Quand penses-tu qu'il sera lancé ?

Junha : Bien sûr. Comme tu l'as mentionné, le “Gray Paper” de JAM a récemment été mis à jour en version 0.7.0. Gavin a aussi dit dans son discours qu'à partir de cette version, le Polkadot Fellowship pouvait commencer à évaluer le milestone 1. Donc, la plupart des équipes qui travaillent sur des clients JAM se préparent à cette évaluation.

L'objectif du milestone 1 est de livrer un client capable “d'importer correctement des blocs”, c'est-à-dire de valider la logique d'exécution la plus basique de JAM.

Concrètement, il s'agit de donner une série de blocs (certains valides, d'autres non), et le client doit identifier ceux qui sont correctement formatés. Pour les blocs valides, le client doit pouvoir lire les données externes, exécuter la logique de transition d'état (cœur du runtime blockchain), et finalement générer un nouvel état sur la chaîne. Car une blockchain est essentiellement une machine à états : à partir d'un état initial, en important des blocs et en exécutant la logique correspondante, on obtient un état ultérieur.

L'évaluation du milestone 1 consiste à vérifier si l'implémentation du client génère le bon état après l'import de ces blocs.

La méthode d'évaluation est simple : nous préparons un lot de blocs de test, puis nous comparons si les différents clients produisent exactement le même état final. Ce résultat d'état peut être résumé par une “racine verticale” (vertical root), ce qui facilite la comparaison. Il existe déjà un outil de test appelé JAM Conformance Fuzzer, qui peut générer automatiquement de nombreux blocs avec des données aléatoires pour tester si chaque implémentation aboutit au même état racine.

Je pense que c'est une excellente occasion de trouver et corriger rapidement les bugs critiques, et de poser les bases pour les phases plus complexes à venir.

Kristen : D'accord, alors quand penses-tu que le testnet sera lancé ?

Junha : Tu parles du testnet JAM ? Certaines équipes ont déjà tenté l'interopérabilité cross-implémentation avec leurs propres binaires compilés, mais à mon avis, un testnet réellement opérationnel ne sera mature qu'après le milestone 2.

Car le milestone 1 vérifie surtout la logique de transition d'état du client, ce qui n'est pas suffisant pour faire tourner un testnet complet. Le milestone 2 évaluera si chaque implémentation a réalisé l'ensemble du protocole de communication réseau (networking spec). Mais ce protocole n'est pas encore stable, il n'est même pas encore écrit dans le Gray Paper. Une fois que la spécification réseau sera stabilisée et que les implémentations seront prêtes, on pourra tester l'interopérabilité entre les nœuds.

À ce moment-là, il sera plus approprié de préparer officiellement le lancement du testnet. Bien sûr, certaines équipes pourraient tenter des essais plus tôt, mais personnellement, je préfère attendre après le milestone 2 pour rejoindre le testnet.

Kristen : D'accord. Penses-tu que les nouvelles annonces de Gavin lors du sommet auront un impact sur ton rythme de développement ?

Junha : Je pense que la plupart de ses annonces concernent la vision à long terme, donc à court terme, cela n'affectera pas beaucoup mon planning. Je reste concentré sur la finalisation du milestone 1, il me faudra encore quelques semaines, voire un mois, pour livrer un client totalement conforme. Donc pour l'instant, ma stratégie de développement ne change pas.

Bien sûr, sur un horizon d'un à trois ans, ces nouvelles orientations pourraient avoir un impact, mais pour l'instant, je me concentre sur la réussite du milestone 1.

Quels seraient les impacts si PoP remplaçait NPoS ?

Kristen : Compris, merci pour ton partage ! Maintenant, une question plus “hardcore” pour Bryan, sur le modèle économique du token. On sait que les développeurs n'aiment pas trop juger l'efficacité des modèles économiques, mais c'est l'une des préoccupations majeures de la communauté. Gavin a annoncé lors du sommet que PoP (Proof of Personhood) remplacerait NPoS, que les récompenses des validateurs deviendraient fixes, et qu'un mécanisme de réduction annuelle limiterait l'offre totale de DOT. En tant que développeur, que penses-tu de ces changements ? Quel serait l'impact principal selon toi ? Es-tu favorable ? As-tu des inquiétudes ou des suggestions ?

Bryan : Effectivement, c'est un grand changement.

Je vais d'abord rappeler le contexte : que ce soit la preuve de travail (PoW), la preuve d'enjeu (PoS), ou maintenant la “preuve de personnalité” (Proof of Personhood, PoP), ces mécanismes servent essentiellement à protéger la sécurité du réseau, à éviter les doubles dépenses, les forks, etc.

Chaque mécanisme a ses coûts : PoW implique des récompenses de bloc et nécessite beaucoup d'électricité et de puissance de calcul, tandis que PoS nécessite de récompenser les stakers.

La nouvelle preuve de personnalité diffère beaucoup au niveau des récompenses. Polkadot utilisait NPoS (Nominated Proof of Stake), qui, bien que moins coûteux que PoW, avait un problème : pour maintenir la sécurité du réseau, il fallait émettre en permanence de nouveaux tokens pour récompenser les validateurs et les nominateurs, ce qui entraînait de l'inflation.

L'objectif de POP est donc de réduire le coût de fonctionnement de la sécurité du réseau, de ne plus dépendre des incitations ou des punitions économiques, mais de passer à un nouveau mode — on ne sait pas encore exactement comment, mais l'idée centrale est “une personne, un vote”. Si cela fonctionne, la triche devient beaucoup plus difficile, la sécurité du réseau est plus facile à garantir, et il n'est plus nécessaire de verser autant de tokens en récompense.

Du point de vue du réseau, cela réduit considérablement les coûts d'exploitation, c'est une bonne chose. Mais il y a aussi des effets secondaires : beaucoup de gens dépendaient des récompenses de staking pour obtenir plus de tokens, ce mode de revenu disparaît quasiment. Il y aura de nouveaux moyens d'obtenir des tokens, mais en quantité bien moindre. D'un autre côté, pour les détenteurs, si les dépenses du réseau diminuent, la valeur de vos tokens augmente, donc globalement, je pense que c'est positif.

Cela pourrait aussi avoir un effet bénéfique sur la DeFi. Si les rendements du staking baissent, les utilisateurs pourraient déplacer leurs fonds vers d'autres protocoles DeFi, comme le prêt, la fourniture de liquidité, etc., ce qui dynamiserait l'écosystème DeFi.

Bien sûr, il faudra voir les détails complets pour juger de l'impact réel, et même avec un design complet, il sera difficile de tout prévoir. Mais personnellement, je vois ces changements d'un œil positif.

Kristen : À court terme, cela risque d'être difficile pour les validateurs, car leurs revenus pourraient chuter fortement. Penses-tu que cela posera problème au début ?

Bryan : Cela dépendra de la façon dont la transition est conçue. Par exemple, il ne s'agira pas de tout changer du jour au lendemain, mais d'une transition progressive, comme la réduction annuelle de l'offre de tokens. On ne coupera pas l'inflation à zéro dès le premier jour, mais on la réduira progressivement, ce qui laissera à chacun le temps de s'adapter et d'ajuster sa stratégie.

Nous devons toujours garantir la sécurité du réseau, permettre aux validateurs de couvrir leurs coûts et de faire un peu de profit, et donner aux gens l'envie de nominer et de choisir de bons validateurs. Ces principes ne changent pas, on veut juste réduire les récompenses. Il y aura donc des changements, mais on espère que le nouveau modèle économique minimisera l'impact.

Qu'est-ce que zkJAM ?

Kristen : C'est vrai, la communauté est très divisée. Au début, tout le monde réclamait “moins d'inflation”, maintenant qu'on passe à une phase déflationniste, certains se plaignent. Je pense que c'est la bonne direction, merci pour ton analyse approfondie.

Passons à un sujet technique : ZKJAM. J'ai vu ce terme dans le PPT de Gavin, cela semble encore conceptuel. Mais le “Zero-Knowledge Proof” (ZK) est très en vogue dans le Web3 ces dernières années, beaucoup disent que ZK est la solution ultime pour les Rollups et la scalabilité. Si à l'avenir ZK et JAM sont combinés, à quoi cela ressemblerait-il ? J'aimerais avoir vos avis à tous les trois. Junha, commençons par toi.

Junha : D'accord. Gavin a comparé JAM dans son discours à un “super ordinateur bare metal décentralisé”, et les différents services qui tournent dessus sont comme des systèmes d'exploitation sur le hardware, comme Windows ou macOS.

Si à l'avenir ZK est intégré à JAM, du point de vue des développeurs de services ou d'applications, cela ne changera pas fondamentalement l'expérience de développement ou d'utilisation.

Même si le mécanisme de sécurité de JAM passe du modèle actuel “audit-based re-execution” à un modèle “basé sur les preuves ZK”, tant que cette mise à niveau est rigoureusement vérifiée et plus efficace, elle vaut la peine d'être adoptée.

Donc, si ZK et JAM s'adaptent bien et que c'est plus avantageux que la méthode actuelle, la mise à niveau est envisageable, et l'expérience globale ne changera pas beaucoup.

Kristen : Merci pour ton partage. Je pense que certains auditeurs ont peut-être été perdus par les termes techniques, mais ne vous inquiétez pas, nous publierons un article récapitulatif en chinois pour que vous puissiez relire et digérer le contenu. Passons à Bryan pour ton avis.

Bryan : Je pense qu'il faut distinguer deux concepts : d'une part, JAM comme infrastructure supportant des Rollups ZK sécurisés, et d'autre part, JAM lui-même utilisant ZK pour sa propre sécurité. Ce sont deux choses très différentes.

Grâce au PVM de JAM, tout algorithme ou architecture lié au ZK, comme un nouveau protocole ZK-Rollup, peut être déployé comme un service sur JAM. C'est relativement facile à réaliser.

Mais si on veut que JAM lui-même soit sécurisé par ZK, cela implique beaucoup de recherche de pointe et d'optimisation des algorithmes existants. Pour l'instant, c'est encore très “avant-gardiste”. Cela dépend de l'état de l'art — les algorithmes actuels ne sont peut-être pas assez rapides ou bon marché, mais qui sait, peut-être que demain quelqu'un inventera un algorithme 100 fois plus efficace, et tout changera.

Donc, si une intégration ZK vraiment utile apparaît à l'avenir et peut rendre JAM plus sûr, je suis évidemment pour.

Kristen : Espérons que ce domaine connaîtra de vraies avancées. Boy Maas, en tant que développeur expérimenté, quel est ton avis ?

Boy Maas : Je pense que Bryan et Junha ont déjà tout dit. Ce que j'aime chez JAM, c'est que c'est un système très pragmatique. Ses choix de design visent à ce que le système fonctionne réellement, qu'il puisse exécuter des calculs. Comme l'a dit Bryan, utiliser ZK pour tout cela est aujourd'hui trop coûteux et irréaliste. Donc j'imagine qu'à l'avenir, on pourrait adopter un “modèle hybride”, où l'audit traditionnel et le ZK coexistent.

Mais pour l'instant, le ZK est trop cher et peu pratique, mais dans les 12 mois à 5 ans à venir, il y aura sûrement beaucoup de changements dans le domaine du ZK. Si le ZK devient vraiment efficace, ce sera une technologie très attractive, qui pourrait redéfinir le modèle de sécurité et l'architecture de tout notre système.

Mais pour l'instant, le modèle hybride est probablement plus réaliste : il reste pratique, tout en permettant aux applications qui ont vraiment besoin de la sécurité ZK d'en bénéficier.

JAM va créer un comité de rédaction du Gray Paper

Kristen : Merci pour vos partages. Passons au sujet suivant : le mécanisme de gouvernance de JAM.

Gavin continuera d'être le rédacteur en chef du Gray Paper, et il a aussi annoncé la création d'un “comité de rédaction du Gray Paper”, composé de contributeurs techniquement compétents et impliqués dans le développement de JAM, qui décideront ensemble des mises à jour, des priorités et des décisions clés du protocole JAM. En tant que développeurs, pensez-vous que ce mode de gouvernance par comité est viable ? Y a-t-il un risque de “dérive” ? Si cela arrive, comment y faire face ? Commençons par Boy Maas.

Boy Maas : Je pense que c'est une question très pertinente. Pour un domaine aussi technique et spécialisé, il est très raisonnable et nécessaire d'avoir un comité pour mettre à jour le Gray Paper. Ceux qui prennent ces décisions doivent avoir une compréhension approfondie et une expérience pratique à long terme des principes fondamentaux de JAM pour juger sagement. Que le fondateur Gavin dirige ce comité est très logique, donc je soutiens totalement ce mode de gouvernance.

Kristen : Donc tu penses qu'il est bon que le protocole soit décidé collectivement par une équipe professionnelle ?

Boy Maas : Oui, tout à fait.

Kristen : D'accord, Bryan, quel est ton avis ?

Bryan : En fait, on peut dire que tous les projets sont gouvernés par une sorte de “comité”, la différence étant la taille et la composition. La question est de savoir si le processus de gouvernance est clairement défini.

Je pense que le fait de formaliser le processus de gouvernance est déjà un progrès, au moins tout le monde sait comment les mises à jour sont décidées, ce qui augmente la transparence et facilite l'amélioration future du processus. S'il n'y a pas de règles, on ne peut pas s'améliorer.

Le contenu du Gray Paper est vraiment complexe, presque tous les développeurs des équipes JAM l'ont lu plusieurs fois dans différentes versions. Mais honnêtement, à part Gavin, personne ne peut le comprendre à 100 %, et peut-être même pas Gavin lui-même dans chaque détail. Beaucoup de gens participent à la modification du document, en corrigeant des fautes, ajustant des formules, optimisant la logique, c'est un vrai processus collaboratif.

Donc, à mon avis, seuls ceux qui ont des années d'expérience dans ce domaine devraient participer à la modification du Gray Paper. Un petit changement peut avoir de grandes conséquences. Cela concerne l'avenir du Web3, voire d'Internet, et la sécurité de nombreux actifs, il faut donc être très prudent. La transparence et l'ouverture sont essentielles. Tout le monde peut faire des suggestions, mais il faut prouver qu'on comprend vraiment ce qu'on propose, sinon le bruit noie les bonnes idées.

Kristen : Donc tu penses que ce comité doit aussi établir des règles, comme qui peut le rejoindre, comment organiser les membres, etc. Car chacun a son avis, sans règles, il est facile de diverger, voire de s'éloigner de l'objectif initial.

Bryan : C'est pour ça qu'on a besoin de smart contracts, de processus clairs, tout doit être écrit. Si les règles sont noires sur blanc, tout le monde peut surveiller leur application, tout est transparent, donc moins de risque de dérive. Si tout se fait en secret, personne ne sait ce qui se passe, c'est là qu'on dévie. La transparence est cruciale, surtout si le processus peut être appliqué par smart contract, alors le mécanisme peut durer longtemps.

Kristen : Je me souviens que la communauté Bitcoin a aussi un comité de développeurs pour faire avancer le projet.

Bryan : Oui, la communauté Bitcoin a un groupe de développeurs principaux, mais la décision finale se fait par fork : la chaîne qui a le plus de puissance de calcul l'emporte.

Kristen : Compris, merci pour tes explications. Enfin, écoutons l'avis de Junha sur ce sujet.

Junha : Je pense que la création d'un comité de rédaction est une étape très naturelle et significative. JAM est un projet très particulier : avant même de développer un logiciel complet, une spécification technique complète (le Gray Paper) a été publiée. Ce document contient de nombreuses formules mathématiques pour définir le comportement d'entrée/sortie du système. Rédiger la documentation avant le développement vise à plus de décentralisation et de résilience du système.

C'est pourquoi le Gray Paper a déjà été révisé plusieurs fois depuis sa publication, et il continuera à l'être même après la version 1.0.

Avec de plus en plus d'équipes qui implémentent le protocole JAM et montent des testnets, on découvrira forcément des points à optimiser pour améliorer l'efficacité ou la faisabilité du protocole. Donc, vu la nature du projet JAM, le Gray Paper continuera probablement d'évoluer dans les mois suivant le lancement du mainnet, voire il pourrait y avoir des hard forks.

Dans ce contexte, il est évidemment préférable qu'un groupe de personnes soit responsable du développement des spécifications du protocole, plutôt que de s'en remettre à un seul auteur.

Comme l'a dit Bryan, la transparence est aussi très importante, le processus de décision du comité doit être public. J'espère aussi que davantage d'équipes utilisant le protocole JAM participeront activement à la relecture, à la correction et au feedback du document, plutôt que de simplement “faire confiance à Gavin”. C'est en participant activement qu'on découvre des axes d'amélioration. C'est un bon début, prometteur. Avec les spécificités du projet JAM, cette façon de faire évoluer la spécification est naturelle et raisonnable.

Nous sous-estimons peut-être ce que JAM peut apporter à la blockchain

Kristen : D'accord, c'est effectivement un bon début. Si tout le processus est transparent, ce sera formidable. Merci pour vos partages, je pense que nous avons couvert tous les sujets prévus aujourd'hui.

Avant de conclure, avez-vous quelque chose à ajouter ? Sur JAM, sur le Web3 Summit, quelque chose que vous n'avez pas eu le temps de dire ? Commençons par Bryan.

Bryan : Rien de particulier à ajouter. JAM est une infrastructure de base, c'est important, mais ce n'est pas tout. Ce qui compte vraiment, ce sont les services et applications construits sur JAM — les utilisateurs n'utiliseront pas JAM directement, mais les services basés sur JAM.

Donc, le lancement de JAM n'est que la première étape vers l'objectif final. Nous devons nous concentrer sur les services et applications qui tourneront sur JAM, car c'est ce qui impactera vraiment les utilisateurs. Il reste donc beaucoup à faire, et notre attention ne doit pas se limiter au protocole JAM lui-même, mais aussi à tout ce qui sera construit dessus.

Kristen : Merci. Boy Maas, as-tu quelque chose à ajouter sur Polona ou JAM ?

Boy Maas : Bien sûr. D'abord, je veux parler de JAM. Je me souviens qu'à Lisbonne, Gavin avait fait une présentation sur JAM. J'ai eu alors le sentiment très fort que nous sous-estimions peut-être ce que cette plateforme peut apporter à la communauté blockchain.

La “bande passante” et la flexibilité offertes par JAM n'ont jamais été atteintes par aucune blockchain auparavant. Je pense que c'est déjà un jalon important dans l'histoire de la blockchain, surtout en ce qui concerne les nouvelles applications qu'il peut accueillir, c'est vraiment unique.

Petite info en plus, notre projet Polona avance très vite, nous avons déjà un proof of concept (PoC) qui tourne sur JAM. Nous avons porté le SVM de Solana sur le PVM, ce qui veut dire que vous pouvez maintenant exécuter directement du bytecode Solana sur JAM, y compris les appels inter-contrats, tout fonctionne, c'est vraiment cool. Cela montre la puissance des services JAM.

Kristen : Super, merci ! Enfin, Junha, un mot de la fin ?

Junha : J'espère que plus de gens s'intéresseront à JAM, à Polkadot et au Gray Paper. J'aimerais vraiment entrer en contact avec plus de personnes pour partager des idées.

Le client JAM est encore en développement, donc il n'y a pas encore beaucoup d'exemples d'applications “finies”. L'équipe de Gavin a montré quelques démos, mais il n'y a pas encore assez de cas concrets pour convaincre tout le monde de ce que ce système peut vraiment faire.

Cependant, si vous vous intéressez à la philosophie derrière le Web3 et que vous voulez vraiment repousser les frontières de ce secteur, alors JAM est un projet qui mérite d'être étudié en profondeur. J'ai travaillé seul sur ce projet ces derniers temps, donc j'aimerais vraiment rencontrer d'autres passionnés, même juste pour lire le Gray Paper ensemble ou discuter. J'espère qu'on pourra échanger des idées, voire construire de nouvelles choses ensemble, surtout après la livraison du client.

Kristen : Merci pour ton partage, et un grand merci à nos invités pour leurs points de vue et analyses ! Merci à tous les auditeurs d'avoir participé aujourd'hui, je vous invite à suivre nos invités sur Twitter, leurs comptes sont dans les annonces de PolkaWorld. Que vous soyez utilisateur ou développeur, suivre les dernières avancées de JAM est très précieux. Merci à tous pour votre écoute, à la prochaine ! Au revoir !