Transactions envoyés à la chaîne bloquées depuis cinq jours dans la mempool de Duniter

Bonsoir/jour,

J’ai des transactions bloquées depuis 5 jours :

Éléments de diagnostic :

  • C’est sur la clef :
    BCnd895BnYZZmrVR22y5qUfbZ2FXEZDTrcer4JRNAFsd
    
  • J’ai fait les transactions via un script automatisé.
  • J’ai essayé de réaliser 16 transactions en environ 5min.
  • Il y avait un écart de 20 secondes entre chaque transaction.
  • Toutes les transactions ont eu lieu sur le même serveur (probablement celui de poka).

Des idées d’où ça pourrait venir ?

Ce script utilise Silkaj en arrière plan.
Silkaj n’est pas été testé pour les transactions en chaîne. Ce problème ne m’étonne pas.
Je dirais qu’actuellement la gestion de sélection des sources de monnaie de SIlkaj n’est pas adaptée à l’enchaînement de tx.
Les transactions se retrouvent avec les mêmes sources et de fait n’entrent pas la chaîne car Duniter a une règle DUBP interdisant ça. Il y a surement d’autres problèmes qu’on ne voit pas du fait de ce dernier.

J’ai déjà expérimenté ça sur la Ğ1-test lors de l’envoi de tx en chaîne. C’est déjà arrivé que ça ne passe pas lors de la rémunération des contributeurs du projet Duniter. Matograine a dû également être confronté à ce problème lors de ses développements.

Une manière de temporairement pallier ce problème et de faire des transactions multi-destinaires avec la gestion de différents montants qui devrait bientôt entrer la branche dev.

Ça me semble un point prioritaire. À ma connaissance, il n’y a pas de ticket à ce sujet. Un début de contribution possible…

4 J'aimes

Pour régler ça il faudrait prendre en priorité les sources n’étant pas utilisées par les txs en piscine ? Ou plus simplement permettre de faire plusieurs txs d’un coup ?

Aucune idée. Ça me semble des bonnes pistes à suivre.
Surement que la première personne qui creusera ce point pourra répondre à ces questions.

Hop : https://git.duniter.org/clients/python/silkaj/issues/312

2 J'aimes

Oui, ou simplement avoir un cache de très courte durée, genre dans .config/silkaj/temp.
Il suffirait d’y mettre les sources, avec un marqueur de consommation.
Lors de l’appel suivant de Silkaj, il pourrait détecter ce cache, et s’il n’est pas périmrée, l’utiliser en excluant les sources commonnées, et puis en le mettant à jour. Un fichier .lock pourrait permettre une lecture/écriture saine du fichier de cache. :slight_smile:

Oui, j’ai évoqué cette solution dans l’issue.

Que signifie « source » dans ce contexte ?

Peut-on amoindrir le problème de notre côté ? Par exemple en augmentant la durée entre chaque transaction ? Ou en changeant de nœud d’une transaction à l’autre ?

Autres questions : au bout de combien de temps les transactions arrêtent-elles d’être en « pending » ? Et à ce moment là que se passe-t-il ? Elles disparaissent ?

Je me confronte à ce soucis depuis un moment…

C’est tout ce que j’ai pu réussir à faire, tirer au hasard un noeud BMA https://git.p2p.legal/axiom-team/astroport/src/master/zen/tools/duniter_getnode.sh pour y égrainer mes TX le plus lentement possible… Bon c’est grâce à cette contrainte que je me suis tourné vers ipfs

:pray: gratitude si vous arrivez à améliorer ce point

Une source est une quantité de Ğ1 appartenant à une clé publique. Chaque DU créé correspond à une source supplémentaire sur ton compte, d’une valeur d’un DU. Une transaction consomme des sources pour en créer ailleurs. C’est comme si, possédant 3 billets de 10 UNL, pour envoyer 25 UNL à quelqu’un tu brûlais tes 3 billets pour en imprimer un de 25 à envoyer, et un de 5 à garder.

Or, chaque source a un identifiant unique, et c’est par cet identifiant qu’une transaction spécifie les sources qu’elle utilise.

Changer de nœud n’y changera rien : les deux transactions consommant la même source, elles sont de toute façon incompatibles dans une même blockchain. Et oui la solution la plus simple sans recoder un client pour l’instant est d’attendre que la transaction précédente soit validée avant d’en créer une autre.

Je ne sais pas comment Duniter nettoie sa mempool, mais un jour il décide de la supprimer et elle disparaît effectivement (des nœuds qui la suppriment, mais chaque nœud a une mempool différente).

3 J'aimes

Tu allais attendre jusqu’à quand pour remonter ce problème majeur au projet Silkaj ? Il faut le dire quand quelque chose ne va pas. Ça aide beaucoup le projet. On se rend compte souvent qu’on rencontre le même problème que d’autres personnes. Ça sera pour la prochaine fois :wink:


Tuxmain a déjà bien répondu aux questions, je vais y ajouter mon apport.

J’ai rajouté « source de monnaie ». Ça devrait déjà éclaircir le point sans le détail donné par Tuxmain qui est très bien.

Oui, avec ce contournement ça me semble une bonne piste stable :

Oui, en augmentant la durée entre l’emisison des documents de transactions. Plus de cinq minutes pour être sûr. Mais, c’est surement pas suffisant pour être certain que la transaction passe.

Non, comme expliqué par Tuxmain.

Je sais pas très bien. Voyont voir ce que disent les paramètres de Duniter :

