Gavin Wood : Quelles leçons avons-nous tirées du passage de Polkadot 1.0 à JAM ?
TechFlow SélectionTechFlow Sélection
Gavin Wood : Quelles leçons avons-nous tirées du passage de Polkadot 1.0 à JAM ?
Gavin a principalement partagé quelques histoires intéressantes sur sa vie avant de commencer Ethereum, ainsi que ses réflexions et enseignements tirés du passage de Polkadot 1.0 à JAM.
Dédié à des analyses Web3 approfondiesTraduction : PolkaWorld
Il y a quelques mois, Gavin a été interviewé par Raoul Pal. Bien que cette vidéo ne soit pas récente, certaines des idées partagées par Gavin méritent toujours d'être connues ! Comme d'habitude, nous publierons cet entretien en deux parties. Voici la première partie ! Gavin y raconte notamment des anecdotes intéressantes sur ses débuts avant Ethereum, ainsi que ses réflexions et enseignements tirés du passage de Polkadot 1.0 à JAM.
Commençons par une série de citations marquantes :
-
Ethereum n’était pas simplement une copie de Bitcoin ; il s’agissait vraiment d’explorer de nouveaux territoires. Personne n’avait encore commencé à le construire, et je savais que j’étais capable de créer quelque chose de nouveau depuis zéro.
-
D’un certain point de vue, Polkadot représente ma tentative de contribuer davantage techniquement au domaine Web3. Cette idée est née de mes réflexions sur ce qu’aurait pu être Ethereum 2.0.
-
Si l’on ne peut pas étendre les capacités du système en améliorant les performances d’un seul nœud, alors il faut adopter une approche d’« extension horizontale ».
-
Je suis fermement convaincu qu’avoir un unique parapluie de sécurité est la solution la plus logique. À mes yeux, un modèle de sécurité fragmentée n’a aucun sens.
-
Le plus grand changement dans ma vision autour de Polkadot concerne ce que j’appelle la « fragmentation continue de l’état ». Nous ne devrions pas figer cette fragmentation continue comme un modèle fixe ; nous devrions plutôt adopter une fragmentation plus souple et temporaire.
-
Aujourd’hui, la définition de « parachain » peut être largement assouplie : toute chaîne capable de s’intégrer au modèle général de « l’ordinateur mondial » JAM peut être considérée comme une parachain.
-
La question centrale est celle de la scalabilité : non seulement augmenter la quantité de données entrantes et sortantes, mais aussi améliorer l’efficacité du traitement des données dans le système. Ce n’est qu’en augmentant ces capacités de plusieurs ordres de grandeur que nous pourrons véritablement soutenir des cas d’usage concrets, et migrer les applications Web2 existantes vers Web3.
-
L’objectif de JAM est de permettre l’exécution directe de code proche du code informatique classique, sans passer par des contrats intelligents, sans optimisation complexe de gas, et avec un coût minimal pour téléverser et exécuter du code, afin d’attirer les utilisateurs.
-
Dès que Web3 deviendra une alternative valable à Web2, un marché suffisamment vaste sera ouvert, et même si le coût de l’espace bloc tend vers zéro, il subsistera une valeur suffisante pour rémunérer les validateurs qui maintiennent le réseau.
-
Si l’espace bloc est suffisamment bon marché, presque gratuit, alors la question ne porte plus sur les barrières d’entrée ou les scénarios d’utilisation, mais sur leur utilité réelle, leur existence d’un public et d’un marché.
Poursuivez la lecture pour en savoir plus !
L’histoire de Gavin avant Ethereum
Raoul Pal : Votre parcours personnel est particulièrement fascinant. Si vous le souhaitez, pourriez-vous revenir en arrière et nous parler de vos débuts ? Par exemple, comment êtes-vous arrivé dans ce domaine, avant même Ethereum ?
Gavin : J’ai toujours été passionné d’économie et de théorie des jeux. J’ai fait des études d’informatique, mais j’ai découvert Bitcoin pour la première fois en février ou mars 2013, en lisant un article sur Amir Taaki, un développeur Bitcoin se définissant comme cypherpunk et anarchiste cryptographique. Il semblait être une figure très intrigante, et j’ai pensé qu’il serait intéressant de le rencontrer et d’entendre sa vision du monde. J’étais également intéressé par l’idée de contribuer à des projets Bitcoin, donc je lui ai envoyé un e-mail. Il m’a répondu, et nous nous sommes rencontrés dans un immeuble abandonné à Londres — mon tout premier contact avec un tel lieu. Il m’a présenté à plusieurs personnes du cercle Bitcoin, dont Mihai Alisie et sa petite amie Roxana. Elle était assise sur un matelas, dans une pièce ressemblant à un bureau, située dans ce bâtiment désaffecté autrefois utilisé comme siège social. J’étais un peu surpris par ce cadre inhabituel pour une première rencontre.
Par la suite, Mihai est devenu mon cofondateur à Ethereum, donc bien que cette première rencontre ait été étrange, elle fut hautement significative. Il m’a également mis en relation avec d’autres acteurs du Bitcoin à Londres, spécialisés dans les points d’échange Bitcoin Cash. Grâce à eux, j’ai gardé le contact, et c’est finalement par eux que j’ai rencontré Vitalik. J’ai lu le white paper d’Ethereum de Vitalik fin 2013, et j’ai commencé à écrire du code.
Raoul Pal : Quand vous avez lu pour la première fois le white paper d’Ethereum et discuté avec Vitalik, qu’est-ce qui vous a fait penser que ce serait un moment décisif ? Qu’est-ce qui rendait Ethereum plus attrayant que Bitcoin ? Après tout, vous auriez pu rester dans l’écosystème Bitcoin, mais vous avez choisi Ethereum.
Gavin : Je pouvais effectivement rester dans l’écosystème Bitcoin. Mais quand on construit quelque chose, on cherche l’endroit où l’on peut apporter le plus de valeur. Bitcoin avait déjà son équipe, son client, sa communauté — un système mature. Ethereum, en revanche, n’était pas une simple copie de Bitcoin ; il cherchait réellement à repousser les limites. Personne n’avait encore commencé à le construire, et je savais que je pouvais créer quelque chose de nouveau dès le départ. À ce moment-là, j’ai senti que mon expertise et ma contribution auraient plus d’impact dans la construction d’un projet entièrement nouveau, où mes compétences pourraient pleinement s’exprimer.
Êtes-vous surpris par le succès d’Ethereum ?
Raoul Pal : Avez-vous été surpris par son succès, ou pensiez-vous dès le départ que ce serait la prochaine grande avancée ? À l’époque, beaucoup d’autres blockchains émergeaient. Le succès d’Ethereum vous a-t-il pris au dépourvu ?
Gavin : Si j’avais vraiment été surpris, je n’aurais probablement pas investi aussi profondément. On ne peut jamais totalement prédire le résultat, car cela dépend de nombreux facteurs, pas seulement du fait qu’un projet soit légèrement ou nettement meilleur. Mais j’avais bel et bien un pressentiment. Ce pressentiment s’est renforcé en janvier 2014, lorsque je me suis rendu à Miami et ai rencontré plusieurs cofondateurs, découvrant pour la première fois l’ambiance de la communauté Bitcoin. C’était lors d’une grande conférence Bitcoin en Floride, dans une atmosphère très animée, pleine de fêtes. Vitalik m’avait invité à participer à un hackathon à Miami, disant que nous terminerions le codage là-bas. Je suis donc parti à Miami, pensant travailler avec l’équipe pendant une semaine, mais je me suis retrouvé dans une sorte de maison de fête, le seul à coder. Malgré cela, cette expérience m’a permis de ressentir l’enthousiasme et l’excitation ambiants.
Il y avait d’autres projets à l’époque — vous vous souvenez peut-être de Mastercoin, très populaire, basé sur l’idée : « Voici Bitcoin, mais vous pouvez y créer des outils financiers. » Il y avait aussi Counterparty, similaire à Mastercoin mais destiné à d’autres usages. Et NXT, une version PoS (preuve d’enjeu) de Bitcoin. Pour moi, il était clair qu’Ethereum offrait bien plus de possibilités que ces autres blockchains naissantes.
Avec cette ambiance électrique, et en voyant que les autres cofondateurs étaient des moteurs importants, j’ai senti qu’Ethereum avait une réelle chance de devenir très grand.
Pourquoi avoir créé Polkadot ?
Raoul Pal : Qu’est-ce qui vous a poussé à créer votre propre blockchain ? Je me souviens qu’on m’a parlé de Polkadot lors d’un de mes panels vers 2012 ou 2013, probablement avant son lancement officiel. On m’a dit que ce projet était crucial, mais je ne comprenais absolument pas ce qu’était l’« interopérabilité ». Je me suis dit que ça sonnait bien, mais je n’avais aucune idée de ce que vous disiez. Pourriez-vous raconter l’histoire de Polkadot ? Comment cette idée vous est-elle venue ? Parlons de ce parcours, de ce que vous pensez avoir eu raison ou tort, et de la direction future.
Gavin : D’un certain point de vue, Polkadot est ma tentative de contribuer davantage techniquement au domaine. Cette idée est née de mes réflexions sur ce qu’aurait pu être Ethereum 2.0, ou sur la manière dont devrait fonctionner un successeur à Ethereum. J’ai toujours pensé que cela prendrait probablement la forme d’une architecture multi-chaînes, composée de nombreuses chaînes différentes. Avant même que le concept de Polkadot ne prenne forme, je pensais que ces chaînes exécuteraient toutes la même fonctionnalité — comme Ethereum, toutes basées sur la machine virtuelle Ethereum (EVM), selon le modèle d’Ethereum 1.0.
Je pensais alors à une structure avec une chaîne principale similaire à la « Beacon Chain » d’Ethereum, que nous appelons dans Polkadot la « Relay Chain ». Cette chaîne supérieure garantirait que toutes les sous-chaînes fonctionnent correctement. Mais ensuite, j’ai réalisé que ces chaînes n’avaient pas besoin de faire exactement la même chose — en fait, il serait peut-être plus simple qu’elles soient différentes. Elles pourraient être spécialisées dans différents domaines, comme ce qu’on appelle aujourd’hui des « application chains ».
Bien que leurs fonctions diffèrent, elles partagent une même sécurité, ce qui leur permet d’interagir facilement et d’assurer l’interopérabilité. Ce terme a plusieurs sens, ce qui peut prêter à confusion. Ici, j’entends par interopérabilité la capacité de ces chaînes à interagir de manière sécurisée dans un même cadre de sécurité, avec des interactions causales directes.
Bien sûr, nous avons appris beaucoup de choses au cours de ce processus. Fondamentalement, c’était une expérience. Nous ne savions pas avec certitude quelle valeur pratique aurait ce niveau d’interopérabilité comparé à l’interopérabilité synchrone et composable d’Ethereum — où les contrats peuvent s’appeler mutuellement et répondre instantanément. Toutefois, en remontant aux origines de Polkadot, l’idée centrale était de regrouper différentes chaînes sous un même cadre de sécurité, chacune spécialisée dans un domaine précis.
Raoul Pal : En réalité, vous aviez anticipé l’ère du monde multi-chaînes bien avant que cela ne devienne une idée courante. Beaucoup ont critiqué cette vision, pensant qu’il n’y aurait qu’un seul monde EVM ou un seul monde Bitcoin. Pourtant, vous avez envisagé dès le départ la coexistence de multiples chaînes différentes.
Gavin : Ce n’était pas une position idéologique, mais une nécessité technique liée à la scalabilité. À l’époque, tout le monde parlait d’extension, car Ethereum était excellent, mais non scalable. La question devenait donc : comment rendre le système extensible ? La réponse : paralléliser le traitement. On peut étendre verticalement, comme Solana tente de le faire, en utilisant des validateurs de plus en plus rapides et en rapprochant leurs connexions. Mais on atteint vite un goulot d’étranglement, surtout si l’on veut préserver les caractéristiques Web3 — le seuil d’entrée augmente, il devient de plus en plus difficile de participer. Les validateurs ont besoin de matériel très puissant, excluant beaucoup de monde.
Si l’on ne peut pas étendre le système en améliorant les performances d’un seul nœud, il faut adopter une approche d’« extension horizontale ». C’est une philosophie classique de la Silicon Valley : l’évolutivité passe par la répartition de la charge entre plusieurs nœuds. Concrètement, diviser la charge en tâches plus petites, assignées à différents nœuds. C’est précisément le cœur de la vision de Polkadot.
Initialement, je ne pensais pas que chaque segment devait former une chaîne indépendante conservant longtemps son état. En fait, les tâches pourraient être attribuées de façon plus souple et temporaire. Toutefois, l’idée fondamentale de diviser et distribuer la charge pour étendre le réseau est inévitable.
Quelles sont les réflexions de Gavin entre Polkadot 1.0 et JAM ?
Raoul Pal : Comment vos hypothèses ont-elles évolué ? Qu’est-ce qui vous a poussé à agir différemment ? Vous construisez continuellement un nouvel univers autour de Polkadot — qu’est-ce qui vous pousse à repousser encore les limites ?
Gavin : Le changement le plus important concerne ce que j’appelle la « fragmentation continue de l’état ». Je reste convaincu qu’un unique parapluie de sécurité est la solution la plus rationnelle. Un modèle de sécurité fragmentée n’a aucun sens. Le modèle initial de Cosmos, et même actuel, repose sur une sécurité décentralisée — même si les équipes de Cosmos essaient maintenant d’implémenter une sécurité partagée, cela reste insuffisant. Je crois aux modèles d’Ethereum et de Polkadot, avec un unique parapluie de sécurité, combiné à une parallélisation dans ce cadre.
Le changement porte surtout sur la manière et la structure de cette parallélisation. La principale différence entre ma vision de Polkadot 1.0 et celle présentée récemment dans le livre gris sur JAM, c’est que le modèle de Polkadot 1.0 repose sur une « fragmentation continue ». Autrement dit, nous avons plusieurs blockchains, chacune avec son propre état, fonctionnant isolément. Bien que la sécurité soit uniforme, chaque chaîne opère indépendamment, avec ses propres validateurs et règles de transition d’état. Elles peuvent s’envoyer des messages via XCM, mais ce mode d’interaction est grossier, bien moins fin que les appels entre contrats intelligents sur Ethereum. J’ai compris que cela limite fortement les combinaisons possibles et les modèles d’utilisation de l’espace bloc. Il en résulte que nous ne devrions pas figer la « fragmentation continue » comme modèle permanent. Au contraire, adoptons une fragmentation plus souple et temporaire.
Ainsi, la fragmentation de l’état concerne un état global unique, plutôt que des divisions durables aux frontières des blockchains. Nous redéfinissons arbitrairement cette fragmentation environ toutes les six secondes. Bien sûr, cela soulève la question de la mise en œuvre, sur laquelle nous réfléchissons activement. Notre approche consiste à ne pas figer cette fragmentation au niveau du protocole, mais à la réajuster selon les besoins des nouveaux cas d’usage, bloc après bloc.
Nous transformons donc progressivement la Relay Chain de Polkadot — initialement conçue pour assurer la sécurité et transmettre des messages entre différents écosystèmes blockchain — en une sorte d’« ordinateur mondial », similaire à une machine virtuelle multicœur omniprésente, capable d’héberger des programmes. Notre objectif est que ces programmes puissent non seulement traiter d’énormes volumes de données, mais aussi exécuter des calculs intensifs.
Raoul Pal : Pour ceux qui n’ont pas saisi votre propos, pourriez-vous donner un exemple concret ? Car quand vous imaginez une solution ou un futur état, vous devez avoir un modèle mental. Ce modèle vous aide à penser : comment utiliser cette technologie ? Quels changements apporte-t-elle ? Quels nouveaux cas d’usage ouvre-t-elle dans la blockchain ? Comment abordez-vous ces questions ?
Gavin : Prenons un exemple simple, une idée longtemps discutée dans l’écosystème Polkadot. Appelée initialement SPREE, j’ai plus tard généralisé cette approche sous le nom d’« Accords ». Vous pouvez voir un « Accord » comme un contrat intelligent, régissant l’interaction entre deux blockchains indépendantes. Bien que différentes parties de l’Accord puissent s’exécuter sur des chaînes distinctes, elles savent toutes qu’elles font partie d’un même système. C’est un peu comme le droit international : une fois qu’une blockchain adhère à l’Accord, elle ne peut pas en sortir arbitrairement. Elle ne peut pas choisir de ne pas l’appliquer dans certains cas — soit elle respecte l’Accord, soit elle s’en retire. Tant qu’elle respecte l’Accord, elle peut interagir avec d’autres chaînes faisant de même.
Imaginez un « Accord » comme un « protocole de jeton ». Ce protocole garantit que lorsque je veux vous envoyer un jeton, je ne crée un nouveau jeton que si vous avez brûlé le vôtre. De même, je sais que vous créerez un nouveau jeton après avoir brûlé le mien. Cela signifie que deux blockchains peuvent interagir directement via ces messages bilatéraux, sans avoir à faire confiance à la blockchain elle-même pour gérer ces transactions.
Raoul Pal : Cela se limite-t-il à l’écosystème Polkadot, ou peut-on l’appliquer à n’importe quelle chaîne ?
Gavin : Cela ne s’applique qu’aux chaînes sécurisées par Polkadot, donc à l’écosystème Polkadot. Cependant, la définition de « parachain » peut désormais être largement assouplie : toute chaîne capable de s’intégrer à ce modèle général d’« ordinateur mondial » peut être considérée comme une parachain. Nous pouvons donc imaginer davantage — et comprendre mieux maintenant — que Polkadot n’était initialement pas conçu pour gérer des chaînes comme les ZK Rollup, mais son architecture est suffisamment générique pour que cela fonctionne, même si ce n’est pas optimal. Ce modèle rend les capacités computationnelles de Polkadot encore plus universelles.
Cela nous pousse à réfléchir : si ce n’est pas une parachain traditionnelle, mais un ZK Rollup, Polkadot peut-il vérifier toutes les transactions de cette chaîne pour en garantir la validité ? Et aller plus loin : ordonner correctement ces transactions, les faire respecter un Accord, ou encore assurer la transmission fidèle de leurs messages ?
Comment JAM stimule-t-il les applications et leur adoption ?
Raoul Pal : Dans des cas d’usage réels, comment cette capacité peut-elle impulser le développement et l’utilisation dans le monde Web3 ?
Gavin : J’aborde cette question d’un point de vue technique, sans trop me concentrer sur des applications spécifiques. Par exemple, je pourrais vous parler de gestion de la chaîne logistique, mais ce n’est pas l’application précise qui compte. L’essentiel est de savoir si la technologie peut supporter une application à une certaine échelle. Imaginons que vous vouliez suivre toutes les chaînes logistiques mondiales, enregistrer toutes les informations de fret — cela implique d’énormes volumes de données. Des dizaines de milliers de navires, des millions, voire des dizaines de millions de conteneurs. Vous devez pouvoir intégrer toutes ces données dans une grande machine d’état et effectuer suffisamment de calculs pour que l’application ait un sens dans le monde réel.
La question centrale est celle de la scalabilité. Les blockchains actuelles ne répondent pas bien à ce besoin. Il faut accroître leur capacité à traiter les données et les calculs, pas seulement en volume d’entrées-sorties, mais aussi en efficacité de traitement. Seule une augmentation de plusieurs ordres de grandeur permettra de soutenir des cas d’usage réels, et de migrer les applications Web2 vers Web3.
C’est précisément l’objectif de cette nouvelle conception JAM : fournir un plan pour gérer des données transactionnelles à l’échelle mondiale.
Quand JAM sera-t-il lancé ?
Raoul Pal : Quand JAM sera-t-il lancé ? Je sais que c’est une question difficile, mais quel est votre calendrier mental ? Combien de temps cela prendra-t-il ?
Gavin : C’est toujours difficile à dire. Prenons une analogie : j’ai réservé une Tesla Roadster en octobre 2017. Dès que je l’ai vue, j’ai voulu réserver, pensant : « Prenez mon argent, livraison dans deux ans ! » Six ans plus tard, je n’ai toujours aucune nouvelle. J’espérais avoir la voiture avant le lancement de Polkadot… manifestement, je me suis trompé. Maintenant, j’espère avoir la Tesla avant JAM, mais qui sait.
En réalité, je m’inspire approximativement de la chronologie d’Ethereum. J’ai publié le yellow paper d’Ethereum il y a environ dix ans, et il a fallu environ six à sept mois pour passer de cette publication à la finalisation et au lancement du protocole. Après audit, quelques ajustements mineurs ont été faits, puis le lancement a eu lieu à l’été 2015, probablement en juillet ou août. Donc, nous pourrions viser un délai similaire pour JAM.
Actuellement, les composantes principales du protocole JAM sont presque achevées. Je travaille actuellement sur les compléments à ajouter au livre gris, que je devrais finaliser dans les une ou deux semaines à venir. Ensuite viendront l’examen communautaire, la revue par les équipes de recherche, la conception de prototypes, et l’audit. Mais je pense que les grandes questions autour de JAM sont essentiellement résolues.
Comment attirer des utilisateurs ?
Raoul Pal : Une fois JAM lancé, le défi principal sera d’élargir l’utilisation par les utilisateurs. Comment comptez-vous relever ce défi ? De nombreux projets blockchain se disputent déjà l’attention, allant jusqu’à payer pour générer de l’activité sur leurs chaînes. Comment affronter cela, puisqu’il ne s’agit plus seulement d’extension technique, mais aussi commerciale ?
Gavin : Mon opinion de base est que les blockchains actuelles n’offrent pas un espace bloc décentralisé de haute qualité, capable de répondre aux besoins de la plupart des applications réelles. Généralement, les frais sont élevés, et il faut souvent acheter du ETH via une bourse pour utiliser Ethereum. Je sais qu’ils travaillent à améliorer cela grâce à de nouvelles infrastructures, mais en réalité, cela ne changera pas radicalement à court terme. L’un des principaux obstacles est le manque de scalabilité : l’espace bloc n’est pas assez bon marché.
L’espace bloc doit devenir quasi gratuit, et la scalabilité doit atteindre un niveau tel que vous puissiez exécuter sur la chaîne des programmes proches du code informatique classique. C’est précisément l’objectif de la conception de JAM. JAM vise à permettre l’exécution directe de code presque standard, sans passer par des contrats intelligents, sans optimisation complexe de gas, avec un coût minimal pour téléverser et exécuter du code, afin d’attirer les utilisateurs. C’est là que se concentre JAM.
Comment le réseau accumule-t-il de la valeur ?
Raoul Pal : C’est un peu comme l’évolution du cloud computing : avec le temps, tout ce qui est numérique finit par coûter presque rien. Le cloud computing en est un bon exemple : autrefois coûteux, il est désormais très abordable, sauf usage massif. Mais si tout devient quasi gratuit, comment la valeur s’accumule-t-elle dans l’écosystème ? À moins d’avoir un très grand volume de transactions, comme AWS dans le cloud. Quelle est votre vision ?
Gavin : Selon moi, à mesure que le coût de l’espace bloc tend vers zéro, de nouvelles applications et marchés émergeront. Des usages auparavant non viables deviendront possibles grâce à des frais quasi nuls. Mon objectif est d’atteindre un stade où vous n’aurez plus besoin d’acheter de crypto-monnaie via une bourse pour faire une transaction blockchain. Actuellement, presque toute action sur une blockchain exige de posséder d’abord une crypto, ce qui limite énormément le marché. Je veux finalement dépasser cette contrainte, mais pour cela, il faut une immense scalabilité. JAM est la première étape vers cette évolutivité extrême.
Je pense que, dès que Web3 deviendra une alternative légitime à Web2, un marché suffisant s’ouvrira. Même si le coût de l’espace bloc tend vers zéro, il subsistera assez de valeur pour rémunérer les validateurs qui maintiennent le réseau. Ainsi, l’échelle finale garantira que l’espace bloc génère assez de valeur pour soutenir tout l’écosystème.
Combien de nouveaux acteurs peuvent encore entrer dans ce domaine ?
Raoul Pal : Une question que je me pose souvent : quand on observe l’évolution des technologies de couche infrastructure — 3G, fibre optique, etc. — on constate qu’après une phase d’expansion, il y a un excès de capacité, puis une consolidation, et enfin une direction claire. Qu’en pensez-vous pour la blockchain ? Car nous n’avons pas encore résolu tous les problèmes, et ce n’est pas un système parfait. Quand atteindrons-nous ce stade d’excès de capacité ?
Gavin : Je pense que nous pourrions connaître une situation similaire à celle du secteur énergétique, et je ne suis pas sûr que nous ayons réellement un excès de capacité énergétique. À mes yeux, l’humanité lutte encore pour l’énergie. Créer un espace bloc de mauvaise qualité est facile : montez une chaîne privée isolée et non sécurisée, vous l’obtenez immédiatement. Mais construire un espace bloc de haute qualité, bien connecté, est bien plus difficile.
Raoul Pal : Moi, je pense plutôt à la capacité des nouveaux entrants à rejoindre ce domaine, plutôt qu’à un excès d’espace bloc. Je suis d’accord : plus l’espace bloc est bon marché et rapide, plus il y a de cas d’usage, et finalement tout Internet pourrait en dépendre. Sur ce point, pas de problème. Mais la question clé est : combien d’innovations ou de nouveaux acteurs peuvent encore entrer ? Ou cela s’arrêtera-t-il à un moment donné, par exemple parce que les nouveaux projets ne trouveront plus de financement ?
Gavin : Si l’espace bloc est suffisamment bon marché, presque gratuit, alors la question n’est plus celle des barrières d’entrée ou des scénarios d’utilisation, mais de leur utilité réelle, de l’existence d’un public et d’un marché. S’il y a un marché, comme créer un site web et utiliser AWS pour héberger un serveur, alors même si le coût du serveur est très bas, et que vous pouvez facilement servir vos cent premiers utilisateurs avides de votre nouveau service, cela n’a pas d’importance si l’énergie coûte cher ou si AWS devient coûteux à l’échelle de centaines de millions d’utilisateurs — tant qu’il y a un marché, les utilisateurs paieront.
Je ne pense donc pas que les nouveaux entrants rencontrent un obstacle majeur sur les cas d’usage, tant qu’il n’y a pas de restrictions similaires. Bien sûr, un problème du modèle Polkadot 1.0 est qu’il n’y a que 50 emplacements de parachains, et ces emplacements sont limités. Une fois qu’ils sont tous occupés, peu importe la qualité de votre cas d’usage, vous devez attendre le prochain emplacement ou participer à un Crowdloan pour en obtenir un — un processus difficile. C’est une leçon tirée de Polkadot : il faut abaisser les barrières d’entrée, non seulement pour les nouvelles applications, mais aussi pour les nouveaux utilisateurs. C’est précisément ce que JAM cherche à résoudre.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@gavofyork
