Je ne suis actuellement plus membre de la ĞDev (expiration au bloc 3756656). Pour pouvoir redevenir membre, j’aurais besoin que au moins un des forgerons ait un oracle de distance fonctionnel sur son nœud forgeron.
Et je vous colle mon docker-compose.yml actuel tel quel (qui fonctionnait avant que je ne sois plus forgeron), et le commente en dessus :
# distance oracle uses same image but another entrypoint
services:
distance-oracle:
image: h30x/duniter-v2s-gdev:800.2
entrypoint: docker-distance-entrypoint
environment:
ORACLE_RPC_URL: "wss://gdev.coinduf.eu/"
ORACLE_RESULT_DIR: "/var/lib/duniter/chains/gdev/distance/"
ORACLE_EXECUTION_INTERVAL: "180"
ORACLE_LOG_LEVEL: "debug"
volumes:
- data-smith:/var/lib/duniter
# networks:
# - duniter
# external volume of duniter node to share data for the inherent to read
volumes:
data-smith:
name: duniter-gdev-smith_data-smith
external: true
# external network of duniter node to read data from rpc API
# networks:
# duniter:
# name: duniter-gdev-smith_default
# external: true
j’utilisais l’image h30x/duniter-v2s-gdev:800.2 dans laquelle j’avais introduit quelques correctifs en attendant qu’on en publie une nouvelle, mais normalement la dernière (duniter/duniter-v2s-gdev:latest) devrait fonctionner j’utilisais le endpoint externe ORACLE_RPC_URL: "wss://gdev.coinduf.eu/" pour une raison d’état indisponible qui est corrigée depuis, et n’utilisais pas le réseau docker duniter-gdev-smith_default j’utilise le volume externe data-smith nommé duniter-gdev-smith_data-smith qui correspond à mon nœud forgeron qui tourne dans un autre docker compose
Ça demande un peu d’adaptation, mais ensuite je l’intégrerai à la doc forgeron par défaut.
C’est la période de rotation de pool, donc c’est plutôt 7 blocks × 3 pools × 6 secondes = 126 secondes il me semble. C’est bien pour la gdev je trouve, et on peut effectivement changer ce paramètre pour la g1 si on veut rester à 5 minutes. Il me semble que c’est calé sur les possibilités de spam.
L’identité à évaluer est dans la pool dans laquelle l’oracle peut agir pendant une période seulement, donc pour être sûr que l’oracle puisse agir il faut qu’il tourne avec une période strictement inférieure à 7 blocs. (moins s’il est lent à s’exécuter)
Je ne mettrai pas de cron à 30s sur mon serveur (d’ailleurs la limite de cron est 1 minute). Par contre l’oracle pourrait faire lui-même une boucle infinie avec un sleep, ça évite de recharger un programme assez lourd trop souvent.
Cette variable fait un sleep en bash : docker/docker-distance-entrypoint · master · nodes / rust / Duniter v2S · GitLab. Et effectivement, c’est donc trop long pour l’intervalle. Est-ce que tu veux proposer un runtime upgrade pour mettre un temps qui te semble raisonnable pour un cron (et du point de vue de l’utilisateur de la règle de distance) ?
J’ai un oracle connecté à mon nœud forgeron, mais il n’a rien vu passer depuis:
2024-11-06T17:25:10.846828000+01:00 Waiting 1800 seconds before next execution...
2024-11-06T17:55:10.885163000+01:00 INFO [distance_oracle] Nothing to do: Pool does not exist
2024-11-06T17:55:10.887276000+01:00 Waiting 1800 seconds before next execution...
2024-11-06T18:25:10.906344000+01:00 INFO [distance_oracle] Nothing to do: Pool does not exist
2024-11-06T18:25:10.907622000+01:00 Waiting 1800 seconds before next execution...
2024-11-06T18:55:10.936258000+01:00 INFO [distance_oracle] Nothing to do: Pool does not exist
2024-11-06T18:55:10.939015000+01:00 Waiting 1800 seconds before next execution...
2024-11-06T19:25:10.967320000+01:00 INFO [distance_oracle] Nothing to do: Pool does not exist
2024-11-06T19:25:10.970737000+01:00 Waiting 1800 seconds before next execution...
Où est le problème ? L’info est pas arrivée à mon nœud ou ma configuration/connexion nœud/oracle est fautive ?
Une demande qui n’est pas traitée pendant la période suivant celle où elle est publiée, est perdue. Il faut que l’oracle tourne juste après la demande.
Je comprends pas ta phrase tuxmain. S’adresse-t-elle à moi vis-à-vis de mon message précédent ? Mon oracle tourne depuis plusieurs jours.
J’ai tenté :
cargo run -- identity request-distance-evaluation-for HugoTrentesaux
[caca warnings enlevés]
Enter password to unlock account 5HDikVWZ2xHfqvVVFwex5zmRsH4LuR3KqMgKZYEbCSjStSKw
Password:
transaction submitted to the network, waiting 6 seconds...
Pallet error: Distance::TargetMustBeUnvalidated
Ah, je ne peux pas faire ça, uniquement Hugo peut faire cette demande :
cgli identity --help
[…]
request-distance-evaluation Request distance evaluation make sure that it's ok otherwise currency is slashed
request-distance-evaluation-for Request distance evaluation for unvalidated identity
Oui, effectivement, au début l’évaluation était calée sur les sessions, donc deux heures. Là on est passé à plus court, je croyais qu’on avait visé 5 minutes, mais visiblement c’est encore plus court. Donc le délai de 1800 secondes est à ajuster, disons à 30 secondes, ce qui est trop court pour un cron comme dit tuxmain, donc il nous faut :
se passer de cron ou bash pour l’oracle en utilisant un scheduler directement dans l’exécutable #258
ou ramener le délai à quelque chose de raisonnable pour un cron
Cet appel existe uniquement pour les nouvelles identités, sinon ça permettrait de renouveler l’adhésion de quelqu’un d’autre.
Je peux utiliser sudo aussi pour ça, mais le but est que le parcours membre de Duniter fonctionne au moment où les testeurs de clients (Ğecko, Cesium²) seront plus nombreux.
Je viens de réaliser qu’un délai trop court peut être problématique si trop peu de forgerons ont un oracle de distance parce qu’il n’est pas garanti que :
l’oracle de distance se déclenche assez tôt dans la période d’évaluation
le forgeron forge un bloc dans dans lequel il pourra intégrer le résultat après cette évaluation mais avant la fin de la période
Donc il faut quand même impérativement allonger le délai si on ne veut pas causer trop de hasard.
Bien vu. Si on a f forgerons, e évaluateurs (f >= e >= 1) et n blocs par période, la proba qu’une période n’ait aucune possibilité d’évaluation est (1-e/f)^n.
Il reste à déterminer la proba cible et le e/f auquel on s’attend, pour déterminer n. (et croiser ça avec le calcul de @bgallois sur le risque de spam)
J’avais mis l’oracle dans un processus distinct de Duniter parce que la période d’évaluation était longue et les calculs potentiellement lourds. Ainsi l’un des deux pouvait planter et redémarrer puis recalculer ou publier les résultats un peu plus tard (les résultats étant dans un fichier).
Si la période est courte, c’est moins pertinent et l’oracle peut être un thread de Duniter. Ça permettrait d’éviter de passer par un fichier (on peut utiliser un channel Rust), retire les complexités liées aux options de CLI…
Peut-être même qu’en utilisant le mécanisme d’offchain worker de Substrate on peut se passer de RPC. De plus, le code serait contenu dans le runtime donc mis à jour selon les règles de la blockchain (ce qui fait sens pour la définition de la règle de distance).
Ce serait une super amélioration qui faciliterait le packaging et le travail de forgerons. Ma stratégie personnelle est actuellement de stabiliser une version et un usage, mais je relirai avec plaisir ce genre de contribution !
Waiting 200 seconds before next execution...
DEBUG [jsonrpsee-client] Connecting to target: Target { host: "duniter-smith", host_header: "duniter-smith:9944", _mode: Plain, path_and_query: "/", basic_auth: None }
DEBUG [jsonrpsee-client] Connection established to target: Target { host: "duniter-smith", host_header: "duniter-smith:9944", _mode: Plain, path_and_query: "/", basic_auth: None }
DEBUG [distance_oracle::api] Looking at Pool0 for pool index 2
INFO [distance_oracle] Nothing to do: Pool does not exist
Waiting 200 seconds before next execution...
je semble avoir réussi à mettre en place un oracle…
Avec une période n=100, si on veut garantir que moins de 1/10 000 évaluation échoue, la proportion de forgerons devant évaluer la distance est 1-(1/10000)^(1/n) soit 8,8%.
j’utilisais l’image 
j’utilisais le endpoint externe 
j’utilise le volume externe data-smith nommé 