Nombre de décimales et durée maximale sans rotation de base

Nodes Duniter-v2s
1

Dans substrate il n’y a pas de nombres flottants, les soldes sont exprimés par un nombre entier non-signé, par défaut sur 128 bits (paramétrable).

Dans Duniter-v2s, je stocke les soldes sur 64 bits, car j’ai considéré que c’était suffisant, mais on peut passer à 128 bits si ça vous semble plus pertinent.

Dans l’API RPC, les soldes monétaires sont transmis encodés selon le format SCALE, chaque langage le décode alors à sa façon, pour le javascript par exemple ça sera décodé comme un BigInt et pas un number.

Je n’ai pas implémenté de mécanisme de rotation des bases dans duniter-v2s, car ça ne servira pas avant plusieurs siècles, et que d’ici là si la Ğ1 existe encore je pense que nos descendants auront déjà réécrit plusieurs fois l’implémentation technique, mais je pense plus probablement que la Ğ1 n’existera plus au profit d’autres monnaies libres.
Qu’importe en fait, je ne vise pas si loin, si duniter-v2s s’avérait fonctionnel en production pour les prochaines 50 années ce sera déjà énorme, et de toute façon ça ne sert à rien de viser dès maintenant un support de problématiques qui n’arriveront que dans plusieurs siècles.

Toutefois, le délai avant l’arrivée du problème dépend du nombre de décimal choisi. Pour le moment je suis parti sur 2 décimales pour coller à duniter v1.

Supposons qu’il y aura 100 millions de Ğ1 lors de la migration sur duniter v2. Avec deux décimales ça fait un montant maximal à représenter de l’ordre de 10^10.

Supposons que la masse monétaire totale soit multipliée par 10 tout les 25 ans, ce qui est à peu près le cas pour N stable, car 1.1^25 ~= 10
On gagne donc 4 puissances de 10 par siècles.

Sur 64 bits on peut monter jusqu’à 10^19, on est donc tranquille pour 225 ans !

Sur 128 bits on peut monter jusqu’à 10^38, on serait donc tranquille pour 700 ans !

Si on veut stocker les montants sur plus que 2 décimales, on perd 25 ans par décimale supplémentaire.
Pour être plus large on peut stocker les soldes sur 128 bits au lieu de 64 bits actuellement.

Du coup 2 questions:

  1. Souhaitez-vous que l’on utilise plus que 2 décimales ?
  2. Souhaitez-vous que l’on stocke les soldes sur 128 bits au lieu de 64 bits ?

Mon avis perso:

  1. Deux décimales c’est largement suffisant, surtout que cette limite s’applique à la Ğ1 mais pas au DUğ1, plus le DUğ1 sera grand (en Ğ1), plus il pourra être exprimé sur un grand nombre de décimales.
  2. Je trouve que c’est de stockage perdu si on utilise 128 bits, car les 64 derniers bits (c’est du little endian) ne nous serviront pas avant des siècles.
4 Likes
2

En phase de démarrage comme actuellement, on est plutôt sur croissance de masse monétaire entre 20 et 30 % par semestre. Et cela va durer et peut-être augmenter tant qu’on a une croissance exponentielle du nombre de membres.
Mais je crois que la masse totale n’est pas stockée, c’est la masse de chaque membre, alors à moins qu’un membre trouve le moyen de récupérer toute la masse monétaire, je crois que ça ira.

Pour les décimales, je me dis souvent que la ğ1 aurais dû démarrer sur un DU à 5 chiffres (avant ou après la virgule importe peu) pour faire une réévaluation plus fine et plus souvent genre tous les trimestres ou tous les mois pour lisser l’augmentation du DU. Mais serait-ce encore la ğ1 ?

3
  1. Non.
  2. Non.

Sauf si argument pertinent qui adviendrai… :wink:

4 Likes
4

Si elle est stockée, on en a besoin pour réévaluer le DU

Je vois un intérêt à ne réévaluer que tout les 6 mois: la possibilité de créer des billets libellés en DUğ1 valables 6 mois.

Réévaluer le DU plus souvent rendrait pragmatiquement impossible les billets libellés en DUğ1.

Ça ne veut pas dire qu’il ne faut pas le faire, peut-être que certaines raisons nécessiteront à l’avenir de réduire le temps entre deux réévaluations, je ne sais pas, mais en tout cas ce n’est pas à l’ordre du jour à court-moyen terme :slight_smile:

