Auteur : PolkaWorld

Gavin Wood, co-fondateur d'Ethereum, créateur de Polkadot et promoteur de la vision Web3.

Avant de commencer officiellement, partageons quelques citations de Gavin sur cette partie !

Quel est le plus grand accomplissement d'Ethereum à ce jour ? – Peut-être CryptoKitties, je ne sais pas, en fait je ne suis pas très sûr. J'ai entendu dire qu'Ethereum avait créé le plus grand nombre de millionnaires de l'histoire.

Ethereum est-il un projet réussi ? – Selon mes critères de succès ? Évidemment, tous les critères ne sont pas remplis, et il est même possible qu'une très petite partie le soit. Bien sûr, il est financièrement réussi.

Avec l'introduction de JAM, la direction de Polkadot a changé. Cela peut être considéré comme une chaîne d'hébergement Rollup conçue de manière native, et la technologie que nous développons est bien supérieure aux Rollups optimistes et Rollups à connaissance nulle sur Ethereum.

Quel est le plus grand accomplissement de Polkadot jusqu'à présent ? – Avoir réalisé une blockchain fragmentée sécurisée.

Quel est le plus grand problème auquel Polkadot est confronté aujourd'hui ? – C'est la fragmentation.

Comment résoudre ces problèmes ? – JAM

Continuez à lire pour voir tout le contenu !

Quel est le plus grand accomplissement d'Ethereum à ce jour ?

Kevin : Donc, tu dis que tu as co-fondé Ethereum en 2014 ? Pourquoi as-tu rejoint en tant que co-fondateur et directeur technique ?

Gavin : Je pense que c'était une occasion rare, j'ai réalisé tout de suite que je devais la saisir et m'y investir à fond. Peut-être pas pour toute ma vie, mais au moins pour une période significative. C'était un projet innovant qui a émergé au bon moment, avec une équipe de personnes très talentueuses et dédiées, ainsi qu'un marché, bien que petit, très intéressé par les nouvelles choses et prêt à essayer. Pour être franc, j'étais très curieux à propos de ce projet, je pensais qu'il avait un énorme potentiel et pourrait aller très loin, tout en contribuant au principe du libéralisme éclairé tel que je le comprends.

Kevin : Qu'est-ce que c'est ?

Gavin : C'est essentiellement une vision optimiste de la société et du développement, cette pensée s'est probablement développée en Occident il y a quatre ou cinq siècles.

Kevin : Quel est le plus grand accomplissement d'Ethereum à ce jour ?

Gavin : Peut-être CryptoKitties, je ne sais pas, en fait je ne suis pas très sûr. J'ai entendu dire qu'Ethereum avait créé le plus grand nombre de millionnaires de l'histoire. Peut-être parce qu'il y avait beaucoup de participants lors de la collecte de fonds, et que le prix a ensuite augmenté suffisamment. Donc, cela pourrait être sa plus grande contribution. Mais honnêtement, il est difficile de dire combien de choses utiles il a réellement réalisées. Cela n'a certainement pas atteint mes attentes d'il y a 10 ans.

Kevin : Donc, si je te demande si tu penses qu'Ethereum est un projet réussi ? Ta réponse est-elle négative ?

Gavin : Ma réponse est, est-ce que je considère personnellement que c'est un succès ? Selon mes critères de succès ? Évidemment, tous les critères ne sont pas remplis, et il est même possible qu'une très petite partie le soit. Bien sûr, il est financièrement réussi. Je pense qu'il y a peut-être un ou deux co-fondateurs d'Ethereum qui s'attendaient à ce qu'il fonctionne mieux.

Kevin : Quels critères pourraient te faire considérer que c'est un succès ?

Gavin : Utilité (Utility)

Kevin : Comment évaluer l'utilité ?

Gavin : La façon d'évaluer l'utilité est de regarder combien de choses les gens peuvent faire maintenant qu'ils ne pouvaient pas faire auparavant.

