Einführung in den Inhalt von Ethereum Dencun

Dencun besteht aus zwei Namen Deneb und Cancun, die die harte Gabel zwischen der Ethereum -Konsensschicht und der Ausführungsschicht darstellen.Die Dencun Hard Fork wurde in Goerli, Sepolia und Holesky Test -Netzwerken abgeschlossen, und das Hauptnetz wird auf Epoche 269568 (ungefähr 13. März 2024) durchgeführt.

Tipps zum Lesen

Vor dem Lesen dieses Artikels umfasst das erste Wissen, das Sie kennen müssen,:

Harte Gabel
Ethereum ist in eine Konsensschicht und eine Ausführungsschicht unterteilt.

Das Dencun -Upgrade enthält 9 EIPs, nämlich:

EIP-1153: Transiente Speicheropcodes (Änderungen der Ausführungsschicht)
EIP-4788: Beacon Block Root in der EVM (Änderungen der Ausführungsschicht und Konsensschicht)
EIP-4844: Shard-Blob-Transaktionen (Ausführungsschicht und Konsensschichtänderungen)
EIP -5656: MCOPY – Speicherkopieranweisung (Ausführungsschicht ändert sich)
EIP-6780: Selfstruction nur in derselben Transaktion
EIP-7044: Dauerhaft gültig unterschriebene freiwillige Ausgänge
EIP-7045: Erhöhen Sie MAX BEARTWERSCHAFT-Einschlussschlitz (Veränderungen der Konsensschicht)
EIP-7514: MAX-Epoche-Abkürzungsgrenze hinzufügen (Änderungen der Konsensschicht)
EIP-7516: Blobbasefee Opcode (Ausführungsschichtänderungen)

In diesem Artikel werden die Änderungen und Auswirkungen dieser EIPs eingeführt (ohne EIP-4844).

Rollups große Ergänzung: Proto-Danksharding (i)

https://medium.com/taipeiThereum-meetup/rollup-and-boost-from-proto-danksharding-85d2fe0566b6

Rollups große Ergänzung: Proto-Danksharding (II)

https://medium.com/taipeiThereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

Als nächstes werden wir die Reihenfolge, die grob in „EIP im Zusammenhang mit Ausführungsschichtänderungen“, „EIP im Zusammenhang mit Konsensschichtänderungen“ und „EIP in Bezug auf EIP-4844“ einführen.

EIP-1153

Ausführungsschicht ändert sich
EIP-1153: Transiente Speicheropcodes

https://eips.ethereum.org/eips/eip-1153

EIP-1153: Fanseite

https://www.eip1153.com/

EIP-1153: Transiente Speicheropcodes

https://ethereum-magices.org/t/eip-1153-transient-storage-opcodes/553

EIP-1153 hat zwei neue Opcodes hinzugefügt: TStore und TLOAD, mit denen „temporäre“ Speicherdaten geschrieben und gelesen werden.Sie werden für viele Vertragsentwickler viele Gaskosten einsparen.

Hintergrund

Der Speicher bezieht sich auf die Smart -Vertrags -Schreibdaten in den Speicherplatz des Vertrags über das SSTORE -OPCODE.Das „vorübergehende“ Merkmal ist, dass die von TStore geschriebenen Daten im Vergleich zu „permanenter Existenz“ bis zum Ende der Transaktion gültig sind.

Betriebsdetails

TStore ist viel billiger als SSTORE, und seine Gültigkeitsdauer kann zwischen verschiedenen Verträgen (bis die Transaktion endet). Der Gedächtnis des B -Vertrags.Dies ist sehr hilfreich für viele Verwendungen:

Wiedereinzugsschloss.Derzeit kann das Wiedereintrittsschloss nur mit SSTORE simuliert werden.
Wird in ERC-20 verwendet, genehmigen Sie innerhalb einer einzigen Transaktion.Wenn Vertrag A mit Vertrag B interagiert, und Vertrag A muss ERC-20 von Vertrag B übertragen, genehmigt Vertrag B zuerst ERC-20, um A vor dem Rufen des Vertrags A.Da die Genehmigung von ERC-20 über SSTORE ist, sind die Kosten nicht niedrig, und die Änderung der Verwendung von TStore wird die Kosten erheblich senken.
Bereitstellungsparameter beim Bereitstellen von Verträgen über create2.Da sich der Konstruktorparameter auf die Vertragsadresse von Create2 -Bereitstellungen auswirkt, wird der Vertragskonstruktor so konzipiert, dass der Auftragskonstruktor die Speicherlieseparameter des Vertrags, wie z.Mit Tstore kann ein solches Modell viele Kosten sparen.

Dinge zu beachten

Wenn Vertragsentwickler Tstore verwenden, um ihre eigene Wiedereinströmungsschloss umzuschreiben, denken Sie daran, das Schloss zu löschen, wenn es an der Zeit ist, es zu löschen. Wenn Sie während des Transaktionsprozesses einen Bedarf haben, können Sie bei der Abgabe des Vertrags möglicherweise nicht eingeben, da die Sperre nicht entsperrt ist (nicht gelöscht).
EIP-1153 wurde in Solidity Version 0.8.24 auf den Markt gebracht, und Entwickler können es im Voraus ausprobieren.Hier sind die von Entwicklern implementierten Mutex -Beispielen.UNISWAP V4, das auf Tstore angewiesen ist, wird auch nach Abschluss des Dencun -Upgrades gestartet.
Dieser EIP hat einen neuen Opcode. Wenn Entwickler also Verträge für mehrere Ketten einsetzen möchten, sollten sie darauf achten, ob alle Ketten den neuesten Opcode unterstützen, andernfalls ist er nicht verfügbar.

EIP-4788

Ausführungsschicht ändert sich
EIP-4788: Beacon Block Root im EVM

https://eips.ethereum.org/eips/eip-4788

EIP-4788: Beacon Root in EVM

https://ethereum-magices.org/t/eip-4788-beacon-root-in-evm/8281

EIP-4788 fügte einen Vertrag von Beacon_roots_address hinzu, damit Personen Daten aus Konsensschichtblöcken lesen können. Die Ausführungsschicht kann Daten aus der Konsensschicht lesen.Durch diesen Vertrag können die Einstell- und Wiedergut -Protokolle Konsensschichtdaten lesen und verwenden, ohne dass Dritte vertrauen, z. B. den Status eines bestimmten Verifizierers.

Betriebsdetails

Benutzer oder Verträge können das Beacon -Block -Root zu einem bestimmten Zeitpunkt abfragen, indem Sie den Vertrag aufrufen.Die Blockwurzel entspricht dem Hash -Wert des Blockinhalts (Beacon Block Hash), der die Merkle -Baumwurzel des Blockinhalts durch SSZ -Codierung ist.Der Anrufer codiert den Zeitstempel in den Wert von UINT256 und behandelt ihn als Anrufinhalt.

Wenn ein Entwickler die Informationen zur Konsensschicht verwenden möchte, wird sein Vertrag die Blockwurzel des Konsensschichtblocks abfragen ) und Merkle -Beweis, um zu überprüfen, ob die Informationen zur Wurzel des Blocks gehört.(SSZ Da der Inhalt in Merkle Tree aufgebaut wird, können alle Informationen im Inhalt den entsprechenden Merkle -Proof generieren, um zu überprüfen, ob die Informationen im Inhalt vorhanden sind.)

△ Der Benutzer stellt den Zeitstempel von Merkle -Proof- und Konsensschichtblöcken zur Verfügung

△ Merkle Proof wird verwendet, um die Überprüfungsbilanz zu einem bestimmten Zeitpunkt zu überprüfen.

Der im Vertrag von Beacon_roots_address gespeicherte Konsensschichtblock ist jedoch tatsächlich das Blockwurzel des „Haupt“ -Blocks (dh der vorherige Block) und nicht die Blockwurzel desselben Blocks wie die Ausführungsschicht.

△ Der Zeitstempel von Block 11001 (1234567) entspricht der Blockwurzel von Block 11000.In ähnlicher Weise entspricht der Zeitstempel von Block 11000 (1234555) der Blockwurzel von Block 10999.

Dinge zu beachten

