Hello, je viens de publier 2 nœuds : 1 rpc et 1 validateur, visibles en Télémetrie et en cours de synchro. Néanmoins je suis un peu dubitatif sur leur rôle respectif.
En termes de conf, la grosse différence c’est que mon nœud validateur possède, outre une node.key différente, des options de lancement en plus :
--rpc-methods=Unsafe
--validator
L’option --validator coule de source.
Mais pour --rpc-methods=Unsafe, là j’ai du mal.
Ne serait-ce pas plutôt au nœud mirroir (le RPC) justement d’exposer l’API RPC (et ne PAS le faire pour le validateur), et de surcroît concernant les méthodes Unsafe ?
Je n’ai pas encore eu le temps de creuser ces notions, peut-être que tout ceci s’explique.
C’est bien normal : les méthodes “unsafe” sont celles à ne pas exposer publiquement (par exemple tu t’y connectes avec un pont ssh ou un vpn). Ce sont les méthodes RPC qui permettent de générer des session keys par exemple, donc uniquement pour un forgeron. De plus, le nœud forgeron doit idéalement être sur une machine qui lui garantit d’avoir toujours les ressources nécessaire pour au moins égaliser la machine de référence.
Pour le nœud RPC, c’est le seul qui doit exposer publiquement une API RPC (donc sans les méthodes unsafe qu’il ne faut pas exposer publiquement), et tu peux en plus le configurer pour être un nœud archive, c’est-à-dire stocker tous les états depuis le début (et pas uniquement les blocs = transitions d’état). Les deux communiquent via la lib p2p, et c’est la seule interface avec le monde extérieur pour un nœud validateur.
D’ailleurs, cette consigne vaut pour le nœud miroir, mais pour le nœud validateur, il faut n’écouter que sur localhost, sauf pour le port p2p. (d’après ce que j’ai compris)
C’est ce point qui n’est pas clair, d’ailleurs @Pinia tiqué aussi (et précisément tu cites ce message juste ensuite).
Je viens de retirer l’exposition RPC, mais comment exposer le port 30333 ? (ou 30334 dans le post initial)
Je ne constate aucun transfert de port via UPnP pour de l’IPv4 derrière ma box, donc je ne vois pas bien comment mon nœud validateur peut être contacté publiquement.
Alors certes il tourne, il va certainement contacter les nœuds validateurs accessibles publiquement. Mais le mien, à mon avis, est inaccessible.
Ça, je ne sais pas comment fonctionne libp2p, je crois que c’est @Pini qui a le plus creusé la question en bossant sur l’entrypoint docker (cf DUNITER_PUBLIC_ADDR and DUNITER_LISTEN_ADDR in Duniter | Configure your node (Docker)).
Mais peut-être que si tu es en mesure d’initier la connexion sans être capable de recevoir une connexion entrante ça suffit (et ce serait logique finalement, question sécurité et surface d’attaque). Si c’est bien ça, le nœud validateur ne doit rien exposer du tout, mais juste avoir des bootnodes vers des noeuds RPC pour la découverte du réseau. Il faut se renseigner.
Justement, c’est ça que je ne comprends pas dans ce que tu dis : pourquoi empêcher le noeud validateur d’écouter directement sur TCP ? Quel intérêt à wrapper ça dans un ws ? Dans mon idée, on devrait écouter en natif TCP sur un port au choix (et bien préciser DUNITER_PUBLIC_ADDR). Mais je n’ai pas fouillé, je n’ai pas lu d’indications de bonnes pratiques et de sécurité.
Ça c’est un choix perso : j’ai une 15aine de services qui tournent sur ce serveur et je ne veux pas me prendre la tête a gérer un port pour chacun. Donc reverse proxy. Mais techniquement rien n’empêche de mapper le port P2P en direct sur l’hôte. La conf du endpoint (DUNITER_PUBLIC_ADDR) reste toutefois nécessaire la plupart du temps. Par ex si le port P2P est mappé sur le port 30334 de l’hôte :
Ok, merci pour cette info que c’est un choix perso. Je vais avoir un autre choix perso ><
J’ai un peu cherché, voici le guide de bonnes pratiques pour Polkadot :
J’ai l’impression que mon nœud est bloqué dans sa synchro, ça fait 2j que mes essais mènent à ce blocage plus ou moins rapidement (ici je suis au bloc 1,194,752).
Cela vous est-il déjà arrivé ? Que faites-vous pour contourner ?
Édit : bon j’ai redémarré ça semble être débloqué.
Je n’ai eu de que très rares blocages. En fait un seul il me semble. Et c’est arrivé quand j’ai poussé mon serveur un peu trop loin en charge avec d’autres tests de services en parallèle. Sinon ça tourne tout seul avec uptime de plusieurs semaines sans souci.
@davidbp845 you might be interested in having a Duniter v2 node on the ĞDev5 network. The documentation is available here: Duniter | [alpha] Duniter v2. Tell me what you think about it!
Thanks a lot Hugo. I’ll read it and hope I can do it.
I’m experiencing trouble with my v1 node now, and first I would like to see if I can fix this. Then I will try to have a v2 one!
We only have three smith on the ĞDev network (@daigongen, @tuxmain, @Pini) and the blockchain is experiencing latencies because @poka is offline. @vit and @HugoTrentesaux should become smith again, and we should train other smith.
