Cet article est tiré de l'appel mensuel du Fellowship technique de Polkadot, le Fellowship technique est un groupe d'experts techniques décentralisés sur la chaîne de Polkadot, dont Gavin Wood fait également partie, donc il assiste presque à chaque réunion et partage ses principaux axes de travail récents. Lors de la réunion de mai, il a partagé ces avancées importantes :
La version 0.7 du livre gris mettra en œuvre toutes les fonctionnalités nécessaires au fonctionnement du réseau.
L'audit du livre gris commence à la fin juillet, en préparation de la version 1.0
Qu'est-ce que Coreboot et Corechains ?
Le Toaster JAM mine-t-il des BTC ?
JAM va-t-il émettre un Token ?
Continuez à lire pour voir toutes les informations !
La version 0.7 du livre gris mettra en œuvre toutes les fonctionnalités nécessaires au fonctionnement du réseau.
Gavin : Le mois dernier, nous avons vécu la première expérience pratique de JAM et avons également fait des préparatifs. Récemment, ce sur quoi je me concentre, c'est de rendre le contenu du livre gris essentiellement complet, afin d'atteindre les normes pour accepter les candidats de la première phase. Bien que le livre gris ne soit pas encore en version 1.0, il doit passer par un audit pour atteindre ce niveau. Mais notre objectif actuel est d'atteindre d'abord la version 0.7.
Plus précisément, l'objectif est de mettre en œuvre toutes les fonctionnalités nécessaires au fonctionnement du réseau dans la version 0.7, et que ces fonctionnalités soient également adaptées à notre manière d'utiliser le réseau. Nous avons continuellement développé divers services, le plus connu étant probablement le service CoreVM. Au cours du développement de ces services, nous avons également pris conscience de la manière dont certaines API devraient être modifiées de manière plus raisonnable.
Si vous regardez les issues concernant la version 0.6 dans le dépôt du livre gris, vous constaterez que la plupart d'entre elles ne concernent pas de changements majeurs dans le protocole, mais plutôt des améliorations de la 'expérience utilisateur' - pour faciliter le travail des développeurs sur JAM.
Par exemple, une fonctionnalité que j'ai récemment ajoutée s'appelle 'métadonnées de compte' (account metadata), qui introduit des informations similaires à celles que les processus dans un système d'exploitation contiennent, comme : qui a créé ce service (service parent), le dernier moment où il a accumulé, sa date de création, etc. Ces informations de base sont très utiles pour le travail de maintenance DevOps.
Je pense que c'est aussi un petit tournant que nous avons franchi par rapport à la logique des blockchains traditionnelles - nous devons maintenant prendre en compte l'expérience utilisateur de DevOps, car nous ne construisons pas une chaîne ordinaire, mais un 'super ordinateur magique d'Internet'.
L'audit du livre gris commence à la fin juillet, en préparation de la version 1.0
En plus des modifications apportées au livre gris, nous travaillons également sur d'autres aspects du code de PolkaJAM. Certains sont liés à CoreVM, d'autres sont des améliorations au niveau des outils. Par exemple, nous développons un outil en ligne de commande appelé JAMtop, similaire à un moniteur d'activité, qui peut maintenant reconnaître les services CoreVM et afficher le contenu qui s'exécute à l'intérieur de l'invité. Par exemple, lorsque vous exécutez le jeu Doom, il vous dira clairement que vous exécutez Doom ; lorsque vous exécutez un test vidéo, il affichera également 'test vidéo en cours', au lieu de dire simplement 'CoreVM en cours'.
Nous avons également apporté d'autres améliorations complémentaires. En gros, je pense toujours que nous pouvons avancer selon le calendrier vers la version 0.7.0, même si le temps de réalisation pourrait être légèrement plus long que ce que je souhaitais, mais je pense que nous devrions être prêts d'ici la fin du mois. Il pourrait encore falloir quelques jours de travail intense, mais cela ne devrait pas poser de problème.
Ensuite, à partir de la version 0.7, mon idée est de me diriger directement vers l'objectif de 1.0. Initialement, nous avions prévu que la série 0.7 à 0.8 apporterait des modifications assez importantes, comme le processus de création de services, le déploiement sur le Toaster, etc. - ces principes restent en théorie, mais j'ai tendance à ne pas vouloir tout inclure dans cette phase.
J'ai en fait déjà dressé une liste d'idées qui pourraient convenir à être intégrées dans la série 0.7 à 0.8 (vous pouvez les voir dans le dépôt du livre gris), mais il semble maintenant que la plupart d'entre elles ne soient pas des fonctionnalités essentielles pour la version 1.0, mais plutôt adaptées à être conservées pour JAM 2.0 ou des itérations ultérieures. Elles ne font pas partie des éléments centraux nécessaires à l'utilisation de JAM.
Donc, mon plan est : une fois que nous atteindrons la version 0.9, nous lancerons le processus d'audit. Actuellement, j'estime que les versions 0.7 à 0.8 auront un intervalle d'environ un mois. Si la 0.7 est publiée à la fin de ce mois, alors à la fin juillet, nous devrions être en mesure de remettre le livre gris de cette version à l'auditeur en préparation de la publication de la 1.0.
Bien sûr, la publication du livre gris 1.0 ne signifie pas qu'il y aura immédiatement de nombreuses implémentations compatibles 1.0, car ces implémentations doivent également être auditées. Mais ces deux processus peuvent se dérouler en parallèle.
C'est-à-dire que tant que l'implémentation du client pendant l'audit du livre gris est basée sur la version 0.9, elle peut également commencer son propre processus d'audit - tant qu'elle est prête à accepter des ajustements ou corrections si nécessaire après l'audit du protocole.
Voilà en gros, tout progresse bien pour le moment.
Qu'est-ce que Coreboot et Corechains ?
Alice et Bob : J'ai trois questions à te poser, d'abord sur la feuille de route : que signifie coreboot ici ? A-t-il été publié ? Est-ce déjà quelque chose d'utilisable ?
Gavin : Eh bien, en fait, nous l'appelons maintenant 'service de démarrage' (bootstrap service). Le nom 'core'... certains l'aiment, d'autres moins. Je ne sais pas si ce nom sera conservé lors de la véritable commercialisation. Pour l'instant, c'est juste un nom temporaire dans le dépôt du projet.
Alice et Bob : Donc, 'core boot' n'est pas vraiment un module au sens propre, c'est juste un 'service de démarrage'. Et qu'en est-il des 'core chains' ? Y a-t-il déjà des gens qui développent cela ?
Gavin : Bastian a fait quelques essais préliminaires, je ne suis pas sûr à quel stade il en est. Je me souviens qu'après le JAM XP, pendant les quelques jours de la réunion fermée à Lisbonne, il faisait des débogages frénétiques. Mais j'ai le sentiment que c'est un projet où une fois que vous commencez, les progrès ne seront pas trop lents. Bien que pour atteindre le niveau de commutation sans couture de Polkadot, cela pourrait prendre un certain temps, j'espère pouvoir prouver rapidement que 'ce truc est faisable'. Basti est aussi là, vous pouvez lui demander.
Basti : Je suis là, comme je l'ai dit précédemment, ce n'est pas encore terminé. Mais je pense que c'est réalisable. Et plus j'y pense, plus je trouve que le résultat final devrait être assez intuitif (je vous en prie, ne déformez pas mes mots 😅). Parce que JAM a déjà fourni beaucoup de modules de construction de base. Comme différents environnements d'exécution, et ces mécanismes par défaut, nous n'avons pas à nous en soucier.
Donc, en gros, cela ne devrait pas être trop compliqué. Je vais essayer de faire une première version 'fonctionnelle' et ensuite l'itérer à partir de là. Mais la version initiale pourrait être un 'super hack', et je devrai ensuite la peaufiner pour en faire quelque chose de plus présentable.
Le Toaster JAM mine-t-il des BTC ?
Alice et Bob : D'accord, merci, j'ai noté cette partie. Gavin, peux-tu nous parler de l'expérience de l'événement JAM XP à Lisbonne ? Comment les équipes se sont-elles comportées ?
Gavin : Ces jours-là étaient assez intéressants, très amusants. Nous avons emmené les gens visiter le Toaster, et leurs réactions ont été plutôt bonnes. La partie matérielle du Toaster progresse bien, elle devrait être quasiment terminée, nous avons maintenant commencé à déployer le code à l'intérieur, et cela se passe bien. L'ambiance générale de l'événement était également formidable, tout le monde était content et intéressé par le contenu présenté.
Pendant la réunion fermée, il n'y a pas eu beaucoup de progrès sur l'interopérabilité, mais peu après, nous avons publié l'exécutable de PolkaJAM, que tout le monde peut utiliser pour tester leur propre implémentation de nœud. Deux équipes ont déjà rapporté qu'elles pouvaient interopérer avec l'implémentation de nœud PolkaJAM, ce qui est un signal très positif, montrant que nous avançons vers une interopérabilité complète. Bien que la chaîne actuelle n'ait réalisé que le premier niveau d'interopérabilité, la deuxième phase pourrait être plus complexe, mais c'est déjà un bon début.
Alice et Bob : J'ai entendu dire que le Toaster était particulièrement bruyant et surchauffait sérieusement, et il y a même des rumeurs disant qu'il mine des bitcoins - qu'en penses-tu ?
Gavin : À ma connaissance, cela n'existe pas. Le Toaster n'a pas de GPU, donc le minage est presque impossible, et ce n'est pas non plus une façon efficace d'utiliser la puissance de calcul.
JAM va-t-il émettre un Token ?
Alice et Bob : D'accord, alors dernière question. Je pense pouvoir deviner ta réponse, mais comme beaucoup de gens posent la question en ce moment, je veux quand même confirmer : y aura-t-il à l'avenir un token dédié à JAM ?
Gavin : Eh bien... pour l'instant, il n'y a pas de projet, mais je suis souvent questionné à ce sujet. Je réfléchis aussi à la signification et à l'utilité d'un token s'il devait vraiment être émis. Actuellement, je ne pense pas que quiconque puisse vraiment clarifier son objectif.
Bien sûr, nous ne pouvons pas complètement exclure cette possibilité. J'ai discuté avec certaines équipes d'implémentation de JAM, et elles ont en effet eu des idées similaires en tête. Donc, ce n'est pas totalement à écarter, mais je n'ai pas encore une position claire. Vous pouvez me reposer la question dans un mois, à ce moment-là, je pourrai peut-être vous donner une réponse plus claire.
Je pense que d'un point de vue économique, cela ressemble en fait à la proposition de valeur de DOT, je ne vois pas de différences particulières.
Cependant, ce sujet est en effet très complexe. Concernant le modèle économique des tokens, il y a beaucoup d'opinions fortes, comme : l'inflation est-elle une bonne chose ou l'incarnation du mal ? L'émission équitable est-elle nécessaire ? Le parcours des fondateurs est-il un atout ou un facteur complètement sans rapport, voire négatif ?
Ces questions sont toutes très subtiles, nous devons évidemment les aborder avec sensibilité, mais parfois elles peuvent aussi devenir une distraction. Donc, je pense que ces deux facteurs doivent être équilibrés. Comme je l'ai dit précédemment, je n'ai pas encore vu de raison particulièrement convaincante pour justifier l'introduction d'un nouveau token.
Mais une chose que je pense vraiment être préoccupante - Polkadot a toujours été fortement lié aux 'chaînes parallèles', car le livre blanc de Polkadot d'il y a huit ans était ainsi rédigé. Et les nouvelles fonctionnalités que JAM offre pourraient être négligées à cause de ce stéréotype. Si JAM est strictement classé sous Polkadot, ses puissantes fonctionnalités pourraient être éclipsées par la marque 'Polkadot', rendant difficile pour les développeurs potentiels de voir sa valeur.
Je pense que nous avons besoin d'une réponse convaincante à cette question, mais je n'en ai pas encore, et je ne pense pas que 'émettre un nouveau token' soit nécessairement cette réponse. Cependant, c'est une question qui mérite réflexion.
C'est en fait plus une question de 'positionnement de marque', ou plutôt, ce sujet a discrètement glissé dans la discussion. Cela concerne non seulement la notoriété de la marque, mais aussi 'l'occupation de l'esprit des utilisateurs' (mindshare) - bien sûr, la marque n'est qu'une petite partie de la communication.
Je pense que JAM peut ouvrir de nombreuses nouvelles possibilités, non seulement pour Parity ou Polkadot Fellowship, mais pour l'ensemble du monde Web3. Alors, comment pouvons-nous communiquer cela, pour que les gens comprennent vraiment la signification de JAM et qu'ils soient disposés à investir du temps à expérimenter ? C'est la question que nous devons résoudre.
Je crains que, comme je l'ai dit précédemment, Polkadot soit presque synonyme de 'chaînes parallèles' dans l'esprit de beaucoup de gens, et si nous voulons que les gens réalisent que Polkadot n'est pas seulement des chaînes parallèles, mais aussi des Services, CoreVM, CorePlay et d'autres architectures entièrement nouvelles, ce sera un défi de communication très difficile. Je veux dire, cela pourrait vraiment être très difficile, à ne pas sous-estimer.
Mais je pense toujours que nous devrions nous concentrer sur 'rendre les cores plus précieux' - seulement lorsque les cores deviennent vraiment pratiques et utiles, nous pourrons vraiment réussir avec la technologie en développement. Et JAM nous aide à atteindre cet objectif.
Ainsi, JAM est un outil très clé. La question est : comment communiquer à l'extérieur ce message : 'Hé, regardez, maintenant ces cores peuvent gérer toute une nouvelle série de tâches, et ils peuvent s'étendre à plus de scénarios. Venez essayer!' Comment faire passer ce message ? C'est vraiment difficile.
Je pense que Polkadot a déjà fait des progrès en matière de communication, mais la plupart des choses restent à un niveau 'communication' proprement dit. Et j'ai effectivement entendu des retours similaires de beaucoup de gens.
En quelque sorte... eh bien, notre performance sur des plateformes comme Twitter s'est effectivement améliorée par rapport à auparavant, mais cette communication est davantage axée sur l'écosystème interne, visant à unifier les points de vue au sein de l'écosystème, et non à communiquer vers l'extérieur, à transmettre ce que nous voulons vraiment dire, à attirer plus d'attention et de reconnaissance. Donc, je pense que ce sont en fait deux problèmes très épineux, et je n'ai actuellement pas de réponse claire.
Je ne sais pas... mais je pense vraiment que dans l'industrie de la cryptographie, les tokens jouent un rôle très fort dans 'la diffusion des signaux'. Donc, nous devons aussi comprendre cela pour réussir dans les objectifs que nous voulons atteindre, tout en comprenant comment les utiliser. Mais nous ne devons pas nous laisser entraîner et faire des choses 'juste pour émettre'. Donc, ma réponse est toujours - je ne sais pas pour l'instant.
Pour l'instant, JAM est juste une mise à niveau technique de Polkadot, c'est tout. C'est la position actuelle du Fellowship technique. Mais comme pour toutes les choses à la pointe de l'industrie, si un meilleur chemin est reconnu à l'avenir, tout pourrait changer.
Alice et Bob : Pendant ce temps, nous devons faire en sorte que le plus de gens possible comprennent JAM et son potentiel.
Gavin : Oui, je pense que beaucoup de gens ont 'entendu parler' de JAM, mais il y a aussi un certain degré de malentendu. Les gens connaissent ce nom, mais ne réalisent pas que c'est en fait quelque chose qu'ils devraient essayer et pratiquer - je pense que c'est un problème plus grand.
C'est un changement de paradigme très significatif. Si votre habitude par le passé était de définir le type de chaîne par 'c'est une nouvelle chaîne EVM', ou de dire 'elle utilise un mécanisme de consensus différent', alors vous pourriez avoir un peu de mal avec ce tout nouveau mode de narration que représente JAM, qui n'appartient pas à ces anciennes catégories, c'est un paradigme totalement différent.
En somme, après tout, nous sommes ici dans la discussion du Fellowship technique, et je ne veux pas que le sujet s'écarte trop.