Der Vertragsvertragsvertragsblockblock -Blockwurzeln von Beacon_roots und 8191 werden überschrieben.Wenn es sich beispielsweise um Block 18191 handelt, ist der aktuelle Block -Root -Bereich, auf den er zugegriffen werden kann, das Blockwurzel von Block 10000 bis Block 18190.

EIP-5656

Ausführungsschicht ändert sich
EIP -5656: MCOPY – Speicherkopieranweisung

https://eips.ethereum.org/eips/eip-5656

EIP-5656 hat einen Mcopy-Opcode hinzugefügt, der speziell zum Kopieren der im Speicher während der Vertragsausführung gespeicherten Werte verwendet wird.Der Vertrag profitiert von den Gaskosteneinsparungen dieses Opcode.

Um Mcopy Opcode zu verwenden, müssen Vertragsentwickler die Compiler -Version als 0,8.24 (oder höher) und die EVM -Version als Cancun angeben:

△ Um MCOPY zu verwenden, müssen Sie die Compiler -Version und die EVM -Version festlegen

HINWEIS: Der Compiler von Version 0.8.24 ist nur für die Verwendung von MCOPY (MCOPY (), Link) durch die Assemblierung geöffnet.

Dinge zu beachten

Dieser EIP hat einen neuen Opcode. Wenn Entwickler also Verträge für mehrere Ketten einsetzen möchten, sollten sie darauf achten, ob alle Ketten den neuesten Opcode unterstützen, andernfalls ist er nicht verfügbar.

EIP-6780

Ausführungsschicht ändert sich
EIP-6780: Selfstruction nur in derselben Transaktion

https://eips.ethereum.org/eips/eip-6780

EIP-6780: Deaktivieren

https://ethereum-magicess.org/t/eip-6780-eactivate-sselfScestruct-xcept-yit-it-occurs-in-the-same-transaction-in-which-a-contract-wa S-Created/13539

EIP-6780 modifizierte das Verhalten von selbstgrößen Opcode, um sich auf den Leerzeichen und die Beseitigung des OPCODES selbst auszurichten.Entwickler, die Selfstruct Opcode verwenden, brauchen besondere Aufmerksamkeit.

Hintergrund

Das aktuelle Verhalten von Self -Cestruct Opcode lautet: (1) Löschen Sie den Code und die Speicherung des Vertrags und (2) übertragen Sie die gesamte ETH an die angegebene Adresse.

Zu Beginn haben wir Opcode mit dem Rückerstattungsmechanismus selbst entsteht, um Entwickler dazu zu ermutigen, nicht verwendete Verträge und Lagerraum zu entfernen, um den Ethereum -Zustand in einer geeigneten Größe aufrechtzuerhalten.Aber nicht viele Menschen tun dies wirklich, aber es gibt Unfälle wie Parity Multisig, die aufgrund der Selbstdestruktur Hunderttausende von ETH einfrieren, sodass die Ethereum -Community die Opcode selbst ausschleudert.In der Vergangenheit gab es viele Vorschläge zum Ändern oder Entfernen von Opcode für das OPCODE, und EIP-6780 ist einer von ihnen und wurde schließlich in die Hardgabel der Dencun aufgenommen.

Hinweis: In der Shanghai Hard Fork Anfang 2023 hat EIP-6049 offiziell angekündigt, dass das Selbstentruhen beseitigt wird.

Querbaum ist eine staatliche Lagerstruktur, die derzeit von der Ethereum -Community aktiv erforscht und entwickelt wird und verwendet wird, um den aktuellen Merkle Patricia -Baum zu ersetzen.Der Verkle -Baum wird die Beweisgröße des Ethereum -Zustands kleiner, sodass er auch für ein staatsloses Client -Design von entscheidender Bedeutung ist.Mit dem staatenlosen Client wird die Hardware von Knoten reduziert, sodass mehr Menschen Knoten mit leichterer und billigerer Hardware ausführen können, wodurch die Dezentralisierung des Netzwerks verbessert wird.

Betriebsdetails

Nach dem EIP-6780 entfernen das Self-Cestruct-Opcode (1) das Verhalten und behalten nur die Funktion von (2) „Übertragen Sie die gesamte ETH an Ihrem Körper in die angegebene Adresse“.Der Vertragscode und der Speicher bleiben unverändert, es sei denn, der Vertrag wird in derselben Transaktion erstellt und dann wird das Selbstentruhen durchgeführt.

Also, wenn das Selbstdestrukturierung ausgelöst wird:

Wenn der Vertrag nicht in derselben Transaktion erstellt wird, bleibt der Vertragscode und der Speicher unverändert, aber die ETH darauf wird an die angegebene Adresse übertragen.
Wenn der Vertrag mit derselben Transaktion erstellt wird, ist das Verhalten das gleiche wie zuvor (vor EIP-6780): Der Vertragscode und der Speicher werden entfernt und die ETH an die angegebene Adresse übertragen.

Für den Perkle -Baum muss das Verhalten von (1) entfernt werden

Bei der Gestaltung von Querbaum unterscheidet sich sein Speicherstatus von dem von Merkle Patricia Tree.Der Speicherzustand von Merkle Patricia Tree kann als Struktur von zwei Schichten (Bäume in Bäumen) vorgestellt werden: Die erste Schicht ist ein Baum, der aus allen Adressen besteht, und die zweite Schicht ist ein Baum, der aus aller Lagerung und Synthese für jede Adresse besteht. Und einer VERKLE -Baum kann sich als geschichtete, völlig flache Struktur vorstellen.Daher können wir im Merkle Patricia -Baum die Speicherung einer Adresse leicht lokalisieren und entfernen, aber im Leerzeichen ist es fast unmöglich, die Speicherung einer Adresse zu lokalisieren, da alle Adressen und jeder Speicherwert der Adresse sind Im selben Baum gleichmäßig verteilt, ist es unmöglich zu wissen, welcher Wert zu welchem Adressspeicher gehört, sodass wir den Vertragscode und den gesamten Speicher im Leerzeichen nicht entfernen können.

△ Das aktuelle State Tree-Design (Merkle Patricia Tree) ist eine zweischichtige Struktur: Die Zustandswurzel entspricht einem Baum, der aus allen Adresssätzen besteht, und die Speicherwurzel entspricht allen Speicher- und synthetischen Bäumen unter einer Adresse.

Quelle: https://fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mpt.html

△ Der State Tree des VERKLE TREE ist ein völlig flacher Baum.

In der Abbildung ist der rote Knoten die Adresse und der grüne Knoten ist der Speicherwert der Adresse.

Quelle: https://youtu.be/s7fm6zz_g0i?t=572

△ Wenn wir den roten Knoten nur den Speicher (grüne Knoten) entfernen, wird der Vertrag die gleiche Adresse direkt erben, was zu einem potenziell hohen Risiko wird.

Quelle: https://youtu.be/s7fm6zz_g0i?t=572

Um den Verkle -Baum willkommen zu heißen, müssen wir Opcode selbst entspannen, Vertragscodes und Speicher zu entfernen.

Dinge zu beachten

Wenn der Entwickler Create2 + selbst entsprudelt, um wiederholt an derselben Adresse bereitzustellen, tritt dies nur gleichzeitig innerhalb derselben Transaktion nach Dencun auf.
Wenn der Entwickler Create2 + selbst zertifiziert, um die Auswirkungen von Vertrags -Upgrades zu erzielen (erzeugt2 + selbstzweigert wird nicht in derselben Transaktion abgeschlossen), kann er nach Dencun nicht fortgesetzt werden.

EIP-7044

Konsensschicht ändert sich
EIP-7044: Dauerhaft gültig unterschriebene freiwillige Ausgänge

https://eips.ethereum.org/eips/eip-7044

EIP-7044: Dauerhaft gültig unterschriebene freiwillige Ausgänge

https://ethereum-magices.org/t/eip-7044-perpetual-valid-ssigned-voluntary-exits/14348

