Am 17. Januar 2024 wurde die Testnet-Version des Ethereum-Netzwerk-Upgrades Dencun im Goerli-Testnetz gestartet, und das Sepolia-Testnetz wurde am 30. Januar erfolgreich gestartet. Das Dencun-Upgrade rückt immer näher.

Nach dem Holesky-Testnet-Upgrade am 7. Februar wird es das Mainnet-Upgrade sein. Der Mainnet-Start des Cancun-Upgrades wurde offiziell am 13. März 2024 festgelegt.

Fast jedes Ethereum-Upgrade wird von signifikanten Markttrends begleitet. Rückblickend auf das letzte Upgrade am 12. April 2023, das sogenannte Shanghai-Upgrade, erfuhren Projekte im Zusammenhang mit Proof-of-Stake (PoS) eine erhöhte Marktnachfrage.

Wenn wir den bisherigen Erfahrungen folgen, wird es wahrscheinlich Möglichkeiten für eine strategische Positionierung vor dem bevorstehenden Dencun-Upgrade geben.

Aufgrund der technischen Komplexität, die mit dem Dencun-Upgrade verbunden ist, kann es jedoch nicht so prägnant zusammengefasst werden wie das Shanghai-Upgrade mit einem einzigen Satz wie "Ethereum wechselt von PoW zu PoS". Diese Komplexität macht es schwierig, die Schwerpunkte für die strategische Positionierung zu erfassen.

Daher zielt dieser Artikel darauf ab, die technischen Details des Dencun-Upgrades in einfacher und verständlicher Sprache zu erklären. Er führt die Leser durch die Feinheiten dieses Upgrades und beleuchtet seine Verbindungen mit Datenverfügbarkeit (DA), Layer-2-Lösungen und anderen relevanten Aspekten.

01. EIP 4484

EIP-4844 ist der wichtigste Vorschlag im Dencun-Upgrade und markiert einen bedeutenden Schritt für Ethereum auf seinem Weg zur dezentralen Skalierung.

Laienhaft ausgedrückt erfordern die aktuellen Ethereum-Layer-2-Lösungen, dass Transaktionen, die auf Layer 2 stattfinden, an die Aufrufdaten des Ethereum-Mainnets übermittelt werden. Diese Aufrufdaten werden dann von Knoten verwendet, um die Gültigkeit von Blöcken im Layer-2-Netzwerk zu überprüfen.

Dieser Ansatz bringt jedoch Herausforderungen mit sich, da trotz der Bemühungen, Transaktionsdaten zu komprimieren, das beträchtliche Transaktionsvolumen auf Layer 2, multipliziert mit den hohen Speicherkosten im Ethereum-Mainnet, immer noch erhebliche Kosten für Layer-2-Knoten und -Benutzer verursacht. Allein diese hohen Kosten können dazu führen, dass Nutzer auf Sidechains umsteigen.

EIP-4844 führt eine kostengünstige Lösung ein, indem es eine neue Art von Speicherbereich namens Binary Large Object (BLOB) einrichtet. Es wird ein neuartiger Transaktionstyp eingeführt, der als "BLOB-Carrying Transaction" bekannt ist, um die Transaktionsdaten zu ersetzen, die zuvor vor dem Upgrade in calldata gespeichert wurden. Dieser innovative Ansatz hilft dem Ethereum-Layer-2-Ökosystem, Einsparungen bei den Gaskosten zu erzielen.

Warum ist BLOB-Speicher kosteneffizient?

Wie wir alle wissen, ist Kosteneffizienz oft mit einem Kompromiss verbunden. Der Grund, warum BLOB-Daten im Vergleich zu ähnlich großen regulären Ethereum-Aufrufdaten geringere Kosten verursachen, ist, dass der Ethereum Execution Layer (EL) nicht direkt auf die BLOB-Daten selbst zugreifen kann.

Stattdessen kann die EL nur auf Verweise auf die BLOB-Daten zugreifen, und die eigentlichen Daten des BLOB können nur vom Ethereum Consensus Layer (CL, auch bekannt als Beacon-Knoten) heruntergeladen und gespeichert werden. Der Speicher- und Rechenbedarf für die Speicherung von BLOB-Daten ist deutlich geringer als bei regulären Ethereum-Aufrufdaten.

Darüber hinaus hat BLOB eine Besonderheit – es kann nur für einen begrenzten Zeitraum (in der Regel etwa 18 Tage) gespeichert werden und dehnt sich nicht wie die Größe des Ethereum-Ledgers unendlich aus.