Kevin : N'est-ce pas un problème de toute l'industrie crypto, et pas seulement d'Ethereum ?

Gavin : En effet. C'est en fait un problème auquel toute l'industrie crypto est confrontée. En 2014 et 2015, nous avons proposé de nombreuses idées pour essayer de débloquer certains domaines économiques qui étaient auparavant inaccessibles grâce à une approche « sans confiance ». L'un des exemples que j'aime particulièrement est la chaîne d'approvisionnement. Par exemple, lorsque vous allez au supermarché, tous les produits ont un code QR, vous pouvez scanner le code QR pour connaître tous les composants de ce produit : quand, où et combien, etc. J'aimerais savoir d'où vient le coton lorsque j'achète un T-shirt.

Maintenant, il est très difficile de réaliser cela dans un modèle centralisé, et cela coûte cher. Mais je pense que c'est possible avec une approche décentralisée. Cependant, ces applications n'ont pas vraiment été déployées. Bien qu'il y ait actuellement quelques projets crypto liés à la chaîne d'approvisionnement, ils sont très de niche, limités à des segments spécifiques du marché. Cela n'a pas tenu ses promesses dans cette direction.

Et ce n'est pas seulement un problème de chaîne d'approvisionnement, je pense que l'imagination de l'industrie crypto est riche, mais il est difficile de traduire cette imagination en actions réelles et en applications de marché réelles, ce qui est vraiment regrettable. Je pense que la principale raison n'est pas un problème technique, bien que la technologie soit effectivement en retard par rapport à notre vision, surtout que la technologie de base a besoin de beaucoup d'améliorations. C'est aussi pourquoi je travaille maintenant sur JAM, essayant d'améliorer la technologie de base pour qu'elle puisse soutenir les idées que je pense être valables et aider l'industrie crypto à jouer un plus grand rôle.

Mais il ne suffit pas d'améliorer la technologie. Vous devez également permettre aux gens de comprendre sa valeur. Et c'est difficile, en partie parce que vous luttez contre l'économie de l'attention.

Pourquoi quitter Ethereum ?

Kevin : Pourquoi es-tu parti d'Ethereum en 2016 ?

Gavin : En fait, c'était à la fin de 2015. À l'époque, nous avons décidé qu'Ethereum avait besoin de faire beaucoup de choses pour être plus largement adopté. Nous étions à la recherche d'investissements externes, et l'une des façons les plus évidentes était de créer une startup liée à Ethereum et d'en rechercher un financement externe. C'était une décision initiale de Vitalik et Jeff (le développeur et ingénieur principal) de le faire.

Ensuite, Jeff ne s'est pas vraiment adapté à la vie de startup. En fait, il est rapidement parti d'Ethereum pour poursuivre sa carrière dans les jeux vidéo. À ce moment-là, il ne restait plus que Vitalik. Vitalik a estimé qu'il était nécessaire de rester à la Fondation Ethereum et de jouer un rôle plus académique, tout en étant consultant pour la filiale que nous avions alors créée, Ethcore.

Nous avons levé des fonds et amené environ la moitié de l'équipe technique d'Ethereum à Ethcore, et développé un client Ethereum. J'ai quitté la Fondation Ethereum à la fin de 2015 pour créer cette filiale, afin d'ajouter une entité soutenue par des fonds privés dans l'écosystème Ethereum.

Cependant, j'ai vraiment complètement quitté l'écosystème Ethereum à la fin de 2017, lorsque j'ai créé Polkadot.

Polkadot développe une technologie Rollup

Kevin : Si tu devais expliquer à ta mère ce qu'est Polkadot ? Que dirais-tu ?

Gavin : Eh bien... Polkadot a connu quelques changements au fil des ans. La vision initiale était d'intégrer différentes architectures de blockchain pour qu'elles puissent être compatibles et partager le même cadre de sécurité. Grâce à ce cadre de sécurité partagé, il est possible d'améliorer considérablement l'efficacité économique. Par exemple, si conçu correctement, il est possible de protéger 100 chaînes avec le même coût, au lieu d'exiger que chaque chaîne soit protégée indépendamment, comme dans d'autres conceptions (comme Cosmos).

