Il y a seulement deux comptes avec des conditions de déverrouillage spéciales :
Ce sont des comptes multi-signatures.
J’aimerai bien les supporter, si quelqu’un peut me dire comment les ajouter dans le json de sortie…
(ce n’est ni urgent ni indispensable, juste pour apprendre).
La palette multisig semble en effet permettre cela. Il y a une fonction qui détermine l’adresse d’un compte en fonction de l’ensemble des clés publiques des signataires et du seuil de signatures.
Il n’y a pas le support de conditions plus avancées (avec des && et ||) mais avec le seuil on peut obtenir l’équivalent d’expressions avec uniquement des && ou uniquement des ||.
Je ne sais pas si le mieux est de générer une sortie fidèle aux données quitte à devoir ignorer certains comptes (ou leur mettre le seuil maximal) à la migration, ou les ignorer directement dans le script en produisant un JSON plus facile à traiter ensuite car adapté à Substrate.
Oui tu as raison. Pas la peine de surcharger la migration avec ces comptes. De surcroît, ce sont des comptes de test visiblement avec très peu de Junes. On peut continuer à les ignorer comme actuellement et les ajouter à la trésorerie sans ruiner leurs propriétaires.
@vit, peut-être pourrais-tu m’aider car dans Duniter V2S, au moment de produire le Genesis je vois passer le message suivant :
actual monetary_mass (7,739,543,077) and initial_monetary_mass (7,739,834,527) do not match
initial_monetary_mass provient de Duniter V1, ce champ est présent dans chaque bloc comme tu sais.
monetary_mass est la somme des soldes des comptes, au sens des identités + les wallets exportés par py-g1-migrator
Il manque des sous 2,914.50 Ğ1 pour être précis (l’affichage au-dessus est en unités sans virgule, il faut diviser les chiffres par 100).
Ce faible montant laisse penser à des comptes non-gérés par py-g1-migrator. Saurais-tu les identifier ? Des comptes à condition de déverrouillage spécial comme ceux que tu cites.
Il n’y avait pas aussi les clés publiques hors de la courbe ed25519 ? (qui doivent contenir celles dépassant 32 octets)
On peut choisir de faire réapparaître les G1 perdues ou de les ignorer. Les faire réapparaître nécessite de parcourir tout l’historique des transactions, car elles sont supprimées de l’index.
En regardant les clé de plus de 32 octets et les conditions &&, je trouve seulement 848,64 Ğ1.
Pour aller à l’essentiel : je propose de ne pas migrer ces comptes, et pour les Ğ1 manquantes par rapport à la masse monétaire théorique je préconise de ne pas migrer ces Ğ1 vers la Trésorerie : je ne voudrais pas que l’on nous reproche une sorte de création monétaire autre que le DU, et concernant les Ğ1 transférées vers des comptes “impossibles” ce n’est pas très différent que les envoyer vers un compte possédé par personne, et que l’on ne pourra pas empêcher de survenir.
actual monetary_mass (7,739,543,077) and initial_monetary_mass (7,739,834,527) do not match
J’avais justement ajouté ce check pour éviter la création ou destruction de monnaie non désirée. Pour clarifier :
Comme c’est cette valeur qui est utilisée pour le calcul du DU, je prends celle-ci comme source de vérité.
J’ai calculé cette valeur dans l’idée que toute unité de monnaie créée par Duniter v1 devait bien être présente sur un compte, et je souhaiterais qu’au genesis v2 la somme de la monnaie sur les comptes soit bien égale à la masse monétaire totale. Une inadéquation entre ces valeurs correspondrait à une création ou destruction monétaire hors du cadre de la TRM, ce qui ne serait pas sérieux par rapport au but du projet.
Je trouve que c’est assez différent d’avoir de la monnaie présente dans le système ou absente du système. Comme la gouvernance on-chain facilite la mise en oeuvre de décisions, il n’est pas impossible qu’on déplace de la monnaie présente sur le système suite à une décision de gouvernance. Par exemple, si une quantité extrêmement importante de monnaie était déplacée par erreur sur un compte n’appartenant à personne, il ne serait pas complètement déraisonnable que la gouvernance décide d’effectuer une transaction en sens inverse pour réparer l’erreur et éviter une “destruction monétaire technique”. La gouvernance aurait aussi le pouvoir de créer de la monnaie hors cadre du DU, mais il faut se l’interdire par respect de la TRM.
Ceci serait aussi possible dans Duniter v1 : si on publie une mise à jour qui contient une règle spéciale et que cette mise à jour est installée par l’ensemble des forgerons.
Pour moi, création et destruction monétaire doivent être soumises aux règles de la TRM au même titre l’une et l’autre. Ce serait aussi grave de détruire une Ğ1 que d’en créer une hors d’un DU.
Pour revenir aux unité manquantes, dans le code actuel, toute la monnaie ignorée clairement identifiée (comptes hors ed25519, sources spéciales) est déplacée dans la trésorerie. Et ce compte “trésorerie” est inclut dans le calcul de monetary_mass.
Malgré cela, il reste un écart entre la masse monétaire théorique et observée.
Il faudrait explorer cette piste et vérifier si ça explique l’écart de monnaie, je n’ai pas encore eu le temps de le faire.
Pour moi il faut faire réapparaître ces Ğ1, Duniter ne devrait pas générer de destruction monétaire si le but est de coller à la TRM.
Ce que j’ai fait en attendant qu’on creuse cette piste est de prendre initial_monetary_mass comme référence et d’ajouter au compte trésorerie toute la monnaie qui n’était pas expliquée par des comptes. Libre à la gouvernance de décider de ne jamais toucher à cette monnaie ou même de la “détruire véritablement” (je ne souhaite pas de destruction monétaire), mais c’est une décision qui ne devrait pas être prise au genesis de la v2 par un nombre très réduit de personnes à mon avis. Toute destruction de monnaie dans le genesis serait un argument pour rejeter la v2 et maintenir la v1 en route, au même titre qu’une création de monnaie.
On fait de toute façon une approximation du DU (dans l’idéal il faudrait un DU continu à réévaluation continue, sans discrétisation).
Cette approximation cause une erreur (par rapport à une définition par équations différentielles) peut-être supérieure à cette monnaie oubliée. Idem pour le changement de base (qui n’aura jamais lieu du coup).
De plus les comptes à conditions spéciales sont des comptes de test faits par des développeurs, de l’argent qui n’était pas destinée à servir à autre chose que le test et qui est négligeable économiquement.
Tant mieux si on peut les récupérer, mais ce n’est pas la peine de le faire si ça fait perdre du temps. La quantité perdue étant connue, on pourra toujours la créer dans la trésorerie si voulu.
Ceci étant dit, je reste plutôt contre cette idée car ces destructions monétaires étaient conformes au protocole. Revenir sur le passé concernant cette monnaie me semble être une ingérence douteuse, pour des montants franchement dérisoires (moins de 0,003 % de M).
Certainement pas à une création, et certainement pas non plus hors cadre de la TRM pour la destruction : la monnaie créée peut très bien être conservée sur le compte d’un utilisateur sans jamais circuler, dans les faits c’est comme si cette monnaie était détruite. L’utilisateur peut aussi l’envoyer sur un compte ingérable (personne n’en possède la clé), même punition. Avec en prime une entrée inutilisée dans le Storage.
Le comité technique n’a pas de compétence sur des décisions non-techniques.
Si quelqu’un veut se prémunir du problème que tu évoques, il n’a qu’à s’en remettre à un prestataire de service type “banque en Ğ1” qui s’occupera de gérer ce genre de risques et d’en assumer les conséquences.
Certainement pas. Tu fais bien ce que tu veux de la monnaie que tu possèdes : si tu décides de l’envoyer à une adresse ingérable, ça te regarde.
2,914.50 Ğ1 pour être précis (l’affichage au-dessus est en unités sans virgule, il faut diviser les chiffres par 100).