Je viens de voir ce message, je ne recommande pas les offchain worker, ils présentent plusieurs inconvénients.
Dans le cas de la distance, l’inconvénient principal est de faire le calcul dans un runtime WASM plutôt qu’en natif, ce qui est plus lent et ne peut pas profiter d’optimisations bas niveau.
Par contre il est possible d’intégrer le calcul de distance dans le binaire client et ne pas avoir besoin de RPC. Le projet Polkadex à fait ça et expliquent comment faire dans cette conférence: https://www.youtube.com/watch?v=iKqdXNo0OH4 (leur cas d’usage est financier mais c’est le procédé technique que je veux mettre en avant ici).
Je reviens à propos de la période d’évaluation qui me semble trop courte.
Le nombre de blocs de la période est aussi le nombre d’évaluateurs au maximum. En plus de la forte probabilité de ne pas être évalué, il y a la forte probabilité qu’un ou deux évaluateurs se retrouvent seuls durant une période, ce qui permet de tricher (un seul tricheur peut influencer la médiane s’il y a deux échantillons).
Il faut mesurer la proportion d’évaluateurs et décider du taux d’échec acceptable. Je pense que l’échec par manque d’évaluateur est à éviter, car il faudra expliquer aux gens que devenir membre, c’est jouer au loto.
D’ailleurs je vois qu’il manque un événement en cas d’absence d’évaluation [edit Hugo → #317]. Pour les clients et l’indexeur : est-ce que ce serait utile ? Plutôt indiquer la pool lors de la demande, puis faire un événement collectif à la fin, et vous laisser déterminer les identités concernées, ou bien indiquer les identités dans l’événement ?