DA=Datenverfügbarkeit≠Abruf historischer Daten

• Weitergeleiteter Originaltitel: Missverständnis der Datenverfügbarkeit: DA = Datenfreigabe ≠ historische Datenabfrage

Vorstellung:

Was genau ist Datenverfügbarkeit? Für die meisten Menschen mag der erste Eindruck "Zugriff auf historische Daten eines bestimmten Moments" sein, aber dies ist tatsächlich ein großes Missverständnis des DA-Konzepts. Kürzlich haben Mitbegründer von L2BEAT und Befürworter von Danksharding zusammen mit dem Gründer von Celestia dieses Missverständnis aufgeklärt. Sie wiesen darauf hin, dass sich Data Availability (DA) eigentlich auf "Datenveröffentlichung" beziehen sollte, aber die meisten Menschen haben DA als "historische Datenabrufbarkeit" interpretiert, was tatsächlich Probleme der Datenspeicherung beinhaltet.

Zum Beispiel erwähnte Dankrad vor einiger Zeit den obligatorischen Rückzugs-/Fluchtlukenmechanismus von Schicht 2 und merkte an, dass der obligatorische Rückzug von Validium das Abrufen des neuesten L2-Zustands erfordert, um einen Merkle-Beweis zu erstellen, während Plasma nur die Daten von vor 7 Tagen benötigt (dies bezieht sich auf ihre Methoden zur Bestimmung einer legitimen Zustandswurzel).

Damit wies Dankrad deutlich darauf hin, dass Validium von DA verlangt, die Sicherheit der Nutzergelder zu gewährleisten, Plasma jedoch nicht. Hier weist der Anwendungsfall Dankrad auf den Unterschied zwischen DA und historischem Datenabruf hin, der darin besteht, dass DA oft nur neu freigegebene Daten umfasst.

Bei L2BEAT wurde die Unterscheidung zwischen Data Availability (DA) und Data Storage (DS) weiter betont. Bartek von L2BEAT hat wiederholt betont, dass DA und Datenspeicherung/Abrufbarkeit historischer Daten zwei verschiedene Dinge sind und dass Benutzer nur deshalb auf die L2-Daten zugreifen können, die sie benötigen, weil die Knoten, die Daten bereitstellen, "freundlich genug zu Ihnen" sind. Darüber hinaus plant L2BEAT, "ob autorisierte Datenspeicherknoten verfügbar sind" als neue Metrik für die Bewertung von Rollups zu verwenden, die über DA hinausgehen.

Die Stellungnahmen der Ethereum-Community/der Mitglieder der Ethereum Foundation zeigen ihre Absicht, die Konzepte im Zusammenhang mit Layer 2 in Zukunft zu klären und zu verfeinern sowie eine detailliertere Definition von Layer 2 selbst bereitzustellen. Dies liegt daran, dass viele Begriffe im Zusammenhang mit Rollup und L2 nicht klar erklärt wurden, z. B. wie weit zurückliegende Daten als "historisch" gelten – einige glauben, dass Daten aus der Zeit vor 256 Blöcken (50 Minuten) als "historisch" gelten, da Smart Contracts nur Daten aus den letzten 256 Blöcken (50 Minuten) abrufen können.

Das von Celestia und der Ethereum Foundation erwähnte "Rollup" bezieht sich jedoch streng genommen auf zwei verschiedene Dinge. Dieser Artikel zielt darauf ab, den Unterschied zwischen dem DA-Konzept und der Datenspeicherung zu verdeutlichen, von der Quelle der DA, der Datenverfügbarkeitsstichprobe, bis hin zu den Implementierungsmethoden der DA in Rollups, und zu erklären, was Datenverfügbarkeit wirklich bedeutet – Datenveröffentlichung.

Der Ursprung des DA-Konzepts

Das Konzept von DA entspringt der Frage nach der "Datenverfügbarkeit", die Celestia-Gründer Mustafa wie folgt erklärt: Bei DA geht es darum, wie sichergestellt werden kann, dass alle Daten in einem Block im Netzwerk veröffentlicht werden, wenn ein Blockproduzent einen neuen Block vorschlägt. Wenn der Blockproduzent nicht alle Daten im Block freigibt, ist es unmöglich zu überprüfen, ob der Block fehlerhafte Transaktionen enthält.

