Datenverfügbarkeit

"Vertraue nicht, verifiziere" (Don't trust, verify) ist eine gängige Maxime bei Ethereum. Die Idee dahinter ist, dass Ihr Knoten unabhängig verifizieren kann, dass die empfangenen Informationen korrekt sind, indem er alle Transaktionen in den Blöcken ausführt, die er von Peers erhält. So wird sichergestellt, dass die vorgeschlagenen Änderungen exakt mit denen übereinstimmen, die der Knoten unabhängig berechnet hat. Das bedeutet, dass Knoten nicht darauf vertrauen müssen, dass die Sender des Blocks ehrlich sind. Dies ist nicht möglich, wenn Daten fehlen.

Datenverfügbarkeit bezieht sich auf die Gewissheit, die ein Benutzer haben kann, dass die zur Verifizierung eines Blocks erforderlichen Daten wirklich für alle Netzwerkteilnehmer verfügbar sind. Für Full Nodes auf Ethereum Layer 1 (L1) ist dies relativ einfach; der Full Node lädt eine Kopie aller Daten in jedem Block herunter – die Daten müssen verfügbar sein, damit das Herunterladen möglich ist. Ein Block mit fehlenden Daten würde verworfen und nicht zur Blockchain hinzugefügt werden. Dies ist "Onchain-Datenverfügbarkeit" und ein Merkmal monolithischer Blockchains. Full Nodes können nicht dazu verleitet werden, ungültige Transaktionen zu akzeptieren, da sie jede Transaktion selbst herunterladen und ausführen. Für modulare Blockchains, Layer-2-Rollups und Light-Clients ist die Landschaft der Datenverfügbarkeit jedoch komplexer und erfordert ausgefeiltere Verifizierungsverfahren.

Voraussetzungen

Sie sollten ein gutes Verständnis der Blockchain-Grundlagen haben, insbesondere der Konsensmechanismen. Diese Seite setzt außerdem voraus, dass der Leser mit Blöcken, Transaktionen, Knoten, Skalierungslösungen und anderen relevanten Themen vertraut ist.

Das Problem der Datenverfügbarkeit

Das Problem der Datenverfügbarkeit besteht in der Notwendigkeit, dem gesamten Netzwerk zu beweisen, dass die zusammengefasste Form einiger Transaktionsdaten, die der Blockchain hinzugefügt werden, wirklich eine Menge gültiger Transaktionen darstellt, ohne jedoch zu verlangen, dass alle Knoten alle Daten herunterladen. Die vollständigen Transaktionsdaten sind für die unabhängige Verifizierung von Blöcken erforderlich, aber die Anforderung, dass alle Knoten alle Transaktionsdaten herunterladen, ist ein Hindernis für die Skalierung. Lösungen für das Problem der Datenverfügbarkeit zielen darauf ab, ausreichende Zusicherungen zu geben, dass die vollständigen Transaktionsdaten den Netzwerkteilnehmern, die die Daten nicht selbst herunterladen und speichern, zur Verifizierung zur Verfügung gestellt wurden.

Light Nodes und Layer-2-Rollups sind wichtige Beispiele für Netzwerkteilnehmer, die starke Zusicherungen der Datenverfügbarkeit benötigen, aber Transaktionsdaten nicht selbst herunterladen und verarbeiten können. Das Vermeiden des Herunterladens von Transaktionsdaten macht Light Nodes erst "light" (leicht) und ermöglicht es Rollups, effektive Skalierungslösungen zu sein.

Datenverfügbarkeit ist auch ein kritisches Anliegen für zukünftige "zustandslose" (stateless) Ethereum-Clients, die keine Zustandsdaten herunterladen und speichern müssen, um Blöcke zu verifizieren. Die zustandslosen Clients müssen dennoch sicher sein, dass die Daten irgendwo verfügbar sind und korrekt verarbeitet wurden.

Lösungen für die Datenverfügbarkeit

Data Availability Sampling (DAS)

Data Availability Sampling (DAS) ist eine Möglichkeit für das Netzwerk, zu überprüfen, ob Daten verfügbar sind, ohne einen einzelnen Knoten zu sehr zu belasten. Jeder Knoten (einschließlich Non-Staking-Knoten) lädt eine kleine, zufällig ausgewählte Teilmenge der Gesamtdaten herunter. Das erfolgreiche Herunterladen der Stichproben bestätigt mit hoher Wahrscheinlichkeit, dass alle Daten verfügbar sind. Dies beruht auf der Löschcodierung (Erasure Coding) von Daten, die einen bestimmten Datensatz um redundante Informationen erweitert (dies geschieht, indem eine als Polynom bekannte Funktion über die Daten gelegt und dieses Polynom an zusätzlichen Punkten ausgewertet wird). Dadurch können die Originaldaten bei Bedarf aus den redundanten Daten wiederhergestellt werden. Eine Konsequenz dieser Datenerstellung ist, dass, wenn irgendwelche der Originaldaten nicht verfügbar sind, die Hälfte der erweiterten Daten fehlt! Die Menge der von jedem Knoten heruntergeladenen Datenstichproben kann so abgestimmt werden, dass es äußerst wahrscheinlich ist, dass mindestens eines der von jedem Client abgetasteten Datenfragmente fehlt, wenn weniger als die Hälfte der Daten wirklich verfügbar ist.

DAS wird verwendet, um sicherzustellen, dass Rollup-Betreiber ihre Transaktionsdaten verfügbar machen, nachdem Full Danksharding implementiert wurde. Ethereum-Knoten werden die in Blobs bereitgestellten Transaktionsdaten mithilfe des oben erläuterten Redundanzschemas zufällig abtasten, um sicherzustellen, dass alle Daten vorhanden sind. Dieselbe Technik könnte auch eingesetzt werden, um sicherzustellen, dass Blockproduzenten alle ihre Daten zur Verfügung stellen, um Light-Clients abzusichern. In ähnlicher Weise wäre bei der Proposer-Builder-Trennung (PBS) nur der Block-Builder verpflichtet, einen gesamten Block zu verarbeiten – andere Validatoren würden mithilfe von Data Availability Sampling verifizieren.

Data Availability Committees (DACs)

Data Availability Committees (DACs) sind vertrauenswürdige Parteien, die Datenverfügbarkeit bereitstellen oder bescheinigen. DACs können anstelle von oder in Kombination mit (opens in a new tab) DAS verwendet werden. Die Sicherheitsgarantien, die mit Komitees einhergehen, hängen von der spezifischen Einrichtung ab. Ethereum verwendet beispielsweise zufällig ausgewählte Teilmengen von Validatoren, um die Datenverfügbarkeit für Light Nodes zu bescheinigen.

DACs werden auch von einigen Validiums verwendet. Das DAC ist eine vertrauenswürdige Gruppe von Knoten, die Kopien von Daten offline speichert. Das DAC ist verpflichtet, die Daten im Falle eines Streits zur Verfügung zu stellen. Mitglieder des DAC veröffentlichen auch Onchain-Bescheinigungen, um zu beweisen, dass die besagten Daten tatsächlich verfügbar sind. Einige Validiums ersetzen DACs durch ein Proof-of-Stake (PoS)-Validator-System. Hier kann jeder ein Validator werden und Daten offchain speichern. Sie müssen jedoch eine "Kaution" (Bond) hinterlegen, die in einem Smart Contract deponiert wird. Im Falle von böswilligem Verhalten, wie z. B. dem Zurückhalten von Daten durch den Validator, kann die Kaution einem Slashing unterzogen werden. Proof-of-Stake-Datenverfügbarkeitskomitees sind wesentlich sicherer als reguläre DACs, da sie ehrliches Verhalten direkt incentivieren.

Datenverfügbarkeit und Light Nodes

Light Nodes müssen die Korrektheit der empfangenen Block-Header validieren, ohne die Blockdaten herunterzuladen. Der Preis für diese Leichtigkeit ist die Unfähigkeit, die Block-Header unabhängig zu verifizieren, indem Transaktionen lokal so ausgeführt werden, wie es Full Nodes tun.

Ethereum-Light-Nodes vertrauen zufälligen Gruppen von 512 Validatoren, die einem Sync-Komitee zugewiesen wurden. Das Sync-Komitee fungiert als DAC, das Light-Clients mithilfe einer kryptografischen Signatur signalisiert, dass die Daten im Header korrekt sind. Jeden Tag wird das Sync-Komitee aktualisiert. Jeder Block-Header weist Light Nodes darauf hin, welche Validatoren voraussichtlich den nächsten Block absegnen werden, sodass sie nicht dazu verleitet werden können, einer böswilligen Gruppe zu vertrauen, die vorgibt, das echte Sync-Komitee zu sein.

Was passiert jedoch, wenn es einem Angreifer irgendwie doch gelingt, einen bösartigen Block-Header an Light-Clients weiterzugeben und sie davon zu überzeugen, dass er von einem ehrlichen Sync-Komitee abgesegnet wurde? In diesem Fall könnte der Angreifer ungültige Transaktionen einschließen und der Light-Client würde sie blind akzeptieren, da er nicht alle im Block-Header zusammengefassten Zustandsänderungen unabhängig überprüft. Um sich davor zu schützen, könnte der Light-Client Betrugsnachweise (Fraud Proofs) verwenden.

Diese Betrugsnachweise funktionieren so, dass ein Full Node, der sieht, wie ein ungültiger Zustandsübergang im Netzwerk verbreitet wird, schnell ein kleines Datenstück generieren könnte, das zeigt, dass ein vorgeschlagener Zustandsübergang unmöglich aus einer bestimmten Menge von Transaktionen resultieren kann, und diese Daten an Peers senden könnte. Light Nodes könnten diese Betrugsnachweise aufgreifen und sie verwenden, um schlechte Block-Header zu verwerfen, um sicherzustellen, dass sie auf derselben ehrlichen Chain bleiben wie die Full Nodes.

Dies setzt voraus, dass Full Nodes Zugriff auf die vollständigen Transaktionsdaten haben. Ein Angreifer, der einen schlechten Block-Header sendet und es außerdem versäumt, die Transaktionsdaten verfügbar zu machen, könnte Full Nodes daran hindern, Betrugsnachweise zu generieren. Die Full Nodes könnten zwar eine Warnung vor einem schlechten Block signalisieren, aber sie könnten ihre Warnung nicht mit einem Beweis untermauern, da die Daten nicht zur Verfügung gestellt wurden, um den Beweis daraus zu generieren!

Die Lösung für dieses Problem der Datenverfügbarkeit ist DAS. Light Nodes laden sehr kleine zufällige Blöcke der vollständigen Zustandsdaten herunter und verwenden die Stichproben, um zu überprüfen, ob der vollständige Datensatz verfügbar ist. Die tatsächliche Wahrscheinlichkeit, nach dem Herunterladen von N zufälligen Blöcken fälschlicherweise von einer vollständigen Datenverfügbarkeit auszugehen, kann berechnet werden (bei 100 Blöcken beträgt die Wahrscheinlichkeit 10^-30 (opens in a new tab), d. h. unglaublich unwahrscheinlich).

Selbst in diesem Szenario könnten Angriffe, die nur wenige Bytes zurückhalten, von Clients, die zufällige Datenanfragen stellen, unbemerkt bleiben. Löschcodierung behebt dies, indem kleine fehlende Datenstücke rekonstruiert werden, die zur Überprüfung vorgeschlagener Zustandsänderungen verwendet werden können. Ein Betrugsnachweis könnte dann unter Verwendung der rekonstruierten Daten erstellt werden, was verhindert, dass Light Nodes schlechte Header akzeptieren.

Hinweis: DAS und Betrugsnachweise wurden noch nicht für Proof-of-Stake-Ethereum-Light-Clients implementiert, stehen aber auf der Roadmap und werden höchstwahrscheinlich die Form von ZK-SNARK-basierten Beweisen annehmen. Heutige Light-Clients verlassen sich auf eine Form von DAC: Sie verifizieren die Identitäten des Sync-Komitees und vertrauen dann den signierten Block-Headern, die sie erhalten.

Datenverfügbarkeit und Layer-2-Rollups

Layer-2-Skalierungslösungen, wie z. B. , senken die Transaktionskosten und erhöhen Ethereums Transaktionsdurchsatz, indem sie Transaktionen offchain verarbeiten. Rollup-Transaktionen werden komprimiert und in Batches auf Ethereum gepostet. Batches repräsentieren Tausende einzelner Offchain-Transaktionen in einer einzigen Transaktion auf Ethereum. Dies reduziert die Überlastung auf der Basisschicht und senkt die Gebühren für die Benutzer.

Es ist jedoch nur möglich, den auf Ethereum geposteten "Zusammenfassungs"-Transaktionen zu vertrauen, wenn die vorgeschlagene Zustandsänderung unabhängig verifiziert und als Ergebnis der Anwendung aller einzelnen Offchain-Transaktionen bestätigt werden kann. Wenn Rollup-Betreiber die Transaktionsdaten für diese Verifizierung nicht zur Verfügung stellen, könnten sie falsche Daten an Ethereum senden.

Optimistic Rollups posten komprimierte Transaktionsdaten auf Ethereum und warten eine gewisse Zeit (typischerweise 7 Tage), damit unabhängige Prüfer die Daten überprüfen können. Wenn jemand ein Problem feststellt, kann er einen Betrugsnachweis generieren und ihn verwenden, um das Rollup anzufechten. Dies würde dazu führen, dass die Chain zurückgesetzt wird und den ungültigen Block auslässt. Dies ist nur möglich, wenn Daten verfügbar sind. Derzeit gibt es zwei Möglichkeiten, wie Optimistic Rollups Transaktionsdaten auf L1 posten. Einige Rollups machen Daten dauerhaft als CALLDATA verfügbar, was dauerhaft Onchain verbleibt. Mit der Implementierung von EIP-4844 posten einige Rollups ihre Transaktionsdaten stattdessen in günstigeren Blob-Speicher. Dies ist kein dauerhafter Speicher. Unabhängige Prüfer müssen die Blobs abfragen und ihre Anfechtungen innerhalb von ~18 Tagen vorbringen, bevor die Daten von Ethereum Layer 1 gelöscht werden. Die Datenverfügbarkeit wird vom Ethereum-Protokoll nur für dieses kurze, feste Zeitfenster garantiert. Danach liegt es in der Verantwortung anderer Entitäten im Ethereum-Ökosystem. Jeder Knoten kann die Datenverfügbarkeit mithilfe von DAS verifizieren, d. h. durch Herunterladen kleiner, zufälliger Stichproben der Blob-Daten.

Zero-Knowledge-Rollups (ZK-Rollups) müssen keine Transaktionsdaten posten, da die Korrektheit von Zustandsübergängen garantieren. Die Datenverfügbarkeit ist jedoch immer noch ein Problem, da wir die Funktionalität des ZK-Rollups ohne Zugriff auf seine Zustandsdaten nicht garantieren (oder mit ihm interagieren) können. Beispielsweise können Benutzer ihre Kontostände nicht kennen, wenn ein Betreiber Details über den Zustand des Rollups zurückhält. Außerdem können sie keine Zustandsaktualisierungen mithilfe von Informationen durchführen, die in einem neu hinzugefügten Block enthalten sind.

Datenverfügbarkeit vs. Datenabrufbarkeit

Datenverfügbarkeit unterscheidet sich von Datenabrufbarkeit. Datenverfügbarkeit ist die Zusicherung, dass Full Nodes auf den vollständigen Satz von Transaktionen, die mit einem bestimmten Block verbunden sind, zugreifen und diesen verifizieren konnten. Daraus folgt nicht zwangsläufig, dass die Daten für immer zugänglich sind.

Datenabrufbarkeit ist die Fähigkeit von Knoten, historische Informationen aus der Blockchain abzurufen. Diese historischen Daten werden nicht zur Verifizierung neuer Blöcke benötigt, sie sind nur für die Synchronisierung von Full Nodes ab dem Genesis-Block oder zur Bedienung spezifischer historischer Anfragen erforderlich.

Das Kern-Ethereum-Protokoll befasst sich in erster Linie mit der Datenverfügbarkeit, nicht mit der Datenabrufbarkeit. Die Datenabrufbarkeit kann durch eine kleine Population von Archivknoten bereitgestellt werden, die von Dritten betrieben werden, oder sie kann über das Netzwerk mithilfe dezentraler Dateispeicher wie dem Portal-Netzwerk (opens in a new tab) verteilt werden.