Das Pectra-Upgrade ist der nächste große Meilenstein für das Ethereum-Netzwerk und wird voraussichtlich im ersten Quartal 2025 umgesetzt. Dieses Upgrade besteht aus zwei Hauptteilen: dem Upgrade der Ausführungsschicht von Prag (Prag) und dem Upgrade der Protokollschicht von Electra (Konstellationsname).

Geschrieben von: dwong

Das Pectra-Upgrade ist der nächste große Meilenstein für das Ethereum-Netzwerk und wird voraussichtlich im ersten Quartal 2025 umgesetzt. Dieses Upgrade besteht aus zwei Hauptteilen: dem Upgrade der Ausführungsschicht von Prag (Prag) und dem Upgrade der Protokollschicht von Electra (Konstellationsname).

Im Gegensatz zu früheren großen Upgrades hat Pectra kein zentrales Hauptziel, sondern konzentriert sich auf zahlreiche technische Verbesserungen und Optimierungen. Dies steht im Gegensatz zum Dencun-Upgrade (das die L2-Gebühren drastisch senkte) oder dem Shapella-Upgrade (das Abhebungen von abgesteckten ETH ermöglichte und damit den letzten Schritt beim Übergang von Ethereum zum Proof-of-Stake (PoS) abschloss).

Neueste Entwicklungen

Kürzlich diskutierten die Ethereum Core Developers (ACD) All Core Developers während einer Telefonkonferenz die Möglichkeit, das Pectra-Upgrade in zwei Phasen aufzuteilen. Nach diesem Vorschlag:

  1. Pectra-Upgrades umfassen EIPs für PECtra-devnet-3 (Einzelheiten siehe unten).

  2. Die ursprünglich geplanten EOF- (EVM Object Format) und PeerDAS-Inhalte (Peer Data Availability Sampling) werden auf das nächste Upgrade verschoben, das vorläufig den Namen Fusaka (Fulu + Osaka) trägt.

  3. Verkle Trees-bezogene Inhalte, die ursprünglich für Osaka geplant waren, werden sich weiter verzögern und könnten in einem späteren Amsterdam-Upgrade implementiert werden.

Dieser schrittweise Ansatz soll sicherstellen, dass die Größe und Komplexität jedes Upgrades überschaubar bleibt und gleichzeitig genügend Zeit für die vollständige Prüfung und Verfeinerung jeder Technologie bleibt.

Pectra-Upgrade-bezogene EIPs

Zur Aufnahme identifizierte EIPs

  1. EIP-2537[1]: Vorkompilierung von BLS12-381-Kurvenoperationen

  2. EIP-2935[2]: Historische Block-Hashes im Status speichern

  3. EIP-6110[3]: Bereitstellung von Validator-Einzahlungen in der Kette

  4. EIP-7002[4]: Auslösbarer Exit der Ausführungsebene

  5. EIP-7251[5]: Erhöhen Sie das maximale effektive Guthaben

  6. EIP-7549[6]: Ausschussindex aus der Bescheinigung entfernen

  7. EIP-7685[7]: Generische Anforderungen der Ausführungsebene

  8. EIP-7702[8]: Legen Sie den EOA-Kontocode für eine Transaktion fest

In Betracht gezogene EIPs

  • EIP-7212: Unterstützt die Vorkompilierung von secp256r1-Kurven

  • EIP-7547[9]: Liste einschließen

  • EIP-7623[10]: Erhöhte Anrufdatenkosten

  • EIP-7742[11]: Machen Sie die Blob-Zählbeziehung zwischen der Konsensschicht und der Ausführungsschicht rückgängig

Einführung in die wichtigsten EIPs

EIP-2537: Vorkompilierung von BLS12-381-Kurvenoperationen

