Dans la RFC GVA je propose de renvoyer un indicateur de l’avancement de validation d’un Movement sur un compte (query MovementByPuckey() ).
En effet, un noeud Duniter dispose a priori de plus d’information qu’un client, pour parvenir à calculer un tel indicateur.
Pour l’utilisateur final, un pourcentage sera simple à comprendre (c’est graphique), mais comment le calculer ?
Avez-vous une idée de l’algo pour faire cela ?
Mon idée est de :
- Paramètre d’entré du calcul : un blockstamp;
- calculer le taux d’acceptation par les noeuds (exemple : 30 noeuds OK / 100).
- prendre en compte uniquement les noeuds membres
- Attention : cela peut changer à chaque instant, alors comment maintenir cela à jour cette information dans un index, sans ruiner les perfs ?
- on peut imaginer de maintenir un tel index seulement pour les 100 blocs de la
forkWindowSize - une routine de mise à jour de l’indicateur pourrait etre executer à chaque mise à jour du head. Mais comment gérer les revert, ou les saut de blocs (insertion de plusieurs blocs AVANT l’execution de la routine) ?
- faire un pourcentage à partir d’un simple ratio :
- par exemple 30 noeuds / 100 ont acceptés ce bloc, donc validé les TX qu’il contient sont validées à 30%.
- mais ne faudrait-il pas aussi intégrer une dimension temps ? Pour n’atteindre 100% théorique qu’àprès 6 blocs, par exemple ? En effet, même si tout le réseau était d’accord instantannément, il se pourrait qu’il soit sur une branche bloquée (par un bug, etc.) et qu’un revert global soit réalisé. Mieux vaut prendre ce cas de figure en compte, et éviter que l’utilisateur voit passer ce pourcentage de 100% à 0% (= non validé)
- Ne faudrait il pas exclure également du calculs les noeuds très désynchronisés ? Par exemple au dela de 100 blocs de retard.
J’imagine quelque chose comme :
- à chaque calcul bloc recu (ou bien tous les x secondes)
- calculer
taux(branche)pour chaque head, en fonction du nombre de noeud sur la branche; - puis on applique ce taux aux blocs précédents de la branche, en remontant depuis le
headBlockjusqu’àheadBlock - 100. - Enfin, on pondère ce taux en fonction de l’age du block:
- taux(blockHead) = taux(branche) * 0 / 6
- taux(blockHead - 1) = taux(branche) * 1/6
- taux(blockHead - 6) = taux(branche) * 1
de manière à atteindre 100% théorique seulement après 6 blocs.
L’inconvénient de cet algo est que l’on atteindra pas souvent 100%, si des noeuds sont toujours en retard (volontairement ou non). A moins d’exclure encore des fork vraiment minoritaires… par exemple quand il ont moins de 1% ou 5% des noeuds.
merci de votre aide. (@elois compris, dans la mesure où il s’agit d’un algo pouvant impacter fortement le index du noeud 
… pas comme le temps redressé ou autres sujet déjà évoqués)