Bonjour à tous,
Je ne sais pas si cette question est à propos, mais je suis à la fois avec beaucoup d’intérêt et de façon très néophyte le sujet de la migration de la blockchain sur substrate, en particulier la partie protocole.
Je suis actif dans la monnaie libre à mon niveau plus sysadmin et netadmin et j’observe que depuis que des Gmarchés ont lieu, les personnes qui se rendent sur place ont une habitude d’utiliser le réseau wifi du lieu, ce qui génère comme nous l’avions observé avec Elois une mise en « sécurité » du nœud duniter suite à un nombre important d’authentifications depuis une seule et même ip (ce qui a priori est plutôt une bonne chose). Celà dit ça génère une confusion chez les usagers ou ils finissent par attribuer des problèmes de fiabilité à duniter (sans diagnostic bien sur).
J’avais pu tester l’ajout dans le fichier de conf (conf.json) de duniter de la directive : « whitelist » qui permettait à mon nœud duniter lors d’un Gmarché sur un site de désactiver temporairement ce mécanisme anti-ddos.
Bien sur cette manip ne concerne que les personnes utilisant mon nœud et pas les autres.
Je profite donc des discussions autour de la refonte du protocole pour proposer qu’un protocole de publication d’ip « de confiance » puisse être intégré afin de permettre par exemple à des comptes membres ou des forgerons (à définir) de déclarer une adresse ip pour une durée donnée.
Je ne trouve pas d’info sur de potentiels mécanismes de blacklistage intégrés à substrate.
Je suppose que cela doit se jouer au niveau de l’API RPC.
Quoi qu’il en soit ce n’est pas normal de se faire ban pour si peu, même considérant plusieurs dizaines de personnes sur la même IP ayant un usage normal.
Déjà en théorie si le réseau étaient vraiment p2p, les utilisateurs ne devraient pas tous être sur le même noeud, mais sur des noeuds random, correctement synchro.
Donc un seul et même noeud ne se ferais pas flooder comme ça.
Oui c’est exactement ça…
Celà dit meme si tu as 200 personnes à un Gmarché qui ont chacun un des 10 noeuds duniter habituellement utilisable( situation idéale) tu verras potentiele 20 utilisateurs différents par noeud depuis la meme ip.
J’ai identifié que le mécanisme se déclenche entre 3 et 5 connexions depuis la meme ip.
En fait c’est plutôt le rôle des nœuds miroir que d’offrir une API qui accepte davantage de charge. Le nœud duniter.org est l’exemple le plus connu, mais bon il n’est pas tellement taillé pour.
Il manque ce genre de nœuds miroirs, et d’un pool que les clients puissent utiliser comme source d’info et soumission des transactions.
La ça rentre dans le domaine que je connais pas, tu veux dire qu’on peut utiliser un noeud mirroir pour l’authent « et » pour envoyer les transactions?
Si c’est le cas on pourrait imaginer une résolution dns random vers plusieurs noeud à la « pool.ntp.org ».
Oui une application cliente peux tout faire à partir d’un miroir.
Pour le pool DNS, oui ça devrait fonctionner. Le client restera sur une IP pendant toute sa session DNS, par contre il faut s’assurer que les nœuds miroirs sont bien synchronisés pour éviter à un client de tomber sur un nœud à la ramasse.
Mais dans l’idée, avoir un nom frontal qui ensuite dispatche les requêtes pour faire du load-balancing, cela fonctionnera (à la synchronisation près des nœuds). Il me semble que c’est une pratique très répandue dans le monde des applications web centralisées.
Oui ya pas mal d’application web qui fonctionnent comme ça avec un dns qui répond une ip différente soit en roundrobin soit en fonction de la geoloc soit les deux (j’en ai monté pour des clients).
Celà dit ça ne fonctionne que si on est capable de déployer sur chaque noeud participant un certificat avec le bon nom (pas forcément compliqué à réaliser avec nginx en reverse proxy devant), je sais pas si c’est plus simple et garant de résultat que l’idée de publier une whitelist celà dit.