Zum Inhalt springen
Financial Context Wiki

Nothing at Stake: Äquivokation, Slashing, Finalität und Alt-Schlüssel-Risiko

Nothing at Stake bezeichnet das Proof-of-Stake-Anreizproblem, bei dem die Unterstützung konkurrierender Verläufe geringe Grenzkosten haben kann. Strafbare Nachrichten, Erwartungswert, Quorumschnitt, Beweisdurchsetzung, Fork-Wahl und Weak-Subjectivity-Annahmen sind getrennt zu prüfen.

Aktualisiert

Nur zur Schulung in der Protokollanalyse; keine Anlage-, Staking-, Validatorbetriebs- oder Sicherheitsberatung. Slashing- und Finalitätsregeln unterscheiden sich je nach Protokoll und Version; auch Implementierung, Schlüsselverwahrung, Netzwerkbedingungen, Governance und Weak-Subjectivity-Annahmen können versagen.

Direkte Antwort

Nothing at Stake ist ein Proof-of-Stake-Anreizproblem: Ist eine zusätzliche Signatur billig und belegt das Protokoll unvereinbare Unterstützung nicht mit wirksamen Kosten, kann ein Validator mehr verdienen, wenn er jeden konkurrierenden Verlauf unterstützt, statt einen auszuwählen. Folgen viele Validatoren diesem privaten Anreiz, können Forks Unterstützung behalten, die Konvergenz kann schwächer werden und ein Angreifer kann Signaturen erhalten, deren Reproduktion bei Proof of Work kostspielig wäre.

Der Begriff bedeutet weder, dass jedes Proof-of-Stake-System kein Sicherheitsbudget besitzt, noch, dass jede Stimme für einen unterlegenen Fork ein Fehlverhalten ist. Gebundenes Kapital, entgangene Belohnungen, Slashing, verzögerte Auszahlungen sowie Fork-Wahl- und Finalitätsregeln können den Ertrag verändern. Welche signierten Nachrichten und Konflikte strafbar sind, hängt von Protokoll und Version ab; eine normale Stimmaktualisierung, verspätete Nachricht oder vorübergehende ehrliche Fork kann zulässig sein.

Drei Fragen müssen getrennt bleiben. Erstens: Kann ein derzeit gebundener Validator zu geringen Kosten zwischen jüngeren Zweigen äquivokieren? Zweitens: Kann nicht verfügbares oder gegnerisches Stimmgewicht den Fortschritt aufhalten, ohne zwei finalisierte Verläufe zu erzeugen? Drittens: Können alte Schlüssel einen langen Alternativverlauf erzeugen, nachdem der Stake auszahlbar ist? Diese Anreiz- und Konsensrisiken hängen zusammen, haben aber unterschiedliche Beweise, Schwellenwerte und Abwehrmaßnahmen.

Ethereum ist ein nützliches Beispiel, keine allgemeingültige Vorlage. Seine Konsensspezifikationen machen zwei verschiedene Vorschläge für denselben Slot sowie Attestierungen mit Doppelabstimmung oder Surround Vote slashbar. Die Fork-Wahl kann den Einfluss äquivokierender Validatoren verwerfen, während die Finalität Supermehrheitsstimmen und Strafen nutzt. Andere Proof-of-Stake-Familien verwenden andere Leader-Auswahlverfahren, Kettenauswahlregeln, Checkpoints, Verfügbarkeitsannahmen oder formale Sicherheitsmodelle.