curl g1.duniter.org/blockchain/parameters
{
  "currency": "g1",
  "c": 0.0488,
  "dt": 86400,
  "ud0": 1000,
  "sigPeriod": 432000,
  "sigStock": 100,
  "sigWindow": 5259600,
  "sigValidity": 63115200,
  "sigQty": 5,
  "sigReplay": 5259600,
  "idtyWindow": 5259600,
  "msWindow": 5259600,
  "msPeriod": 5259600,
  "xpercent": 0.8,
  "msValidity": 31557600,
  "stepMax": 5,
  "medianTimeBlocks": 24,
  "avgGenTime": 300,
  "dtDiffEval": 12,
  "percentRot": 0.67,
  "udTime0": 1488970800,
  "udReevalTime0": 1490094000,
  "dtReeval": 15778800
}⏎    
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│                   Certification life-span in the sandbox                   │     a month     │
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│                     Identity life-span in the sandbox                      │     a month     │
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│                    Membership life-span in the sandbox                     │     a month     │
├────────────────────────────────────────────────────────────────────────────┼─────────────────┤

{sig,idty,ms,}Window sont définis. Par contre pour la transaction, le document le plus utilisé, txWindow n’est pas défini. Ça doit surement être la même valeur.

Après, comme dis Tuxmain, chaque mainteneur de nœud pourrait mettre en place des règles différentes sur la mempool de son nœud pour gérer l’expiration des documents.


Concernant la sélection des sources de monnaie dans Silkaj, je ne vois pas trop pourquoi ce problème a lieu. Silkaj enlève les sources des transactions trouvés dans les pendings. Peut-être qu’il est plus rapide que Duniter à mettre à jour ces indexes, soit c’est un bug dans Silkaj. À investiguer.

2 J'aimes

Ok, j’imagine qu’on devrait pouvoir faire ça de notre côté : endormir le script après chaque transaction et le réveiller toutes les 5 minutes jusqu’à ce qu’on constate que la transaction est bien passée. Le script devrait être utilisé essentiellement en arrière-plan via un CRON, donc si on le repense et qu’on le retravaille en ce sens ça ne devrait pas poser de problème.

Quand vous aurez mis en place les transactions chaînées, on parlera des conditions de lock spéciales.

Je suis en plein dedans dans Sakia et c’est passionnant, mais complexe.
Il faut gérer les sources qui se déverrouillent suivant la date, celles qui nécessitent plusieurs signatures, et celles qui nécessitent des mots de passes. Sachant qu’on peut joyeusement mélanger tout ça, vous aurez besoin de plusieurs outils :

  • Chercher un pattern dans la condition pour savoir si on la gère ou pas.
  • Évaluer le script de la condition pour savoir si elle est déverrouillée ou pas (faire un interpréteur de script Duniter quoi…).

J’ai codé les deux cette semaine dans Sakia, grâce à la grammaire des conditions de Duniterpy.

J’en ferai profiter tout le monde quand ce sera prêt…

4 J'aimes

c’est la solution que je compte utiliser… cette fonction sera gérée par le cron_MINUTE.sh des Stations « June / Zen Fontaine » …

Je compte passer ce confinement à la réécriture de G1sms+ vers Astroport.com = G1Bot multicanal + SSB et IPFS :wink:

On active le Web4D.
« Anoptical P2P System », où tous les pouvoirs sont délégués aux individus.

Voila le plan de transformation…
P2Pmesh

Ce sera https://p2p.legal en Monnaie Libre

Après le prix de l’innovation Open Source attribué à axiom-team.fr en décembre dernier pour son action à la promotion de la monnaie libre.
Ce projet a reçu le Label "MIZ :heart: " de la part de la Fondation madeinzion.org

Je n’avais pas rencontré ce problème spécifiquement mais j’ai conscience de l’importance qu’a la façon d’agréger les sources sur la blockchain. Plus petites d’abord. Plus vieilles. Plus grosses… Chaque choix a un impact!
Et de toute façon ça ne pourra jamais encaisser 1000 TX/s
Alors temporiser et consolider est nécessaire.
Zen dans ipfs et cron ont résolut ce problème
Et ssb-g1-tip l’expérimente.

Ce qui est faux, il existe des crypto dont le TPS (Transactions per Second) est bien supérieur à 1000.

txWindow vaut 1 semaine mais ce paramètre va être supprimé en v13 (je vais bientôt soumettre les spec justement).

Chaque nœud sera alors libre de décider combien de temps il gardera une tx dans sa mempool (ce sera probablement fixé a une semaine par défaut).

OK lesquelles?

Alors déjà le TPS de visa est de l’ordre de 1700, il n’y a donc pas besoin de beaucoup plus si on voulait une même monnaie libre pour les 7 milliard d’être humains (mais avoir une même monnaie pour toute la planète ne me semble pas souhaitable).

En tout les cas il existe plusieurs blockchain qui dépassent ce TPS, notamment : fleta, eas, qtum, tron, etc

Ce qui ne veut pas dire que ce doit être un objectif, en dessous de 100 millions d’utilisateurs ont a pas besoin d’un tel TPS, je voulais simplement rappeler que la barrière n’est pas technique, les solutions techniques existent pour avoir de très bon TPS sur blockchain. Sans parler des Lighting Network qui permettent d’aller bien plus loin encore…

L’une d‘elle est elle vraiment totalement décentralisé à consensus public ?
Il y a le Zen dans ipf aussi :wink:

Pas toutes en effet. Mais de toute façon nous n’avons pas besoin de 1000 TPS aujourd’hui. Et avec les Lightning Network (qui sont dans notre roadmap) ont pourra largement dépasser les 10000 TPS (et plus encore), en restant basé sur notre blockchain, donc je ne vois pas l’intérêt d’abandonner le concept de blockchain, ni à court terme, ni a long terme :slight_smile: