Gavin Wood : Après l’EVM, JAM deviendra le nouveau consensus de l’industrie !

À la suite de l'article d'hier, nous partageons la seconde partie de la dernière interview de Gavin Wood !

Les blockchains publiques peuvent être en concurrence, mais les développeurs ne se rassemblent qu'autour du consensus.

Il y a dix ans, l'EVM inventée par Gavin est devenue un consensus ; depuis lors, l'ensemble du secteur dispose d'un « langage » commun.

Dix ans plus tard, Gavin lance à nouveau JAM, espérant qu'il devienne le prochain « langage » du secteur.

Ce n'est pas un outil pour une chaîne spécifique, mais un protocole de base permettant à toutes les chaînes d'obtenir une extensibilité élastique, une collaboration distribuée et une interopérabilité inter-réseaux.

N'importe quel constructeur peut bâtir son propre système dessus, voire permettre à différents tokens et écosystèmes de partager le même réseau de sécurité.

Pour les développeurs, cela signifie une chose :

Construire la prochaine génération de blockchain ne nécessite plus de repartir de zéro, JAM devient le nouveau point de départ par défaut.

L'atmosphère autour de JAM, je ne l'avais plus ressentie depuis 2015

Pala Labs : Actuellement, la tournée mondiale de JAM est à mi-parcours. Tu t'es rendu personnellement dans différents pays pour rencontrer les développeurs actifs de JAM ainsi que des supporters passionnés. Quel est ton ressenti sur ce modèle de construction décentralisée de JAM ?

Gavin : Jusqu'à présent, je suis très optimiste quant à l'avancement global de JAM. Les développeurs de JAM manifestent un enthousiasme et une proactivité rarement vus à l'époque du développement de Polkadot — ils aiment sincèrement ce projet et sont prêts à assumer une véritable responsabilité pour leur travail.

Pour comprendre cette différence, il faut revenir au mode de développement de Polkadot. À l'époque, le développement se faisait au sein d'une structure d'entreprise. Bien qu'il y ait eu des membres engagés et responsables, cette « proactivité » était en quelque sorte imposée par le système — tu reçois un salaire, assumer des responsabilités fait partie de ton travail.

Mais JAM est complètement différent. Les développeurs actuels n'ont pas de rémunération stable, ils investissent leur propre temps, énergie et prennent des risques. À l'avenir, ils pourraient effectivement recevoir des subventions ou des récompenses, mais à condition de livrer des résultats. À l'inverse, la logique de l'entreprise consiste à payer d'abord un salaire élevé, et c'est l'entreprise qui assume le risque si l'employé n'est pas à la hauteur.

Les développeurs de JAM assument donc eux-mêmes le risque, ce qui en dit long sur leur engagement. On a affaire à une équipe qui construit réellement pour une vision et qui est capable de produire des résultats. Dans cet environnement, on perçoit une foi rare — difficile à trouver chez les employés d'une entreprise traditionnelle.

En fin de compte, la structure organisationnelle d'une entreprise traditionnelle est essentiellement un système de pouvoir descendant : le patron détient le pouvoir de décision suprême, délègue aux cadres, qui à leur tour répartissent les tâches aux chefs d'équipe, et finalement les employés exécutent. Chacun doit rendre compte à son supérieur, suivre les instructions, et sa performance dépend du jugement de ses supérieurs.

Mais JAM n'est absolument pas ce modèle.

Dans ce projet, je suis davantage un conseiller, répondant aux questions lorsque c'est nécessaire — parfois de façon très concise, voire un peu directe, mais globalement amicale. En dehors de cela, je rédige le whitepaper gris et m'efforce de vérifier la faisabilité des conceptions, au moins pour me convaincre moi-même, et j'espère aussi permettre aux autres de comprendre la rationalité de ces solutions.

Cependant, ce qui fait vraiment avancer JAM, ce ne sont pas mes actions, mais les équipes de développement impliquées. Leur motivation peut être la passion, l'envie d'acquérir de l'expérience, ou la conviction que ce système aura une valeur commerciale à l'avenir. Mais quelle que soit la motivation, ils construisent ce système de manière proactive et spontanée.

Cette atmosphère, c'est la première fois depuis 2015 que je la ressens à nouveau, très similaire aux débuts d'Ethereum — chacun s'investissait avec passion ; même si le whitepaper gris était extrêmement complexe, ils étaient prêts à passer beaucoup de temps à le comprendre et à le transformer peu à peu en un logiciel réellement fonctionnel.

Après l'EVM, JAM deviendra le nouveau consensus de l'industrie