Au fil des ans, Polkadot a essayé de se différencier de Cosmos sur ce point. Parce que dans le modèle de Cosmos, chaque chaîne doit assumer sa propre sécurité. Tandis que Polkadot résout ce problème par la sécurité partagée. Mais malheureusement, ces deux approches traitent en réalité des problèmes très différents. Avec le recul, je pourrais être plus enclin à décrire Polkadot comme un "système de fragmentation", plutôt que comme un "système multi-chaînes". Avec le recul, cette formulation est très clé pour expliquer et transmettre l'idée centrale de Polkadot. En particulier lors de la communication ou de la promotion de Polkadot, cette distinction aide à décrire plus clairement ses caractéristiques techniques et sa différence avec d'autres projets (comme Cosmos).

Maintenant, avec l'introduction de JAM, cette direction a connu quelques changements. La technologie que nous développons pour Polkadot peut être considérée comme une technologie Rollup, et Polkadot lui-même peut être considéré comme une chaîne d'hébergement Rollup spécifiquement conçue. Le développement et la conception de cette technologie ne sont pas simples, donc il n'est pas surprenant que nous voyions d'autres deux technologies concurrentes être bien moins efficaces que celles que nous avons développées pour Polkadot. Plus précisément, il s'agit des Rollups optimistes et des Rollups à connaissance nulle, qui ont tous deux été utilisés sur Ethereum. Ainsi, nous pouvons décrire Polkadot comme une chaîne d'hébergement Rollup conçue de manière native – bien sûr, cette affirmation peut ne pas convenir pour expliquer à maman, mais elle est acceptable pour ceux qui sont familiers avec le domaine crypto.

Avec JAM, qui est l'objectif de développement futur de Polkadot, nous essayons de faire évoluer Polkadot d'un modèle multi-chaînes à un modèle de ressources de calcul plus générique. Dans le modèle multi-chaînes, les différentes chaînes de Polkadot (appelées chaînes parallèles dans l'écosystème Polkadot) partagent le même cadre de sécurité et peuvent interagir les unes avec les autres. Dans le nouveau modèle, notre objectif est d'élargir davantage le champ d'application de Polkadot, tout comme Ethereum a transformé les fonctionnalités de base de Bitcoin en une ressource de calcul universelle. Nous souhaitons éliminer des restrictions de conception trop subjectives, permettant à Polkadot de prendre en charge des cas d'utilisation plus variés.

Alors, quel est l'avenir de Polkadot ? Fondamentalement, il deviendra un grand ordinateur partagé qui fonctionnera toujours comme vous vous y attendez. Sur cet ordinateur partagé, vous pouvez télécharger des programmes qui peuvent être des services pour résoudre des problèmes spécifiques. Étant donné que c'est un ordinateur partagé, ces services peuvent interagir et se coordonner entre eux.

L'essentiel, c'est que c'est un grand ordinateur partagé unique. Ce que nous ne voulons pas faire, c'est le diviser en différentes parties, qui ne peuvent pas vraiment interagir entre elles.

Le plus grand accomplissement de Polkadot est son plus grand problème

Kevin : Je pense que tu fais peut-être référence à un fait que nous connaissons tous, et qui a en réalité causé beaucoup de confusion dans l'écosystème Ethereum aujourd'hui. Alors, quel est le plus grand accomplissement de Polkadot jusqu'à présent ?

Gavin : Avoir réalisé une blockchain fragmentée sécurisée.

Kevin : Quel est le plus grand problème auquel Polkadot fait face aujourd'hui ?

Gavin : C'est la fragmentation.

Kevin : Que signifie cela concrètement ?

Gavin : La fragmentation a toujours été considérée comme le "Saint Graal" de l'expansion des blockchains, son concept provient de la conception de bases de données. Dans une base de données, vous pouvez diviser une base de données (essentiellement un ensemble d'enregistrements) en plusieurs fragments. Chaque fragment fonctionne de manière indépendante, et les fragments ne peuvent interagir que dans certaines interfaces très précises, par exemple, un enregistrement peut se déplacer d'un fragment à un autre.

