Zum Inhalt springen
Financial Context Wiki

Nachweis der Geschichte: Aufgezeichnete Reihenfolge, Ticks, Slots und Konsensgrenzen

Proof of History ist die sequentielle Hash-Chain-Uhr von Solana: Sie macht die aufgezeichnete Reihenfolge und Berechnungszahlen eines Produzenten überprüfbar, beweist aber nicht unabhängig die Uhrzeit, die Reihenfolge der fairen Transaktionsankunft, die Auswahl der Fork oder die Endgültigkeit.

Aktualisiert

Nur zur Schulung in der Protokollanalyse; keine Anlage-, Validatorbetriebs-, Leistungs- oder Sicherheitsberatung. Proof-of-History-Parameter, Clientverhalten, Leader-Zeitplanung, Abstimmung, Fork-Wahl und Bestätigungsregeln können sich je nach Netzwerk und Softwareversion ändern.

Direkte Antwort

Proof of History oder PoH ist die kryptografische Uhr- und Ledger-Reihenfolge-Datenstruktur von Solana. Ein Produzent wendet wiederholt eine Hash-Funktion an, sodass jede Ausgabe von der vorherigen Ausgabe abhängt, erfasst regelmäßig Zählungen und Zustände und mischt von Transaktionen abgeleitete Daten in die Kette. Ein Prüfer kann diese Übergänge neu berechnen und die von dieser bestimmten Kette aufgezeichnete Reihenfolge bestätigen.

PoH ist kein eigenständiger Konsensalgorithmus. Es wählt nicht die kanonische Abzweigung, stellt keine anteilsgewichtete Vereinbarung bereit, schließt Blöcke nicht ab und beweist nicht, dass eine Transaktion das Netzwerk zu einem bestimmten Zeitpunkt erreicht hat. Solana kombiniert die Uhr mit geplanten Leitern, Transaktionsausführung, Validator-Abstimmungen, Fork-Auswahl und Sperren im Tower BFT-Stil. Zwei Forks können jeweils intern gültige PoH-Sequenzen enthalten; Konsensregeln bestimmen, welcher Geschichte das Netzwerk folgt.

Der Umfang dieser Garantie ist begrenzt. Schreibt ein Eintrag die Daten d nach Zustand h2 fest, kann der spätere Zustand h3 = H(h2 || d) ohne diese Festschreibung nicht berechnet werden. Das zeigt, dass der Erzeuger d vor h3 kannte, und fixiert die aufgezeichnete Position relativ zu späteren Ausgaben. Es zeigt weder den Empfangszeitpunkt jedes Validators noch eine faire Ankunftsreihenfolge, die Wahrheit externer Daten oder den kanonischen Status des Eintrags.

Die Generierung erfolgt sequentiell, da die nächste Eingabe erst bekannt ist, wenn der vorherige Hash vorhanden ist. Veröffentlichte Grenzzustände ermöglichen es Verifizierern, separate begrenzte Segmente parallel wiederzugeben, die aggregierte Hash-Arbeit bleibt jedoch bestehen. Aus diesem Grund wird PoH oft mit einer überprüfbaren Verzögerungsfunktion verglichen, während Solana in seiner eigenen Tower BFT-Erklärung von einer lockeren Verwendung dieses Begriffs spricht; Ein formaler VDF verfügt normalerweise über eine Evaluierungs- und Verifizierungsschnittstelle, deren Verifizierung im Vergleich zur sequentiellen Evaluierung effizient ist.