Mit EIP-7044 kann die vom Überprüfer verwendete Signatur dauerhaft gültig sein, wodurch die Signatur aufgrund von Network-Hardgabel ungültig ist.Die Benutzererfahrung und der Schutz von Überprüfern, die nicht verwalteten Verpfändungsdiensten (z. B. Lido) anvertraut, werden verbessert: Es besteht keine Notwendigkeit, einen Dritten zu bitten, jedes Mal erneut zu unterschreiben, wenn Sie Hardgabel haben.

Hintergrund

Der Überprüfung von Ethereum POS muss zwei private Schlüssel haben: Eine wird für die tägliche Teilnahme an der Überprüfung verwendet (z Der Schlüssel der Adresse wird als Rückzugsschlüssel bezeichnet.Wenn der Validator POS beenden soll, unterschreibt er den Validator -Schlüssel, und der signierte Inhalt enthält die aktuelle Version (Hard Forked).

In den aktuellen nicht verpflichten Versprechensdiensten hält der Dienstanbieter den Validator-Schlüssel in der Hand, und der Benutzer hält den Rückzugsschlüssel. Versprechen Sie Vermögenswerte und Handhabungsgebühren, um den Zweck der Nicht-Kunden zu erreichen.Um zu vermeiden, dass Dienstanbieter die Erpressung von Benutzern drohen, indem sie „POS nicht beenden“, unterschreiben Dienstanbieter das Exit POS -Zertifikat zu Beginn und übergeben den Beweis dem Benutzer, damit Benutzer jederzeit beenden können, nicht um POS, nicht an POS, nicht dem Benutzer von Dienstleistern betroffen.

Betriebsdetails

Aber weil der Signaturinhalt, der POS beendet, die aktuelle Network (Hard Fork) -Version enthält, wie z. B. die aktuelle Shanghai oder die vorherige Version von Capella.Das Netzwerk wird die „Hard -Fork -Version im Exit -Zertifikat“ und die „aktuelle Version des Netzwerks“ vergleichen.Mit anderen Worten, da das Netzwerk weiterhin aktualisiert wird, ist nach Hardgabel und ein Upgrade auf eine neue Version der zu alte Exit -Beweis ungültig.

Zum Beispiel sind die Hardgabelversionen der Konsensschicht von alt nach neu, Altair, Bellatrix und (aktuelle) Capella.Das bei Altair unterzeichnete Exit -Zertifikat wird jetzt ungültig.Um diese Situation zu bewältigen, muss der Benutzer jedes Mal, wenn der Benutzer das Exit -Zertifikat im Voraus erhält, ein weiteres Exit -Zertifikat vom Dienstanbieter anfordern. Exit pos „droht die Erpressung von Benutzern.

HINWEIS: Da „Exit POS“ erst nach Capella geöffnet ist, darf niemand das Exit -Zertifikat in Altair oder Bellatrix im Voraus anmelden.

Daher repariert EIP-7044 die Hardgabelversion im Exit-Zertifikat in Capella, sodass alle in der aktuellen Version signierten Exit-Zertifikate dauerhaft gültig sind.Unabhängig davon, wie viele Updates in Zukunft vorgenommen werden, wird Capella im Exit -Zertifikat unterzeichnet und wird nicht mehr von der Hardgabel -Version betroffen.

Dinge zu beachten

Da die Hard -Fork -Version des Exit -Zertifikats bereits in Capella festgelegt ist, wird nach Deneb das Exit -Zertifikat der Deneb -Version im Voraus ungültig.

EIP-7045

Konsensschicht ändert sich
EIP-7045: Erhöhen Sie Max Beman Bonitation Inclusion Slot

https://eips.ethereum.org/eips/eip-7045

EIP-7045: Erhöhen Sie Max Beman Bonitation Inclusion Slot

https://ethereum-magicess.org/t/eip-7045-increase-max-attestation-inclusion-slot/14342

EIP-7045 erweitert die Gültigkeitsdauer der Abstimmung von Validatoren, sodass mehr Zeit verdient werden kann und die Netzwerkstabilität erhöht.Keine Auswirkungen auf allgemeine Benutzer oder Überprüfungen.

Hintergrund

Ursprünglich hat die Abstimmung des Verifizierers (Bescheinigung) eine Epoche (32 Slots), die verdient werden kann. Wartezeitprobleme oder erst nach der Stimmen von Slot 10020 wurde es erfolgreich an das P2P -Netzwerk gesendet, aber ihre Stimmen würden immer noch verdient.Aber wenn ihre Stimme nur bis zu 10033 Slot erscheint, gibt es keine Möglichkeit, ihre Stimme einzubeziehen, und es wird angesehen, dass es keine Abstimmung gibt.

Betriebsdetails

EIP-7045 erweitert die Gültigkeitsdauer der Stimmabschluss bis zum jüngsten „vor der nächsten Epoche der Abstimmung“.Nehmen wir beispielsweise an, dass der Verifizierer Alice zum Slot 3205 auf Epoch 100 und vor EIP-7045 zugewiesen wird, und ihre Abstimmung gilt bis zum Steckplatz 3237 (3237 = 3205 + 32). Slot 3237 (3237 = 3205 + 32);

Hinweis: Epoche 0 enthält Slots 0 bis 31;

EIP-7514

Konsensschicht ändert sich
EIP-7514: MAX-Epoch-Abwanderungsgrenze hinzufügen

https://eips.ethereum.org/eips/eip-7514

EIP-7514: MAX-Epoch-Abwanderungsgrenze hinzufügen

https://ethereum-magices.org/t/eip-7514-add-max-epoch-churn-limit/15709

Hintergrund

Nachdem Shanghai im Jahr 2023 Validatoren für den Ausgang von POS verbessert und geöffnet hatte, hat es mehr Benutzer angezogen, sich beizutreten und Validatoren zu werden, was dazu führte, dass die Validator -Wartesequenz (Eintragswarteschlange) immer voll ist und die Gesamtzahl der Validatoren ebenfalls schnell zunimmt.

△ Die Eintrittswarteschlange ist nach dem Abschluss von POS von Open gestiegen.Quelle: https://www.validatorqueue.com/

Wenn der Validator darauf wartet, dass die Sequenz vollständig beladen ist, werden 50% der ETH in etwa acht Monaten ab September 2023 (als der EIP vorgeschlagen) bis Mai 2024 zugesagt. 2019.Es gibt mehrere Nachteile von so vielen ETH -Säugeln, wie zu vielen Validatoren, was zu vielen Validatoren -Abstimmungs- und Aggregationssignaturen führt, was die Belastung des P2P -Netzwerks der Validatoren und die Erweiterung der Konsenskette erhöht.Darüber hinaus sind einige Leute der Meinung, dass die von Ethereum erforderliche Sicherheit nicht so viel ETH-Beteiligung erfordert.

Und warum gießt so viel ETH weiterhin ein?Denn selbst wenn die ETH 100% beteiligt ist, beträgt die annualisierte Rate immer noch etwa 1,6%. eine sehr attraktive Option.

Glücklicherweise trat der Verpfändungsboom in der zweiten Hälfte von 2023 allmählich zurück und verlangsamte das Wachstum der Anzahl der Validatoren.

△ Das Wachstum der Anzahl der Validatoren verlangsamte sich in der zweiten Hälfte von 2023, wobei im Februar 2024 etwa 25% der ETH zugesagt wurden.Quelle: https://www.validatorqueue.com/

Betriebsdetails

Die ursprüngliche Anzahl der Eintragswarteschlangen variiert mit der aktuellen Anzahl der Validatoren. ist ungefähr 950.000).

