Analyse des bevorstehenden Hard Forks von Ethereum - Pectra Upgrade

Einführung

In unserem vorherigen Artikel haben wir ausführlich den Lebenszyklus der Ethereum-Validatoren überprüft und verschiedene Aspekte im Zusammenhang mit der bevorstehenden Electra-Hardfork diskutiert. Jetzt ist es an der Zeit, sich auf die bevorstehenden Änderungen in Electra und Prague-Upgrade zu konzentrieren und sie im Detail zu erklären.

Die Geschichte der Ethereum 2.0 ‘Proof-of-Stake’-Hardfork ist komplex. Sie begann mit der Hinzufügung einer Beacon-Schicht zur bestehenden Ausführungsschicht, während die Ausführungsschicht weiterhin Proof-of-Work beibehielt (Phase0 und Altair Hardforks) und gleichzeitig den Proof-of-Stake-Konsens auf der Beacon-Schicht aktiviert. Anschließend wurde im Bellatrix-Hardfork der PoS vollständig aktiviert (obwohl Abhebungen noch nicht aktiviert waren). Dann ermöglichte der Capella-Hardfork Abhebungen und vervollständigte den Lebenszyklus der Validatoren. Der jüngste Hardfork Deneb (Teil des Deneb/Cancun-Upgrades) hat geringfügige Änderungen an den Parametern der Beacon-Kette vorgenommen, wie z.B. das Zeitfenster für Beweise, die Behandlung von freiwilligem Ausstieg und die Beschränkungen für den Wechsel von Validatoren. Die Hauptänderungen in Deneb/Cancun erfolgen in der Ausführungsschicht, wo blob transactions, blob gas, KZG-Verpflichtungen für blob eingeführt und die SELFDESTRUCT-Operation verworfen wurden.

Die Prague/Electra (auch Pectra genannt) Hardfork hat wichtige Upgrades für die Ausführungsebene und die Konsensebene eingeführt. Als Rechnungsprüfer des Lido-Projekts konzentrieren wir uns hauptsächlich auf die Veränderungen im Konsens und beim Staking in diesem Hardfork. Dennoch können wir die Veränderungen in der Ausführungsebene von Prague nicht ignorieren, da sie wichtige Merkmale für das Ethereum-Netzwerk und die Validatoren umfassen. Lassen Sie uns in die Details dieser Veränderungen eintauchen.

Höheres Überblick über Pectra

Electra hat viele Funktionen in die Beacon-Schicht eingeführt. Die wichtigsten Updates umfassen:

• Erlauben Sie dem Validierer, dass sein effektives Guthaben zwischen 32 und 2048 ETH variieren kann (anstatt fest bei 32 ETH zu bleiben).
• Erlaubt Validatoren, den Austritt durch einen sekundären “Abhebungs”-Beleg zu beantragen (es ist kein aktiver Validatoren-Schlüssel mehr erforderlich).
• Ändern Sie die Art und Weise, wie die Beacon-Schicht Eth1-Einzahlungen verarbeitet (nicht mehr durch das Analysieren von Ereignissen im Einzahlungsvertrag).
• Fügen Sie ein neues universelles Framework hinzu, um Anfragen von regulären Eth1-Verträgen auf der Beacon-Schicht zu verarbeiten (ähnlich der Verwaltung von Electra-Pre-Deposits).

Gleichzeitig hat Prague folgende Änderungen in der Führungsebene eingeführt:

• Ein neuer vorkompilierter Vertrag, der die BLS12-381-Kurve unterstützt, um zkSNARK-Beweise zu verifizieren (neben der beliebten BN254-Kurve).
• Ein neuer Systemvertrag zum Speichern und Abrufen von bis zu 8192 historischen Blockhashes (sehr nützlich für nicht zustandsbehaftete Clients).
• Erhöhen Sie die Kosten für calldata-Gas, um die Blockgröße zu verringern und Projekte zu ermutigen, calldata-intensive Operationen (wie Rollup) in die in Dencun eingeführten Blobs zu verschieben.
• Unterstützung von mehr blobs pro Eth1-Block und Bereitstellung einer API zum Lesen dieser Anzahl.
• Ermöglicht es EOA (Externe Besitzkonto), ihren eigenen Kontocode zu haben, was die Operationen erheblich erweitert, die EOA durchführen kann, wie z.B. multicalls ausführen oder die Ausführung an eine andere Adresse delegieren.

Lassen Sie uns den entsprechenden Ethereum-Verbesserungsvorschlag (EIP) zur weiteren Diskussion heranziehen:

• EIP-7251: MAX_EFFECTIVE_BALANCE erhöhen
• EIP-7002: Ausführungsschicht auslösbare Beendigung
• EIP-6110: Bereitstellung von Deposits für Validator auf der Chain
• EIP-7549: Entfernen des Ausschussindex aus dem Nachweis
• EIP-7685: Allgemeine Ausführungsschicht-Anfrage
• EIP-2537: Vorcompilierung der BLS12-381 Kurvenoperationen
• EIP-2935: Speichern Sie den Verlaufsblock-Hash im Zustand
• EIP-7623: Erhöhung der Kosten für calldata
• EIP-7691: Erhöhung der Blob-Durchsatzleistung
• EIP-7840: Fügen Sie dem EL-Konfigurationsdatei die Blob-Planung hinzu
• EIP-7702: EOA-Kontocode einrichten