Pala Labs : On dirait que JAM n'est pas seulement un projet blockchain traditionnel, il semble dépasser le cadre de la blockchain et des crypto-monnaies, et même aller plus loin que Polkadot. Si tu devais expliquer JAM à quelqu'un qui ne connaît pas Polkadot, comment le présenterais-tu ? À quoi sert cet outil ?

Gavin : Pour faire simple, JAM est un protocole appelé « Join Accumulate Machine », dont la spécification complète est clairement écrite dans le whitepaper gris de JAM. Selon ce document, JAM combine les atouts principaux de Polkadot et d'Ethereum :

• D'une part, il hérite du mécanisme crypto-économique de Polkadot — c'est ce mécanisme qui soutient la grande extensibilité de Polkadot ;
• D'autre part, il adopte une interface et un modèle de service plus proches d'Ethereum, permettant à la chaîne principale d'être programmable.

Contrairement aux architectures traditionnelles qui ne rendent programmables que les modules de calcul haute performance, JAM va plus loin. Il permet non seulement de programmer les unités de calcul, mais aussi de contrôler par programmation le « processus de collaboration » et « l'effet cumulatif » entre différents modules — d'où le nom « Join Accumulate Machine ».

Bien que JAM ait été initialement proposé comme une mise à niveau de Polkadot et ait reçu un large soutien de la communauté, sa conception ne se limite pas à Polkadot. C'est une architecture de base hautement abstraite, indépendante de toute blockchain spécifique, qui peut être considérée comme la conception fondamentale de la prochaine génération de blockchains.

La capacité centrale de JAM réside dans sa faculté à orchestrer et répartir de manière sécurisée et distribuée la charge de travail sur l'ensemble du réseau, conférant ainsi aux applications une extensibilité élastique native — ce qu'aucune autre solution du secteur ne permet actuellement.

De plus, JAM permet d'interconnecter plusieurs instances de réseau, élargissant ainsi la portée des applications au-delà des limites d'une seule chaîne. Cela en fait non seulement une nouvelle architecture de chaîne, mais aussi un paradigme potentiel pour les solutions d'extensibilité de nouvelle génération.

Nous pouvons tout à fait considérer JAM en dehors du cadre de la « mise à niveau de Polkadot ». Comme je l'ai souligné en rédigeant le whitepaper gris : je suis meilleur pour créer de zéro que pour faire évoluer un système existant. Ainsi, la conception de JAM ne s'appuie pas sur une extension progressive d'un cadre existant, mais repart des principes fondamentaux pour bâtir un tout nouveau système à partir d'une page blanche.

Bien que JAM ait intégré certains acquis techniques de Polkadot, il a aussi introduit de nombreux concepts et mécanismes inédits. J'ai systématisé tout cela dans le whitepaper gris afin de l'extraire du contexte de Polkadot et d'en faire une architecture de base à valeur plus universelle — un peu comme le jeu d'instructions x64 à l'époque.

À ce propos, rappelons l'histoire du x64. Intel avait initialement conçu le jeu d'instructions x86 pour ses processeurs, évoluant du 8086 au 80286, 80386, puis à la série Pentium, devenant la norme pour les PC compatibles IBM et dominant longtemps le marché du desktop.

Mais à l'aube de l'ère 64 bits, la solution maison d'Intel était trop avant-gardiste et n'a pas été acceptée par le marché. AMD, alors considéré comme un « suiveur », a conçu une extension 64 bits plus simple et plus viable sur la base du jeu d'instructions 32 bits d'Intel — l'AMD64. Le marché a choisi la voie d'AMD, forçant Intel à abandonner sa propre solution pour adopter celle d'AMD. Dès lors, les rôles de leader et de suiveur se sont inversés.

Cette histoire est significative : même si Intel a adopté la technologie d'AMD, il ne voulait pas utiliser le nom « AMD64 », et le secteur a progressivement adopté l'appellation neutre « x64 ». Aujourd'hui, les deux fabricants construisent leurs produits sur cette architecture unifiée.

Si je cite cet exemple, c'est pour illustrer que JAM a le potentiel de devenir le « x64 technique » du secteur blockchain. Il est perçu comme la direction rationnelle de l'évolution de la blockchain, en particulier pour les blockchains publiques attachées à la résilience, à la décentralisation et aux principes du Web3. Le protocole maintient une grande ouverture dans des domaines comme le modèle de gouvernance, le mécanisme d'émission de tokens ou le système de staking, ce qui signifie que chaque projet blockchain peut personnaliser ces modules, voire choisir son propre langage de programmation en adoptant JAM.

