Bonjour,
Je m’appelle Jérôme, je fais du Rust depuis 2 ans environs (ce langage c’est le turfu), j’ai une petite culture blockchain sans vraiment me considérer au niveau pour l’instant et je me tate à venir participer au réseau (personnellement et professionnellement).
Vous me conseiller de commencer comment pour mettre les mains dans le code Duniter V2 ?
Rebonjour Jérôme,
Pour les autres, je vous informe qu’on a passé 2h en visio à parler de Duniter, Rust, et compagnie. J’ai cherché quelque chose dans le Plan de migration v2 qui pourrait convenir à Jérôme :
Je me suis dit que les sujets les plus évidents n’étaient pas adaptés:
Par contre, en regardant les tickets, je me suis dit que le #72 et #73 sont pas mal pour rentrer dans le projet. Même si ce n’est pas indispensable pour la migration, ça fait une bonne entrée en matière, et ça fait que dès qu’on a plus de sous, on peut proposer des missions plus longues à @jrx.
Je vais essayer de re-contacter @elois pour voir s’il ne serait pas d’accord pour m’aider à “recruter” la bonne personne pour les bonnes tâches, vu qu’il a une meilleure vision d’ensemble du projet.
Et je vais refaire une passe dans le plan de migration, parce que je vois des trous par rapport à ce que j’ai découvert récemment dans le code.
Bienvenue dans la monnaie du turfu @jrx !
Ça a l’air compliqué, il faut gérer l’exécution des inhérents, leur injection, détecter quand il faut les injecter, donc toucher au runtime et au client, comme pour la règle de distance. D’ailleurs les tickets ont le label D-hard.
Pour les offences, le goOffline automatique #25 a l’air plus simple et plus prioritaire.
Effectivement, j’avais mis toutes les offences dans le même sac, mais l’offence I’m online est un comportement purement automatique qui ne fait pas appel à de la gouvernance pour sortir d’une blacklist (cf Offence management). Et en effet, c’est assez prioritaire au sens où ça devrait pas mal augmenter la stabilité des réseaux, en particulier des réseaux de tests. Reste à estimer le nombre d’heures que ça peut prendre. Avec le temps de rentrer dedans, je dirais à la louche une centaine d’heure pour tout implémenter, tester, et documenter (elois semble parler de forker la pallet offences, qui définit le OnOffenceHandler. dans polkadot c’est géré par le staking, nous il faudrait un comportement dédié). À xxx€/h (faible mais acceptable vu le projet d’après ce que j’ai compris), ça ferait xx k€. Reste à confirmer de notre côté si l’estimation est réaliste, je compte mettre @elois sur le coup, et voir si ça convient à Jérôme. On peut se laisser un peu de temps pour éclaircir tout ça et programmer une visio pour valider une fois qu’on est prêts.
Hum … C’est un sacré jargon tout ça, faut vraiment que je creuse un peu plus avant de me lancer dans une quête niveau 42. Je vais commencer par quelques tutos substrate peut-être, ça éclairera peut-être certains des mots qui je ne comprends pas.
Heu … au fait, on s’est mal compris @HugoTrentesaux,
(faible mais acceptable vu le projet d’après ce que j’ai compris)
Non, non, c’est pas faible, ce sont mes tarifs “normaux”.
Vu l’implication bénévole de nombreux contributeurs, je ne me sentirai vraiment pas à l’aise dans mes pompes d’appliquer la même tarification à ce projet, sauf si ma contribution est déterminante et que j’arrive à accélérer le projet au delà de l’espéré (ce qui est finalement peu probable, je suis juste un humain hein).
Bref, d’abord il faut qu’on trouve un moyen de démarrer qui soit bon pour tout le monde, et on verra si ça colle bien pour tout le monde ok ?
(et puis on fait pas plus de discutions tarifaire sur un forum publiquement indexé svp)
Pour commencer à manipuler les concepts de Substrate côté client (wallet) il y a Ğcli, un client tout bête en Rust qui sert surtout pour le test.
Comme exercice Substrate+Duniter, ajouter des commandes de WoT à gcli (certifier, confirmer une identité) peut être intéressant (et utile en vrai).
Quelques petites questions et remarques pendant que je regarde cette video de @elois : RML16 - 26 Mai 2022 Duniter-v2s Substrate by @elois - YouTube
C’est quoi UT ? il me semble que c’est différent du UD (Universal Dividende) et je ne pense pas que ça ait un rapport avec Unreal Tournament mais je n’arrive pas à saisir l’explication de ce terme.
L’histoire de distance sur le graph de WoT me semble être un vrai gros morceau difficile, vous auriez des resources qui expliquent ça ? je suis tombé sur quelques articles du forum, mais j’avoue ne pas encore comprendre cette histoire de distance rule, et l’attaque qui va avec.
Ça ne me dit rien, peut-être UTC ? C’est à quel moment de la vidéo ?
Pour la WoT il y a des articles détaillés ici : Duniter | Toile de confiance
Si c’est pas censé être un truc, déjà cette information m’aide.
Je crois que c’est quand il parle de unit, ça doit être quand il différencie les valeurs relatives (en UD) et absolue (en unité : du coup UT ?), je suis pas sûr, mais je vais finir par trouver.
Quelques autres questions et remarques ?
Questions
substrate, y’a du code spécifique qui ne peut pas être mis dans le repo final ? GitHub - duniter/substrate: Substrate: The platform for blockchain innovators
Remarques
Cargo.toml racine à la fois pour un package et un workspace, c’est la première fois que je vois ça je crois. (je sais même pas si c’est une “bonne pratique”)Améliorations
Élois avait dû ajouter du code spécifique, je ne sais plus pour quoi. Et on a gardé le fork. C’est quand même utile si jamais on a besoin d’ajouter un commit à une version particulière ou que sais-je. En tout cas ça ne fait pas tellement plus de travail de le garder, même si ce n’est pas toujours nécessaire.
On a créé le dépôt en forkant substrate-node-template donc on a gardé la même structure (qui est déjà assez compliquée).
Quelle est la commande qui a donné ça ? En fonction de ce qu’on veut faire (build runtime, build client, test, benchmark…) il faut activer des features différentes.
C’est juste cargo c --all de base ça passe niquel mais si j’ajoute :
[workspace.dependencies]
sp-api = { git = "https://github.com/duniter/substrate", branch = "duniter-substrate-v0.9.32" }
dans le Cargo.toml racine, puis dans runtime/gdev/Cargo.toml je change :
# sp-api = { git = 'https://github.com/duniter/substrate', branch = 'duniter-substrate-v0.9.32', default-features = false }
sp-api = { workspace = true, default-features = false }
(au pif hein, j’ai vraiment chopé un toml au pif), là je me tape l’erreur
error: failed to run custom build command for `gdev-runtime v3.0.0 (/home/jrx/_git/duniter-v2s/runtime/gdev)`
Caused by:
process didn't exit successfully: `/home/jrx/_git/duniter-v2s/target/debug/build/gdev-runtime-c089ee2e291ae98a/build-script-build` (exit status: 1)
--- stdout
Information that should be included in a bug report.
Executing build command: "/home/jrx/.rustup/toolchains/nightly-2022-10-09-x86_64-unknown-linux-gnu/bin/cargo" "rustc" "--target=wasm32-unknown-unknown" "--manifest-path=/home/jrx/_git/duniter-v2s/target/debug/wbuild/gdev-runtime/Cargo.toml" "--color=always" "--profile" "release"
Using rustc version: rustc 1.66.0-nightly (8796e7a9c 2022-10-08)
--- stderr
Blocking waiting for file lock on package cache
Compiling getrandom v0.2.8
Compiling rand v0.7.3
error: the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
--> /home/jrx/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.8/src/lib.rs:263:9
|
263 | / compile_error!("the wasm32-unknown-unknown target is not supported by \
264 | | default, you may need to enable the \"js\" feature. \
265 | | For more information see: \
266 | | https://docs.rs/getrandom/#webassembly-support");
| |________________________________________________________________________^
error[E0433]: failed to resolve: use of undeclared crate or module `imp`
--> /home/jrx/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.8/src/lib.rs:290:5
|
290 | imp::getrandom_inner(dest)
| ^^^ use of undeclared crate or module `imp`
For more information about this error, try `rustc --explain E0433`.
error: could not compile `getrandom` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
warning: build failed, waiting for other jobs to finish...
Bon et si je fais met le default-features = false au niveau du Cargo.toml de racine, là ça se passe bien et j’ai plus besoin de référencer git dans gdev
sp-api = { workspace = true }
Apparement ils ont clean tout ça dans le repo original maintenant : substrate-node-template/Cargo.toml at main · substrate-developer-hub/substrate-node-template · GitHub
Oui, c’est un monde à part, il y a beaucoup de concepts à assimiler.
Je pense que tu fais référence à cette ligne dans la présentation, c’est une faute de frappe pour “UD” (universal dividend).
Je ne sais toujours pas quelles sont vraiment les implications de ce critère de distance (même si je l’ai pas mal étudié avec datajune), mais ça donne une topologie intéressante à la toile, qui pourrait grandement faciliter la détection d’attaque Sybil (mais c’est encore à étudier).
Comme dit tuxmain, il y a un chouilla de code spécifique. Comme on peut le voir ici (Commits · duniter/substrate · GitHub), on ajoute la possibilité de seller manuellement des blocs vides (pour les tests d’intégration), et on désactive rockdb qui bouffe du temps de compilation.
Ok pour les dépendances au niveau workspace, ce serait bien de les mettre comme ça. Et ça pourrait valoir le coup de repartir sur le nouveau node template parce que l’architecture a un peu évolué depuis. Mais tout dépend de la quantité de boulot que ça représente !!
J’ai fait pas mal de cleanup et local là, j’ai un workspace et des toml bien factorisés 
Vous pouvez me faire un compte gitlab où je peux push une branche pour vous montrer ça ?
Il doit y avoir un autre moyen (enfin j’espère) parce que du coup, ça va faire plus de travail pour tenir à jour substrate :
Je suis partagé entre faire un truc propre et suivre Polkadot au plus près. Sachant que Polkadot est la blockchain “officielle” de Substrate donc elle fait référence.
Quand j’ai mis à jour Substrate c’était assez long de faire suivre tous les changements, et j’ai dû copier certains bouts de code de Polkadot (à la version correspondante). Plus on s’en éloigne plus les màj seront difficiles.
Je t’ai créé un compte avec ton adresse du forum et comme login jrx, et t’ai ajouté sur le projet pour que tu puisses faire une branche directement dessus.
La stratégie de mise-à-jour est effectivement un point sensible du projet (et probablement de tout projet substrate) puisque si des failles sont découvertes en amont, la sécurité du projet dépend de la vitesse à laquelle les correctifs sont appliqués. J’ai écrit à @elois pour savoir s’il souhaitait partager ses connaissances à ce sujet.
De ce que j’ai compris, Polkadot n’est qu’une implémentation particulière de ce qu’il est possible de faire avec Substrate, il me semble que Duniter n’est pas conçu pour être interropérable avec Polkadot ? si ? (c’est une vrai question, je ne sais pas).
On doit pouvoir manipuler ça par les features ou juste en ajoutant pas la crates ? à voir.
La bonne pratique généralement quand on utilise un framework comme Substrate semble l’être c’est de ne pas le modifier mais l’étendre, là où c’est prévu de modifier les comportements (ici, il me semble qu’il y’a quand même quelques points d’abstraction possible). (pour ceux que ça intéresse, c’est un peu comme Open–closed principle - Wikipedia en POO)
J’ai regardé les modifications faites par @elois sur substrate, j’ai vraiment beaucoup de mal à en juger la pertinence avec mes faibles compétences du moment : Comparing paritytech:master...duniter:duniter-substrate-v0.9.32 · paritytech/substrate · GitHub
Il me semble que certaines pourraient être proposées upstream à Parity (des “simples” commentaires par exemple). Mais pour le reste, je suis dans le flou.
Yes, c’est le bon chemin vers l’enfer de maintenir un fork
Thanks !
Voilà : Files · jrx/workspace_tomls · nodes / rust / Duniter v2S · GitLab
Beaucoup de toml modifiés, mais ça n’a pas l’air d’avoir fait un cataclysme dans le Cargo.lock donc ça me semble être pas mal.
A vérifier plus à fond, je n’ai pas exécutés tous les tests (notamment les end2end)
J’ai l’impression que Substrate est une partie qui a été abstraite de Polkadot, une sorte d’“essence”, un “substrat”.
Et ça a permis de développer d’autres réseaux, donc de donner d’autres exemples de ce qu’il était possible de faire avec substrate.
Un tree du dossier runtime du dépôt polkadot :
runtime
├── common
├── kusama
├── metrics
├── parachains
├── polkadot
├── rococo
├── test-runtime
└── westend
On voit les runtime des deux réseaux principaux : polkadot et kusama (rococo et westend sont destinés à des réseaux de test). Mais l’idée de l’écosystème polkadot est de tirer parti du consensus global des réseaux principaux pour faire fonctionner toutes les “parachains”. Et il y en a un paquet qu’on peut voir par exemple sur https://polkadot.js.org/apps/ dans le menu de gauche.
Vu les idées politiques de Duniter et l’utilisation de la toile de confiance pour le consensus, nous avons en effet choisi de ne pas faire une “parachain de polkadot”, mais bien une “solo chain”, autrement dit un réseau indépendant.
En général, c’est assez difficile de comprendre ce que fait @elois parce qu’il a un niveau bien plus élevé que le notre, mais je dirais que 9 fois sur 10 en creusant un peu, on se rend compte à quel point ce qu’il fait est bien pensé, propre, et entièrement pertinent. Donc à moins de montrer précisément pourquoi il s’est planté (ça arrive, mais assez rarement), je pars du principe que c’est pertinent.
Ce que l’on fait n’est pas vraiment “maintenir un fork”, mais juste controller les montées en version avec deux “hacks” destinés à nos cas d’usage précis. Elois a déjà réalisé quelques contributions à substrate upstream, et il connaît bien les mécanismes d’intégration de modifications dans substrate, donc il y a des raisons de lui faire confiance sur ce choix (en attendant d’être nous même en mesure de le comprendre pleinement).
Merci pour ta branche. À première vue ça me semble bien, il faut juste qu’on réfléchisse par rapport aux pallets, car elles pourraient être utilisées par d’autres projets (y compris par une parachain de Duniter, qui sait). Et peut-être aussi qu’on voudrait garder des authors par pallet, comme @tuxmain qu’on pourrait ajouter à la pallet oneshot-account . On peut continuer cette discussion dans la MR !131.