Production du DU

Protocols Ğ1v2 protocol
42

Non, et c’est bien le problème, je fonctionne un peu à l’aveugle et avec des estimations. Il y a même moyen que le calcul de la règle de distance rentre très bien dans les deux secondes allouées au calcul d’un bloc, on pourrait l’implémenter simplement et benchmarker, ça éviterait la solution compliquée de l’oracle comme tu questionnais justement.

Mais quand on a le choix, comme pour le DU, entre deux implémentations dont la difficulté d’implémentation est comparable et que l’une des deux semble plus optimisée, ça aide à faire le choix.

Une de mes inquiétudes avec la v2 est de prendre la responsabilité de mettre en place quelque chose que l’on serait incapable de comprendre et modifier. C’est pour ça que je me suis fixé comme priorité de documenter et faire monter en compétence d’autres personnes, même si ça ralentit un peu la migration. Mais je me fixe quand même un terme de deux ans (qui me semble raisonnable par rapport au temps que prend le développement logiciel). Je pense qu’on pourra migrer en 2025 avec ce qu’on aura à ce moment sans trop de risque de se planter. Pour info je n’ai qu’un an d’expérience en développement logiciel et ça me rassure beaucoup d’être à côté de personnes comme toi qui en ont une dizaine.

4 Likes
43

Je ne souhaite pas revenir en arrière :slight_smile: je note avoir proposé une solution satisfaisante dès le départ, mais qui a été rejetée sans réelle justification.

Et je fais le lien avec d’autres observations sur le forum où je trouve que l’on se perd en optimisations prématurées, et j’émets l’hypothèse que c’est le fait de coder en Substrate qui génère une sorte d’emprise mentale qui ne favorise pas la prise de recul.

Voilà, en version courte :slight_smile:

6 Likes
44

En effet, si on peut dans certaines circonstances constater qu’une masse monétaire croît à un rythme maintenu constant, sa densité de création non symétrique dans telle ou telle sous-partie de l’économie violerait l’éthique des classes de solutions du problème des trois producteurs étendu aux N citoyens de la zone économique.

c’est avec cette allégation que je propose directement de fixer sans autre calcul le D.u à 11o%an
un peu comme le fait que la masse Kg disparait entre l’ energie cinétique et la potentielle lors d’ une chute libre, les factorisation, exposant, moyenne ne concernant que M et puis M n’ étant pas nécessaire voire même un faux repere en population non-stable, puis aussi en honneur à galilé, simplifions les choses en ramenant la symétrie au centre de la reflexion, nous trouverions pour la june une et la deux aussi ce triple avantage.
symétrie apparente - convergeance
références accessibles - Dx1,1/an
economie de calculs - non tare

NB on peut aussi le faire avec juste une addition D + D + D +D + D + D +D + D +D +D +D + retrait de la virgule d’ un cran mais bon, là on sait exactement de combien sera le D.u de tout temps donc même pas besoin de ça

pour le calcul de distance idem LAL1.3

45

Je déterre ce sujet à l’intention des développeurs de clients v2s au cas où, car j’ai l’impression que le sujet est passé un peu sous le tapis des discutions récentes.
ping @vit @Moul @kimamila @vjrj entre autre :slight_smile:

Pour rappel, dans Duniter le balance free ne représente pas toujours le solde réel d’un compte membre.
Il faut y ajouter l’estimation (précise) des DU non réclamés.

Pour donner plus de corps à cette phrase, je vous montre ici les implémentation Dart et TypeScript que j’ai fais respectivement pour Ğecko et pour Duniter portal, si vous voulez vous en inspirer pour l’adapter à votre propre logique. L’important étant les appels storages nécessaires, ainsi que le _computeUnclaimUds en lui même (un peu tricky).

Dart

https://git.duniter.org/clients/gecko/-/blob/5db0c5f3948bb200c2f0bcbbb3d5d397292849b2/lib/providers/substrate_sdk.dart#L299-356

Ici le solde réel est donc transferableBalance.

TypeScript (React)

https://git.duniter.org/clients/duniter-portal/-/blob/6b2f9a26bee95e10106852229194ff0a0bb69b9e/packages/react-components/src/AddressInfo.tsx#L540-585

La balance totale étant donc utilisé plus loin:

SOMME(freeBalance, unclaimedUds, reservedBalance)

value={balancesAll ? (balancesAll.freeBalance || BN_ZERO).add(unclaimedUds || BN_ZERO).add(balancesAll.reservedBalance || BN_ZERO) : 1}

En pseudo code simplifié ça donne:

// Required storage calls
account = api.query.system.account(address)
idtyIndex = api.query.identity.identityIndexOf(address)
idtyData = api.query.identity.identities(idtyIndex)
pastReevals = api.query.universalDividend.pastReevals()
currentUdIndex = api.query.universalDividend.currentUdIndex()

// Get first eligible UD from identity
firstEligibleUd = idtyData.data.firstEligibleUd

// Compute unclaimed UDs
function computeUnclaimedUds(firstEligibleUd, pastReevals, currentUdIndex):
    IF firstEligibleUd == 0:
        RETURN 0
        
    total = 0
    index = currentUdIndex
    
    FOR [revalNbr, revalValue] IN reverse(pastReevals):
        IF revalNbr <= firstEligibleUd:
            count = index - firstEligibleUd
            total += count * revalValue
            BREAK
        ELSE:
            count = index - revalNbr
            total += count * revalValue
            index = revalNbr
            
    RETURN total

totalBalance = account.free + unclaimedUds

Je partage ça aussi dans l’idée de challenger mon algo, qu’il sorte de l’obscurité, j’ai hâte que d’autres clients implémentes ce calcul pour nous assurer de tomber sur les mêmes résultats, et voir si vous trouver un autre algo meilleur ou plus élégant.

6 Likes
46

Ça ressemble beaucoup à celui du runtime en tout cas :

4 Likes
47

Bah c’est même exactement le même en fait!
Je ne savais même pas que le runtime avait besoin d’implémenter cet algo.

48

3 posts were split to a new topic: Add balances to squid accounts