Das Cancun-Upgrade steht vor der Tür. Welche Anpassungen haben die Mainstream-L2 vorgenommen?

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.
• Nachdem Ethereum L2 an EIP4844 angepasst wurde, sind die Transaktionsgebühren deutlich gesunken und der TPS von L2 hat sich verdoppelt. Benutzer werden das Gefühl haben, dass Transaktionen schneller, kostengünstiger, reibungsloser und reaktionsschneller ablaufen. Auf diesen L2s wird es komplexere und größere Dapp-Anwendungen geben.
• Optimistische Rollups lassen sich einfacher an EIP4844 anpassen, während ZK-Rollups komplizierter 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 BLS12-381-Kurven vorkompiliert hat. 2. Verwenden Sie eine andere Beweismethode, um den gleichen Zweck zu erreichen, indem Sie BN254 verwenden, das von der Ethereum-Vorkompilierung unterstützt wird.
• 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 einer innovativen zkSNARK-zkEVM-Anpassungslösung, die die erste zkSNARK-zkEVM-Anpassung an EIP4844 sein wird. 1. Hintergrund: Im Jahr 2020 veröffentlichte Ethereum eine Roadmap mit Rollup als Kerninitiativen, die den Weg für die Zukunft weisen Entwicklung. Anschließend beschrieb Vitalik die endgültige Vision von Ethereum im „Endgame“ des zweiten Jahres, wobei er die Optimierung der Basisschichtkonstruktion hervorhob und Unterstützung für Rollup bereitstellte. Diese Maßnahmen haben die Hauptrichtung der zukünftigen Entwicklung von Ethereum klargestellt und den Grundstein für das kontinuierliche Wachstum des Blockchain-Ökosystems gelegt.

Ethereum hat die Danksharding-Sharding-Technologie eingeführt, um seine Stabilität als Datenverfügbarkeitsschicht zu verbessern. Es wird erwartet, dass diese Technologie die L2-Transaktionsgebühren senkt, die Anzahl der Rollup-Transaktionen pro Sekunde erhöht und den Umfang des Ethereum-Netzwerks weiter erweitert.

Seit diesem Jahr wurde das Ethereum Cancun-Dencun-Upgrade schließlich am 13. März 2024 mit der bevorstehenden Einführung von EIP4844 veröffentlicht. Dieser Hard Fork gilt als erster Schritt für Ethereum zur Implementierung von Danksharding und ist ein entscheidendes Glied in 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-Carry-Transaktionen ein. Jede Blob-tragende Transaktion hat die Fähigkeit, eine Liste von Blobs zu „tragen“. Ein Blob ist ein Datenpaket mit einer Größe von etwa 125 KB. Die Speicherzeit von Blob ist relativ kurz, nur 4096 Epochen, etwa 18 Tage.

L2-Transaktionsgebühren sind deutlich gesunken. Da Blobs keinen permanenten Speicher erfordern, sind Blobs größer und kostengü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.

Der TPS von L2 wurde verdoppelt. Das aktuelle Ziel sind 3 Blobs pro Block, wobei maximal 6 Blobs zulässig 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.

• Nach der Anpassung an EIP4844 bietet Ethereum L2 Endbenutzern schnellere Transaktionen, geringere Kosten, ein reibungsloseres Erlebnis und reaktionsschnellere Antworten. Dadurch werden komplexere und umfangreichere Dapp-Anwendungen auf die L2-Plattform gebracht.
• 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 passt sich an EIP4844 an

Optimistic Rollup ist eine Technologie, die die Korrektheit der Rollup-Ausführung durch Betrugssicherheit gewährleistet. Bei diesem Mechanismus gehen Knoten davon aus, dass der Zustandsübergang korrekt ist, es sei denn, jemand schlägt innerhalb der angegebenen Zeit einen Betrugsbeweis vor, um zu beweisen, dass der Zustandsübergang illegal ist. Sobald ein Betrugsnachweis vorliegt, werden zuvor eingereichte Zustandsübergänge widerrufen.

Optimistic Rollup lässt sich einfacher an EIP4844 anpassen als ZK-Rollup. Übermitteln Sie alle L2-Transaktionen über Blob-tragende Transaktionen an L1, um die Anpassung abzuschließen. Darüber hinaus muss der Betrugsnachweis angepasst werden, um ihn an EIP4844 anzupassen. Dieser Teil kann langsam durchgeführt werden. Schließlich haben viele optimistische Rollups noch keine Betrugsbeweise eingeführt. Ich habe ein Betrugszertifikat online gestellt, aber festgestellt, dass seit mehr als zwei Jahren kein Betrugszertifikat eingereicht wurde.

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

• tx_payload_body- der TransactionPayloadBody der standardmäßigen EIP-2718-Blob-Transaktion ist.
• Blobs – Blob-Liste. 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.

Anpassen des Betrugsnachweises:

• 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-Beweis des Zustandsübergangs ein weiterer Beweisprozess 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.
3. 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.
4. 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.
5. 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, dass die vom Blob-Commitment von EIP4844 verwendete elliptische Kurve BLS12-381 ist und der vorkompilierte ETH-Vertrag nur BN254 unterstützt. Aufgrund der unterschiedlichen Kurven ist es für uns schwierig, sie direkt zu verwenden Überprüfen Sie das Abschlusszertifikat der Blob-Verpflichtung im Vertrag.
6. 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

4. Was sind die L2-Anpassungen? Hast du EIP4844?

Im Optimistic-Rollup haben Optimism und Arbitrum ihr Engagement für die Einführung von EIP-4844 zum Ausdruck gebracht und arbeiten eng mit ihren Communities zusammen, um die erforderlichen Updates zu testen und bereitzustellen. Arbitrum ist ein Rollup der Stufe 1 und bietet eine relativ gute Sicherheit. Dies erfordert die Anpassung der Betrugssicherheit an EIP4844. Optimistisches Rollup ist ein Rollup der Stufe 0. Es gibt derzeit keinen Betrugsnachweis. Es ist einfacher anzupassen, aber die Sicherheit ist nicht hoch genug.

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). Mit dem SNARK-Rollup untersucht zkSync auch, wie Blob-tragende Transaktionen genutzt werden können, um die Kosten weiter zu senken und die Leistung zu verbessern. Scroll veröffentlichte letztes Jahr einen Artikel, in dem er die Idee der Anpassung von EIP4844 vorstellte (Artikellink).

Das Beeindruckendste ist Morph, ein optimistischer ZK-Rollup, der als erster eine Lösung für zkEVM zur Anpassung an EIP4844 veröffentlicht hat soll das erste zkEVM-Rollup sein, das EIP4844 abgeschlossen hat.

Optimistic ZK Rollup vereint die Vorteile beider Rollup-Arten. Es glaubt optimistisch an die von Sequencer übermittelten Ausführungsergebnisse und ermöglicht es denjenigen, die Zweifel an den Ergebnissen haben, Herausforderungen zu starten. Nur wenn eine Herausforderung ausgegeben wird, generiert der Prüfer ZKP, um die Richtigkeit der Ausführungsergebnisse zu beweisen. Es verfügt über die Effizienz von Optimistic Rollup und die ZK-erprobte Zuverlässigkeit von ZK Rollup.

Das obige ist der detaillierte Inhalt vonDas Cancun-Upgrade steht vor der Tür. Welche Anpassungen haben die Mainstream-L2 vorgenommen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!