Un exemple physique simple peut aider à comprendre. Imaginez un bureau des années 60, comme un cabinet médical, où sont conservés les dossiers médicaux des patients. Ces dossiers sont généralement gardés dans des tiroirs anciens. Si les dossiers ne concernent que 20 personnes, un tiroir peut suffire et il est facile de les trier par ordre alphabétique. Mais si les dossiers dépassent la capacité d'un tiroir, par exemple, s'il y a plus de personnes, vous devez répartir les dossiers dans plusieurs tiroirs. Si le nombre de tiroirs continue d'augmenter, par exemple s'il faut quatre ou cinq tiroirs, vous aurez également besoin de plusieurs meubles de rangement.

Chaque tiroir peut être considéré comme un fragment. Ils fonctionnent de manière indépendante : vous pouvez ouvrir un tiroir sans ouvrir les autres, et vous pouvez rechercher dans un tiroir sans avoir à consulter tous les tiroirs. Cela contraste avec le fait d'avoir un tiroir particulièrement long (par exemple, un tiroir de 10 mètres). S'il n'y a qu'un long tiroir, cela n'est clairement pas pratique, car vous avez besoin d'une pièce de 10 mètres pour le loger. Et lorsque vous cherchez quelqu'un dont le nom commence par "W", vous devrez probablement tirer tout le tiroir et marcher jusqu'à la position "W", ce qui est clairement inefficace.

Ainsi, d'un certain point de vue, le design de la fragmentation est raisonnable. Cependant, cela pose également des problèmes. Par exemple, que faire si un tiroir est plein ? Vous pourriez avoir besoin de réajuster la répartition des dossiers, par exemple, changer les dossiers de A à E en A à D, puis déplacer les dossiers commençant par E vers le tiroir en dessous. Mais cela pourrait également amener le tiroir suivant à ne pas avoir suffisamment de place, donc vous devrez ajuster à nouveau, et chaque ajustement nécessite également de changer l'étiquette à l'extérieur du tiroir. Tout ce processus peut devenir complexe et fastidieux.

Ainsi, la fragmentation apporte également sa propre série de problèmes.

L'essentiel est que ces "tiroirs" (fragments) fonctionnent de manière indépendante, que ce soit dans la conception de blockchain fragmentée ou dans la conception de bases de données. Essentiellement, les données resteront fragmentées après avoir été divisées, à moins que vous n'effectuiez une opération très spéciale, qui est généralement très chronophage, coûteuse et gourmande en ressources, pour déplacer des enregistrements ou des données d'un tiroir (fragment) à un autre. Cela signifie que réorganiser des enregistrements dans un tiroir unique peut être facile, mais il est très difficile de réorganiser des enregistrements entre différents tiroirs. C'est précisément le problème de la fragmentation. Pour les données, ce n'est peut-être pas un problème grave, c'est pourquoi la fragmentation est largement adoptée dans la conception de bases de données. Mais pour les services, comme les contrats intelligents qui nécessitent des interactions fréquentes et des changements, cette approche n'est pas idéale. Si les contrats intelligents sont considérés comme des objets placés dans des tiroirs, et que vous souhaitez que le contrat intelligent d'un tiroir interagisse avec celui d'un autre tiroir, vous devez ouvrir les deux tiroirs simultanément. Cela signifie que vous devez tirer les deux tiroirs, les connecter ensemble, exécuter toutes les opérations d'interaction nécessaires aux contrats intelligents, puis les séparer et les remettre dans leurs tiroirs respectifs. Ce processus est complexe et inefficace, et ne convient pas aux cas d'utilisation nécessitant des interactions fréquentes.

