Die Vergangenheit, Gegenwart und Zukunft der Cancun-Upgrades

Vergangenes Leben

**Warum ist das Cancun-Upgrade erforderlich? **

• Die Vision von Ethereum ist es, unter der Prämisse der Dezentralisierung skalierbarer und sicherer zu werden. Auch das aktuelle Upgrade von Ethereum hat sich der Lösung dieses Trilemmas verschrieben, steht aber vor großen Herausforderungen.
• Probleme mit Ethereum:
• Derzeit gibt es niedrige TPS und Leistung, hohe Gasgebühren und ernsthafte Überlastungen. Gleichzeitig wächst auch der für den Betrieb eines Ethereum-Clients erforderliche Speicherplatz schnell. Im Grunde geht es um die Arbeit zur Gewährleistung der Sicherheit und Dezentralisierung von Auch die Auswirkungen des Volumenkonsensalgorithmus auf die gesamte Umgebung von Ethereum werden immer bedeutender.
• Daher unternimmt Ethereum derzeit unter der Prämisse der Dezentralisierung die Frage, wie man mehr Daten übertragen und Gas reduzieren kann, um die Skalierbarkeit zu verbessern, und wie man den Konsensalgorithmus optimiert, um die Sicherheit zu gewährleisten.
• Um das Trilemma aus Sicherheit, Dezentralisierung und Skalierbarkeit zu lösen, hat Ethereum den PoW-to-PoS-Mechanismus verwendet, um den Knotenschwellenwert weiter zu senken, und plant außerdem, die Beacon-Kette zu verwenden, um Prüfer nach dem Zufallsprinzip zuzuweisen, um die Sicherheit zu optimieren. Kurz gesagt Aufgrund der Skalierbarkeit erwägt Ethereum den Einsatz von Sharding, um die Arbeitslast der Knoten zu reduzieren, was es Ethereum auch ermöglicht, mehrere Blöcke gleichzeitig zu erstellen und seine Skalierbarkeit zu verbessern.
• Der aktuelle Platz jedes Ethereum-Blocks beträgt etwa 200–300 KB, die Mindestgröße jeder Transaktion beträgt etwa 100 Bytes, also etwa 2000 Transaktionen, geteilt durch die Blockzeit von 12 Sekunden, die Obergrenze von TPS von Ethereum ist auf etwa 100 begrenzt. Diese Daten können offensichtlich nicht den Bedarf von Ethereum decken.
• Daher konzentriert sich Ethereum Layer 2 darauf, wie große Datenmengen in den Block eingefügt werden Im Weltraum wird die Sicherheit durch Betrugs- und Gültigkeitsnachweise gewährleistet, weshalb die DA-Schicht die Obergrenze der Sicherheit bestimmt, was auch der Kerninhalt des Cancun-Upgrades ist.
• Die iterative Route der Ethereum-Ökologie kann die Leistung des Benchmarks Solana (in Bezug auf Verzögerung und Durchsatz) nicht erreichen, und die Fragmentierungsleistung von Near wird kurzfristig nicht zu sehen sein, ebenso wenig wie die parallele Ausführungsleistung von Sui und Aptos. Kurzfristig kann Ethereum nur eine mehrschichtige Struktur mit Rollup als Kern aufbauen, daher wird Cancun aktualisiert, um TPS und Gas zu lösen Gebühren und Entwicklererfahrung sind für die Ethereum-Roadmap von entscheidender Bedeutung.

**Wie ist die Ethereum-Roadmap geplant? **

Die letzten wichtigen Upgrades und ihre Ziele

• 2020Jahr12Monat1* Die Beacon-Kette wird offiziell veröffentlicht und ebnet den Weg für ein POS-Upgrade*
• 2021**8Monat5** London-Upgrade, EIP1559 verändert das Wirtschaftsmodell von Ethereum;
• 2022Jahr9Monat15* Paris-Upgrade (The Zusammenführen), abgeschlossen POW-Wechsel POS;*
• 2023Jahr4Monat12* In Shanghai aufgerüstet, das Problem der Pfandrücknahme gelöst;*
• Das Wirtschaftsmodell und POS-bezogene Upgrades wurden abgeschlossen, und die nächsten paar Upgrades haben die Probleme der Leistung von Ethereum, TPS und Entwicklererfahrung gelöst;
• Der nächste Schritt besteht darin, sich auf die Ethereum-Roadmap zu konzentrieren Die Anstieg .
• Ziel: Erreichen Sie mehr als 100.000 TPS im Rollup.
• Es gibt 2 Schemata, On-Chain und Off-Chain:
• Off-Chain-Lösung: bezieht sich auf Layer2, einschließlich Rollup usw.
• On-Chain-Schema: Bezieht sich auf das Vornehmen von Änderungen direkt in L1, einem beliebten Sharding-Schema. Ein einfaches Verständnis von Sharding besteht darin, alle Knoten in verschiedene Bereiche zu unterteilen und die Aufgaben jedes Bereichs zu erledigen, wodurch die Geschwindigkeit effektiv erhöht wird.
• Sharding-Schema-Analyse:
• Das Dilemma des Sharding-Schemas: Früher umfasste Sharding Status-Sharding, Transaktions-Sharding usw., aber die Synchronisierung zwischen verschiedenen Shards stellt ein Problem dar. Derzeit ist es schwierig, eine groß angelegte Netzwerkknoten-Datensynchronisierung durchzuführen. , nicht nur kann die MEV-Situation nicht lösen, sondern erfordert möglicherweise auch eine große Anzahl von Patches, um verschiedene auftretende Probleme auszugleichen, die kurzfristig nicht realisiert werden können.
• Danksharding ist ein neues Sharding-Design, das für Ethereum vorgeschlagen wurde. Seine Kernidee ist Zentralisierte Blockproduktion + Dezentrale Verifizierung + **Resistenz gegen Zensur,**Dies hängt auch mit der unten erwähnten Datenverfügbarkeit zusammen Sampling (DAS), Block Producer-Packer Separation (PBS) und Censorship Resistance List (Crlist). Die größte Bedeutung der Kernidee von Danksharding liegt darin, Ethereum L1 in eine einheitliche Siedlung (Abrechnung) und Datenverfügbarkeit (Datenverfügbarkeit) umzuwandeln. Verfügbarkeit）层.

Das Sharding-Schema ist in 2 Schritte unterteilt, derzeit ist es in Proto- unterteilt. Sharding undFully-Rollup*****. ***

• Daher- dankesharding**:**
• einführen: Unterstützen Sie die Reduzierung der L2-Gebühren und erhöhen Sie den Durchsatz durch die Einführung von Blobs , gleichzeitig als Pre-Sharding-Lösung, um den Weg für das vollständige Sharding zu ebnen. Es wird erwartet, dass die Implementierung von Danksharing nach dem Proto-Danksharding zwei bis fünf Jahre dauern wird.
• Inhalt: Das Hauptmerkmal von Proto-Danksharding ist die Einführung einer neuen Art von Blob-Transaktion. Blob zeichnet sich durch große Kapazität und niedrige Kosten aus. Durch das Hinzufügen solcher Datenpakete zu Ethereum können alle Rollup-Daten im Blob gespeichert werden, was erheblich ist entlastet die Hauptkette. Der Speicherdruck kann auch die Rollup-Kosten senken.
• Vollständiges Rollup
• Einführung: Rollup ist vollständig erweitert und konzentriert sich auf die Nutzung der Datenverfügbarkeit.
• Inhalt:
• P2P-Design von DAS: einige Arbeiten und Untersuchungen im Zusammenhang mit Daten-Sharding-Netzwerkverbindungsproblemen;
• Datenverfügbarkeits-Sampling-Client: Entwickeln Sie einen einfachen Client, der durch zufälliges Abtasten einiger Kilobyte schnell feststellen kann, ob Daten verfügbar sind.
• Effiziente DA-Selbstheilung: Kann alle Daten unter den schlimmsten Netzwerkbedingungen (z. B. böswilliger Validator-Angriff oder langfristige Ausfallzeit großer Blockknoten) effizient wiederherstellen.

Treffen der Ethereum-Kernentwickler

Jedes Upgrade von Ethereum hängt vom Kernentwicklertreffen ab, durch die gemeinsame Diskussion der Kernmitwirkenden und gemäß einer Reihe von Vorschlägen der Entwickler wird die zukünftige Entwicklungsrichtung festgelegt

*Definition: Das Kernentwicklertreffen ist eine wöchentliche Telefonkonferenz der Ethereum-Entwicklergemeinschaft, bei der Hauptmitwirkende verschiedener Organisationen technische Fragen diskutieren und zukünftige Arbeiten an Ethereum koordinieren. Sie legen die zukünftige technische Ausrichtung des Ethereum-Protokolls fest und sind auch die Autorität, die tatsächlich Entscheidungen über das Upgrade von Ethereum trifft. Sie sind dafür verantwortlich, zu entscheiden, ob EIP im Upgrade enthalten ist, ob eine Änderung der Roadmap erforderlich ist und andere wichtige Dinge Angelegenheiten.

• Kernprozess: Der auf EIP ausgerichtete Upgrade-Prozess läuft ungefähr wie folgt ab: Zuerst wird ein EIP zunächst auf der Kernentwicklerkonferenz (kurz ACD) akzeptiert, und dann wird es vom Kundenteam getestet, unabhängig davon, ob das EIP darin enthalten ist Aktualisieren oder nicht, und überprüfen Sie es nach dem letzten Test noch einmal und entscheiden Sie dann basierend auf der Diskussion, ob es in das eigentliche Upgrade einbezogen werden soll.
• Konferenzen sind in 2 Kategorien unterteilt, nämlich das Treffen der Konsensebene und das Treffen der Führungsebene, die abwechselnd alle zwei Wochen stattfinden:
• ** Treffen der Konsensebene (Alle Konsens der Kernentwickler – ACDC), der sich auf die Ethereum-Konsensschicht (Proof of Stake, Beacon-Kette usw.) konzentriert;**
• Meeting auf Führungsebene ( Alle Core Developers-Lösung – ACDE**), die sich auf die Ausführungsschicht von Ethereum (EVM, **Gas Schedule usw.) konzentriert.
• Es gibt drei Arten von Ethereum-Kernbetreuern, hauptsächlich offizielle Organisationen oder freiwillige Foren, die Vorschläge diskutieren:
• AllCoreDevs: Code-Betreuer, verantwortlich für den ETH1-Netzwerk-Client, Upgrade, Wartung des Ethereum-Codes und der Kernarchitektur;
• Abschnitt „Projektmanagement“: Unterstützung von Ethereum-Entwicklern, Koordinierung von Hard Forks, Überwachung von EIP usw. und direkte Unterstützung von AllCoreDevs bei Kommunikation und Betrieb;
• Äther Magier: Ein „Forum“, das Diskussionen rund um EIP und andere technische Themen wünscht.

Zeitleiste der eskalationsbezogenen Treffen in Cancun

*Je nach Inhalt der Diskussion kann dieses Cancun-Upgrade grob in 5 Phasen unterteilt werden. ***

Phase 1 – Einführung von Upgrade-Themen

Neue Aufgaben einführenProto-Danksharding*****,EOF und „Selbstzerstörung“ * Opcode, oberflächliche Diskussion des Shanghai-Upgrade-Inhalts*

• Nachdem die Fusion von Ethereum am 15. September 22 abgeschlossen war, wurde das Entwicklertreffen für vier Wochen ausgesetzt, sodass Entwickler einen Monat lang die im nachfolgenden Upgrade besprochene EIP überprüfen konnten.
• Am 28. und 22. Oktober schlug das erste Entwicklertreffen nach der Fusion erstmals die Implementierung von Proto-Danksharding, EOF und dem Opcode „Selbstzerstörung“ vor. Zu diesem Zeitpunkt ist der spezifische Umfang von Proto-Danksharding noch nicht festgelegt. und einige Entwickler sind meiner Meinung nach vorläufig. Das Shanghai-Upgrade kann in mehrere kleine Upgrades unterteilt werden, z. B. zuerst die Aktivierung zugesagter ETH-Abhebungen und dann die Aktualisierung von EIP 4844, aber eine andere Gruppe von Entwicklern hält es für sinnvoller, ein größeres Upgrade in einem Schritt durchzuführen.

Phase 2 – Festlegung des Zeitrahmens und Vorbereitung auf die KZG-Zeremonie

Am Ende des Jahres 2022 dreht sich die Ethereum-Konferenz hauptsächlich um ***EOF und EIP 4844 Diskussion, während EIP weiterhin beworben wird 4844 Die für die ***—KZG-Zeremonie erforderliche vorläufige Einstellungszeremonie wird von den Entwicklern am *******23 durchgeführt. **** Jahr **** 1 **** Monat offiziell bestätigt, welches Upgrade **** 4844 **** in *** erscheinen wird

• Am 22. November wurde EOF oder Proto-Danksharding in der Telefonkonferenz Nr. 149 aller Kernentwickler von Ethereum erwähnt. Derzeit erwägen Entwickler noch, es in das Shanghai-Upgrade aufzunehmen;
• In der Konsensebenensitzung am 2. Dezember 22, Trent, der Leiter des Ethereum-Ökosystems Van Epps hat die EIP aktualisiert 4844 Fortschritt bei der Implementierung der erforderlichen vertrauenswürdigen Setup-Zeremonie zum Generieren eines In 4844 verwendeter Sicherheitscode. Van Epps hofft, dass die Zeremonie eine der größten aller Zeiten im Krypto-Bereich sein wird und 8.000 bis 10.000 Spenden gesammelt werden. Der öffentliche Spendenzeitraum für die Zeremonie wird etwa zwei Monate dauern und irgendwann im Dezember beginnen.
• Beim Kernentwicklertreffen am selben Tag gab es einige Diskussionen über EOF und die Deaktivierung des Selbstzerstörungs-Opcodes. Ein Entwickler der Ethereum Foundation lehnte die Verschiebung von EOF nach Cancun ab und argumentierte, dass dies der Fall sein würde, wenn die Codeänderungen nicht in Shanghai berücksichtigt würden Die Möglichkeit, nach Cancun zu gelangen, ist sehr gering. In Bezug auf den Selbstzerstörungscode gibt es derzeit Entwickler, die eine Weiterentwicklung des EIP befürworten 4758, aber die direkte Deaktivierung dieses Opcodes wird einige Anwendungen beschädigen, und der Entwickler ist der Meinung, dass dieser EIP noch einmal für eine Weile abgewogen werden sollte, bevor ein Randfall zum Schutz dieser Vertragsart erstellt wird;
• Beim Kernentwicklertreffen am 9. Dezember 22 wurde die Umsetzung der KZG-Zeremonie hinsichtlich des Cancun-Upgrades und des aktuellen EIP gefördert 4844 Die erforderliche vertrauenswürdige Einrichtungszeremonie ist fertig;
• In der Konsensebenensitzung am 16. und 22. Dezember zum Thema EIP 4844 diskutierten die Entwickler über die Zusammenführung von zwei unterschiedlichen Pull Requests (PRs) in der Spezifikation für Proto-Danksharding, einer bezog sich darauf, wie Knoten die Datenverfügbarkeit über einen bestimmten Punkt hinaus nach der Datenbereinigung handhaben, und einer, wenn ein Block neue Fehlercodes einführt, um zu warnen Knoten, wenn Informationen zu Blobs fehlen
• Während des Kernentwicklertreffens am 5. Januar 23 einigten sich die Entwickler darauf, Codeänderungen im Zusammenhang mit der EOF-Implementierung aus dem Shanghai-Upgrade zu entfernen. Beiko schlug zu diesem Zeitpunkt vor, nach zwei Wochen zu entscheiden, ob EOF in das Upgrade von Cancun einbezogen werden sollte;

