Gavin ne se repose pas le week-end, répondant aux questions de tout le monde dans le groupe de discussion de JAM ! Il a révélé plusieurs éléments intéressants sur la feuille de route du protocole JAM. 👀
Il a non seulement expliqué comment le service Bootstrap de JAM va évoluer à l'avenir, la possibilité de réalisations diversifiées, mais il a également proposé pour la première fois une idée radicale ayant une 'signification constitutionnelle' - de fixer la quantité totale de DOT à π × 10⁹ (environ 3,14 milliards) et de l'inscrire dans le bloc genesis de JAM.
Les mots-clés de cette discussion incluent :
Service Bootstrap : le 'système de plugins de démarrage' de la chaîne JAM, qui ne sera plus monopolisé par Parity, mais pourra être réalisé et remplacé par différentes équipes.
π × 10⁹ : une proposition d'un montant total fixe de DOT symboliquement significatif, derrière laquelle se cache une conception économique plus stable et résistante aux abus de gouvernance.
Comité éditorial du Gray Paper (GPEB) : il remplacera progressivement Gavin, en dirigeant l'orientation de l'évolution des versions du protocole JAM.
Autonome et pouvant être forké : Polkadot peut choisir à tout moment la version du protocole, ou même créer son propre 'Blue Paper', garantissant la souveraineté technique de la communauté.
Qui paie ? 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épertoire de questions-réponses', mais cela esquisse en réalité le plan complet de Gavin sur la façon dont le protocole JAM évoluera progressivement vers une neutralité technique + une gouvernance contrôlable + une évolution autonome.
Cet article vous expliquera en détail tous les points soulevés lors de cette conversation, vous permettant de voir la prochaine direction technique et la configuration de gouvernance du protocole JAM.
Comment le service Bootstrap de JAM va-t-il évoluer ?
Gavin indique que le service Bootstrap actuellement développé par Parity n'est pas encore complet, mais sera continuellement itéré dans les mois à venir, avec des fonctionnalités plus riches et une documentation plus claire.
Plus important encore : le service Bootstrap de JAM ne sera pas limité à une seule version dans le futur, et ne sera pas monopolisé par Parity.
Il a fait une analogie - tout comme le BIOS de l'ordinateur a de nombreuses implémentations, différentes équipes peuvent également développer leurs propres services Bootstrap, tant qu'elles respectent un certain standard de format. Cela signifie que le réseau JAM disposera de méthodes de démarrage d'infrastructure diversifiées et alternatives, offrant 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 :
La chaîne JAM charge des services 'de base' au démarrage, tout comme un ordinateur exécute le BIOS au démarrage.
Par exemple, si le protocole JAM remplace la chaîne de relais de Polkadot à l'avenir, quelle sera la première étape pour démarrer cette chaîne ? Vous devez informer 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 ?
Est-il nécessaire de définir certaines fonctionnalités de contrat ?
Faut-il intégrer un service externe (comme un système de vote, un oracle, etc.) ?
Tout cela n'est pas gravé dans le protocole, mais injecté au démarrage de la chaîne (bootstrap) via un service modulaire. Ce service est ce que Gavin appelle 'service Bootstrap'.
Donc, le rôle du service Bootstrap est :
Pour initialiser le module de chaîne JAM : par exemple les fonctionnalités de staking, de gouvernance, de trésorerie, etc.
Injecter la logique de fonctionnement : par exemple, 'Quelle est la quantité totale de DOT ?', 'Comment le DOT est-il distribué ?', 'Qui peut voter ?', etc.
Définir l'état de départ de la chaîne : par exemple, quels services spécifiques sont inclus dans le bloc genesis, quel est l'ordre d'activation.
Le Bootstrap est le 'menu de démarrage personnalisé' de la chaîne JAM, il détermine quelles fonctionnalités et configurations seront disponibles au démarrage de votre chaîne.
Alors pourquoi Gavin dit-il que le Bootstrap ne devrait pas être contrôlé par Parity ?
Parce que c'est comme : si tous les ordinateurs du monde ne peuvent démarrer qu'avec le BIOS de Microsoft, ce n'est en réalité ni sûr ni libre.
Il espère qu'à l'avenir, non seulement Parity, mais plusieurs équipes pourront développer des services Bootstrap de styles différents, tels que :
Certains se concentrent sur les fonctionnalités de confidentialité
Certains se concentrent sur l'extension des performances
Il y a des services pour des industries spécifiques (comme les chaînes de jeux, les chaînes de données, etc.)
Ainsi, JAM est une véritable plateforme de calcul ouverte et combinable.
Service Bootstrap = le mécanisme permettant d'ajouter des 'plugins de fonctionnalités de démarrage' à la chaîne JAM. Il détermine quelles capacités cette chaîne aura au démarrage et à quoi elle ressemblera.
Gavin souhaite que cela soit flexible, standardisé, et permettre à toutes les équipes de participer au développement, et non pas contrôlé par une seule entreprise, Parity.
Que signifie π × 10⁹ ? Est-ce lié à la quantité totale de DOT ?
Gavin a proposé une idée radicale et élégante : fixer la quantité totale de DOT à π × 10⁹ (environ 3,14 milliards), et l'inscrire directement dans le bloc genesis de JAM.
Il espère ainsi retirer complètement le droit de modification de la quantité totale de DOT de la gouvernance sur la chaîne, évitant que le nombre total ne soit modifié ou proposé de manière répétée. Si un changement doit vraiment être effectué, cela doit se faire par un fork dur de l'ensemble du protocole.
Cela augmentera considérablement la stabilité de la politique économique du DOT, c'est une idée de conception plus proche d'un 'niveau constitutionnel'.
Bien que l'idée de Gavin de 'fixer la quantité totale de DOT à π × 10⁹' soit une proposition politique, elle n'est pas sortie de nulle part, mais repose sur la capacité de conception sous-jacente du protocole JAM.
Dans la section 4.6 (Économie) du Gray Paper JAM (v0.7.0), il est clairement indiqué :
JAM est un système économique cryptographique combinant cryptographie et théorie des jeux ;
Il définit un concept de 'token' natif, où tous les soldes de compte appartiennent à N₂⁶⁴, soit un maximum d'environ 18 milliards de tokens ;
Il précise également que l'unité minimale est de 10⁻⁹, et utilise une 'unité standard' unifiée de 10⁹ (plutôt que d'utiliser 10¹⁸ comme Ethereum) ;
Le Gray Paper indique que le nombre total de tokens réellement émis devrait être bien inférieur à cette limite.
Cela fournit exactement l'espace de faisabilité au niveau du protocole pour la proposition de Gavin de 'fixer la quantité totale de DOT à π × 10⁹ (environ 3,14 milliards)'.
En d'autres termes, bien que JAM ne définisse pas de politique économique, il offre un mécanisme suffisamment neutre et flexible, permettant à des réseaux comme Polkadot de décider par eux-mêmes, via le service Bootstrap, de la quantité totale de tokens, des méthodes de distribution, etc.
Vous pouvez comprendre que JAM vous donne un système de portefeuille pour stocker de l'argent (techniquement capable d'accueillir 18 milliards de tokens), mais la quantité exacte à y mettre, et qui contrôle la manière de créer des tokens, est à votre (via le service Bootstrap) propre détermination. C'est juste un cadre, sans politiques définies.
Qui décide de la version du protocole JAM ?
Chaque version du protocole JAM sera associée à une version spécifique du Gray Paper.
Gavin indique que le dernier Gray Paper représente le protocole JAM le plus récent, et certaines versions seront également soumises à des audits externes, en tant que versions 'prêtes à être produites'.
La communauté Polkadot peut décider, via un processus de gouvernance, quel version du JAM utiliser sur le réseau principal. 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 continuera-t-il à diriger le Gray Paper ?
Bien que Gavin continue d'être le rédacteur en chef du Gray Paper, il prévoit également de constituer un comité éditorial du Gray Paper (GPEB).
Ce comité sera composé de membres ayant de solides capacités techniques et ayant participé en profondeur au développement du protocole JAM, et décidera ensemble à l'avenir de l'évolution des versions du protocole JAM, des priorités et de l'orientation à long terme.
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é ne s'accorde pas sur la direction du GPEB ?
Gavin déclare explicitement : la communauté Polkadot conserve une souveraineté complète sur le protocole.
Si la direction du GPEB n'est pas acceptable, Polkadot peut choisir une version différente du protocole JAM, voire forker sa propre version, par exemple, il a humoristiquement déclaré que Polkadot DAO pourrait totalement forker un 'Blue Paper' 😄
Il prévoit également, après la version v1.0, d'ouvrir le Gray Paper à des licences (peut-être sous un accord Copyleft protégé par des brevets), permettant des forks, une utilisation et une amélioration libres sous certaines conditions.
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 bon fonctionnement du GPEB, y compris l'organisation de réunions, les discussions de priorités et l'élaboration de standards.
En même temps, s'il y a d'autres réseaux basés sur JAM, il espère qu'ils pourront également assumer les responsabilités de maintenance correspondantes.
Gavin prévoit de sélectionner personnellement les membres du GPEB au début, en privilégiant ceux ayant un solide background technique et ayant réellement participé au développement de JAM. Par la suite, il mettra en place un rédacteur en chef adjoint et transférera progressivement le pouvoir de sélection des membres au comité lui-même, à Polkadot Fellowship, à la Web3 Foundation et à d'autres institutions.
Gavin veut créer un mécanisme de 'couche constitutionnelle' JAM qui ne dépend pas de la gouvernance par vote.
De la quantité fixe de DOT, à confier l'évolution de JAM au comité éditorial du Gray Paper, en passant par la possibilité pour la communauté de conserver la souveraineté de gouvernance par le biais de forks, Gavin cherche à établir un mode de gouvernance de protocole 'résistant aux abus de gouvernance, dominé par la technologie'.
Ce n'est pas seulement une correction de la gouvernance actuelle sur la chaîne, mais aussi le reflet central de la 'modularité + souveraineté interchangeable' du protocole JAM.
Que pensez-vous de ce modèle de gouvernance JAM ? N'hésitez pas à en discuter dans la section des commentaires !