Bonjour à tous,
Depuis quelques jours, je me documente sur les changements qui ont été faits dans Duniter v2 pendant ces 2 ans où j’étais absent.
Je découvre qu’il a été décidé de sanctionner monétairement le compte qui demande l’évaluation de la règle de distance pour une identité si le résultat de l’évaluation est négatif.
J’imagine que l’intention est de protéger du spam, mais cela me semble impliquer trop de défauts pour les wallets et pour les utilisateurs. Je vais expliquer les défauts puis proposer une alternative.
1. Implique au wallet de vérifier la distance offchain au préalable (ou de créer un intermédiaire pour le faire)
Si chaque wallet vérifie la distance localement :
- Développements complexes pour les wallets
- Risques de bugs, car les implémentations arrondissent différemment (on avait eu le problème sur la v1 entre le module C++ et le module Rust qui arrondissent les flottants différemment).
- Demande au wallet de télécharger l’intégralité du graphe de la TdC, ce qui n’est pas envisageable en cas de faible connexion
- Demande beaucoup de calculs en local, ce qui n’est pas envisageable pour des ordiphones avec une configuration matérielle modeste
Si des intermédiaires vérifient la distance offchain et font la demande :
- Rajoute un logiciel dans un écosystème technique déjà très complexe. Et même si c’est intégré à un logiciel existant, cela ajoute encore un autre type d’acteur alors qu’on en a déjà beaucoup (forgerons, indexeurs, nœuds miroirs RPC, etc.)
- Ces acteurs intermédiaires prennent des risques (voir partie 2) sans rémunération ; il faudrait les rémunérer pour leur travail. Cela complexifie encore le modèle d’incitations économiques à mettre en place pour pérenniser l’écosystème sur le long terme.
- Ces acteurs ont un pouvoir de censure. Ils peuvent blacklister des membres, les empêchant de renouveler leur adhésion. C’est aussi le cas pour les nœuds miroirs RPC, c’est pourquoi il faut décentraliser le réseau RPC, ce qui est déjà complexe. Ces acteurs pourraient être des nœuds RPC avec une option de configuration particulière, mais cela complexifie la compréhension du réseau. Il faudrait ajouter un flag dans les fiches de peer, etc.
2. La distance peut passer sous le seuil entre la pré-évaluation offchain et l’évaluation onchain
Imaginons qu’un membre atteigne tout juste 80 % des référents. Il suffit qu’un autre membre devienne référent en émettant une certification à l’autre bout de la toile pour que, d’un coup, le membre évalué passe à 79,9 % des référents, alors que rien n’a changé concernant ses certifications à lui.
Le relayeur qui signe la demande d’évaluation prend donc un risque : celui d’être sanctionné monétairement même si la pré-évaluation était correcte.
Il faudrait pré-évaluer contre un état correspondant au bloc sur lequel vont se baser les oracles pour le prochain “round”, ce qui n’est faisable que si les rounds sont suffisamment longs et annoncés à l’avance.
3. Si l’identité ne respecte pas la distance, quelqu’un doit redemander régulièrement pour elle
Aujourd’hui, dans la v1, l’utilisateur demande l’adhésion une fois, et son adhésion est inscrite automatiquement dans le futur quand les conditions sont réunies. Dans la v2, en l’état actuel, il faut qu’un acteur redemande l’évaluation de la distance, sinon l’identité ne (re)deviendra pas membre même si elle respecte les critères. C’est une perte de fonctionnalité pour les utilisateurs.
J’avais déjà ces potentiels problèmes en partie en tête il y a 4 ans. C’est pour cela que mon idée de départ était de mesurer la distance dans l’intégralité de la toile toutes les 4h (à chaque session/epoch). Cela avait aussi le bénéfice de permettre à une identité qui n’atteint pas le seuil d’être réévaluée automatiquement jusqu’à ce qu’elle atteigne le seuil ou que la demande expire.
À l’époque, cette approche faisait d’autant plus sens que quelqu’un travaillait sur un algorithme permettant d’évaluer l’intégralité de la toile en un temps raisonnable par rapport au nombre de membres.
Question : comment fonctionne l’algorithme de l’oracle de distance maintenant ? Est-ce qu’il parcourt toute la toile ?
Solution alternative :
Ajouter un paramètre DistanceRetryPeriod dans la palette distance (en nombre d’EstimationPeriod).
Stocker tout les index d’identités en échec dans un set IdtyToRetry: [idty_indexes].
Stocker tous les index d’identités en échec dans une map IdtyToRetryPerPeriod: (EstimationPeriodIndex, [idty_indexes]).
Rejeter toute nouvelle demande d’estimation pour une identité dans le set IdtyToRetry.
À chaque début d’estimation, prendre (take) le tableau [idty_indexes] correspondant dans la map IdtyToRetryPerPeriod et filtrer pour enlever toutes les identités dont le statut est IdtyStatus::Revoked (les retirer aussi du set). Pousser toutes les autres dans la prochaine pool d’estimation.
Au résultat d’estimation: Supprimer du set et de la map les identités qui respectent la règle. Ajouter dans le set et la map “retry” toutes les identités en échec avec period index: CurrentPeriodIndex + T::DistanceRetryPeriod
Pour la migration vers la v2, je suggère de simplement supprimer la sanction pour le moment.
Il y a déjà plusieurs checks qui protègent du spam, notamment le fait de devoir recevoir 5 certifications valides pour que la distance soit évaluée. Cela est déjà aussi sécurisé contre le spam que la v1 en production depuis 8 ans.
Qu’en pensez-vous ? 