EIP-7514 wird die Eingangswarteschlange auf 8 reparieren, wobei die Anzahl der aktuellen Validatoren nicht mehr zunimmt, wodurch das Wachstum der Validatoren verlangsamt und der Gemeinschaft mehr Zeit für langfristige Lösungen wie die nächste Hardgabel verleiht kann EIP-7251 verdienen.

EIP-4844 und EIP-7516

EIP-4844: Shard-Blob-Transaktionen

https://www.eip4844.com/

Rollups große Ergänzung: Proto-Danksharding (i)

https://medium.com/taipeiThereum-meetup/rollup-and-boost-from-proto-danksharding-85d2fe0566b6

Rollups große Ergänzung: Proto-Danksharding (II)

https://medium.com/taipeiThereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

EIP-4844 fügte eine neue Transaktionstyp hinzu, eine Transaktion, die speziell zum Speichern von Blobendaten verwendet wurde.Durch das Platzieren der Daten in einen Blob wird Rollup die Transaktionsgebühren weiter verringern.

EIP-4844 ist keine Änderung, um die Kapazität zu erweitern und zu aktualisieren, sondern eher wie „Upgrade der Blockgasgrenze“ und „Kosten senken“, sodass der Block mehr (Rollup-) Transaktionen in ihn einsetzen kann.EIP -4844 ebnet aber auch den Weg für den wirklichen Expansionsplan – Danksharding.

