Zum Inhalt springen
Financial Context Wiki

Stake-Grinding-Angriffe: Manipulation der Proof-of-Stake-Zufälligkeit

Bei einem Stake-Grinding-Angriff wird unter zulässigen Schlüsseln, Blöcken oder Zufallsbeiträgen nach einem Ergebnis gesucht, das die künftige Validator-Auswahl verbessert. Lernen Sie Angriffspfade, Suchvorteil und protokollspezifische Abwehr kennen.

Aktualisiert

Nur zur Aufklärung über Protokollsicherheit. Zufälligkeit, Leader-Auswahl, Strafen und Angriffskosten sind protokoll- und versionsspezifisch; prüfen Sie die aktive Spezifikation und Implementierung, bevor Sie Sicherheits- oder Staking-Schlüsse ziehen.

Direkte Antwort

Ein Stake-Grinding-Angriff nutzt Wahlmöglichkeiten, die ein Proof-of-Stake-Teilnehmer hat, bevor die Protokollzufälligkeit feststeht. Er bewertet mehrere gültige Schlüssel, Blockkandidaten oder Zufallsbeiträge und behält beziehungsweise veröffentlicht die Option, die eine künftige Proposer-, Komitee- oder Fork-Auswahl begünstigt. Diese zusätzliche Suche macht aus einer Ziehung mehrere Kandidaten und kann Einfluss über den nominellen Stake-Anteil hinaus verleihen.

Grinding bezeichnet eine Angriffsfamilie, kein universelles Verfahren. Beim Block- oder Seed-Grinding verändert ein Produzent zulässige Blockinhalte oder Vorgänger, wenn der resultierende Hash spätere Zufälligkeit speist. Beim Key Grinding erzeugt er vor der Registrierung viele Schlüssel und behält Identitäten mit günstiger Eignung. Beim Grinding durch selektive Offenlegung hält er Commitment, Reveal, Signatur oder Block zurück oder veröffentlicht sie, nachdem er die Wirkung jeder erlaubten Wahl auf den Seed kennt.

Hash, verifizierbare Zufallsfunktion (VRF) oder Commit-Reveal machen den Gesamtprozess nicht automatisch unverzerrt. Entscheidend ist, wer Eingaben wählt, wann Eignung erkennbar wird, wie viele Alternativen testbar sind, ob ein Abbruch eine weitere Wahl eröffnet und wie lange der Seed von den durch ihn gewählten Leadern getrennt bleibt. Eine belastbare Prüfung muss die genaue Protokollversion untersuchen statt Sicherheit aus dem Namen eines Primitivs abzuleiten.

Angriffs- und Analysepfad

  1. Auswahlregel festhalten. Erfassen Sie Netzwerk, Version, Epoche oder Runde, aktiven Stake-Snapshot, Seed-Ableitung, Eignungstest, Fork Choice sowie Belohnungs- und Strafregeln.
  2. Alle gegnerischen Wahlmöglichkeiten abbilden. Dazu gehören Schlüssel vor der Registrierung, gültige Transaktionsreihenfolgen, optionale Felder, mögliche Elternblöcke, Veröffentlichung, Randomness-Reveals und Abbrüche. Ein Feld ist nur relevant, wenn seine Änderung einen akzeptierten künftigen Zustand oder Seed beeinflusst.
  3. Suchbudget messen. Schätzen Sie Zahl der Kandidaten vor Ablauf der Frist, Unabhängigkeit der Versuche sowie Rechenaufwand, entgangene Belohnungen, Einlagen, Verzögerungen oder slashbare Handlungen je Versuch.
  4. Seed mit künftiger Macht verknüpfen. Bestimmen Sie den Auswahlvorlauf für Proposer oder Komitees, ob der Gegner Ergebnisse vor seiner Bindung kennt und ob eine günstige Auswahl eine neue Grinding-Chance schafft.
  5. Akzeptanz und Verstärkung bewerten. Jeder Kandidat muss Zustandsübergang, Zeit-, Signatur- und Fork-Choice-Regeln erfüllen. Modellieren Sie wiederholten Einfluss zustandsbehaftet; übertragen Sie keine Einrundenwahrscheinlichkeit unter einer falschen Unabhängigkeitsannahme.
  6. Jede Abwehr gegen jede Wahl testen. Verzögerte Seeds, VRFs, Schlüsselregistrierung, Strafen, Threshold-Beacons und verifizierbare Verzögerungsfunktionen adressieren verschiedene Fähigkeiten und bringen eigene Verfügbarkeits- und Implementierungsannahmen mit.

Das Beweispaket sollte Kandidatenblöcke oder Commitments, genaue Hashes und Domänen, Zeitdaten, Stake-Snapshots, die implementierte Seed-Berechnung und kontrafaktische Auswahlresultate enthalten. Eine Proposer-Serie allein ist kein Beweis, da ehrliche stakegewichtete Lotterien natürliche Häufungen erzeugen.

Ausgearbeitetes Beispiel

Angenommen, ein vereinfachtes Protokoll gibt einem Angreifer 10% Wahrscheinlichkeit, nächster Proposer zu sein. Bei nur einem festen Seed beträgt seine Auswahlwahrscheinlichkeit 0.10. Ein Fehler erlaube ihm nun, 20 unabhängige, gleich gültige Kandidaten-Seeds fast kostenlos zu prüfen und einen davon zu veröffentlichen.

