La Ğdev lancée en mai 2022 lors des RML16 comporte deux décimales, ce qui est trop faible pour pouvoir appliquer des frais et dépôt en fonction d’un nombre d’octets.
Il est possible de faire une division, mais nous ne le ferons pas pour plusieurs raisons :
- Cela demanderait de forker substrate, car la partie qui calcule les frais notamment, impose de paramétrer une quantité de frais par octet.
- ce serait moins optimisé, car il faut faire une division en plus, sans compter les problèmes d’arrondis.
Or, un centime de Ğ1 par octet, c’est déjà beaucoup trop, nous devons donc augmenter le nombre de décimales, ce qui va également impliquer de stocker les soldes sur 128 bits (comme le font tous les autres projets substrate, c’est moi qui avais modifié à 64 bits pensant que c’était suffisant pour nous).
Le problème, c’est que les soldes monétaires sont stockées un peu partout, j’ai fait le point et ça nous demanderait de modifier une quinzaine de storage item dans huit pallets différentes.
Ce serait une migration beaucoup trop complexe, qui demanderait énormément de travail et qui imposerait de passer la blockchain en lecture seule, même à mon boulot (chez Moonbeam), on n’a jamais fait une migration aussi complexe.
Si un jour on a l’obligation de le faire en prod, on le fera, mais se forcer à le faire sur la ĞDev ralentirait beaucoup trop les développements, et repousserait la migration de la Ğ1 de trois à quatre mois minimum.
J’ai donc décidé de purger la ĞDev, c’est à dire de l’arrêtée et de la relancer avec un nouveau genesis, je reprendrais probablement la même toile initiale que lors des RML16.
Mais quitte à purger la ĞDev, il y a d’autres changements structurants que j’aimerais inclure, car ils seront plus faciles à inclure sans migration à gérer, je pense notamment au passage au DU manuel ainsi qu’à la mise à jour de substrate, mais également d’autres trucs.
Le temps d’implémenter tout ça, ça va nous mener en août voir en septembre, car je vais probablement être indisponible pendant un mois cet été (je ne suis pas encore sûr à 100 %, ça ne dépend pas de moi).
Ces prochains mois, beaucoup de boulot essentiel pour consolider la ğDev, et pouvoir enfin faire des tests de charge à l’automne, entre autres :
- Passer à la création manuelle du DU.
- Coder tous les tests benchmark pour tous nos calls et nos hooks.
- Étalonner tous les poids de nos pallets et des pallets de substrate (pour les pallets de substrate qu’on utilise, j’ai déjà réalisé une partie du travail).
- Passer à quatre décimales, et passer le solde en
u128. - Et plein d’autres petites taches que je ne liste pas ici, allez voir les issues sur le gitlab :runtime-400 · Milestones · nodes / rust / Duniter v2S · GitLab
Pendant ce temps la ğDev ne va pas avancer, où très peu, je pousserai peut-être d’autres runtime upgrade avant le reset, mais seulement avec des petits changements mineurs, et c’est pas sûr.
Bref, la route est encore extrêmement longue coté cœur duniter-v2s, donc les développeurs des wallets/clients ont largement le temps 