Mustafa weist auch darauf hin, dass Ethereum Rollups einfach L2-Blockdaten auf der Ethereum-Chain veröffentlichen und sich auf ETH verlassen, um die Datenverfügbarkeit sicherzustellen. Auf der offiziellen Website von Ethereum wird das Problem der Datenverfügbarkeit als die Frage zusammengefasst: "Wie überprüfen wir, ob die Daten eines neuen Blocks verfügbar sind?" Bei Light Clients bezieht sich das Problem der Datenverfügbarkeit auf die Überprüfung der Verfügbarkeit eines Blocks, ohne dass der gesamte Block heruntergeladen werden muss.

Auch auf der offiziellen Website von Ethereum wird klar zwischen Datenverfügbarkeit und Datenabrufbarkeit unterschieden: Datenverfügbarkeit bezieht sich auf die Fähigkeit von Nodes, Blockdaten herunterzuladen, wenn sie vorgeschlagen werden, mit anderen Worten, sie bezieht sich auf die Zeit, bevor ein Block einen Konsens erreicht. Die Abrufbarkeit von Daten bezieht sich auf die Fähigkeit von Knoten, historische Informationen aus der Blockchain abzurufen. Obwohl für die Archivierung möglicherweise historische Blockchain-Daten erforderlich sind, müssen Knoten keine historischen Daten verwenden, um Blöcke zu verifizieren und Transaktionen zu verarbeiten.

Nach Ansicht von Celestias chinesischem Mitwirkenden und W3Hitchhiker-Partner Ren Hongyi geht Layer 2 im Vorfeld davon aus, dass Ethereum ausreichend sicher und dezentral ist. Sortierer können DA-Daten getrost an Ethereum senden, und diese Daten werden ungehindert an alle Ethereum-Full-Nodes weitergegeben. Da L2-Full-Nodes selbst den Geth-Client betreiben, gelten sie als Teilmenge der Ethereum-Full-Nodes und können somit die DA-Daten von Layer 2 empfangen.

In den Augen von Dr. Qi Zhou, dem Gründer von EthStorage, ist die Definition von Datenverfügbarkeit (DA), dass niemand die Transaktionsdaten zurückhalten kann, die von Benutzern an das Netzwerk übermittelt werden. Das entsprechende Vertrauensmodell besteht darin, dass wir nur dem Protokoll von Layer 1 (L1) selbst vertrauen müssen, ohne dass wir andere Vertrauensannahmen einführen müssen.

Qi Zhou weist darauf hin, dass die derzeitige Implementierung von DA in Ethereum im Wesentlichen P2P-Broadcasting (unter Verwendung des Gossip-Protokolls) ist, bei dem jeder vollständige Knoten neue Blöcke herunterlädt, neue Blöcke verbreitet und Rollup-Daten speichert. Ethereum Full Nodes werden historische Blöcke jedoch nicht für immer speichern. Nach der Implementierung von EIP-4844 können sie automatisch Daten löschen, die eine bestimmte Zeit zurückliegen (anscheinend 18 Tage). Es gibt nicht viele Archivknoten, die weltweit alle historischen Daten speichern. EthStorage plant, diese Lücke im Ethereum-Ökosystem zu schließen und Layer 2 bei der Einrichtung seiner dedizierten Datenpermanenzknoten zu unterstützen.

Die frühen Diskussionen über die Datenverfügbarkeit durch die Ethereum Foundation sind in den Tweets und GitHub-Dokumenten von Vitalik Buterin aus dem Jahr 2017 zu sehen. Damals glaubte er, dass es notwendig sei, die Hardwarekonfiguration der Full Nodes zu erhöhen, um die Skalierbarkeit und Effizienz der Blockchain zu gewährleisten (Full Nodes sind diejenigen, die den kompletten Block herunterladen und seine Gültigkeit überprüfen, und Validatoren, die am Konsens teilnehmen, sind eine Teilmenge der Full Nodes). Eine Erhöhung der Hardwareanforderungen für Full Nodes würde jedoch auch die Betriebskosten erhöhen, was zu einer Zentralisierung der Blockchain führen würde.

In diesem Zusammenhang schlug Vitalik vor, ein Schema zu entwickeln, um die Sicherheitsrisiken zu adressieren, die durch die Zentralisierungstendenz von Hochleistungs-Full-Nodes entstehen. Er plante die Einführung von Löschcodes und zufälligen Datenstichproben, um ein Protokoll zu entwickeln, das es leichten Knoten mit geringerer Hardwarekapazität ermöglicht, zu überprüfen, ob ein Block problemlos ist, ohne den gesamten Block zu kennen.

