Plasma Docs - Build on Plasma

En bref

Plasma sépare les nœuds validateurs (qui proposent et finalisent les blocs) des nœuds non validateurs (qui servent les RPC et suivent la chaîne sans affecter le consensus). Cela permet à Plasma de maintenir un ensemble de validateurs petit et sécurisé, de laisser les fournisseurs RPC évoluer indépendamment, et d’éviter d’ajouter du risque sur le consensus ou le réseau.

Architecture de haut niveau

Couche	Rôle	Modèle de confiance
Couche de consensus (CL)	Proposer et finaliser les blocs	PlasmaBFT
Couche d’exécution (EL)	Traiter les transactions, gérer l’état, servir les RPC	Fait entièrement confiance à sa CL associée

Chaque validateur exécute un nœud de consensus et un nœud d’exécution, connectés directement. À l’exception de leurs partenaires, les nœuds ne communiquent pas en dehors de leurs pairs de couche (CL-à-CL, EL-à-EL). Cette séparation garde le système prévisible, sécurisé et facile à raisonner.

Le défi de la mise à l’échelle

À mesure que l’utilisation augmente, davantage d’applications et d’utilisateurs ont besoin d’un accès RPC pour interroger les données de la chaîne ou envoyer des transactions. Mais si chaque nouveau nœud d’exécution doit être apparié à un nouveau nœud de consensus, la mise à l’échelle devient inefficace et risque de gonfler l’ensemble des validateurs. Laisser les fournisseurs RPC exécuter des validateurs supplémentaires juste pour répondre à la demande de lecture n’est pas pratique ni aligné avec les objectifs de performance de Plasma.

La solution : nœuds non validateurs

Les nœuds non validateurs se comportent comme des nœuds de consensus mais ne participent pas au consensus. Au lieu de cela, ils « suivent » un validateur de confiance pour les blocs finalisés et les mises à jour de fork-choice. Comportements clés :

Ils s’abonnent au nœud de consensus d’un validateur pour rester synchronisés.
Ils exposent la même vue fork-choice qu’un vrai validateur le ferait.
Ils ne font que lire, donc ils n’ajoutent pas de charge ni n’introduisent de risque de sécurité.

Pour les applications, un nœud non validateur ressemble exactement à un nœud complet : il peut répondre aux requêtes RPC et refléter l’état actuel, mais il ne peut pas proposer de blocs ni voter.

Avantages de cette conception

Objectif	Comment les nœuds non validateurs aident
Garder l’ensemble des validateurs réduit	Les nœuds non validateurs ne votent pas ; seuls les validateurs le font.
Échelle horizontale illimitée	Les fournisseurs RPC peuvent lancer des centaines de nœuds RPC en lecture/écriture, chacun avec son propre nœud non validateur, sans nouvelles places de validateurs.
Maintenir la justesse du consensus	Chaque nœud d’exécution suit toujours exactement une CL. Pas de risque de divergence d’état.
Réduire les risques	Les nœuds non validateurs sont en lecture seule et ne peuvent pas affecter les messages de consensus.
Simplifier le basculement	En suivant plusieurs validateurs, si l’un tombe hors ligne, ils peuvent basculer vers un autre automatiquement.

Comparaison récapitulative

Fonctionnalité	Validateurs	Nœuds non validateurs
Participation au consensus	Complète (proposition, vote, finalisation)	Aucune (réception uniquement)
Types de messages	Tous les messages de consensus	Messages de blocs uniquement
Rôle réseau	Participant actif	Suiveur passif
Besoins en ressources	Plus élevés (consensus complet)	Plus faibles (messagerie uniquement)

Décentralisation progressive

Plasma suit un modèle de décentralisation progressive. Plutôt que d’ouvrir l’ensemble des validateurs dès le premier jour, l’accent initial est mis sur la stabilité, la performance et l’utilisabilité pour les développeurs. Cette approche privilégie la fiabilité du réseau pendant que les composants principaux du protocole évoluent encore. La décentralisation reste un objectif à long terme, mais elle sera mise en place progressivement. L’ensemble des validateurs s’étendra en trois étapes :

