Das Pectra-Upgrade ist der nächste wichtige Meilenstein für das Ethereum-Netzwerk, der voraussichtlich im ersten Quartal 2025 umgesetzt wird. Dieses Upgrade besteht aus zwei Hauptkomponenten: dem Prager Upgrade (Ausführungsschicht) und dem Electra-Upgrade (Protokollschicht).
Im Gegensatz zu früheren großen Upgrades hat Pectra kein einziges prominentes Ziel; stattdessen konzentriert es sich auf mehrere technologische Verbesserungen und Optimierungen. Dies steht im Gegensatz zum Dencun-Upgrade (das die L2-Gebühren erheblich reduzierte) und zum Shapella-Upgrade (das den Rückzug von gestakedem ETH ermöglichte und den Übergang von Ethereum zu Proof of Stake (PoS) abschloss).
Kürzlich diskutierten die Ethereum-Kernentwickler (ACD, All Core Developers) während einer Telefonkonferenz die Möglichkeit, das Pectra-Upgrade in zwei Phasen aufzuteilen. In diesem Vorschlag heißt es:
Dieser stufenweise Ansatz zielt darauf ab, den Umfang und die Komplexität jedes Upgrades überschaubar zu halten und gleichzeitig genügend Zeit für gründliche Tests und die Verfeinerung der verschiedenen Technologien zu lassen.
Dieser Vorschlag führt vorberechnete Operationen auf der BLS12-381-Kurve ein und verbessert die Effizienz von Operationen wie der BLS-Signaturüberprüfung erheblich. Im Vergleich zu den vorhandenen vorberechneten BN254-Operationen bietet BLS12-381 eine höhere Sicherheit (über 120 Bits, während BN254 nur 80 Bits bietet). Diese Verbesserung umfasst nicht nur grundlegende Kurvenoperationen, sondern integriert auch Multi-Exponentiation und legt damit die Grundlage für eine effiziente Aggregation von öffentlichen Schlüsseln und Signaturen.
Dieser Vorschlag schlägt vor, die Hashes der letzten 8.192 Blöcke in einem Systemvertrag zu speichern, um in erster Linie die Ausführung zustandsloser Clients zu unterstützen. Auf diese Weise können zustandslose Clients leichter auf die erforderlichen historischen Informationen zugreifen und gleichzeitig die Kompatibilität mit dem vorhandenen BLOCKHASH-Opcode aufrechterhalten. Diese Änderung vereinfacht den Speichermechanismus für den Block-Hash-Verlauf und bietet einen neuen Ansatz für den Zugriff auf historische Daten.
Dieser Vorschlag integriert den Prozess der Validator-Einlagen direkt in die Blockstruktur der Ethereum-Ausführungsebene. Diese Änderung verschiebt die Verantwortung für die Einbeziehung und Überprüfung von Einlagen von der Konsensschicht auf die Ausführungsschicht und beseitigt die Notwendigkeit, dass die Konsensschicht über Einlagen (oder eth1data) abstimmt. Durch die Generierung einer Liste von Einlagen durch Analyse von Vertragsprotokollereignissen aus Einzahlungstransaktionen verbessert diese Methode nicht nur die Sicherheit und Effizienz der Einlagenverarbeitung, sondern auch die Benutzererfahrung. Darüber hinaus vereinfacht sie das Design der Client-Software und reduziert die Gesamtkomplexität des Systems.
Mit diesem Vorschlag wird ein neuer Mechanismus eingeführt, der es Validatoren ermöglicht, ihre Anmeldeinformationen über die Ausführungsschicht (0x01) zurückzuziehen, um Abhebungs- und Beendigungsvorgänge auszulösen. Insbesondere wird die Auszahlungsnachricht an den Block der Ausführungsschicht angehängt und dann von der Konsensschicht verarbeitet. Dieser Ansatz bietet Validatoren flexiblere Ausstiegsoptionen bei gleichzeitiger Aufrechterhaltung der Sicherheit und Konsistenz des Systems.
Dieser Vorschlag zielt darauf ab, den maximalen effektiven Saldo (MAX_EFFECTIVE_BALANCE) für Ethereum-Validatoren zu erhöhen, während der Mindest-Stake-Saldo bei 32 ETH bleibt. Diese Änderung bietet mehrere Vorteile:
Dieser Vorschlag schlägt vor, das Indexfeld des Ausschusses aus den signierten Proof-Nachrichten zu entfernen, um die Aggregation der gleichen Konsensstimmen zu ermöglichen. Das Hauptziel dieser Änderung besteht darin, die Effizienz von Casper FFG-Clients zu verbessern, indem die durchschnittliche Anzahl der erforderlichen Pairings zur Überprüfung der Konsensregeln reduziert wird. Während alle Arten von Clients von dieser Verbesserung profitieren können, wird erwartet, dass sie die bedeutendste Leistungsverbesserung für ZK-Schaltungen bietet, die den Casper FFG-Konsens nachweisen müssen.
Dieser Vorschlag definiert einen allgemeinen Rahmen für die Speicherung und Verarbeitung von Anfragen, die durch Smart Contracts ausgelöst werden. Die spezifische Implementierung fügt sowohl dem Ausführungsheader als auch dem Body ein Feld hinzu, um Anfrageinformationen zu speichern. Dadurch werden diese Anfragen der Konsenusschicht zugänglich gemacht und ermöglichen es ihr, jede Anfrage zu verarbeiten. Dieser Mechanismus ist hauptsächlich darauf ausgelegt, die steigende Nachfrage nach Validator-Kontrolle durch Smart Contracts zu bewältigen und eine Grundlage für komplexere On-Chain-Interaktionen in der Zukunft zu schaffen.
EIP-7702 wurde von Vitalik Buterin und anderen vorgeschlagen und zielt darauf ab, die Kontoabstraktion auf Ethereum zu optimieren. Mit diesem Vorschlag wird ein neuer Transaktionstyp eingeführt, der es externen Konten (EOAs) ermöglicht, Kontocode über einen Autorisierungsmechanismus festzulegen. Diese Verbesserung unterstützt mehrere neue Funktionen:
Durch die Annahme einer neuen Transaktionsstruktur verbessert dieser Vorschlag nicht nur die Funktionalität und Benutzerfreundlichkeit von EOAs, sondern bietet auch eine gute Kompatibilität und Skalierbarkeit für zukünftige Kontenabstraktionstechnologien.
Obwohl das Pectra-Upgrade kein herausragendes Hauptziel hat, wird es die Funktionalität, Sicherheit und Effizienz des Ethereum-Netzwerks durch eine Reihe von technischen Verbesserungen und Optimierungen weiter verbessern. Mit dem Fortschreiten der Upgrade-Pläne könnten weitere EIPs eingebunden oder angepasst werden.
Referenzen
[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 Developer Consensus Layer Meeting #197:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
Dieser Artikel stammt ausDwong], Originaltitel „Interpreting Ethereum Pectra: Das nächste große Upgrade“, Urheberrechtszuordnung zum Originalautor [dwong], wenn Sie Einwände gegen den Nachdruck haben, kontaktieren Sie uns bitte Gate Learn Team, das Team wird es so schnell wie möglich gemäß den entsprechenden Verfahren bearbeiten.
Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen repräsentieren ausschließlich die persönlichen Ansichten des Autors und stellen keine Anlageberatung dar.
Andere Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt und nicht erwähnt.Gate.io, der übersetzte Artikel darf nicht reproduziert, verteilt oder plagiiert werden.
Das Pectra-Upgrade ist der nächste wichtige Meilenstein für das Ethereum-Netzwerk, der voraussichtlich im ersten Quartal 2025 umgesetzt wird. Dieses Upgrade besteht aus zwei Hauptkomponenten: dem Prager Upgrade (Ausführungsschicht) und dem Electra-Upgrade (Protokollschicht).
Im Gegensatz zu früheren großen Upgrades hat Pectra kein einziges prominentes Ziel; stattdessen konzentriert es sich auf mehrere technologische Verbesserungen und Optimierungen. Dies steht im Gegensatz zum Dencun-Upgrade (das die L2-Gebühren erheblich reduzierte) und zum Shapella-Upgrade (das den Rückzug von gestakedem ETH ermöglichte und den Übergang von Ethereum zu Proof of Stake (PoS) abschloss).
Kürzlich diskutierten die Ethereum-Kernentwickler (ACD, All Core Developers) während einer Telefonkonferenz die Möglichkeit, das Pectra-Upgrade in zwei Phasen aufzuteilen. In diesem Vorschlag heißt es:
Dieser stufenweise Ansatz zielt darauf ab, den Umfang und die Komplexität jedes Upgrades überschaubar zu halten und gleichzeitig genügend Zeit für gründliche Tests und die Verfeinerung der verschiedenen Technologien zu lassen.
Dieser Vorschlag führt vorberechnete Operationen auf der BLS12-381-Kurve ein und verbessert die Effizienz von Operationen wie der BLS-Signaturüberprüfung erheblich. Im Vergleich zu den vorhandenen vorberechneten BN254-Operationen bietet BLS12-381 eine höhere Sicherheit (über 120 Bits, während BN254 nur 80 Bits bietet). Diese Verbesserung umfasst nicht nur grundlegende Kurvenoperationen, sondern integriert auch Multi-Exponentiation und legt damit die Grundlage für eine effiziente Aggregation von öffentlichen Schlüsseln und Signaturen.
Dieser Vorschlag schlägt vor, die Hashes der letzten 8.192 Blöcke in einem Systemvertrag zu speichern, um in erster Linie die Ausführung zustandsloser Clients zu unterstützen. Auf diese Weise können zustandslose Clients leichter auf die erforderlichen historischen Informationen zugreifen und gleichzeitig die Kompatibilität mit dem vorhandenen BLOCKHASH-Opcode aufrechterhalten. Diese Änderung vereinfacht den Speichermechanismus für den Block-Hash-Verlauf und bietet einen neuen Ansatz für den Zugriff auf historische Daten.
Dieser Vorschlag integriert den Prozess der Validator-Einlagen direkt in die Blockstruktur der Ethereum-Ausführungsebene. Diese Änderung verschiebt die Verantwortung für die Einbeziehung und Überprüfung von Einlagen von der Konsensschicht auf die Ausführungsschicht und beseitigt die Notwendigkeit, dass die Konsensschicht über Einlagen (oder eth1data) abstimmt. Durch die Generierung einer Liste von Einlagen durch Analyse von Vertragsprotokollereignissen aus Einzahlungstransaktionen verbessert diese Methode nicht nur die Sicherheit und Effizienz der Einlagenverarbeitung, sondern auch die Benutzererfahrung. Darüber hinaus vereinfacht sie das Design der Client-Software und reduziert die Gesamtkomplexität des Systems.
Mit diesem Vorschlag wird ein neuer Mechanismus eingeführt, der es Validatoren ermöglicht, ihre Anmeldeinformationen über die Ausführungsschicht (0x01) zurückzuziehen, um Abhebungs- und Beendigungsvorgänge auszulösen. Insbesondere wird die Auszahlungsnachricht an den Block der Ausführungsschicht angehängt und dann von der Konsensschicht verarbeitet. Dieser Ansatz bietet Validatoren flexiblere Ausstiegsoptionen bei gleichzeitiger Aufrechterhaltung der Sicherheit und Konsistenz des Systems.
Dieser Vorschlag zielt darauf ab, den maximalen effektiven Saldo (MAX_EFFECTIVE_BALANCE) für Ethereum-Validatoren zu erhöhen, während der Mindest-Stake-Saldo bei 32 ETH bleibt. Diese Änderung bietet mehrere Vorteile:
Dieser Vorschlag schlägt vor, das Indexfeld des Ausschusses aus den signierten Proof-Nachrichten zu entfernen, um die Aggregation der gleichen Konsensstimmen zu ermöglichen. Das Hauptziel dieser Änderung besteht darin, die Effizienz von Casper FFG-Clients zu verbessern, indem die durchschnittliche Anzahl der erforderlichen Pairings zur Überprüfung der Konsensregeln reduziert wird. Während alle Arten von Clients von dieser Verbesserung profitieren können, wird erwartet, dass sie die bedeutendste Leistungsverbesserung für ZK-Schaltungen bietet, die den Casper FFG-Konsens nachweisen müssen.
Dieser Vorschlag definiert einen allgemeinen Rahmen für die Speicherung und Verarbeitung von Anfragen, die durch Smart Contracts ausgelöst werden. Die spezifische Implementierung fügt sowohl dem Ausführungsheader als auch dem Body ein Feld hinzu, um Anfrageinformationen zu speichern. Dadurch werden diese Anfragen der Konsenusschicht zugänglich gemacht und ermöglichen es ihr, jede Anfrage zu verarbeiten. Dieser Mechanismus ist hauptsächlich darauf ausgelegt, die steigende Nachfrage nach Validator-Kontrolle durch Smart Contracts zu bewältigen und eine Grundlage für komplexere On-Chain-Interaktionen in der Zukunft zu schaffen.
EIP-7702 wurde von Vitalik Buterin und anderen vorgeschlagen und zielt darauf ab, die Kontoabstraktion auf Ethereum zu optimieren. Mit diesem Vorschlag wird ein neuer Transaktionstyp eingeführt, der es externen Konten (EOAs) ermöglicht, Kontocode über einen Autorisierungsmechanismus festzulegen. Diese Verbesserung unterstützt mehrere neue Funktionen:
Durch die Annahme einer neuen Transaktionsstruktur verbessert dieser Vorschlag nicht nur die Funktionalität und Benutzerfreundlichkeit von EOAs, sondern bietet auch eine gute Kompatibilität und Skalierbarkeit für zukünftige Kontenabstraktionstechnologien.
Obwohl das Pectra-Upgrade kein herausragendes Hauptziel hat, wird es die Funktionalität, Sicherheit und Effizienz des Ethereum-Netzwerks durch eine Reihe von technischen Verbesserungen und Optimierungen weiter verbessern. Mit dem Fortschreiten der Upgrade-Pläne könnten weitere EIPs eingebunden oder angepasst werden.
Referenzen
[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 Developer Consensus Layer Meeting #197:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
Dieser Artikel stammt ausDwong], Originaltitel „Interpreting Ethereum Pectra: Das nächste große Upgrade“, Urheberrechtszuordnung zum Originalautor [dwong], wenn Sie Einwände gegen den Nachdruck haben, kontaktieren Sie uns bitte Gate Learn Team, das Team wird es so schnell wie möglich gemäß den entsprechenden Verfahren bearbeiten.
Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen repräsentieren ausschließlich die persönlichen Ansichten des Autors und stellen keine Anlageberatung dar.
Andere Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt und nicht erwähnt.Gate.io, der übersetzte Artikel darf nicht reproduziert, verteilt oder plagiiert werden.