Für alle / Wie es funktioniert
Settlement und Aufzeichnung
Der Inhalt jedes Blocks wird veröffentlicht, in Reihenfolge, Block 0 eingeschlossen, und Ethereum hält immer entweder die Daten oder eine Festschreibung auf Daten, die anderswo verfügbar sind. Das macht die Chain prüfbar statt bloß behauptet.
Zwei Ebenen der Veröffentlichung
| Ebene | Was sie hält |
|---|---|
| Datenverfügbarkeitsschicht | die vollständige Payload, pro Blockinhaltsadressiert, über ihren Hash adressiert; der Sequencer prüft den Digest der Bestätigung, bevor er sich darauf verlässt |
| Ethereum-Inbox | ein kompakter Envelope, der die Payload benennteine Festschreibung pro Planungsziel von 60 s, Blob oder Calldata je nach gemessenen Preisen |
| Rückfallebene | die vollständige Payload als Calldata auf Ethereumgenommen, wann immer der Datenverfügbarkeitspfad ausfällt, damit die Chain durch einen Ausfall hindurch ableitbar bleibt |
Stellen Sie sich einen Laden vor, der jede Quittung in einem Aktenraum aufbewahrt und einmal pro Minute der Bank eine versiegelte Zusammenfassung schickt: "Hier ist der Fingerabdruck der Quittungen, die ich gerade abgelegt habe". Die Bank kann die Quittungen aus dem Fingerabdruck nicht lesen, aber jeder, der in den Aktenraum kommt, kann prüfen, dass nichts verändert wurde. Und wenn der Aktenraum einmal nicht erreichbar ist, schickt der Laden der Bank stattdessen die Quittungen selbst. Der Sequencer von Pickle ist der Laden, die Datenverfügbarkeitsschicht ist der Aktenraum, und Ethereum ist die Bank.
Jeder versiegelte Block erzeugt eine Ableitungs-Payload mit seiner vollständigen Transaktionsliste. Die Payload wird in einer inhaltsadressierten Datenverfügbarkeitsschicht gespeichert, über ihren Hash adressiert, und der Sequencer prüft die Bestätigung, bevor er sich darauf verlässt. Ein kompakter Envelope, der diese Payload benennt, wird dann in einen Inbox-Contract auf Ethereum geschrieben. Fällt der Datenverfügbarkeitspfad aus irgendeinem Grund aus, wird stattdessen die vollständige Payload als Calldata auf Ethereum gesendet.
Jeder Block wird gesendet, in Reihenfolge, Block 0 eingeschlossen. Die Inbox nimmt Anhänge nur vom bestimmten Batcher-Schlüssel an und gibt pro Batch ein indexiertes Event aus; dieser Index ist die Gesamtordnung, der jeder Verifizierer folgt.
Die Payload trägt die vollständige Transaktionsliste des Blocks zusammen mit Blockbereich, Parent-Hash, Block-Hash und festgeschriebenem Zeitstempel; der Zeitstempel ist enthalten, weil er Teil der Ausführungsumgebung ist, nicht nur des Headers, und eine Replika gegen dieselbe Uhr ausführen muss, um denselben Hash zu versiegeln. Die Veröffentlichung ist zweistufig: die Payload in einen inhaltsadressierten Speicher unter ihrem Hash mit Digest-Prüfung bei der Bestätigung, und ein Envelope in die L1-Inbox pro Aggregationsfenster. Die Inbox ist auf den Batcher beschränkt und gibt pro Anhang ein indexiertes Event aus. Das Instrument der Festschreibung, Blob oder Calldata, wird pro Einreichung anhand gemessener Preise gewählt, da bei dieser Payload-Größe bei niedrigen Blob-Gebühren das Ausführungs-Gas dominiert und bei hohen schlichte Calldata gewinnt.
Was eine Payload trägt
- Die vollständige Transaktionsliste des Blocks, sodass nichts am Block vertraut werden muss.
- Blockbereich, Parent-Hash und Block-Hash, sodass die Replika weiß, wo er hingehört und was sie reproduzieren muss.
- Den festgeschriebenen Zeitstempel, denn eine Transaktion, die die Uhr gelesen hat, sah diesen Wert, und eine Replika, die gegen eine andere Uhr ausführt, würde einen anderen Hash versiegeln.
Warum eine Festschreibung pro Fenster
Ethereum erhält nicht eine Transaktion pro versiegeltem Block. Die vollständigen Daten gehen pro Block an die Datenverfügbarkeitsschicht; eine Festschreibung geht pro Aggregationsfenster an Ethereum, bei einem Planungsziel von 60 Sekunden. Die Aggregation ist es, was die modellierten Settlement-Kosten im niedrigen Millionenbereich in Dollar pro Jahr hält statt bei den Dutzenden oder Hunderten Millionen, die ein Design mit einer Sendung pro Block verursachen würde. Die Seite zu den Grenzen nennt die modellierte Spanne und worauf sie beruht.
Unabhängige Verifizierung
Jeder Betreiber kann dasselbe Binary als Replika betreiben. Sie produziert nichts. Sie liest die Ethereum-Inbox ab ihrem zuletzt angewendeten Index, holt jede Payload über ihre Inhaltsadresse oder dekodiert die eingebettete Calldata-Rückfallebene, führt jede Transaktion in Reihenfolge gegen den festgeschriebenen Zeitstempel erneut aus, versiegelt den Block lokal und vergleicht den Hash mit dem, den der Sequencer festgeschrieben hat.
Bei jeder Abweichung hält eine Replika dauerhaft an
Eine Abweichung ist absichtlich endgültig: Ein erneuter Versuch würde weitere Blöcke versiegeln und sich von der kanonischen Chain entfernen und dabei die Ursache verschütten. Eine angehaltene Replika ist das Signal, dass die veröffentlichten Daten und der festgeschriebene Hash nicht übereinstimmen. Nichts on-chain entscheidet über diese Unstimmigkeit; die Seite zum Vertrauensmodell sagt, was daraus folgt.
Eine synchronisierte Replika bedient das standardmäßige Lese-RPC aus ihrem eigenen, unabhängig abgeleiteten Zustand. Ihre Guthaben, Receipts und Header sind lokal neu abgeleitet, keine vertrauten Kopien der Antworten des Sequencers. Die Einreichung von Transaktionen wird an den Sequencer weitergeleitet; eine Replika nimmt nichts in einen lokalen Mempool auf.
Woher die Historie gelesen wird
Der Sequencer ist darauf optimiert, über die Gegenwart Auskunft zu geben, und hält ein kurzes Fenster jüngster Blöcke. Die vollständige Historie wird in die Datenbank des Explorers indexiert, die fortlaufend vom Sequencer gespeist wird und in der alles Historische beantwortet wird. Beide liegen stromabwärts derselben veröffentlichten Payloads, und eine Replika kann beides allein aus Ethereum und der Datenverfügbarkeitsschicht nachbauen.