Zum Inhalt springen
Financial Context Wiki

Light Clients

Fork-sensitiver Leitfaden zu Bootstrap und Sync Committees von Consensus Light Clients, Weak-Subjectivity-Checkpoints, optimistischen und finalisierten Headern, Ausführungszustandsnachweisen, RPC-Anbietern, Datenverfügbarkeit und Datenschutz.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Ein Light Client ist Verifizierungssoftware, die einer Blockchain mit weniger lokaler Ausführung, weniger lokalem Zustand und weniger Historie folgt als eine Full Node. Eine Light Node ist ein Gerät oder Prozess, auf dem diese Software läuft. Auf Ethereum mit Proof of Stake startet ein Consensus Light Client von einem vertrauenswürdigen, aktuellen und finalisierten Checkpoint und prüft fork-sensitiv Updates der Sync Committees, um optimistische und finalisierte Header zu führen. Er führt nicht jede EVM-Transaktion erneut aus.

Diese verifizierte Konsenssicht ist nur der erste Vertrauensanker. Um einen Konto- oder Contract-Storage-Wert zu verifizieren, muss der Client den authentifizierten Beacon-Header mit dem Execution-Payload-Header verknüpfen, dessen stateRoot auswählen und einen Konto- oder Storage-Nachweis gegen diese Root prüfen. Eine gewöhnliche RPC-Antwort ohne den erforderlichen Nachweis bleibt eine Behauptung des Anbieters. Konsenssignaturen belegen nicht automatisch Transaktionshistorie, Receipts, Traces, Datenverfügbarkeit, Anwendungsverhalten oder langfristige Abrufbarkeit.

Funktionsweise

  1. Netzwerk und Vertrauensanker festlegen: Chain-Identität, Genesis Validators Root und Genesis-Zeit, Fork-Zeitplan und Presets, aktuelle Uhrzeit, Client-Version sowie einen aktuellen, vertrauenswürdigen und finalisierten Weak-Subjectivity-Checkpoint. Den Checkpoint über unabhängige authentifizierte Quellen gegenprüfen; Übereinstimmung unter Peers kann eine bösartige Ausgangs-Root nicht korrigieren.
  2. Ein LightClientBootstrap für die vertrauenswürdige Block-Root abrufen. Bootstrap-Header, aktuelles Sync Committee und dessen Merkle-Branch prüfen und anschließend den LightClientStore initialisieren. Chain, Fork Digest, Generalized Index oder Serialisierungsschema ablehnen, wenn sie nicht zum konfigurierten Fork passen.
  3. LightClientUpdate-Objekte nach Sync-Committee-Periode verarbeiten. Vor der Rotation der Committees Slots, Participation Bits, aggregierte BLS-Signatur und Domain, Branches des aktuellen und nächsten Committees, Finality Branch und Monotonie prüfen. Fork-Upgrades können Objektfelder und Generalized Indices ändern; Altair-Konstanten sind keine dauerhaft universellen Werte.
  4. Getrennte Richtlinien für optimistic_header und finalized_header führen. Ein optimistisches Update kann aktuellere Informationen mit höherem Reorganisations- oder Vorenthaltungsrisiko liefern; ein finalisiertes Update hat einen stärkeren Konsensstatus, kann aber zurückliegen. Anwendungen müssen den passenden Header ausdrücklich wählen, statt die neueste Antwort nachträglich als final zu bezeichnen.
  5. Ausführungsdaten verankern. Execution-Payload-Header und Branch im authentifizierten Light-Client-Header prüfen und dann jede Konto- oder Storage-Abfrage an den Execution-stateRoot, Block-Hash und Finalitätsstatus binden. Auf Ethereum kann eth_getProof einen Konto- und angeforderte Storage-Nachweise liefern; Nodes, Pfade, Werte und Nichtexistenz sind lokal zu verifizieren.
  6. Jede nicht verifizierte Oberfläche erfassen. Ein Saldennachweis authentifiziert weder Transaction Receipt, Log-Abfrage, Trace, Call-Simulation, Mempool, Token-Bezeichnung, Oracle, Blob oder historischen Bereich noch die Behauptung des Anbieters, kein Ergebnis ausgelassen zu haben. Für jedes benötigte Objekt einen Nachweis, unabhängigen Neuaufbau, Full-Node-Fallback oder eine ausdrückliche Vertrauensannahme festlegen.
  7. Im Fehlerfall geschlossen arbeiten. Checkpoint, Fork, optimistische und finalisierte Roots, Execution Block und State Root, Proof Nodes, Anbieter und Zeitstempel protokollieren. Maximale Veraltung durchsetzen, Anbieter und Netzwerkpfade diversifizieren, Abfrageprivatsphäre schützen, Erholung von Eclipse-Angriffen und Ausfällen testen und eine Full Node oder ein anderes Verifikationssystem verwenden, wenn die Nachweisfläche des Light Clients nicht ausreicht.

