Datenverfügbarkeit

„Nicht vertrauen, sondern überprüfen“ (Don't trust, verify) ist eine gängige Maxime bei Ethereum. Die Idee dahinter ist, dass Ihr Blockchain-Knoten unabhängig überprüfen kann, ob 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 Blockchain-Knoten unabhängig berechnet hat. Das bedeutet, dass Blockchain-Knoten nicht darauf vertrauen müssen, dass die Sender des Blocks ehrlich sind. Dies ist jedoch nicht möglich, wenn Daten fehlen.

Datenverfügbarkeit bezieht sich auf das Vertrauen, das ein Benutzer haben kann, dass die zur Überprüfung eines Blocks erforderlichen Daten wirklich für alle Netzwerkteilnehmer verfügbar sind. Für vollständige Blockchain-Knoten (Full Nodes) auf Ebene 1 von Ethereum ist dies relativ einfach; der vollständige Blockchain-Knoten 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 die „Datenverfügbarkeit auf der Blockchain“ und ein Merkmal monolithischer Blockchains. Vollständige Blockchain-Knoten können nicht dazu verleitet werden, ungültige Transaktionen zu akzeptieren, da sie jede Transaktion selbst herunterladen und ausführen. Für modulare Blockchains, Ebene-2-Rollups und Light Clients ist die Landschaft der Datenverfügbarkeit jedoch komplexer und erfordert ausgefeiltere Überprüfungsverfahren.

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, Blockchain-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 Blockchain-Knoten alle Daten herunterladen. Die vollständigen Transaktionsdaten sind für die unabhängige Überprüfung von Blöcken erforderlich, aber die Anforderung, dass alle Blockchain-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 bieten, dass die vollständigen Transaktionsdaten den Netzwerkteilnehmern, die die Daten nicht selbst herunterladen und speichern, zur Überprüfung zur Verfügung gestellt wurden.

Light-Knoten und Ebene-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. Die Vermeidung des Herunterladens von Transaktionsdaten macht Light-Knoten 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-Anwendungen, die keine Statusdaten herunterladen und speichern müssen, um Blöcke zu überprüfen. Die zustandslosen Anwendungen 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 Blockchain-Knoten zu sehr zu belasten. Jeder Blockchain-Knoten (einschließlich Nicht-Staking-Knoten) lädt eine kleine, zufällig ausgewählte Teilmenge der Gesamtdaten herunter. Das erfolgreiche Herunterladen der Stichproben bestätigt mit hoher Zuversicht, dass alle Daten verfügbar sind. Dies beruht auf der Daten-Erasure-Coding (Löschcodierung), 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 Blockchain-Knoten heruntergeladenen Datenstichproben kann so eingestellt werden, dass es äußerst wahrscheinlich ist, dass mindestens eines der von jeder Anwendung 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-Blockchain-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 all ihre Daten zur Sicherung von Light Clients zur Verfügung stellen. In ähnlicher Weise müsste unter der Trennung von Block-Vorschlagenden und Block-Erstellern (Proposer-Builder Separation) nur der Block-Ersteller einen gesamten Block verarbeiten – andere Validatoren würden dies mithilfe von Data Availability Sampling überprüfen.

Komitees für Datenverfügbarkeit (Data Availability Committees)

Data Availability Committees (DACs) sind vertrauenswürdige Parteien, die Datenverfügbarkeit bereitstellen oder bestätigen. 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-Knoten zu bestätigen.

DACs werden auch von einigen Validiums verwendet. Das DAC ist eine vertrauenswürdige Gruppe von Blockchain-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 Bestätigungen auf der Blockchain, um zu beweisen, dass die besagten Daten tatsächlich verfügbar sind. Einige Validiums ersetzen DACs durch ein Proof-of-Stake (PoS)-Validatorsystem. Hier kann jeder ein Validator werden und Daten Off-Chain 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-Komitees für Datenverfügbarkeit sind wesentlich sicherer als reguläre DACs, da sie ehrliches Verhalten direkt anreizen.

Datenverfügbarkeit und Light-Knoten

Light-Knoten 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 überprüfen, indem Transaktionen lokal so erneut ausgeführt werden, wie es vollständige Blockchain-Knoten tun.

Ethereum-Light-Knoten 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 warnt Light-Knoten davor, welche Validatoren voraussichtlich den nächsten Block abzeichnen 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 abgezeichnet 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 Statusänderungen unabhängig überprüft. Um sich davor zu schützen, könnte der Light Client Betrugsnachweise verwenden.

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

Dies setzt voraus, dass vollständige Blockchain-Knoten Zugriff auf die vollständigen Transaktionsdaten haben. Ein Angreifer, der einen schlechten Block-Header sendet und es zudem versäumt, die Transaktionsdaten verfügbar zu machen, könnte verhindern, dass vollständige Blockchain-Knoten Betrugsnachweise generieren. Die vollständigen Blockchain-Knoten 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-Knoten laden sehr kleine zufällige Blöcke der vollständigen Statusdaten 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 liegt die Wahrscheinlichkeit bei 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 Anwendungen, die zufällige Datenanfragen stellen, unbemerkt bleiben. Erasure Coding behebt dies, indem kleine fehlende Datenstücke rekonstruiert werden, die zur Überprüfung vorgeschlagener Statusänderungen verwendet werden können. Ein Betrugsnachweis könnte dann unter Verwendung der rekonstruierten Daten erstellt werden, was verhindert, dass Light-Knoten schlechte Header akzeptieren.

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

Datenverfügbarkeit und Ebene-2-Rollups

Ebene-2-Skalierungslösungen, wie z. B. , senken die Transaktionskosten und erhöhen den Durchsatz von Ethereum, indem sie Transaktionen Off-Chain verarbeiten. Rollup-Transaktionen werden komprimiert und in Stapeln (Batches) auf Ethereum gepostet. Stapel repräsentieren Tausende einzelner Off-Chain-Transaktionen in einer einzigen Transaktion auf Ethereum. Dies reduziert die Überlastung auf der Basisebene 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 Statusänderung unabhängig überprüft und als Ergebnis der Anwendung aller einzelnen Off-Chain-Transaktionen bestätigt werden kann. Wenn Rollup-Betreiber die Transaktionsdaten für diese Überprüfung 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 kontrollieren 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 und der ungültige Block weggelassen wird. 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, das dauerhaft auf der Blockchain verbleibt. Mit der Implementierung von EIP-4844 posten einige Rollups ihre Transaktionsdaten stattdessen in günstigeren Blob-Speicher. Dies ist kein permanenter Speicher. Unabhängige Prüfer müssen die Blobs abfragen und ihre Anfechtungen innerhalb von ca. 18 Tagen vorbringen, bevor die Daten von der Ethereum-Ebene 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 Blockchain-Knoten kann die Datenverfügbarkeit mithilfe von DAS überprüfen, 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 Statusübergängen garantieren. Die Datenverfügbarkeit ist jedoch immer noch ein Problem, da wir die Funktionalität des ZK-Rollups ohne Zugriff auf seine Statusdaten nicht garantieren (oder mit ihm interagieren) können. Beispielsweise können Benutzer ihre Kontostände nicht kennen, wenn ein Betreiber Details über den Status des Rollups zurückhält. Außerdem können sie keine Statusaktualisierungen 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 vollständige Blockchain-Knoten auf den vollständigen Satz von Transaktionen, die mit einem bestimmten Block verbunden sind, zugreifen und diesen überprüfen konnten. Daraus folgt nicht zwangsläufig, dass die Daten für immer zugänglich sind.

Datenabrufbarkeit ist die Fähigkeit von Blockchain-Knoten, historische Informationen aus der Blockchain abzurufen. Diese historischen Daten werden nicht zur Überprüfung neuer Blöcke benötigt, sie sind nur erforderlich, um vollständige Blockchain-Knoten ab dem Genesis-Block zu synchronisieren oder bestimmte historische Anfragen zu bedienen.

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 dezentralisierter Dateispeicherung wie dem Portal Network (opens in a new tab) verteilt werden.