Zum Inhalt springen
Financial Context Wiki

Gültigkeitsnachweis

Ein verifikationsorientierter Leitfaden zu Gültigkeitsnachweisen, öffentlichen Eingaben, Witnesses, Annahmen des Beweissystems, Rollup-Zustandsübergängen, Datenverfügbarkeit, Finalität und Betriebsausfällen.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage- oder Sicherheitsberatung. Ein Gültigkeitsnachweis ist nur so verlässlich wie sein Statement, die Bindung öffentlicher Eingaben, das Beweissystem, der Verifier, der Datenverfügbarkeitspfad, die Verträge, Betreiber, Governance und Settlement-Chain.

Direkte Antwort

Ein Gültigkeitsnachweis ist ein kryptografischer Beleg dafür, dass eine behauptete Berechnung eine präzise definierte Relation erfüllt. Ein Verifier prüft den Beweis anhand eines Verifikationsschlüssels und öffentlicher Eingaben. Bei einem Rollup binden diese Eingaben üblicherweise eine vorherige State Root, eine vorgeschlagene neue State Root und Commitments zu einem Transaktionsbatch. Nach erfolgreicher Prüfung kann der Settlement-Vertrag die neue Root akzeptieren, ohne jede Transaktion erneut auszuführen.

Die Garantie ist enger als „das System ist korrekt“. Sie hängt von solider Kryptografie, dem beabsichtigten Programm oder Circuit, korrekter Kodierung der öffentlichen Eingaben, einem authentischen Verifikationsschlüssel sowie korrekten Verifier- und State-Update-Verträgen ab. Die Prüfung allein beweist weder Datenabruf, Prover-Liveness, Finalität des Settlement-Blocks, eine gutartige Aktualisierung noch einen funktionierenden Auszahlungspfad. Ein Gültigkeitsnachweis kann ein Zero-Knowledge-System verwenden; Gültigkeit allein bedeutet aber keine Privatsphäre.

1
Ausführen

Der Prüfer führt einen Stapel oder eine Berechnung aus und zeichnet den resultierenden Zustandsübergang auf.

Funktionsweise

  1. Exaktes Deployment fixieren: L1- und L2-Chain-IDs, Rollup-Version, State-Update-Vertrag, Verifier-Adresse und Bytecode, Hash des Verifikationsschlüssels, Beweissystem, Circuit- oder Programmversion, Datenverfügbarkeitsmodus, Adminrechte, Pausenstatus und Finalitätsrichtlinie. validity proof ist keine systemübergreifende Spezifikation.
  2. Vor der Interpretation die bewiesene Relation definieren. Kurzform: Unter den Soundness-Annahmen soll Verify(vk, x, proof) = 1 bedeuten, dass ein Witness w mit R(x, w) = 1 existiert. vk ist der Verifikationsschlüssel, x die vollständige öffentliche Eingabe und R das kodierte Regelwerk. Der Beweis gilt nur für diese Relation.
  3. Öffentliche Eingaben unabhängig rekonstruieren. Prüfen, ob die vorherige Root die vom Vertrag akzeptierte Root ist; Batch- oder Daten-Commitment, Chain- und Batch-IDs, nachfolgende Root, Nachrichten- oder Auszahlungs-Roots und Parameter aus kanonischen Daten ableiten. Ein an falsche Chain, Root, Programm oder Batch gebundener Beweis belegt den falschen Claim.
  4. Beweis und Vertragspfad prüfen. Einen kompatiblen unabhängigen Verifier ausführen und danach Onchain-Aufruf, Receipt, Event, akzeptierte Batchnummer und Storage-Änderung untersuchen. Sicherstellen, dass der State-Update-Vertrag den vorgesehenen Verifier aufrief und das Ergebnis nicht über Upgrade oder privilegierten Zweig umging, simulierte oder ersetzte.
  5. Datenverfügbarkeit separat prüfen. Erforderliche Transaktionsdaten, Zustandsdifferenzen, Blob-Sidecars oder vom Komitee attestierte Daten abrufen, Commitments prüfen und Zustandsübergang oder Exit-Witness reproduzieren. Ein gültiger Beweis kann bei nicht verfügbaren Daten bestehen, insbesondere wenn Validium oder externes Komitee Daten offchain hält.
  6. Lebenszykluszustände trennen: erzeugt, eingereicht, inkludiert, Beweis verifiziert, Zustand akzeptiert, Settlement sicher, Settlement finalisiert und Auszahlung abgeschlossen. Proving-Rückstand und Kosten, Sequencer- und Prover-Liveness, L1-Inklusion, Reorgs, Bridge-Verzögerungen, Forced Inclusion und Escape-Verfahren messen, statt alles „final“ zu nennen.
  7. Reproduzierbare Belege sichern: Vertragsadressen und Codehashes, Verifikationsschlüssel- und Programmhashes, vollständige öffentliche Eingaben, Beweisbytes oder dauerhafte Referenz, Batchdaten, Prüfkommando und Softwareversion, Receipt, finalisierte Blockreferenz und erfolgreichen Exit-Test. Nach jedem Upgrade erneut prüfen.

