Zum Hauptinhalt springen

​
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

SchichtRolleVertrauensmodell
Konsensschicht (CL)Blöcke vorschlagen und finalisierenPlasmaBFT
Ausführungsschicht (EL)Transaktionen verarbeiten, State verwalten, RPCs bedienenVertraut 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

ZielWie Non-Validator-Nodes helfen
Validator-Menge schlank haltenNon-Validator-Nodes stimmen nicht ab; nur Validatoren tun das.
Unbegrenzte horizontale SkalierungRPC-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 wahrenJeder Ausführungs-Node folgt weiterhin genau einer CL. Es besteht kein Risiko einer State-Divergenz.
Risiko reduzierenNon-Validator-Nodes sind Read-Only und können Konsensnachrichten nicht beeinflussen.
Failover vereinfachenIndem sie mehreren Validatoren folgen, können sie automatisch zu einem neuen wechseln, wenn einer offline geht.

​
Zusammenfassender Vergleich

FunktionValidatorenNon-Validator-Nodes
KonsensteilnahmeVollständig (vorschlagen, abstimmen, finalisieren)Keine (nur empfangen)
NachrichtentypenAlle KonsensnachrichtenNur Block-Nachrichten
NetzwerkrolleAktiver TeilnehmerPassiver Follower
RessourcenanforderungenHöher (vollständiger Konsens)Niedriger (nur Messaging)

​
Progressive Dezentralisierung

Plasma folgt einem Modell der progressiven Dezentralisierung. 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:
1

Zentralisierter Betrieb

Während des Testnets werden alle Konsens-Nodes vom Plasma-Team betrieben, um schnelle Iteration und minimales operatives Risiko zu ermöglichen.
2

Vertrauenswürdige Validator-Menge

Nach dem Mainnet-Start tritt eine kleine Gruppe externer Validatoren bei, ausgewählt nach Zuverlässigkeit, operativer Bereitschaft und geografischer Verteilung.
3

Erlaubnisfreie Teilnahme

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-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, die den öffentlichen Schlüssel, die IP-Adresse und den Port jedes Peers kodieren. Die enodes.txt jedes Netzwerks ist im 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: 
[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: 
[network]
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

SchichtProtokollPortDiscovery-Methode
Executiondevp2p30303Vertrauenswürdige enodes + automatische Discovery
Consensuslibp2p34070Bootstrap-Nodes aus non-validator.toml
Details zu Ports und Firewall finden Sie im Leitfaden Non-Validator-Node-Einrichtung.

​
Schnellstart

Node-Typen

Validator-, Non-Validator- und RPC-Anbieter-Rollen verstehen

Non-Validator-Node-Einrichtung

Deployen Sie Ihren Node mit Docker Compose

Hardware-Anforderungen

Minimum- und empfohlene Spezifikationen für Ihren Node

Operator-Onboarding

Loslegen mit erlaubnisfreiem Node-Betrieb