Afin de réaliser une synchronisation initiale via WS2P sans avoir à reposer sur WS2Pv2 qui demande un investissement en temps important (me concernant en tout cas), je pense étendre légèrement le protocole WS2Pv1 pour ce besoin précis.
La solution est simple : ajouter la possibilité d’utiliser le mot SYNC à la place du mot CONNECT, afin de signifier que la connexion est réalisée exclusivement dans le but de synchroniser.
Ainsi, le nœud qui recevrait ce type de connexion n’établirait pas la connexion réciproque, et se contenterait de répondre OK puis d’attendre des requêtes de récupération de blocs. Le nœud n’accepterait aucun autre type de requête pour cette connexion sous peine de clore celle-ci sans délai et d’ajouter un flag de bannissement temporaire sur la clé + l’IP du nœud contrevenant.
Grâce à ce mécanisme, on peut gérer un pool de connexion spécifique à la synchro et donc contourner les quotas WS2P traditionnels.
À noter que l’utilisation du mot clé CONNECT est toujours possible et permet elle aussi de se synchroniser dès aujourd’hui en WS2P (sauf que Duniter n’utilise pas ce mécanisme pour l’instant), mais dans ce cas on est soumis à des quotas stricts qui refoulent facilement les nœuds non-membres.
En fait ce n’est pas bon, car pour rappel le nœud contacté ne peut vérifier l’initiateur d’une connexion qu’en l’authentifiant à son tour en générant un challenge.
Donc il faut établir les 2 liens au niveau applicatif, même si le lien serveur -> initiateur n’est pas utilisé dans les faits.
Je me demande : faut-il vraiment que WS2P permette la synchronisation totale de la blockchain ? Étant une API inter-nœud, cela impliquerait que tout nœud devrait avoir stocké l’intégralité de la blockchain, et permettre de la restituer. Or justement, nous nous orientons vers la possibilité d’avoir des nœuds légers, s’en tenant à avoir suffisamment d’informations sur la fenêtre courante, mais pas plus.
En fait je trouverais beaucoup plus simple que Duniter supporte la synchronisation à partir d’autres solutions que WS2P, par exemple à partir de fichiers téléchargés par ailleurs. Il serait aussi possible d’offrir d’autres méthodes, mais WS2P me semble être le dernier des endroits appropriés.
Et je dis ça alors que j’arrive enfin à un début de fonctionnement sur Duniter. Mais je préfère retirer un truc bancal que persister dans une erreur.
De mon coté je pense qu’on est encore bien loin de ça, d’abord il faut binariser entièrement le protocole et faire pas mal d’autres changements majeurs, la possibilité d’avoir des light nodes n’est pas pour demain, même si c’est le cap qu’on s’est fixé a long terme
Quand a l’api inter-noeud, elle doit de toute façon permettre aux nœuds de se demander des blocs entre eux, notamment pour s’assurer d’avoir bien connaissance de tout les fork en cours et être en capacité de choisir la bonne branche. Donc ça me semble a contraire l’endroit naturel et adapté pour.
En tout cas c’est la logique que je vais développer dans Duniter-Rust conformément a la RFC WS2Pv2, mais rien ne t’empeche dans l’implémentation Duniter-Ts de partir sur un mécanisme de synchronisation a part.
La synchronisation ne fait pas vraiment parti du protocole et donc in finé la manière dont un noeud récupère la blockchain peut sans problème être différente
Je pense qu’il est donc important d’en tenir compte dès aujourd’hui, afin de s’éviter les développements coûteux qui seront à supprimer demain. Enfin après chacun estimera ce qui est coûteux ou pas, et implémentera en fonction.
Bof !
Oui, mais ça reste cadré dans une fenêtre assez courte. La synchro demande d’aller jusqu’au bloc zéro.
C’est marrant car pour moi c’est moins coûteux d’implémenter la sync a WS2P qui permet déjà de partager des chunk que de créer un nouveau process de zéro
Mais soit, choisi ce qui te semble le moins coûteux pour Duniter-Ts, ce n’est pas génant si les deux implémentations ont des mécanismes de synchronisation différent, l’important c’est qu’elles appliquent le même protocole et surtout résolvent les fork de la même façon pour rester “d’accord” sur la vision de la monnaie.
Et bien quand tu auras 4 années d’un code logiciel derrière toi dont les principes ont été mouvants les 3 premières, peut-être verra-tu cela autrement. Et puis c’est vrai que tu arrives plus âgé que moi à mes débuts et beaucoup de choses ont été bien défrichées, tu es certainement mieux armé et surtout pas encore usé.
J’aimerais bien que l’on appelle ce logiciel Duniter, et que tu renommes le logiciel Rust différemment. J’ai trouvé ce nom et j’aimerais qu’il ne me soit pas confisqué, en quelque sorte.
Je me place du côté utilisateur et mainteneur de noeud, pas du côté développeur.
Si la synchro se fait par WS2P publique, on a bien plus de chance de trouver un nœud pour se synchroniser qu’avec BMA. Je suis donc en faveur d’une synchro avec WS2P.
Pourquoi ? La communication disant que BMA était obsolète (du point de vue de la maintenance du code) et allait disparaître et qu’il n’était pas nécessaire de l’activer fût un gros souci pour les clients qui voyaient le nombre de nœuds disponibles ne pas augmenter, voir baisser. Mais ça c’est du passé.
Actuellement, si je veux me synchroniser,
Je dois trouver un nœud avec l’api BMA activée.
Je dois trouver un fichier à importer (jamais utilisé, car comment trouver un tel fichier sans contacter le propriétaire d’un nœud pour qu’il publie ou m’envoie ce fichier).
Je dois attendre un futur troisième type de endpoint à activer (pas fan du tout, deux api pour fonctionner c’est bien).
Conclusion, avec une vision utilisateur à court terme :
Activez vos endpoints BMA qui n’est pas encore obsolète, vous décentraliserez les accès clients et augmenterez les chances de pouvoir vous re-synchroniser.
Patience, lorsque la synchro arrivera sur WS2P, vous pourrez vous re-synchroniser sur plus de nœuds, sans efforts ou endpoint à activer.
Dès le début de uCoin je précisais “Free Software + Open protocol”. Il s’agissait d’un logiciel avant tout. D’ailleurs quand on télécharge le logiciel, le nom du binaire est bien “duniter” et ce nom se retrouve aussi dans la fenêtre du logiciel.
Ce n’est pas gênant de prendre un autre nom pour une autre implémentation, Bitcoin ou Linux en possèdent plein.
L’utilisateur n’a pas conscience ni n’a envie d’avoir conscience des problématiques liées à la gestion du cœur du réseau.
La sécurité va commencer à prendre le pas sur la simplicité, c’est normal. Le tout c’est que malgré les restrictions sur le protocole de communication inter-nœud, on développe des alternatives en parallèle pour conserver le niveau de confort précédent. Voire mieux.
Comme le disait Eloïs dans un autre sujet, le protocole réseau ne fait pas vraiment partie du cœur du protocole. Je l’y ai mis mais il devrait en être retiré, la couche de communication est indépendante du protocole blockchain (même si elle peut reposer sur lui, mais le protocole en est agnostique tout comme la Ğ1 est agnostique de l’économie qui se développe sur elle).
Bien entendu, la sécurité prime ! Si tu estimes que faire la synchro via WS2P est difficile à gérer en tant que développeur et comporte des risques de sécurité, alors fais autrement. Je pointais juste le côté confort utilisateur, mais pas que.
Une fois un système en place, on observe la réaction des utilisateurs et on découvre que si les manipulations sont pénibles il y aura des abandons, des contournements, etc. C’est normal. Surtout en p2p ou une décision sur le logiciel entraîne une modification des comportements qui se répand sur tout le réseau…
Bref, tu as nos avis, à toi de décider… (roulement de tambour !)
Et par défaut l’activer sur Duniter 1.7.x. Puis dans de futures version la désactiver par défaut ainsi que proposer aux utilisateurs la désactivation de cette fonction, une fois de nouvelles solutions en place.