Gültigkeitsdauer der BLOB-Speicherung

Im Gegensatz zum permanenten Ledger der Blockchain handelt es sich bei BLOBs um temporäre Speicher, die für 4.096 Epochen oder etwa 18 Tage zur Verfügung stehen.

Nach Ablauf sind die meisten Konsensclients nicht in der Lage, bestimmte Daten im BLOB abzurufen. Der Nachweis seiner bisherigen Existenz verbleibt jedoch in Form von KZG-Verpflichtungen im Mainnet und wird dauerhaft im Ethereum-Mainnet gespeichert.

Warum 18 Tage? Dies ist ein Kompromiss zwischen Speicherkosten und Effektivität.

Zunächst einmal müssen wir die intuitivsten Nutznießer dieses Upgrades betrachten, optimistische Rollups (wie Arbitrum und Optimism), da es ein 7-tägiges Zeitfenster für die Betrugssicherheit in optimistischen Rollups gibt. Die im Blob gespeicherten Transaktionsdaten sind genau das, was optimistische Rollups beim Starten einer Abfrage benötigen.

Daher muss die Gültigkeitsdauer des Blobs sicherstellen, dass auf den Betrugsbeweis für optimistische Rollups zugegriffen werden kann. Der Einfachheit halber wählte die Ethereum-Community 2 hoch 12 (4.096 Epochen werden von 2^12 abgeleitet, und eine Epoche ist ungefähr 6,4 Minuten).

BLOB-tragende Transaktion und BLOB

Das Verständnis der Beziehung zwischen den beiden ist wichtig, um die Rolle von BLOBs bei der Datenverfügbarkeit (DA) zu verstehen.

Ersteres ist der Gesamtvorschlag EIP-4484 und stellt eine neue Art von Transaktion dar, während letzteres als temporärer Speicherort für Layer-2-Transaktionen verstanden werden kann.

Die Beziehung zwischen den beiden kann so verstanden werden, dass die meisten Daten in der ersten (Layer-2-Transaktionsdaten) in der zweiten gespeichert werden. Die restlichen Daten, d.h. die BLOB-Datenbindung, werden in den Calldata des Mainnets gespeichert. Mit anderen Worten: Versprechen können von der EVM gelesen werden.

Commitment kann man sich so vorstellen, dass alle Transaktionen im BLOB in einen Merkle-Baum umgewandelt werden, und dann kann der Vertrag nur auf die Merkle-Wurzel, die das Commitment ist, zugreifen.

Dies kann geschickt erreicht werden: Obwohl der EVM den spezifischen Inhalt des BLOB nicht kennen kann, kann der EVM-Vertrag die Authentizität der Transaktionsdaten überprüfen, indem er das Commitment kennt.

02. Die Beziehung zwischen BLOB und Layer 2

Die Rollup-Technologie erreicht die Datenverfügbarkeit (DA) durch das Hochladen von Daten in das Ethereum-Mainnet, aber sie ist nicht dafür vorgesehen, dass die Smart Contracts von L1 diese hochgeladenen Daten direkt lesen oder verifizieren.

Der Zweck des Hochladens von Transaktionsdaten in L1 besteht einfach darin, allen Teilnehmern die Möglichkeit zu geben, die Daten einzusehen.

Vor dem Dencun-Upgrade werden Optimistic Rollups, wie oben erwähnt, Transaktionsdaten als Calldata auf Ethereum veröffentlichen. Daher kann jeder diese Transaktionsinformationen verwenden, um den Zustand zu reproduzieren und die Richtigkeit des Layer-2-Netzwerks zu überprüfen.

Es ist nicht schwer zu erkennen, dass Rollup-Transaktionsdaten kostengünstig, offen und transparent sein müssen. Calldata ist kein guter Ort, um Transaktionsdaten speziell für die Schicht 2 zu speichern, und BLOB-Carrying Transaction ist maßgeschneidert für Rollup.

An dieser Stelle fragen Sie sich vielleicht, welche Bedeutung Transaktionsdaten haben.

In der Realität werden Bewegungsdaten nur in bestimmten Szenarien verwendet:

