> ## Documentation Index > Fetch the complete documentation index at: https://docs.plasma.org/llms.txt > Use this file to discover all available pages before exploring further. # Vue d'ensemble > Comprendre l'architecture modulaire des nœuds Plasma et les rôles des opérateurs ## 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](https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/). 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 : 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. 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. 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](https://github.com/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](https://ethereum.org/en/developers/docs/networking-layer/#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](https://github.com/PlasmaLaboratories/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](https://docs.libp2p.io/concepts/fundamentals/peers/) : ```toml theme={null} [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 : ```toml non-validator.toml theme={null} [network] external_address = "node.example.com:34070" ``` ```bash CLI theme={null} --p2p.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](./non-validator-node-setup#port-configuration). ## Démarrage rapide Comprendre les rôles de validateur, non validateur et fournisseur RPC Déployez votre nœud avec Docker Compose Spécifications minimales et recommandées pour votre nœud Commencez avec une exploitation de nœud sans permission