Les nœuds qui font du bootstrapping dans Massa font déjà partie du réseau et sont donc capables de suivre l’état en observant les blocs qui passent dans le réseau, en les vérifiant et en appliquant les changements d’état qu’ils provoquent.
Table des matières
- Introduction
- Modèle de sécurité
- Détails de la mise en œuvre
Procédure du point de vue du nœud en cours d’amorçage
Procédure du point de vue du nœud bootstrapping in Massa - Optimisations futures
Introduction
Dans certaines blockchains comme le bitcoin, il est recommandé aux nœuds complets qui rejoignent le réseau de télécharger tous les blocs depuis le début (genèse) de la blockchain afin de revérifier tout l’historique des changements d’état. Dans certaines blockchains comme le bitcoin, il est recommandé aux nœuds qui rejoignent le réseau de télécharger tous les blocs depuis le début (genèse) de la blockchain afin de revérifier l’historique complet des changements d’état.Cependant, Massa a un triple objectif de décentralisation/sécurité/performance :
la décentralisation maximale exige que les exigences matérielles des nœuds restent cohérentes avec celles d’un ordinateur de bureau grand public typique afin de réduire la barrière d’entrée pour devenir un coureur de nœuds
la sécurité maximale exige que tous les nœuds vérifient tous les blocs et toutes les opérations
la performance maximale exige d’utiliser le matériel du nœud à son maximum (CPU, réseau, mémoire, stockage).
Cela signifie que l’État dans Massa évolue presque aussi vite que les ordinateurs de bureau grand public typiques peuvent exécuter des blocs, ce qui implique que le rattrapage des blocs depuis la genèse ne va que légèrement plus vite que les nouveaux blocs apparaissent entre-temps, et prendrait un temps très long. De plus, Massa vise à traiter des milliers d’opérations par seconde, ce qui signifie qu’il produit beaucoup de données de blocs chaque seconde, empêchant ainsi les nœuds dotés du matériel cible de stocker l’historique complet des blocs et rendant impossible le démarrage à partir de la genèse puisque les anciens blocs sont oubliés.
Les nœuds Massa qui rejoignent le réseau doivent donc s’amorcer en téléchargeant l’état actuel absolu.
Notez que les nœuds peuvent se remettre de déconnexions de courte durée en demandant les données manquantes aux nœuds qui les entourent une fois qu’ils reviennent dans le réseau. Cependant, comme les nœuds Massa ne stockent qu’un court historique de blocs et oublient les plus anciens, il est impossible de se remettre d’une longue déconnexion puisque les nœuds environnants ont oublié les blocs dont le nœud qui se remet en route a besoin. Dans ce cas, un nouveau bootstrap d’état est nécessaire.
Modèle de sécurité
L’exemple du bootstrapping Bitcoin
Pour comprendre le modèle de sécurité de l’amorçage de nœuds, Bitcoin est un bon exemple de départ.
Lorsque les créateurs de nœuds Bitcoin décident de rejoindre le réseau, ils téléchargent d’abord le logiciel du nœud à partir d’une source centrale (par exemple, bitcoin.org). Si cette source est compromise, le nœud peut se retrouver sur un autre réseau, et/ou un vol de clé privée peut se produire. Bitcoin exige donc de faire confiance à l’entité qui fournit le logiciel du nœud.
Notez qu’en option, si les nœuds ne souhaitent pas télécharger l’historique complet des blocs, ils font confiance à un état de “point de contrôle” plus récent encodé dans le logiciel du nœud. Si cet état est compromis, la connaissance que le nœud a de l’ensemble du grand livre peut être faussée.
En supposant que le logiciel du nœud n’est pas corrompu, les nouveaux nœuds qui rejoignent le réseau ont besoin d’une liste initiale de nœuds pairs auxquels ils doivent d’abord se connecter afin de découvrir le réseau. Cette liste est codée en dur dans le logiciel du nœud (voir la documentation sur le bitcoin). Si tous les pairs indiqués par cette liste initiale sont compromis, le nœud peut se retrouver sur un réseau différent (non bitcoin), même si le logiciel du nœud lui-même n’est pas compromis. Bitcoin requiert donc également la confiance dans au moins un des pairs initiaux.
Notez que le fait de se retrouver sur le mauvais réseau peut être détecté en vérifiant les hachages de blocs avec une source externe. Mais cela nécessite de faire confiance à une autre source de données.
Le cas de Bootstrapping dans Massa
Le cas de Massa est très similaire à celui de Bitcoin. Les utilisateurs de nœuds doivent également faire confiance à la source du logiciel de nœud qu’ils téléchargent, ainsi qu’à la liste initiale de pairs.
De la même manière que pour les points de contrôle de Bitcoin, les nœuds Massa qui démarrent doivent obtenir l’état actuel à partir d’une source fiable, idéalement la même source que celle à partir de laquelle ils ont téléchargé le logiciel du nœud, afin d’éviter de devoir faire confiance à plusieurs entités.
Le téléchargement de l’état à partir d’une source non fiable peut entraîner des problèmes majeurs tels que le vol de pièces. En tant que tel, l’amorçage à partir de sources non fiables devrait être découragé, et l’amorçage d’autres nœuds devrait être opt-in pour les coureurs de nœuds afin d’éviter la circulation de “listes d’amorçage” comme le moyen par défaut d’amorçage des coureurs de nœuds non conscients.
Détails de la mise en œuvre
Procédure du point de vue du noeud en cours d’amorçage
Les nœuds Massa qui s’amorcent commencent par se connecter à un nœud choisi au hasard parmi ceux listés dans massa node/base_config/config.toml
(section Bootstrap/bootstrap_list).
Le processus de bootstrap utilise un port et un protocole distincts de la communication normale entre pairs de Massa.
Toutes les communications avec le noeud d’amorçage choisi sont authentifiées en utilisant la clé publique (node ID) du noeud d’amorçage (dans le fichier config.toml, section Bootstrap/bootstrap_list) afin d’éviter les attaques de type “man-in-the-middle”.
Le nœud en cours d’amorçage tente ensuite de télécharger l’état actuel, ainsi qu’une liste initiale de pairs à partir du nœud d’amorçage.
Une fois amorcé avec succès, le nœud peut alors se connecter aux pairs, découvrir le reste du réseau et traiter les blocs entrants en direct pour maintenir son état à jour.
Dans Massa, le hachage de l’état est utilisé comme partie de la graine de preuve d’enjeu, qui est un mécanisme de sécurité contre les nœuds d’amorçage malveillants envoyant un état compromis. Il garantit que les nœuds avec un état altéré finissent par être isolés du réseau réel parce que leurs tirages de preuve d’enjeu diffèrent, ce qui les amène à rejeter les blocs honnêtes entrants. Notez cependant que la détection d’une discordance de semences PoS peut prendre jusqu’à 2 cycles.
En cas d’échec du bootstrap, le nœud de bootstrapping réessaie avec un autre nœud de bootstrap choisi aléatoirement après un délai.
Procédure du point de vue de l’amorçage dans un nœud Massa
Les nœuds Massa peuvent amorcer d’autres nœuds, avec certaines limitations car la procédure est lourde pour le nœud d’amorçage.
Le système de bootstrap écoute sur l’adresse/port défini dans massa-node/base_config/config.toml
(section bootstrap/bind). Le serveur bootstrap du noeud peut être désactivé en supprimant l’entrée bind du fichier de configuration.
L’état de Massa est volumineux (~1 terabyte dans le pire des cas), et le téléchargement vers les noeuds d’amorçage prend du temps. Pendant ce temps, de nouvelles modifications de l’état continuent à apparaître, de sorte que les nouveaux changements affectant les parties déjà téléchargées doivent être envoyés à la volée.
Par défaut, les nœuds Massa n’autorisent qu’une liste blanche d’adresses IP à s’amorcer à partir d’eux. Cette liste est présente dans le fichier massa-node/base_config/bootstrap_whitelist.json. Cette liste est destinée à empêcher les attaques par inondation par des attaquants prétendant faire du bootstrap, et rend également plus difficile pour les runners de nœuds de faire du bootstrap à partir de sources non fiables. Si vous souhaitez désactiver la liste blanche et permettre à quiconque de s’amorcer à partir de votre nœud, il suffit de supprimer le fichier bootstrap_whitelist.json et de redémarrer votre nœud.
Un fichier complémentaire bootstrap_blacklist.json
(absent par défaut) peut également être créé à côté de bootstrap_whitelist.json (et suivant la même syntaxe) afin d’empêcher explicitement certaines adresses IP de s’amorcer à partir du nœud.
Une fois qu’un noeud a accepté d’amorcer un noeud entrant, il ajoute l’adresse IP du noeud entrant à un cache local empêchant cette IP de s’amorcer à nouveau pendant un temps défini dans massa-node/base_config/config.toml
(section bootstrap/per_ip_min_interval) en refusant les connexions ultérieures de cette IP pendant le délai défini par la configuration. Le délai d’exclusion n’est pas prolongé si l’IP distante tente de nouvelles connexions pendant le délai d’exclusion. Le délai d’exclusion est cependant appliqué si le bootstrap a été accepté mais a échoué pour une raison quelconque. Cela vise à limiter la charge sur les nœuds d’amorçage individuels et à répartir la charge entre les nœuds d’amorçage.
Le nombre de nœuds qui s’amorcent simultanément à partir du nœud local est limité (massa-node/base_config/config.toml
section bootstrap/max_simultaneous_bootstraps). Les tentatives excessives sont refusées mais ne déclenchent pas le mécanisme de délai d’exclusion.
Optimisations futures
Nous prévoyons d’ajouter la possibilité de télécharger des données d’amorçage à partir de sources non fiables pour l’équilibrage de charge, mais ensuite de vérifier le hachage de l’état obtenu à partir de sources fiables, et de revenir au téléchargement complet à partir de sources fiables uniquement si plusieurs tentatives d’amorçage à partir de cette approche hybride échouent.