So analysieren Sie den Proof of History

  1. Fixieren Sie den Netzwerk- und Softwarekontext. Zeichnen Sie Netzwerk, Genesis-Hash, Slot, Epoche, Agave oder eine andere Clientversion und Beobachtung auf Zeit. Aktive Werte wie hashes_per_tick, ticks_per_slot und ns_per_slot lesen; Importieren Sie keine Konstanten aus einem alten Artikel oder einem anderen Cluster.
  2. Rekonstruieren Sie die Hash-Kette. Beginnen Sie mit einem vertrauenswürdigen Vorgängerstatus und überprüfen Sie den num_hashes jedes Eintrags, den resultierenden Hash und die Transaktionsliste. In der Eintragsimplementierung von Agave hängt eine Eintragskennung vom vorherigen Eintrag ab und, wenn Transaktionen vorhanden sind, von einem aus deren Signaturen abgeleiteten Hash.
  3. Ticks und Slot-Platzierung validieren. Tick-Einträge, erwartete Hash-Anzahl, Tick-Höhe und maximale Tick-Höhe anhand der Bank- und Rekorderregeln prüfen. Der Rekorder ordnet die Tick-Höhe mithilfe des konfigurierten ticks_per_slot einem Schlitz zu; Slots sind Protokollintervalle, keine unabhängigen Beweise von einer externen Uhr.
  4. Unterscheiden Sie Einbeziehung von Ankunft. Eine Verpflichtung beweist, dass die Eingabe spätestens bei ihrer Einfügung in diese Sequenz bekannt war. Um eine Untergrenze zu beanspruchen, identifizieren Sie einen signierten Rückverweis auf einen früheren PoH-Zustand. Keine der Grenzen beweist die globale Erstreihenfolge, Mempool-Fairness oder einen vertrauenswürdigen UTC-Zeitstempel.
  5. Generierung von der Überprüfung trennen. Messen Sie die sequentielle Produktion auf einer Abhängigkeitskette und messen Sie dann die Wiedergabe mithilfe authentifizierter Segmentgrenzen und verfügbarer Kerne. Melden Sie Gesamt-Hashes, Latenz des kritischen Pfads, aggregierte Überprüfungsarbeit und Grenzdatenannahmen, anstatt nur zu sagen, dass die Überprüfung „schnell“ ist.
  6. Verfolgen Sie den Konsenspfad. Identifizieren Sie den geplanten Leiter, den Bankstatus, Stimmen, Aussperrungen, die Fork-Choice-Regel, den verwurzelten oder endgültigen Status und die Verpflichtungsebene. Eine gültige PoH-Kette kann immer noch zu einem verlierenden Fork gehören, und ein länger aussehender Zähler allein ist kein Konsenszertifikat.
  7. Stress kontroverser und operativer Fälle. Testleiter-Zweideutigkeit, Auslassung und Neuordnung von Transaktionen, übersprungene Slots, Partitionen, schnellere oder falsch kalibrierte Hardware, ungültige Tick-Zählungen, verzögerte Wiedergabe, Ledger Nichtverfügbarkeit, Client-Divergenz und korrelierte Betreiber- oder Infrastrukturkontrolle.

Die Überprüfungsausgabe sollte vier Ansprüche unterscheiden: Sequenzgültigkeit, konfigurierte Protokollzeit, Konsensstatus und externe Zeit. Geben Sie an, welche Start-Hash- und Ledger-Daten vertrauenswürdig waren, welche Hashes neu berechnet wurden, welche Abstimmungs- oder Verpflichtungsnachweise überprüft wurden und welche Beobachtungen von lokalen Uhren oder Drittanbieterdiensten stammten.

Arbeitsbeispiele

1. Dateneinfügung korrigiert eine aufgezeichnete Position

Betrachten Sie h1 = H(h0) und dann h2 = H(h1). Ein Produzent fügt eine von der Transaktion abgeleitete Verpflichtung d ein und berechnet h3 = H(h2 || d), gefolgt von h4 = H(h3). Jeder, der dieselben Vorgänge wiederholt, kann überprüfen, ob die aufgezeichnete Kette d zwischen h2 und h3 festschreibt und dass h4 vom Ergebnis abhängt.

Die Obergrenzenanweisung ist eng: Der Produzent kannte d, bevor er h3 berechnete. Wenn die signierte Transaktion selbst auf h1 verweist, kann ein Prüfer vorbehaltlich der Signatur- und Herkunftsprüfungen auch nachweisen, dass sie nach Kenntnis dieses früheren Zustands erstellt wurde. Ohne eine solche Rückreferenz liefert PoH allein keine Untergrenze. Keiner der Fälle beweist, wann ein anderer Knoten die Transaktion zum ersten Mal empfangen hat.

