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