Bug de synchro des piscines

Bonsoir à tous,

J’ai certifié il y a à peu près 2 semaines Ivanoe. Voulant voir si son statut avait avancé (s’il avait trouvé d’autres certifs notamment), je suis allé voir sur g1-monit et vu qu’Ivanoe avait 2 certifs seulement et pas 3 (il lui manque la mienne).
Retour sur Césium : ma certif apparaît.
J’ai alors changé de noeud sur Césium (j’étais à la base sur g1.duniter.org) pour voir et surprise : certains noeuds ont cette certification, d’autres ne l’ont pas (notamment celui de @elois sur lequel pointe g1-monit )

Du coup, j’ai pensé éventuellement rejouer cette certification depuis Césium en me positionnant sur un noeud « ignorant » mais j’ai peur que ça mette le b…l et je voulais vous demander avant.

Ces bug de synchronisation arrivent-ils souvent ?

Merci de vos réponses.

Salut !

Si vous avez un noeud Duniter CLI, une solution plus propre est de faire :

duniter import-lookup Ivanoe g1.duniter.org 443 ts.g1.librelois.fr 443

qui va renvoyer les documents liés à l’identité Ivanoe depuis g1.duniter.org vers ts.g1.librelois.fr

Je n’ai pas accès à mon noeud présentement. Indiquez-moi si ça vous est impossible, je le ferai dès que je rallumerai mon ordi sous Debian GNU.
voir ce post à ce sujet.

Souvent je ne sais pas, mais on a ce genre de questions régulièrement, oui. Genre une fois tous les 2-3 mois.


Si ce support vous est utile, vous pouvez contribuer au développement logiciel et humain de Ğ1 sur la clef Ğ1cotis :

bg3AoYQKeyzaJaQoXJQATehLCk5wRFnYEvdRyjgg9LT
3 J'aimes

Super. Je viens de lancer la commande. Ça a marché. Merci pour lui :wink:

2 J'aimes

Bonsoir @piaaf31 :slight_smile:

Ce ne sont pas des bug, tout réseau décentralisé est nécessairement incomplet et incohérent. La seule garantie de synchronisation porte sur le contenu de la blockchain (c’est justement a cela que sert une blockchain). Les mempools/piscines/sandbox n’ont jamais étés et ne seront jamais parfaitement synchronisés, c’est tout simplement impossible et de toute façon pas nécessaire.

Il suffit qu’une seul nœud membre est le dossier d’inscription complet pour l’écrire dans un bloc, plus de noeuds ont le dossier complet plus il a de chances d’être écris rapidement, mais il n’est nul besoin que tous l’ai :wink:

2 J'aimes

Merci pour les précisions :wink:

Donc le fait qu’un document émis peut n’être écrit qu’après plusieurs blocs vient du fait que l’écrivain d’un bloc ne l’a pas forcément en mempool, ou bien seulement d’un problème d’horodatage, de décalage de l’heure blockchain avec l’heure du document ?

C’est exactement ça oui :slight_smile:

Non aucun rapport puisque le document est horodaté avec un blockstamp forcément existant, ça ne peut être le cas que pour un nœud sur une branche de fork.

1 J'aime

Je pense que lors de la création de comptes multiples effectué à la création de billets, je me heurte à la taille de piscine du noeud auquel je m’adresse.
Résultat de mon dernier test: 29 transferts passés sur 54 demandés par paquet de 6 echelonnés de 2 secondes toutes les 2 minutes.

Pour ne plus me heurter à cette limite, je me demandais s’il vallait mieux changer de noeud régulièrement pour passer les TX ou demander à synchroniser les piscines??

Changer de nœud régulièrement, ce qui participe a décentraliser le réseau en ne chargeant pas toujours les mêmes noeuds :slight_smile:

Ce doit aussi être possible d’envoyer le même document à plusieurs noeuds, non ?

Oui mais pas a tous, sinon tu spam le réseau pour rien. Perso si je codai un truc qui doit envoyer des tx au réseau je piocherai 2 ou 3 noeuds sur les N noeuds que je connais a l’instant t et j’enverrai mon lot de tx a ces 2 ou 3 noeuds, ainsi j’augmente mes chances que mes tx soient traitées sans spammer tout le réseau (juste 3 noeuds parmi N).

1 J'aime

Quel client actuel pourrait posséder cette aptitude? Tant que j’utilise silkaj, je ne peux en choisir qu’1 parmi N.

Tu peut contribuer a silkaj pour ajouter cette feature :slight_smile:

Duniterpy 0.55.0+ te permet de travailler en P2P grâce à la commande API api.bma.network.ws2p_heads.

Cela te donne les blockchains des pairs du nœud questionné et ainsi de connaître :

  • la blockchain majoritaire
  • les nœuds étant sur la blockchain majoritaire

Tu peux ensuite répartir correctement tes TX sur ces nœuds comme indiqué par elois.

2 J'aimes

@vtexier Cool !!

Les autres fonctions en profitent directement?
Comme https://git.duniter.org/clients/python/duniterpy/blob/master/examples/send_transaction.py

Un collègue libre aguerri à la bibliothèque du python passe me voir demain soir.
Parce qu’il me faut toujours du code à Hacker pour que je puisse commencer à bricoler.

Dans la fabrique de vêtements, je ne sais que le coudre, pas le tisser…

Non, il faut le faire « à la main », en partant des « heads » brutes, afin d’obtenir une liste de nœuds à jour. Mais on prévoit d’ajouter une fonction helper générique qui permettra d’obtenir une liste de « endpoints » des nœuds sur la blockchain majoritaire. Stay tuned…

Sinon j’ai des ourlets à faire… :wink:

1 J'aime