L’offre totale de DOT sera-t-elle bientôt fixée ? Gavin a révélé une direction de conception clé dans le groupe de discussion JAM !

Gavin ne se repose même pas le week-end, répondant aux questions de tout le monde dans le groupe de discussion JAM ! Il a révélé de nombreux éléments Alpha intéressants concernant la feuille de route du protocole JAM. 👀

Il a non seulement expliqué comment le service Bootstrap de JAM évoluerait à l’avenir et les possibilités de mises en œuvre diversifiées, mais il a aussi, pour la première fois, proposé clairement une idée radicale et à la portée « constitutionnelle » — fixer le total de DOT à π × 10⁹ (environ 3,14 milliards) et l’inscrire dans le bloc genesis de JAM.

Les mots-clés de cette discussion incluent :

• Service Bootstrap : le « système de plug-in de démarrage » de la chaîne JAM, qui ne sera plus monopolisé par Parity à l’avenir et pourra être implémenté et remplacé par différentes équipes
• π × 10⁹ : une proposition hautement symbolique de fixation du total de DOT, derrière laquelle se cache une conception économique plus stable et résistante aux abus de gouvernance
• Comité éditorial du Gray Paper (GPEB) : prendra progressivement la relève de Gavin pour diriger l’évolution des versions du protocole JAM
• Fork autonome : Polkadot peut choisir à tout moment la version du protocole, voire créer son propre « Blue Paper », garantissant la souveraineté technique de la communauté
• Qui finance ? Si le Trésor de Polkadot adopte JAM, il devrait assumer le budget de fonctionnement de base du comité éditorial

Ce n’est pas seulement un « résumé de questions-réponses », c’est en réalité une esquisse complète de la vision de Gavin sur la manière dont le protocole JAM évoluera progressivement vers la neutralité technique + une gouvernance contrôlable + une évolution autonome.

Cet article vous expliquera en détail tous les points clés révélés lors de cette conversation, afin que vous puissiez comprendre la prochaine direction technique et le paysage de gouvernance du protocole JAM.

Comment le service Bootstrap de JAM va-t-il évoluer ?

Gavin a indiqué que le service Bootstrap actuellement développé par Parity n’est pas encore complet, mais qu’il sera continuellement amélioré dans les prochains mois, avec des fonctionnalités plus riches et une documentation plus claire.

Plus important encore : à l’avenir, le service Bootstrap de JAM n’aura pas qu’une seule version, et ne sera pas une exclusivité de Parity.

Il a donné une analogie — tout comme il existe de nombreuses implémentations de BIOS pour les ordinateurs, différentes équipes peuvent également développer leur propre service Bootstrap, tant qu’elles respectent certaines normes de format. Cela signifie que le réseau JAM disposera de méthodes de démarrage d’infrastructure diversifiées et interchangeables, offrant ainsi plus de flexibilité aux développeurs et à l’écosystème.

Vous vous demandez peut-être ce qu’est le service Bootstrap de JAM ?

Pour faire simple, vous pouvez le comprendre comme suit :

Lors du démarrage, la chaîne JAM charge un service fournissant les « fonctionnalités de base », tout comme un ordinateur exécute le BIOS au démarrage.

Par exemple, si à l’avenir le protocole JAM remplace la chaîne relais de Polkadot, quelle serait la première étape pour démarrer cette chaîne ? Vous devez indiquer à la chaîne :

• Y a-t-il un système de staking ?
• Y a-t-il un système de gouvernance ?
• Qui sont les comptes initiaux ? Comment les DOT initiaux sont-ils répartis ?
• Faut-il configurer certaines fonctionnalités de contrat ?
• Faut-il connecter un service externe (par exemple, un système de vote, un oracle, etc.) ?

Rien de tout cela n’est codé en dur dans le protocole, mais est injecté via un service modulaire lors du démarrage (bootstrap) de la chaîne. Ce service, c’est ce que Gavin appelle le « service Bootstrap ».

Ainsi, le rôle du service Bootstrap est :

• Initialiser les modules de la chaîne JAM : par exemple staking, gouvernance, trésorerie, etc.
• Injecter la logique d’exécution : par exemple « quel est le total de DOT », « comment les DOT sont-ils répartis », « qui peut voter », etc.
• Définir l’état initial de la chaîne : par exemple, quels services sont présents dans le bloc genesis, quel est l’ordre d’activation, etc.

Le Bootstrap est donc le « menu de démarrage personnalisé » de la chaîne JAM, il détermine quelles fonctionnalités et quelles configurations votre chaîne aura au démarrage.

Pourquoi Gavin dit-il que Bootstrap ne devrait pas être contrôlé par Parity seule ?

Parce que c’est comme si tous les ordinateurs du monde ne pouvaient démarrer qu’avec le BIOS de Microsoft, ce qui ne serait ni sûr ni libre.

Il souhaite qu’à l’avenir, non seulement Parity, mais aussi plusieurs équipes puissent développer différents styles de services Bootstrap, par exemple :

• Certains axés sur la confidentialité
• D’autres misant sur la performance et l’extensibilité
• D’autres encore ciblant des secteurs spécifiques (par exemple, chaînes de jeux, chaînes de données, etc.)

C’est ainsi que JAM deviendra une véritable plateforme de calcul ouverte et composable.

Service Bootstrap = un mécanisme permettant d’installer des « plug-ins de démarrage » sur la chaîne JAM.

Il détermine les capacités et l’apparence de la chaîne au démarrage.

Gavin souhaite le rendre flexible, standardisé, et permettre à toute équipe de participer au développement, au lieu d’un contrôle exclusif par Parity.

Que signifie π × 10⁹ ? Est-ce lié au total de DOT ?

Gavin a proposé une idée radicale et élégante : fixer le total de DOT à π × 10⁹ (environ 3,14 milliards) et l’inscrire directement dans le bloc genesis de JAM.

Il souhaite, par ce moyen, retirer complètement le pouvoir de modifier le total de DOT de la gouvernance on-chain, afin d’éviter que le total ne soit modifié arbitrairement ou soumis à des propositions répétées. Si un changement devait avoir lieu, il faudrait alors procéder à un hard fork du protocole entier.

Cela renforcerait considérablement la stabilité de la politique économique de DOT, s’approchant d’une conception de type « constitutionnelle ».

Bien que Gavin ait évoqué dans la discussion « fixer le total de DOT à π × 10⁹ » comme une proposition de politique, ce n’est pas une idée sortie de nulle part, mais basée sur les capacités de conception sous-jacentes du protocole JAM.

Dans la section 4.6 « Economics » du Gray Paper JAM (v0.7.0), il est clairement indiqué :

• JAM est un système crypto-économique combinant cryptographie et théorie des jeux ;
• Il définit un concept natif de « token », tous les soldes de comptes (balance) appartiennent à N₂⁶⁴, soit un maximum d’environ 18 milliards de tokens ;
• Il précise également que l’unité minimale est 10⁻⁹, et adopte une « unité standard » unifiée de 10⁹ (et non 10¹⁸ comme Ethereum) ;
• Le Gray Paper indique : le total de tokens effectivement émis doit être bien inférieur à ce plafond.

Cela offre précisément l’espace de faisabilité au niveau du protocole pour la proposition de Gavin de « fixer le total de DOT à π × 10⁹ (environ 3,14 milliards) ».

Autrement dit, JAM lui-même ne définit pas de politique économique, mais il fournit un mécanisme suffisamment neutre et flexible pour permettre à des réseaux comme Polkadot de décider eux-mêmes, via le service Bootstrap, du total de tokens, de la méthode de distribution, etc.

Vous pouvez le voir comme ceci : JAM vous donne un système de portefeuille capable de contenir 18 milliards de tokens (techniquement), mais combien d’argent y mettre et qui contrôle la frappe, c’est à vous (via le service Bootstrap) de le décider. Ce n’est qu’un cadre, il ne fixe pas la politique.

Qui décide de la version du protocole JAM ?

Chaque version du protocole JAM correspond à une version spécifique du Gray Paper.

Gavin a indiqué que le Gray Paper le plus récent représente le protocole JAM le plus à jour, certaines versions étant même soumises à des audits externes pour être considérées comme « prêtes pour la production ».

La communauté Polkadot peut, via un processus de gouvernance, décider elle-même de la version de JAM à utiliser sur le mainnet. D’autres chaînes peuvent également choisir différentes versions pour construire leur propre réseau. Ce modèle renforcera considérablement la flexibilité et l’autonomie de l’évolution du protocole.

Gavin dirigera-t-il toujours le Gray Paper ?

Bien que Gavin soit actuellement le rédacteur en chef du Gray Paper, il prévoit également de former un Gray Paper Editorial Board (GPEB, comité éditorial du Gray Paper).

Ce comité sera composé de membres ayant de solides compétences techniques et une implication profonde dans le développement du protocole JAM, et décidera à l’avenir collectivement de l’évolution des versions, des priorités et de la direction à long terme du protocole JAM.

Si un jour Gavin n’est plus actif, ce comité deviendra l’« organe de gouvernance de fait » du protocole JAM.

Que faire si la communauté n’est pas d’accord avec la direction du GPEB ?

Gavin a clairement indiqué : la communauté Polkadot conserve l’entière souveraineté du protocole.

Si elle n’est pas d’accord avec la direction du GPEB, Polkadot peut choisir une version différente du protocole JAM, voire forker sa propre version, comme il l’a dit avec humour, la DAO Polkadot peut tout à fait forker un « Blue Paper » 😄

Il prévoit également, après la v1.0, d’ouvrir la licence du Gray Paper (peut-être avec une licence Copyleft protégée par brevet), permettant de forker, d’utiliser et d’améliorer librement dans des conditions appropriées.

Qui finance le fonctionnement du GPEB ?

Si Polkadot décide de construire son réseau sur JAM à long terme, Gavin estime que le Trésor de Polkadot devrait financer le fonctionnement normal du GPEB, y compris l’organisation des réunions, la discussion des priorités et l’établissement des standards.

En même temps, si d’autres réseaux sont également basés sur JAM, il espère qu’ils assumeront eux aussi une part de la responsabilité de maintenance.

Gavin prévoit de sélectionner personnellement les premiers membres du GPEB, en privilégiant ceux qui ont une solide expérience technique et ont effectivement contribué au développement de JAM. Par la suite, il nommera des rédacteurs adjoints et transférera progressivement le pouvoir de sélection des membres au comité lui-même, à la Polkadot Fellowship, à la Web3 Foundation, etc.

Gavin veut créer un mécanisme « constitutionnel » JAM indépendant de la gouvernance par vote

De la fixation du total de DOT à la délégation de l’évolution de JAM au comité éditorial du Gray Paper, en passant par la possibilité pour la communauté de conserver la souveraineté de gouvernance via le fork, Gavin tente d’établir une méthode de gouvernance du protocole « résistante aux abus de gouvernance, axée sur la technique ».

Cela constitue non seulement une correction de la gouvernance on-chain actuelle, mais aussi l’incarnation centrale du protocole JAM « modulaire + souveraineté interchangeable ».

Que pensez-vous de ce modèle de gouvernance JAM ? N’hésitez pas à en discuter dans les commentaires !