Einige dieser EIPs betreffen hauptsächlich die Konsens (Beacon) Schicht, während andere mit der Ausführungsschicht verbunden sind. Einige überspannen beide Schichten, da bestimmte Vorgänge (wie Ein- und Auszahlungen) synchronisierte Änderungen zwischen Konsens und Ausführung erfordern. Aufgrund dieser gegenseitigen Abhängigkeit ist es unrealistisch, Electra und Prague zu trennen. Daher werden wir jeden EIP nacheinander überprüfen und die betroffenen Ethereum-Komponenten in jedem Fall angeben.

EIP-7251: Hinzufügen von MAX_EFFECTIVE_BALANCE

Referenz: EIP-7251

Seit der ersten Phase0-Hardfork wurde in Vorbereitung auf den Proof-of-Stake von Ethereum das maximale effektive Guthaben der Validatoren bis Electra auf 32 ETH festgelegt. Die Anforderung an die Aktivierungsvalidierung ist mindestens spec.min_activation_balance (32 ETH). Einmal aktiviert, beginnen die Validatoren mit diesem maximalen effektiven Guthaben, können aber ihr effektives Guthaben auf spec.ejection_balance (16 ETH) reduzieren und entfernt werden, wenn dieser Schwellenwert erreicht ist. Diese “minimale” Logik bleibt in Electra gleich, aber jetzt ist spec.max_effective_balance auf 2048 ETH gestiegen. Infolgedessen können Validatoren zwischen 32 und 2048 ETH einzahlen, um sie zu aktivieren, was zu ihrem effektiven Guthaben beiträgt. Diese Verschiebung markiert eine Verschiebung von “32ETH - Proof of Stake” zu “Proof of Stake”: )

Dieser veränderliche verfügbare Betrag wird jetzt verwendet für:

• Erhöht die Wahrscheinlichkeit, ein Blockvorschlagender zu werden, proportional zum verfügbaren Guthaben.
• Erhöhen Sie die Wahrscheinlichkeit, Mitglied des Synchronisierungsausschusses zu werden, proportional zum verfügbaren Guthaben
• Als Grundlage für die Berechnung von relativen Reduktions- und Inaktivitätsstrafenbeträgen

Die ersten beiden Aktionen sind die rentabelsten Operationen für Validator. Daher werden nach Electra die Validator mit hohen Einsätzen häufiger an der Blockvorschlag und Synchronisierungsausschuss teilnehmen, wobei ihre Häufigkeit proportional zu ihrem effektiven Guthaben ist.

Ein weiterer Einfluss betrifft die Reduzierung. Alle Reduzierungsstrafen sind proportional zum gültigen Guthaben des Validierers:

• Die Reduzierung der sofortigen und verzögerten Strafen ist für Validatoren mit hohen Einsätzen größer.
• Die “Verzögerung” der Strafe für die Reduzierung von Validierern mit hohen Einsätzen ist auch größer, da der “reduzierte” Teil des Gesamteinsatzes größer wird.
• Melder von Validatoren mit hohem effektivem Guthaben erhalten einen höheren Anteil an reduzierten Einsätzen.

Electra hat auch Änderungen an der Abschneidungsrate vorgenommen, definiert einen Teil des abgeschnittenen Validator-Saldos und gibt ihn an den Berichterstatter weiter.

Als nächstes kommt die Auswirkung der Ungültigkeit. Wenn ein Validator während seiner Aktivität (Beweis oder Vorschlag) offline ist, sammelt sich ein Ungültigkeitswert an, was zu einer Bestrafung der Ungültigkeit in jedem Zyklus führt. Diese Strafen stehen auch im Verhältnis zum gültigen Guthaben des Validators.

Aufgrund des Anstiegs des verfügbaren Guthabens hat sich auch die “Wechselbeschränkung” der Validatoren geändert. In der “Vor-Electra”-Ära von Ethereum hatten Validatoren in der Regel das gleiche verfügbare Guthaben. Die Definition der Wechselbeschränkung für den Rückzug besagt, dass “innerhalb eines Zyklus maximal 1/65536 (spec.churn_limit_quotient) des Gesamteinsatzes zurückgezogen werden können”. Dies führte zu einer “festen” Anzahl von Validatoren mit dem gleichen Einsatz, die sich zurückziehen. Allerdings kann es nach “Electra” vorkommen, dass nur wenige “Wale” aussteigen, da sie einen wesentlichen Teil des Gesamteinsatzes repräsentieren.

Eine weitere Überlegung ist die Rotation vieler Validatoren-Schlüssel auf einer einzelnen Validator-Instanz. Große Validatoren sind derzeit gezwungen, Tausende von Validatoren-Schlüsseln auf einer Instanz auszuführen, um eine große Stake aufzunehmen, die in 32-ETH-Teile aufgeteilt ist. Mit Electra ist dieses Verhalten nicht mehr zwingend erforderlich. Aus finanzieller Sicht hat diese Änderung nur geringe Auswirkungen, da Belohnungen und Wahrscheinlichkeiten linear mit dem Einsatzbetrag skaliert werden. Daher entspricht die Anzahl von 100 Validatoren mit jeweils 32 ETH einem Validator mit 3200 ETH. Darüber hinaus können mehrere aktive Validatoren-Schlüssel über dasselbe Eth1-Abhebungszertifikat verfügen, was die Auszahlung aller Belohnungen an eine einzelne ETH-Adresse ermöglicht und somit die mit der Zusammenführung von Belohnungen verbundenen Gas-Kosten vermeidet. Die Verwaltung einer großen Anzahl von Schlüsseln führt jedoch zu zusätzlichen Verwaltungskosten.

