Autor: Maggie@Foresight Ventures

TL;DR:

• Das Cancun-Upgrade wird am 13. März 2024 gestartet und EIP4844 wird bald online sein. Danksharding ist der Kern der Ethereum-Roadmap und dieses Upgrade ist der erste Schritt zur Verwirklichung von Danksharding.
• Nach der Anpassung von Ethereum L2 an EIP4844 sind die Transaktionsgebühren deutlich gesunken und der TPS von L2 hat sich verdoppelt. Benutzer werden das Gefühl haben, dass die Transaktionsgeschwindigkeit schneller, die Kosten niedriger, das Erlebnis reibungsloser und die Reaktion schneller ist. Auf diesen L2s wird es komplexere und größere Dapp-Anwendungen geben.
• Optimistische Rollups lassen sich leichter an EIP4844 anpassen, während ZK-Rollups komplexer anzupassen sind. Ethereum verfügt nicht über vorkompilierte Verträge zur Unterstützung der elliptischen Kurven BLS12-381, was einige ZKP-Überprüfungen erschwert und den Fortschritt der ZK-Rollups bei der Anpassung an EIP4844 behindert.
• Das Problem der elliptischen Kurven kann auf zwei Arten gelöst werden: 1. Warten Sie, bis Ethereum die elliptischen Kurven BLS12-381 vorkompiliert hat. 2. Verwenden Sie eine andere Beweismethode, um den gleichen Zweck zu erreichen, und verwenden Sie die von Ethereum unterstützte BN254.
• Derzeit passen sich Arbitrum, Optimistic, Starknet, zkSync, Scroll, Polygon zkEVM und der neue L2 Morph an EIP4844 an. Unter ihnen gaben Arbitrum, Optimistic und Starknet an, dass sie die EIP4844-Anpassung nach dem Cancun-Upgrade implementieren werden. Morph übernahm die Führung bei der Veröffentlichung der innovativen zkSNARK zkEVM-Anpassungslösung, die die erste zkSNARK zkEVM sein wird, die sich an EIP4844 anpasst.

1. Hintergrund

Im Jahr 2020 veröffentlichte Ethereum die „Rollup-centered Ethereum Roadmap“ und die endgültige Version von Ethereum, beschrieben in „Endgame“, veröffentlicht von Vitalik im folgenden Jahr. Das Bild bestimmt die Allgemeine Richtung von Ethereum: Optimierung des Aufbaus der Basisschicht von Ethereum und Bereitstellung von Rollup.

Ethereum hat die Sharding-Technologie von Danksharding eingeführt, um seine Leistung als Datenverfügbarkeitsschicht zu verbessern. Es wird erwartet, dass diese Technologie die L2-Transaktionsgebühren erheblich senken und die TPS von Rollup erhöhen wird, wodurch eine groß angelegte Expansion von Ethereum erreicht wird.

Bis zu diesem Jahr wurde das Ethereum Cancun-Dencun-Upgrade am 13. März 2024 endlich gestartet, und EIP4844 steht kurz davor, online zu gehen. Man kann sagen, dass dieser Hard Fork das erste Mal ist, dass Ethereum diesen Schritt implementiert hat ist der Kern der Ethereum-Roadmap. Bezüglich der DA-Schicht, der technischen Prinzipien von Danksharding und des Inhalts von EIP4844 lesen Sie bitte einen technischen Artikel, den ich letztes Jahr geschrieben habe: DA (Datenverfügbarkeit) Der Sommer steht vor der Tür? https://foresightnews.pro/article/detail/33575

2 Wie kommt das Cancun-Upgrade L2 zugute?

EIP4844 führt einen neuen Transaktionstyp namens Blob-tragende Transaktionen ein. Jede Blob-tragende Transaktion kann eine Liste von Blobs „tragen“. Ein Blob ist ein Datenpaket von etwa 125 KB. Blobs werden für einen kurzen Zeitraum gespeichert, nämlich nur 4096 Epochen, also etwas mehr als 18 Tage.

