Je pensais que les _blocking n’étaient que des wrappers transformant la fonction en future et ajoutant .await. Donc que bloquant ou pas ne changerait pas l’effet sur les autres tâches (et que rt-multi-thread permet moins de congestion en utilisant plusieurs threads, mais je n’ai pas l’impression qu’on l’utilise).
Non pas du tout, si tu regardes les définitions des types ça attend des futures dans les 2 cas.
Ici c’est relatif au fonctionnement interne de tokio, qui à deux threadpool (les deux sont déjà multi-thread), un pour les taches dont l’exécution est effectivement asynchrone et un pour les autres taches (dites blocking).
Un code est considéré comme effectivement asynchrone s’il occupe très peu de temps cpu entre deux yield.
Je précise que là c’est des notions qui n’ont aucun rapport avec substrate, c’est purement la notion même d’asynchrone, je t’invite à lire des articles sur le sujet, comme celui-ci par exemplei: Async: What is blocking? – Alice Ryhl
1 Like
Non c’est de la merde, recommence et fait mieux stp. Un peu de sérieux.
Je vais finir par le faire en python.
En fait on va plutôt partir sur l’exploration de graphe à l’ancienne, qui est en temps borné en fonction de N. Les matrices prennent beaucoup trop de mémoire (quadratique, et dès qu’on dépasse les quelques Go ça ne tient plus en RAM donc ça fait exploser le temps d’exécution).
Après je ne perds pas l’espoir d’un algo distribué de produit de matrices à l’aide de sous-matrices, mais ça devient très compliqué, surtout si on veut un résultat vérifiable. (et je ne sais même pas s’il existe un algo pour ça)
3 Likes
Pour info, et pour éviter qu’on ne soit plusieurs à bosser sur la même feature, je me penche sur une 1ère implémentation sans Oracle (à la fois pour me faire la main sur Substrate et pour voir dans quelle mesure ce pourrait être suffisant dans un premier temps).
J’ai déjà pas mal avancé, mais j’ai encore besoin de temps avant de présenter du code.
7 Likes
Suite à la publication des résultats de benchmarks basés sur le pire cas actuel de la toile Ğ1, j’en conclue que nous pouvons effectivement nous passer temporairement d’Oracle.
Je compte proposer une MR prochainement pour intégrer la règle de distance en ce sens.
A voir ensuite, selon le temps et la volonté de chacun, de rester dans ce mode pour la migration de la Ğ1 sur Duniter V2S ou d’ajouter l’Oracle.
Les différents éléments de la version avec oracle sont quasiment tous là, et c’est même plus simple que prévu (pas besoin de RPC). Avant de poursuivre j’aimerais arriver à l’intégrer dans les tests cucumber.
Mais puisque ta version sera prête avant et suffira un moment, je peux aussi prioriser autre chose. (je pense par exemple aux màj de substrate, sur lesquelles il serait bon de ne pas trop prendre de retard)
J’ai regardé ta branche distance, effectivement il y a déjà pas mal d’éléments. Personnellement je préfère te laisser faire cette partie si tu as envie de la réaliser, sinon je m’y investirai mais plus tard (plutôt après la migration pour l’instant).
1 Like
Les éléments essentiels sont prêts. Voici un résumé chronologique du fonctionnement :
- L’identité est créée, confirmée, certifiée. Elle ne peut pas encore être validée.
- Quelqu’un demande par un extrinsic l’évaluation de sa règle de distance. L’identité est alors ajoutée dans un des 3 pools d’évaluation, qui tournent à chaque session.
- À la session suivante, les oracles récupèrent le pool par RPC, calculent et enregistrent le résultat (pour toutes les identités dans le pool) dans un fichier.
- À la session suivante, Duniter récupère ce fichier en local s’il existe, et le publie en inhérent quand il écrit un bloc. À chaque publication on calcule la médiane des résultats publiés dans la session et on met à jour le storage.
- Au début de la session suivante, on ajoute chaque identité ayant un résultat positif (règle de distance respectée) dans une table du storage.
- Lors de la validation ou du renouvellement d’une identité, on vérifie que l’identité est bien dans la table des résultats positifs.
L’oracle est un exécutable indépendant, qui peut être lancé par cron par exemple à chaque demi-heure.
Le fonctionnement par fichier plutôt que par sémaphore ou thread permet une plus grande flexibilité et une plus grande résilience aux pannes (le nœud ou l’oracle peuvent planter et redémarrer sans perte de données).
TODO :
- Faire marcher les tests end2end. En mode manual seal, les inhérents sont bien fournis par les providers mais les extrinsics correspondants ne sont pas créés.
- Benchmark. Peut-être qu’il serait intéressant d’étaler sur plusieurs blocs l’application des résultats et la mise à jour des médianes, même si ces algos sont au pire en temps linéaire en le nombre d’identités à tester.
- Antispam. Le poids blockchain étant assez faible, il faut empêcher le spam autrement. Demande d’évaluation autorisée uniquement aux identités confirmées et certifiées mais non validées, ou validées mais expirant bientôt, par exemple.
- Offences. Un évaluateur qui envoie plusieurs fois son résultat devrait être puni.
- Supprimer les anciens fichiers d’évaluation.
Questions :
- Qui peut demander l’évaluation de la règle de distance ? (tout le monde, un membre, l’identité concernée)
- Quand oublie-t-on le résultat positif d’une évaluation ? (délai fixe après publication, lors de la validation)
- Si aucun oracle n’a parlé, est-ce que l’identité est par défaut validée ou invalidée ?
- Une évaluation négative annule-t-elle une évaluation positive passée ?
2 Likes
Que se passe-t-il pour les identités qui ne satisfont pas à la règle de distance ?
Rien, elles se verront refuser validate_identity et renew_membership.
Une évaluation négative n’annule pas une évaluation positive précédente. Mais on peut encore décider que si.
1 Like
Pourquoi ne pas justement mettre un poids élevé, de l’ordre de celui qui serait s’il n’y avait pas d’oracle ?
Implicitement ma question portait sur les certifications associées. Restent-elles valides ? Que peux faire le candidat membre pour améliorer les choses ?
La distance n’est vérifiée que dans la validation et le renouvellement des identités, mais n’a aucun impact sur les certifications. Les identités et certifications préexistantes seront indemnes. Il faudra juste penser à demander l’évaluation de la distance avant de renouveler l’identité.
3 Likes
Proposition d’antispam pour la demande d’évaluation de la règle de distance :
pour chaque demande d’évaluation, on dispose de :
- idty_index de l’identité demandeuse soumise à évaluation (minimum 5 certif reçues)
- statut parmi (
inexistant, 
en attente, 
positive, 
négative)
pour pouvoir soumettre une demande d’évaluation il faut que le statut soit inexistant (absence de demande existante) ou “ négative”.
une évaluation positive est valide pendant un délai défini (1 mois par exemple), après cela, l’expiration programmée la supprime
Voici les transitions possibles :
- [ absence de demande] — demande —> [ statut “en attente”]
- — évaluation —> [ statut “négative”]
- — demande —> [ statut “en attente”]
- — demande —> [
- — évaluation —> [ statut “positive” (expiration programmée)]
- — validation / renouvellement —> [ absence de demande]
- — expiration —> [ absence de demande]
- — validation / renouvellement —> [
- — évaluation —> [
Donc au maximum, une identité peut cycler un renouvellement d’identité toutes les deux sessions, ce qui me semble largement acceptable.
Ça répond donc aux
- Qui peut demander l’évaluation de la règle de distance ? (tout le monde, un membre, l’identité concernée)
→ seulement l’identité concernée - Quand oublie-t-on le résultat positif d’une évaluation ? (délai fixe après publication, lors de la validation)
→ lors de la validation si elle a lieu avant le délai fixe - Si aucun oracle n’a parlé, est-ce que l’identité est par défaut validée ou invalidée ?
→ le statut reste “en attente”, donc pas de validation possible - Une évaluation négative annule-t-elle une évaluation positive passée ?
→ il ne peut pas y avoir d’évaluation négative suite à une évaluation positive
Et il me semble que ça répond aussi à l’antispam.
1 Like
Ok donc je représenterais ces états d’identités par une map DistanceStatus :
- inexistant ou négatif → absence (car il est inutile de conserver un résultat négatif)
- en évaluation → variante Pending
- positif → variante Valid
Il suffit alors de vérifier l’absence de l’identité dans la map.
Une autre map sera nécessaire pour indexer les blocs (ou plutôt les sessions) d’expiration.
C’est la solution évidente, puisque la médiane des résultats n’existe pas (cependant ce n’est pas l’oracle qui déclenche l’application des résultats, et décider d’un résultat positif serait possible sans coût supplémentaire), mais ça ne répond pas à la question sur la résilience. Est-ce qu’on veut qu’une pénurie d’oracles empêche la TdC de fonctionner, ou au contraire qu’elle permette de contourner la règle de distance.
Finalement avec l’hypothèse que les pénuries d’oracles seront rares et courtes, je pense qu’il est préférable de faire patienter quelques membres et futurs membres honnêtes plutôt que de laisser des opportunités même très courtes à des attaquants.
3 Likes
Je réitère : pourquoi ne pas mettre un poids élevé à l’extrinsic de demande d’évaluation ? Du moins des frais élevés à proportion de ce que l’extrinsic représenterait en terme de poids si celui-ci était sans oracle.
Si j’ai bien lu, rien n’empêche un membre de spammer sa demande.
Et les lui rembourser si sa demande s’évalue positivement par la suite.
1 Like
On peut bloquer (en reserved ou frozen, je ne sais plus lequel) un montant sur le compte. En cas d’évaluation positive ou d’absence d’oracle on le débloque ; négative on le transfère à la trésorerie.
D’accord mais il faut aussi que ce montant soit directement décompté si l’extrinsic échoue lui-même (ex. si demande d’évaluation alors qu’il en a déjà une en attente).
Et mettre ce montant en proportion du coût CPU car l’oracle a tout de même un impact sur la machine au cas où l’extrinsic passe.
Ce montant serait indépendant et complémentaire des poids, donc l’extrinsic coûterait toujours son poids, et le blocage de montant ne serait utile qu’en cas de calcul effectif.
Pour la proportion au coût CPU ça va être compliqué, puisque ça dépend de la TdC. On peut benchmarker l’oracle, et on fait un ajustement après l’évaluation en fonction du coût réel, mais comme ce n’est pas aussi critique que le remplissage des blocs (cette ressource étant plus flexible) je pense qu’on peut se contenter d’un coût antispam fixe.