Das Problem der Datenverfügbarkeit

Wie können Peers in einem Blockchain-Netzwerk sicher sein, dass alle Daten eines neu vorgeschlagenen Blocks verfügbar sind? Und warum ist das wichtig?

In diesem Beitrag gehen wir auf die Details des Datenverfügbarkeitsproblems ein und wie es sich auf das Skalieren von Ethereum auswirken kann.

Was ist das Problem der Datenverfügbarkeit?

Das Datenverfügbarkeits (DA) Problem: Wie können Peers in einem Blockchain-Netzwerk sicher sein, dass alle Daten eines neu vorgeschlagenen Blocks tatsächlich verfügbar sind? Wenn die Daten nicht verfügbar sind, könnte der Block bösartige Transaktionen enthalten, die vom Blockproduzenten versteckt werden. Selbst wenn der Block nicht-bösartige Transaktionen enthält, könnte das Verbergen von ihnen die Sicherheit des Systems beeinträchtigen.

Um ein Beispiel zu geben, nehmen wir an, dass Alice eine Betreiberin eines ZK-Rollup (ZKR)Sie reicht einen ZK-Nachweis auf Ethereum ein, der überprüft wird. Wenn sie nicht alle Transaktionsdaten auf Ethereum einreicht, obwohl ihr Nachweis beweist, dass alle Zustandsübergänge im Rollup gültig sind, könnten die Benutzer des Rollups dennoch im Dunkeln darüber sein, wie es um ihre aktuellen Kontostände steht. Der eingereichte Nachweis gibt keinen Aufschluss über die aktuellen Zustände, aufgrund seiner Zero-Knowledge-Natur.

Ein analoges Beispiel existiert im Optimistic Rollup (OPR)Einstellung, in der Alice eine Behauptung auf Ethereum einreicht, aber keiner der Teilnehmer des OPR sie herausfordern kann, weil die Transaktionsdaten nicht verfügbar sind und sie daher nicht in der Lage sind, die Behauptung neu zu berechnen oder anzufechten.

Um die oben genannten Szenarien zu bekämpfen, schreiben sowohl OPR- als auch ZKR-Designs den Betreibern vor, alle Transaktionsdetails einzureichen Ethereumals „calldata“. Während dies dazu führt, dass sie das DA-Problem kurzfristig umgehen, steigt mit der Anzahl der Transaktionen innerhalb von Rollups auch die Menge der Daten, die übermittelt werden müssen, was die Skalierbarkeit, die diese Rollups bieten können, einschränkt.

Um die Sache noch schlimmer zu machen, ist die Nichtverfügbarkeit von Daten kein eindeutig zuordenbarer Fehler. Das bedeutet, dass die Teilnehmer anderen Peers nicht nachweisen können, dass ein bestimmter Datenblock fehlt. Dies liegt daran, dass Bob verkünden kann, dass der von Alice eingereichte Block fehlende Daten hat, aber wenn Charlie Alice befragt, kann sie ihm die Daten zur Verfügung stellen.

Wie wirkt sich das heute auf eine Blockchain aus?

Um diese Frage zu beantworten, lassen Sie uns zunächst die allgemeine Blockstruktur einer Ethereum-ähnlichen Blockchain und die Arten von Clients überprüfen, die auf einem beliebigen Blockchain-Netzwerk existieren.

Ein Block kann in zwei Hauptteile unterteilt werden:

• Block Header: Ein kleiner Blockheader enthält den Digest und die Metadaten zu den in dem Block enthaltenen Transaktionen.
• Block-Body: Dies enthält alle Transaktionsdaten und macht den Großteil der Blockgröße aus.

In herkömmlichen Blockchain-Protokollen gelten alle Knoten als vollständige Knoten, die den gesamten Block synchronisieren und alle Zustandsübergänge überprüfen. Sie müssen eine beträchtliche Menge an Ressourcen aufwenden, um die Transaktionsgültigkeit zu überprüfen und die Blöcke zu speichern. Auf der positiven Seite können diese Knoten nicht dazu gebracht werden, eine ungültige Transaktion zu akzeptieren.