Nothing at Stake analysieren

  1. Protokollkontext festlegen. Erfasse protocol, version, network, epoch, slot, validator set und Beobachtungszeitpunkt. Bestimme die aktiven fork choice, finality gadget, reward rule, penalty rule und withdrawal delay; die Bezeichnung „PoS“ legt keinen dieser Punkte fest.
  2. Signierte Handlungen definieren. Liste Blockvorschläge, Attestierungen, Prevotes, Precommits, Zertifikate oder andere Nachrichten und ihre Domänen auf. Unterscheide zwei Nachrichten, die lediglich verschiedene Nachfolger bevorzugen, von einem nach den zitierten Regeln formal slashbaren double proposal, double vote oder surround vote.
  3. Ertrag ohne Strafe modellieren. Schätze Zweigwahrscheinlichkeiten, Belohnungen des kanonischen Zweigs, zusätzliche Signatur- und Verbreitungskosten, Bestechungen, entgangene Gelegenheiten und Belohnungen für widersprüchliche Nachrichten. Vergleiche EV(honest) mit EV(equivocate), statt aus geringem Stromverbrauch auf eine profitable Abweichung zu schließen.
  4. Durchsetzbaren Verlust modellieren. Ermittle gebundenes Guthaben, Erkennungswahrscheinlichkeit, Gültigkeitsfenster der Beweise, Meldeweg, Aufnahme- und Zensurrisiko, anfängliche Strafe, Korrelationsstrafe, Ausschluss, Auszahlungszeitpunkt und entgangenes künftiges Einkommen. Eine dokumentierte Strafe ist nicht gleichbedeutend mit einer zuverlässigen Durchsetzung von slashing evidence.
  5. Fork-Wahl und Finalität trennen. Rekonstruiere, wie neueste Stimmen, Äquivokationen und Nachrichtentiming den Head beeinflussen, und berechne das Gewicht zur Rechtfertigung oder Finalisierung von Checkpoints. Analysiere safety threshold und liveness threshold getrennt: Zurückgehaltene Stimmen können Finalität verhindern, ohne widersprüchliche Finalität zu erzeugen.
  6. Alt-Schlüssel- und Synchronisationsannahmen prüfen. Bestimme, wann ausgeschiedener Stake nicht mehr bestraft werden kann, welchen finalisierten Verlauf ein Online-Knoten ablehnt, wie ein neuer oder lange offline gewesener Knoten einen weak-subjectivity checkpoint erhält und wie Aktualität und Herkunft geprüft werden. Dies ist das Long-Range-Problem und nicht bloß eine jüngere Doppelabstimmung.
  7. Betrieb und Kontrolle einem Stresstest unterziehen. Prüfe doppelte Schlüssel, Failover-Knoten, Remote-Signer, Datenbank-Rollbacks, Clientfehler, korreliertes Hosting, Staking-Pools, delegierte Verwahrung, Partitionen, Eclipse-Angriffe und Beweiszensur. Zähle unabhängige Kontroll- und Softwarepfade, nicht nur Validator-IDs.

Das Ergebnis sollte eine versionierte Anreiz- und Konsensbewertung sein, kein allein aus dem Begriff abgeleitetes Urteil. Zeige die genauen Nachrichten, die ein Schlüssel signieren darf, objektiv prüfbare Konfliktbeweise, den Zeitraum der erreichbaren Sicherheit, den Sicherheit schützenden Schwellenwert, den Fortschritt ermöglichenden Schwellenwert und den vertrauenswürdigen Zustand, den ein synchronisierender Knoten benötigt.

Rechenbeispiele

1. Eine straffreie Strategie kann beide Zweige begünstigen

Angenommen, genau einer von zwei Zweigen wird kanonisch: Zweig A mit Wahrscheinlichkeit 0.55 und Zweig B mit 0.45. Eine Signatur auf dem kanonischen Zweig verdient 1.00 unit, eine Signatur auf dem unterlegenen Zweig nichts. Ohne Strafen und zusätzliche Betriebskosten ergibt ausschließliches Signieren von A EV(A only) = 0.55 * 1.00 = 0.55 units. Das Signieren beider Zweige ergibt EV(sign both) = (0.55 + 0.45) * 1.00 = 1.00 unit.

Diese Rechnung veranschaulicht das Anreizproblem; sie ist keine Staking-Renditeprognose. Sie setzt voraus, dass bei jedem Ausgang die Signatur auf dem kanonischen Zweig belohnt wird, die Handlungen zulässig oder nicht durchgesetzt sind, sich die Zweigergebnisse gegenseitig ausschließen und dem Validator keine Preis-, Reputations-, Latenz- oder künftigen Einkommensverluste entstehen.

