Évaluation de la règle de distance : cas concret

Support Duniter-v2
1

Dans le post Déroulé d'une demande d'évaluation de règle de distance, je décris le fonctionnement que j’attendais de l’évaluation de la règle de distance.

Avec le runtime 803, la période d’évaluation est repassée à une valeur permettant l’intégration de l’évaluation (100 blocs), on a un exemple de fonctionnement avec les entrées au bloc 3,899,600.

Par contre, je me rends compte que ça ne fonctionne pas comme je m’y attendais, et qu’il y a un bug.
:arrow_right: cf Évaluation de la règle de distance : cas concret - #10 by HugoTrentesaux pour un exemple qui a marché.

  • bloc 3899300, on change de période d’évaluation
  • bloc 3899357, Zoriko-J demande l’évaluation
  • bloc 3899370, zenbio demande l’évaluation
  • bloc 3899388, ZinzinGroues demande l’évaluation
  • bloc 3899400, on change de période d’évaluation, le groupe précédent est figé et les évaluations peuvent commencer
  • bloc 3899428, Zatalyz demande l’évaluation
  • bloc 3899455, zazou demande l’évaluation
  • bloc 3899486, zebulon demande l’évaluation
  • bloc 3899500, on change de période d’évaluation, les évaluations peuvent être publiées
  • bloc 3899506, moul publie un résultat avec succès
  • bloc 3899511, moul tente de publier à nouveau, mais cela échoue, ainsi que toutes les tentatives suivantes
  • bloc 3899514, moul
  • bloc 3899516, moul
  • bloc 3899519, moul
  • bloc 3899521, moul
  • bloc 3899522, moul
  • bloc 3899528, moul
  • bloc 3899545, moul
  • bloc 3899554, moul
  • bloc 3899556, moul
  • bloc 3899577, moul
  • bloc 3899581, moul
  • bloc 3899586, moul
  • bloc 3899595, moul
  • bloc 3899597, moul
  • bloc 3899600, on change de période d’évaluation, les distances suivantes sont évaluées positivement
    • Zoriko-J
    • zenbio
    • ZinzinGroues

Le bug, c’est que le nœud forgeron ne devrait pas réessayer de publier un résultat s’il l’a déjà fait dans la période, ça provoque un échec, ce n’est pas la peine.
Le comportement que j’avais mal compris, c’est qu’il se passe une période entière d’évaluation avant que le forgeron commence à publier son résultat.
Et apparemment l’oracle de moul n’a pas fonctionné à la période suivante puisque Zatalyz, zazou et zebulon n’ont pas reçu d’évaluation entre le bloc 3899600 et 3899700. Tout est vide au bloc 3899700.

2 Likes
2

Au bloc 3899516 = 0x73b455151b8f16277f2a6d2d56823a22a9c71e9e9e8f417739d36e45009807dc, on devrait avoir la clé de moul dans le storage.

currentPoolIndex = 2

evaluationPool2.evaluators = [ 5HDikVWZ2xHfqvVVFwex5zmRsH4LuR3KqMgKZYEbCSjStSKw]

C’est bien la clé de moul. Par contre client/distance/src/lib.rs cherche une clé qui est dans babe_owner_keys.