Es könnte eine weitere Klasse von Knoten geben, die nicht über Ressourcen verfügen (oder nicht ausgeben möchten), um jede Transaktion zu überprüfen. Stattdessen sind sie hauptsächlich daran interessiert, den aktuellen Zustand der Blockchain zu kennen und ob einige Transaktionen, die sie betreffen, in der Kette enthalten sind oder nicht. Idealerweise sollten diese Leichtclients auch davor geschützt werden, einer Kette zu folgen, die ungültige Transaktionen enthält. Dies ist tatsächlich möglich mithilfe sogenannter Betrugsnachweise. Dabei handelt es sich um prägnante Nachrichten, die zeigen, dass ein bestimmter Block eine ungültige Transaktion enthält. Jeder vollständige Knoten kann einen solchen Betrugsnachweis erstellen, sodass der Leichtclient nicht darauf vertrauen muss, dass ein bestimmter vollständiger Knoten ehrlich ist. Sie müssen nur sicherstellen, dass sie gut mit einem Gossip-Netzwerk verbunden sind, das sicherstellt, dass sie einen Betrugsnachweis für einen Blockheader erhalten, wenn dieser verfügbar ist.

Allerdings gibt es ein Problem mit diesem System: Was ist, wenn ein Blockproduzent nicht die gesamten Daten hinter einem Block offenbart? In diesem Fall werden Vollknoten den Block offensichtlich ablehnen, da es aus ihrer Sicht nicht einmal ein Block ist, wenn er nicht mit dem Blockkörper geliefert wird. Leichte Clients können jedoch mit der Header-Kette präsentiert werden und haben keine Möglichkeit zu bemerken, dass die Daten fehlen. Gleichzeitig können Vollknoten keine Betrugsnachweise erbringen, da ihnen die für die Erstellung von Betrugsnachweisen erforderlichen Daten fehlen.

Um dem entgegenzuwirken, benötigen wir einen Mechanismus, damit Leichtclients die Verfügbarkeit von Daten überprüfen können. Dadurch würde sichergestellt, dass ein Blockproduzent, der Daten verbirgt, nicht davonkommen kann, indem er einen Leichtclient überzeugt. Es würde auch den Blockproduzenten zwingen, Teile der Daten preiszugeben, sodass das gesamte Netzwerk auf kollaborative Weise Zugriff auf den gesamten Block hätte.

Lassen Sie uns das Problem mit Hilfe eines Beispiels etwas genauer untersuchen. Angenommen, der Blockproduzent Alice erstellt einen Block B mit den Transaktionen tx1, tx2, ..., txn. Nehmen wir an, tx1 ist eine bösartige Transaktion. Wenn tx1 übertragen wird, kann jeder vollständige Knoten überprüfen, dass sie bösartig ist, und dies einem Leichtkunden als Betrugsnachweis senden, der sofort weiß, dass der Block inakzeptabel ist. Wenn Alice jedoch tx1 verbergen möchte, enthüllt sie den Header und alle Transaktionsdaten außer tx1. Die vollständigen Knoten können die Richtigkeit von tx1 nicht überprüfen.

Man könnte denken, dass eine einfache Lösung darin besteht, dass alle Leichtclients einfach die Transaktionen zufällig auswählen und wenn sie feststellen, dass ihre Stichproben verfügbar sind, können sie sicher sein, dass der Block verfügbar ist. Lassen Sie die Leichtknoten eine beliebige Transaktion gleichmäßig zufällig abfragen. Die Wahrscheinlichkeit, dass der Leichtclient tx1 abfragt, beträgt 1/n. Somit kann Alice mit überwältigender Wahrscheinlichkeit die Leichtclients dazu bringen, eine bösartige Transaktion zu akzeptieren. Mit anderen Worten, die meisten Leichtclients werden getäuscht. Aufgrund der nicht nachweisbaren Natur können Vollknoten in keiner Weise nachweisen, dass tx1 nicht verfügbar ist. Leider verbessert eine Erhöhung der Anzahl der Stichproben dies nicht wesentlich.

