J’ai rédigé une introduction et ébauché un plan pour un article de blog sur Duniter Substrate en preview sur http://duniter.trentesaux.fr/blog/duniter-substrate/.
@elois est-ce que ça correspond à ce que tu avais en tête ?
Le markdown est là et dispo pour des MR, mais je peux aussi prendre les retours ici et les intégrer moi-même pour plus d’homogénéité.
Il est excellent cet article félicitations @HugoTrentesaux 
@HugoTrentesaux pense tu pouvoir le publier bientôt 
?
Le travail de Hugo à besoin d’être complété pour pouvoir être publié…
Concernant les points en bas de l’article encore non-complétés:
Dans un premier temps nous n’utiliserons pas la pallet democracy, et on ne l’utilisera d’ailleurs peut-être jamais, car elle est basée sur le nombre de tokens pour voter pas sur les humains.
À la place je vois plutot une combinaision entre quelques instances de la pallet collective et nos propres pallets.
Dans un 1er temps nous aurons une seule instance de la pallet collective qui représente les membres forgerons, et les droits root seront donnés à la majorité des 2/3: ce qui signifie qu’un call ne peut être exécuté en tant que root que si les 2/3 des membres forgerons votent pour en blockchain.
À plus long-terme (donc après la migration de la Ğ1), je proposerai plus de démocratie, avec notamment une idée d’assemblée tirée au sort, mais on en débattra après la migration de la Ğ1, chaque chose en son temps
On ne sait pas encore ce qui sera appliqué précisément, c’est encore en discussion, et il y aura plusieurs itérations.
Comme premier système, je pense proposer un système simple de frais fixes par poids, avec éventuellement des quotas gratuits pour les identités, mais pour des raisons techniques le compte devra quand même avoir le solde nécessaire pour payer les frais même s’il ne les paye pas.
Dans un 2ème temps, après la migration de la Ğ1, on devra réfléchir à comment améliorer ça et adapter notamment à l’utilisation de réseau (le taux de remplissage des blocs en poids).
Sur ce point je pense avoir déjà donné suffisamment de détails précis sur ce forum pour la rédaction.
C’est un point sur lequel je n’ai pas commencé l’implémentation, donc je n’ai aucun détail pour le moment. Si ce n’est rappeler les grandes lignes: différents membres s’inscriront en blockchain pour réaliser le calcul de distance, avec un dépôt de monnaie conséquent. Ils seront rémunérés s’ils font bien le cacul et si leurs résultats sont proches de la médiane des résultats, et sanctionnés s’ils ne font pas le calcul y temps ou que leurs résultats sont loin de la médiane des résultats.
Les UTXO sont remplacées par le stockage direct du solde et d’un nonce pour empecher le rejeu.
La 1ère transaction d’un compte a pour nonce 0, puis chaque nouvelle transaction en blockchain doit avoir un nonce égal à 1+ le nonce courant stocké en blockchain.
Les transactions ont également une durée de vie limitée à quelques heures, ce qui permet de supprimer le nonce en cas de suppression du compte.
Pour savoir quand est-ce que le nonce peut être supprimé, il y a un système de compteur: chaque pallet qui « utilise un compte » incrémente son compteur, puis le décrémente lorsqu’elle na plus besoin du compte. Dès que le compteur atteint zéro, le compte est totalement supprimé du storage onchain, ce qui implique également la suppression du nonce.
Pour le moment dans Duniter-v2s, il y a 2 mécanismes qui modifient ce compteur:
La production du DU va devenir manuelle, avec un extrinsic dédié pour réclamer ses DU.
Pour des raisons de calcul de poids, il sera probablement nécessaire d’indiquer en paramètre de l’extrinsic une borne haute du nombre de DU créés où du moins du nombre de réévaluation traversées, Mais n’ayant pas encore implémenté cette partie je ne peux pas détailler pour le moment, c’est seulement quand j’implémente que je vois certaines limitations ou besoin d’exposer tel interface plutôt que tel autre pour des raisons techniques.
Concernant la production du DU j’ai aussi une autre réflexion dont je n’ai pas encore parlé: utiliser le hook on_idle pour les créer automatiquement lorsque le réseau est sous-utilisé.
En effet, l’utilisation de la blockchain n’est jamais constante, il y a toujours des phases d’engorgement et des phases de creux.
Il faut comprendre que si l’entièreté du bloc n’est pas utilisé en termes de temps d’exécution, cette ressource est définitivement perdue, la blockchain ne va pas passer au prochain bloc plus rapidement, elle attendra quoi qu’il arrive 6 secondes entre 2 blocs.
C’est pourquoi substrate à prévu un hook on_idle, qui est appelé lorsque la pool de transaction est vide, mais qu’il reste encore beaucoup de temps d’exécution pour finir le bloc.
On pourrait envisager d’utiliser ce hook on_idle pour créer automatiquement des DU qui seront de toute façon créés manuellement plus tard si on ne le fait pas. Reste à définir des critères pour sélectionner les DU qui seront très probablement réclamés, et pas les DU qui seront «peu probablement réclamés".
Pour être juste au niveau des frais, il faudrait peut-être que les DU créé automatiquement prélève les mêmes frais aux utilisateurs qui s’ils avaient été créés manuellement.
En conclusion, il peut être judicieux de retirer de l’article les points qui sont encore trop incertains, ils pourront faire l’objet de prochain articles quand on aura plus avancé
Lu. Je tenterai de rédiger ces points sous forme d’article dans le mois qui vient. En attendant, l’article est dispo sur https://duniter.fr/blog/duniter-substrate/ dans sa forme incomplète.
Mais si quelqu’un d’autre veut bien écrire, le champ « authors » peut contenir plusieurs noms ^^