Phase III – Vorbesprechung des Umfangs des Vorschlags

Am Ende des Jahres 231******** zog EOF****** zur Beförderung nach Cancun Nach dem Umzug aus Shanghai Promotion drehen sich seitdem 2 Monate hauptsächlich um EOF** und EIP Andere Vorschläge außer 4844* wurden diskutiert, und gleichzeitig wurde ***EOF vorgeschlagen, Cancun zu verlassen. Diese Zeit wurde hauptsächlich damit verbracht, den Umfang der Vorschläge für die Modernisierung von Cancún abzustecken. ***

• Beim Kernentwicklertreffen am 20. Januar 23 wurde EOF zur Aktualisierung nach Cancun verlegt;
• Beim Kernentwicklertreffen am 6. März 23 lautete der vorläufige Vorschlag für das Cancun-Upgrade: EIP 4788 (Staatswurzel der öffentlichen Beacon-Kette), EIP 2537 (Effiziente Durchführung von Vorgängen wie BLS-Signaturüberprüfung und SNARKs-Überprüfung), EIP-5920 (führt den neuen Opcode PAY ein) und EIP Eine kombinierte Implementierung von 6189 (um SELFDESTRUCT mit Verkle-Bäumen kompatibel zu machen) und EIP-6190 (Änderung der SELFDESTRUCT-Funktion, um nur eine begrenzte Anzahl von Zustandsänderungen zu verursachen);
• Im Kernentwicklertreffen am 16. und 23. März, außer EOF und EIP 4844 wurden die folgenden Vorschläge für die Aufnahme in Cancun in Betracht gezogen: SSZ-Format, SELFDESTRUCT-Löschung, EIP 2537, EVMMAX, EIP

1153. Unbegrenzte SWAP- und DUP-Anweisungen, Einführung von PAY-Codes und Beacon-State-Roots im EVM;

• Beim Kernentwicklertreffen am 30. März 23 wurde zum ersten Mal der Vorschlag EIP-6780 zur Deaktivierung von SELFDESTRUCT vorgelegt, der auch der Vorschlag zur Deaktivierung von SELFDESTRUCT ist, für dessen Verwendung sich Cancun schließlich entschieden hat. Aber was die Implementierung von EOF von Erigon betrifft (EL) Ein Entwickler im Kundenteam sagte EOF „Zu viel Veränderung“, um mit dem Ethereum-Verbesserungsvorschlag EIP beim bevorstehenden Cancún-Upgrade zu konkurrieren 4844 gab es kurz nach dem Cancun-Upgrade einen Vorschlag, EOF in der Hard Fork zu implementieren;

Die vierte Stufe – Bestimmen Sie die klare Richtung der Angebotsaktualisierung und löschen Sie irrelevante Vorschläge

Im 23***4Monat gibt es eine klare Richtung für die Vorschläge, die durch das Cancun-Upgrade abgedeckt werden sollen, und die Schlüsselknoten sind da 4 ***************************************** ************************************************** *********** EIP und **tim führten ebenfalls eine ausführlichere Diskussion über die alternativen Vorschläge, in 4Monat In der Sitzung am 27,EIP 6780、*EIP 6475 und *EIP 1153 soll in Cancun enthalten sein, und gleichzeitig *EOF und EVMMAX (mit * ***EOF **implementierungsbezogener EIP-Teilsatz) wurde aus dem Cancun-Upgrade entfernt, EOF-Upgrade hilft hauptsächlich EVM führt die Versionskontrolle durch und kann mehrere Vertragsregelsätze gleichzeitig ausführen, was die spätere Erweiterung von Ethereum unterstützt, aber unter Berücksichtigung der Machbarkeit des gesamten Upgrades ** * EOFDas Upgrade kann mit dem täglichen Upgrade fortgeführt werden

• 23****4Monat12****, das Upgrade von Ethereum Shanghai ist abgeschlossen;
• Während des Core-Dev-Meetings am 13.04.23 diskutierten die Entwickler das EIP 4844 (zur Offenlegung von Daten über den CL-Statusstamm im EL) werden mindestens neun weitere EIPs für das Upgrade in Betracht gezogen, nämlich EIP 4844**, SELFDESTRUCT REMOVE (EIP-6780, EIP 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIPs（EIP 6601 und EIP 6690), SS Änderungen（EIP 6475、EIP 6493、EIP 6465、EIP 6404 und EIP 6466 ）、EIP 5656 und****EIP 6193**；
• Beim Kernentwicklertreffen am 27. und 23. April standen verschiedene Fortschritte und Kompromisse im Mittelpunkt. Erstens wird EIP4844 weiterhin für die Aufnahme in das Cancun-Upgrade identifiziert, wobei die folgenden EIPs hinzugefügt werden: EIP 6780 (Ändert die Funktionalität des SELFDESTRUCT-Opcodes), EIP 6475 (Ein neuer SSZ-Typ (Simple Serialization) zur Darstellung optionaler Werte), EIP 1153 (fügen Sie einen neuen Opcode zum Betriebsstatus hinzu); zweitens ist das EIP, das in Betracht gezogen wird, aber nicht offiziell im Upgrade enthalten ist, EIP 6913 (Einführung der SETCODE-Anweisung), EIP 6493 (Definieren Sie ein Signaturschema für SSZ-codierte Transaktionen), EIP 4788 (Beacon-Chain-Block-Root im EL-Block-Header offenlegen), EIP 2537 (fügt die BLS12-381-Kurve als Vorkompilierung hinzu) und EIP 5656 (führt neue EVM-Anweisungen zum Kopieren von Speicherbereichen ein); schließlich EOF ** und ** EVMMAX** (** EOF ** Implementierungsabhängig ** * EIP* Teilmenge) wurde aus dem Cancun-Upgrade entfernt. **EOF Das Upgrade wurde auf der Ethereum Developers Conference Anfang ****2023****1**** aus Shanghai verlegt und anschließend von * aktualisiert *** Vom Ende von 1 bis zum Anfang von 4 im Jahr 23**** wird es standardmäßig im Cancun-Upgrade angezeigt, jedoch in ** 23** **EOF **wurde im Entwicklertreffen am 29, 4 wieder entfernt. **

Die fünfte Phase – endgültige Vorschlagsfindung und Detailverbesserung

235Monate optimieren und verbessern hauptsächlich die Details des endgültigen Vorschlags,SSZ-> Die RLP-Änderungen führen dazu, dass die beidenSSZs in Cancun nicht mehr benötigt werden EIPs*****, alsoEIPs 6475 und 6493 werden für Upgrades aus Cancun verlegt. Gleichzeitig wurde in der Kernbesprechung am 26-Tag Tim Beiko empfiehlt, zukünftige Gespräche über die Erweiterung der Reichweite von Cancun auf die folgenden fünf zu beschränkenEIP:*EIP-5920 * ,5656,7069,4788 und ****2530 * ****. Die Entwickler haben nun den vollständigen Umfang des Cancun-Upgrades ermittelt. ***

*Ethereum Core Consensus-Sitzung am 05.05.23, in der das zuletzt erwähnte EIP besprochen wird 4788, beim Hinzufügen der EIP 6987 und EIP In der Diskussion in 6475 geht es bei diesen beiden Vorschlägen um Verifizierer bzw. SSZ-Transaktionen;

• Beim 161. Treffen der Ethereum-Führungsebene am 11. Mai 23 sagte Tim Beiko sagte, dass der Umfang des Cancun-Upgrades in den nächsten Wochen noch geändert werden könne, aber ohne ausdrücklichen Rat der Entwickler werde der Umfang des Cancun-Upgrades im „Standard“-Zustand bleiben, wie die Diskussion über EIP-4844 zeigt dass die Entwicklung Der Autor stimmte zu, SSZ aus der EL-Implementierung von EIP-4844 zu entfernen, **aber es hat noch keinen Einfluss auf den weiteren Fortschritt von ** 6475 **. **Darüber hinaus diskutierten die Entwickler kurz zwei EIPs, die in Cancun in Betracht gezogen werden sollen, nämlich EIP 6969（EIP

1559. und EIP 5656 (effiziente EVM-Anweisungen zum Kopieren von Speicherbereichen);

• Die Entwicklungen in 4844 wurden in der Konsenssitzung der Entwickler am 18. Mai 23 kurz besprochen, z. B. die Möglichkeit, Smart-Contract-Anwendungen auf EL zu ermöglichen, Beweise für den CL-Status zu überprüfen;
• Die Deaktivierung von SELFDESTRUCT, Änderungen der EIP-4844-Spezifikation, Opcode-Management und mögliche endgültige Ergänzungen in Cancun wurden beim 162. Ethereum Core-Treffen am 25. Mai 2023 besprochen. Tim Beiko empfiehlt, zukünftige Gespräche über die Erweiterung der Reichweite von Cancun auf die folgenden fünf EIPs zu beschränken: EIP-5920**, 5656, 7069,* ** 4788* ** und ** 2530**. Die Entwickler werden es in den nächsten Wochen bestätigen ** Dencun** (****Deneb

• das gesamte Angebot von Cancun****);**

• Auf dem 110. Ethereum Consensus Layer Meeting am 1. Juni 2023 stellte ein Forscher der Ethereum Foundation die Ergebnisse eines Datenexperiments zur Fähigkeit der Ethereum-Mainnet-Knoten zur Verbreitung großer Datenmengen vor. Aufgrund dieses Ergebnisses schlug der Forscher vor, dass die EIP Die 4844-Spezifikation erhöhte sich von maximal 4 Blobs auf 6 pro Block. Gleichzeitig denken Entwickler über das EIP nach 4788 im Cancun-Upgrade enthalten;
• Beim Kernentwicklertreffen am 13. Juni 2023 bestätigten die Entwickler offiziell den Upgrade-Umfang, einschließlich EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788；
• In der Konsenssitzung am 15. Juni 2023 wurde diskutiert, welche CL-zentrierten EIPs in Deneb aufgenommen werden sollten, darunter EIP-6988, EIP-7044 und EIP-7045, und das CL-Kundenteam stimmte zu Zum Folgenden wird ein EIP-4844-Testnetzwerk Devnet6 die erhöhte Anzahl von Blobs testen und innerhalb von zwei Wochen eine endgültige Entscheidung in dieser Angelegenheit treffen, während Forscher Michael der Ethereum Foundation Neuder schlug vor, die Einsatzobergrenze von 32 ETH aufzuheben, um das Wachstum des aktiven Validator-Sets zu reduzieren;
• In der Sitzung am 22. Juni 2023 schlug Tim vor, die vorkompilierte Adresse von 4844 auf 0xA zu verschieben, sie zu packen und den BLS an eine andere Adresse zu verschieben, allerdings über EIP vorkompiliert 2537, aber es wird in Cancun nicht berücksichtigt;
• In der Konsenssitzung am 29. Juni 2023 diskutierten die Entwickler weiterhin über die Anzahl der Blobs und begrenzten den Ziel-Blob Von 2 auf 3 erhöht, das maximale Blob-Limit von 4 auf 6 erhöht und 4844 Testnetzwerk Devnet #7 kommt bald.

dieses Leben

• Der Kerninhalt ist EIP 4844, Proto-Danksharding
• Der endgültige EIP-Bereich für dieses Cancun-Upgrade ist: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. Unterdessen diskutierten die Entwickler beim 111. Ethereum ACDC-Treffen am 19. Juni weiter über EIP 6988、** EIP 7044**、**EIP 7045 zur Aufnahme in Deneb. Die Entwickler sagten, sie planen, die drei oben genannten EIPs in den kommenden Wochen in die Deneb-Spezifikation zu integrieren.

**Analyse von SchlüsselEIP

EIP 4844