• Für optimistisches Rollup, das auf einer Vertrauensannahme basiert, besteht die Möglichkeit der Unehrlichkeit. In solchen Fällen werden die per Rollup hochgeladenen Transaktionsdatensätze nützlich und ermöglichen es Benutzern, Betrugsnachweise zu initiieren.
• Für ZK Rollup hat der Zero-Knowledge-Proof bewiesen, dass die Zustandsaktualisierung korrekt ist. Das Hochladen von Daten dient nur dazu, dass Benutzer den vollständigen Zustand selbst berechnen können. Wenn der Layer-2-Knoten nicht ordnungsgemäß funktioniert, wird der Escape-Hatch-Mechanismus aktiviert, der einen vollständigen L2-Zustandsbaum erfordert. Dies wird im letzten Abschnitt dieses Artikels erläutert.

Dies impliziert, dass die tatsächliche Nutzung von Transaktionsdaten durch Verträge sehr begrenzt ist. Selbst in den Betrugsnachweisen von Optimistic Rollup ist nur der Nachweis erforderlich, dass Transaktionsdaten zu einem bestimmten Zeitpunkt "existierten", und es besteht keine Notwendigkeit, die Details jeder Transaktion im Voraus im Mainnet zu speichern.

Durch das Platzieren von Transaktionsdaten im BLOB kann der Mainnet-Vertrag, obwohl er für Verträge nicht zugänglich ist, die Zusage des BLOB speichern.

Wenn der betrugssichere Mechanismus in Zukunft eine bestimmte Transaktion benötigt, kann die Bereitstellung der Daten für diese Transaktion, sofern sie übereinstimmen, den Vertrag überzeugen und die Transaktionsdaten für den betrugssicheren Mechanismus liefern.

Dies nutzt nicht nur die Offenheit und Transparenz der Transaktionsdaten, sondern vermeidet auch die enormen Gaskosten, alle Daten im Voraus in den Vertrag einzutragen.

Dadurch, dass nur das Engagement erfasst wird, sind die Transaktionsdaten überprüfbar und gleichzeitig die Kosten stark optimiert. Dies ist eine clevere und effiziente Lösung für das Hochladen von Transaktionsdaten mithilfe der Rollup-Technologie.

Es sollte beachtet werden, dass im eigentlichen Betrieb von Dencun der Merkle-Baum ähnlich wie Celestia nicht zur Generierung von Commitment verwendet wird, sondern der KZG-Algorithmus (Kate-Zaverucha-Goldberg, Polynomial Commitment) verwendet wird.

Im Vergleich zu Merkle tree proof ist der Prozess der Generierung von KZG Proof relativ komplex, aber sein Verifizierungsvolumen ist kleiner und die Verifizierungsschritte sind einfacher. Der Nachteil ist jedoch, dass es vertrauenswürdige Einstellungen (ceremony.ethereum.org, die jetzt beendet wurde) und ist nicht in der Lage, Quantencomputerangriffe zu verhindern (Dencun verwendet die Version-Hash-Methode, und andere Verifizierungsmethoden können bei Bedarf ersetzt werden).

Für das mittlerweile populäre DA-Projekt Celestia wird eine Variante des Merkle-Baums verwendet. Im Gegensatz zu KZG verlässt es sich bis zu einem gewissen Grad auf die Integrität von Knoten, trägt aber dazu bei, die Schwelle für Rechenressourcen zwischen Knoten zu senken und den dezentralen Charakter des Netzwerks beizubehalten.

03. Möglichkeiten in Dencun

Während EIP-4844 die Kosten senkt und die Effizienz für Layer 2 erhöht, erhöht es auch Sicherheitsrisiken, was auch neue Möglichkeiten mit sich bringt.

Um zu verstehen, warum das so ist, müssen wir auf den oben erwähnten Mechanismus der Notluke oder des erzwungenen Rückzugs zurückkommen.

Wenn der Layer-2-Knoten deaktiviert ist, kann dieser Mechanismus sicherstellen, dass Benutzergelder sicher an das Mainnet zurückgegeben werden. Voraussetzung für die Aktivierung dieses Mechanismus ist, dass der Benutzer den vollständigen Zustandsbaum von Layer 2 abrufen muss.

Unter normalen Umständen müssen Benutzer nur einen Layer-2-Full-Node finden, um Daten anzufordern, Merkle-Beweise zu generieren und diese dann an den Mainnet-Vertrag zu übermitteln, um die Legitimität ihrer Abhebung nachzuweisen.

Vergessen Sie jedoch nicht, dass der Benutzer den Fluchtlukenmechanismus aktivieren möchte, um L2 zu verlassen, weil die L2-Knoten böswillig gehandelt haben. In diesem Fall ist die Wahrscheinlichkeit hoch, dass sie nicht die gewünschten Daten von den Knoten erhalten.

Das ist es, was Vitalik oft als Datenvorenthaltsangriff bezeichnet.