Die Fähigkeit des Aggregatvalidierers, das Guthaben zu erhöhen, wurde um einen neuen Typ von Ausführungsanforderung erweitert. Bisher hatten wir Einzahlung und Auszahlung. Jetzt wird es einen weiteren Typ geben: Aggregatanforderung. Es wird zwei Validatoren zu einem zusammenführen. Die Operationsanfrage wird den öffentlichen Schlüssel des Quellvalidierers und des Zielvalidierers enthalten und ähnlich wie Einzahlung und Auszahlung verarbeitet werden. Das Aggregat wird auch ausstehende Anfragen und Guthabenänderungsbeschränkungen haben, ähnlich wie Einzahlung und Auszahlung.

Zusammenfassend:

• Für kleine unabhängige Validatoren hat Electra die Möglichkeit eingeführt, ihr effektives Guthaben (und ihre Belohnungen) automatisch zu erhöhen. Bisher konnte jeder Überschuss über 32 ETH nur abgehoben werden, aber nach Electra wird dieser Überschuss schließlich zu seinem effektiven Saldo beitragen. Der effektive Saldo kann jedoch nur in Vielfachen von spec.effective_balance_increment (1 ETH) erhöht werden, was bedeutet, dass die Erhöhung erst nach Erreichen des nächsten “1 ETH-Limits” erfolgt.
• Für große unabhängige Validatoren ermöglicht Electra eine erhebliche Vereinfachung der Verwaltung, indem mehrere aktive Validatoren-Schlüssel zu einem einzigen integriert werden. Obwohl dies die Spielregeln nicht ändert, ist es zweifellos viel einfacher, eine 1x2048-Delegation zu führen als eine 64x32-Delegation zu verwalten.
• Für die Anbieter von Liquiditätsanlagen sammeln sie kleine Anlagen von Benutzern und verteilen sie unter den Validatoren. Electra hat mehr Flexibilität in das Anlagezuweisungsschema integriert, erfordert jedoch gleichzeitig eine erhebliche Überarbeitung der Buchhaltung für Validatoren, die auf einem festen 32-ETH-Guthaben basieren.

Ein weiteres wichtiges Thema sind die Historiedaten und Gewinnschätzungen der Validatoren, die insbesondere für neue Teilnehmer relevant sind, die versuchen, Risiken und Renditen abzuschätzen. Vor Electra (zum Zeitpunkt der Abfassung dieses Artikels) schuf die Begrenzung auf 32 ETH (unabhängig davon, ob es sich um ein Minimum oder Maximum handelt) eine Gleichmäßigkeit in den Historiedaten. Das Guthaben, die Belohnungen, individuelle Kürzungen von Strafen, die Häufigkeit der Blockvorschläge und andere Kennzahlen sind für alle Validatoren gleich. Diese Gleichmäßigkeit ermöglicht es Ethereum, seine Konsensmechanismen zu testen und wertvolle Netzwerkverhaltensdaten zu sammeln, ohne statistische Ausreißer zu haben.

Nach Electra wird es bedeutende Veränderungen in der Verteilung der Einsätze geben. Große Validator-Beteiligung bei Blockvorschlägen und im Synchronisationsausschuss wird häufiger vorkommen, größere Bestrafungen bei Slash-Ereignissen und größere Auswirkungen auf Verzögerungen, Aktivierungswarteschlangen und Ausstiegswarteschlangen. Obwohl dies in der Datenaggregation Herausforderungen darstellen kann, stellt der Konsens von Ethereum sicher, dass nichtlineare Berechnungen minimal sind. Der einzige nichtlineare Bestandteil verwendet sqrt(total_effective_balance) zur Berechnung der Grundbelohnung, die für alle Validator-Belohnungen gilt. Dies bedeutet, dass die Belohnungen und Slashings der Validatoren immer noch auf einer „pro 1 ETH“-Basis geschätzt werden können (oder genauer gesagt, je nach spec.effective_balance_increment, was sich in Zukunft ändern könnte).

Für weitere Einzelheiten siehe unseren früheren Artikel zum Verhalten der Validatoren.

EIP-7002: Auslösbare Ausführungsebene-Beendigung

Referenz: EIP-7002

Jeder Validierer in Ethereum hat zwei Schlüsselpaare: einen aktiven Schlüssel und einen Abhebungsschlüssel. Der aktive öffentliche BLS-Schlüssel dient als Hauptidentität des Validierers in der Beacon-Kette. Dieses Schlüsselpaar wird zum Signieren von Blöcken, Beweisen, Abrechnungen, Synchronisieren von Ausschussaggregationen und (vor dieser EIP) zum freiwilligen Ausscheiden verwendet (um die Konsensaustritte der Validierer nach Verzögerungen zu starten). Das zweite Schlüsselpaar („Abhebungsbeleg“) kann ein weiteres BLS-Schlüsselpaar oder ein herkömmliches Eth1-Konto (privater Schlüssel und Adresse) sein. Jetzt erfordert die Auszahlung an eine ETH-Adresse eine Abhebungsnachricht, die mit dem aktiven BLS-Privatschlüssel signiert werden muss. Diese EIP hat dies geändert.