Durchgerechnete Beispiele

  • Ganzzahlige Grenze des Sync Committees. Für ein Committee mit 512 Mitgliedern lautet der Supermajority-Test der Spezifikation participants * 3 >= 512 * 2. Bei 341 Teilnehmern gelten 341 / 512 = 66.6015625% und 1,023 < 1,024; der Test schlägt fehl. Bei 342 gelten 342 / 512 = 66.796875% und 1,026 >= 1,024; der Test ist bestanden. Damit wird die konfigurierte Update-Regel geprüft, nicht die Ehrlichkeit aller Committee-Mitglieder oder Implementierungen bewiesen.
  • Header-Zeitachsen. Ein didaktischer Checkpoint liegt bei Slot 10,000, ein attestierter Header bei 10,064 und dessen finalisierter Header bei 10,032. Bei 12 seconds/slot liegt der attestierte Header 64 * 12 = 768 seconds = 12 minutes 48 seconds nach dem Checkpoint; die Finalität liegt 32 * 12 = 384 seconds = 6 minutes 24 seconds hinter dem attestierten Header. Slot-Timing garantiert weder Netzwerkauslieferung noch Finalität gemäß einer festen Echtzeit-SLA.
  • Kompakter Branch, begrenzte Aussage. In einem idealen ausgeglichenen Baum mit 2^20 Blättern enthält ein Single-Leaf-Branch 20 Geschwister-Hashes. Bei 32 bytes/hash sind das 640 bytes; gegenüber einem Objekt mit 8 MiB = 8,388,608 bytes hat der Branch 0.00762939453125% der Größe, eine Reduktion um 99.99237060546875%. Der Branch belegt nur die Beziehung des Blatts zur Root, nicht die Verfügbarkeit der übrigen Bytes.
  • Nachweis gegenüber bloßem RPC. An einem finalisierten Execution-stateRoot ergibt ein verifizierter Kontonachweis 3.25 ETH, während eine unbelegte RPC-Antwort 3.30 ETH nennt. Die Abweichung beträgt 0.05 ETH; die unbelegte Antwort ist 0.05 / 3.30 = 1.5151515152% höher. Akzeptiert wird der unter der gewählten Root belegte Wert. Daraus dürfen aber kein späterer Saldo, Receipt, historisches Ergebnis oder Token-Identität abgeleitet werden.

Risiken

  • Falsche Chain, Genesis Validators Root, Genesis-Zeit oder Presets konfigurieren.
  • Von einem bösartigen, veralteten oder nicht finalisierten Checkpoint starten.
  • Nur eine nicht authentifizierte Checkpoint-Quelle nutzen oder einen Long-Range-Fork akzeptieren.
  • Durch Abweichung der lokalen Uhr Slots, Perioden, Domains oder Veraltung falsch beurteilen.
  • Mit veraltetem Fork-Zeitplan, Objektschema oder Generalized Index arbeiten.
  • Sync-Committee-Beteiligung, BLS-Signaturen oder Domains nicht validieren.
  • Committee-Rotation verpassen oder ein ungültiges aktuelles oder nächstes Committee akzeptieren.
  • Den optimistischen Header wie den finalisierten Header behandeln.
  • Falschen Beacon-Header, Execution Payload oder Execution-Block-Hash verknüpfen.
  • Konto- oder Storage-Nachweis gegen den falschen stateRoot prüfen.
  • Fehlerhafte Trie-Nodes, Pfade, Kodierungen oder Nichtexistenznachweise akzeptieren.
  • Eine nicht unterstützte oder unbelegte RPC-Methode als verifiziert behandeln.
  • Veraltete, zensierte, unvollständige oder erfundene Anbieterantworten erhalten.
  • Eclipse-, Sybil- oder gemeinsame Kontrollausfälle scheinbar verschiedener Anbieter erleiden.
  • Verfügbarkeit verlieren, wenn Proof-Serving Full Nodes Daten prunen oder nicht mehr ausliefern.
  • Konsensgültigkeit mit erneuter Ausführung oder Anwendungskorrektheit verwechseln.
  • Einen gültigen Nachweis mit Datenverfügbarkeit oder dauerhafter Abrufbarkeit verwechseln.
  • Benötigte Receipts, Logs, Traces, Bodies oder Historie nicht erhalten.
  • Ausfall von Client-Implementierung, Abhängigkeit, Binary oder Fork-Upgrade.
  • Abfragen, IP, Konten und Transaktionen gegenüber Anbietern oder Peers offenlegen.

Häufige Irrtümer

  • Ein Light Client ist lediglich eine kleinere Full Node oder ein umbenannter Remote-RPC-Endpunkt.
  • Ein vom Sync Committee verifizierter Header macht jede RPC-Antwort vertrauenswürdig.
  • Der aktuellste optimistische Header entspricht einem finalisierten Header.
  • Ein Merkle-Nachweis oder eine Konsenssignatur belegt Datenverfügbarkeit und vollständige Historie.
  • Die Nutzung eines Light Clients bietet automatisch Datenschutz, Verfügbarkeit und Zensurresistenz einer Full Node.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...