1 Like
5

Oui

Oui.

3 Likes
6

Quid pour la ĞT ou la ĞDev ? Dans la discussion sur les paramètres de la ĞDev, tu indiques un taux c de 4,88% toutes les semaines, soit 4,88%^52 par an, soit une augmentation de 10^35 par an, ce qui ne colle pas avec les 10^19 disponibles en 64 bits.

Je n’ai pas pu participer à la discussion sur les paramètres, je ne sais pas si vous avez vu ce point.

7

Pour la ĞTest on aura probablement besoin de passer à 128 bits en effet, pour la ĞDev ce n’est pas génant car d’ici 225 semaines elle aura probablement été purgée(=supprimée) plusieurs fois d’ici la :slight_smile:
Et si ce n’est pas le cas, ça peut se changer après le genesis si le state à migrer n’est pas trop gros.

1 Like
8

Pour des raisons liées à la gestion des frais et dépôts en fonction du nombre d’octets, on va être obligé d’augmenter le nombre de décimales, je propose de passer à 4 décimales, et de passer les soldes à 128 bits pour être tranquille, explications dans ce sujet:

3 Likes
9

Je relance le sujet après avoir vu ce post qui rapporte un bug de Tikka causé par la masse monétaire qui ne tient plus dans 63 bits.

En effet Duniter stocke les montants en 64 bits, et d’après mes calculs c’est largement suffisant pour la Ğ1 à long terme. (issue)

Mais j’avais oublié la Ğdev qui croît beaucoup plus vite. D’ailleurs la masse monétaire est bloquée :

universalDividend.monetaryMass = 18446744073709551615 = 2^64-1

Le DU n’étant pas distribué automatiquement, la total issuance n’est qu’à la moitié de la limite, mais déjà trop pour 63 bits.

La blockchain devrait y survivre puisque l’arithmétique sature (si la limite est dépassée, on prend la valeur max représentable).

Quelques solutions :

  • diminuer le taux de croissance et détruire des Ğ1 en sudo
    • il faut bricoler, mais ça ne change rien aux forgerons
  • relancer la Ğdev avec un taux de croissance plus faible
    • zéro dev, mais embête les forgerons
  • passer en 128 bits
    • il faut coder la migration ou relancer la chaîne
    • inutile pour la Ğ1 → gaspillage de place dans les bases de données, calculs plus lents, mauvais support par certains langages
5 Likes
10

On pourrait supprimer des Ğdev en sudo dans un premier temps pour débloquer la situation, puis au prochain reboot diminuer la croissance du DU.

Car même en supprimant là j’imagine que le DU va tellement augmenter qu’on va de nouveau atteindre les 64 bits en quelques comptes assez vite.

11

Une autre solution serait d’implémenter le changement de base, ce qui serait comme détruire la monnaie à la main mais en plus propre. Par contre ça risque de perturber tous les autres outils Substrate qui ne sont pas faits pour ça.

Si on part sur le changement du taux en 64 bits (avec ou sans reset), je propose les paramètres suivants :

  • Taux de croissance annuel de c=3 (suffisant pour décourager l’utilisation comme une vraie monnaie ?)
  • DU initial de 20.00 Ğ1
  • période du DU comme actuellement (6h)
  • période de réévaluation comme actuellement (24h)

Ainsi on a les propriétés suivantes :

  • En 10 ans, avec 10 000 membres, on atteint seulement 41 bits (en python int(10000*2000*3**10).bit_length()).
  • Chaque réévaluation ajoute au moins 1 centime au DU (sinon on pourrait rester bloqué à cause d’un arrondi, je ne sais pas il faudrait vérifier) (2000*3**(1/365/6) ~ 2001.00355).

Je prépare une proposition au comité technique pour changer ça.

Edit: Ah mais non pour changer les constantes il faut faire un runtime upgrade.

2 Likes
12

En g1/gtest oui, mais en gdev c’est duniter-parameters il me semble.

Mes deux centimes parce que j’ai pas le temps : sinon on démarre juste une gtest avec des paramètres raisonnables (retours attendus sur GTest Paramètres) et on met la ĞDev à la poubelle le temps d’avoir du temps pour ça.

1 Like