Also, was machen wir damit?

Die Lösung für dieses Problem besteht darin, Redundanz in einen Block einzuführen. Es gibt eine umfangreiche Literatur über Codierungstheorie im Allgemeinen und insbesondere über Löschcodierung, die uns bei diesem Problem helfen kann.

Erasure-Codierung ermöglicht es uns im Wesentlichen, eine beliebige Anzahl von n Datenblöcken auf 2n Datenblöcke zu erweitern, sodass jede Kombination von n aus 2n ausreicht, um das ursprüngliche Datenstück wiederherzustellen (die Parameter sind anpassbar, aber hier betrachten wir dies der Einfachheit halber).

Wenn wir den Blockproduzenten zwingen, die Transaktionen tx1, tx2, …, txn zu löschen, dann müsste er, um eine einzelne Transaktion zu verbergen, n+1 Datenchunks verbergen, da bereits n ausreichen, um den gesamten Transaktionssatz zu konstruieren. In diesem Fall geben eine konstante Anzahl von Abfragen dem Leichtkunden eine sehr hohe Zuversicht, dass die zugrunde liegenden Daten tatsächlich verfügbar sind.

Wow, ist das also so?

Nein. Obwohl dieser einfache Trick das Verbergen erschwert, ist es immer noch möglich, dass der Blockproduzent die Löschcodierung absichtlich falsch durchführt. Ein vollständiger Knoten kann jedoch überprüfen, ob diese Löschcodierung korrekt durchgeführt wurde. Falls nicht, kann er dies einem leichten Client beweisen. Dies ist eine weitere Art von Betrugsnachweis, ähnlich wie im Fall von bösartigen Transaktionen oben. Interessanterweise muss es einen einzigen ehrlichen Vollknoten-Nachbarn eines leichten Clients geben, damit dieser sicher sein kann, dass er im Falle eines bösartigen Blocks einen Betrugsnachweis erhält. Dies stellt sicher, dass der leichte Client mit sehr hoher Wahrscheinlichkeit Zugriff auf eine Kette ohne bösartige Transaktionen hat.

Aber es gibt einen Haken. Wenn dies naiv gemacht wird, kann die Größe einiger Betrugsnachweise in der Größenordnung der Blockgröße liegen. Die Ressourcenvoraussetzung, die wir beim Leichtclient hatten, verbietet uns die Verwendung eines solchen Designs. Es gab in dieser Hinsicht Verbesserungen durch die Verwendung von mehrdimensionalen Auslöschungscodierungstechniken, die die Größe der Betrugsnachweise auf Kosten der Commitmentgröße reduzieren. Aus Gründen der Kürze gehen wir nicht darauf ein, aber dieses Papierhat eine detaillierte Analyse davon.

Das Problem bei fälschungssicheren Lösungen ist, dass die Leichtkunden nie vollständig sicher sind, was einen Block betrifft, für den sie noch keinen Fälschungsnachweis erhalten haben. Außerdem vertrauen sie kontinuierlich darauf, dass ihre vollständigen Knotenpeers ehrlich sind. Auch ehrliche Knoten müssen Anreize erhalten, um kontinuierlich Blöcke zu prüfen.

Wir haben hier unsere Aufmerksamkeit auf Systeme gerichtet, die garantieren, dass, wenn die Blockcodierung ungültig ist, Vollknoten dies erkennen und Lichtclients einen Beweis liefern können, der sie von Fehlverhalten überzeugt. In dem nächsten Abschnitt werden wir uns jedoch mit Blockcodierungen befassen, die garantieren, dass nur gültige Codierungen in die Kette übernommen werden können. Dies beseitigt die Notwendigkeit von Betrugsnachweisen, die Codierungsfehler beweisen. Diese lösungsorientierten Beweise ermöglichen es Anwendungen, das System zu nutzen, ohne auf solche Betrugsnachweise von Vollknoten warten zu müssen.