Tatsächlich können die Besitzer dieser beiden Schlüsselpaare (Aktiv und Auszahlung) unterschiedlich sein. Der aktive Schlüssel des Validierers ist für Validierungsaufgaben zuständig: den Betrieb des Servers aufrechterhalten usw., während das Auszahlungszertifikat normalerweise vom Stake-Owner kontrolliert wird, der Belohnungen erhält und für die Gelder verantwortlich ist. Derzeit kann nur der Stake-Owner, der das Auszahlungszertifikat kontrolliert, den Ausstieg des Validierers nicht initiieren, sondern nur Belohnungen abheben. In dieser Situation kann der Besitzer des aktiven Schlüssels des Validierers effektiv das Gleichgewicht des Validierers als „Geisel“ halten. Der Validierer kann eine „vorab signierte“ Ausstiegsnachricht erstellen und sie dem Stake-Owner übergeben, aber diese improvisierte Methode ist nicht ideal. Darüber hinaus erfordern sowohl das Abheben als auch der Ausstieg derzeit die Interaktion mit den Beacon-Chain-Validierern über spezielle APIs.

Die beste Lösung besteht darin, dass der Staker die Möglichkeit hat, sowohl den Abzug als auch die Auszahlung gleichzeitig über einen herkömmlichen Smart Contract zu veranlassen. Dies beinhaltet die Standard-Eth1-Signaturprüfung und vereinfacht den Vorgang erheblich.

Dieses EIP ermöglicht es den Stakeholdern, Abhebungen und Auszahlungen auszulösen, indem sie standardisierte Transaktionen von ihrer ETH-Adresse an einen speziellen Smart Contract senden (ähnlich dem Einzahlungsprozess mit dem bestehenden “Deposit”-Vertrag), wenn genügend Einsätze entfernt werden.

• Der Staker sendet eine Abhebungsanforderung (“in” Anforderung) an den “Withdraw”-Vertrag des Systems.
• Vertragsgebühren werden in bestimmten Fällen erhoben (in ETH berechnet), um potenzielle bösartige Angriffe zu mildern, ähnlich wie bei EIP-1559, wobei die Gebühren bei stark ausgelasteter Anforderungswarteschlange steigen.
• Der Vertrag speichert die Auszahlungs- / Abmeldeanforderung in seinem Speicher.
• Wenn ein Block auf der Beacon-Ebene vorgeschlagen wird, werden die eingehenden Abhebungs-/Auszahlungsanforderungen aus der Warteschlange aus dem Speicher abgerufen.
• Der Beacon-Schicht verarbeitet die “in” -Anforderung, interagiert mit dem Guthaben des aktiven Validators, ordnet den Validator-Austritt an und bildet eine “out” -Abhebungsanforderung.
• Die Auszahlungsanforderung ‘out’ wird auf der Ausführungsebene verarbeitet und die Pfandgeber erhalten ihre ETH.

Obwohl die Einzahlung eine Aktion im Eth1-Block auslöst und dann über die “Ausstehende” Einzahlungswarteschlange in die Beacon-Ebene “verschoben” wird, folgt die Auszahlung einem anderen Ansatz. Sie wird in der Beacon-Ebene (über CLI) ausgelöst und dann in den Eth1-Block “verschoben”. Jetzt werden beide Ansätze über dasselbe allgemeine Framework (wie unten beschrieben) ausgeführt: Erstellen einer Anforderung auf der Eth1-Ebene, Bearbeiten der “Ausstehenden” Einzahlungs-/Auszahlungs-/Zusammenführungs-Warteschlange und Verarbeiten auf der Beacon-Ebene. Bei “Ausgabe”-Aktionen wie Auszahlungen wird auch die Ausgabe-Warteschlange verarbeitet und das Ergebnis wird im Eth1-Block “abgerechnet”.

Durch dieses EIP können Staker ihre Validator-Positionen über reguläre ETH-Transaktionen abrufen und verlassen, ohne direkt mit der Validator-CLI interagieren oder auf Validator-Infrastruktur zugreifen zu müssen. Dies vereinfacht den Staking-Prozess erheblich, insbesondere für große Staker. Die Validator-Infrastruktur kann nun fast vollständig isoliert werden, da nur die Schlüssel der aktiven Validator-Positionen gepflegt werden müssen und alle Staking-Vorgänge an anderer Stelle verarbeitet werden können. Es beseitigt die Notwendigkeit für unabhängige Staker, auf Aktivitäten von aktiven Validatoren zu warten, und vereinfacht erheblich die Off-Chain-Teile von Diensten wie dem Community Staking Module von Lido.

Daher hat dieses EIP die Staking-Operationen “abgeschlossen” und vollständig auf die Eth1-Schicht verschoben, was das Sicherheitsrisiko der Infrastruktur erheblich verringert und die Dezentralisierung der unabhängigen Staking-Initiative stärkt.

EIP-6110: Einlagen für Verifizierer auf der Chain

Referenz: EIP-6110

Derzeit erfolgt die Einzahlung über Ereignisse im “Einzahlungs”-Vertragssystem (wie in früheren Artikeln ausführlich diskutiert). Der Vertrag akzeptiert ETH und Validatorenzertifikate und löst das Ereignis “Deposit()” aus, das anschließend analysiert und in eine Einzahlungsanforderung auf der Beacon-Ebene umgewandelt wird. Das System hat viele Nachteile: Es erfordert eine Abstimmung über eth1data auf der Beacon-Chain-Ebene, was zu erheblicher Verzögerung führt. Darüber hinaus muss die Beacon-Ebene die Execution-Ebene abfragen, was die Komplexität weiter erhöht. Diese Probleme wurden in EIP ausführlich diskutiert. Eine einfachere Methode, die viele dieser Probleme nicht erfordert, besteht darin, Einzahlungsanforderungen direkt im Eth1-Block an einer bestimmten Stelle zu platzieren. Dieser Mechanismus ähnelt dem in früheren EIPs beschriebenen Abhebungsprozess.

