Déroulé d'une demande d'évaluation de règle de distance

Je décris ici le déroulé d’une demande d’évaluation de la règle de distance telle qu’effectuée lors de l’adhésion ou la ré-adhésion. Cette évaluation à lieu en trois temps qui correspondent aux périodes d’évaluation. Une période d’évaluation trop longue ralentit les entrées dans la toile, et une période d’évaluation trop courte augmente les probabilités d’erreur si tous les forgerons n’ont pas un oracle qui s’exécutent suffisamment fréquemment (cf Besoin de plus de forgeron avec oracle de distance!). Dans cet exemple, je vais utiliser une période d’évaluation de 100 blocs.

:warning: J’avais mal compris le fonctionnement des périodes, cf le sujet Évaluation de la règle de distance : cas concret. J’attends d’être sûr avant de modifier ce qui suit.

  • bloc 90000 : nouvelle période d’évaluation 900
  • bloc 90005 : Alice envoie une cinquième certification à Eve et demande l’évaluation de la règle de distance, cette demande d’évaluation est ajoutée à la piscine de la période actuelle
  • bloc 90022 : Bob souhaite renouveler son adhésion proche de l’expiration malgré un warning disant qu’il en respecte pas la règle de distance. Il envoie une demande d’évaluation qui vient rejoindre la précédente
  • bloc 90100 : nouvelle période d’évaluation 901, la piscine est figée, les oracles peuvent commencer à calculer, en utilisant la toile au bloc 90100 comme référence
  • bloc 90101 : Serge a un oracle qui s’exécute à tous les blocs, il calcule donc un résultat et le place à disposition de son noeud forgeron
  • bloc 90108 : Sabine calcule un bloc, mais elle n’a pas encore d’évaluation à disposition, donc elle ne publie pas de résultat
  • bloc 90120 : Sabine a réglé son oracle pour s’exécuter tous les 100 blocs, et il tombe peu après le début de la période, elle a donc un résultat à disposition
  • bloc 90133 : Serge calcule son premier bloc de la période, et publie le résultat de son oracle dans un inherent
  • bloc 90155 : Sabine calcule son deuxième bloc de la période, elle peut donc publier son résultat dans un inherent
  • bloc 90188 : l’oracle de Samuel s’exécute tard dans la période, il a un résultat à disposition
  • bloc 90200 : nouvelle période d’évaluation 902, il y a deux résultats publiés (Serge et Sabine), Samuel avait un résultat, mais n’a pas forgé de bloc et n’a donc pas pu le publier.
    • la distance de Eve est ok, elle passe donc membre et Alice récupère sa caution
    • par contre, la distance de Bob est ko, il perd sa caution et devra demander une autre évaluation en faisant bien attention cette fois de respecter la règle de distance

Voilà un exemple de déroulé. Les périodes d’évaluation tournent, c’est-à-dire qu’il y a toujours une piscine prête à recevoir les nouvelles demandes d’évaluation, une piscine qui reçoit les évaluations, et une piscine vidée en début de période pour appliquer les résultats.

3 Likes

:thinking: 90100 je présume.

Sinon merci du rappel de fonctionnement !

1 Like

Merci pour ce déroulé. Bien que ma représentation me semble encore assez flou. Donc, à relire attentivement.

Quand l’oracle calcule des distances, il publie le résultat en local. Du coup, uniquement le nœud forgeron accolé peu intégrer cette information dans un bloc ? Ai-je correct ?

1 Like

Bien vu @cgeek pour la coquille :slight_smile:

Exactement !

L’architecture qui a été retenue (cf Calcul de distance via oracle) est que l’oracle puisse fonctionner indépendamment de Duniter et dépose le résultat dans un fichier, lequel sera lu par Duniter. D’autres options de communication entre l’oracle et Duniter sont possibles, comme suggéré dans ce message :

Et effectivement, la publication se fait dans un inherent (https://docs.substrate.io/learn/transaction-types/#inherent-transactions), donc soumis par l’auteur du bloc.