Bonjour d'un dev Rust qui passe par là

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)

2 Likes

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).

2 Likes

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.

1 Like

Quelques autres questions et remarques ?

Questions

Remarques

  • TIL : je ne savais pas qu’on pouvait utiliser un 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

  • Depuis quelques versions de Rust, c’est possible de définir les versions de dépendances au niveau workspace et donc d’éviter de les répéter dans tous les toml, ça simplifie énormément les montées de version et la cohérence globale des crates d’un même workspace : Workspaces - The Cargo Book … enfin en théorie parce que quand je test ça …
2 Likes

É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

3 Likes

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 !!

2 Likes

J’ai fait pas mal de cleanup et local là, j’ai un workspace et des toml bien factorisés :tada:

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 :

2 Likes

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.

1 Like

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.

1 Like

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 !

3 Likes

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)

1 Like

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.

2 Likes

Alors j’ai vraiment bourriné sur les numéros de version, les auteurs …
Si y’a besoin de différencier un peu plus, c’est assez facile à faire, en fonction de ce que tout le monde veut faire, si la “paternité” des trucs est importante pour les contributeurs.

le fork substrate devrait revenir en copyleft à ce stade

Bon ça fait un mois que j’arrive pas à m’y remettre, ce projet m’intéresse mais j’ai trop d’autres choses à faire pour m’éparpiller.
Ca me saoule mais je dois me rendre à l’évidence, je vais probablement pas contribuer.
La marche est trop haute, faudrait que je me “passionne” pour le sujet pendant un mois pour être efficace, et j’ai clairement pas un mois de temps libre à consacrer.

3 Likes

Bien noté @jrx, bonne continuation pour tes projets, la porte restera toujours ouverte :wink:

4 Likes

Bonjour Jérôme, merci pour ton message ! Effectivement je pense que nous ne nous sommes pas rencontrés au bon moment, à la fois dans ta vie et dans la vie du projet. De ton côté tu sembles être dans une phase transitoire pendant laquelle tu as besoin d’une source de revenu confortable pour pouvoir avancer en parallèle sur ton projet perso. De notre côté Duniter ne pourrait te payer que pendant un temps trop court et pour une marche un peu haute qui te drainerait trop d’énergie.

Actuellement on a commencé à Bosser avec Benjamin (cf Bienvenue à Benjamin sur Duniter) qui s’en sort très bien. On devrait donc arriver à amener le projet à un stade de maturité qui nous permettrait de revenir vers toi avec des tâches qui te conviendraient mieux et plus de budget.

En tout cas je garde en tête ton intérêt pour la génération de code et ta capacité à faire beaucoup avec peu, ce sera particulièrement adapté quand on en sera à la mise en place des systèmes de votes car ils nécessitent de générer des éléments d’interface de manière procédurale. Je suis sûr que nos chemins se recroiseront !

4 Likes