Die Änderungen, die in diesem EIP vorgeschlagen wurden, sind vielversprechend. Die Verarbeitung von eth1data kann jetzt vollständig entfernt werden, ohne dass eine Abstimmung oder lange Verzögerung zwischen den Ereignissen auf der Eth1-Seite und den Einzahlungspaketen auf der Beacon-Ebene erforderlich ist (derzeit etwa 12 Stunden). Es entfernt auch die Logik des Einzahlungsvertrags-Snapshots. Dieses EIP vereinfacht die Einzahlungsverarbeitung und bringt sie mit dem oben genannten Auszahlungsmechanismus in Einklang.

Für Staker und Validator reduzieren diese Änderungen signifikant die Verzögerung zwischen der Einzahlung und der Aktivierung des Validators. Wenn ein Validator gekürzt wird, erfolgt auch die erforderliche Nachzahlung schneller.

Es gibt nicht viel mehr zu sagen über dieses EIP, außer dass es veraltete Logik entfernt, den Prozess vereinfacht und bessere Ergebnisse für alle Beteiligten schafft.

EIP-7685: Allgemeine Ausführungsschichtanfrage

Referenz: EIP-7685

Dieses EIP sollte eigentlich vor den ersten drei EIPs eingereicht werden, die mit Einzahlung/Auszahlung/Fusion zusammenhängen, da es die Grundlage für diese EIPs bildet. Die Einführung an dieser Stelle erfolgt jedoch, um die zunehmende Notwendigkeit der speziellen Datenkonsistenzbewegung zwischen Eth1 (Ausführung) und Beacon (Konsens) Chain-Blöcken (Schichten) zu betonen. Dieses EIP betrifft zwei Schichten und ermöglicht eine effizientere Verarbeitung von Anfragen, die durch reguläre ETH-Transaktionen ausgelöst werden. Derzeit beobachten wir:

• Die Einzahlungsvorgänge in Eth1-Blöcken werden in den Beacon-Blöcken “verschoben” und dort verarbeitet.
• Die Auszahlungsanforderungen im Beacon-Block (mit CLI) werden zur Verarbeitung in den Eth1-Block “verschoben”. Beacon-Anfrage.

Diese drei Aktionen zeigen die Notwendigkeit einer konsistenten Behandlung verschiedener Arten von Anfragen bei der Umwandlung zwischen der Ausführungsebene und der Beacon-Ebene. Darüber hinaus benötigen wir die Fähigkeit, diese Aktionen nur mit der Eth1-Ebene auszulösen, da dies ermöglicht, die Infrastruktur der Validatoren von der Infrastruktur des Staking-Managements zu isolieren und so die Sicherheit zu erhöhen. Daher ist eine allgemeine Lösung zur Verwaltung solcher Anfragen sowohl praktisch als auch notwendig.