1. L2-Transaktionsgebühren sind deutlich gesunken. Da Blobs keinen dauerhaften Speicher erfordern, sind Blobs größer und günstiger als Blockspeicher. Blobs können bei gleichem Gasverbrauch zehnmal mehr Daten speichern als Calldata. Ein an EIP4844 angepasstes Rollup kann Transaktionsdaten in Blobs speichern und so die Transaktionsgebühren um eine Größenordnung senken.
2. Der TPS von L2 wird verdoppelt. Derzeit liegt das Ziel pro Block bei 3 Blobs, wobei maximal 6 Blobs erlaubt sind. Blöcke sind nur 90 KB groß und jeder Blob ist etwa 125 KB groß. Die Einführung von Blob entspricht einer mehrfachen Erweiterung des Blockraums zum Speichern von Rollup-Daten, sodass auch die TPS von Rollup verdoppelt werden kann. Und in „On Increasing the Block Gas Limit“ von Toni und Vitalic heißt es, dass durch die Erhöhung des Block-Gas-Limits und des Preises für Calldata-Bytes ungleich Null eine kleinere Blockgröße mit weniger Variablen erreicht wird, sodass mehr hinzugefügt werden kann die Zukunft. Je mehr Blobs, desto größer der Speicherplatz.

Für Endbenutzer: Nachdem Ethereum L2 an EIP4844 angepasst wurde, wird die Transaktionsgeschwindigkeit schneller, die Kosten werden niedriger, das Erlebnis wird reibungsloser und die Reaktion wird reaktionsschneller sein. Auf diesen L2s wird es komplexere und größere Dapp-Anwendungen geben.

3. Wie passt sich L2 an EIP4844 an?

Wie passt sich L2 an EIP4844 an? Wir müssen Optimistic Rollup und ZK Rollup separat besprechen.

Optimistic Rollups passen sich an EIP4844 an

Optimistic Rollup verwendet Betrugssicherheit, um die Richtigkeit bei der Ausführung des Rollups sicherzustellen. Der Knoten geht davon aus, dass der Zustandsübergang korrekt ist, es sei denn, jemand legt innerhalb der angegebenen Zeit ein Betrugszertifikat vor, aus dem hervorgeht, dass der zuvor übermittelte Zustandsübergang illegal ist. In diesem Fall wird der Zustandsübergang abgebrochen.

Im Vergleich zu ZK Rollup lässt sich Optimistic Rollup einfacher an EIP4844 anpassen. Es müssen lediglich Layer-2-Transaktionen über Blob-tragende Transaktionen an Layer 1 übermittelt werden, um die Anpassung abzuschließen. Darüber hinaus ist auch eine Anpassung des Betrugsnachweises an die Anforderungen von EIP4844 erforderlich, obwohl dieser Teil schrittweise erfolgen kann. Tatsächlich haben viele Optimistic Rollup-Projekte noch keine betrugssicheren Funktionen eingeführt. Obwohl Betrugsbeweise eingeführt wurden, wurde in den letzten zwei Jahren kein einziger Betrugsbeweis vorgelegt.

1. L2-Transaktionsübermittlung: Wenn das Rollup übermittelt wird, wird die Blob-tragende Transaktion verwendet, um die Rollup-Daten im Blob zu speichern. Die Nutzlast der Blob-tragenden Transaktion ist rlp([tx_payload_body, blobs, commitments, proofs]), wobei

• tx_payload_body- der TransactionPayloadBody der standardmäßigen EIP-2718-Blob-Transaktion ist.
• Blobs – Liste der Blobs. Eine Transaktion kann bis zu zwei Blobs enthalten.
• Verpflichtungen – Blobs KZG-Verpflichtungsliste.
• Proofs- Blob- und Proof-Liste entsprechend der KZG-Verpflichtung. Dieser Nachweis wird vom ETH-Knoten überprüft.

• Zuerst benötigen der Prüfer und der Herausforderer mehrere Interaktionsrunden, um den Streitpunkt zu finden.
• Dann reichen Sie den Streitpunkt zur Beurteilung an L1 ein. Zur Anpassung an EIP4844 muss möglicherweise nachgewiesen werden, dass die betreffenden Daten auf einem bestimmten Blob gespeichert sind.
• Da Blob-Daten nach etwa 18 Tagen gelöscht werden, muss der Challenge-Zeitraum vor dem Löschen liegen, was durch aktuelle optimistische Rollups erfüllt wird. Der Challenge-Zeitraum beträgt in der Regel nicht mehr als 7 Tage.

ZK-Rollups passen sich an EIP4844 an

ZK-Rollup verwendet ZKP, um zu beweisen, dass der L2-Statusübergang korrekt ist. Die Anpassung des ZK-Rollups an EIP4844 ist komplizierter als das optimistische Rollup.

1. L2-Transaktionseinreichung: Dieser Schritt des Optimistic Rollup ist ähnlich.