Le PVM utilisé par JAM est une architecture de jeu d'instructions hautement générique. Les chaînes qui l'adoptent bénéficient de l'extensibilité et de la composabilité de JAM, et pourront à l'avenir réaliser la collaboration et l'intégration inter-chaînes via JAM.

Je réfléchis actuellement à une direction — j'espère pouvoir bientôt publier un article à ce sujet — sur la façon de permettre à deux blockchains basées sur JAM, mais utilisant des tokens différents, de fusionner davantage : partager le même réseau de sécurité tout en conservant leur propre système de tokens. Je crois que même si ce n'est pas la forme ultime de l'industrie blockchain, c'est déjà une percée majeure susceptible d'en changer la donne.

À plus grande échelle, JAM pourrait devenir, comme l'a été la technologie d'Ethereum à ses débuts, une base commune pour l'industrie. L'EVM d'Ethereum a déjà été adoptée ou partiellement intégrée par de nombreuses blockchains, et son format de transaction ainsi que sa logique d'exécution sont devenus des standards de fait. JAM possède le même potentiel de technologie neutre, inter-token et inter-réseau.

Comme je l'ai souvent répété, JAM doit être une technologie de base neutre. Je suis convaincu que sa conception peut soutenir le développement stable de l'industrie blockchain pour les cinq à dix prochaines années, voire plus. Bien sûr, le système continuera d'évoluer. Si la preuve à divulgation nulle de connaissance (ZK) devient économiquement viable, certains modules de JAM pourraient être remplacés. Mais dans l'ensemble, JAM, en tant qu'innovation systémique cohérente, ne sera jamais limitée à l'écosystème Polkadot : toute chaîne reconnaissant sa valeur pourra l'adopter dans son propre cadre de gouvernance.

De plus, JAM a dès le départ adopté les principes de décentralisation et de « spécification d'abord » : publier d'abord la spécification du protocole, puis organiser sa mise en œuvre, et mobiliser plus de 35 équipes indépendantes dans le monde pour participer au développement, assurant ainsi une distribution naturelle du savoir et du contrôle. Cette approche aidera JAM à devenir une technologie de base véritablement neutre et largement adoptée dans le monde Web3.

À l'ère « post-confiance », Gavin conseille aux jeunes développeurs : Web3 n'est pas un choix, c'est une responsabilité

Pala Labs : Nous avons rencontré de nombreux développeurs passionnés par JAM, dont beaucoup sont très jeunes, parfois encore étudiants, représentant la nouvelle génération du secteur. Si tu devais t'adresser à eux — ils te ressemblent peut-être il y a 20 ans, aimant créer, rêvant d'une société et d'un monde libres — que voudrais-tu leur dire ?

Gavin : Impliquez-vous tôt, et investissez-vous à fond. Vous devez suivre votre propre jugement de valeur. Si vous adhérez aux principes fondamentaux de la liberté de volonté et de la souveraineté individuelle issus du mouvement des Lumières, alors vous devez agir vous-même — car personne ne peut assumer cette responsabilité à votre place.

Pala Labs : L'intelligence artificielle ne risque-t-elle pas aussi de poser des problèmes d'usurpation d'identité ?

Gavin : Le système de confiance de la société actuelle s'effondre rapidement. Vers 2014-2015, un terme est devenu populaire — « l'ère post-vérité », signifiant que le public ne croit plus à l'existence d'une vérité objective. Bien que cette observation ait une certaine valeur, elle ne tient pas philosophiquement. J'ai toujours soutenu que la vérité existe, et que l'humanité a le devoir de la rechercher. Si une décision n'est pas fondée sur les faits les plus raisonnables et fiables du moment, elle sera forcément erronée.

Cela dit, nous sommes bel et bien entrés dans une « ère post-confiance » : les gens deviennent soit sceptiques envers tout, soit accordent leur confiance à des démagogues dangereux. Ces deux extrêmes sapent la rationalité de la société. Dans ce contexte, l'intelligence artificielle ne fera qu'amplifier le problème.

Bien sûr, l'IA a des aspects positifs dans de nombreux domaines, comme l'amélioration de la communication ou la création artistique. Moi-même, j'utilise souvent l'IA pour mixer ou composer de la musique. Mais sur les plans socio-économique, politique et géopolitique, les risques de l'IA sont loin d'être négligeables.

Nous ne pouvons pas compter sur la régulation. Elle ne fait souvent que restreindre l'accès à l'IA pour les citoyens respectueux des lois dans les sociétés libres, sans pouvoir empêcher les organisations malveillantes ou les États non libres d'utiliser l'IA pour attaquer les sociétés libres. Se fier uniquement à la régulation n'est donc pas la solution.