• Einführung:
• Der Name des EIP4844-Vorschlags lautet Proto-Danksharding, das Vorprotokoll der Vollversion der Sharding-Erweiterung Danksharding. Der gesamte Satz von Sharding-Schemata basiert tatsächlich auf Rollup für die On-Chain-Erweiterung. **Der Zweck des Programms besteht darin, die ** 2 Schicht **Rollup——****zu erweitern, indem es L2 dabei hilft, Gebühren zu senken und den Durchsatz zu erhöhen , und ebnet gleichzeitig den Weg für vollständiges Sharding (Sharding). **
• In der Telefonkonferenz am 23. Februar werden die Ethereum-Entwickler EIP machen Das 4844-Upgrade trägt den Namen Deneb, was der Name eines Sterns erster Größe im Sternbild Schwan ist, der künftig das EIP auf der entsprechenden GitHub-Version ist Die Benennung von 4844 wird auf Deneb aktualisiert; in der Sitzung am 1. Juni 23 wird es einige Änderungen in der nächsten Upgrade-Spezifikation von Ethereum geben, die auf der CL-Seite Deneb und auf der EL-Seite Cancun heißt;
• Im Entwicklertreffen am 23. Juni bereiteten die Entwickler die Aktualisierung des EIP vor Die vorkompilierte Adresse 4844. Derzeit haben die Kernentwickler 9 Vorkompilierungen zur EVM hinzugefügt und werden die EIP bis aktivieren 4844 und 4788 erstellen zwei Vorkompilierungen unter den Adressen „0xA“ bzw. „0xB“. In der Konsenssitzung am 29. Juni ist EIP startbereit 4844s dediziertes Kurzzeittestnetzwerk Devnet #7。
• EIP-4844** führt einen brandneuen Transaktionstyp ein – Blob Transkation。** *Blob-Profil:
• Blob, ähnlich einem Plug-in-Datenpaket, am Anfang nur 128 Der Speicherplatz von KB betrug zu Beginn der Diskussion des Vorschlags das Ziel und die Grenze von Blob 2/4 und wurde in der Entwicklerbesprechung am 9. Juni 23 auf 3/6 angepasst. Das heißt, derzeit kann jede Transaktion in Ethereum bis zu drei Blob-Transaktionen umfassen, also 384 KB, das Ziel jedes Blocks Die Blob-Kapazität beträgt 6, also 768 KB, das bis zu 16 Blobs transportieren kann, was 2 MB entspricht;
• Es kann einen gewissen Einfluss auf die Netzwerkstabilität haben, aber das Ethereum-Entwicklungsteam hat sich dennoch entschieden, zuerst zu testen, um die Notwendigkeit nachfolgender Hard Forks zur Erweiterung des Blob-Blocks zu vermeiden.
• Klecks **in ** KZG commit Hash Als ** Hash, der zur Datenüberprüfung verwendet wird, ähnelt die Funktion ** Merkle ;
• Der Knoten synchronisiert den Blob in der Kette Nach der Transaktion läuft der Blob-Teil ab und wird nach einer gewissen Zeit gelöscht. Die Speicherzeit beträgt drei Wochen.
• Blob-Funktion – verbessert das TPS von Ethereum und senkt gleichzeitig die Kosten
• Derzeit beträgt das Gesamtdatenvolumen des gesamten Ethereum nur etwa 1 TB, und Blob kann jedes Jahr 2,5 bis 5 TB zusätzliches Datenvolumen nach Ethereum bringen, was das Hauptbuch selbst um ein Vielfaches übersteigt.
• Für Knoten verursacht das Herunterladen zusätzlicher 1 MB bis 2 MB Blob-Daten pro Block keine Bandbreitenbelastung, und der Speicherplatz erhöht nur die feste Menge an Blob-Daten von etwa 200 bis 400 GB pro Monat, was keine Auswirkungen hat Dezentralisierung des gesamten Ethereum-Knotens, aber die Erweiterung um Rollup wird erheblich verbessert;
• Tatsächlich muss der Knoten selbst nicht alle Blob-Daten speichern, da es sich bei dem Blob tatsächlich um ein temporäres Datenpaket handelt, sodass der Knoten tatsächlich nur drei Wochen lang eine feste Datenmenge herunterladen muss.
• Die Rolle von EIP-4844** – um das erste Kapitel der Danksharding-Erzählung zu eröffnen**
• **Hohe Kapazitätserweiterung: **Derzeit kann EIP-4844 zunächst die L2-Kapazität erweitern. Die Vollversion von Danksharding kann das Blob-Datenvolumen in EIP-4844 von 1 MB auf 2 MB auf 16 MB auf 32 MB erweitern und so Dezentralisierung und Sicherheit gewährleisten Bei gleichzeitiger Erzielung einer höheren Expansion;
• **Niedrige Gebühren: **Bernstein-Analysten zeigen, dass Proto-Dank-Sharding die Gebühren des Layer-2-Netzwerks auf das 10- bis 100-fache des aktuellen Niveaus senken kann;
• Die tatsächlichen Daten:
• Das Opside-Testnetzwerk hat 4844 bereitgestellt, wodurch die Rollup-Kosten nach aktuellen Beobachtungen um 50 % gesenkt werden können;
• Die technische DA-Lösung von EigenLayer gibt nicht zu viel preis, um ihre Daten auszuwerten.
• Streng genommen hat Celestia wenig mit Ethereum zu tun und seine DA-Kosten können derzeit nicht abgeschätzt werden, abhängig von seinen spezifischen technischen Lösungen;
• Die Lösung von Ethstorage besteht darin, sein Layer2-Speicherzertifikat hochzuladen, und seine DA-Kosten können auf 5 % des Originals reduziert werden;
• Topia geht davon aus, die Kosten um das 100- bis 1000-fache zu senken, da das Hauptnetzwerk Danksharding auch Sicherheit und Kompatibilität mit Layer-1-P2P-Netzwerkübertragung berücksichtigen muss.
• **DA****Lösung: Danksharding (eine Sharding-Lösung für die Erweiterung von Ethereum) Wenn die Erweiterung derzeit fortgesetzt wird, ist die Knotenbelastung möglicherweise zu groß (****16 MB). **** oben) und unzureichende Datenverfügbarkeit (30 Tage Gültigkeit). Lösung: **
• Datenverfügbarkeitsstichprobe (Data Availability Sampling) – reduziert die Belastung der Knoten
• Schneiden Sie die Daten im Blob in Datenfragmente und lassen Sie den Knoten vom Herunterladen der Blob-Daten zur zufälligen Überprüfung der Blob-Datenfragmente wechseln, sodass die Blob-Datenfragmente in jedem Knoten des Ethereum verstreut sind, die vollständigen Blob-Daten jedoch im gesamten Ethereum-Ledger gespeichert, ist die Voraussetzung, dass die Knoten ausreichend und dezentral sein müssen;
• DAS verwendet zwei Technologien: Löschcode (Erasure Codierung) und KZG Polynomial Commitment (KZG Engagement);
• Proposer-Packager-Trennung (PBS) – Das Problem der Arbeitsteilung der Knoten wurde gelöst, wobei die Knoten mit der Konfiguration mit hoher Leistung für das Herunterladen aller Daten zur Codierungsverteilung verantwortlich waren und die Knoten mit der Konfiguration mit geringer Leistung dafür verantwortlich waren Stichprobenüberprüfung.
• Ein Knoten mit einer Hochleistungskonfiguration kann ein Builder werden. Der Builder muss nur die Blob-Daten zum Codieren herunterladen, einen Block (Block) erstellen und ihn dann zur Stichprobenprüfung an andere Knoten senden. Für den Builder, weil die Synchronisierung Die Anforderungen an Datenvolumen und Bandbreite sind hoch, daher wird es relativ zentralisiert sein.
• Ein Knoten mit geringer Leistungskonfiguration kann zum Antragsteller (Proposer) werden, und der Antragsteller muss nur die Gültigkeit der Daten überprüfen und den Blockheader (Block) erstellen und senden Header), aber für den Antragsteller (Proposer) sind die Anforderungen an das Synchronisationsdatenvolumen und die Bandbreite gering, sodass er dezentralisiert wird.
• Anti-Zensur-Liste (crList) – löst das Problem, dass Paketierer aufgrund ihrer übermäßigen Überprüfungsbefugnis bestimmte Transaktionen absichtlich ignorieren und Transaktionen, die sie MEV erhalten möchten, nach dem Zufallsprinzip sortieren und einfügen können.
• Bevor der Builder (Builder) Blocktransaktionen packt, veröffentlicht der Antragsteller (Proposer) zunächst eine überprüfungsresistente Liste (crList), die alle Transaktionen im Mempool enthält;
• Der Builder (Builder) kann die Transaktionen nur in crList verpacken und sortieren, was bedeutet, dass der Builder weder seine eigene private Transaktion einfügen kann, um MEV zu erhalten, noch eine Transaktion absichtlich ablehnen kann (es sei denn, Gas Limit ist voll);
• Nach dem Packen sendet der Builder die endgültige Version des Transaktionslisten-Hash an den Antragsteller, und der Antragsteller wählt eine der Transaktionslisten aus, um den Blockheader (Block) zu generieren Header) und Broadcast;
• Wenn der Knoten Daten synchronisiert, erhält er den Blockheader vom Antragsteller (Proposer) und dann den Blockkörper vom Paketierer (Builder), um sicherzustellen, dass der Blockkörper die endgültig ausgewählte Version ist.
• Dual-Slot-PBS – löst das Problem, dass zentralisierte Paketierer durch die Übernahme von MEV immer zentraler werden
• Verwenden Sie den Gebotsmodus, um den Block zu bestimmen:
• Der Builder (Builder) erstellt den Blockheader der Transaktionsliste, nachdem er die crList und die Gebote erhalten hat.
• Der Antragsteller (Proposer) wählt den Block-Header und den Builder (Builder) aus, die schließlich erfolgreich bieten, und der Antragsteller erhält bedingungslos die Zuschlagsgebühr (unabhängig davon, ob ein gültiger Block generiert wird);
• Das Verifizierungskomitee (Komitees) bestätigt den Gewinnerblock-Header;
• Der Erbauer legt den Hauptteil des Gewinnerblocks offen;
• Das Verifizierungskomitee (die Ausschüsse) bestätigt den Körper des siegreichen Blocks und führt eine Verifizierungsabstimmung durch (wenn der Block bestanden wird, wird der Block produziert, wenn der Packer den Blockkörper absichtlich nicht angibt, wird davon ausgegangen, dass der Block vorliegt ist nicht vorhanden).
• Bedeutung:
• Erstens hat der Builder (Builder) mehr Befugnisse zum Paketieren von Transaktionen, aber die oben erwähnte crList schränkt erstens die Möglichkeit ein, Transaktionen vorübergehend einzufügen, und zweitens, wenn der Builder (Builder) durch Ändern der Reihenfolge der Transaktionen profitieren möchte, dann Es muss zu Beginn eine Menge Ausschreibungskosten bezahlen, um sicherzustellen, dass es die Qualifikation des Blockkopfes erhalten kann, dann wird der erzielte MEV-Gewinn weiter reduziert, und insgesamt wird es Auswirkungen auf die Mittel und den tatsächlichen Wert haben MEV zu erhalten;
• In der Anfangsphase wird jedoch möglicherweise nur eine kleine Anzahl von Personen zu Packern (unter Berücksichtigung von Knotenleistungsproblemen), während die meisten Personen nur zu Antragstellern werden, was zu einer weiteren Zentralisierung führen kann. Gleichzeitig ist die Anzahl der Packer sehr gering Im Fall von wird es wahrscheinlicher sein, dass einige erfahrene Bergleute mit MEV-Fähigkeiten erfolgreich bieten, was sich stärker auf den tatsächlichen MEV-Lösungseffekt auswirkt;
• Hat gewisse Auswirkungen auf einige MEV-Lösungen, die MEV-Auktionen verwenden.
• Bedeutung:
• EIP 4844 Eigentlich eine stark vereinfachte Version Danksharding**: **Es bietet die gleiche Anwendungsschnittstelle wie Danksharding, einschließlich eines neuen Opcodes namens Data Hash; und ein neues Datenobjekt namens Binary Große Objekte, das heißt Blob;
• Proto-Danksharding ** wird verwendet, um die vollständige ** Danksharding -Spezifikation „Klammer“ (** ist das Transaktionsformat und die Verifizierungsregeln****) zu implementieren. * * Vorschlag: Es wurde jedoch noch kein Sharding implementiert und alle Prüfer und Benutzer müssen weiterhin die Verfügbarkeit vollständiger Daten direkt überprüfen;
• Warum die langfristige Perspektive Proto-Danksharding nicht EIP wählt 4488 ** reduziert direkt die Gebühr von ** Layer2 , da bei einem zukünftigen Upgrade auf einen vollständigen Shard nur eine kleine Anpassung erforderlich ist:
• EIP Der wesentliche praktische Unterschied zwischen 4488 und Proto-Danksharding besteht darin, dass EIP-4488 versucht, die Änderungen, die Ethereum heute vornehmen muss, zu minimieren, während Proto-Danksharding heute mehr Änderungen an Ethereum vornimmt, um in Zukunft ein Upgrade auf Ethereum durchzuführen. Minimale Änderungen sind erforderlich für Vollversions-Sharding;
• Obwohl es eine sehr komplexe Aufgabe ist, ein vollständiges Sharding zu erreichen (mit Stichproben zur Datenverfügbarkeit usw.), und nach der Implementierung von Proto-Danksharding noch viel zu tun ist, werden diese Komplexitäten auf der Konsensebene kontrolliert. Sobald Proto-Danksharding bereitgestellt ist, müssen das Client-Team der Ausführungsschicht, die Rollup-Entwickler und Benutzer keine zusätzliche Arbeit leisten, um zum vollständigen Sharding überzugehen.
• Um ein vollständiges Sharding zu erreichen, ist es notwendig, die eigentliche Implementierung von ** PBS, Delegationsnachweis und Datenverfügbarkeitsstichprobe abzuschließen, aber solche Änderungen werden sich auf ** CL * konzentrieren * Schicht, Entwickler müssen keine Neuanpassungen vornehmen **: 4844 implementiert derzeit einen neuen Transaktionstyp, der genau dem Transaktionsformat, der Konsens-Kreuzvalidierungslogik und der Ausführungsschichtlogik entspricht, die im gesamten Shard erforderlich sind Abgeleitet für Blobs, selbstanpassende unabhängige Gaspreise. Um in Zukunft ein vollständiges Sharding zu erreichen, ist es notwendig, die eigentliche Implementierung von PBS, Delegationsnachweis und Datenverfügbarkeitsstichprobe abzuschließen, aber diese Änderungen erfolgen nur auf der CL-Ebene Es ist nicht erforderlich, dass EL-Layer- oder Rollup-Entwickler Änderungen vornehmen, was für die Entwicklung praktisch ist.

gefolgt von SELFDESTRUCT Entfernung,EIP-6780 wurde schließlich als die am besten geeignete Lösung ermittelt, aber der Entwickler auf 26 Im Treffen tim schlug vor, diesem Vorschlag einen weiteren Opcode hinzuzufügenSETCODE*, damit programmatische Konten weiterhin aktualisiert werden können***

SELBSTZERSTÖRUNG Entfernung EIP-6780**:**X