[edit] j’ai fait une issue Distance client: search for the right key (#261) · Issues · nodes / rust / Duniter v2S · GitLab

2 Likes
3

Plus de détails dans #261, mais en gros, pour passer des clés BABE présentes localement dans le noeud à la clé forgeron, il suffit d’appeler session.keyOwner(babe, <session_key>) :

image
image1876×584 95.6 KB

C’est l’étape qui manquait dans l’oracle. Par ailleurs, s’il y a plusieurs clés localement (par exemple si le forgeron a appelé plusieurs fois author.rotateKeys(), pour savoir laquelle des clés est celle en ligne, il faut regarder dans babe.authorities() :

clés BABE actuelles de tous les forgerons 
[
  [
    0x5a172f9a6759763f59a7e0a4d170b467b744eabb3adb454f38a2e7957fb9cd28
    1
  ]
  [
    0xa839fec2502624f0e6a3d3562d9286e8a7dacc542f8c41dfc2e59014b7e65f33
    1
  ]
  [
    0x86b0d33adf53bdcd249989157ccf2e52db17cfa6acf93c46ce5b3eedf9430f6f
    1
  ]
  [
    0x68c31363f71533ab1480e8667a68fdd17be17ec1d54c1ac7c185b8ce4bd33866
    1
  ]
  [
    0xa270f4a53e9223dca94ae2892a33ec6a9af0a9e00e82a13471c4ccfa18f2c759
    1
  ]
  [
    0x9cc36cc4571f90740bc5bf8ba24cff82d0dacf04fb7d12a8159492c1d94c8b55
    1
  ]
  [
    0x08846256456f83f84d13cfe784561800baa363798f79accf9a376c226f44803a
    1
  ]
  [
    0xbeeeea669805ed1abcd9aaa2f4a65ce6285a4e1a9387c11dfd73919fc8ffe416
    1
  ]
  [
    0x7c5ed718ea243c0996475e142ee52a7212d2281883028a20fde099d77cb42f26
    1
  ]
]
4

On dirait qu’il y a un autre problème. Par exemple, au bloc 3,913,084, le nœud forgeron de moul continue à essayer de publier un résultat et obtient l’erreur distance.WrongResultLength, parce qu’aucune évaluation n’est en attente.

Et là, c’est entièrement ma faute, en relisant !252, j’ai omis que remplacer session_index par pool_index n’avait pas de sens, puisque le premier est incrémental alors que le second est modulo 3.

Ticket correspondant : #262.

Pire, au bloc 3,913,400 ce sont les résultats de la session précédente qui ont été pris en compte. Et donc zebulon a pu renouveler son adhésion alors que la règle de distance n’était pas respectée :scream:
(c’est lié au problème de numérotation des fichiers d’évaluation)

2 Likes
5

C’est corrigé dans master : si vous faites tourner un oracle de distance, vous pouvez mettre à jour Duniter et l’oracle et ça devrait marcher.

Note si vous voulez tester l’oracle avec un nœud de test local (duniter --dev --tmp) : le dossier par défaut de l’oracle (option -d) n’est pas le bon dans ce cas, il faut trouver celui généré par Substrate dans /tmp/substrateXXXXX.

6

Ce que tu corriges dans ta MR, c’est juste #261, soit la re-publication dans la même période (qui donne un ExtrinsicFail).

Il reste encore la possibilité qu’un fichier “1” soit produit par l’oracle alors que le noeud n’est pas forgeron, puis soit soumis à une période ultérieure par le forgeron (et supprimé), mais que ce ne soit pas à la bonne période. D’où l’utilité de #262.

7

Au hasard du post Commentaires de transaction dans Tikka, je vois dans le bloc 4073116 qu’une évaluation est publiée alors qu’elle n’aurait pas dû. Mais bon, c’est les aléas d’un système en train de changer…

image
image952×834 74.3 KB

8

Suite au runtime 900 et avec l’oracle de distance de Duniter 0.9.1, je tente à nouveau l’évaluation :

image
image1250×997 119 KB

Cette identité est non membre car son adhésion a expiré, elle respecte la règle de distance et a 5 certifications reçues actives.

J’utilise donc sudo pour l’incarner et demander à renouveler son adhésion avec request_distance_evaluation:

image
image1759×565 78.8 KB

Demande enregistrée au bloc 4143084, ce qui devrait aboutir à un calcul entre les blocs 4143100 et 4143200, une publication entre les blocs 4143200 et 4143300, et une validation à ce dernier bloc.

9

Pareil pour Zoulya qui vient d’être certifiée par zenbio et Zoriko-J, dont la demande a été intégrée au bloc 4,143,136.

image
image1065×1245 150 KB

10

Évaluations demandée :

  • Zoroastre : 4,143,084
  • Zoulya : 4,143,136
  • Zephy : 4,143,158
  • Zenobie : 4,143,166
  • Zephyr01 : 4,143,175 (résultat négatif attendu)
  • zabou73 : 4,143,268
  • zadkiel : 4,143,307

Résultats aux blocs :

Zephyr01 a bien été slashé de 10 ĞD qui sont allés dans le treasury :

image
image308×480 27.6 KB

11

Effectivement, cette identité est redevenue membre au bloc 4143300 comme on peut le voir :slight_smile:

Je continue avec :

  • zencat
  • Zedogcompany
  • Zaza974
  • Zakaria007
  • Zofia
  • ZestDher