2. ZK-Beweiseinreichung: Im Vergleich zum ZK-Rollup vor der Anpassung ist zusätzlich zum ZKP-Nachweis des Zustandsübergangs ein weiterer Nachweisprozess erforderlich. Das heißt, es wird bewiesen, dass die Blob-Verpflichtung und der Transaktionsstapel übereinstimmen, wodurch sichergestellt wird, dass die Eingabe des Zustandsübergangsnachweises korrekt ist.

   Zum Beispiel: Die ZK-Schaltung des Zustandsübergangs kann einen Beweis für den Berechnungsprozess a + a = b generieren. Der ZKP, der generiert wird, wenn (a=1,b=2) und (a=2,b=4) ist legal. Daher muss ich auch einen Beweis dafür erbringen, dass die Eingabe, die ich damals gemacht habe, (a=1,b=2) statt (a=2,b=4) war.

   Dies muss nicht vor der Anpassung an EIP4844 erfolgen, da die Daten direkt in Calldata gespeichert werden und direkt gelesen werden können, sodass die Eingabe nicht angepasst wird. Nach Verwendung von EIP4844 können die Blob-Daten nicht direkt gelesen werden, und dies kann nur durch eine neue Schaltung nachgewiesen werden.

   Es ist einfacher, diesen Beweismechanismus mit dem ZK-Rollup von STARK (wie Starknet) zu implementieren. Dies ist eine Herausforderung für das ZK-Rollup mit SNARK. Der Grund dafür ist: Die elliptische Kurve, die von der Blob-Verpflichtung von EIP4844 verwendet wird, ist BLS12-381, während der vorkompilierte ETH-Vertrag nur BN254 unterstützt, was für uns schwierig ist Überprüfen Sie den Nachweis des Abschlusses der Blob-Verpflichtung im Smart-Vertrag.

3. Die Verwendung von zkEVM/zkVM von SNARK muss das in Punkt 2 erwähnte Problem lösen, dass der ZK-Beweis aufgrund einer Kurveninkongruenz nicht generiert werden kann.

• Warten darauf, dass Ethereum die vorkompilierten BLS12-381-Verträge unterstützt. Das wird lange dauern.
• Gehen Sie einen anderen Weg, um es zu beweisen. Um neue Schaltkreise zu entwerfen, müssen Sie die elliptische Kurve BN254 verwenden, die vom vorkompilierten Vertrag unterstützt wird. Derzeit sehen wir, dass Morph diesen Ansatz verfolgt. Damit ist Morph auch das erste zkEVM, das die EIP4844-Anpassung abgeschlossen hat.

Morphs EIP-4844 zkEVM-Integrationslösung finden Sie unter: https://medium.com/@morphlayer2/morphs-solution-to-eip-4844-zkevm-integration-7f469910478f

IV. Welche Sind L2s an EIP4844 angepasst?

Optimistic Rollup lässt sich relativ einfach an EIP4844 anpassen.

• Arbitrum wird am 14. März das Arb OS20-Upgrade starten, um die EIP-Änderungen für das Cancun-Upgrade umzusetzen (Artikellink). Arbitrum gehört zum Stage 1 Rollup. Sowohl die Transaktionseinreichung als auch der Betrugsnachweis müssen an EIP4844 angepasst werden, und die Sicherheit ist relativ gut.
• Optimism hat am 14. März das Ecotone-Upgrade gestartet, um die Anpassung abzuschließen(Artikellink). Optimistisches Rollup ist ein Rollup der Stufe 0. Es gibt derzeit keinen Betrugsnachweis. Es ist einfacher anzupassen, aber die Sicherheit ist nicht hoch genug. Nach Abschluss der Anpassung werden auch alle Super-Chain-Netzwerke im Op-Ökosystem von EIP-4844 profitieren.

Beim ZK-Rollup ist die Schwierigkeit der Rollup-Anpassung mit STRAK und SNARK unterschiedlich.

• Es ist einfacher, EIP4844 mit dem Rollup von STARK anzupassen, und Starknet ist einer der Vertreter.
• Starknet hat einen Artikel veröffentlicht, der besagt, dass Cancun die EIP4844-Anpassung nach dem Upgrade implementieren wird (Artikellink).
• zkSync wurde über Boojum aktualisiert, damit zkSync den Übergang von SNARK auf STARK-Proof abschließen kann. Dies ist auch eine Vorbereitung für das EIP4844-Upgrade. Boojun ist ein auf STARK basierendes Beweissystem. (Link zum Artikel)
• Die Anpassung an das Rollup von SNARK ist relativ kompliziert.

Das obige ist der detaillierte Inhalt von. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!