• Hintergrund:
• Am 21. März schlug Vitalik vor, dass SELFDESTRUCT der Ethereum-Ökologie mehr schadet als nützt. Der Hauptgrund dafür ist, dass es das einzige ist, das eine unendliche Anzahl von Zustandsobjekten in einem einzigen Block ändern kann, was zu Änderungen in den Vertragscodes führt. und kann ohne Zustimmung des Kontos verwendet werden. Kann den Betriebscode des Kontostands ändern, was große versteckte Gefahren für die Sicherheit von Ethereum birgt;**
• Die einzige Möglichkeit, einen Vertrag in der Kette zu entfernen, ist SELBSTZERSTÖRUNG. Wenn Sie die Selbstzerstörungsfunktion im Vertrag aufrufen, können Sie den Vertrag selbst zerstören. Das im Vertrag hinterlegte Ethereum wird an die angegebene Adresse versendet. Die verbleibenden Code- und Speichervariablen werden in der Zustandsmaschine entfernt. Tatsächlich klingt die Aktion der Vertragszerstörung in der Theorie gut, ist aber tatsächlich sehr gefährlich. Obwohl die Funktion selfdestruct** Entwicklern helfen kann, im Notfall den Smart Contract zu löschen und den Saldo im Vertrag an die angegebene Adresse zu überweisen, wird diese Funktion auch von Kriminellen genutzt und ist somit ein Angriffsmittel. **
• Beim Kernentwicklertreffen am 13. April 23 wurden vier Vorschläge zu SELFDESTRUCT zur Teilnahme an der Diskussion vorgelegt, nämlich 6780, 4758, 6046 und 6190, sowie das nachfolgende EIP Als endgültiger Vorschlag wurde 6780 festgelegt.
• Einführung: Selbstzerstörung ist der Notfallknopf des Smart Contracts, der den Vertrag zerstört und die verbleibende ETH auf das angegebene Konto überträgt.
• EIP 6780: Deaktivieren Sie SELFDESTRUCT, es sei denn, sie befinden sich in derselben Transaktion im Vertrag.
• UPDATE: Am 26. Mai schlug Tim vor, zusätzlich zur Entfernung von SELFDESTRUCT einen weiteren Opcode hinzuzufügen – SETCODE, damit programmatische Konten weiterhin aktualisiert werden können. (Das heißt, die Aktualisierungsfunktion wird hinzugefügt und die Eigenschaft im Smart-Vertrag wird durch Aktualisierung/Upgrade aktualisiert.) Hier erfolgt die Absorption von EIP Die Vorteile von 4758, die Dapp Raum für Upgrades geben können.

• Grund: Die Manipulation des SELFDESTRUCT-Codes erforderte ursprünglich umfangreiche Änderungen am Kontostatus, wie zum Beispiel das Löschen aller Codes und des Speichers. Dies stellt eine Schwierigkeit für die zukünftige Verwendung von Verkle-Bäumen dar: Jedes Konto wird in vielen verschiedenen Kontoschlüsseln gespeichert, die nicht explizit mit dem Root-Konto verknüpft werden.
• GEÄNDERT: Diese EIP implementiert Änderungen zur Entfernung von SELFDESTRUCT, außer in den folgenden beiden Fällen
• Apps, die nur zur Selbstzerstörung zum Abheben von Geldern verwendet werden, funktionieren weiterhin.
• SELFDESTRUCT, das in derselben Transaktion im Vertrag verwendet wird, muss nicht geändert werden.
• Bedeutung: Erhöhte Sicherheit
• Zuvor gab es im Mainnet einen Vertrag, der SELFDESTRUCT nutzte, um einzuschränken, wer Transaktionen über den Vertrag initiieren kann;
• Verhindern Sie, dass Benutzer nach der SELBSTZERSTÖRUNG weiterhin Gelder einzahlen und in einem Tresor handeln, da dieser Tresor dann dazu führen kann, dass jemand bei wiederholter Nutzung Token im Tresor stiehlt.

Bei den folgenden drei Vorschlägen handelt es sich um Vorschläge zu SELFDESTRUCT, die später im 23Jahr4 gelöscht wurden *** 6780 wurde im Kernentwicklertreffen am 28.******* offiziell ausgewählt und die anderen drei Vorschläge wurden aufgegeben. Der Grund ist, dass das Ethereum-Entwicklungsteam den Opcode SELFDESTRUCT** schließlich vollständig löschen möchte und die folgenden drei Vorschläge größtenteils durch Ersetzen geändert werden. ***

• EIP-4758 (VERALTET): Deaktivieren Sie SELFDESTRUCT, indem Sie SELFDESTRUCT in SENDALL ändern, wodurch alle Gelder für den Anrufer wiederhergestellt werden (alle Ether im Konto an den Anrufer gesendet werden), aber kein Code oder Speicher gelöscht wird.
• Grund: Wie oben erforderte die Manipulation des SELFDESTRUCT-Codes umfangreiche Änderungen am Kontostatus, wie z. B. das Löschen aller Codes und des Speichers. Dies stellt eine Schwierigkeit für die zukünftige Verwendung von Verkle-Bäumen dar: Jedes Konto wird in vielen verschiedenen Kontoschlüsseln gespeichert, die nicht explizit mit dem Root-Konto verknüpft werden.
• Ändern:
• Opcode SELFDESTRUCT wurde in SENDALL umbenannt, verschiebt jetzt nur noch alle ETH im Konto zum Aufrufer, dieses Schema zerstört keinen Code und Speicher mehr und ändert keine Zufallszahlen;
• Alle Rückerstattungen im Zusammenhang mit SELFDESTRUCT wurden gelöscht
• Bedeutung:
• Die ursprüngliche Funktionalität im Vergleich zu EIP-6780 wurde beibehalten, da einige Anwendungen immer noch den SELFDESTRUCT-Code verwenden müssen.
• EIP-6046 (VERALTET): Ersetzen Sie SELFDESTRUCT durch DEACTIVATE. Ändern Sie SELFDESTRUCT so, dass der Speicherschlüssel nicht gelöscht wird, und verwenden Sie einen speziellen Wert in der Konto-Nonce, um die Deaktivierung anzuzeigen
• Grund: Wie oben werden Konten bei einem Verkle-Baum anders organisiert: Kontoeigenschaften (einschließlich Speicher) verfügen über separate Schlüssel, es ist jedoch unmöglich, alle verwendeten Schlüssel zu durchlaufen und zu finden. Die Manipulation von SELFDESTRUCT-Codes erforderte bisher umfangreiche Änderungen am Kontostatus, was es sehr schwierig machte, SELFDESTRUCT in Verkle-Bäumen weiterhin zu verwenden.
• Ändern:
• Ändern Sie die durch EIP-2681 eingeführten Regeln, sodass die reguläre Nonce-Erhöhung durch 2^64-2 statt durch 2^64-1 begrenzt wird;
• SELBSTZERSTÖRUNG wurde geändert in:
• Löschen Sie keine Speicherschlüssel und lassen Sie das Konto bestehen;
• Kontostand auf Ziel übertragen **, **Kontostand auf 0 setzen.
• Stellen Sie die Konto-Nonce auf 2^64-1 ein.
• Keine Rückerstattungen seit EIP-3529;
• Die relevante Regel SELFDESTRUCT von EIP-2929 bleibt unverändert.
• Bedeutung:
• Dieser Vorschlag bietet mehr Flexibilität als andere direkte Löschungen von SELFDESTRUCT.
• EIP-6190 (VERALTET): SELFDESTRUCT wurde geändert, kompatibel mit Verkle, sodass es nur eine begrenzte Anzahl von Statusänderungen verursacht
• Grund: Wie oben werden Konten bei einem Verkle-Baum anders organisiert: Kontoeigenschaften (einschließlich Speicher) verfügen über separate Schlüssel, es ist jedoch unmöglich, alle verwendeten Schlüssel zu durchlaufen und zu finden. Die Manipulation von SELFDESTRUCT-Codes erforderte bisher umfangreiche Änderungen am Kontostatus, was es sehr schwierig machte, SELFDESTRUCT in Verkle-Bäumen weiterhin zu verwenden.
• GEÄNDERT: Anstatt den Vertrag am Ende einer Transaktion zu zerstören, geschieht am Ende der Transaktion, die ihn aufgerufen hat, Folgendes:
• Der Vertragscode ist auf 0x1 und die Zufallszahl auf 2^64-1 gesetzt.
• Der 0. Speicherslot des Vertrags wird mit dem CREATE-Opcode ( keccak256(contractAddress, nonce)) wird ausgegeben, wenn die Adresse. Die Zufallszahl ist immer 2^64-1.
• Wenn sich der Vertrag selbst zerstört, nachdem der Anruf von einem oder mehreren Alias-Verträgen weitergeleitet wurde, stellen Sie den 0. Speicherplatz des Alias-Vertrags auf die in Schritt 2 berechnete Adresse ein.
• Der Restbetrag des Vertrags wird vollständig an die Adresse oben im Stapel überwiesen;
• Die Oberseite des Stapels ist aufgeplatzt.
• Bedeutung:
• Entwickelt, um SELFDESTRUCT zu ermöglichen, anschließend mit minimalen Änderungen Verkle-Bäume zu bilden;
• Die Gaskosten stiegen mit der Anwendung von EIP-2929.

Gefolgt vonEIP 1153***, spart gleichzeitig Gas****** und ebnet den Weg für zukünftiges Speicherdesign***

EIP 1153X

• Kurzbeschreibung: Transiente Speicher-Opcodes. Fügen Sie Opcodes zur Zustandsmanipulation hinzu, die sich wie Geschäfte verhalten, aber nach jeder Transaktion verworfen werden.
• Grund:
• Das Ausführen einer Transaktion in Ethereum kann mehrere verschachtelte Ausführungsrahmen erzeugen, wobei jeder Rahmen durch einen CALL-Befehl (oder einen ähnlichen Befehl) erstellt wird. Verträge können in derselben Transaktion erneut eingegeben werden. In diesem Fall gehört mehr als ein Frame zu einem Vertrag.
• Derzeit können diese Frames auf zwei Arten kommunizieren: Eingabe/Ausgabe über CALL-Anweisungen und über Store-Updates. Die Kommunikation über I/O ist unsicher, wenn es ein Zwischenframework gibt, das zu einem anderen nicht vertrauenswürdigen Vertrag gehört.
• mit Wiedereintritt Beispielsweise kann eine Sperre nicht auf Zwischenrahmen zurückgreifen, um den Zustand der Sperre zu kommunizieren: SSTORE-Kommunikation über Speicher SLOAD ist teuer, und transienter Speicher ist eine dedizierte und gaseffiziente Lösung für das Problem der Kommunikation zwischen Rahmen.
• Geändert: Zwei neue Opcodes, TLOAD ( 0xb3 ) und TSTORE ( 0xb4 ), wurden dem EVM hinzugefügt.
• Transienter Speicher ist privat für den Vertrag, der ihn besitzt. Genau wie persistenter Speicher kann nur das besitzende Vertrags-Framework auf seinen temporären Speicher zugreifen. Beim Zugriff auf den Speicher greifen alle Frames auf denselben flüchtigen Speicher zu, auf die gleiche Weise wie beim persistenten Speicher, jedoch anders als beim Speicher.
• Mögliche Anwendungsfälle:
• Wiedereintritt sperren;
• In der Kette berechenbare CREATE2-Adressen: Konstruktorparameter werden aus dem Fabrikvertrag gelesen und nicht als Teil des Initialisierungscode-Hashs übergeben;
• EIP-20-Genehmigung für eine einzelne Transaktion, z. B. #temporaryApprove(address Spender, uint256 Betrag)；
• Transfergebührenvertrag: Zahlen Sie eine Gebühr an den Token-Vertrag, um Transfers während Transaktionen freizuschalten;
• „Till“-Modus: Ermöglicht dem Benutzer die Ausführung aller Aktionen als Teil des Rückrufs und prüft, ob „till“ am Ende ausgeglichen ist;
• Proxy-Aufrufmetadaten: Übergeben Sie zusätzliche Metadaten an die Implementierung von Verträgen, ohne Aufrufdaten zu verwenden, z. B. die Werte unveränderlicher Proxy-Konstruktorparameter.
• Bedeutung:
• Sparen Gas**, mit einfacheren** Gas Abrechnungsregeln;
• ** Lösen Sie das Problem der Inter-Frame-Kommunikation; **
• ** Ändern Sie nicht die Semantik bestehender Operationen; **
• Nach Gebrauch muss der Vorratstank nicht geleert werden;
• ** Zukünftige Speicherdesigns (z. B. ** Verkle **-Bäume) müssen keine Rückerstattungen für die sofortige Speicherung berücksichtigen. **

Gefolgt von 4788, kann dies die Vertrauensannahme im Pfandpool verringern**

EIP 4788**:**X

• Einführung: Beacon-Block-Root in EVM. *Aktualisierung: Beim Entwicklertreffen am 15. und 23. Juni schlugen die Entwickler vor, Codeänderungen vorzunehmen, um das Staker-Erlebnis zu verbessern. Diese EIP wird die Wurzel des Beacon-Kettenblocks offenlegen, der EVM-interne Kettenstatusinformationen für die DApp-Entwicklung enthält. Das Vertrauen des Autors minimiert den Zugriff.
• GEÄNDERT: Übertragen Sie die Hash-Wurzeln jedes Beacon-Kettenblocks in den entsprechenden Ausführungsnutzlast-Header, speichern Sie diese Wurzeln in einem Vertrag im Ausführungsstatus und fügen Sie einen neuen Opcode hinzu, um diesen Vertrag zu lesen.
• Bedeutung: Dies ist ein Code-Änderungsvorschlag, der vorschlägt, die Ethereum Virtual Machine (EVM) so zu ändern, dass sie den Status der Vertragsschicht (CL) offenlegen kann Root-Daten auf der Ausführungsebene (EL) können die Kommunikation zwischen verschiedenen Protokollen und Anwendungen im Ethereum-Netzwerk effizienter und sicherer machen**. **Erlauben Sie vertrauenswürdigere Designs für Absteckpools, Überbrückungs- und erneute Absteckprotokolle.

Der letzte ist5656***, der einen effizienten neuen Speicherkopie-Opcode bereitstellt, derzeit jedoch aufgrund seiner Testbandbreite vorübergehend in das Upgrade einbezogen wird** *

EIP 5656X

• Einführung: MCOPY

• Anweisung zum Kopieren des Speichers. Update: 09.06.23, das Entwicklungsteam gab an, dass es anfangs geteilter Meinung über MCOPY war, da es zwar das Sicherheitsproblem löste, sie aber immer noch Bedenken hatten, es zur für das Upgrade erforderlichen Implementierungs- und Testbandbreite hinzuzufügen, stimmten aber schließlich der Einbeziehung zu EIP, wird jedoch zur Entfernung in Betracht gezogen, wenn der Entwickler beim Testen oder auf der Clientseite auf Kapazitätsprobleme stößt. Daher wird MCOPY* derzeit vorübergehend in das Cancun-Upgrade einbezogen. **