Seine ursprüngliche Idee bezog sich eigentlich auf eine Idee, die im Bitcoin-Whitepaper erwähnt wird, die besagt, dass Light-Nodes nicht den kompletten Block erhalten müssen, sondern von ehrlichen Full Nodes benachrichtigt werden, wenn es ein Problem mit dem Block gibt. Dieses Konzept könnte auf spätere Betrugsnachweise ausgeweitet werden, stellt aber nicht sicher, dass ehrliche Full Nodes immer genügend Daten erhalten können, noch kann es im Nachhinein beurteilen, ob der Blockierer die Veröffentlichung einiger Daten zurückgehalten hat.

Zum Beispiel könnte ein Knoten A einen Betrugsbeweis veröffentlichen, in dem behauptet wird, dass er einen unvollständigen Block von Knoten B erhalten hat. Es ist jedoch unmöglich festzustellen, ob der unvollständige Block von A fabriziert oder von B gesendet wurde. Vitalik wies darauf hin, dass dieses Problem durch Data Availability Sampling (DAS) gelöst werden könnte, was offensichtlich Fragen der Datenveröffentlichung mit sich bringt.

Vitalik ging in seinem Artikel "Ein Hinweis zur Datenverfügbarkeit und Löschcodierung" kurz auf diese Probleme und ihre Lösungen ein. Er wies darauf hin, dass DA-Nachweise (Data Availability) im Wesentlichen eine "Ergänzung" zu Betrugsnachweisen sind.

Stichproben zur Datenverfügbarkeit

Das Konzept von DA ist jedoch nicht so einfach zu erklären, wie das GitHub-Dokument von Vitalik zeigt, das 18 Korrekturen durchläuft, wobei die letzte Korrektur am 25. September 2018 eingereicht wurde. Nur einen Tag zuvor, am 24. September 2018, haben Celestias Gründer Mustafa und Vitalik gemeinsam das später berühmte Paper "Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities" verfasst.

Interessanterweise wird Mustafa als Erstautor der Studie aufgeführt, nicht Vitalik (ein anderer Autor ist jetzt Forscher an der öffentlichen Sui-Blockchain). Das Papier erwähnt das Konzept der Fraud Proofs und erläutert das Prinzip des Data Availability Sampling (DAS), grob beschrieben ein gemischtes Protokoll aus DAS + zweidimensionalem Erasure Coding + Fraud Proofs. In dem Papier wird ausdrücklich erwähnt, dass das DA-Proof-System eine notwendige Ergänzung zu den Betrugsnachweisen ist.

Aus Vitaliks Sicht funktioniert das Protokoll folgendermaßen:

Angenommen, eine öffentliche Blockchain verfügt über N Konsensknoten (Validatoren) mit Hardware mit hoher Kapazität, was einen hohen Datendurchsatz und eine hohe Effizienz ermöglicht. Obwohl eine solche Blockchain eine hohe TPS (Transactions Per Second) haben kann, ist die Anzahl der Konsensknoten, N, relativ klein, was sie zentralisierter macht und eine höhere Wahrscheinlichkeit von Absprachen zwischen Knoten aufweist.

Es wird jedoch davon ausgegangen, dass mindestens einer der N Konsensknoten ehrlich ist. Solange mindestens 1/N der Validatoren ehrlich sind und in der Lage sind, Betrugsbeweise zu erkennen und zu verbreiten, wenn ein Block ungültig ist, können Light Clients oder ehrliche Validatoren auf Sicherheitsprobleme im Netzwerk aufmerksam werden und Mechanismen wie das Abschneiden bösartiger Knoten und soziale Konsens-Forks verwenden, um das Netzwerk wieder in den Normalzustand zu versetzen.

Wie Vitalik bereits erwähnt hat, ist es schwierig festzustellen, ob der Blockvorschlagsteller diesen Teil nicht veröffentlicht hat, ob er während der Übertragung von anderen Knoten zurückgehalten wurde oder ob es sich um eine falsche Flagge des Knotens handelt, der den Betrugsbeweis veröffentlicht. Wenn sich die Mehrheit der Knoten verschwört, kann der ehrliche 1/N-Validator isoliert sein und keine neuen Blöcke empfangen können, was ein Szenario für einen Angriff auf die Zurückhaltung von Daten ist. In solchen Fällen kann der ehrliche Knoten nicht feststellen, ob dies auf schlechte Netzwerkbedingungen oder eine absichtliche Zurückhaltungsverschwörung anderer zurückzuführen ist, und er kann auch nicht wissen, ob andere Knoten ebenfalls isoliert sind, was es schwierig macht zu beurteilen, ob sich eine Mehrheit bei der Zurückhaltung von Daten verschworen hat.