Also, wie funktionieren diese Lösungen?

In letzter Zeit haben polynomiale Verpflichtungen im Blockchain-Bereich wieder verstärktes Interesse gefunden. Insbesondere diese polynomialen Verpflichtungen, Konstante KZG/Gate-Verpflichtungen für Polynome, kann verwendet werden, um ein sauberes DA-Schema zu entwerfen, ohne dass Betrugsnachweise erforderlich sind. Kurz gesagt, ermöglichen es uns KZG-Verpflichtungen, sich zu einem Polynom zu verpflichten, indem sie ein einzelnes Element der elliptischen Kurvengruppe verwenden. Darüber hinaus unterstützt uns das Schema dabei zu beweisen, dass an einem Punkt i das Polynom φ zu φ(i) ausgewertet wird, wobei ein konstant großes Zeugnis verwendet wird. Das Verpflichtungsschema ist rechnerisch bindend und auch homomorph, was es uns ermöglicht, Betrugsnachweise elegant zu vermeiden.

Wir zwingen den Blockproduzenten, die ursprünglichen Transaktionsdaten zu nehmen und in einer 2D-Matrix der Größe n x m anzuordnen. Es verwendet die Polynominterpolation, um jede Spalte der Größe n in Spalten der Größe 2n zu erweitern. Jede Zeile dieser erweiterten Matrix erzeugt ein Polynom-Commitment und sendet diese Commitments als Teil des Blockheaders. Eine schematische Darstellung des Blocks ist unten angegeben.

Die leichten Clients können jede Zelle dieser erweiterten Matrix abfragen, um den Zeugen zu erhalten, der es ihnen ermöglicht, ihn sofort gegen den Blockheader zu überprüfen. Die konstant großen Mitgliedschaftsnachweise machen die Stichprobenentnahme äußerst effizient. Die homomorphe Natur des Commitments stellt sicher, dass der Nachweis nur dann verifiziert, wenn der Block korrekt konstruiert ist, und die Polynominterpolation stellt sicher, dass eine konstante Anzahl erfolgreicher Proben bedeutet, dass die Daten mit sehr hoher Wahrscheinlichkeit verfügbar sind.

Eine schematische Darstellung des Blocks

Die Feinheiten des Schemas sowie weitere Optimierungen und Kostenschätzungen würden den Rahmen dieses Artikels sprengen. Wir möchten jedoch darauf hinweisen, dass, obwohl wir hier ein 2D-Schema diskutieren, ähnliche Garantien auch mit einem 1D-Schema bereitgestellt werden können, das eine kleinere Header-Größe auf Kosten einer geringeren Parallelität und einer geringen Client-Sampling-Effizienz aufweist. Wir werden in Folgeartikeln tiefer darauf eingehen.

Was sind die anderen Alternativen und was als Nächstes?

Der höherdimensionale Löschcode und die KZG-Verpflichtungen sind nicht die einzigen Möglichkeiten, um das DA-Problem anzugehen. Es gibt noch andere Wege, die wir hier ausgelassen haben, wie Codierte Merkle-Bäume, Codierter Interleaving-Baum, FRI, und STARK-basierte Ansätze, aber jeder hat seine Vor- und Nachteile.

Bei Gate haben wir an einer Datenverfügbarkeitslösung mit KZG-Verpflichtungen gearbeitet. In späteren Beiträgen werden wir auf die Implementierungsdetails eingehen, wie Sie es heute verwenden können und wie wir beabsichtigen, den DA-Problemraum zu transformieren. Für weitere Informationen zu Gate folgen Sie uns auf Twitter und schließen Sie sich uns an Discord-Server.

Haftungsausschluss：

1. Dieser Artikel wird von [wieder abgedrucktAvail Team]. Alle Urheberrechte gehören dem Originalautor [Avail Team]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die [GateGate LearnTeam und sie werden es umgehend bearbeiten.

2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.

3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.