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.
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 :
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
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 ?
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.
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??
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).
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…
