I’d like to write a small tool able to read the blockchain and extract some informations. I don’t remember all the explanations during RML8, but I suppose the blockchain is stored by duniter in the file duniter.db.
Is it possible to get some hints on the structure of this file? Thanks.
Gérard
The structure has changed since RML8 anyway. The hints:
If you need more specific answers, please write them and I will try to answer.
Thank you.
J’aurais besoin de consulter les données de piscine pour les identités, certifications et appartenances. Malheureusement, les tables idty, cert et memberships sont presque toujours vides et ne me renseignent pas suffisamment. Je crois que les piscines sont maintenant locales. Comment peut-on accéder à leur ensemble ? @elois Comment fais-tu ?
@gerard94 il te suffit d’ouvrir une copie de la bdd qui se trouve dans ~/.config/duniter/ton-profil/duniter.db avec un explorateur sqlite et pour les données en piscine tout se passe dans les tables avec le suffixe _pending :
identities_pending contient les identités et certifications_pending contient les certifications 
Merci Elois. Chez moi la bdd est dans /home/gerard/.config/duniter/duniter_default/duniter.db. Mais mon problème, c’est que ces deux vues _pending, de même que les tables sous-jacentes idty et cert, sont vides la plupart du temps (à part une ligne ou deux de temps en temps) et ne contiennent pas tout ce que tu affiches sur g1-monit. Est-ce que mon noeud fonctionnerait mal ?
@gerard94 les tables qui finissent en _pending sont les piscines des nœuds, et les données qu’elles contiennent se perdent facilement sur les nœuds qui ne sont sur le réseau que par intermittence, si tu veut que ton nœud duniter est une piscine plutôt complète et conserve cette piscine plutôt complète il faut qu’il soit en permanence sur le réseau et depuis longtemps et en ip fixe et port fixe, car si ton nœud est de retour sur le réseau depuis peu ou que son ip ou port change régulièrement il faut a chaque fois le temps que les autres nœuds te “retrouve”, c’est a dire que tu re-rentre dans leur liste de nœuds connus et joignables, ce qui prend un peu de temps, temps pendant lequel tu ne reçoit pas les données de leur piscine.
g1-monit.elois.org est sur le réseau en permanence depuis des mois et toujours sur la même ip et le même port, c’est ce qui fait que sa piscine est assez complète, il est aussi possible que certains membres bidouilleurs pushes manuellement les donnés de leur nœud vers g1-monit pour qu’il présente des données plus complètes, je sais que @cgeek l’à déjà fait par le passé !
EDIT : pour les tables idty et cert je crois que c’est normal car il me semble que ce sont d’anciennes tables destinées à disparaître. Il te faut utiliser a la place i_index pour les identités et c_index pour les certifications
Alors techniquement ce sont plutôt des vues, sur les tables identity, certification, etc. Donc forcément si ces tables sont vides pour Gérard, alors les vues le seront aussi.
@gerard94 : les piscines sont aussi alimentées à la synchronisation initiale du nœud (en fin de procédure). Ça peut échouer si les piscines sont très fournies et que le nœud qui les renvoie est un peu faible en CPU/disque. Je te conseille d’en refaire une complète, avec Duniter dernière version. Tu devrais avoir toutes les identités en piscine avec au moins 1 certification. Attends-toi à une soixantaine de résultats minimum.
Oui !!! 56 identities_pending et 161 certifications_pending après resynchronisation. Je vais pouvoir travailler. Merci à tous deux.
À propos d’une IP stable, j’étais passé en IPV6, ce qui sûrement l’avenir, mais celles-ci changeaient souvent, voire disparaissaient. Je suis donc revenu sur mon unique IPV4, stable (j’ai une FreeBox). Est-ce qu’il y a un moyen d’avoir une IPV6 stable ?
Par curiosité c’est quoi ton projets ? 
Pour l’instant, j’en ai deux. Le premier serait d’améliorer les prévisions de la date d’entrée dans la toile pour les identités en piscine. J’ai quelques idées d’algorithmes, mais je préfère voir ce que ça donne avant d’en parler plus longuement. Le second serait de pouvoir faire des versements sécurisés avec la méthode “des trois signatures” (https://www.youtube.com/watch?v=jmg2E0bT2vw).
Il y a toujours un problème pour récupérer les données de WOT en piscine sur mon noeud. J’ai effectué une transaction sur Cesium à partir de https://g1.duniter.fr/#/app/. Je l’ai immédiatement reçue sur la table txs de mon noeud. Par contre j’ai envoyé une certification sur une identité non encore membre il y a plusieurs jours par le même Cesium et toujours rien sur ma table cert. Cela pourrait-il être un bug ? Je précise que cette certification apparaît bien sur g1-monit.
Bien que les documents rebondissent de nœud en nœud au moment de leur émission, le rebond n’est pas parfait et certains nœud peuvent ne rien recevoir.
C’est pour cela que les piscines sont tout de même synchronisées manuellement, 1 fois par jour dans la version 1.3 (car le processus est lourd).
Tu peux toutefois forcer la synchronisation des piscines en relançant une synchronisation générale. Si tu disposes de la version Duniter Server, un simple sync g1.duniter.org 80 suffira, sans même réinitialiser les données du nœud. Sinon, il faut en effet refaire une synchronisation complète.
Merci pour les tuyaux. J’ai récupéré spontanément quelques données dernièrement. Je vais surveiller ça.
Pour l’instant, avec une IPV4 stable, il me semble rester à peu près à jour pour les données de piscine. Parfait de ce côté là, sauf que j’aimerais bien me remettre en IPV6 un jour. Il faudra que je fasse d’autres essais.
J’aimerais poser quelques questions sur un domaine qui me paraît toujours mystérieux : le temps de la blockchain et les timestamps.
Dans la table block, quelle est la différence entre les champs time et medianTime ? Comment sont-ils calculés et quels sont leurs rôles respectifs ? Lorsqu’une identité, une certification, une appartenance (membership), etc… apparaît dans un block, ce block possède déjà deux dates (time et medianTime) ; à quoi correspondent alors les blocks_id ou blocks_uid en tant que timestamps ? Par exemple, j’ai cru d’abord que le délai de cinq jours entre deux certifications successives s’écoulait à partir du medianTime du block_uid de la première certification, mais cela donnait des résultats aberrants, jusqu’à ce que je refasse le calcul à partir du medianTime du block où apparaissait ladite certification. Du coup je me suis demandé à quoi servait son timestamp.
Voila, voila. Si une bonne âme pouvait esquisser une réponse et excuser mon ignorance…
Alors je ne sais plus s’il existe un article du wiki qui explique cette notion de temps blockchain mais s’il n’en existe pas il nous faudra le créer !
La blockchain possède son propre temps pour empêcher qu’une minorité malveillante ne trafique les horloges locales de leurs nœuds pour faire retarder la blockchain et empecher là création du DU.
Dans le cas de la Ğ1, le temps blockchain est calculé comme étant le temps moyen des 24 derniers block. Avant c’était la médiane qui était utilisée, d’ou historiquement le nom medianTime. (et la valeur 24 est un paramètre de la monnaie).
Le champ time d’un blocks correspond à l’heure locale de la machine ayant trouvée le block, ce champ n’est utilisé que pour calculer le temps moyen des 24 derniers block et c’est tout. Il te faut donc toujours utiliser le champ medianTime et jamais le champ time !
Concernant la date d’émission d’un document, la date a considérer est la valeur du champ medianTime du block d’émission. Attention selon le phénomène étudié il faut parfois considérer la date d’émission du document (inscrite dans le document sous forme de blockstamp) et parfois la date d’écriture du document en blockchain.
Concernant les disponibilités des certifications le champ qui fait foi est la valeur chainable_on la plus élevée dans les certifications du même émetteur inscrites en blockchain (donc dans c_index).
Wow, merci @elois, je n’espérais pas une réponse aussi rapide.
Le champ medianTime est donc calculé uniquement sur la machine qui a trouvé le bloc. Ce n’est pas une moyenne sur l’ensemble du réseau ? Dans ce cas, rien n’empêche le possesseur du noeud de trafiquer son horloge. Je ne comprends pas bien.
À l’occasion, ce serait bien de préciser ce point. À moins que ce soit déjà dans le protocole, mais il ne me semble pas.
Merci pour c_index. Ça va bien m’aider.
Non, car tout les nœuds tu réseau peuvent vérifier que la valeur du champ medianTime du nouveau block qu’il recoivent correspond bien à la moyenne du champ time des 24 derniers blocks de la blockchain, si la moyenne ne correspond pas le block sera rejeté par le reste du réseau et le noeud malveillant forkera tout seul.
Il n’est pas possible de tricher sans modifier les blocks précédents, ce qu’une blockchain empêche justement, et grâce a la difficulté personnalisée les 24 derniers blocks ont forcément été trouvés par de nombreux calculateurs différents qu’il faudrait donc tous corrompre, bref, c’est les bases du concept de blockchain qu’il te faut revoir là
Si si tout cela est bien spécifié dans le protocole DUP mais c’est un protocole technique énonçant uniquement les règles nécessaires et suffisantes, donc il est très difficile de comprendre en 1ère lecture tout ce qu’il implique, même pour un informaticien !
Dans Bitcoin, cette “impossibilité” (en réalité c’est plutôt une grande difficulté) est liée au fait qu’il faut produire une preuve de travail, et que le niveau de celle-ci dépend des preuves des blocs précédents, et donc finalement de la puissance CPU globale du réseau.
Dans Duniter il y a aussi de cela, mais la preuve de travail est très réduite en difficulté car seuls des membres du réseau peuvent calculer ces blocs (ce qui permet de réduire drastiquement le coût CPU de la blockchain). On s’assure de cela en ayant des blocs signés numériquement (ce n’est pas le cas de Bitcoin), et ces signatures doivent correspondre à des membres. Qui plus est chaque membre a sa propre difficulté.
Je ne crois pas que Gérard ait besoin de cela, il comprend. Il demande simplement quelles sont les règles dans le cas de Duniter. Après tout elles ne sont pas identiques à celles du Bitcoin.