Opération centralisée

Pendant le testnet, tous les nœuds de consensus sont opérés par l’équipe Plasma pour permettre une itération rapide et minimiser le risque opérationnel.

Ensemble de validateurs de confiance

Après le lancement du mainnet, un petit groupe de validateurs externes rejoindra le réseau, sélectionnés pour leur fiabilité, leur préparation opérationnelle et leur distribution géographique.

Participation sans permission

Avec le temps, l’accès aux validateurs s’ouvrira au public, soutenu par des garde-fous au niveau protocole pour la sûreté, la vivacité et l’alignement économique.

Ce déploiement par étapes équilibre la décentralisation avec l’intégrité du réseau. Il permet au protocole de se renforcer avant de confier les responsabilités d’infrastructure critique à un ensemble plus large de validateurs.

Découverte des pairs

Les nœuds Plasma découvrent et se connectent aux pairs via deux mécanismes indépendants — un pour chaque couche de la pile.

Couche d’exécution (Reth)

Le client d’exécution utilise le protocole standard d’Ethereum devp2p pour la découverte des pairs. Au démarrage, votre nœud Reth se connecte à un ensemble de pairs d’exécution de confiance définis dans enodes.txt. Ce sont des URLs enode qui encodent la clé publique, l’adresse IP et le port de chaque pair. Le fichier enodes.txt de chaque réseau est pré-configuré dans le dépôt non-validator-templates. Après s’être connecté à l’ensemble initial, le protocole de découverte intégré de Reth (discv4/discv5) trouve automatiquement les pairs supplémentaires. La couche P2P d’exécution fonctionne sur le port 30303 (TCP/UDP).

Couche de consensus (PlasmaBFT)

Le client observateur du consensus découvre les pairs via des nœuds bootstrap définis dans non-validator.toml. Chaque entrée de nœud bootstrap inclut un hôte API, un port P2P et un peer ID libp2p :

[network.bootstrap_nodes.0]
api_host = "plasma-mainnet-observer-cs-1.plasmalabs.tech"
p2p_port = 34070
peer_id = "16Uiu2HAm4WdZmik6PVsRvcbCzc1eHuNfQHgj52CxUAjmdC7W5dXi"

Chaque réseau est livré avec 3 nœuds bootstrap. Votre client observateur s’y connecte au démarrage et, avec la découverte des pairs activée (discovery.enabled = true), trouve automatiquement les pairs supplémentaires sur le réseau. La couche P2P du consensus fonctionne sur le port 34070 (TCP).

Nœuds derrière NAT

Si votre nœud est derrière une passerelle NAT ou un pare-feu, les autres pairs ne pourront peut-être pas l’atteindre via son adresse interne. Vous pouvez configurer une adresse externe afin que les pairs puissent découvrir et se connecter à votre nœud :

[network]
external_address = "node.example.com:34070"

Si le port est omis, il prend par défaut la valeur de p2p_port. Assurez-vous que l’adresse externe est accessible et que les ports pertinents sont redirigés à travers votre pare-feu.

Récapitulatif

Couche	Protocole	Port	Méthode de découverte
Exécution	devp2p	`30303`	Enodes de confiance + découverte automatique
Consensus	libp2p	`34070`	Nœuds bootstrap depuis `non-validator.toml`

Pour les détails sur les ports et le pare-feu, consultez le guide d’Installation d’un nœud non validateur.

Démarrage rapide

Types de nœuds

Comprendre les rôles de validateur, non validateur et fournisseur RPC

Installation d'un nœud non validateur

Déployez votre nœud avec Docker Compose

Exigences matérielles

Spécifications minimales et recommandées pour votre nœud

Onboarding des opérateurs

Commencez avec une exploitation de nœud sans permission

​En bref

​Architecture de haut niveau

​Le défi de la mise à l’échelle

​La solution : nœuds non validateurs

​Avantages de cette conception

​Comparaison récapitulative

​Décentralisation progressive

​Découverte des pairs

​Couche d’exécution (Reth)

​Couche de consensus (PlasmaBFT)

​Nœuds derrière NAT

​Récapitulatif

​Démarrage rapide