---
title: "Light Clients"
description: "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."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Light Clients
> 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
- [Full Nodes](/de/crypto/full-node/)
- [Weak Subjectivity](/de/crypto/weak-subjectivity/)
- [State Roots](/de/crypto/state-root/)
## Quellen
- [Light clients](https://ethereum.org/developers/docs/nodes-and-clients/light-clients/) - Ethereum.org (abgerufen: 2026-08-13)
- [Altair Light Client -- Sync Protocol](https://ethereum.github.io/consensus-specs/specs/altair/light-client/sync-protocol/) - Ethereum Consensus Specs (abgerufen: 2026-08-13)
- [Altair Light Client -- Light Client](https://ethereum.github.io/consensus-specs/altair/light-client/light-client/) - Ethereum Consensus Specs (abgerufen: 2026-08-13)
- [Electra Light Client -- Sync Protocol](https://ethereum.github.io/consensus-specs/electra/light-client/sync-protocol/) - Ethereum Consensus Specs (abgerufen: 2026-08-13)
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (abgerufen: 2026-08-13)
- [eth_getProof](https://ethereum.github.io/execution-apis/api/methods/eth_getProof/) - Ethereum Execution APIs (abgerufen: 2026-08-13)
- [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum.org (abgerufen: 2026-08-13)
- [Data availability](https://ethereum.org/developers/docs/data-availability/) - Ethereum.org (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/light-client/index.mdx