2. Segmentwiedergabe reduziert die Latenz, nicht die Gesamtarbeit

Angenommen, ein aufgezeichnetes Intervall enthält 1.000.000 Hashes und authentifizierte Prüfpunkte teilen es in 10 Segmente mit 100.000 Hashes auf. Mit ausreichend Kernen können zehn Segmente gleichzeitig wiedergegeben werden, sodass die Latenzzeit der Wall-Clock-Verifizierung der Dauer eines Segments plus Overhead nahe kommen kann.

Die Verifizierer führen zusammen immer noch 1.000.000 Hashes aus; Die Prüfpunkte legen unabhängige Startzustände offen, verwandeln die Kette jedoch nicht in einen prägnanten Beweis. Die Leistung hängt von der Hardware, der Planung, der Speicherbewegung und dem Vertrauen in die Grenzen ab. Aus diesem Grund sollte eine parallele PoH-Wiedergabe nicht automatisch als effizienter Verifizierungsalgorithmus jeder formalen VDF-Konstruktion beschrieben werden.

3. Tick- und Slot-Arithmetik ist konfigurationsabhängig

Gehen Sie von einer beispielhaften Konfiguration mit hashes_per_tick = 100,000 und ticks_per_slot = 8 aus. Ein vollständig gehashter Slot enthält dann 100,000 * 8 = 800,000-Hashes mit Tick-Grenzen nach jedem konfigurierten Intervall. Wenn Sie einen der Parameter ändern, ändert sich die Zuordnung. Dieses Beispiel ist keine aktuelle Mainnet-Konstante.

Agave unterstützt auch Konfigurationen, die sich nicht durch diese vereinfachte Multiplikation beschreiben lassen. Ein Prüfer sollte die tatsächlichen Bank-Felder abrufen und die Einträge nach den Client-Regeln validieren. Die Umrechnung eines Slots oder Zählwerts in Sekunden hängt außerdem von der Kalibrierung der Zieldauer und der beobachteten Ausführung ab, nicht nur von kryptografischer Prüfung.

4. Aufgezeichnete Reihenfolge ist nicht Ankunftsreihenfolge oder Endgültigkeit

Angenommen, Transaktion A erreicht einen Anführer vor Transaktion B, aber der Anführer zeichnet B nahe der Zählung 300.000 und A nahe der Zählung 450.000 auf. Gültiger PoH beweist, dass B in dieser erzeugten Sequenz vor A steht. Es beweist nicht, dass B zuerst ankam, dass die Anweisung fair war oder dass ein anderer Anführer dieselbe Anweisung befolgte.

Angenommen, eine Partition erzeugt Fork X und Fork Y, jeweils mit einer gültigen Sequenz. Die PoH-Validierung kann fehlerhafte Einträge auf beiden Forks ablehnen, wählt jedoch nicht X oder Y aus. Der Leader-Zeitplan, stake-gewichtete Stimmen, Aussperrungen, die Fork-Wahl und die angeforderte Commitment-Stufe bestimmen das Konsensergebnis; Anwendungen dürfen einen PoH-Zähler nicht durch einen Bestätigungs- oder Endgültigkeitsnachweis ersetzen.

Risiken und Überprüfungsfehler

Kryptografische und Zeitfehler

  • PoH als vertrauenswürdige Wanduhr zu bezeichnen oder einen Hash-Zähler unabhängig zu beanspruchen, beweist einen UTC-Zeitstempel.
  • Die Angabe von Transaktionseinbindung beweist die netzwerkweite Empfangszeit, die erste Reihenfolge oder die Wahrheit externer Daten.
  • Die Annahme einer sequentiellen Generierung verhindert, dass ein Produzent bekannte Daten zurückhält, weglässt oder auswählt, wann er eingefügt werden soll.
  • Die Kollisionsresistenz allein wird als vollständige Grenze für Hardwaregeschwindigkeit, Kalibrierungsdrift oder Implementierungsvarianz behandelt.
  • Beschreibung von Parallelität Segmentwiedergabe als Nullarbeit oder als prägnanter Beweis ohne Zählung aggregierter Hashes.
  • Aufruf von PoH als formaler VDF ohne Angabe der Konstruktion, der Beweisschnittstelle und der Verifizierungsannahmen, die verglichen werden.
  • Vertrauen von Prüfpunktgrenzen, Vorgänger-Hashes oder heruntergeladenen Ledger-Segmenten ohne Authentifizierung ihrer Herkunft.

