Problème fenêtre courante dans Remuniter, Cesium et Silkaj

[elois]

Remuniter et silkaj considèrent que le bloc courant fait parti de la fenêtre courante, or d’après les règles BRG_04 et BR_G18 (entre autre), ce n’est pas le cas :

HEAD.issuersCount = COUNT(UNIQ((HEAD~1..<HEAD~1.issuersFrame>).issuer))
blocksOfIssuer = HEAD~1..<HEAD~1.issuersFrame>[issuer=HEAD.issuer]

Je me suis rendu compte de cet écart en testant une contribution de @ji_emme a Dunitrust qui consiste en l’ajout d’une commande blocks affichant l’équivalent de la commande blocks de silkaj (affichage du nombre de blocs forgés par chaque membre dans la fenêtre courante).

Afin de tester, j’ai comparé les résultats avec ceux affichés par remuniter et silkaj. Et c’est la que j’ai trouvé la différence. J’ai d’abord pensé a un bug coté Dunitrust mais après vérification des spécifications il s’avère que c’est remuniter et silkaj qui ont tord

Cesium est également concerné dans le calcul de la difficulté personnalisée des membres (vue réseau en mode expert).

ticket Silkaj: blocks cmd: wrong current frame (#243) · Issues · clients / python / silkaj · GitLab
ticket Cesium: Vue réseau mode expert: Difficulté personnalisé incorrecte (#840) · Issues · clients / Cesium-grp / Cesium · GitLab
ticket Remuniter: Wrong current frame · Issue #17 · duniter/remuniter · GitHub

[Moul]

Ça serait pas plus intéressant de faire les choses dans l’autre sens, à savoir considérer le bloc courant dans la fenêtre courante ?

C’est un comportement connu de cgeek, mais qui n’a pas été modifié, car peu prioritaire.

Avoir un protocole cohérent plutôt que demander aux clients d’implémenter un comportement non-cohérent. À moins, que le fait de ne pas inclure le bloc courant dans la fenêtre courante a du sens ? S’agit-il d’une fonctionnalité ?

Réimplémenter de nouveau un protocole est le moment idéal pour remettre à plat le protocole et corriger ses petites imperfections. Luxe que n’avait pas l’auteur du protocole et son implémentation.

[elois]

Au fond je comprend tout a fait @Moul mais on ne peut hélas pas procéder ainsi

Il nous faut d’abord une v1 de Dunitrust en prod qui fasse ses preuves en appliquant le protocole existant a la lettre, et c’est seulement quand cette étape sera passée que nous (les dev de dunitrust) pourront proposer des changements de protocole.

Tant que cette étape n’est pas atteinte c’est Duniter qui sert de référence et tout changement de protocole doit d’abord être implémenté dans Duniter, donc pour le moment je me contente de suivre les changements de Duniter quand il y en a.

Soit les clients s’adaptent à la lettre au protocole existant soit le bug vas traîner encore au moins 2 ans (sauf a ce qu’un développeur de Duniter implémente ce changement de protocole avant).

Et ça ne c’est rien @Moul , il y a beaucoup de comportements “non-cohérents” que je suis obligé d’implémenter dans Dunitrust et qui te ferait bondir (comme reproduire artificiellement les failles de la grammaire de parsing des documents de Duniter), cela est indispensable pour garantir que les utilisateurs de la Ğ1 ne subiront pas de régression.

Enfin, ce qui nous parait “non-cohérent” peut en fait l’être pour des raisons qui nous échappent, c’est pour cela que tout changement de protocole doit faire l’objet d’une proposition formalisée et validée par des pairs

[Moul]

Oui, excuse-moi, c’est pas le bon moment pour effectuer des changements de protocoles à l’initiative du projet Dunitrust.

La commande blocks a avant tout pour but de monitorer le réseau, et ne pas afficher le bloc courant c’est mettre à mal cette fonctionnalité.

Suivant l’affichage en mode compact ou non des blocs, ça peut-être fait. En affichage compact, c’est possible de respecter cette règle. Par contre, en affichage non-compact, je souhaite que le bloc courant soit affiché. Peut-être en séparant le bloc courant des blocs de la fenêtre courante (en ajoutant le dernier manquant).

[elois]

Arf je me suis emmêlé les pinceaux ce jour la

Je crois qu’en réalité il n’y a pas de bug, c’est moi qui avais oublié une subtilité essentielle ce jour-là :

Les règles du protocole sont décrites dans le contexte ou l’on est dans la validation globale, on est en train de valider le bloc HEAD, qui n’est donc pas encore “appliqué”, le dernier bloc appliqué est donc bien HEAD~1.

De sorte que la fenêtre courante contient bien le dernier bloc appliqué.

En revanche, j’ai repéré une autre subtilité : il est en réalité impossible de connaître de manière exacte la difficulté personnalisée d’un membre sans faire d’hypothèse sur le contenu du prochain bloc.

En effet, conformément a la règle BR_G18, la difficulté personnalisée d’un membre dépend de HEAD.powMin. Mais HEAD désignant le prochain bloc chaînable qu’on essayera d’empiler, on ne peut pas connaître son contenu avant de le recevoir.

Or, selon quel nœud trouve le prochain bloc, il n’aura pas inséré le même time que les autres, on ne peut donc pas prédire de manière exacte la valeur du champ powMin du prochain bloc.

Cette remarque a toute son importance pour qui développe un nœud, mais pour les clients qui n’affichent la difficulté personnalisée qu’à titre informatif (Silkaj, Césium, etc), ce n’est pas très important, car la variation sera au maximum de ±2 par rapport à l’hypothèse “powMin restera identique”.
Si l’on veut être exact, il serait souhaitable de préciser dans les vues qui affichent la difficulté personnalisée d’indiquer qu’il s’agit d’une approximation à ±2 près.

[Moul]

@elois

En est tu certain ? Comment silkaj défini la fenêtre courante et comment en récupère t’il son contenu ?

Oui, tu as raison. Pour que Silkaj soit compatible avec DUBPv12, silkaj blocks devrait afficher le bloc courant séparément des blocs de la fenêtre courante. Une ligne pourrait séparer le bloc courant des blocs dans la fenêtre courante du style :

silkaj -gt blocks 5
Last 5 blocks from n°546846 to n°546850
|   block |       gentime       |     mediantime      |    hash    |   powMin |        uid        |
|---------+---------------------+---------------------+------------+----------+-------------------|
|  546851 | 2020-04-09 13:43:26 | 2020-04-09 12:31:50 | 000000B151 |       92 | matograine-G1Test |
|---------+---------------------+---------------------+------------+----------+-------------------|
|  546850 | 2020-04-09 13:37:29 | 2020-04-09 12:25:53 | 000001BADE |       92 |       cgeek       |
|  546849 | 2020-04-09 13:31:43 | 2020-04-09 12:20:07 | 000000AC3F |       92 |     moul-test     |
|  546848 | 2020-04-09 13:26:08 | 2020-04-09 12:14:32 | 000001BEAD |       92 | matograine-G1Test |
|  546847 | 2020-04-09 13:20:31 | 2020-04-09 12:08:55 | 0000009922 |       92 |       vit2        |
|  546846 | 2020-04-09 13:14:52 | 2020-04-09 12:03:16 | 0000013325 |       92 |     moul-test     |

au lieu de :

Last 5 blocks from n°546847 to n°546851 
|   block |       gentime       |     mediantime      |    hash    |   powMin |        uid        |
|---------+---------------------+---------------------+------------+----------+-------------------|
|  546851 | 2020-04-09 13:43:26 | 2020-04-09 12:31:50 | 000000B151 |       92 | matograine-G1Test |
|  546850 | 2020-04-09 13:37:29 | 2020-04-09 12:25:53 | 000001BADE |       92 |       cgeek       |
|  546849 | 2020-04-09 13:31:43 | 2020-04-09 12:20:07 | 000000AC3F |       92 |     moul-test     |
|  546848 | 2020-04-09 13:26:08 | 2020-04-09 12:14:32 | 000001BEAD |       92 | matograine-G1Test |
|  546847 | 2020-04-09 13:20:31 | 2020-04-09 12:08:55 | 0000009922 |       92 |       vit2        |

Ce que je ne comprends pas, c’est pourquoi DUBP n’intègre pas le bloc courant dans la fenêtre courante ? Y’a-t-il une raison technique à ce choix ? Peut-on l’ajouter ?

[elois]

@Moul

Ce que je ne comprends pas, c’est pourquoi DUBP n’intègre pas le bloc courant dans la fenêtre courante ? Y’a-t-il une raison technique à ce choix ? Peut-on l’ajouter ?

Oui il y a au moins deux raisons technique :

@elois

Les règles du protocole sont décrites dans le contexte ou l’on est dans la validation globale , on est en train de valider le bloc HEAD , qui n’est donc pas encore « appliqué » , le dernier bloc appliqué est donc bien HEAD~1 .

@elois

il est en réalité impossible de connaître de manière exacte la difficulté personnalisée d’un membre sans faire d’hypothèse sur le contenu du prochain bloc.

En effet, conformément a la règle BR_G18, la difficulté personnalisée d’un membre dépend de HEAD.powMin . Mais HEAD désignant le prochain bloc chaînable qu’on essayera d’empiler, on ne peut pas connaître son contenu avant de le recevoir.

Or la fenêtre courante sert par définition a calculer la difficulté personnalisée, elle ne peut donc pas inclure le dernier bloc

[Moul]

Ok, merci. Ce choix technique s’éclaircit mais n’est pas tout fait net pour moi.

Par contre, le premier point n’est pas une raison technique. Il est selon moi une conséquence d’un choix technique (2.) dont en découle une règle dans le protocole. C’est une règle du protocole, rien de plus.

Je pense qu’étudier la règle BR_G18 me permettrais de comprendre que ce que tu dis ne permet pas de faire autrement.

[elois]

@Moul en fait c’est un problème de définition et de manière dont les clients récupèrent le contenu de la fenêtre courante.

Je vois bien intuitivement que ce qu’il te semble logique d’afficher coté client c’est la fenêtre courante a HEAD+1, et a ta place je voudrais faire pareil, c’est logique coté client. Mais Duniter ne le fait pas aujourd’hui car il n’en a pas besoin, il n’actualise la fenêtre courante que lors de la validation d’un nouveau bloc « candidat ».

Il suffirait que silkaj calcula a la mano la fenêtre courante suivante, ça pourrait être aussi fait par GVA (a ajouter a la TODO list)