Ce sujet sert à discuter du sujet: Vocabulaire de base pour comprendre Duniter-v2s (lecture fortement recommandée pour tous)
Si quoi que ce soit n’y ait pas clair, merci de poser vos questions ici.
C’est également ici que vous pouvez proposer des modifications pour améliorer ce lexique 
Bonsoir,
Voici mon premier message sur le forum Duniter et je n’espère pas le dernier.
Cela fait quelques mois que je suis de (très) loin la migration de Duniter vers Substrate et je trouve vraiment que le choix d’utiliser un framework reconnu et porté par une communauté est la meilleure chose que vous puissiez faire pour le développement de la June.
Cela permettra à des développeurs compétent en Substrate (il y en a sans doute bien plus que des dev Duniter ) de pouvoir contribuer à Duniter très facilement.
Première question qui m’est venue à l’esprit sur le vocabulaire :
C’est la partie de code qui contient les « Pallet » et leurs « Call », elle est compilée en webassembly et le code webassembly du runtime est inclus dans le storage onchain, ce qui permet de mettre à jour le code du runtime via… des règles onchain définies par le runtime.
Cela veut dire que le code nécessaire à l’éxecution de la blockchain se trouve dans la blockchain elle-même ? Un peu comme une page web contient son code javascript qui peut changer à tout moment sans que l’utilisateur s’en rende compte ?
Si c’est le cas, c’est très ingénieux, cela évite les mises à jour des différents noeuds. Si je comprends bien, les noeuds exécuterons tous un “logiciel” qui implémente le protocole substrate, puis ensuite le protocole propre à la June peut évoluer sans forcément mettre à jour le code des noeuds ?
J’imagine que si des correctifs sont apportés au binaire substrate, on voudra tout de même mettre à jour son logiciel non ? Je ne connais pas de moyen de mettre à jour un binaire qui tourne en mémoire sans l’arrêter et le relancer. Je sais que certains langages permettent le “hot reloading” et c’est parfois utiliser pour des plugins ou autres, mais rarement pour l’ensemble de l’application.
Si c’est possible avec Substrate, c’est clairement une sacrée prouesse .
Bonjour,
Le runtime WASM ne concerne que le protocole de la monnaie. Comme il est portable il peut être unique pour toutes les machines. Le reste (l’exécutable gérant réseau, bdd, fournissant son API au runtime, etc.), qui n’est pas en blockchain, ne peut pas être changé via la blockchain. Il doit être mis à jour classiquement, par le gestionnaire de paquets du système par exemple, et il doit être compilé pour chaque architecture.
Ok merci pour les précisions, c’est bien ce que j’avais compris. En tout cas, c’est déjà super que la mise à jour du protocole fasse partie intégrante du protocole .
Passer par WASM est aussi une excellente idée !
L’inconvénient tout de même est qu’un compilé WASM est moins performant qu’un compilé natif : il manque des optimisations spécifiques au système cible, et certaines optimisations comme SIMD sont encore plus compliquées à mettre en place (je ne sais même pas si Substrate le permet).
Connaissant mal les contraintes en crytomonnaie, je ne me rends pas bien compte de l’impact que cela peut avoir sur les performances globales.
Ce que je sais c’est que WASM permet des performance très proche du natif (sauf comme tu dis certaines instructions genre SIMD) et je me dis que si le reste (l’executable contenant substrate) est compilé nativement, ça devrait aller.
De ce que je comprends, c’est tout de même l’executable qui fait la majeur partie du boulot, le protocole de la monnaie ne doit pas être la partie qui prend le plus de temps processeur.
En guise de comparaison, c’est sans doute un peu comme les jeux vidéo qui utilisent des langages de scripting (parfois compilés, parfois pas comme LUA) pour toute la logique de « gameplay », le reste est codé dans un langage compilé et optimisé (souvent C++) et représente les partie les plus importantes en terme de temps CPU.
J’imagine que c’est très similaire pour les protocoles implémentés sur Substrate.
En tout cas, ça doit être un brin plus rapide que l’implem actuelle, je sais que Node.js est bien optimisé mais tout de même .
Bonjour @AndreasL, désolé je ne vois tes posts que maintenant 
Oui le runtime wasm continent uniquement la logique métier, toutes les opérations moyennement coûteuses (quelque ms) sont exécutés en natif via des externalités invoquées par le runtime. Exemples: accès à la base de donnée, vérification des signatures, etc
Pour les opérations trop coûteuses (temps d’exécution supérieur à la seconde), on les déplace carrément offchain.
Concernant les mises à jour, oui dans la pratique il faudra toujours mettre à jour son binaire de temps en temps, mais comme ça concerne des changements hors-protocole, il n’y a pas besoin de se synchroniser pour se mettre à jour en même temps.
Merci @elois pour ta réponse, c’est donc ce que j’avais compris.
Je serai vraiment intéressé par contribuer à Duniter v2, déjà parce que ça me permettrai d’apprendre Rust et aussi parce que ça à l’air d’être techniquement assez poussé.
Le truc c’est que je me rends bien compte de l’investissement nécessaire pour contribuer à un tel projet et pour l’instant c’est juste pas possible pour moi.
Je vais néanmoins essayer de suivre l’évolution du projet tout en me documentant comme je peux sur Substrate et la surcouche Duniter et si jamais un jour je me sens en capacité de m’investir plus, je sais où aller :).
D’ici là, bonne continuation sur ce magnifique projet !
Bonsoir @AndreasL,
Il est vrai que contribuer significativement au code demande beaucoup d’investissement, mais il y a d’autres manières d’aider le projet duniter-v2s qui demandent moins d’investissement.
Par exemple, le simple fait de comprendre certaines notions plus facilement de par ton background peut te permettre de les expliquer aux autres avec tes mots, et ça c’est quelque chose sur lequel j’ai vraiment besoin d’aide pour 2 raisons:
J’ai ma manière d’expliquer, et je constate avec les temps que j’ai des difficultés à me faire comprendre par certains. On à tous un cerveau différent, et certains ont besoin que les choses soient expliquées d’une manière différente, ce que je suis incapable de faire. J’ai donc vraiment besoin que d’autres personnes qui ont compris les concepts de duniter v2 puissent les expliquer à leur tour à leur manière
Prendre le temps d’expliquer est très chronophage, surtout à l’écrit, et encore plus pour moi car je suis plus lent que la moyenne pour écrire. Du coup parfois (voir souvent), je n’ai pas la possibilité de prendre le temps qu’il faudrait pour répondre aux questions. Quand vous voyer une question technique sur duniter-v2s, si vous avez des éléments de réponse, même partiels, mais que vous êtes confiant sur la conformité des éléments que vous avez, svp répondez, vous me ferez gagner du temps, ce qui me permet d’employer ce temps à avancer sur duniter-v2s.
Bonjour @elois
Ca c’est quelque chose que je peux faire :).
Après, j’ai pas encore une grande compréhension de duniter-v2s mais avec le temps ça va venir (comme avec les concepts de la TRM) et donc au début, je vais sans doute répondre juste aux questions générales et plus ça va plus je pourrai être précis.
Tu penses que le besoin est plus sur ce forum ou sur le forum monnaie-libre ?
En tout cas si je peux aider en ce sens c’est cool et t’as raison, on a tous des manières de penser différentes et avoir plusieurs personnes qui expliquent ça aide vachement 
.
Sur les deux
Ok cool, je vais tâcher de suivre de plus près le lancement de GDev et pourquoi pas proposer un noeud, mais j’ai pas de machine qui tourne h24 pour l’instant.
Dans le sujet Vocabulaire de base pour comprendre Duniter-v2s (lecture fortement recommandée pour tous), tu introduis deux “type de cryptographie”.
Quelle est la différence entre ed25519 et sr25519, dans quel cas souhaite-on utiliser l’un plutôt que l’autre ?
sr25519 est une amélioration plus récente, plus rapide a vérifiée et permettant la vérification des signatures par batch. On préférera utiliser sr25519 dès que c’est possible, ed25519 n’est supporté que pour des raisons de compatibilité
Ok. Étrange que ssh-keygen ne le propose pas. C’est très récent ?
C’est très récent ?
Vu l’inertie forte dans ce domaine, oui. La plupart des hardware wallet ne gèrent pas sr25519 (bon certains ne gèrent même pas ed25519), et polkadot est la 1ère crypto-monnaie “connue” à utiliser ce scheme (et encore l’une des seules aujourd’hui).
Peut-être ajouter une entrée « API WebSocket » ?
Très intéressant en tout cas ce référentiel de vocabulaire, excellente idée.
C’est l’API RPC, elle est dispo en HTTP ou en Websocket mais c’est la même API
Je n’ai pas vu la définition de hook ni de consumer.