Vor EIP-4844 wurden permanente Layer-2-Datensätze im Mainnet aufgezeichnet. Wenn kein Layer-2-Knoten einen vollständigen Off-Chain-Status bereitstellen konnte, konnten Benutzer selbst einen vollständigen Knoten bereitstellen.

Dieser Full Node kann alle historischen Daten, die vom Layer-2-Sequenzer im Mainnet freigegeben werden, über das Ethereum-Mainnet abrufen. Benutzer können den erforderlichen Merkle-Nachweis erstellen und den Nachweis an den Vertrag im Mainnet übermitteln, um die L2-Asset-Entnahme sicher abzuschließen.

Nach EIP-4844 existieren Layer-2-Daten nur noch im BLOB der Ethereum-Vollknoten, und historische Daten vor 18 Tagen werden automatisch gelöscht.

Daher ist die Methode im vorherigen Absatz, den gesamten Zustandsbaum durch Synchronisieren des Mainnets zu erhalten, nicht mehr praktikabel. Wenn Sie den vollständigen Zustandsbaum von Layer 2 erhalten möchten, können Sie sich nur auf Mainnet-Knoten von Drittanbietern verlassen, die alle Ethereum-BLOB-Daten gespeichert haben (die nach 18 Tagen automatisch gelöscht werden sollten), oder auf native Layer-2-Knoten (die selten sind).

Nachdem EIP-4844 live gegangen ist, wird es für Benutzer sehr schwierig sein, den vollständigen Statusbaum von Layer 2 auf absolut vertrauenswürdige Weise zu erhalten.

Ohne eine stabile Möglichkeit für Benutzer, die Layer-2-Zustandsstruktur zu erhalten, können sie unter extremen Bedingungen keine erzwungenen Entnahmevorgänge durchführen. Daher ist EIP-4844 bis zu einem gewissen Grad zu einem Sicherheitsdefizit für Layer 2 geworden.

Um diesen Mangel an Sicherheit auszugleichen, brauchen wir eine vertrauenslose Speicherlösung mit einem positiven Konjunkturzyklus. Storage bezieht sich hier hauptsächlich auf die vertrauenslose Aufbewahrung von Daten in Ethereum, was sich vom Speicherplatz in der Vergangenheit unterscheidet, da es in diesem Fall ein Schlüsselwort "trustless" gibt.

Ethstorage kann das Problem der Vertrauenswürdigkeit lösen und hat zwei Finanzierungsrunden von der Ethereum Foundation erhalten.

Tatsächlich kann dieses Konzept das Potenzial, das das Dencun-Upgrade mit sich bringt, wirklich ausschöpfen, und es verdient unsere Aufmerksamkeit.

Die intuitivste Bedeutung von Ethstorage besteht darin, dass es die verfügbare Zeit von DA BLOB vollständig dezentralisiert verlängern kann, wodurch die Mängel der Layer-2-Sicherheit nach EIP-4844 ausgeglichen werden.

Darüber hinaus konzentrieren sich die meisten bestehenden L2-Lösungen hauptsächlich auf die Skalierung der Rechenleistung von Ethereum, d. h. die Erhöhung der TPS. Die Nachfrage nach der sicheren Speicherung großer Datenmengen im Ethereum-Mainnet ist jedoch stark gestiegen, insbesondere aufgrund der Popularität von dApps wie NFTs und DeFi.

So ist die Nachfrage nach der Speicherung von On-Chain-NFTs riesig, denn die Nutzer besitzen nicht nur Token von NFT-Verträgen, sondern auch das On-Chain-Image. Ethstorage kann die zusätzlichen Vertrauensprobleme lösen, die mit der Speicherung dieser Bilder bei einem Drittanbieter einhergehen.

Schließlich kann Ethstorage auch die Front-End-Anforderungen von dezentralen dApps erfüllen. Aktuell existierende Lösungen werden primär auf zentralen Servern (mit DNS) gehostet. Dieses Setup macht Websites anfällig für Zensur und andere Probleme wie DNS-Hijacking, Website-Hacking oder Serverabstürze, wie Vorfälle wie Tornado Cash zeigen.

Ethstorage befindet sich noch in der ersten Testphase, und Benutzer, die optimistisch sind, was die Aussichten dieses Tracks angeht, können es ausprobieren.

Verzichtserklärung:

1. Dieser Artikel ist ein Nachdruck von [Biteye], Alle Urheberrechte liegen beim ursprünglichen Autor [Biteye]. 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.