• Geändert: Es wurde eine effiziente EVM-Anweisung zum Kopieren von Speicherbereichen bereitgestellt.
• Bedeutung: Das Kopieren des Speichers ist ein grundlegender Vorgang, die Implementierung auf dem EVM ist jedoch mit Kosten verbunden.
• Mit der Verfügbarkeit der MCOPY-Anweisung können Codewörter und -sätze präziser kopiert werden, wodurch die Speicherkopierleistung um etwa 10,5 % erhöht wird, was für verschiedene rechenintensive Vorgänge sehr nützlich ist;
• Es wird auch für Compiler nützlich sein, effizienteren und kleineren Bytecode zu generieren;
• Es kann eine gewisse Menge an Kosten für vorkompiliertes Identitätsgas einsparen, aber es kann die Implementierung dieses Teils nicht wirklich fördern.

Auswahlliste****EIP

Am 236Monat15***** wurde die Konsenssitzung der Entwickler in *** besprochen EIP** mit Schwerpunkt auf CL sind in Deneb enthalten, wobei **** ** EIP 6988******、**EIP 7044、******EIP 7045 *** *** wird zum Beitritt vorgeschlagen. ***

EIP 6988**:**X

• Aufgabe: Verhindern Sie, dass gekürzte Validatoren als Blockantragsteller gewählt werden.
• Bedeutung: Erhöhte Strafen für Knotenverstöße kommen der DVT zugute.

EIP 7044**:**X

• Zusammenfassung: Sicherstellen, dass signierte Validator-Exits dauerhaft gültig sind.
• Bedeutung: Es kann die Erfahrung der Spieler bis zu einem gewissen Grad verbessern.

EIP 7045**:**X

• Einleitung: Testamentsbescheinigung Der Slot-Einschlussbereich erstreckt sich von einem gleitenden Fenster von einer Epoche bis zu zwei Epochen.
• Bedeutung: Verbesserung der Netzwerksicherheit.

Analyse von EIP löschen

Am **** Tag des 29******************************* *********************************************** In ** 160***ACDE Treffen von Ethereum, EVMMAX und **** EOF Es wurde bestätigt, dass **** aus diesem Upgrade entfernt wird. Änderungen im Zusammenhang mit EOF können in nachfolgenden täglichen Upgrades eingeführt werden

EVMMAX EIPs**:**

• Kurzbeschreibung: EVMMAX zielt darauf ab, den arithmetischen Operationen und Signaturschemata auf Ethereum mehr Flexibilität zu verleihen. Derzeit gibt es zwei EVMMAX-Vorschläge, einen mit EOF und einen ohne EOF.
• EIP 6601: EVM Modular Arithmetic Extensions (EVMMAX)
• Änderung: ist EIP 5843 Iterationen, mit EIP Der Unterschied von 5843 ist:
• 6601 führt einen neuen EOF-Abschnittstyp ein, der den Modulus, den vorberechneten Montgomery-Parameter und die Anzahl der zu verwendenden Werte speichert (der zur Laufzeit konfigurierbare Modulus wird weiterhin unterstützt);
• 6601 verwendet einen separaten Speicherbereich für EVMMAX-Werte mit neuen Lade-/Speicher-Opcodes, um Werte zwischen EVM<->EVMMAX-Speicher zu verschieben;
• Der 6601 unterstützt Operationen mit Modulen bis zu 4096 Bit (vorläufiger Grenzwert in EIP erwähnt).
• Bedeutung: EIP-5843 führt eine effiziente modulare Addition, Subtraktion und Multiplikation für die Ethereum Virtual Machine ein, EIP-6601 führt weitere Upgrades auf dieser Basis durch die Einführung eines Setup-Abschnitts, eines separaten Speicherraums und neuer Opcodes durch, um modulare arithmetische Operationen für eine bessere Organisation zu sorgen und Flexibilität bei gleichzeitiger Unterstützung eines größeren Moduls und einer Verbesserung der EVM-Leistung.
• Als EVM-Vertrag, der arithmetische Operationen auf elliptischen Kurven für verschiedene Kurven ermöglicht (einschließlich BLS12-381);
• MULMOD reduziert die Gaskosten für Operationen mit Werten bis zu 256 Bit um 90-95 % im Vergleich zu den bestehenden Opcodes ADDMOD;
• Ermöglicht die Implementierung der Modexp-Vorkompilierung als EVM-Vertrag;
• Reduziert die Kosten der ZKP-Verifizierung in algebraischen Hash-Funktionen (z. B. MiMC/Poseidon) und EVM erheblich.
• EIP 6690:
• Änderung: EIP-6990 ist ein von EIP-6601 adaptierter Vorschlag, um optimierte modulare Rechenoperationen in die EVM einzuführen, ohne auf EOF angewiesen zu sein. Während EIP-6601 EIP-4750 und EIP-3670 als Abhängigkeiten erfordert, bietet EIP-6990 eine unabhängigere Lösung. Es bietet einen einfacheren Ansatz, indem die Abhängigkeit von EOF beseitigt wird.
• Bedeutung: Es behält die Kernfunktionalität von EIP-6601 bei, die optimierte modulare arithmetische Operationen an ungeraden Modulen bis zu 4096 Bit durchführen kann. Diese Vereinfachung ermöglicht eine effizientere Implementierung und Übernahme und bietet gleichzeitig die mit EIP-6601 verbundenen Vorteile.

EOF Änderungen**:**

• Einführung: EOF ist ein Upgrade von EVM, das neue Vertragsstandards und einige neue Opcodes einführt. Der traditionelle EVM-Bytecode (Bytecode) ist eine unstrukturierte Befehlssequenz (unstrukturiert). Befehlsfolge) Bytecode. EOF führt das Konzept eines Containers ein, der strukturierten Bytecode implementiert. Der Container besteht aus einem Header und mehreren Abschnitten zur Strukturierung des Bytecodes. Nach dem Upgrade kann die EVM eine Versionskontrolle durchführen und mehrere Sätze von Vertragsregeln gleichzeitig ausführen.
• EIP 663:
• Kurzbeschreibung: Uneingeschränkte SWAP- und DUP-Anweisungen
• Bedeutung: Durch die Einführung zweier neuer Anweisungen: SWAPN und DUPN, die sich von SWAP und DUP dadurch unterscheiden, dass die Stapeltiefe von 16 Elementen auf 256 Elemente erhöht wird
• EIP 3540:
• Einführung:
• In der Vergangenheit hatte der in der Kette bereitgestellte EVM-Bytecode keine vordefinierte Struktur und der Code wurde nur überprüft, bevor er im Client ausgeführt wurde. Dies verursacht nicht nur indirekte Kosten, sondern hindert Entwickler auch daran, neue einzuführen Funktionen oder veraltete alte Funktionen.
• Dieses EIP führt einen Container ein, der für EVM erweitert und versioniert werden kann, und deklariert das Format des EOF-Vertrags. Auf dieser Grundlage kann der Code beim Bereitstellen des EOF-Vertrags, also bei der Erstellung, überprüft werden Zeitvalidierung bedeutet, dass verhindert werden kann, dass Verträge bereitgestellt werden, die nicht dem EOF-Format entsprechen. Diese Änderung implementiert die EOF-Versionskontrolle, die dazu beitragen wird, vorhandene EVM-Anweisungen zu deaktivieren oder in Zukunft umfangreiche Funktionen (z. B. Kontoabstraktion) einzuführen .
• Bedeutung:
• Die Versionskontrolle trägt dazu bei, dass in der Zukunft neue Funktionen eingeführt oder eingestellt werden (z. B. die Einführung der Kontoabstraktion).
• Die Trennung von Vertragscode und Daten ist für die L2-Verifizierung (op) von Vorteil und reduziert die Gaskosten von L2-Validatoren. Gleichzeitig ist die Trennung von Vertragscode und Daten auch für die Arbeit der On-Chain-Datenanalyse bequemer Werkzeuge.
• EIP 3670:
• Einführung: Basierend auf EIP-3540 soll sichergestellt werden, dass der Code des EOF-Vertrags dem Format entspricht und gültig ist, und die Bereitstellung von Verträgen, die nicht dem Format entsprechen, verhindert werden, ohne Legacy zu beeinträchtigen Bytecode。
• Bedeutung: Basierend auf dem von 3540 eingeführten Container stellt EIP-3670 sicher, dass der Code im EOF-Vertrag gültig ist, oder verhindert, dass er bereitgestellt wird. Das bedeutet, dass undefinierte Opcodes nicht in EOF-Verträgen eingesetzt werden können, was den zusätzlichen Vorteil hat, dass die Anzahl der hinzuzufügenden EOF-Versionen reduziert wird.
• EIP 4200:
• Einführung:
• Einführung der ersten EOF-spezifischen Opcodes: RJUMP, RJUMPI und RJUMPV, die kodieren Ziele als vorzeichenbehaftete Sofortwerte. Compiler können diese neuen JUMP-Opcodes verwenden, um die Gaskosten bei der Bereitstellung und Ausführung von JUMP zu optimieren, da sie die Notwendigkeit bestehender JUMP- und JUMPI-Opcodes für Jumpdest überflüssig machen Die für die Analyse erforderliche Laufzeit. Diese EIP ist für dynamische Die Hinzufügung von Sprung.
• Im Vergleich zu herkömmlichen JUMP-Operationen besteht der Unterschied darin, dass Operationen wie RJUMP keine bestimmte Versatzposition angeben, sondern eine relative Versatzposition (von dynamisch). Sprünge -> statische Sprünge), weil oft statisch Sprünge reichen aus.
• Bedeutung: Netzwerk optimieren und Kosten senken.
• EIP 4750:
• Gehen Sie mit der Funktion von 4200 noch einen Schritt weiter: durch die Einführung von CALLF Die beiden neuen Opcodes von und RETF implementieren eine alternative Lösung für die Situation, die nicht durch RJUMP, RJUMPI und RJUMPV ersetzt werden kann, sodass JUMPDEST im EOF-Vertrag nicht mehr benötigt wird und Dynamik daher verboten ist springen.
• Bedeutung: Optimieren Sie den Code, indem Sie ihn in mehrere Teile aufteilen.
• EIP 5450:
• Hintergrund: Der Hintergrund ist immer noch, dass der Ethereum-Vertrag bei der Bereitstellung nicht überprüft wird und nur eine Reihe von Prüfungen durchgeführt werden, wenn er ausgeführt wird, ob der Stapel überläuft (die Obergrenze liegt bei 1024), ob das Gas ausreicht, und so weiter.
• Inhalt: Eine weitere Gültigkeitsprüfung für EOF-Verträge hinzugefügt, diesmal rund um den Stapel. Diese EIP verhindert Situationen, in denen die EOF-Vertragsbereitstellung zu einem Stack-Unterlauf oder -Überlauf führen kann (stack Unter-/Überläufe). Auf diese Weise können Kunden die Anzahl der Gültigkeitsprüfungen reduzieren, die sie während der Ausführung von EOF-Verträgen durchführen.
• Bedeutung: Eine große Verbesserung besteht darin, diese Prüfungen, die während der Ausführung stattfinden, so selten wie möglich zu machen und mehr Prüfungen durchzuführen, wenn der Vertrag bereitgestellt wird.

5Monat26******************************* ************************************************** ************************************ 4844Zugehörige Änderung des Transaktionstyps vonSSZ****** zu RLPbedeutet, dass Cancuns zwei a****** SSZ EIPs******, alsoEIPs 6475 und 6493** werden zur Modernisierung aus Cancun verlegt***

EIP 6475X

• Einführung: EIP Begleitvorschlag zu 4844. Proto-danksharding führt einen neuen Transaktionstyp ein, der die SSZ-Kodierung anstelle der von anderen Transaktionstypen verwendeten RLP-Kodierung verwendet.
• UPDATE: Während des 161. Ethereum Executive Layer Core Developers Meeting gab es eine Diskussion über das EIP Die Diskussion über das SSZ-Serialisierungsformat für 4844 zeigte, dass die Entwickler zunächst geneigt waren, eine frühe Iteration des SSZ-Formats über Blob-Transaktionen in EL einzuführen, und schließlich planten die Entwickler, alle Transaktionstypen von RLP auf SSZ zu aktualisieren, allerdings angesichts des unklaren Pfads und schon gar nicht beim Cancun-Upgrade implementiert, haben die Entwickler darüber nachgedacht, SSZ aus EIP-4844 zu entfernen. Nach langer Diskussion einigten sich die Entwickler darauf, SSZ aus der EL-Implementierung von EIP-4844 zu entfernen. *****EIP6475 wird jedoch nicht entfernt. **SSZ-> Durch die RLP-Änderungen werden die beiden SSZs in Cancun nicht mehr benötigt EIPs: ** Deshalb EIPs 6475 und 6493 werden für Upgrades aus Cancun verlegt. **

EIP 6493X

• Einführung: SSZ-Transaktionssignaturschema. Diese EIP definiert ein Signaturschema für mit Simple Serialization (SSZ) codierte Transaktionen und befasst sich mit der Art und Weise, wie Knoten mit Blob-Transaktionstypen umgehen sollen, die auf CL im SSZ-Format formatiert, auf EL jedoch anders codiert sind. Dieses EIP ist Teil eines Updates des Ethereum-Serialisierungsformats für schichtübergreifende Konsistenz;
• Hintergrund: SSZ Änderungen
• Einführung: Einfach SerialiZe ist die Serialisierungsmethode, die in der Beacon-Kette verwendet wird.
• SS Die Änderungen umfassen auch drei weitere unterstützende Vorschläge, dieses Mal wurde nur 6465 eingeführt.
• EIP 6465: SSZ-Entzugswurzel, definiert vorhandene Merkle-Patricia Migration von Trie (MPT)-Verpflichtungen zu Simple Serialization (SSZ)-Abhebungen;
• EIP 6404 / EIP 6466:
• Beide definieren eine bestehende Merkle-Patricia Trie-Versprechen (MPT) werden derzeit auf Simple Serialization (SSZ) migriert.
• EIP-6404 – SSZ-Transaktionsstamm
• EIP-6466 — SSZ-Quittungsbasis