Dieser Vorschlag führt Vorkompilierungsoperationen auf der BLS12-381-Kurve ein und verbessert so die Effizienz von Operationen wie der BLS-Signaturüberprüfung erheblich. BLS12-381 bietet mehr Sicherheit als bestehende BN254-Vorkompilierungen (mehr als 120 Bit im Vergleich zu den 80 Bit von BN254). Diese Verbesserung umfasst nicht nur grundlegende Kurvenoperationen, sondern integriert auch mehrere exponentielle Operationen und legt damit den Grundstein für eine effiziente Aggregation öffentlicher Schlüssel und Signaturen.

EIP-2935: Speichern Sie historische Block-Hashes im Status

Der Vorschlag schlägt vor, die Hashes der letzten 8192 Blöcke im Systemvertrag zu speichern, eine Änderung, die in erster Linie der Unterstützung der zustandslosen Clientausführung dient. Auf diese Weise können zustandslose Clients die erforderlichen Verlaufsinformationen einfacher abrufen und gleichzeitig die Kompatibilität mit vorhandenen BLOCKHASH-Opcodes wahren. Dies vereinfacht nicht nur den Speichermechanismus des Block-Hash-Verlaufs, sondern bietet auch eine neue Möglichkeit, auf historische Daten zuzugreifen.

EIP-6110: Stellen Sie Validator-Einzahlungen in der Kette bereit

Der Vorschlag integriert den Prozess der Validator-Einzahlungen direkt in die Blockstruktur der Ethereum-Ausführungsschicht. Durch diese Änderung wird die Verantwortung für die Aufnahme und Überprüfung von Einlagen von der Konsensschicht auf die Ausführungsschicht verlagert, sodass die Konsensschicht nicht mehr über Einlagen (oder eth1data) abstimmen muss. Durch die Analyse der Vertragsprotokollereignisse von Einzahlungstransaktionen zur Erstellung einer Einzahlungsliste verbessert diese Methode nicht nur die Sicherheit und Effizienz der Einzahlungsabwicklung, sondern auch das Benutzererlebnis. Darüber hinaus vereinfacht es das Design der Client-Software und reduziert die Gesamtkomplexität des Systems.

EIP-7002: Auslösbarer Exit der Ausführungsschicht

Der Vorschlag führt einen neuen Mechanismus ein, der es Validatoren ermöglicht, Sperr- und Beendigungsvorgänge auszulösen, indem sie Anmeldeinformationen über die Ausführungsschicht (0x01) zurückziehen. Die spezifische Implementierung besteht darin, die Widerrufsnachricht an den Block der Ausführungsschicht anzuhängen, der dann von der Konsensschicht verarbeitet wird. Dieser Ansatz bietet Validatoren flexiblere Exit-Optionen und behält gleichzeitig die Sicherheit und Konsistenz des Systems bei.

EIP-7251: Erhöhen Sie das maximale effektive Guthaben

Der Vorschlag zielt darauf ab, das maximale effektive Guthaben (MAX_EFFECTIVE_BALANCE) der Ethereum-Validatoren zu erhöhen und gleichzeitig das Mindesteinsatzguthaben von 32 ETH beizubehalten. Diese Änderung hat mehrere Vorteile:

  1. Ermöglichen Sie großen Knotenbetreibern die Zusammenführung mit weniger Validatoren und verbessern Sie so die betriebliche Effizienz.

  2. Bieten Sie kleinen Spielern die Möglichkeit, Zinseszinsprämien zu erhalten, wodurch das Wetten attraktiver wird.

  3. Bieten Sie flexiblere Einsatzoptionen, um mehr Teilnehmer anzulocken.

  4. Reduzieren Sie redundante Validatoren im Netzwerk und reduzieren Sie die Anzahl der P2P-Nachrichten.

  5. Reduzieren Sie den Speicherbedarf von BeaconState und verbessern Sie die Systemeffizienz.

  6. In Verbindung mit dem verbesserten Teilauszugsmechanismus auf der Ausführungsebene wird die Liquidität des gesamten Ethereum-Netzwerks weiter optimiert.

EIP-7549: Ausschussindex aus der Attestierung verschieben