Die Wahrscheinlichkeit, dass mindestens ein Kandidat den Angreifer auswählt, beträgt 1 - (1 - 0.10)^20, also ungefähr 87.8%. Der Angreifer besitzt deshalb nicht 87.8% des Stakes; das Protokoll hat ihm versehentlich 20 Ziehungen und die Auswahl nach Sichtung der Ergebnisse gewährt.

Die Rechnung ist eine abstrakte Illustration, keine Prognose für eine eingesetzte Chain. Resultate können korreliert sein, Fristen Versuche begrenzen, Varianten Gebühren oder Belohnungen kosten, Zurückhalten kann bestraft werden und die nächste Proposer-Rolle muss keinen dauerhaften Fork-Choice-Einfluss schaffen. Diese Grenzen sind vor einer wirtschaftlichen oder konsensbezogenen Bewertung zu messen.

Abwehr und Prüfliste

Konstruktion der Zufälligkeit

  • Leiten Sie Auswahlzufälligkeit aus Eingaben ab, die feststanden, bevor betroffene Teilnehmer die resultierenden Zuweisungen kennen oder steuern konnten.
  • Trennen Sie Beitrag, Commitment, Reveal und Verwendung zeitlich so weit, dass der aktuelle Leader den Seed seines direkten Nachfolgers nicht günstig durchsuchen kann.
  • Berücksichtigen Sie den letzten Revealer: Commit-Reveal bleibt verzerrbar, wenn das Zurückhalten einem Teilnehmer eine Wahl zwischen Ergebnissen gibt.
  • Nutzen Sie Threshold- oder verteilte Beacons nur mit expliziten Annahmen zu ehrlicher Teilnahme, Liveness, Wiederherstellung und Mitgliederwechsel.

Eignung und Identität

  • Binden Sie VRF-Schlüssel und Stake an einen Registrierungs-Snapshot, bevor der relevante Seed bekannt ist; andernfalls kann Offline-Schlüsselerzeugung zu Key Grinding werden.
  • Trennen Sie Randomness-Domänen nach Chain, Version, Runde, Rolle und Zweck, damit ein Nachweis nicht kontextübergreifend wiederverwendet wird.
  • Bevorzugen Sie gegebenenfalls private Eignung, aber beachten Sie: Private Leader-Wahl mindert vorzeitige Zielangriffe, repariert jedoch keine verzerrte Seed-Erzeugung.
  • Begrenzen Sie günstigen Identitätswechsel und definieren Sie, wie delegierter Stake, Pools und wechselnde Validator-Mengen in die Lotterie eingehen.

Ökonomie und Betrieb

  • Bepreisen Sie verpasste Blöcke, verlorene Belohnungen, gebundenes Kapital, erkennbare Equivocation und korrelierte Strafen; nicht jede legale Wahl ist slashbar.
  • Überwachen Sie Seed-Beiträge, fehlende Reveals, ungewöhnliche Kandidatenerzeugung, Proposer-Häufigkeit und Softwarevielfalt über statistisch aussagekräftige Zeiträume.
  • Halten Sie konsenskritische Zufälligkeit von diskretionären Builder-, Relay- oder Transaktionssortier-Schnittstellen fern, sofern deren Harmlosigkeit nicht spezifiziert ist.
  • Testen Sie Rückfallverhalten. Ein nur bei Antwort aller Parteien unverzerrter Mechanismus kann Bias-Resistenz gegen einen Liveness-Ausfall tauschen.

Häufige Irrtümer

  • Hash-Ausgaben sind zufällig, daher ist Grinding unmöglich. Ein Hash kann für eine feste Eingabe unvorhersagbar sein, während ein Teilnehmer aus vielen Eingaben ein verzerrtes Ergebnis auswählt.
  • Eine VRF beseitigt jeden Grinding-Angriff. Sie beweist eine Ausgabe für Schlüssel und Eingabe; Schlüsselerzeugung, Seed-Kontrolle, Registrierungszeitpunkt und selektive Veröffentlichung bleiben eigene Fragen.
  • Commit-Reveal-Zufälligkeit ist automatisch unverzerrt. Ohne Neutralisierung oder Preis des Abbruchs kann der letzte Teilnehmer zwischen Reveal und Abbruch wählen.
  • Grinding erfordert Mehrheits-Stake. Auch eine Minderheit kann mit mehreren günstigen Versuchen übermäßige Auswahlchancen gewinnen; für ein Sicherheitsversagen sind jedoch weitere protokollspezifische Bedingungen nötig.
  • Viele aufeinanderfolgende Vorschläge beweisen Manipulation. Zufällige Leader-Wahl erzeugt Serien. Erkennung erfordert ein vorab definiertes Statistikmodell sowie Protokoll- und Implementierungsbelege.
  • Grinding und Nothing at Stake sind dasselbe. Grinding verzerrt Zufälligkeit oder Eignung; Nothing at Stake betrifft Anreize zur Unterstützung konkurrierender Historien. Beides kann interagieren, bleibt aber analytisch verschieden.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...