Si vous ne travaillez qu'entre deux tiroirs, c'est déjà assez difficile, mais si vous souhaitez que plusieurs tiroirs interagissent simultanément, cela devient très complexe et très difficile. L'un des problèmes de cette approche est que vous empêchez l'interaction libre entre les tiroirs, ce qui signifie que les autres contrats intelligents dans les tiroirs ne peuvent suivre qu'un seul modèle d'interaction. Tout le système devient rapidement complexe, difficile et inefficace.

Une autre façon de procéder est de permettre aux tiroirs de communiquer entre eux par l'envoi de messages. Un tiroir (fragment) peut publier un message, qui sera ensuite transmis à un autre tiroir. C'est exactement ce que Polkadot fait avec XCM (Cross-Consensus Messaging). Bien que cette approche soit possible, le problème est qu'elle ne permet pas d'obtenir ce type d'interaction étroite, efficace et flexible, et elle est loin d'être aussi fluide que lorsque tout fonctionne dans le même espace ou "terrain de jeu".

Prenons un exemple, supposons qu'une école a quatre terrains de jeux différents, correspondant à quatre blockchains différentes. Si vous jouez à "cache-cache" sur l'un des terrains, cela ne pose pas de problème, le jeu peut se dérouler sans accroc. Mais si vous devez jouer à "cache-cache" entre deux terrains, cela devient très difficile. Vous devez envoyer un message à l'autre terrain, par exemple, "Je suis maintenant celui qui cherche, si tu entres dans cette zone, je te prendrai." Et le joueur de l'autre terrain doit le savoir, mais ne peut pas comprendre complètement, et tout le jeu devient rapidement chaotique.

Ainsi, "cache-cache" est un jeu qui ne peut être joué que sur un seul terrain. C'est précisément le problème entre les fragments, les interactions entre fragments sont comme des tentatives de jouer à un jeu entre terrains de jeux, ce qui est difficile à réaliser efficacement.

Si certaines solutions doivent fonctionner de manière très asynchrone, il sera très difficile de les faire fonctionner correctement. C'est comme ne pouvoir jouer qu'à travers des messages. Si c'est un jeu comme les échecs, cela peut ne pas être trop difficile ; mais si c'est un jeu comme cache-cache, cela devient pratiquement impossible.

La situation est similaire pour les contrats intelligents. Certains contrats intelligents ne fonctionnent pas trop mal dans ce modèle, peut-être juste un peu plus lent que la normale, mais ce n'est pas un gros problème. Et certains cas d'utilisation, comme la validation d'identité (KYC), sont relativement simples. Par exemple, vous pourriez avoir une chaîne dédiée à la validation d'identité, et une autre chaîne pour gérer les transferts. La chaîne de transfert pourrait avoir besoin de vérifier si l'adresse cible a passé la validation KYC et AML avant d'exécuter le transfert. Elle peut envoyer un message demandant, "Cette adresse a-t-elle passé la validation KYC et AML ?" La chaîne de validation d'identité répond "Oui", puis la chaîne de transfert exécute le transfert. Tout le processus peut prendre un peu plus de quelques secondes, mais ce n'est pas un gros problème.

Cependant, il existe d'autres cas d'utilisation, comme les échanges décentralisés (DEX), qui sont beaucoup plus complexes. Par exemple, vous devez demander le prix actuel, puis décider si vous tradez. À ce moment-là, vous pourriez avoir besoin d'envoyer un message à une autre chaîne, et cette autre chaîne répond "Le prix actuel est celui-ci, le trade peut être effectué de cette manière." Ensuite, le message revient à la chaîne d'origine, qui confirme "J'accepte ce prix, veuillez exécuter le trade." Mais juste avant que le trade ne soit exécuté, l'autre chaîne pourrait dire "Le prix a changé, c'est maintenant ce prix." Les messages vont et viennent, et rapidement tout le processus devient très inefficace, voire impossible à réaliser efficacement.

