> ## 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. # Überblick > Plasmas modulare Node-Architektur und Betreiberrollen verstehen ## Kurzfassung Plasma trennt **Validator-Nodes** (die Blöcke vorschlagen und finalisieren) von **Non-Validator-Nodes** (die RPCs bedienen und der Chain folgen, ohne den Konsens zu beeinflussen). Dadurch kann Plasma die Validator-Menge klein und sicher halten, RPC-Anbietern unabhängige Skalierung ermöglichen und vermeiden, dass Konsens- oder Networking-Risiken hinzukommen. ## High-Level-Architektur | **Schicht** | **Rolle** | **Vertrauensmodell** | | :---------------------- | :-------------------------------------------------------- | :-------------------------------------- | | Konsensschicht (CL) | Blöcke vorschlagen und finalisieren | PlasmaBFT | | Ausführungsschicht (EL) | Transaktionen verarbeiten, State verwalten, RPCs bedienen | Vertraut vollständig der zugehörigen CL | Jeder Validator betreibt einen Konsens-Node und einen Ausführungs-Node, die direkt miteinander verbunden sind. Mit Ausnahme ihrer Partner kommunizieren Nodes nicht außerhalb ihrer Schicht-Peers (CL-zu-CL, EL-zu-EL). Diese Trennung hält das System vorhersehbar, sicher und leicht nachvollziehbar. ### Die Skalierungsherausforderung Mit zunehmender Nutzung benötigen mehr Apps und Nutzer RPC-Zugriff, um Chain-Daten abzufragen oder Transaktionen zu senden. Aber wenn jeder neue Ausführungs-Node *zwingend* mit einem neuen Konsens-Node gekoppelt werden muss, wird die Skalierung ineffizient und es droht eine Aufblähung der Validator-Menge. RPC-Anbietern zu erlauben, zusätzliche Validatoren nur zur Befriedigung der Lese-Nachfrage zu betreiben, ist weder praktikabel noch im Einklang mit Plasmas Performance-Zielen. ### Die Lösung: Non-Validator-Nodes Non-Validator-Nodes verhalten sich wie Konsens-Nodes, nehmen aber nicht am Konsens teil. Stattdessen „folgen" sie einem vertrauenswürdigen Validator für finalisierte Blöcke und Fork-Choice-Updates. Schlüsselverhalten: * Sie **abonnieren** den Konsens-Node eines Validators, um synchron zu bleiben. * Sie **exponieren** dieselbe Fork-Choice-Sicht, die ein echter Validator hätte. * Sie **lesen nur**, fügen also keine Last hinzu und stellen keine Sicherheitsrisiken dar. Für Anwendungen sieht ein Non-Validator-Node genauso aus wie ein vollwertiger Node: Er kann auf RPC-Anfragen reagieren und den aktuellen State widerspiegeln, aber er kann keine Blöcke vorschlagen oder abstimmen. ### Vorteile dieses Designs | **Ziel** | **Wie Non-Validator-Nodes helfen** | | :--------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------- | | Validator-Menge schlank halten | Non-Validator-Nodes stimmen nicht ab; nur Validatoren tun das. | | Unbegrenzte horizontale Skalierung | RPC-Anbieter können hunderte von Read/Write-RPC-Nodes hochfahren, jeder mit eigenem Non-Validator-Node, ohne neue Validator-Plätze zu benötigen. | | Konsenskorrektheit wahren | Jeder Ausführungs-Node folgt weiterhin genau einer CL. Es besteht kein Risiko einer State-Divergenz. | | Risiko reduzieren | Non-Validator-Nodes sind Read-Only und können Konsensnachrichten nicht beeinflussen. | | Failover vereinfachen | Indem sie mehreren Validatoren folgen, können sie automatisch zu einem neuen wechseln, wenn einer offline geht. | ### Zusammenfassender Vergleich | Funktion | Validatoren | Non-Validator-Nodes | | :---------------------- | :------------------------------------------------- | :------------------------ | | Konsensteilnahme | Vollständig (vorschlagen, abstimmen, finalisieren) | Keine (nur empfangen) | | Nachrichtentypen | Alle Konsensnachrichten | Nur Block-Nachrichten | | Netzwerkrolle | Aktiver Teilnehmer | Passiver Follower | | Ressourcenanforderungen | Höher (vollständiger Konsens) | Niedriger (nur Messaging) | ## Progressive Dezentralisierung Plasma folgt einem [Modell der progressiven Dezentralisierung](https://a16zcrypto.com/posts/article/progressive-decentralization-crypto-product-management/). Statt die Validator-Menge vom ersten Tag an zu öffnen, liegt der anfängliche Fokus auf Stabilität, Performance und Entwicklerfreundlichkeit. Dieser Ansatz priorisiert die Netzwerkzuverlässigkeit, während sich Kernprotokoll-Komponenten noch weiterentwickeln. Dezentralisierung bleibt ein langfristiges Ziel, wird aber stufenweise eingeführt. Die Validator-Menge wird in drei Phasen erweitert: Während des Testnets werden alle Konsens-Nodes vom Plasma-Team betrieben, um schnelle Iteration und minimales operatives Risiko zu ermöglichen. Nach dem Mainnet-Start tritt eine kleine Gruppe externer Validatoren bei, ausgewählt nach Zuverlässigkeit, operativer Bereitschaft und geografischer Verteilung. Mit der Zeit wird der Validator-Zugang öffentlich geöffnet, gestützt durch Protokoll-Sicherheitsmaßnahmen für Sicherheit, Liveness und ökonomische Ausrichtung. Dieser stufenweise Rollout balanciert Dezentralisierung mit Netzwerkintegrität. Er ermöglicht es dem Protokoll, sich zu härten, bevor kritische Infrastrukturverantwortlichkeiten an eine breitere Validator-Menge übergeben werden. ## Peer-Discovery Plasma-Nodes entdecken und verbinden sich mit Peers über zwei unabhängige Mechanismen — einen für jede Schicht des Stacks. ### Ausführungsschicht (Reth) Der Execution Client verwendet Ethereums Standard-[devp2p](https://github.com/ethereum/devp2p)-Protokoll für Peer-Discovery. Beim Start verbindet sich Ihr Reth-Node mit einer Reihe vertrauenswürdiger Execution-Peers, die in `enodes.txt` definiert sind. Dies sind [enode-URLs](https://ethereum.org/en/developers/docs/networking-layer/#enode), die den öffentlichen Schlüssel, die IP-Adresse und den Port jedes Peers kodieren. Die `enodes.txt` jedes Netzwerks ist im [non-validator-templates](https://github.com/PlasmaLaboratories/non-validator-templates)-Repository vorkonfiguriert. Nach der Verbindung mit dem initialen Set findet Reths integriertes Discovery-Protokoll (discv4/discv5) automatisch weitere Peers. Die Execution-P2P-Schicht läuft auf Port `30303` (TCP/UDP). ### Konsensschicht (PlasmaBFT) Der Consensus Observer Client entdeckt Peers über Bootstrap-Nodes, die in `non-validator.toml` definiert sind. Jeder Bootstrap-Node-Eintrag enthält einen API-Host, P2P-Port und eine [libp2p-Peer-ID](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" ``` Jedes Netzwerk wird mit 3 Bootstrap-Nodes ausgeliefert. Ihr Observer Client verbindet sich beim Start mit diesen und findet, bei aktivierter Peer-Discovery (`discovery.enabled = true`), automatisch weitere Peers im Netzwerk. Die Konsens-P2P-Schicht läuft auf Port `34070` (TCP). ### Nodes hinter NAT Wenn Ihr Node hinter einem NAT-Gateway oder einer Firewall liegt, können andere Peers ihn möglicherweise nicht über seine interne Adresse erreichen. Sie können eine externe Adresse konfigurieren, damit Peers Ihren Node entdecken und sich verbinden können: ```toml non-validator.toml theme={null} [network] external_address = "node.example.com:34070" ``` ```bash CLI theme={null} --p2p.external-address node.example.com:34070 ``` Wenn der Port weggelassen wird, wird standardmäßig der Wert von `p2p_port` verwendet. Stellen Sie sicher, dass die externe Adresse erreichbar ist und die relevanten Ports durch Ihre Firewall weitergeleitet werden. ### Zusammenfassung | Schicht | Protokoll | Port | Discovery-Methode | | :-------- | :-------- | :------ | :------------------------------------------------ | | Execution | devp2p | `30303` | Vertrauenswürdige enodes + automatische Discovery | | Consensus | libp2p | `34070` | Bootstrap-Nodes aus `non-validator.toml` | Details zu Ports und Firewall finden Sie im Leitfaden [Non-Validator-Node-Einrichtung](./non-validator-node-setup#port-configuration). ## Schnellstart Validator-, Non-Validator- und RPC-Anbieter-Rollen verstehen Deployen Sie Ihren Node mit Docker Compose Minimum- und empfohlene Spezifikationen für Ihren Node Loslegen mit erlaubnisfreiem Node-Betrieb