2. Durchsetzbares Slashing kann den Ertrag umkehren

Behalte die kanonische Bruttobelohnung von 1.00 unit bei und addiere eine Bestechung von 0.02 unit für die Äquivokation. Angenommen, gültige Beweise erreichen den Strafmechanismus mit Wahrscheinlichkeit 0.80 und der gesamte zurechenbare Verlust beträgt 5.00 units. Der vereinfachte Ertrag ist EV(equivocate) = 1.00 + 0.02 - (0.80 * 5.00) = -2.98 units und liegt unter den 0.55 units beim ausschließlichen Signieren von A.

Das Ergebnis ändert sich bei anderer Erkennung, Aufnahme, einziehbarer Sicherheit oder künftigem Einkommen. Tatsächliche Strafen können von effektivem Guthaben, korrelierten Verstößen, Zeit und Protokollzustand abhängen. Betreiber sollten eine Ergebnisverteilung modellieren und den Implementierungspfad prüfen; drei gewählte Zahlen zu multiplizieren beweist keine Anreizkompatibilität eines eingesetzten Systems.

3. Quorumschnitt schützt Sicherheit, kann aber Lebendigkeit gefährden

Betrachte 100 stake units und eine Regel, die mindestens 67 units für eine Finalitätsstimme verlangt. Zwei solche Quoren überschneiden sich um mindestens 67 + 67 - 100 = 34 units. Zwei widersprüchliche Finalisierungen erfordern deshalb, dass mindestens 34 Einheiten an beiden Quorumszertifikaten teilnehmen; ein rechenschaftsfähiges Protokoll kann diese Schnittmenge nachweisbar slashbar machen.

Derselbe Schwellenwert hat eine andere Auswirkung auf die Lebendigkeit. Halten 34 units gültige Stimmen zurück, bleiben nur 66 units und damit weniger als 67; die Finalität kann aussetzen. Diese 34 Einheiten allein finalisieren keine zwei Zweige. Sicherheitsversagen, zurechenbare Beweise und fehlender Fortschritt dürfen nicht als dasselbe Ereignis beschrieben werden.

4. Alte Schlüssel schaffen ein anderes Synchronisationsproblem

Angenommen, ein Online-Knoten hat Checkpoint epoch 39,900 finalisiert, während ein neuer Knoten keinen vertrauenswürdigen Zustand besitzt. Ein Angreifer erlangt Schlüssel, die um epoch 10,000 genügend Stake kontrollierten, nachdem diese Validatoren ausgeschieden und ihre Sicherheiten nicht mehr erreichbar sind, und erzeugt einen Alternativverlauf bis epoch 40,000. Billige historische Signaturen sind relevant, doch das Slashing heutiger Validatoren schreckt diese alten Schlüssel möglicherweise nicht mehr ab.

Der Online-Knoten lehnt einen Verlauf ab, der seiner finalisierten Sicht widerspricht. Der neue Knoten benötigt einen aktuellen authentifizierten Checkpoint oder eine gleichwertige Protokollregel, um die Verläufe zu unterscheiden, bevor die objektive Prüfung fortgesetzt werden kann. Deshalb gehören Weak Subjectivity und Auszahlungszeitpunkt in die Prüfung, bleiben aber analytisch von der Live-Äquivokation gebundener Validatoren getrennt.

Risiken und Prüfungsfehler

Protokoll- und Beweisfehler

  • Jede Stimme für einen nicht kanonischen Fork als slashbar bezeichnen, ohne die genauen signierten Felder und Domänen zu prüfen.
  • Fork, Reorganisation, verpassten Vorschlag, verspätete Stimme und nachweisbare Äquivokation als austauschbare Ereignisse behandeln.
  • Ethereums Proposer- und Attester-Bedingungen auf ein Protokoll mit anderen Nachrichten oder Finalitätsregeln anwenden.
  • Beim Vergleich vermeintlich widersprüchlicher Signaturen Kettenidentität, Fork-Version, Epoch oder Slot auslassen.
  • Annehmen, zwei Signaturen allein bewiesen einen Verstoß, ohne Validatoridentität, Domänen, Abstammung und gültige Kryptografie.
  • Einfluss auf die Fork-Wahl mit Rechtfertigung, Finalisierung oder Abwicklung auf Anwendungsebene verwechseln.
  • Einen Sicherheitssatz ohne seine Annahmen zu Synchronität, Ehrlichkeit, Verfügbarkeit und Gegner lesen.

