Bug fenetre courante dans remuniter, cesium et silkaj

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 :stuck_out_tongue:

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

ticket Silkaj: https://git.duniter.org/clients/python/silkaj/issues/243
ticket Cesium: https://git.duniter.org/clients/cesium-grp/cesium/issues/840
ticket Remuniter: https://github.com/duniter/remuniter/issues/17

3 J'aimes

Ç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.

2 J'aimes

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

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 :slight_smile:

2 J'aimes

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).

1 J'aime

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

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.

2 J'aimes