Bonjour,
Je vais commencer à rédiger la doc pour installer un noeud forgeron. Pour cela, j’ai plusieurs questions.
1 - le contenu de la license forgeron a-t-il déjà été rédigé ? Un brouillon ? Des grandes idées dans un sujet sur ce forum ? Si oui, pouvez-vous me pointer où ? Me répondre avec les grandes idées ?
2- Si non, est-il pertinent de créer un dépôt de license forgeron avec les grandes idées, permettant de travailler le brouillon ?
3 - J’ai cru comprendre qu’il serait demandé de monter un noeud miroir et de le maintenir quelque temps (mettons 3 semaines). Hors, monter un noeud miroir implique de mettre en place un reverse-proxy qui n’est pas nécessaire dans le cas d’un noeud forgeron, vu qu’il n’a plus ‘que’ les connexions p2p.
- ai-je mal compris, et un reverse proxy est-il également nécessaire dans le cas d’un noeud forgeron ?
- si j’ai bien compris, cette demande (configurer un reverse-proxy pour le démonter après) me semble superflue. Dans ce cas est-il possible de vérifier que quelqu’un fait bien tourner un noeud s’il n’expose pas les API RPC ? Cela impliquerait de lui demander d’activer la télémétrie, ce que la personne ne veut peut-être pas. Je ne trouve pas, dans PolkadotJS, l’information ‘à qui appartient le pair’ sur la liste des pairs
- NB - le fait d’avoir configuré un reverse-proxy pour le noeud miroir peut être considéré comme un marqueur des compétences nécessaires pour sécuriser un noeud forgeron. Sur le plan pédagogique, je suis opposé aux tests sur des éléments non utilisés dans la pratique, mais ici ça peut se comprendre, c’est très proche.
5 Likes
Il y a quelque chose là :
Non, mon nœud forgeron n’utilise pas de reverse proxy.
Peut-être avec la télémétrie publique (au moins temporairement), et en regardant dans les listes de pairs des autres nœuds.
Je ne pense pas que le capacité à maintenir un nœud en ligne dans la durée soit si importante pour devenir forgeron : si la config était mauvaise et que le serveur explose, le forgeron sera retiré automatiquement en quelques heures.
En revanche on pourrait faire des tests d’intrusion sur le serveur pour vérifier qu’il correspond à des exigences minimales de sécurité.
2 Likes
Oui, un brouillon déjà très avancé qu’on pourrait publier ! @1000i100 as-tu rendu public ce qu’on a regardé ensemble avant l’été ? Ça me paraît très bien et on pourrait dès maintenant le mettre en avant à mon avis.
Effectivement, ce serait paradoxal de demander une compétence non utile pour la tâche (savoir mettre en place https). Les nœuds miroir sont faits pour les clients et doivent supporter une certaine charge. Les nœuds forgerons au contraire doivent être protégés au maximum pour éviter toute surcharge. Ils doivent répondre aux ressources minimales, mais rien ne sert de leur allouer plus de ressources.
Pour ce qui est du uptime désirable, je ne sais pas. Mais je privilégierais plutôt la quantité de forgerons (décentralisation du pouvoir), en comptant sur la solidité du consensus (à tester avec plus de nœuds).
J’étais justement en train de me poser cette question pour mettre à jour la liste des bootnodes. On devrait pouvoir récupérer les fiches de pair mais je vais peut-être finir par tout simplement demander leurs IP ou DNS aux gens !
Pour ce qui est d’évaluer la capacité des forgerons à avoir un nœud qui reste synchro pendant un moment, on pourrait faire des mesures d’uptime, mais je ne vois pas trop comment faire. Peut-être avec les heartbeat p2p ? Ça mérite d’investiguer.
1 Like
Elle se trouve là :
Et je viens de faire une merge-request 
5 Likes
Au besoin je peux corriger l’orthographe 
Merci pour ce travail 
2 Likes