# Évaluation de la règle de distance : cas concret
**URL:** https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694
**Category:** Duniter-v2
**Tags:** distance
**Created:** [14 November 2024 16:12 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694 "2024-11-14T16:12:16Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [14 November 2024 16:12 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/1 "2024-11-14T16:12:16Z")
Dans le post [Déroulé d'une demande d'évaluation de règle de distance](https://forum.duniter.org/t/deroule-dune-demande-devaluation-de-regle-de-distance/12679), 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.
➡ cf [Évaluation de la règle de distance : cas concret - #10 by HugoTrentesaux](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/10) 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.
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [14 November 2024 18:57 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/2 "2024-11-14T18:57:15Z")
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](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/261)
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [15 November 2024 10:44 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/3 "2024-11-15T10:44:16Z")
Plus de détails dans [#261](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/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, )` :
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**
>
> ```auto
> [
> [
> 0x5a172f9a6759763f59a7e0a4d170b467b744eabb3adb454f38a2e7957fb9cd28
> 1
> ]
> [
> 0xa839fec2502624f0e6a3d3562d9286e8a7dacc542f8c41dfc2e59014b7e65f33
> 1
> ]
> [
> 0x86b0d33adf53bdcd249989157ccf2e52db17cfa6acf93c46ce5b3eedf9430f6f
> 1
> ]
> [
> 0x68c31363f71533ab1480e8667a68fdd17be17ec1d54c1ac7c185b8ce4bd33866
> 1
> ]
> [
> 0xa270f4a53e9223dca94ae2892a33ec6a9af0a9e00e82a13471c4ccfa18f2c759
> 1
> ]
> [
> 0x9cc36cc4571f90740bc5bf8ba24cff82d0dacf04fb7d12a8159492c1d94c8b55
> 1
> ]
> [
> 0x08846256456f83f84d13cfe784561800baa363798f79accf9a376c226f44803a
> 1
> ]
> [
> 0xbeeeea669805ed1abcd9aaa2f4a65ce6285a4e1a9387c11dfd73919fc8ffe416
> 1
> ]
> [
> 0x7c5ed718ea243c0996475e142ee52a7212d2281883028a20fde099d77cb42f26
> 1
> ]
> ]
>
> ```
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [15 November 2024 14:15 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/4 "2024-11-15T14:15:02Z")
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](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/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](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/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 😱
(c’est lié au problème de numérotation des fichiers d’évaluation)
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [22 November 2024 16:15 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/5 "2024-11-22T16:15:40Z")
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`.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [22 November 2024 16:20 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/6 "2024-11-22T16:20:46Z")
Ce que tu corriges dans ta MR, c’est juste [#261](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/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](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/262).
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [27 November 2024 09:12 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/7 "2024-11-27T09:12:28Z")
Au hasard du post [Commentaires de transaction dans Tikka](https://forum.duniter.org/t/commentaires-de-transaction-dans-tikka/12722), 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…
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [1 December 2024 17:04 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/8 "2024-12-01T17:04:39Z")
Suite au runtime 900 et avec l’oracle de distance de Duniter 0.9.1, je tente à nouveau l’évaluation :
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`:
Demande enregistrée au bloc [4143084](https://duniter-portal.axiom-team.fr/?rpc=wss%3A%2F%2Fgdev.coinduf.eu#/explorer/query/0x59a11cb9875eca45b6549a3b9cf70e3515dd86c26d8ba2e289b1230a9b9aca2e), 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.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [1 December 2024 17:08 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/9 "2024-12-01T17:08:59Z")
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`.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [1 December 2024 17:12 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/10 "2024-12-01T17:12:38Z")
É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 :
- [4,143,300](https://duniter-portal.axiom-team.fr/?rpc=wss%3A%2F%2Fgdev.coinduf.eu#/explorer/query/0x53313331414a7bc44d075a8821b7f46383029949acb16a01f140277409d0229a) (1 ok)
- [4,143,400](https://duniter-portal.axiom-team.fr/?rpc=wss%3A%2F%2Fgdev.coinduf.eu#/explorer/query/0xde823aca47bdc5bef3f836a726e1e7bc24fbb4e425b51da6e40c66827797cb83) (3 ok, 1 ko)
- [4,143,500](https://duniter-portal.axiom-team.fr/?rpc=wss%3A%2F%2Fgdev.coinduf.eu#/explorer/query/0xaf915a512ad07f40aa23e32e8e9be676e658a0477baa812e2be449a1ff9bc408) (1 ok)
- [4,143,600](https://duniter-portal.axiom-team.fr/?rpc=wss%3A%2F%2Fgdev.coinduf.eu#/explorer/query/0xc8c0314e2b910f7233b71d45320f8060d8a4da12c66f4f7a8545f684fa1c4567) (1 ok)
Zephyr01 a bien été slashé de 10 ĞD qui sont allés dans le treasury :
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [1 December 2024 17:27 UTC](https://forum.duniter.org/t/evaluation-de-la-regle-de-distance-cas-concret/12694/11 "2024-12-01T17:27:23Z")
> [@HugoTrentesaux](#):
>
> `4143300`, et une validation à ce dernier bloc.
Effectivement, cette identité est redevenue membre au bloc [4143300](https://duniter-portal.axiom-team.fr/?rpc=wss%3A%2F%2Fgdev.coinduf.eu#/explorer/query/0x53313331414a7bc44d075a8821b7f46383029949acb16a01f140277409d0229a) comme on peut le voir 🙂
* * *
Je continue avec :
- zencat
- Zedogcompany
- Zaza974
- Zakaria007
- Zofia
- ZestDher