Darüber hinaus sind Blob Fair und General Fair separate und unabhängige Gebührenmärkte, jeweils ihre eigene Grundgebühr und Prioritätsgebühr. Transaktionen).

Zusammenfassung und Fokus

Die Dencun -Hardgabel besteht aus der Deneb -Hardgabelung der Konsensschicht und der Hardgabel von Cancun der Ausführungsschicht.
Der Protagonist dieses Upgrades ist EIP-4844.
Änderungen an der Konsensschicht umfassen EIP-7044, EIP-7045 und EIP-7514.
Mit EIP-7044 ermöglicht Validatoren, die nicht verwaltete, festgelegte Dienste verwenden, um zukünftige Hardgabeln bei der Abgabe von POS zu vermeiden.
EIP-7045 und EIP-7514 können als Aktualisierungen angesehen werden, die die Stabilität des POS-Netzwerks erhöhen.
Änderungen an der Ausführungsschicht umfassen EIP-1153, EIP-4788, EIP-5656, EIP-6780 und EIP-7516.
Mit EIP-1153 können viele Vertragsdesignmodelle viel Gas sparen.
Mit EIP-4788 können die Ausführungsschicht die Konsensschichtinformationen auf eine Weise lesen, die nicht vertrauenswürdige Dritte erfordert und mehr Möglichkeiten für das Einbringen verwandter Dienste ermöglicht.
EIP-6780 eliminiert das Selbstentrudent weiter und beseitigt seine Fähigkeit, „Vertragscodes und -status zu entfernen“.
Entwickler müssen auf die Annahme achten, dass „vorübergehende Speicherung nach Transaktionen gelöscht wird“, wenn sie EIP-1153 verwenden, und achten Sie darauf, ob Ihr Vertrag betroffen ist, wenn dies betroffen ist.
Normale Benutzer müssen nicht besondere Aufmerksamkeit schenken.

Referenzdaten und empfohlene erweiterte Lesung

EIP-1153

https://eips.ethereum.org/eips/eip-1153
https://www.eip1153.com/
https://ethereum-magices.org/t/eip-1153-transient-storage-opcodes/553
https://hackmd.io/@-_wyfkbvsmip5m7mnb4b8a/sjfh66eca

EIP-4788

https://eips.ethereum.org/eips/eip-4788
https://ethereum-magices.org/t/eip-4788-beacon-root-in-evm/8281

EIP-5656

https://eips.ethereum.org/eips/eip-5656

EIP-6780

https://eips.ethereum.org/eips/eip-6780
https://ethereum-magicess.org/t/eip-6780-eactivate-sselfScestruct-xcept-yit-it-occurs-in-the-same-transaction-in-which-a-contract-wa S-Created/13539
https://www.youtube.com/watch?v=s7fm6zz_g0i

EIP-7044

https://eips.ethereum.org/eips/eip-7044
https://ethereum-magices.org/t/eip-7044-perpetual-valid-ssigned-voluntary-exits/14348

EIP-7514

https://eips.ethereum.org/eips/eip-7514
https://ethereum-magices.org/t/eip-7514-add-max-epoch-churn-limit/15709

EIP-4844 & amp;

https://www.eip4844.com/
https://medium.com/taipeiThereum-meetup/rollup-and-boost-from-proto-danksharding-85d2fe0566b6
https://medium.com/taipeiThereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8
https://eips.ethereum.org/eips/eip-7516
https://ethereum-magices.org/t/eip-7516-blobbasefee-opcode/15761