Daher muss es einen Weg geben, um mit einer sehr hohen Wahrscheinlichkeit sicherzustellen, dass ehrliche Validatoren die Daten erhalten können, die für die Validierung von Blöcken erforderlich sind. Und um herauszufinden, wer hinter einem Angriff steckt, der Daten zurückhält – ob es sich um den Blockierer handelt, der nicht genügend Daten veröffentlicht hat, ob sie von anderen Knoten zurückgehalten wurden oder ob es sich um eine Verschwörung der Mehrheit handelt. Es ist klar, dass dieses Sicherheitsmodell viel mehr Schutz bietet als die "ehrliche Mehrheitsannahme", die in typischen PoS-Ketten üblich ist, und Data Availability Sampling (DAS) ist die spezifische Implementierungsmethode.

Angenommen, es gibt viele Lichtknoten im Netzwerk, möglicherweise 10 mal N, die jeweils mit mehreren Validatoren verbunden sind (der Einfachheit halber nehmen wir an, dass jeder Lichtknoten mit allen N Validatoren verbunden ist). Diese Lichtknoten würden mehrere Datenstichproben von Validatoren durchführen, wobei jedes Mal nach dem Zufallsprinzip ein kleiner Teil der Daten angefordert wird (angenommen, es handelt sich nur um 1 % eines Blocks). Dann würden sie die erworbenen Fragmente an Validatoren weitergeben, denen diese Daten fehlen. Solange genügend Lichtknoten vorhanden sind und die Häufigkeit der Datenabtastung hoch genug ist, kann sichergestellt werden, dass alle Validatoren schließlich die notwendige Datenmenge erfassen können, um einen Block zu validieren, selbst wenn einige Anfragen abgelehnt werden, solange die meisten beantwortet werden. Dadurch können die Auswirkungen des Zurückhaltens von Daten durch andere Knoten als den Blockvorschlager negiert werden.

(Bildquelle: W3 Hitchhiker)

Wenn sich die Mehrheit der Validatoren verschwört und sich weigert, auf die meisten Anfragen von Light-Nodes zu antworten, wäre es für die Leute leicht zu erkennen, dass es ein Problem mit der Kette gibt (denn selbst wenn einige Leute schlechtes Internet haben, würde dies nicht dazu führen, dass die meisten Light-Node-Anfragen abgelehnt werden). Daher kann das oben genannte Schema mit hoher Wahrscheinlichkeit das Verschwörungsverhalten der Mehrheit bestimmen, obwohl solche Situationen an sich selten sind. Mit diesem Ansatz können Unsicherheiten aus anderen Quellen als dem Blockvorschlager beseitigt werden. Wenn der Blockvorschlager Daten zurückhält, z. B. weil er nicht genügend Daten im Block veröffentlicht, um ihn zu validieren (nach der Einführung von zweidimensionaler Löschcodierung enthält ein Block 2k2k-Fragmente, und die Wiederherstellung der ursprünglichen Daten des Blocks erfordert mindestens etwa kk-Fragmente oder 1/4. Um zu verhindern, dass andere die Originaldaten wiederherstellen, müsste der Antragsteller mindestens k+1*k+1-Fragmente zurückhalten), werden sie schließlich von ehrlichen Validatoren entdeckt, die dann Betrugsbeweise senden, um andere zu warnen.

Laut Vitalik und Mustafa kombinierten sie im Wesentlichen Ideen, die bereits von anderen vorgeschlagen worden waren, und fügten darüber hinaus eigene Innovationen hinzu. Betrachtet man das Konzept und die Implementierungsmethode als Ganzes, wird deutlich, dass sich die "Datenverfügbarkeit" darauf bezieht, ob die Daten, die zur Verifizierung des letzten Blocks benötigt werden, vom Blockvorschlagsteller veröffentlicht wurden und ob sie von den Prüfern empfangen werden können. Hier geht es darum, ob die Daten "vollständig veröffentlicht" sind, und nicht darum, ob "historische Daten abgerufen werden können".

Wie die Datenverfügbarkeit (DA) von Ethereum Rollup implementiert wird

Schauen wir uns mit der obigen Behauptung an, wie Data Availability (DA) in Ethereum-Rollups implementiert ist, was ziemlich deutlich wird: Der Block-Proposer in einem Rollup ist als Sequencer bekannt, der die Daten veröffentlicht, die benötigt werden, um Layer-2-Zustandsübergänge auf Ethereum in Intervallen zu überprüfen. Insbesondere initiiert es eine Transaktion zu einem bestimmten Kontrakt und stopft die DA-bezogenen Daten in die benutzerdefinierten Eingabeparameter, die dann in einem Ethereum-Block aufgezeichnet werden. Angesichts des hohen Dezentralisierungsgrades von Ethereum kann sichergestellt werden, dass die vom Sequenzer übermittelten Daten reibungslos von den "Verifizierern" empfangen werden. Die Entitäten, die die Rolle der "Verifizierer" spielen, unterscheiden sich jedoch in verschiedenen Rollup-Netzwerken.