Ce qui est vraiment nécessaire, c'est de s'appuyer sur des bases technologiques plus solides et puissantes pour limiter les effets destructeurs potentiels de l'IA — qu'il s'agisse d'abus internes ou de menaces externes malveillantes.

À mon avis (même si c'est peut-être un peu biaisé), seule la technologie Web3 peut réellement résoudre ce problème. La raison est simple : l'IA consiste à « affaiblir la vérité, renforcer la confiance ». Lorsque nous dépendons de l'IA, nous dépendons en réalité des organisations qui fournissent les modèles et services — qu'il s'agisse d'institutions qui entraînent les grands modèles ou de prestataires qui exécutent les modèles sur des serveurs fermés et renvoient les résultats.

Mais nous ne pouvons pas auditer les données d'entraînement des modèles, ni savoir pourquoi ils donnent telle ou telle réponse ; même les formateurs ne comprennent pas forcément le fonctionnement interne du modèle. À l'inverse, il est plus fiable de laisser les individus vérifier eux-mêmes les faits. Mais à mesure que la société dépend de plus en plus de l'IA et lui fait confiance à la légère, les gens sombrent dans une « confiance aveugle, apparemment objective ».

Puisque la logique de l'IA est « moins de vérité, plus de confiance », nous devons utiliser une technologie comme Web3, qui offre « moins de confiance, plus de vérité », pour rétablir l'équilibre.

Dans une société libre, il ne s'agit pas de renforcer la régulation de Web3, mais d'agir rapidement : lever les restrictions inutiles et offrir un soutien concret et des financements à ceux qui construisent l'infrastructure Web3.

Pala Labs : De nombreux nouveaux développeurs rejoignent le projet JAM, peux-tu imaginer son évolution dans cinq ou six ans ?

Gavin : Prédire l'avenir est toujours difficile, mais je peux partager mon expérience. Fin novembre 2013, je vivais à Londres et j'avais un ami appelé « Johnny Bitcoin », également ami de Vitalik. Nous allions boire une bière chaque mois pour discuter. Lors d'une de ces rencontres, il m'a dit que son ami Vitalik travaillait sur un nouveau projet basé sur Bitcoin, appelé Ethereum, et cherchait quelqu'un pour développer le code. J'ai plaisanté : « D'accord, je m'en occupe. » J'ai toujours pensé être un bon programmeur, alors il a proposé : « Puisque tu es si doué, pourquoi ne pas développer Ethereum ? » C'est ainsi que je suis devenu l'un des développeurs d'Ethereum. À l'époque, le whitepaper d'Ethereum était à mi-chemin entre un document de vision et une spécification formelle, pas totalement sans ambiguïté mais suffisamment détaillé pour être réalisable. Durant les quatre ou cinq mois suivants, nous avons travaillé sur différents prototypes compatibles, ce qui a finalement abouti au yellow paper d'Ethereum — la spécification officielle du protocole. J'étais alors développeur indépendant sur ce protocole, avec Vitalik et Jeff, qui développait la version Go d'Ethereum. Plus tard, je suis devenu cofondateur d'Ethereum, j'ai fondé Parity et continué à développer d'autres produits liés.

Voilà comment j'ai commencé dans la blockchain — développeur indépendant, utilisant uniquement mon temps libre pour développer un protocole à partir de zéro.

Je ne sais donc pas si l'équipe de développement de JAM appréciera autant ce parcours que moi. Mais pour moi, c'était le point de départ de ma vie, je n'avais pas d'autre choix, et il s'est avéré que cette voie offrait des perspectives bien plus grandes que je ne l'imaginais.

Bien sûr, il ne s'agit pas seulement d'écrire du code, il faut aussi apprendre à communiquer : rencontrer des investisseurs potentiels, présenter le projet, concevoir des cas d'usage basés sur le protocole, écrire des smart contracts, promouvoir le projet, conseiller les autres, etc. Écrire du code n'est que le point de départ, mais c'est aussi le cœur de tout.

Au cours des 11 dernières années, je n'ai presque jamais arrêté de programmer. En fait, cela remonte à encore plus tôt : depuis l'âge de huit ou neuf ans, je n'ai presque jamais arrêté — la plus longue pause a été un voyage à pied en Amérique centrale, et cela n'a duré que trois mois.

C'est le chemin que j'ai suivi, et si ces nouveaux développeurs ont assez de passion et de compétences, à mon avis, rien ne peut les empêcher de suivre cette voie — sauf que cette fois, l'objectif est JAM et non Ethereum !