Der Vorschlag schlägt vor, das Indexfeld des Ausschusses aus signierten Bescheinigungsnachrichten zu entfernen, um die Aggregation identischer Konsensabstimmungen zu ermöglichen. Das Hauptziel dieser Änderung besteht darin, die Effizienz des Casper FFG-Clients zu verbessern, indem die durchschnittliche Anzahl der Paare reduziert wird, die zur Überprüfung der Konsensregeln erforderlich sind. Während alle Arten von Kunden von dieser Verbesserung profitieren können, wird diese Änderung wahrscheinlich zu den bedeutendsten Leistungsverbesserungen für ZK-Schaltkreise führen, die den Casper FFG-Konsens nachweisen müssen.

EIP-7685: Generische Anforderungen der Ausführungsschicht

Der Vorschlag definiert einen allgemeinen Rahmen für die Speicherung und Verarbeitung von durch Smart Contracts ausgelösten Anfragen. Die spezifische Implementierung besteht darin, dem Ausführungsheader und -körper ein Feld hinzuzufügen, um Anforderungsinformationen zu speichern, wodurch diese Anforderungen der Konsensschicht ausgesetzt werden und es ihr ermöglicht wird, jede Anforderung zu verarbeiten. Dieser Mechanismus ist hauptsächlich darauf ausgelegt, auf die steigenden Anforderungen von Validatoren zu reagieren, die durch Smart Contracts gesteuert werden, und eine Grundlage für komplexere On-Chain-Interaktionen in der Zukunft zu schaffen.

EIP-7702: Legen Sie den EOA-Kontocode für eine Transaktion fest

EIP-7702, vorgeschlagen von Vitalik Buterin und anderen, zielt darauf ab, die Kontoabstraktion von Ethereum zu optimieren. Der Vorschlag führt einen neuen Transaktionstyp ein, der es externen Konten (EOA) ermöglicht, Kontocodes über einen Autorisierungsmechanismus festzulegen. Diese Verbesserung ermöglicht mehrere neue Funktionen:

  1. Batch-Vorgänge: Ermöglichen Sie EOA, mehrere Vorgänge in derselben Transaktion auszuführen, um die Effizienz zu verbessern.

  2. Zahlungstransaktion: Bieten Sie Dritten die Möglichkeit, Transaktionsgebühren zu bezahlen.

  3. Herabstufung von Berechtigungen: Erhöhen Sie die Sicherheit und Flexibilität Ihres Kontos.

Durch die Einführung einer neuen Transaktionsstruktur verbessert der Vorschlag nicht nur die Funktionalität und Benutzerfreundlichkeit von EOA, sondern bietet auch eine gute Kompatibilität und Skalierbarkeit für zukünftige Kontoabstraktionstechnologien.

Abschluss

Obwohl das Pectra-Upgrade kein herausragendes Hauptziel hat, wird es die Funktionalität, Sicherheit und Effizienz des Ethereum-Netzwerks durch eine Reihe technischer Verbesserungen und Optimierungen weiter verbessern. Im Verlauf des Upgrade-Programms werden möglicherweise weitere EIPs integriert oder angepasst.

Referenzen

EIP-7600: Pectra-Hard-Fork-Metadaten[12]

Ethereum Core Developer Consensus Layer Meeting Nr. 197[13]

[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537

[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935

[3]EIP-6110: https://eips.ethereum.org/EIPS/eip-6110

[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002

[5]EIP-7251: https://eips.ethereum.org/EIPS/eip-7251

[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549

[7]EIP-7685: https://eips.ethereum.org/EIPS/eip-7685

[8]EIP-7702: https://eips.ethereum.org/EIPS/eip-7702

[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547

[10]EIP-7623: https://eips.ethereum.org/EIPS/eip-7623

[11]EIP-7742: https://eips.ethereum.org/EIPS/eip-7742

[12]EIP-7600: Pectra-Hard-Fork-Metadaten: https://eips.ethereum.org/EIPS/eip-7600

[13] Ethereum Core Developers Consensus Layer Meeting Nr. 197: https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/