Im Fall von Arbitrum zum Beispiel bucht der Sequenzer Stapel von Transaktionen zu einem bestimmten Vertrag auf Ethereum. Der Vertrag selbst überprüft diese Daten nicht, sondern gibt ein Ereignis aus, auf das L2-Vollknoten lauschen können, um sie darüber zu informieren, dass der Sequencer einen Stapel von Transaktionen veröffentlicht hat. Konkret verwenden ZK Rollups einen Verifier-Vertrag auf Ethereum als "Verifier". Ein ZK-Rollup muss lediglich einen State Diff + Validity Proof veröffentlichen, d.h. Informationen über Zustandsänderungen sowie einen Validitätsnachweis. Der Verifier-Vertrag prüft den Gültigkeitsnachweis, um festzustellen, ob er mit dem State Diff übereinstimmt. Wenn die Validierung erfolgreich ist, wird der vom Sequencer veröffentlichte L2-Block/Batch als gültig betrachtet.

(Quelle: Ehemaliges Whitepaper von Polygon Hermez)

Optimistische Rollups erfordern die Veröffentlichung von mehr Daten auf Ethereum, da sie sich ausschließlich auf L2-Vollknoten verlassen, um Daten herunterzuladen und die Gültigkeit von Blöcken zu überprüfen. Das bedeutet, dass mindestens die digitalen Signaturen jeder L2-Transaktion (die jetzt üblicherweise aggregierte Signaturen verwendet) offengelegt werden müssen. Wenn Vertragsaufrufe erfolgen, müssen neben den Transaktionsübertragungsadressen auch die Eingabeparameter offengelegt werden, um Replay-Angriffe zu verhindern, usw. Im Vergleich zu den vollständigen Transaktionsdaten gibt es jedoch noch einige Kürzungen.

Im Vergleich zu ZK-Rollups sind die DA-Kosten (Data Availability) von optimistischen Rollups höher, da ZK-Rollups nur die endgültigen Zustandsänderungen offenlegen müssen, nachdem ein Stapel von Transaktionen ausgeführt wurde, begleitet von einem Gültigkeitsnachweis, der die Prägnanz von ZK SNARK/STARK nutzt. während optimistische Rollups nur die umständlichste Methode verwenden können, bei der alle Transaktionen von anderen L2-Vollknoten erneut ausgeführt werden müssen.

Zuvor schätzte W3hitchhiker grob, dass der Skalierungseffekt von ZKR (Zero-Knowledge Rollups) ohne Berücksichtigung der zukünftigen Entwicklungen von EIP-4844 und Blobs ein Vielfaches des OPR (Optimistic Rollups) erreichen könnte. Wenn man Smart Wallets im Zusammenhang mit EIP-4337 in Betracht zieht (die Fingerabdrücke, Irisdaten anstelle von privaten Schlüsselsignaturen verwenden), wäre der Vorteil von ZKR noch offensichtlicher, da es die Binärdaten von Fingerabdrücken und Iris nicht auf Ethereum veröffentlichen muss, während Optimistic Rollups dies tun.

Was Validium und Plasma/Optimium betrifft, so verwenden sie tatsächlich die Off-Chain-DA-Schicht von Ethereum, um DA zu erreichen. Zum Beispiel hat ImmutableX, das ein Gültigkeitsnachweissystem eingeführt hat, eine Reihe von DAC-Knoten (Data Availability Committee) speziell für die Veröffentlichung von Daten im Zusammenhang mit DA eingerichtet. Metis veröffentlicht DA-Daten auf Memlabs, und Rooch und Manta verwenden Celestia. Derzeit ist Celestia aufgrund der Existenz von DAS (Data Availability Solutions) und betrugssicheren Systemen eines der vertrauenswürdigsten DA-Layer-Projekte außerhalb von Ethereum.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [Geek Web3]. Leiten Sie den Originaltitel weiter:Missverständnisse über die Verfügbarkeit von Daten: DA = Data Publishing ≠ Historical Data Retrieva, Alle Urheberrechte liegen beim ursprünglichen Autor [ Faust, Geek web3]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an das Gate Learn-Team , das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen 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, Verbreiten oder Plagiieren der übersetzten Artikel verboten.