Ainsi, dans ce genre de situation, les transactions doivent être presque simultanées, sinon elles ne peuvent pas être effectuées. Ce phénomène est similaire aux jeux joués dans un terrain de jeu. Certains jeux, comme cache-cache, ne peuvent être complétés que dans le même espace, une interaction asynchrone rendrait le jeu complètement impossible.

La solution est JAM

Kevin : Quelle est la solution viable ?

Gavin : Eh bien, JAM est ma proposition, Join Accumulate Machine (Machine d'accumulation de connexion).

Kevin : Qu'est-ce que JAM ?

Gavin : JAM est une façon flexible de rassembler les joueurs de différents "terrains de jeu", créant un terrain de jeu temporaire où ils peuvent jouer à cache-cache. Voici un exemple improvisé (peut-être un peu fou, désolé). Pour continuer avec l'exemple de cache-cache : Supposez qu'il y ait quatre terrains de jeu fixes, dans la conception de JAM, il n'y a plus de terrains de jeu fixes.

Les terrains de jeu ne sont plus fixes, et les joueurs ne sont plus contraints à un terrain spécifique, et le coût de déplacement entre différents terrains de jeu n'est pas si élevé. Au lieu de cela, nous avons une vaste zone de jeu où les terrains de jeu peuvent rapidement se former et disparaître. Dans ce cas, nous nous concentrerions sur les joueurs dans le jeu, rassemblant temporairement ceux qui sont proches les uns des autres, susceptibles de se "prendre", pour créer un terrain de jeu temporaire où ils peuvent continuer à jouer à cache-cache.

Lorsque certains de ces joueurs sortent de ce terrain de jeu temporaire, nous ajustons à nouveau la position du terrain de jeu, redéfinissant une nouvelle portée de terrain basée sur ceux qui sont toujours proches les uns des autres. Si certains joueurs sont très éloignés, nous savons qu'ils ne se "prendront" pas dans un avenir proche, donc ils n'ont pas besoin de participer à ce terrain de jeu. Ils sont temporairement dans un état de "hors du jeu" jusqu'à ce qu'ils se rapprochent à nouveau d'autres joueurs et aient besoin de participer au jeu, à ce moment-là, ils seront inclus dans le nouveau terrain de jeu.

Si nous réalisons le système de cette manière plus flexible, nous pouvons imaginer un système qui peut à la fois évoluer et prendre en charge des combinaisons synchrones. Son cœur réside dans le fait qu'il ne divisera pas de manière permanente les soi-disant "états". En d'autres termes, les joueurs ne seront pas fixés à un terrain de jeu particulier, mais seront regroupés dynamiquement en temps réel selon les besoins. Le système regroupant les joueurs en fonction des besoins réels, et faisant avancer le jeu selon ces regroupements.

Dans le contexte des contrats intelligents, la réalisation de ce concept ressemble à mettre tous les contrats intelligents dans un grand "four" partagé, mais ce four ne les pousse pas à interagir les uns avec les autres tout le temps, mais peut se diviser dynamiquement. Par exemple, le système peut extraire 10, 50 ou 2 contrats intelligents de ce four, les regrouper, leur permettre d'interagir et de fonctionner ensemble, puis les séparer. Ensuite, évaluer à nouveau, sélectionner un autre ensemble de contrats intelligents différent, les regrouper à nouveau, puis les séparer.

Cette approche nous permet de traiter plusieurs groupes de contrats intelligents parallèles simultanément, plutôt que de ne pouvoir faire fonctionner qu'un seul groupe de contrats intelligents de manière synchronisée. Grâce à cette méthode de traitement parallèle, nous pouvons augmenter considérablement la capacité de traitement des interactions du système, prenant en charge des volumes d'interaction des centaines de fois plus que les méthodes traditionnelles, réalisant ainsi une véritable évolutivité.