Konsens- und Protokollfehler

  • PoH-Konsens, Proof of Stake, Tower BFT, Leader-Wahl, Fork-Wahl und Finalität werden als derselbe Mechanismus bezeichnet.
  • Angenommen, die gültige Sequenz mit der höchsten Anzahl muss kanonisch sein, ohne die Stimmen und den Fork-Choice-Status zu prüfen.
  • Behandeln eines lokal wiedergegebenen Eintrags als bestätigt, gerootet oder abgeschlossen, ohne die angeforderte Commitment-Semantik zu überprüfen.
  • Verwenden historischer hashes_per_tick-, ticks_per_slot- oder Slot-Dauerwerte als universelle aktuelle Konstanten.
  • Übersprungene Slots, Leader-Rotation, Partitionen, Mehrdeutigkeiten und Client-Versionsunterschiede werden ignoriert, wenn Rekonstruktion der Reihenfolge.
  • Vergleich der Zählungen von unabhängigen Zweigen oder Startzuständen, als ob sie zu einer authentifizierten Sequenz gehörten.
  • Annahme, der aktuelle Blockhash einer Transaktion sei lediglich ein Zeitstempel und kein Protokollgültigkeitskontext.

Betriebs-, Leistungs- und Kontrollfehler

  • Benchmarking-Hash Generierung allein, während Ausführung, Signaturüberprüfung, Wiedergabe, Bandbreite und Speicher ignoriert werden.
  • Gleichsetzung der theoretischen Segmentparallelität mit dem beobachteten Aufholen des Validators unter CPU, I/O und Speicherkonflikt.
  • Ignorieren von Tick-Validierungsfehlern, Rekorder-Störungen, verzögertem Banking, Ledger-Lücken, Snapshot-Vertrauen und beschädigtem Status.
  • Zählung von Validator-Identitäten als unabhängig, wenn Client, Hosting, Netzwerk, führende Infrastruktur oder Kontrolle werden gemeinsam genutzt.
  • Durch die Annahme einer schnelleren Hardware werden Netzwerklatenz, Paketverlust, Zensur, Denial-of-Service oder Risiko der Einsatzkonzentration beseitigt.
  • Angabe einer Ziel-Slotdauer, einer Durchsatzschätzung oder eines alten Benchmarks als Service-Level-Garantie.

Häufige Missverständnisse

  • PoH ist der vollständige Konsensalgorithmus von Solana. PoH liefert eine überprüfbare aufgezeichnete Sequenz; Validator-Voting, Sperren, Fork-Wahl und andere Konsensregeln entscheiden über den Verlauf, dem das Netzwerk folgt.
  • PoH beweist die genaue reale Zeit jeder Transaktion. Es beweist Abhängigkeit und Anzahl innerhalb einer authentifizierten Sequenz; Die Zuordnung dieser Reihenfolge zur bürgerlichen Zeit erfordert Konfiguration und externe Beobachtungen.
  • PoH garantiert eine faire Transaktionsreihenfolge. Ein Leiter kann Eingaben innerhalb von Protokoll- und Ressourcenbeschränkungen auswählen, verzögern, neu anordnen oder weglassen; PoH macht die resultierende aufgezeichnete Reihenfolge überprüfbar.
  • PoH ist Proof-of-Work-Mining mit einem anderen Namen. Beide verwenden Hashing, aber die Kernaufgabe von PoH ist eine sequentielle Uhr, nicht ein offenes paralleles Rennen, dessen Gewinnerarbeit die wählt Kette.
  • Jede gültige PoH-Sequenz ist endgültig. Konkurrierende Forks können jeweils intern gültig sein; Bestätigung und Endgültigkeit erfordern den Konsensnachweis des Netzwerks.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...