Dieses EIP legt einen Rahmen für mindestens drei Hauptfälle fest: Einzahlung, Auszahlung und Zusammenführung. Das ist der Grund, warum in frühen EIPs Felder wie WITHDRAWAL_REQUEST_TYPE und DEPOSIT_REQUEST_TYPE eingeführt wurden. Jetzt wird mit CONSOLIDATION_REQUEST_TYPE ein weiteres Feld hinzugefügt. Darüber hinaus kann dieses EIP auch einen allgemeinen Mechanismus zur Behandlung solcher Anfragen einschließen, der Beschränkungen für die Verarbeitung solcher Anfragen umfasst (siehe Konstanten: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Obwohl die detaillierten Implementierungsdetails dieses Frameworks noch nicht verfügbar sind, wird es sicherlich wichtige Anforderungstypen, Integritätsmechanismen (wie Hashes und Merkelisierte Anforderungen) sowie Warteschlangenverarbeitung und Geschwindigkeitsbeschränkungen umfassen.

Dieses EIP hat architektonische Bedeutung, da es Eth1 ermöglicht, wichtige Operationen in der Beacon-Schicht durch einheitliche Rahmenbedingungen auszulösen. Für Endbenutzer und Projekte bedeutet dies, dass alle Anfragen, die auf der Eth1-Ebene ausgelöst werden, auf der Beacon-Schicht effizienter übertragen und verarbeitet werden.

EIP-2537: Precompilation für BLS12-381 Kurvenoperationen

Referenz: EIP-2537

Wenn Sie keine tiefergehende Kenntnis wünschen, können Sie die vorkompilierte BLS12-381 als eine Art komplexen verschlüsselten “Hash”-Operation betrachten, die jetzt in Smart Contracts verwendet werden kann. Für diejenigen, die interessiert sind, lassen Sie uns weiter darüber diskutieren.

Mathematische Operationen auf elliptischen Kurven wie BLS12-381 (und entsprechend BN-254) werden derzeit hauptsächlich für zwei Zwecke verwendet:

• BLS-Signatur, bei der eine spezielle Operation namens „Pairing“ zur Überprüfung dieser Signaturen verwendet wird. BLS-Signaturen werden von Verifizierern weit verbreitet eingesetzt, da sie mehrere Signaturen zu einer aggregieren. Verifizierer verlassen sich auf BLS-Signaturen, die auf der BLS12-381-Kurve basieren (obwohl sie auch jede Kurvenimplementierung unterstützen können, die Pairing unterstützt, wie z. B. BN254).
• Überprüfung des zkSNARK-Beweises, wobei Pairing zur Überprüfung des Beweises verwendet wird. Darüber hinaus wird zur Überprüfung des Block-Commitments von großen Blöcken, die durch den Dencun-Hardfork eingeführt wurden, auch Pairing für die KZG-Commitments verwendet.

Wenn Sie in einem Smart Contract eine BLS-Signatur oder einen zkSNARK-Beweis überprüfen möchten, müssen Sie diese “Pairings” berechnen, was rechnerisch sehr aufwendig ist. Ethereum verfügt bereits über einen vorkompilierten Smart Contract für Vorgänge mit der BN254-Kurve (EIP-196 und EIP-197). Die BLS12-381-Kurve (die heute als sicherer angesehen wird und breiteren Einsatz findet) ist jedoch noch nicht als vorkompiliert implementiert. Ohne einen solchen vorkompilierten Vertrag erfordert die Implementierung von Pairings und anderen Kurvenoperationen in einem Smart Contract erhebliche Berechnungen und verbraucht eine große Menge an Gas (~10^5 bis 10^6 Gas), wie hier gezeigt.

Dieses EIP öffnet vielen potenziellen Anwendungen Tür und Tor, insbesondere bei der kostengünstigen BLS-Signaturüberprüfung auf der BLS12-381-Kurve. Dadurch wird die Umsetzung von Schwellenwertverfahren für verschiedene Zwecke ermöglicht. Wie bereits erwähnt, verwenden Ethereum-Validatoren Signaturen, die auf BLS12-381 basieren. Mit diesem EIP können nun auch Standard-Smart Contracts effizient aggregierte Validatoren-Signaturen überprüfen. Dies erleichtert den Nachweis der Zustimmung und die Überbrückung von Vermögenswerten zwischen verschiedenen Netzwerken, da BLS-Signaturen weit verbreitet in Blockchain verwendet werden. Schwellenwert-BLS-Signaturen selbst ermöglichen den Aufbau vieler effizienter Schwellenwertverfahren für Abstimmungen, dezentrale Zufallsgenerierung, Multisig usw.

Die kostengünstigere Überprüfung von zkSNARK-Nachweisen könnte die Tür für eine Vielzahl von Anwendungen öffnen. Der hohe Kosten für die Überprüfung von zkSNARK-Nachweisen behindert derzeit viele Lösungen, was bestimmte Projekte nahezu unmachbar macht. Dieser EIP hat das Potenzial, dies zu ändern.

EIP-2935: Speichern von historischen Blockhashes im Zustand

Referenz: EIP-2935

Dieser EIP schlägt vor, 8192 (ca. 27,3 Stunden) Historische Block-Hashes im Blockchain-Status zu speichern, um rollup und Smart Contracts eine erweiterte Historie bereitzustellen. Es schlägt vor, das aktuelle Verhalten des BLOCKHASH-Opcode beizubehalten, indem die Beschränkung auf 256 Blöcke beibehalten wird und gleichzeitig ein neuer Systemvertrag eingeführt wird, der speziell für die Speicherung und Abfrage von Historische Hashes entworfen wurde. Dieser Vertrag führt die set()-Operation aus, wenn Blöcke auf der Ausführungsebene verarbeitet werden. Seine get()-Methode ist öffentlich zugänglich und ruft den erforderlichen Block-Hash aus einem Ringpuffer ab.

Derzeit ist es möglich, in EVM auf den Hashwert historischer Blöcke zuzugreifen, jedoch ist der Zugriff auf die letzten 256 Blöcke (ca. 50 Minuten) beschränkt. In einigen Fällen ist es jedoch entscheidend, auf ältere Blockdaten zuzugreifen, insbesondere für Cross-Chain-Anwendungen (die den Nachweis von Daten früherer Blöcke erfordern) und für zustandslose Clients, die regelmäßig auf frühere Blockhashes zugreifen müssen.

Diese EIP erweitert den Zeitbereich, der für Rollup- und Cross-Chain-Anwendungen verfügbar ist, sodass sie direkt auf historische Daten in der EVM zugreifen können, ohne diese extern sammeln zu müssen. Dadurch werden diese Lösungen robuster und nachhaltiger.

EIP-7623: Erhöhung der Kosten für calldata

Referenz: EIP-7623

calldata reguliert die verfügbare Größe der Transaktionsnutzlast und kann in einigen Fällen groß sein (z. B. wenn große Arrays oder Binärpuffer als Parameter übergeben werden). Die wesentliche Verwendung von calldata ist hauptsächlich auf Rollups zurückzuführen, die die Transaktionsnutzlast durch die Übermittlung von calldata mit dem aktuellen Rollup-Status enthalten.

Die Einführung von großen, überprüfbaren binären Daten in die Blockchain ist entscheidend für Rollup. Das Dencun (Deneb-Cancun) Upgrade führt eine wichtige Innovation für solche Anwendungsfälle ein - Blob-Transaktionen (EIP-4844). Blob-Transaktionen haben ihre eigene spezielle ‘Blob’-Gasgebühr. Obwohl der Hauptteil vorübergehend gespeichert wird, werden der Verschlüsselungsnachweis (KZG-Commitment) und sein Hash in die Konsensschicht integriert. Daher bietet Blob eine bessere Lösung für Rollup im Vergleich zur Verwendung von Calldata zur Speicherung von Daten.

Die Förderung von Rollup, seine Daten in ein Blob zu überführen, kann durch die Methode des ‘Karotte und Stock’ realisiert werden. Die gesenkten Blob-Gebühren dienen als ‘Karotte’, während dieser EIP die Kosten für calldata als ‘Stock’ erhöht, um übermäßige Datenspeicherung in Transaktionen zu unterdrücken. Dieser EIP ergänzt den nächsten EIP-7691 (Erhöhung der Blob-Durchsatzrate), der die maximale Anzahl von Blobs pro Block erhöht.

EIP-7691: Erhöhung der Durchsatzrate von Blob

Referenz: EIP-7691

In the previous Dencun hard fork, blob was introduced, and the maximum and target number of blobs per “block” was a conservative estimate. This is due to the complexity of predicting how the p2p network will handle the propagation of large binary objects between validating nodes. The previous configuration has proven to be good, making it an appropriate time to test the new values. Previously, the target/maximum blob count per block was set to 3/6. These limits are now increased to 6/9 respectively.

Die Anpassung hat die Rollup weiterhin dazu motiviert, ihre Daten von calldata auf Blobs zu verschieben, wobei die Arbeit an der Suche nach den besten Blob-Parametern noch im Gange ist.

EIP-7840：Fügt die Terminierung von Blob zur EL-Konfigurationsdatei hinzu

Referenz: EIP-7840

Dieser EIP schlägt vor, das Ziel und die maximale Anzahl von Blöcken pro Blob (wie zuvor diskutiert) sowie den Wert von baseFeeUpdateFraction zum Ethereum Execution Layer (EL) Konfigurationsdatei hinzuzufügen. Es ermöglicht auch den Zugriff auf diese Werte über die Node API. Diese Funktion ist besonders nützlich für Aufgaben wie die Schätzung der Blob-Gasgebühren.

EIP-7702: Setzen Sie den Code des EOA-Kontos

Referenz: EIP-7702

Dies ist ein sehr wichtiges EIP, das bedeutende Veränderungen für die Ethereum-Benutzer bringen wird. Wie wir wissen, kann ein EOA (externes Besitzkonto) keinen Code haben, aber eine Transaktionssignatur bereitstellen (tx.origin). Im Gegensatz dazu hat ein Smart Contract Bytecode, kann aber keine direkte Signatur “es” machen. Jede Benutzerinteraktion, die zusätzliche, automatische und überprüfbare Logik erfordert, kann derzeit nur durch Aufruf eines externen Vertrags ausgeführt werden. In diesem Fall wird jedoch der externe Vertrag zum msg.sender für den nachfolgenden Vertrag, was bedeutet, dass der Aufruf “vom Vertrag und nicht vom Benutzer” stammt.

Dieses EIP führt einen neuen SET_CODE_TX_TYPE=0x04 Transaktionstyp ein (wir hatten zuvor alte 0x1 Transaktionen, neue 0x02 Transaktionen aus dem Berlin- und EIP-1559-Upgrade, sowie 0x03 blob Transaktionen, die in Dencun eingeführt wurden). Dieser neue Transaktionstyp ermöglicht die Codefestlegung für EOA-Konten. Tatsächlich ermöglicht es EOA, „im Kontext seines eigenen EOA-Kontos“ externen Code auszuführen. Aus externer Sicht scheint es, als ob das EOA während des Transaktionsprozesses den Code von externen Verträgen ausleiht und ihn ausführt. Technisch gesehen wird dies durch das Hinzufügen eines speziellen Berechtigungsdatentupels zum „Code“-Speicher der EOA-Adresse erreicht (vor diesem EIP war dieser „Code“-Speicher für EOA immer leer).

Derzeit enthält dieser EIP-Vorschlag einen neuen Transaktionstyp 0x04, der ein Array enthält:

authorization_list = [[chain_id, Adresse, Nonce, y_Parität, r, s], …]

Jeder Eintrag erlaubt es einem Konto, den Code von der angegebenen Adresse zu verwenden (aus dem letzten gültigen Berechtigungseintrag). Bei der Verarbeitung solcher Transaktionen wird der Code der angegebenen EOA auf einen speziellen Wert von 0xef0100 || Adresse (23 Byte) gesetzt, wobei die Adresse auf den Vertrag zeigt, der den gewünschten Code enthält. || steht für die Verknüpfung und 0xef0100 steht für einen speziellen magischen Wert, den herkömmliche Smart Contracts nicht enthalten können (gemäß EIP-3541). Dieser magische Wert stellt sicher, dass diese EOA nicht als herkömmlicher Vertrag betrachtet werden kann und keine Aufrufe wie bei einem herkömmlichen Vertrag durchgeführt werden können.

Wenn dieses EOA eine Transaktion initiiert, wird die angegebene Adresse verwendet, um den entsprechenden Code im Kontext dieses EOA aufzurufen. Obwohl die vollständigen Implementierungsdetails dieses EIPs noch nicht klar sind, ist sicher, dass es bedeutende Veränderungen mit sich bringen wird.

Eine Hauptauswirkung besteht darin, dass mehrere Aufrufe (multicall) direkt von EOA aus durchgeführt werden können. Multicall ist ein fortlaufender Trend in DeFi, bei dem viele Protokolle diese Funktion als leistungsstarkes Werkzeug anbieten (z. B. Uniswap V4, Balancer V3 oder Euler V2). Mit diesem EIP können jetzt mehrere Aufrufe direkt von EOA aus gestartet werden.

Zum Beispiel löst dieses neue Feature ein häufiges Problem in DeFi: Die Ineffizienz von approve() + anything(), das zwei separate Transaktionen erfordert. Dieses EIP ermöglicht eine allgemeine „Vorabgenehmigung“ Logik, so dass etwas wie approve(X) + deposit(X) in einer einzigen Transaktion durchgeführt werden kann.

Ein weiterer Vorteil der Möglichkeit, eine EOA im Namen einer anderen Partei zu beauftragen, ist das Konzept des Sponsorings. Sponsoring ist ein oft diskutiertes und sehr gewünschtes Merkmal, um neuen Benutzern den Einstieg in Ethereum zu erleichtern.

Die mit EOA verbundene programmierbare Logik eröffnet viele Möglichkeiten, wie die Implementierung von Sicherheitsbeschränkungen, das Festlegen von Ausgabelimits, die Durchsetzung von KYC-Anforderungen usw.

Natürlich wirft diese Verschiebung auch eine Reihe von Designfragen auf. Ein Problem ist die Verwendung von chain_id, die bestimmt, ob dieselbe Signatur über mehrere Netzwerke hinweg gültig sein kann, je nachdem, ob sie in der Signatur enthalten ist oder nicht. Eine weitere Komplikation ist die Wahl zwischen der Verwendung der Adresse des Objektcodes und der Einbettung des eigentlichen Bytecodes. Beide Methoden haben ihre eigenen Besonderheiten und Einschränkungen. Darüber hinaus spielt die Verwendung von Nonce eine Schlüsselrolle bei der Definition, ob eine Berechtigung “multi-purpose” oder “single-purpose” ist. Diese Elemente wirken sich auf Funktions- und Sicherheitsaspekte aus, einschließlich Aspekten wie Masseninvalidierungssignaturen und Benutzerfreundlichkeit. Vitalik hat diese Fragen in einer Diskussion (hier) aufgeworfen, die es wert ist, weiter untersucht zu werden.

Es ist erwähnenswert, dass diese Änderung einen Sicherheitsmechanismus von Ethereum, tx.origin, beeinflussen wird. Weitere Details zur Umsetzung dieses EIP sind erforderlich, aber es scheint, dass das Verhalten von require(tx.origin == msg.sender) sich ändern wird. Diese Überprüfung war immer der zuverlässigste Weg, um sicherzustellen, dass msg.sender ein EOA und kein Vertrag ist. Andere Methoden wie die Überprüfung von EXTCODESIZE (um festzustellen, ob es sich um einen Vertrag handelt) scheitern oft und können umgangen werden (z. B. durch Aufrufen des Konstruktors oder Bereitstellen von Code an einer vordefinierten Adresse nach der Transaktion). Diese Überprüfungen dienen dazu, Reentrance- und Flash-Loan-Angriffe zu verhindern, sind jedoch bei weitem nicht ideal, da sie auch die Integration mit externen Protokollen behindern. Nach diesem EIP scheint selbst die zuverlässige require(tx.origin == msg.sender) Überprüfung veraltet zu werden. Protokolle müssen sich anpassen, indem sie diese Überprüfungen entfernen, da der Unterschied zwischen „EOA“ und „Vertrag“ nicht mehr relevant ist - jetzt kann jede Adresse relevanten Code haben.

Die Trennung zwischen traditionellen EOA und Smart Contracts wird weiterhin verwischt. Dieses EIP bringt Ethereum näher an Designs wie TON, bei denen jedes Konto im Wesentlichen ausführbarer Code ist. Mit zunehmend komplexer Interaktion mit Protokollen ist die Verwendung programmierbarer Logik zur Verbesserung der Benutzererfahrung ein natürlicher Fortschritt.

Schlussfolgerung

Das Upgrade von Prague/Electra (Pectra) ist für März 2025 geplant. Die bedeutendsten geplanten Änderungen umfassen:

• Veränderbare validierende Parteien können bis zu 2048 ETH staken, was die Verteilung des Stakings, den Zeitplan der validierenden Parteien und die Verwaltung der großen Staking-Anbieter durch die Integration von kleineren Stakings vereinfachen wird.
• Verbesserung der Interaktionsebene mit der Konsensebene, Vereinfachung des Datenaustauschs zwischen den Eth1-Ausführungsblöcken und den Beacon-Chain-Blöcken. Dies wird Einzahlungen, Aktivierungen, Auszahlungen und Ausstiege erheblich vereinfachen, diese Prozesse beschleunigen und die Grundlage für weitere Interaktionen zwischen der Konsensebene und der Ausführungsebene legen.
• In Smart Contracts, support cheaper BLS signatures and zkSNARK verifications directly through the new “Pairing-Friendly” BLS12-381 precompiles.
• Ermutigen Sie Rollups, Blob-Transaktionen durch Erhöhung der Blob-Transaktionsschwelle und Erhöhung der calldata-Kosten zu übernehmen
• Lassen Sie EOA als programmierbares Konto fungieren und verleihen Sie ihm Mehrfachaufrufe, Sponsoring und andere erweiterte Funktionen

Wie Sie sehen können, wird Pectra einen erheblichen Einfluss auf das Benutzererlebnis bei Stakeholdering und Konsensschicht sowie Ausführungsschicht haben. Obwohl wir in dieser Phase nicht alle diese Änderungen detailliert durch Codeanalyse abdecken können, da die Entwicklung noch im Gange ist, werden wir diese Updates in zukünftigen Artikeln behandeln.