Anreiz- und Durchsetzungsfehler

  • Signaturen als billig bezeichnen, ohne gebundenen Verlust, entgangene Belohnungen und künftiges Einkommen einzupreisen.
  • Maximales nominelles Slashing in jedem Zustand als erwarteten einziehbaren Verlust behandeln.
  • Annehmen, Beweise würden vor der Auszahlung stets beobachtet, verbreitet, aufgenommen und verarbeitet.
  • Proposer-Zensur, Netzwerkpartitionen, Eclipse-Isolation und Ablauf des Beweisfensters ignorieren.
  • Einen beispielhaften Erwartungswert als Beweis nutzen, obwohl Wahrscheinlichkeiten, Bestechungen und Verluste ungemessen sind.
  • Korrelationsstrafen, Tokenpreisbewegungen, Absicherungen, externe Bestechungen und Angreifergewinn ignorieren.
  • Annehmen, der alte Schlüssel eines ausgeschiedenen Validators sei weiterhin durch aktuell slashbare Sicherheit gedeckt.

Betriebs-, Konzentrations- und Wiederherstellungsfehler

  • Denselben Signaturschlüssel auf Failover-Knoten ohne dauerhaften gemeinsamen Slashing-Schutz betreiben.
  • Signer oder Slashing-Datenbank aus veralteten Sicherungen wiederherstellen und bereits signierte Konflikte erneut erzeugen.
  • Validatorschlüssel trotz gemeinsamer Verwahrung, Client-, Cloud- oder Governance-Kontrolle als unabhängige Betreiber zählen.
  • Annehmen, delegierende Staker trügen keine Verluste durch Betreiber, Pool oder Restaking-Abhängigkeit.
  • Bei der Wiederherstellung eines lange inaktiven Knotens nur einem Explorer, Anbieter oder mitgelieferten Checkpoint vertrauen.
  • Hohe Staking-Beteiligung allein als Sicherheitsbeweis ausgeben, ohne Stakeverteilung, Schwellenwert und Kontrolle zu analysieren.

Häufige Missverständnisse

  • Bei Proof of Stake steht buchstäblich nichts auf dem Spiel. Gut konstruierte Systeme können gebundenes Kapital, Belohnungen und künftige Teilnahme Verlusten aussetzen; entscheidend ist, ob diese Kosten für die relevante Abweichung ausreichend und durchsetzbar sind.
  • Jede Validatornachricht auf zwei Forks ist eine Doppelabstimmung. Slashbarkeit hängt von Nachrichtenfeldern, Domänen und Konfliktregeln des Protokolls ab; ehrliche Fork-Wahl-Aktualisierungen benötigen Spielraum.
  • Slashing garantiert Konsens. Slashing schafft Rechenschaft und Anreize, aber Sicherheit und Lebendigkeit hängen auch von Schwellenwerten, Netzwerk, Implementierungen, Schlüsselsicherheit und Annahmen zu ehrlichem Verhalten ab.
  • Ein Drittel des Stakes kann allein zwei Zweige finalisieren. In einem Zwei-Drittel-Finalitätsdesign kann ungefähr ein Drittel häufig den Fortschritt stoppen; widersprüchliche Finalität erfordert überlappende Supermehrheiten und slashbare Teilnahme ihrer Schnittmenge.
  • Nothing at Stake und Long-Range-Angriffe sind identisch. Beide nutzen billige Signaturen, doch das eine betrifft Live-Unterstützung konkurrierender Zweige, während das andere alte Schlüssel gegen Knoten ohne aktuellen vertrauenswürdigen Zustand einsetzen kann.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...