Tim Beiko** schlug zukünftige Entwicklungen rund um die Erweiterung von Cancun in einem Kernentwicklertreffen am 5Monat26*** vor. Gespräche finden statt auf die folgenden fünf beschränktEIP:EIP 5920,5656,7069,4788 und 2537, in diesem Rahmen werden Folgevorschläge generiert. Follow-upEIP 5656*** und EIP 4788 wurde als offizieller Upgrade-Vorschlag bestätigt, 5920,7069 und 2537 entfernt, woEIP 5920 ist auf die Besorgnis des Entwicklers über die möglichen Nebenwirkungen der Art der Übertragung von ETH** sowie auf die noch nicht abgeschlossenen Überlegungen, Tests und Sicherheitsarbeiten des Upgrades zurückzuführen entfernen. ***

EIP 5920**:**X

• Einführung: Zahlungs-Opcode. Führt den neuen Opcode PAY für Ethereum-Transfers ein, der Ether an eine Adresse sendet, ohne eine seiner Funktionen aufzurufen.
• Grund: Derzeit erfordert das Senden von Ether an eine Adresse, dass der Benutzer eine Funktion für diese Adresse aufruft, was mehrere Probleme mit sich bringt:
• Erstens eröffnet es einen Vektor für Wiedereintrittsangriffe, da der Empfänger den Absender zurückrufen kann;
• Zweitens öffnet es einen DoS-Vektor, sodass die übergeordnete Funktion sich darüber im Klaren sein muss, dass dem Empfänger möglicherweise der Treibstoff oder der Rückruf ausgeht;
• Schließlich ist der CALL-Opcode für einfache Ether-Transfers unnötig teuer, da er eine Erweiterung des Speichers und des Stacks, das Laden der vollständigen Daten des Empfängers, einschließlich Code und Speicher, erfordert und schließlich einen Anruf ausführen muss, was möglicherweise andere unbeabsichtigte Vorgänge ausführt.
• Ändern:
• Ein neuer Opcode wird eingeführt: ( PAY) PAY_OPCODE wobei:
• Nimm zwei Werte vom Stapel: addrthen val.
• Übertragen Sie wei von der Ausführungsadresse val zur Adressadresse. Wenn addr eine Nulladresse ist, wird valwei anhand der Ausführungsadresse programmiert.
• Mögliche Fallstricke: Bestehende Verträge werden unabhängig vom tatsächlichen Guthaben ihres Wallets genutzt, da es bereits möglich ist, Ether an eine Adresse zu senden, ohne diese anzurufen.
• Bedeutung: sparen Gas**. ** *Aktualisierung: 09.06.23 PAY wurde aus dem Upgrade entfernt, da Bedenken hinsichtlich möglicher Nebenwirkungen der Art und Weise der ETH-Übertragung sowie der für die Verabschiedung des Vorschlags erforderlichen Begründungs-, Test- und Sicherheitsarbeiten bestehen.

EIP 7069X

• Einführung: Geänderte CALL-Anweisung
• GEÄNDERT: Es wurden drei neue Aufrufanweisungen eingeführt, CALL2, DELEGATECALL2 und STATICCALL2, die eine Vereinfachung der Semantik bewirken. Ziel ist es, die Beobachtbarkeit von Gas aus der neuen Richtlinie zu streichen und die Tür zu einer neuen Klasse von Verträgen zu öffnen, die von der Preisanpassung nicht betroffen sind.
• Hintergrund:
• 63/64-Regel: Begrenzen Sie die Anruftiefe und stellen Sie sicher, dass der Anrufer über verbleibende Energie verfügt, um Zustandsänderungen vorzunehmen, nachdem der Angerufene zurückgekehrt ist.
• Vor der Einführung der Regeln 63/64 war eine etwas genauere Berechnung des verfügbaren Gases des Anrufers erforderlich. Solidity verfügt über eine komplexe Regel, die versucht, die Kosten auf der Anruferseite für die Ausführung des Anrufs selbst abzuschätzen, um einen angemessenen Gaswert festzulegen.
• **Derzeit wird **63/64 eingeführt Regeln:
• Anruftiefeninspektion gelöscht;
• Stellen Sie sicher, dass Sie mindestens 5000 Gas reservieren, bevor Sie das aufgerufene Verhalten ausführen.
• Stellen Sie sicher, dass für das aufgerufene Verhalten mindestens 2300 Gas verfügbar sind.
• Subventionsregeln: Wie die bekannte 2300-Subvention: Wenn ein Vertrag einen anderen Vertrag aufruft, erhält der aufgerufene Vertrag 2300 Gas wird verwendet, um sehr begrenzte Vorgänge durchzuführen (genug, um eine kleine Berechnung durchzuführen und ein Protokoll zu erstellen, aber nicht genug, um einen Speicherplatz zu füllen), und da es eine feste Gasmenge festlegt, gibt es für Menschen keine Möglichkeit, diese als zu bestimmen solange der Gaspreis angepasst werden kann. Welche Berechnungen kann Gas unterstützen?
• Bedeutung: ** Bereitet den Weg für die zukünftige Einführung von ** EOF ** und ist für die Abwicklung großer Verträge bequemer. **
• Gas-Optionalität entfernt: Neue Richtlinien erlauben keine Angabe von Gas begrenzen, sondern sich auf die „63/64-Regel“ verlassen (die sich hauptsächlich auf die Neubepreisung von Gas für eine große Anzahl von IO-Vorgängen in EIP-150 bezieht, die den Gasverbrauch bestimmter Vorgänge erhöht), um das Gas zu begrenzen. Diese wichtige Verbesserung vereinfacht Der Prozess basiert auf der „Zulagen“-Regel. Unabhängig davon, ob der Wert gesendet wird oder nicht, muss der Anrufer keine gasbezogenen Berechnungen durchführen.
• Nach der Einführung des neuen Vorschlags können Benutzer Out jederzeit überwinden, indem sie mehr Gas in der Transaktion senden (natürlich vorbehaltlich des Blockgaslimits). des Gasfehlers.
• Früher wurden bei der Erhöhung der Speicherkosten (z. B. EIP-1884 erhöhte Gasmengen für bestimmte Opcodes) einige Verträge, die nur eine begrenzte Menge Gas an ihre Anrufe schickten, durch den neuen Kostenmechanismus gebrochen. Zuvor hatten einige Verträge eine Tankobergrenze, die die Menge an Benzin, die sie ausgeben konnten, dauerhaft begrenzte. Selbst wenn sie es in ihre Unteranrufe schickten, würde es nicht funktionieren, egal wie viel zusätzliches Benzin sie schickten, weil der Anruf die Menge an Benzin begrenzen würde Betrag gesendet.
• Den Weg für die Einführung von EOF ebnen: Sobald das EVM Object Format (EOF) eingeführt ist, können alte Call-Anweisungen im EOF-Vertrag abgelehnt werden, wodurch sichergestellt wird, dass sie weitgehend immun gegen Gaspreisänderungen sind. Da diese Vorgänge erforderlich sind, um die Beobachtbarkeit von Gas zu verhindern, wird EOF sie anstelle bestehender Anweisungen verlangen;
• Praktischere Status-Rückgabecodes: Es wurden praktische Funktionen eingeführt, die detailliertere Statuscodes zurückgeben: Erfolg (0), Wiederherstellung (1), Fehler (2), und können in Zukunft erweitert werden.

EIP 2537**:**X

• Einführung: Vorkompilierung der BLS12-381-Kurvenmanipulation.
• Geändert: Es wurden Operationen auf der BLS12-381-Kurve hinzugefügt, die auf den Satz vorkompiliert wurden, der für die effiziente Durchführung der BLS-Signaturüberprüfung und der SNARKs-Überprüfung usw. erforderlich ist.
• Bedeutung: Ethereum kann sicherere kryptografische Beweise erstellen und eine bessere Interoperabilität mit der Beacon-Kette ermöglichen**. **

PR 3175 *** Erwähnt, aber nicht in die engere Wahl gezogen, keine weitere Diskussion ***

PR 3175**:**X

• Kurzfassung: Dieser Vorschlag würde bestrafte Validatoren daran hindern, Blöcke vorzuschlagen, wenn sie aus der Warteschlange entfernt werden. Wenn mehr als 50 % der Validatoren für böswilliges Verhalten bestraft werden, können diese Validatoren immer noch Sperren vorschlagen, während sie gewaltsam aus dem Netzwerk entfernt werden. Die Änderung dieser Logik ist eine relativ geringfügige Änderung der CL-Schicht, die Schutz vor „hohen Fehlermodi“ bietet, sagen die Entwickler.
• Laut dem 108. Ethereum Core Developers Consensus Meeting am 4. Mai, PR 3175 wird derzeit als EIP formatiert und wird aus Sicherheitsgründen in EIP-6987 geändert, um zu verhindern, dass abgekürzte Validatoren als Blockantragsteller ausgewählt werden.

Zukunft

Basierend auf den oben genannten Informationen sind wir zu folgenden Schlussfolgerungen gelangt:

**1.**Die Hauptziele des Cancun-Upgrades sind, in der Reihenfolge ihrer Priorität, Kapazitätserweiterung, Sicherheit, Einsparung von Gas und Interoperabilität:

• Es besteht kein Zweifel, dass der Ausbau oberste Priorität hat (4844);
• Sicherheit und Gaseinsparung stehen an zweiter Stelle (6780, 1153, 5656 und 7045), unter Berücksichtigung einer gewissen Entwicklererfahrung;
• Der dritte Punkt ist die Interoperabilität, beispielsweise die Optimierung der Verbindung, Kommunikation und Interoperabilität zwischen Dapps (4788, 7044 und 6988);
• Erwartete Daten: Testnet 4844 kann Opside reduzieren 50 % der Rollup-Kosten; die technischen Lösungen von EigenLayer und Celestia haben nicht allzu viel preisgegeben, und ihre Daten können nicht ausgewertet werden; Ethstorage schätzt, dass die Kosten von DA auf 5 % des Originals sinken werden; Topia geht davon aus, die Kosten zu senken um das 100- bis 1000-fache.

2.** Cancun-Upgrade In den nächsten 2~5 Jahren Danksharding** ist es die goldene Entwicklungsperiode von DA-Schichtprojekten****

