--- title: "Schwache Subjektivität: Vertrauensanker und sichere PoS-Synchronisierung" description: "Schwache Subjektivität ermöglicht es einem Proof-of-Stake-Knoten, nach Erhalt eines ausreichend aktuellen vertrauenswürdigen Kontrollpunkts objektiv vorwärts zu prüfen. Erfahren Sie, warum alte Signaturen langfristige Historien unterstützen können, wie die Aktualität von Kontrollpunkten und die Unabhängigkeit der Quelle überprüft werden und was die Synchronisierung von Kontrollpunkten nicht beweist." 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. # Schwache Subjektivität: Vertrauensanker und sichere PoS-Synchronisierung > Nur zu Bildungszwecken; keine Anlageberatung. Investieren kann zu Verlusten führen. ## Direkte Antwort Schwache Subjektivität ist ein Proof-of-Stake-Sicherheitsmodell, bei dem ein Knoten Blöcke, Zustandsübergänge, Abstimmungen und Fork-Auswahlen gemäß den Protokollregeln überprüfen kann, nachdem er von einem ausreichend aktuellen Checkpoint gestartet ist, der über einen vertrauenswürdigen oder sozial bestätigten Kanal erhalten wurde. Der „schwache“ subjektive Input ist der Ausgangspunkt. Es ist keine Erlaubnis, beliebige spätere Blöcke auszuwählen: Sobald verankert, muss der Knoten Historien ablehnen, die den Checkpoint nicht enthalten, und normal nach vorne verifizieren. Das Problem ist historische Mehrdeutigkeit. Ein Gegner, der Schlüssel von Validatoren erhält, die ausgeschieden sind und wirtschaftlich nicht mehr bestraft werden können, könnte eine lange alternative Geschichte mit gültig aussehenden Signaturen erstellen. Ein Knoten, der die kanonische Kette beobachtet hat, während diese Validatoren noch bestrafbar waren, behält nützliche Erinnerungen. Ein brandneuer Knoten, ein Knoten, dessen Datenbank gelöscht wurde, oder ein Knoten, der länger offline war als das sichere Rekenzzeitfenster des Protokolls, ist möglicherweise nicht in der Lage, die sozial kanonische Geschichte nur aus Genesis-Daten und Peer-Nachrichten zu identifizieren. Am Ethereum ist ein schwacher-Subjektivitäts-Checkpoint ein `epoch` und `block_root`, den der Client als absolute Bezugspunkte behandelt. Ein erfolgreicher Abgleich muss beweisen, dass der kanonische Pfad diesen Ursprung zu diesem Zeitpunkt enthält; eine Abweichung ist ein kritisches Versagen und keine Fork-Choice-Abstimmung. Ein schwacher-Subjektivitäts-Checkpoint unterscheidet sich auch von einem gewöhnlichen finalisierten Checkpoint: Wenn ein Knoten zuerst auf zwei widersprüchliche finalisierte Historien ohne vorheriges Gedächtnis stößt, identifizieren die Finalitätsregeln allein nicht, welche soziale Historie kanonisch ist. Verallgemeinern Sie nicht den Mechanismus von Ethereum. CometBFT Light-Clients beginnen von einem vertrauenswürdigen Header innerhalb eines konfigurierten `trusting_period` und übertragen Vertrauen mithilfe von Validator-Set-Überlappungen, Signaturen, Zeitgrenzen und Zeugen. Ouroboros Genesis-Forschung definiert stattdessen eine Ketten-Auswahlregel, die dazu bestimmt ist, von einem vertrauenswürdigen Genesis-Block unter ihrem angegebenen Sicherheitsmodell zu starten. „Proof of Stake“ impliziert daher nicht ein bestimmtes Checkpoint-Format, eine bestimmte Periodenformel oder ein bestimmtes Bootstrap-Verfahren. Trennen Sie also schwache Subjektivität von einer Synchronisationsverknüpfung. Checkpoint-Synchronisation kann die Startzeit und die Verarbeitung des historischen Zustands reduzieren, aber Geschwindigkeit ist nicht die Sicherheitsdefinition. Eine vertrauenswürdige Wurzel authentifiziert nicht die Website, die sie bereitgestellt hat, validiert keine Ausführungspayload außerhalb der angegebenen Annahmen des Clients, stellt keine gekürzte Historie wieder her, beweist keine Datenverfügbarkeit und macht kein ausgeblendetes Peer-Set ehrlich. ## Wie man einen schwach-subjektiven Bootstrap überprüft ### 1. Identifizieren Sie das genaue Protokoll und Sicherheitsmodell Notiere den `network`, `chain ID`, Genesis-Root oder Hash, aktiven Fork oder Laufzeit, Client-Version, Checkpoint-Typ und Konsens-Spezifikation. Bestimme, ob das Protokoll einen aktuellen sozialen Checkpoint, einen vertrauenswürdigen Header plus Validator-Set, eine Finalitätsbeweiskette oder nur Genesis unter einem anderen Modell erfordert. Transplantiere niemals Ethereums `compute_weak_subjectivity_period` oder CometBFTs `trusting_period` in eine andere Kette ohne deren Regeln. ### 2. Entscheiden Sie, ob das bestehende Treuhandverhältnis noch aktuell ist Inventarisiere den zuletzt lokal verifizierten finalisierten Kontrollpunkt des Knotens, seine Epoche oder Höhe und Zeit, die aktuelle Zeitquelle und jede Datenbankwiederherstellung. Berechne das Alter unter Verwendung der aktuellen Protokollregeln und des Zustands, nicht anhand einer erinnernden Kalenderschätzung. Für Ethereum testet der Phase 0 Leitfaden `current_epoch <= ws_state_epoch + ws_period`; Electra ändert die Periodenberechnung so, dass sie vom gesamten aktiven Guthaben und dem Guthabenumschlag abhängt. Wenn das Vertrauen abgelaufen ist, besorge einen neuen Anker außerhalb des Netzes, anstatt es stärker gegen nicht vertrauenswürdige Peers zu versuchen. ### 3. Erwerben und den Checkpoint verifizieren Erhalten Sie denselben Checkpoint aus unabhängig verwalteten und unabhängig bezogenen Kanälen: zum Beispiel ein von Ihnen betriebenes Node, ein anderer Betreiber, mehrere Client-Teams und Explorer mit unterschiedlicher Infrastruktur. Zeichnen Sie jede Quelle, Abrufzeit, Netzwerk, `epoch` und die vollständige Root auf. Fünf URLs, die einen Upstream kopieren, bilden eine Fehlerdomäne. Eine einfache Mehrheitsentscheidung als Antwort ersetzt nicht die Quellenunabhängigkeit, authentifizierten Transport oder die Überprüfung von Vorfällen in der Gemeinschaft. ### 4. Binde jedes Kontrollpunktfeld Überprüfen Sie das Netzwerk und die Genesis-Identität vor dem Checkpoint-Wert. Bewahren Sie die vollständige Root ohne Kürzung auf und kombinieren Sie sie mit der genauen Epoche oder Höhe, dem Zustand, falls erforderlich, der Fork-Version und der Erwerbszeit. Die Anleitung von Ethereum verwendet `block_root:epoch_number`; die Initialisierung von CometBFT bindet zudem einen vertrauenswürdigen Header und Validatorensatz sowie Vertrauensparameter. Eine korrekte Root, die an die falsche Kette oder Höhe angehängt wird, ist kein gültiger Anker. ### 5. Erzwingen Sie einen fehlgeschlagen-geschlossenen Synchronisierungspfad Konfigurieren Sie den Checkpoint über die dokumentierte Schnittstelle des Clients und behalten Sie Startprotokolle. Während der Synchronisation muss der kanonische Pfad beim Checkpoint-Epoch dem angegebenen `block_root` entsprechen. Der Ethereum-Leitfaden erfordert einen beschreibenden kritischen Fehler und Beenden des Prozesses, wenn die Assertion fehlschlägt. Verwerfen Sie den Checkpoint nicht stillschweigend, greifen Sie nicht auf die Mehrheitsmeinung der Peers zurück, überschreiben Sie ihn nicht mit einer neueren Peer-Antwort oder behalten Sie einen Validator-Signatur, während seine Konsensansicht unklar ist. ### 6. Trennen Sie die Schichten, die überprüft wurden und die, die nicht überprüft wurden Verfolgen Sie Vertrauenspunkte des Konsensus, Prüfungen von Beacon- oder Konsensusblöcken, Status der Ausführungspayload, Synchronisierung des Ausführungszustands, historische Nachfüllungen und Anwendungsnachweise separat.Ethereumoptimistisches Synchronisieren erlaubt einen Kontrollpunktanker`ExecutionPayload`angenommen zu werden`VALID`ohne es zuerst der Ausführungs-Engine zu übergeben, während ein optimistischer Knoten keine Validator-Aufgaben ausführen darf.LighthouseCheckpoint-Backfill überprüft die Integrität der historischen Hash-Kette und die Signaturen der Vorschlagenden, stellt jedoch standardmäßig nicht jeden historischen Zustand wieder her. ### 7. Aktualisieren, überwachen und Wiederherstellung üben Stellen Sie eine Benachrichtigung ein und aktualisieren Sie die Marge bequem innerhalb des gültigen Zeitraums. Überwachen Sie die Finalisierung, die Uhrgesundheit, Kundenmeinungsverschiedenheiten, den Status von `execution_optimistic`, die Diversität der Peer-Teilnehmer, das Alter von Prüfpunkten und Rückfülllücken. Üben Sie die Wiederherstellung von einer gelöschten Datenbank, einem abgelaufenen Prüpunkt, widersprüchlichen Quellen und einem nicht verfügbaren Anbieter. Bewahren Sie unterzeichnete Aufzeichnungen von Ankern und Entscheidungen auf, aber lassen Sie einen archivierten Prüpunkt nicht zu einem dauerhaft vertrauenswürdigen veralteten Prüpunkt werden. ## Bearbeitete Beispiele ### Ethereum Kontrollpunkt mit verbleibendem Spielraum Verwenden Sie einen illustrativen Zustand, dessen anwendbare Electra-Referenzberechnung `ws_period = 3,532 epochs` ergibt. Angenommen `current_epoch = 420,000` und der unabhängig bestätigte Kontrollpunkt ist `checkpoint_epoch = 418,200`: `checkpoint_age = 420,000 - 418,200 = 1,800 epochs`. Der Aktualitätstest des Leitfadens ist `420,000 <= 418,200 + 3,532`, daher liegt der Kontrollpunkt innerhalb des Zeitraums. Bei `32 slots * 12 seconds = 6.4 minutes per epoch` beträgt sein Alter `1,800 * 6.4 / 1,440 = 8 days`. Der verbleibende Spielraum beträgt `3,532 - 1,800 = 1,732 epochs` oder `1,732 * 6.4 / 1,440 = 7.6978 days`. Dies verwendet einen Referenztabellenzeitraum, kein Live-Netzwerk-Versprechen; der Client muss vom tatsächlichen Fork und Zustand aus berechnen. ### Abgelaufener Prüfpunkt wird nicht von mehr Peers repariert Angenommen `current_epoch = 500,000`, `checkpoint_epoch = 496,000` und das zutreffende `ws_period = 3,532 epochs`: `checkpoint_age = 500,000 - 496,000 = 4,000 epochs`. Da `500,000 > 496,000 + 3,532`, ist der Checkpoint um `4,000 - 3,532 = 468 epochs` veraltet. Bei 6.4 Minuten pro Epoche liegt das `468 * 6.4 / 60 = 49.92 hours` über der Grenze. Das Herunterladen desselben abgelaufenen Wurzels von 100 Peers stellt die Annahme nicht wieder her; der Betreiber benötigt einen ausreichend aktuellen Checkpoint von vertrauenswürdigen, bestätigten Kanälen. ### Quellenanzahl versus Quellunabhängigkeit Ein Operator erhält fünf Antworten. Vier melden `epoch = 600,000` und eine identische vollständige Wurzel mit der Bezeichnung `root_A`, während eine andere eine andere vollständige Wurzel mit der Bezeichnung `root_B` meldet. Die Untersuchung zeigt, dass drei übereinstimmende Websites alle denselben gehosteten Knoten proxyen; die vierte ist der eigene Knoten des Operators. Die scheinbare Übereinstimmung ist `4 / 5 = 80%`, repräsentiert jedoch nur zwei unabhängige Linien. Unter einer Richtlinie, die drei unabhängige administrative und Datenpfade verlangt, ist der Kontrollpunkt noch nicht genehmigt. Ein dritter unabhängiger Operator bestätigt `root_A`, der abweichende Dienst wird isoliert, und der Provenienzbericht erklärt die Entscheidung. ### CometBFT-Stil Vertrauenszeitraum Budget Betrachten Sie eine Kette, die mit `unbonding_period = 21 days` konfiguriert ist, und einen vom Betreiber ausgewählten `trusting_period = 14 days`, im Einklang mit der Anforderung, dass die Vertrauensperiode kürzer als die Entbündelungsperiode sein muss. Ein vertrauenswürdiger Header, der `11 days` alt ist, hat `14 - 11 = 3 days` Spielraum. Ein tägliches Aktualisierungsziel lässt einen operativen Puffer. Wenn der Client nach `16 days` zurückkehrt, liegt der Header zwei Tage über seiner Vertrauensperiode und muss durch eine neue vertrauenswürdige Initialisierung ersetzt werden; Ethereum-Epochenformeln entscheiden diesen CometBFT-Fall nicht. ## Risiken und Prüfungsfehler - **Falsches Netzwerk:** Eine gültige Wurzel aus Testnetz, Fork, Klon oder anderer Genesis kann die falsche Historie verankern. - **Veralteter Checkpoint:** Eine Wurzel außerhalb des anwendbaren Zeitraums erfüllt die Annahme über aktuelle Validatoren nicht mehr. - **Falsche Periodenformel:** Fork-Upgrades, Validator-Guthaben, Churn, Unbonding und Sicherheitsparameter können die Grenze verändern. - **Einheitliche Quelle:** Mehrere Endpunkte können denselben Knoten, Cloud-Account, dieselbe Datenbank, denselben DNS-Anbieter oder Betreiber nutzen. - **Kompromittierte Verteilung:** Eine bösartige Version, Website, ein Paket, eine DNS-Antwort oder Support-Nachricht kann den Checkpoint austauschen. - **Verkürzter Vergleich:** Nur Präfix, Screenshot oder formatierten Bezeichner zu vergleichen kann eine abweichende vollständige Wurzel verbergen. - **Feldabweichung:** Die richtige Wurzel mit falscher Epoche, Höhe, falschem Zustand, Fork oder Netzwerk ist nicht derselbe Checkpoint. - **Fallback auf Peer-Mehrheit:** Ein eclipsed Node kann viele gegnerische Peers sehen; ihre Anzahl überstimmt den Vertrauensanker nicht. - **Stiller Fallback:** Ein Client oder Wrapper, der einen abgelehnten Checkpoint ignoriert, unterläuft die Fail-Closed-Kontrolle. - **Widersprüchliche finalisierte Historien:** Ein neuer Knoten löst einen Konsensfehler nicht dadurch, dass beide Zweige als finalisiert gelten. - **Uhrfehler:** Falsche lokale Zeit verfälscht Prüfungen von Slot, Epoche, Alter, Vertrauenszeitraum und künftigen Headern. - **Verwechslung des optimistischen Zustands:** Ein importierter Konsensblock kann noch einen nicht vollständig validierten Execution Payload enthalten. - **Verfrühte Validator-Aufgaben:** Signieren im optimistischen, unsynchronisierten oder unsicheren Zustand kann Fehlstimmen oder Slashing auslösen. - **Verwechslung historischer Vollständigkeit:** Checkpoint-Synchronisierung und Backfill können historische Zustände auslassen, obwohl der aktuelle Head gültig ist. - **Ungültige Backfill-Signaturen:** Auch ein per Hash verketteter historischer Block braucht die vorgeschriebene Proposer-Signaturprüfung. - **Unzureichender Ausführungs- oder Anwendungsnachweis:** Die Konsensverankerung beweist keine beliebigen RPC-Werte, Vertragsbehauptungen oder Off-Chain-Indizes. - **Datenverfügbarkeitslücke:** Eine Zustandswurzel garantiert keinen Zugriff auf jeden Body, Blob, Witness oder historischen Datensatz. - **Abgelaufener Wiederherstellungsplan:** Wird der Ablauf erst im Störfall entdeckt, fehlt möglicherweise eine unabhängige Checkpoint-Quelle. - **Erfasste soziale Koordination:** Governance, Client-Teams, Explorer, Börsen und Betreiber können Anreize oder Abhängigkeiten teilen. - **Falsche Verallgemeinerung:** Ein anderes PoS-Design kann andere Annahmen, Beweisketten, Vertrauenszeiträume oder Genesis-Bootstrap-Garantien nutzen. ## Häufige Missverständnisse ### Bedeutet schwache Subjektivität, dass die Protokollregeln nach dem Start subjektiv sind? Nein. Der Knoten akzeptiert einen bestimmten aktuellen Anker über einen sozialen oder vertrauenswürdigen Kanal und wendet dann deterministische Validierungs- und Fork-Choice-Regeln an. Blöcke, die mit dem Anker in Konflikt stehen, werden abgelehnt. ### Ist ein fertiger Checkpoint automatisch ein sicherer Bootstrap-Checkpoint? Nein. Es muss zum vorgesehenen Netzwerk und zur kanonischen sozialen Geschichte gehören, nach den anwendbaren Regeln ausreichend aktuell sein, die erforderlichen Felder enthalten und über einen vertrauenswürdigen, bestätigten Weg kommen. Eine erstmals auf einer von einem Angreifer bereitgestellten Geschichte beobachtete Endgültigkeit begründet keine Herkunft. ### Entfernt das Synchronisieren von Genesis das Problem des Fernangriffs? Nicht für ein Protokoll, dessen Sicherheitsmodell einen aktuellen Weak-Subjectivity-Checkpoint erfordert. Das interne Wiedergeben gültiger Signaturen von Genesis an sagt einem frischen Knoten nicht, welche von zwei alten finalisierten Historien die Gemeinschaft tatsächlich verfolgt hat. Andere Protokolle können unter verschiedenen Annahmen unterschiedliche Genesis-Bootstrap-Garantien bieten. ### Überprüft die Checkpoint-Synchronisierung alle historischen Ausführungen und Zustände? Nein. Das Verhalten des Clients ist geschichtet und implementierungsspezifisch. Der Knoten kann das Ankerobjekt vertrauen oder optimistisch importieren, den aktuellen Ausführungszustand separat synchronisieren und nur Blockverbindungen und Vorschlagssignaturen nachtragen, ohne alle historischen Zustände neu aufzubauen. ### Kann einem fest codierten Kontrollpunkt für immer vertraut werden? Nein. Ein Prüfpunk ist an ein Netzwerk gebunden, Punkt. Er kann weiterhin als Prüfungsnachweis oder historische Einschränkung nützlich bleiben, aber ein Knoten, dessen jüngste Vertrauensannahme abgelaufen ist, benötigt einen entsprechend aktuellen Anker oder den von diesem Protokoll angegebenen Wiederherstellungsprozess. ## Verwandte Themen - [Endgültigkeit](/de/crypto/finality/) - [Gabelauswahlregel](/de/crypto/fork-choice-rule/) - [Nachweis des Einsatzes](/de/crypto/proof-of-stake/) - [Schlitzen](/de/crypto/slashing/) - [Leichtclient](/de/crypto/light-client/) ## Quellen - [Schwache Subjektivität](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (zugegriffen: 2026-08-19) - [Phase 0 -- Weak Subjectivity Anleitung](https://ethereum.github.io/consensus-specs/specs/phase0/weak-subjectivity/) - Ethereum Konsens-Spezifikationen (zugegriffen: 2026-08-19) - [Electra -- Weak Subjectivity Anleitung](https://ethereum.github.io/consensus-specs/electra/weak-subjectivity/) - Ethereum Konsens-Spezifikationen (zugegriffen: 2026-08-19) - [Phase 0 -- P2P-Schnittstelle](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Konsens-Spezifikationen (zugegriffen: 2026-08-19) - [Optimistisches Synchronisieren](https://ethereum.github.io/consensus-specs/sync/optimistic/) - Ethereum Konsens-Spezifikationen (zugegriffen: 2026-08-19) - [Kontrollpunkt-Synchronisation](https://lighthouse-book.sigmaprime.io/advanced_checkpoint_sync.html) - Lighthouse Book (zugegriffen: 2026-08-19) - [CometBFT Kernüberprüfung](https://docs.cometbft.com/v0.38/spec/light-client/verification/) - CometBFT (zugegriffen: 2026-08-19) - [Ouroboros Genesis: Zusammensetzbare Proof-of-Stake-Blockchains mit dynamischer Verfügbarkeit](https://eprint.iacr.org/2018/378.pdf) - IACR Cryptology ePrint Archive (zugegriffen: 2026-08-19) Source: https://wiki.fcontext.com/de/crypto/weak-subjectivity/index.mdx