Durchgerechnete Beispiele

  • Batch-Claim. Ein Rollup verarbeitet 8,192 transfers. Der Beweis bindet alte Root R0, neue Root R1 und Batch-Commitment B7. Erfolgreiche Prüfung stützt: „Es existiert ein Witness, der diesen Circuit von R0 nach R1 für B7 erfüllt.“ Sie beweist weder Abrufbarkeit der Bytes von B7, vollständige Sequencer-Inklusion noch Finalität von R1.
  • Rekursive Aggregation. Ein Aggregator prüft 16 child proofs in einem Parent-Circuit und reicht einen Parent-Beweis ein. Besteht er, akzeptiert der Verifier die Aggregationsrelation und gebundenen Child-Commitments. Auditoren müssen dennoch prüfen, ob jedes Child, Reihenfolge und Abbildung öffentlicher Eingaben kontrolliert werden; die Anzahl allein schafft keine Bindung.
  • Hypothetisches Gas-Ledger. Direkte Re-Exekution verbrauche 24,000,000 gas, Beweisprüfung 600,000 gas und erforderliche Datenpublikation 180,000 gas. Der Beweispfad benötigt 600,000 + 180,000 = 780,000 gas, modelliert also eine Reduktion von (24,000,000 - 780,000) / 24,000,000 = 96.75%. Proving-Hardware, Aggregation, fehlgeschlagene Einreichungen, Storage, Bridge und Aufbewahrung fehlen.

Risiken

  • Falsche Chain, Deployment, Batch, Verifier, Verifikationsschlüssel oder Circuit-Version prüfen.
  • Ein solides Beweissystem beweist treu einen unvollständigen oder falschen Circuit.
  • Öffentliche Eingaben lassen Chain-ID, Root, Batch, Nachrichtendomäne oder Parameter aus oder kodieren sie falsch.
  • Fehler in Verifier, Precompile, unsicherer Bibliothek oder inkompatibler Implementierung.
  • Kompromittiertes Setup-Material oder verletzte kryptografische Annahmen.
  • Upgradefähige Verträge oder Governance ersetzen Verifier, Schlüssel, Programm oder Annahmeregel.
  • Privilegierte Umgehungen, Notfallmodi, Pausen oder Allowlists schwächen den Pfad.
  • Fehlerhafte Beweiserzeugung, Nichtdeterminismus oder abweichende Witnesses verschiedener Clients.
  • Prover-Zentralisierung, Zensur, Ausfall, Rückstand oder Hardwarefehler stoppt Updates.
  • Fehlende Transaktionsdaten, Zustandsdifferenzen, Blobs, Preimages oder Archive.
  • Komiteesignaturen oder Daten-Commitment mit aktueller Abrufbarkeit verwechseln.
  • Beweistransaktion aus unsicherem, reorganisiertem oder nichtkanonischem Block akzeptieren.
  • Beweisannahme mit sofortiger Auszahlung oder wirtschaftlicher Finalität verwechseln.
  • Zustandsübergang, Saldo, Nachricht oder Exit-Witness nicht unabhängig reproduzieren.
  • Verifikationsgas, Datengebühren, Beweislatenz, Bridge-Verzögerung oder Recovery-Kosten unterschätzen.
  • Das Modell eines Rollups auf ein anderes Deployment übertragen.

Häufige Irrtümer

  • Ein verifizierter Gültigkeitsnachweis belegt alle Implementierungsdetails und sichtbaren Salden.
  • Jeder Gültigkeitsnachweis ist Zero-Knowledge und verbirgt Transaktionsdaten.
  • Gültigkeitsnachweise beseitigen Datenverfügbarkeits-, Liveness- und Zensurrisiken.
  • Die Prüfung macht die Settlement-Transaktion sofort final und auszahlbar.
  • Ein kleinerer Beweis oder schnellerer Verifier macht das System automatisch sicherer oder billiger.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...