• Schicht Die Sicherheitsobergrenze von 2 hängt von der verwendeten DA-Schicht ab. Proto-Danksharding wird dem Speicherprotokoll, dem modularen Protokoll und dem L1-Speichererweiterungsnetzwerk durch eine günstigere staatliche Datenspeicherung zugute kommen.
• **Zuerst **Danksharding kehrt zum Wesen der Ethereum-Zustandsmaschine zurück. V Gott erwähnte, dass der Zweck des Ethereum-Konsensprotokolls nicht darin besteht, die dauerhafte Speicherung aller historischen Daten zu gewährleisten. Stattdessen soll ein hochsicheres Echtzeit-Bulletin-Board bereitgestellt und Platz für andere dezentrale Protokolle zur längerfristigen Speicherung gelassen werden (Der Der Zweck des Ethereum-Konsensprotokolls besteht nicht darin, zu garantieren Speicherung aller historischen Daten für immer. Der Zweck besteht vielmehr darin, Stellen Sie ein hochsicheres Echtzeit-Bulletinboard bereit und lassen Sie Platz für andere dezentrale Protokolle zur längerfristigen Speicherung. ）；
• **Zweitens reduziert **Danksharding **die Kosten für **DA **, aber auch die tatsächlichen Landezeit- und Datenverfügbarkeitsprobleme müssen gelöst werden. **
• DA** Kostenreduzierung: **Vor diesem Update war es notwendig, calldata aufzurufen, um Daten vom Rollup in der Ethereum-Hauptkette zu veröffentlichen, und die Gasgebühr für den Aufruf dieses Codes war sehr teuer, was sehr hoch ist Die größte Auszahlung von 2, die EIP 4844 führt Data Blob als zusätzlichen Datenraum ein, der nur für Rollups gilt, wodurch die Speicherkosten und damit die DA-Kosten erheblich gesenkt werden.
• Die tatsächliche Landezeit ist lang und das verbesserte ** TPS ** und das reduzierte ** Gas ** sind immer noch begrenzt, also ist es gut für ** DA * * Layer-Projekte in nachfolgender Weiterentwicklung:
• Ich bin beunruhigt über Danksharding in Polynya Im Artikel zum Sharding von Sicherheitsdaten wird darauf hingewiesen, dass die Implementierung zwei bis fünf Jahre dauern wird.
• ** Selbst wenn es landet, kann es ** TPS ** erhöhen und ** Gas reduzieren. Die Größenordnungen sind immer noch begrenzt:**
• EIP 4844 unterstützt derzeit 6 Blobs, und das zukünftige Erweiterungsproblem kann nur durch Danksharding gelöst werden;
• Der aktuelle Ethereum-Blockplatz beträgt etwa 200 KB. Nach Danksharding beträgt die geplante Größe in der Spezifikation 32 Megabyte, was einer etwa 100-fachen Verbesserung entspricht. Derzeit liegt der TPS von Ethereum bei etwa 15. Im idealisierten Zustand wird er nach einer 100-fachen Erhöhung bei etwa 1500 liegen, was keine große Größenverbesserung darstellt.
• Daher lange Zeit bis zur Landung + Begrenzte tatsächliche Änderungen werden von Vorteil sein DA Layer-Projekte, einige wie Celestia, ** Eigenda** ** ** DA ** Projekt kann immer noch zu günstigeren Kosten und schneller passieren ** TPS *, um in Zukunft mit ** Danksharding ** zu konkurrieren , ETH-Speicher Topia und andere neue DA-Projekte können ebenfalls die Marktlücke schließen, bevor sie landen. **
• Technische Probleme wie Datenspeicherung und Datenverfügbarkeit müssen ebenfalls behoben werden:
• Es gibt zwei Hauptkosten von DA: Der eine sind die Kosten für die Netzwerkbandbreite, der andere sind die Speicherkosten, und 4844 selbst löst nicht das Speicherproblem und das Bandbreitenproblem der Blockkette
• Der Blob wird etwa 3 Wochen lang auf der Ethereum-Konsensschicht gespeichert und dann gelöscht. Wenn Sie vollständige historische Aufzeichnungen speichern und alle Daten verfügbar machen möchten, umfassen die aktuellen Lösungen: Dapp selbst speichert Daten, die sich auf sich selbst, das Ethereum-Portalnetzwerk, beziehen (derzeit in Entwicklung) oder Protokolle von Drittanbietern wie Block-Explorer, historische Daten in BitTorrent oder spontane Speicherung durch einzelne Benutzer.
• Daher wird Proto-Danksharding dem Speicherprotokoll, dem modularen Protokoll und dem L1-Speichererweiterungsnetzwerk zugute kommen:
• Die Nachfrage nach dem Aufruf historischer Daten wird zu einem neuen Entwicklungskanal für dezentrale Speicherprotokolle oder Indexprotokolle von Drittanbietern führen;
• Nachfolgende modulare Vereinbarungen können Transaktionen über Hochgeschwindigkeits-Rollup ausführen, die sichere Abwicklungsschicht ist für die Abwicklung verantwortlich und die kostengünstige Datenverfügbarkeitsschicht mit großer Kapazität ist für die Garantie verantwortlich;
• Gutes L1-Speichererweiterungsnetzwerk, wie z. B. Eth Speicher, der eine Second-Tier-Lösung für programmierbaren Speicher zu geringeren Speicherkosten bieten kann.

**3.**Cancun-Upgrade-Vorteile L2Diversity, L3, RAAS und Datenverfügbarkeit und andere Tracks

• L2-Track-Analyse:
• Hauptschicht2, wie z. B. Arbitrum Orbit、OP Stapel、Polygon2.0、Fraktal 5 Projekte, darunter Scaling (unter StarkWare) und HyperChain (unter zkSync), werden davon profitieren. Durch die Reduzierung der Speichergebühren durch Blob wird die vorherige Serie zu einer eingeschränkten Schicht 2 Die Entwicklungskosten und Skalierbarkeitsprobleme wurden erheblich verbessert, und der Datendurchsatz wurde erheblich verbessert. Nach der Lösung des Kostenproblems wurde die Hauptschicht gelöst 2 Es besteht die Möglichkeit, weiterhin eine hochgradig angepasste Multi-Chain-Parallel-L3-Ökologie für bestimmte Funktionen bereitzustellen;
• Die Lücke bei den Betriebskosten zwischen Second-Tier-Layer2 und Mainstream-Layer2 wird kleiner, was einigen kleinen Projekten mehr Entwicklungsmöglichkeiten bietet, wie z. B. Aztec, Metis, Boba, ZKspace, Layer2.finance usw.;
• Obwohl die tatsächlichen Anforderungen modularer Blockchain-Projekte noch überprüft werden müssen, sind immer noch verschiedene Programmiersprachen möglich, wie z. B. Cario von Starkware, Sprachen der Move-Serie, Sprachen der C-, C+±, C#- und Go-Serie, die von Wasm unterstützt werden und dies können Stellen Sie weitere Web2-Entwickler vor.
• Raas-Track-Analyse:
• Der Vorteil von Raas selbst liegt in seinem hohen Maß an Individualisierung, individuellen Anforderungen > reinen Kosten und Effizienz, daher ist die Kostenreduzierung ein großer Vorteil des maßgeschneiderten Rollups.
• Das Problem mit dem RAAS-Track besteht jedoch darin, dass es sich möglicherweise um einen OverHype handelt, und es bestehen sogar Zweifel am RAAS-Track selbst. ** Angesichts der Konkurrenz von ** 5 ** Köpfen** Layer2 ** und der Entstehung verschiedener neuer ** DA ** können neue Projekte ein Problem darstellen ein Fragezeichen auf der Strecke. **
• Zuerst die Header-Ebene 2 Der Vorteil der Bereitstellung der Anwendungskette liegt in der Integrität des Netzwerkrahmens und der Sicherheit der Ökologie zwischen den Ketten, und der Vorteil von RAAS liegt in seiner Anpassung und Freiheit;
• Allerdings sind die technischen Barrieren von RAAS der OP- und ZK-Serie derzeit nicht stark, und sie befinden sich kurzfristig noch im Testnet-Stadium, und es gibt keine tatsächliche Produktinteraktion. In Anbetracht des tatsächlichen Fortschritts von RAAS, technischen Formen und Angesichts der ökologischen Vorteile von Layer3 in der Zukunft ist der tatsächliche Bedarf von RAAS zweifelhaft.
• OP-Abteilung: Obwohl OP Grundstein-Upgrade+ des Stapels Die Einführung von 4844 hat zu einer geringfügigen Kosten- und Effizienzsteigerung geführt, die Steigerung ist jedoch nicht sehr attraktiv.
• ZK-Serie: Derzeit folgen viele führende Projekte dem ZKEVM-Weg und legen mehr Wert auf die Kompatibilität mit Ethereum, sodass das Schaltungsdesign eine gewisse Effizienz opfert und nicht so zielgerichtet ist wie die OP-Serie. Aber der ZK ist derzeit auf dem Markt Die meisten RAAS verwenden immer noch führende Projekte (wie ZkSync), um die Kette zu verzweigen, und die Barrieren sind immer noch nicht stark.
• SO, kurzfristig OP RAAS** **Es gibt noch Raum für Entwicklung, bevor ** layer3 ** landet. Auf lange Sicht ** ZK RAAS ** und ** Layer3 ** könnten der zukünftige Trend sein. **
• ZK RAAS hat nach 4844 einen größeren Kostennachteil und verbraucht viel mehr Rechenleistung als OP. Obwohl die Kosten für das Hochladen auf L1 geringer sind als die für OP, ist dies nur ein Tropfen auf den heißen Stein im Vergleich zu den Kosten des Proof-Prozesses. während OP Der Vorteil besteht darin, dass in kurzer Zeit schnell eine Ökologie aufgebaut werden kann und vor der Landung von Schicht 3 noch Raum für Entwicklung vorhanden ist.
• Für herkömmliche DeFi-Anwendungen und NFT-Märkte ist die Transformation des Rollups keine starre Anforderung. Nur Zahlungsanwendungen oder Spiele, die eine hohe Effizienz erfordern, haben eine stärkere Nachfrage nach Rollup. In Zukunft könnten sich DeFi-Projekte auf L2 befinden, soziale Projekte auf L3 oder außerhalb der Kette und schließlich werden Kerndaten und Beziehungen auf L2 platziert. Gaming-Projekte müssen auf L3 oder Rollup gehen, aber wenn man bedenkt, dass die meisten davon aktuell sind Kettenspiele sind im Wesentlichen Fonds, und die Unfähigkeit von Token, extern zu zirkulieren, hat zu Entwicklungsengpässen geführt, gepaart mit dem Aufkommen von Spielen in der gesamten Kette. Die ökologische Attraktivität von L3 selbst ist weitaus größer als die von Rollup.

**4.**Cancun-Upgrade verbessert Entwickler- und Benutzererfahrung

• Cancun aktualisiert den zweiten wichtigen Vorschlag SELBSTZERSTÖRUNG Durch die Entfernung wird die Sicherheit von Ethereum weiter verbessert. Gleichzeitig wird für mögliche Probleme bei der programmgesteuerten Kontoaktualisierung nach der Löschung ein neuer Operationscode SETCODE vorbereitet, um diese Situation zu verbessern;
• Dritter EIP-Vorschlag für Cancun-Upgrade 1153 fügt einen transienten Speicherbetriebscode hinzu, der erstens Gas sparen kann, zweitens das Problem der Inter-Frame-Kommunikation löst und schließlich den Weg für zukünftige Speicherdesigns wie Verkle Tree ebnet, die das Rückerstattungsproblem transienter Transaktionen nicht berücksichtigen müssen Lagerung;
• Vierter EIP-Vorschlag für Cancun-Upgrade 5656 führt den Speicherkopierbefehl MCOPY ein, mit dem Codewörter und -sätze genauer kopiert werden können, wodurch die Speicherkopierleistung um etwa 10 % verbessert wird.
• Der fünfte Vorschlag für ein Cancun-Upgrade ist EIP 4788 kann die Kommunikation zwischen verschiedenen Protokollen und Anwendungen im Ethereum-Netzwerk effizienter und sicherer machen und auch vertrauenswürdigere Designs für Pfandpools, Bridging- und Restaking-Protokolle ermöglichen;
• Cancun aktualisiert die neuesten (15. und 23. Juni) vorgeschlagenen CL-zentrierten EIP-Upgrades: EIP 6988、EIP 7044、EIP 7045, das die Sicherheit und Benutzerfreundlichkeit von Ethereum im Detail verbessert, beispielsweise durch die Verbesserung der Erfahrung von Pfandgebern und die Verbesserung der Netzwerksicherheit.
• Zu den gelöschten Vorschlägen gehört SSZ-> Durch die Transformation des RLP entstehen die beiden SSZs EIP（EIP 6475 und EIP

6493. wurde aus dem Cancun-Upgrade entfernt; EOF-bezogene Vorschläge wurden aus dem Cancun-Upgrade entfernt, nachdem sie aus dem Shanghai-Upgrade entfernt wurden, und es wird derzeit davon ausgegangen, dass sie direkt im späteren täglichen Upgrade implementiert werden können; EVMMAX ist auf einige EIPs zurückzuführen im Zusammenhang mit der EOF-Implementierung Teilmenge, daher wurde es auch aus Cancun zur Aktualisierung zusammen mit EOF verlegt; unter Berücksichtigung der möglichen Nebenwirkungen, die bei der Übertragung der ETH auftreten können, sowie der Argumentation, Tests und Sicherheitsarbeiten, die für die Verabschiedung des Vorschlags erforderlich sind , EIP 5920 aus dem Upgrade entfernt.

**5. **Beziehung mit zkml und Kontoabstraktion

Geringe Auswirkung auf zkml

• ZKML ist wissensfrei (Zero Wissen) und maschinelles Lernen (Machine Lernen); die Kombination aus **Blockchain und ML Modell löst die Datenschutz- und Überprüfbarkeitsprobleme des maschinellen Lernens:
• Datenschutz: Die Vertraulichkeit der Eingabedaten, z. B. die Verwendung einer großen Menge persönlicher Informationen als Daten, um die Maschine für Schulungen zu füttern, ist die Vertraulichkeit persönlicher Informationen eine wichtige Anforderung; oder Modellparameter sind die Kernkompetenz des Projekts Verschlüsselung ist auch erforderlich, um Wettbewerbsbarrieren aufrechtzuerhalten. Wenn Vertrauensprobleme wie diese bestehen, werden ML-Modelle daran gehindert, größere Daten und Anwendungen zu erhalten.
• Überprüfbarkeit: Die wissensfreie Proof-Technologie hat ein breites Anwendungsspektrum, und ZKP ermöglicht es Benutzern, die Richtigkeit von Informationen ohne Überprüfung zu ermitteln. Und da das Modell des maschinellen Lernens viele Berechnungen erfordert, kann das ML-Modell Beweise über ZK-SNARK generieren, wodurch die Beweisgröße reduziert und der Rechenleistungsbedarf von ML verringert wird.
• Die Speicheranforderungen von ZKML ** haben wenig zu tun mit ** DA **: **Benötigen Sie so etwas wie Speicherplatz Die Kerntechnologie dieser separaten Speicherstruktur ist das „SQL-sichere“ neue Sicherheitsprotokoll. Einfach ausgedrückt handelt es sich um ein Data Warehouse neben der Blockchain, das es Entwicklern ermöglicht, On-Chain und Off-Chain in einem einfachen SQL-Format zu verbinden. Daten und Laden Sie die Ergebnisse direkt in den Smart Contract;
• ZK-SNARKs **ist die Hauptform von ** ZK ** in ** ZKML ** und kann an die On-Chain-Berechnung von ** **ML angepasst werden ** ** Mit der Entwicklung der Kryptographie wird insbesondere der rekursive **SNARK Beweis von Vorteil sein ZKML Landung in der Kette:
• ZK-SNARKs zeichnen sich durch hohe Kompaktheit aus. Durch die Verwendung von ZK-SNARKs kann der Prüfer einen kurzen Beweis generieren, und der Verifizierer muss nicht interagieren und muss nur einen kleinen Berechnungsaufwand durchführen, um seine Gültigkeit zu überprüfen. Diese Art von Beweis Benötigt nur einmal Die Art der Interaktion zwischen dem Verifizierer und dem Verifizierer macht ZK-SNARKs in praktischen Anwendungen effizient und praktisch und eignet sich besser für die Rechenleistungsanforderungen von ML in der Kette.
• Es ist derzeit nicht möglich, in der Kette zu trainieren, und nur die Ergebnisse von Berechnungen außerhalb der Kette können in der Kette gespeichert werden:
• Das aktuelle ML-Problem ist eher auf die unbefriedigten Anforderungen an die Rechenleistung und die geringe Leistung zurückzuführen, die durch Algorithmusbeschränkungen verursacht werden (kann nicht parallel berechnet werden). ZK-Beweise für große Modelle erfordern eine höhere Rechenleistung, die in der Kette nicht unterstützt werden kann. Derzeit beliebt ZK-SNARKs unterstützen ML-Zero-Knowledge-Proof nur in geringem Umfang und mit geringem Rechenaufwand, d. Kettenberechnungen.

Gute Kontoabstraktion

• Zuallererst kann das Cancun-Upgrade bis zu einem gewissen Grad reduziert werden ZK Rollup Gebührennachweis:
• Die aktuelle zkSync-Transaktionsgebühr hängt von drei Aspekten ab:
• Die Kosten für feste Ressourcen, die der Verifizierer für die Generierung und Überprüfung von SNARK-Beweisen verbraucht, sind relativ hoch.
• Die Gasgebühr, wenn der Verifizierer den SNARK-Nachweis an das Ethereum-Mainnet übermittelt, dieser Teil der Gebühr erhöht sich aufgrund der Überlastung des Mainnets entsprechend;
• Die vom Benutzer an den Verifizierer gezahlte Servicegebühr, einschließlich Transaktionsbestätigung, Nachrichtenübermittlung usw.
• Wenn daher 4844 eingeführt wird, wird das Problem der durch die Überlastung des Hauptnetzes verursachten erhöhten Gasgebühren gemildert und die Kosten für ZKP-Nachweise können bis zu einem gewissen Grad gesenkt werden. Obwohl dies im Vergleich zu den Kosten für die Erstellung von Nachweisen nicht viel ist, Angesichts der Tatsache, dass sich ZK noch in einem frühen Stadium befindet, sollte der zukünftige Entwicklungstrend der ZK-Serie nicht unterschätzt werden.
• **Zweitens wandelt die Kontoabstraktion herkömmliche ** tx -Transaktionen in ** Benutzeroperationen um, und dann ** Benutzeroperationen verwenden ECDSA * * In Blöcke gepackt, belegt der Speicher in der Kette mehr als zuvor, sodass der Speicherbedarf höher ist;
• **Als nächstes Kontoabstraktion und ** ZK Rollup können sich gegenseitig ergänzen:
• Das aktuelle Problem der Kontoabstraktion ist Gas Die Gebühr ist teuer, da es zu viele Schritte und intelligente Verträge gibt, sodass viele Daten anfallen, die zu Gas führen Die Gebühr ist teuer und ZK Der Vorteil von Rollup besteht darin, dass Daten reduziert werden können.
• Die Kontoabstraktion macht es schwierig, die Sicherheit zu gewährleisten: Da AA mehrere Verträge umfasst, ist die Sicherheit ein Problem, aber nach der schrittweisen Bildung von L2 in der Zukunft wird sich die Konsensschicht nicht ändern, intelligente Verträge werden mehr Verwendungsmöglichkeiten haben und die Sicherheit Auch die Kontenabstraktion kann mit Hilfe von ZK gewährleistet werden Die vertrauenswürdige Verifizierung des Rollups wird die Sicherheit weiter verbessern.
• **In Anbetracht des Aufstiegs der ** KI -Technologie kann sie schließlich dazu beitragen, die Sicherheit von On-Chain-Verträgen zu erhöhen und On-Chain-Transaktionen oder Aktivitätsschritte zu optimieren:
• KI und Sicherheit: KI-Technologie kann verwendet werden, um die Sicherheit und den Datenschutz von On-Chain-Transaktionen zu verbessern. Beispielsweise nutzt die Web3-Sicherheitsplattform SeQure KI, um böswillige Angriffe, Betrug und Datenlecks zu erkennen und zu verhindern, und bietet Echtzeit-Überwachungs- und Alarmmechanismen, um die Sicherheit und Stabilität von Transaktionen in der Kette zu gewährleisten;
• KI und Optimierung von Aktivitäten in der Kette: Zu den Aktivitäten in der Blockchain gehören Transaktionen, Vertragsausführung und Datenspeicherung. Durch die intelligenten Analyse- und Vorhersagefunktionen der KI können On-Chain-Aktivitäten besser optimiert und die Gesamteffizienz und Leistung verbessert werden. KI kann dabei helfen, Transaktionsmuster zu erkennen, ungewöhnliche Aktivitäten zu erkennen und Echtzeitempfehlungen zur Optimierung der Ressourcenzuteilung für Blockchain-Netzwerke durch Datenanalyse und Modelltraining bereitzustellen.
• **Daher wird das Cancun-Upgrade von der Erweiterung des Speicherplatzes bis zur Integration mit dem ** ZK reichen Die Komplementarität von Rollup ** und die Kombination mit ** KI **-Technologie werden der zukünftigen Entwicklung der Kontoabstraktion schrittweise zugute kommen. **

**6.**Rückblick auf die Ethereum-Roadmap: Was kommt als nächstes?

• **Derzeit hat **Layer2 ** keine ähnliche Leistung (in Bezug auf Latenz und Durchsatz) wie ** Solana **, noch wie ** Near ** Solche Sharding-Leistung und keine parallele Ausführungsleistung wie ** Sui ** und ** Aptos **, das Cancun-Upgrade hat die führende Position von Ethereum als Marktführer verbessert; **
• Nach dem Cancun-Upgrade werden mehrere größere Entwicklungszeiten geschätzt Fully-Danksharding** (2~5 Jahre), *MEV * und ** PBS Landung (1~3 Jahre), Kontoabstraktion (1~2 Jahre), ***ZK * * *Alles (3~6 Jahre), EOF und Entwicklererfahrung (wie oft haben Sie die Erweiterung gesehen?). **

Der Geißel

• Ziel: Konzentrieren Sie sich auf die Lösung von MEV-Problemen.
• Lösung: Minimieren Sie MEV auf der Anwendungsebene durch „Proposer-Builder Separation (PBS)“. Zu diesem Zeitpunkt können Blobs optimiert und Vorbestätigungsdienste oder Vorkaufsschutz eingeführt werden.
• PBS ist die Trennung von Blockproduzenten und -sortierern. Der Sortierer ist unabhängig von der Kette nur für die Sortierung verantwortlich, und der Blockersteller kümmert sich nicht um die Transaktion, sondern wählt das vom Sortierer erstellte Paket direkt aus und fügt es der Kette hinzu. Dieser Prozess wird den gesamten Prozess fairer machen und MEV-Probleme lindern, was die Idee der MEV-Externalisierung ist.
• Der Fertigstellungsgrad von PBS ist immer noch sehr niedrig und die PBS sind ausgereifter Zusammenarbeit mit externen MEV-Lösungen – mevboost by flashbots.
• Erweiterte Version von „Enshrined „Proposer-Builder Separation (ePBS)“ weist einen geringeren Fertigstellungsgrad und einen längeren Zyklus auf und wird voraussichtlich kurzfristig nicht umgesetzt. Darüber hinaus gibt es progressive Versionen von PEPC und Optimistic Relaying, das die Flexibilität und Anpassungsfähigkeit des PBS-Frameworks erhöht

Der Rand

• Ziel: Verwenden Sie den Verkel-Baum, um Merkle zu ersetzen, eine Lösung zur Vertrauensminimierung einzuführen, Light Nodes die gleiche Sicherheit wie Full Nodes zu ermöglichen und die Blocküberprüfung so einfach und leicht wie möglich zu gestalten.
• Gleichzeitig wird die ZKisierung von L1 eindeutig zur Verge-Roadmap hinzugefügt. ZK wird der allgemeine Trend zukünftiger Erweiterung und Beschleunigung sein;
• Lösung: Einführung von zk-SNARKs, um das alte Proof-System zu ersetzen, einschließlich SNARK-basierter Light-Clients; SNARKs für Konsenszustandsänderungen; Enshrined Rollups.
• Verkle-Bäume sind eine effizientere Alternative zu landesspezifischen Merkle-Bäumen, die nicht einen Pfad von jedem Schwesterknoten (Knoten, die denselben übergeordneten Knoten haben) zum ausgewählten Knoten bereitstellen müssen, sondern nur den Pfad selbst als Beweis für einen Teil von Verkle Beweise sind dreimal effizienter als Merkle-Beweise.
• Verankert Rollup bezieht sich auf ein Rollup, das über eine Art Konsensintegration auf L1 verfügt. Der Vorteil besteht darin, dass es den Konsens von L1 erbt und keine Governance-Token benötigt, um Rollup-Upgrades durchzuführen. Gleichzeitig werden Berechnungen außerhalb der Kette durchgeführt und nur veröffentlicht Aufgrund der Auswirkungen auf die Blockchain kann die Anzahl der Transaktionen erhöht werden, die technische Schwierigkeit bei der Implementierung ist jedoch relativ groß. Die Kombination dieser Rollups wird in Zukunft in der Lage sein, die meisten Anforderungen des Blockchain-Ökosystems in den nächsten Jahrzehnten zu erfüllen.

Der säubern

• Der Purge bezieht sich auf das Ziel, das Protokoll zu vereinfachen, indem der Speicherbedarf reduziert wird, um an der Validierung des Netzwerks teilzunehmen. Dies wird vor allem durch den Winterschlaf und die Verwaltung von Geschichte und Staat erreicht. Historical Data Dormancy (EIP-4444) ermöglicht es Kunden, historische Daten, die älter als ein Jahr sind, zu bereinigen und die Bereitstellung auf P2P-Ebene einzustellen.
• Zustand ruhend. Beim Umgang mit dem Zustandswachstum gibt es zwei Hauptziele: schwache Staatenlosigkeit, die sich auf das Ziel bezieht, den Zustand nur zum Aufbau eines Blocks zu verwenden, ihn aber nicht zu überprüfen; der Zustand, auf den zugegriffen wird. Der Zustandsruhezustand sollte den Zustand, den ein Knoten speichern muss, um insgesamt 20–50 reduzieren GB。
• In der fünften Stufe Purge, EIP 4444 ist explizit in Roadmap geschrieben, EIP-4444 erfordert, dass der Client Daten löscht, die älter als ein Jahr sind, und in dieser Phase gibt es noch einige EVM-Optimierungsarbeiten, wie z. B. die Vereinfachung des GAS- und EVM-Vorkompilierungsmechanismus usw.;

**Der Gönnen Sie sich **

• In der letzten sechsten Stufe Splurge, EIP Erwähnt wurde auch 4337. Als langfristiger Layout-Vorschlag für die Wallet-Ökologie wird die Kontoabstraktion die Benutzerfreundlichkeit von Wallets in Zukunft weiter verbessern, einschließlich der Verwendung von Stablecoins zur Bezahlung von Benzin, Wallets zur sozialen Erholung usw.;

Referenzmaterialien:

• Update zum Ethereum-Kernentwicklertreffen:
• Äther Alle Kernentwickler rufen Nr. 148 an Zuschreibung
• Äther Alle Kernentwickler rufen #149 Writeup auf
• Äther Konsensschichtaufruf Nr. 99 Zuschreibung
• Äther Alle Kernentwickler rufen Nr. 150 an Zuschreibung
• Äther Alle Kernentwickler rufen Nr. 151 an Zuschreibung
• Äther Konsensschicht-Aufruf Nr. 100 Zuschreibung
• Äther Rufen Sie alle Kernentwickler unter der Nummer 152 an Zuschreibung
• Äther Rufen Sie alle Kernentwickler unter der Nummer 153 an Zuschreibung
• Äther Originaldiskussion im Magicians-Forum:
• Äther Rufen Sie alle Kernentwickler unter der Nummer 156 an Zuschreibung
• Äther Rufen Sie alle Kernentwickler unter der Nummer 157 an Zuschreibung
• Äther Rufen Sie alle Kernentwickler unter der Nummer 158 an Zuschreibung
• Äther Rufen Sie alle Kernentwickler unter der Nummer 159 an Zuschreibung
• Äther Alle Kernentwickler rufen die Nummer 160 an Zuschreibung
• Äther Konsensaufruf Nr. 108 für alle Kernentwickler Zuschreibung
• Äther Rufen Sie alle Kernentwickler unter der Nummer 161 an Zuschreibung
• Äther Konsensaufruf Nr. 109 für alle Kernentwickler Zuschreibung
• Äther Rufen Sie alle Kernentwickler unter der Nummer 162 an Zuschreibung
• Äther Konsensaufruf Nr. 110 für alle Kernentwickler Zuschreibung *Tim twitterte über das neueste Ethereum Cancun-Upgrade (09.06.23):
• Ethereum All Core Developers Consensus Call Nr. 111 Zuschreibung
• Äther Konsensaufruf Nr. 112 für alle Kernentwickler Zuschreibung
• Inhalte zum Ethereum-Upgrade:
• Einführung in Selbstzerstörungscode:
• Entdecken Sie den EVMMAX-Vorschlag und BLS12-381
• Was wird das Cancun-Upgrade außer EIP-4844 noch beinhalten? Ein Blick auf den neuesten Konsensaufruf von Ethereum
• Welche neuen Inhalte wurden beim Upgrade von Ethereum Shanghai hinzugefügt?
• Tweets:
• OK Ventures: Nach dem Upgrade von Ethereum Shanghai wertet Cancun potenzielle Investitionsmöglichkeiten auf. Foresight-Nachrichten
• Welche Vorschläge wird das Cancun-Upgrade neben dem hochkarätigen EIP-4844 beinhalten?
• V Gott: EVM-Funktion, deren Löschung in Betracht gezogen werden sollte
• Proto-Danksharding FAQ
• Empfohlen von V God丨Um ein tiefgreifendes Verständnis der Sharding-Roadmap von Ethereum zu haben, reicht es aus, diesen Bericht zu lesen
• Ein Artikel zum Verständnis von Danksharding, dem neuen Upgrade-Plan von Ethereum
• Entschlüsseln Sie interessante Fakten und verborgene Geheimnisse in der neuesten Roadmap von Ethereum
• Vitalik: Warum SELBSTZERSTÖRUNG der Ökologie von Ethereum mehr schadet als nützt
• Ethereum-Vision:
• Blockwerke Forschungsstipendiat Brrr: Wie Proto-Danksharding Ethereums L1 beschleunigt Rollup-Skalierbarkeit
• Das 111. Ethereum ACDC-Treffen: Besprechen Sie den endgültigen Umfang des Deneb-Upgrades und drei Vorschläge, einschließlich EIP-7044
• KOL Stacy Muurs Blick auf die Entwicklung der Ethereum-Skalierungslösungen: OP Stapel、Beliebig Umlaufbahn、Polygon 2,0
• Horizontaler Vergleich von drei Arten von Rollups: klassische Rollups (Optimistisch/ZK Rollups）、Enshrined Rollups、Sovereign Rollups
• [AMA] Wir sind EF Research (Teil 8: 07. Juli, 2022):
• 3 beliebte Titel, die es wert sind, im Jahr 2023 noch einmal überdacht zu werden
• Montenegro EDCON Gedanken zum Ende des Jahres 2023: Ein Blick auf Infrastruktur- und Anwendungstrends
• Unendliche Fantasie über die Möglichkeit, KI und Web3 zu kombinieren
• AI+Web3: Erforschung der Integration von künstlicher Intelligenz und Blockchain
• Vergleich von zk-rollup und op-rollup: Analyse, warum das aktuelle zkSync aus der Verifizierungsmethode stammt Die Benzingebühr ist hoch
• „Volumes zu Volumes hinzufügen“: Kontoabstraktionslösungen im Rollup-Zeitalter
• Eingehende Interpretation von ZKML: technische Prinzipien, Anwendungsszenarien, Vorteile und Herausforderungen
• ZKML: eine Modellbereitstellungstechnologie, die KI und Blockchain integriert, um den Schutz der Privatsphäre zu erreichen
• brauchbar Sicherheitsdaten Scherben
• Dialog mit Qi, Gründer von EthStorage Zhou | Datenverfügbarkeit und dezentrale Speicherung
• Lesen Sie die neueste Version der Ethereum-Entwicklungs-Roadmap in einem Artikel
• Über den Weltraum Und Eine kurze Einführung in die Zeit
• Ursprünglicher Vorschlag:
• EIP 4844:
• EIP 6780:
• EIP 1153:
• EIP 5920:
• EIP 5656:
• EIP 7069:
• EIP 4788:
• EIP 2537:
• EVMMAX EIPs:
• EIP 6601:
• EIP 6990:
• EOF Änderungen:
• EIP 663:
• EIP 3540:
• EIP 3670:
• EIP 4200:
• EIP 4750:
• EIP 5450:
• EIP 6475:
• EIP 6493:
• PR 3175: