Analysieren Sie Ethereums bevorstehende Hardgabeln – Pectra -Upgrade

einführen

In unserem vorherigen Artikel haben wir den Lebenszyklus von Ethereum Validator im Detail überprüft und mehrere Aspekte im Zusammenhang mit der kommenden Electra Hard Fork erörtert.Jetzt ist es an der Zeit, sich auf Änderungen der bevorstehenden Electra- und Prag -Upgrades zu konzentrieren und sie ausführlich zu erklären.

Die Geschichte des Ethereum 2.0 „Beweis für den Einsatz“ ist komplex.Es beginnt mit dem Hinzufügen einer Beacon -Schicht zur vorhandenen Ausführungsschicht, die den Nachweis der Arbeit (Phase0 und Altair Hardgabeln) beibehält, während die Beacon -Schicht den Beweis für den Einsatzkonsens initiiert.Anschließend ist POS in der Bellatrix Hard Fork vollständig aktiviert (obwohl der Rückzug nicht aktiviert ist).Dann erlaubt Capella Hard Fork Abhebungen und absolvieren den Lebenszyklus des Validators.Jüngste Hardgabeln Deneb (Teil des Upgrades von Deneb/Cancun) haben geringfügige Überarbeitungen der Beacon -Kettenparameter vorgenommen, z.Die Hauptänderungen in Dencun treten in der Ausführungsschicht auf, starten Blob -Transaktionen, Blobgas, KZG -Versprechen für Blobs und die Abgabe von Selbstdestrukturoperationen.

Jetzt führt die Hardgabel von Prag/Electra (d. H. Pectra) wichtige Verbesserungen der Ausführung und der Konsensschichten vor.Als Wirtschaftsprüfer für das LIDO-Projekt konzentrieren wir uns hauptsächlich auf Konsens und Veränderungen im Zusammenhang mit Veränderungen in dieser harten Gabel.Wir können jedoch die Änderungen der Ausführungsschicht in Prag jedoch nicht ignorieren, da sie wichtige Merkmale enthalten, die das Ethereum -Netzwerk und die Validatoren beeinflussen.Lassen Sie uns auf die Details dieser Änderungen eingehen.

Ein Überblick über Pectra auf höherer Ebene

Electra führt zahlreiche Merkmale in die Beacon -Schicht ein.Hauptaktualisierungen sind:

• Ermöglicht das gültige Gleichgewicht des Verifizierers zwischen 32 und 2048 ETH (und nicht einer festen 32 ETH).

• Ermöglicht die Überprüfungen, die Ausgänge durch sekundäre „Entzug“ -Geuchscheine einleiten (der Taste für aktive Verifizierer ist nicht mehr erforderlich).

• Ändern Sie die Art und Weise, wie die Beacon -Schicht ETH1 -Einlagen umgeht (das Ereignis wird nicht mehr aus dem Einzahlungsvertrag analysiert).

• Fügen Sie einen neuen gemeinsamen Rahmen für die Bearbeitung von Anfragen von regulären ETH1-Verträgen auf der Beacon-Schicht hinzu (ähnlich wie die Verwaltung vor der Elektralablagerung).

In der Zwischenzeit führte Prag die folgenden Änderungen der Ausführungsschicht vor:

• Ein neuer vorkompilierter Vertrag, der die BLS12-381-Kurve unterstützt, um ZksNark-Beweise zu überprüfen (mit Ausnahme der beliebten BN254-Kurve).

• Ein neuer Systemvertrag zum Speichern und Zugriff auf bis zu 8192 historische Blockhashes (sehr nützlich für Staatenlose Kunden).

• Erhöhen Sie die CALLDATA-Gaskosten, um die Blockgröße zu senken und Projekte zu ermutigen, CallData-Intensive wie Rollup zu Blobs in Dencun zu migrieren.

• Unterstützt mehr Blobs pro ETH1 -Block und bietet eine API zum Lesen dieser Zahlen.

• Das Ermöglichen von EOA (External -Account) kann einen eigenen Kontocode erheblich erweitern, was EOA tun kann, z. B. Multicalls auszuführen oder die Ausführung an andere Adressen zu delegieren.

Weitere Diskussionen finden Sie auf den relevanten Vorschlag für Ethereum Improvement (EIP):

• EIP-7251: MAX_EFPECTECTE_BALLED hinzugefügt

• EIP-7002: Ausführungsschicht löst den Ausgang aus

• EIP-6110: Die Einzahlung der Überprüfung wird auf Ketten bereitgestellt

• EIP-7549: Bewegen Sie den Ausschussindex aus dem Beweis heraus

• EIP-7685: Anfrage der allgemeinen Ausführungsschicht

• EIP-2537: Vorkompilierung des BLS12-381-Kurvenbetriebs

• EIP-2935: Historische Blockhash im Staat retten

• EIP-7623: Erhöhen Sie die Calldata-Kosten

• EIP-7691: Der BLOB-Durchsatz nimmt zu

• EIP-7840: Hinzufügen von BLOB-Zeitplan zur EL-Konfigurationsdatei

• EIP-7702: EOA-Kontocode einrichten

Einige dieser EIPs umfassen hauptsächlich die Konsensschicht (Consensus), während andere mit der Ausführungsschicht zusammenhängen.Einige umfassen zwei Schichten, da bestimmte Operationen (wie Einlagen und Abhebungen) synchrone Änderungen zwischen dem Konsens- und Ausführungsschichten erfordern.Aufgrund dieser gegenseitigen Abhängigkeit ist es unpraktisch, Electra und Prag zu trennen, sodass wir jeden EIP wiederum überprüfen und die jeweils betroffenen Ethereum -Komponenten angeben.

EIP-7251: MAX_EFPECTECTE_BALLED hinzugefügt

Referenz: EIP-7251

Seit der ersten Phase0 -Hardgabel wurde der maximal gültige Gleichgewicht des Überprüfers bis zu Electra auf 32 ETH festgelegt, um den Nachweis des Anteils für Ethereum vorzubereiten.Aktivieren Sie die Anforderungen an die Verifizierer mindestens spec.min_activation_balance (32 ETH).Nach der Aktivierung beginnt der Validator mit diesem maximal gültigen Gleichgewicht, kann jedoch sein gültiges Gleichgewicht auf Spec.Eunction_balance (16 ETH) reduzieren und beim Erreichen dieser Schwelle ein Rahmen sein.Diese „minimale“ Logik bleibt in Electra unverändert, aber jetzt wurde spec.max_effective_balance auf 2048 ETH erhöht.Daher kann der Validator zwischen 32 und 2048 ETH zur Aktivierung ablegen, was alle zu ihrem gültigen Saldo beiträgt.Diese Verschiebung markiert die Verschiebung von „32Th-Sof of Stake“ zu „Proof of Stake“ 🙂 🙂

Diese variable gültige Balance wird nun verwendet für:

• Erhöhen Sie die Wahrscheinlichkeit, ein Blockantrieb zu werden, proportional zum effektiven Gleichgewicht

• Erhöhen Sie die Wahrscheinlichkeit, Mitglied des Synchronausschusses zu werden, proportional zum effektiven Gleichgewicht

• Als Grundlage für die Berechnung der Menge an relativen Kürzungen und inaktiven Strafen

Die ersten beiden Aktivitäten sind die lohnendsten Aktionen für Validatoren.Daher werden nach Electra häufiger Validatoren bei großem Einstellen am Blockvorschlag und den Synchronisationsausschüssen teilnehmen, wobei die Frequenz proportional zu ihrem effektiven Gleichgewicht ist.

Ein weiterer Einfluss hat mit Schnitten zu tun.Alle Kürzungen sind proportional zum gültigen Gleichgewicht des Überprüfers:

• „Sofortige“ und „Verzögerungskürzungen“ sind für Validatoren von hohen Einsätzen noch größer.

• Die „verzögerten“ Schnittfeine mit Grenzwertvalidatoren mit hohen Zusagen sind ebenfalls größer, da der „Grenzwert“ des Gesamtversprechens größer wird.

• Whistleblower, die Validatoren mit höheren gültigen Guthaben melden, erhalten einen größeren Anteil an reduzierten Einsätzen.

Electra schlug auch Änderungen des Schnittverhältnisses vor, definierte einen Teil des abgeschnittenen Validator -Gleichgewichts und erhielt ihn durch den Whistleblower.

Als nächstes kommt die Auswirkungen der Ungültigkeit.Wenn der Validator bei aktivem (beweisen oder vorgeschlagen) offline ist, sammelt sich der Ingunziitätswert an, was zur Verhängung der Ungültigkeitsstrafe für jeden Zyklus führt.Diese Strafen haben auch mit dem gültigen Saldo des Validators zu tunAnteilBeziehung.

Aufgrund der Erhöhung des gültigen Saldos hat sich auch die „Ersatzlimit“ des Verifizierers geändert.In Ethereum „Before Electra“ haben Validatoren in der Regel die gleiche gültige Balance, und die Ausgangsersatzlimit wird als „In einem Zyklus definiert, kann es nicht maximal 1/65536 (Spec.Crurn_Limit_quotient) Total Aspace geben Erstellt eine „feste“ Anzahl von Verifiziererausgängen mit demselben Anteil.Nach Electra gibt es jedoch möglicherweise nur wenige „Wale“ aus, weil sie einen wichtigen Teil des Gesamtversprechens darstellen.

Eine weitere Überlegung ist die Drehung vieler Verifizierertasten auf einer einzelnen Verifiziererinstanz.Derzeit sind große Validatoren gezwungen, Tausende von Validatorschlüssel auf einer Instanz zu betreiben, um ein großes Einlagen aufzunehmen und sie in 32 ETH -Abschnitte aufzuteilen.Bei Electra ist dieses Verhalten nicht mehr obligatorisch.Aus finanzieller Sicht hat diese Änderung nur geringe Auswirkungen, da die Belohnungen und Wahrscheinlichkeit mit der Menge an Versprechen linear skaliert sind.Daher entsprechen 100 Validatoren pro 32 ETH einer ETH 3200 ETH.Darüber hinaus können mehrere aktive Tasten für aktive Verifizierer den gleichen ETH1 -Rückzugsanweis aufweisen, sodass alle Belohnungen an eine einzige ETH -Adresse zurückgezogen werden können, wodurch die mit Belohnungsfusionen verbundenen Gaskosten vermieden werden.Durch die Verwaltung großer Mengen an Tasten entstehen jedoch zusätzliche Verwaltungskosten.

Die Fähigkeit, Validator Balances zu aggregieren, fügt einen neuen Anforderungsart für Ausführungsschicht hinzu.Vorher hatten wir Einlagen und Abhebungen.Jetzt wird es einen anderen Typ geben: Gesamtanforderung.Es kombiniert zwei Validatoren zu einem.Diese Betriebsanforderung enthält den öffentlichen Schlüssel des Quellverifiers und den Zielpublikum und wird ähnlich wie Einzahlungen und Abhebungen verarbeitet.Die Aggregationen haben auch anhängige Anfragen und Einschränkungen des Gleichgewichtsersatzes, genau wie Einlagen und Abhebungen.

Die Zusammenfassung lautet wie folgt:

• Für kleine unabhängige Validatoren führt Electra die Fähigkeit ein, ihr effektives Gleichgewicht (und Belohnungen) automatisch zu erhöhen.Zuvor konnte ein Überschuss von mehr als 32 ETH erst zurückgezogen werden, aber nach Electra wird dieser Überschuss schließlich zu seinem effektiven Gleichgewicht beitragen.Das effektive Gleichgewicht kann jedoch nur die Vielfachen von Spec.Effective_Balance_increment (1 ETH) erhöhen, was bedeutet, dass die Erhöhung erst nach der nächsten „1 Eth -Grenze“ auftritt.

• Für große unabhängige Validatoren bietet Electra eine signifikante Vereinfachung des Managements, indem mehrere aktive Validatorschlüssel in einem konsolidiert werden können.Während dies das Spiel nicht ändert, ist der Betrieb eines 1×2048 -Anteils zweifellos viel einfacher als die Verwaltung von 64×32 -Einsätzen.

• Für mobile Anbieter, die von Benutzern ein kleines Einrichten und die Zuweisung zwischen Validatoren sammeln, fügt Electra mehr Flexibilität im Einstellallokationsschema hinzu, erfordert jedoch auch die Berücksichtigung von Validatoren, die auf festen 32 ETH -gültigen Guthaben ausführen, ein schwerwiegendes Refactoring durchzuführen.

Ein weiteres wichtiges Thema sind die historischen Daten und Gewinnschätzungen von Validatoren, insbesondere für neue Teilnehmer, die versuchen, Risiken und Belohnungen zu bewerten.Vor Electra (zum Zeitpunkt dieser Schrift) schuf die 32 ETH -Kappe (sowohl kleinste als auch größte) Einheitlichkeit der historischen Daten.所有验证者的有效余额、奖励、个体削减惩罚、区块提议频率和其他指标都相同。这种均匀性使以太坊能够在没有统计异常值的情况下测试其共识机制，从而收集有价值的网络行为数据。

在 Electra 之后，质押的分布将发生重大变化。Große Validatoren werden häufiger an Blockvorschlägen und Synchronisationsausschüssen beteiligt sein, wobei höhere Kürzungen und größere Auswirkungen auf verzögerte Kürzungen, Aktivierungswarteschlangen und Ausgangswarteschlangen beeinträchtigen.虽然这可能在数据聚合中造成挑战，但以太坊的共识确保非线性计算是最小的。Die einzige nichtlineare Komponente verwendet SQRT (Total_effective_Balance), um die Basisbelohnung zu berechnen, die für alle Validatoren gilt.Dies bedeutet, dass Validator-Belohnungen und -kürzungen weiterhin auf der Basis von „PER-1 ETH“ geschätzt werden können (oder genauer auf der Grundlage von spec.effective_balance_increment, die sich in Zukunft ändern können).

Weitere Informationen finden Sie in unserem vorherigen Artikel zum Verhalten des Validators.

EIP-7002: Auslöser ausführbare Ausführungsschichtausgang

Referenz: EIP-7002

Jeder Validator in Ethereum verfügt über zwei Schlüsselpaare: einen aktiven Schlüssel und einen Rückzugsschlüssel.Ein aktiver öffentlicher BLS -Schlüssel dient als primäre Identität des Verifizierers in der Beacon -Kette, die zum Signieren von Blöcken, Beweisen, Kürzungen, Synchronisierungsausschüssen und (vor diesem EIP) freiwilligen Ausstieg verwendet wird (um eine Verzögerung zu befolgen (um eine Verzögerung zu befolgen, initiieren Sie den Konsens des Verifizierers ein. Ausfahrt).Das zweite Schlüsselpaar („Entzugsgutschein“) kann ein weiteres BLS -Schlüsselpaar oder ein reguläres ETH1 -Konto (privater Schlüssel und Adresse) sein.Jetzt müssen die Auszahlungsmeldungen, die vom aktiven BLS Private -Schlüssel unterzeichnet werden, an die ETH -Adresse extrahiert werden.Dieser EIP wurde geändert.

Tatsächlich können die Eigentümer dieser beiden Schlüsselpaare (aktive und abzüge) unterschiedlich sein.Der aktive Schlüssel des Verifiers ist für die Überprüfungsverantwortung verantwortlich: Ausführen des Servers, des normalen Betriebs usw., und Entzugsgutscheine werden normalerweise vom Beteiligten Eigentümer gesteuert, der Belohnungen erhält und für Mittel verantwortlich ist.Gegenwärtig kann nur der Verpfändungsbesitzer, der den Auszugsgutschein kontrolliert, den Ausgang des Verifierers nicht einleiten und die Belohnung nur zurückziehen kann.Diese Situation ermöglicht es dem aktiven Schlüsselbesitzer des Verifizierers, das Gleichgewicht des Verifiers als „Geisel“ in seiner Hand effektiv zu halten.Der Überprüfer kann die Ausgangsnachricht „vorab“ „vorab“ „dem Stakeholder übergeben“, aber diese Problemumgehung ist nicht ideal.Darüber hinaus erfordern sowohl Extraktion als auch Ausgang derzeit eine Interaktion mit Beacon Layer -Validatoren über eine dedizierte API.

Die beste Lösung besteht darin, dem Beteiligungsbesitzer sowohl Ausstiegs- als auch Auszahlungsvorgänge durch regelmäßige Smart -Vertragsanrufe durchzuführen.Dies beinhaltet eine Standard -ETH1 -Signaturüberprüfung, die den Betrieb erheblich vereinfacht.

Mit diesem EIP können Stakeholder Abhebungen und Ausgaben auslösen, indem Standardtransaktionen an dedizierte intelligente Verträge von ihrer ETH -Adresse gesendet werden (ähnlich dem vorhandenen Einzahlungsverfahren unter Verwendung von „Einzahlungsverträgen“).Der Prozess des Extrahierens (oder des Verlassens, wenn ausreichend gestaltet wird) ist wie folgt:

• Die Verpflegung sendet einen Auszahlungsantrag („in“ Anfrage) an den „Auszahlungsvertrag“ des Systems.

• Die Vertragsgebühren erhoben spezifische Gebühren (in ETH), um potenzielle böswillige Angriffe zu mildern, und ähnlich wie bei EIP-1559 steigen die Gebühren, wenn die Anfrage-Warteschlange beschäftigt ist.

• Der Vertrag spart den Antrag „in“ Abhebungs-/Ausstiegsanfrage für seinen Speicher.

• Wenn der Beacon -Schicht ein Block vorgeschlagen wird, wird die Anforderung „In“ -Enwöhnung/Beenden in der Warteschlange aus dem Speicher abgerufen.

• Die Beacon Layer verarbeitet die „In“ -Anforderung, interagiert mit dem Gleichgewicht des aktiven Verifizierers, stellt den Überprüfer zum Beenden und bildet einen „Auszugsantrag“ aus „out“.

• Die Auszahlungsanfrage „Out“ wird in der Ausführungsschicht bearbeitet, und der Stakeholder erhält seine ETH.

Obwohl Ablagerungen im ETH1 -Block ausgelöst und dann durch die „ausstehende“ Einzahlungswarteschlange „bewegt“ werden „, folgen Abhebungen unterschiedlichen Schemata.Sie werden auf der Beacon -Schicht (über die CLI) ausgelöst und dann in den ETH1 -Block „bewegt“.Beide Systeme werden nun denselben gemeinsamen Framework (wie unten beschrieben) durchführen: Erstellen Sie eine Anfrage in der ETH1 -Ebene, verarbeiten Sie die „ausstehenden“ Einzahlungs-/Auszahlungs-/Zusammenführungswarteschlangen und verarbeiten Sie sie auf der Beacon -Schicht.Für „Ausgabeberationen“ wie Entzug wird auch die Ausgangswarteschlange verarbeitet, und das Ergebnis wird im ETH1 -Block „festgelegt“.

Mit diesem EIP können Staker regelmäßige ETH -Transaktionen verwenden, um ihre Validatoren zu extrahieren und zu verlassen, ohne direkt mit der Validator -CLI zu interagieren oder auf die Infrastruktur des Validators zuzugreifen.Dies vereinfacht die Abläufe, insbesondere für große Haftanbieter, erheblich.Die Überprüfungsinfrastruktur kann jetzt fast vollständig isoliert werden, da nur der Schlüssel des aktiven Verifizierers beibehalten wird, während alle Einstellvorgänge an anderer Stelle behandelt werden können.Es wird von unabhängigen Stakern beseitigt, auf aktive Validator-Aktionen zu warten, und vereinfacht den nicht-ketten-Teil der Lido-Dienste wie das Community-Stakelmodul erheblich.

Daher „vervollständigt“ dieser EIP den Einlagenbetrieb und migriert ihn vollständig in die ETH1 -Schicht, wodurch die Sicherheitsrisiken der Infrastruktur erheblich reduziert und die Dezentralisierung unabhängiger Stakelinitiativen verbessert wird.

EIP-6110: Versorgung von Überprüfungsvorkommen in der Kette

Referenz: EIP-6110

Derzeit werden Einzahlungen durch Ereignisse im „Einzahlungsvertrag“ des Systems (wie in früheren Artikeln ausführlich erläutert) erreicht.Der Vertrag akzeptiert ETH- und Verifizierer -Anmeldeinformationen und Ausgaben „Deposit ()“ Ereignisse, die dann analysiert und in Einzahlungsanfragen auf der Beacon -Schicht umgewandelt werden.该系统有许多缺点：它要求对信标链层的 eth1data 进行投票，这增加了显著的延迟。Darüber hinaus muss die Beacon -Schicht die Ausführungsschicht abfragen, was die Komplexität weiter erhöht.Diese Themen werden im EIP ausführlich erörtert.Ein einfacherer Weg, um mit vielen dieser Probleme zu handeln, besteht darin, Einzahlungsanfragen direkt in den ETH1 -Block am angegebenen Ort einzubeziehen.Dieser Mechanismus ähnelt dem im vorherigen EIP beschriebenen Abenthaltsverarbeitungsprozess.

Die in diesem EIP vorgeschlagenen Änderungen sind vielversprechend.Die ETH1DATA -Verarbeitung kann jetzt vollständig entfernt werden, wobei keine Verzögerungen zwischen Ereignissen auf der ETH1 -Seite und Einzahlungen auf der Beacon -Schicht (derzeit ca. 12 Stunden) stimmen oder länger ablegen müssen.Es beseitigt auch die Logik von Einzahlungsvertrags -Schnappschüssen.Dieser EIP vereinfacht die Ablagerungsabwicklung und stimmt mit dem oben beschriebenen Auszahlungsverarbeitungsschema aus.

Für Staker und Validatoren verringern diese Änderungen die Verzögerung zwischen Einlagen und Aktivierung von Validator erheblich.Wenn Validatoren geschnitten werden, sind auch die erforderlichen Ergänzungsmittel schneller.

Es gibt nichts mehr zu diesem EIP zu sagen, außer dass er veraltete Logik entfernt, den Prozess vereinfacht und bessere Ergebnisse für alle Beteiligten erzielt.

EIP-7685: Anfrage der allgemeinen Ausführungsschicht

Referenz: EIP-7685

Dieser EIP hätte vor den ersten drei EIPs im Zusammenhang mit Einzahlung/Auszahlung/Fusion vorgeschlagen werden sollen, da er die Grundlage für diese EIPs legt.Die Einführung hier ist jedoch, die wachsende Nachfrage nach konsistenten mobilen dedizierten Daten zwischen ETH1 (Ausführung) und Beacon (Consensus) -Kettenblöcken (Schichten) hervorzuheben.Dieser EIP betrifft zwei Ebenen, wodurch die Anfrageverarbeitung durch herkömmliche ETH -Transaktionen effizienter ausgelöst wird.Derzeit beobachten wir:

• Das Einzahlungsereignis im ETH1 -Block wird zur Bearbeitung in den Beacon -Block „verschoben“.

• Die Auszahlungsanfrage (unter Verwendung der CLI) im Beacon -Block wird zur Bearbeitung in den ETH1 -Block „verschoben“.

• Der Verifierer-Merge muss verarbeitet werden, was auch eine ETH1- & GT; Beacon-Anfrage darstellt.

Diese drei Vorgänge zeigen die Notwendigkeit einer konsistenten Verarbeitung verschiedener Arten von Anforderungen beim Wechsel zwischen der Ausführungsschicht und der Beacon -Schicht.Darüber hinaus benötigen wir die Fähigkeit, diese Operationen nur mithilfe der ETH1 -Schicht auszulösen, da wir die Infrastruktur des Validators aus der Infrastruktur für die Stakelmanagement isolieren können, wodurch die Sicherheit verbessert wird.Eine allgemeine Lösung zur Verwaltung solcher Anfragen ist daher sowohl praktisch als auch notwendig.

Dieser EIP legt einen Rahmen für mindestens drei Hauptsituationen fest: Einlagen, Abhebungen und Fusionen.Aus diesem Grund hat Early EIP Felder wie Encent_Request_Type und Deposit_Request_Type eingeführt, und jetzt wird der Zusammenschluss ein weiteres Feld hinzufügen, Consolidation_Request_Type.Darüber hinaus kann dieser EIP einen gemeinsamen Mechanismus für die Bearbeitung von Beschränkungen für solche Anforderungen enthalten (Referenzkonstanten: anhängig_deposits_limit, anhängig_Partial_Withdrawals_Limit, anhängig_consolidations_limit).

Während detaillierte Implementierungsdetails zu diesem Framework noch nicht verfügbar sind, werden sicherlich kritische Anfragetypen, Integritätsmechanismen (z. B. Hashing und Merkelized Anfragen) sowie ausstehende Warteschlangenverarbeitung und Ratenbeschränkung enthalten.

Dieser EIP ist architektonisch aussagekräftig und ermöglicht Eth1, kritische Operationen in der Beacon -Schicht durch ein einheitliches Rahmen auszulösen.Für Endbenutzer und Projekte bedeutet dies, dass alle in Eth1 Layer ausgelösten Anfragen auf der Beacon -Schicht effizienter geliefert und verarbeitet werden.

EIP-2537: Vorkompilierung des BLS12-381-Kurvenbetriebs

Referenz: EIP-2537

Wenn Sie keinen tieferen Blick darauf werfen möchten, können Sie sich die Vorkompilierung von BLS12-381 als komplexe Verschlüsselung „Hash“ -Operation vorstellen, die jetzt in intelligenten Verträgen verwendet werden kann.Lassen Sie uns für Interessierte weiter erkunden.

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

• BLS -Signaturen, bei denen eine spezielle Operation als „Paarung“ verwendet wird, um diese Signaturen zu überprüfen.BLS -Signaturen werden von Überprüfern weit verbreitet, da sie mehrere Signaturen zu einem aggregieren.Validatoren stützen sich auf BLS-Signaturen basierend auf BLS12-381-Kurven (obwohl sie auch mit jeder Kurve implementiert werden können, die die Paarung wie BN254 unterstützt).

• Überprüfung von ZksNark -Proofs, bei denen die Paarung zur Überprüfung von Beweisen verwendet wird.Darüber hinaus verwenden KZG -Verpflichtungen für große Stücke, die von Dencun Hard Forks eingeführt wurden, die Paarung, um Blockverpflichtungen zu validieren.

Wenn Sie BLS -Signaturen oder ZksNark -Beweise in einem intelligenten Vertrag überprüfen möchten, müssen Sie diese „Paare“ berechnen, was rechnerisch teuer ist.Ethereum hat bereits einen vorkompilierten Vertrag (EIP-196 und EIP-197) für den BN254-Kurvenbetrieb.Die BLS12-381-Kurve (heute als sicherer und heute genauer verwendet) wurde jedoch noch nicht als vorkompiliert implementiert.In Ermangelung einer solchen Vorkompilierung erfordert die Implementierung von Paarungen und anderen Kurvenoperationen in intelligenten Verträgen viele Berechnungen, wie hier gezeigt, und verbraucht großes Gas (ca. ~ 10 bis 10^6 Gas).

Dieser EIP öffnet die Tür zu vielen potenziellen Anwendungen, insbesondere bei billiger BLS-Signaturüberprüfung basierend auf der BLS12-381-Kurve.Dies ermöglicht es, Schwellenwertlösungen für verschiedene Zwecke zu erreichen.Wie bereits erwähnt, haben Ethereum-Validatoren BLS12-381-basierte Signaturen verwendet.Mit diesem EIP können Standard -Smart -Verträge jetzt die aggregierten Überprüfungssignaturen effizient überprüfen.Dies kann die Überbrückung des Konsens und über Netzwerkanlagen über die Überbrückung des Konsens übereinstimmen, da BLS -Signaturen in Blockchains weit verbreitet sind.Schwellenwert-BLS-Signaturen selbst ermöglichen die Konstruktion vieler effizienter Schwellenwertschemata für Abstimmungen, dezentrale Zufallszahlengenerierung, Mehrsignatur usw.

Die Überprüfung des billigeren ZksNark -Proofs entsperren wiederum eine große Anzahl von Anwendungen.Viele ZksNark-basierte Lösungen werden derzeit durch hohe Beweisüberprüfungskosten behindert, was bestimmte Projekte nahezu unpraktisch macht.Dieser EIP hat das Potenzial, dies zu ändern.

EIP-2935: Historische Blockhash im Staat retten

Referenz: EIP-2935

Dieser EIP schlägt vor, 8192 (ca. 27,3 Stunden) historische Blockhashes im Blockchain -Zustand zu speichern und für Staateless Kunden wie Rollups und intelligente Verträge einen erweiterten Geschichte zu bieten.Es wird empfohlen, das aktuelle Verhalten des Blockhash -Opcode beizubehalten, wobei ein Grenzwert für 256 Blöcke beibehalten wird, während ein neuer Systemvertrag eingeführt wird, der speziell für das Speichern und Abrufen historischer Hashes entwickelt wurde.Dieser Vertrag führt die SET () -Operation durch, wenn die Ausführungsschicht den Block verarbeitet.Die GET () -Methode ist für jeden zugänglich, um den erforderlichen Block -Hash aus dem Ringpuffer abzurufen.

Derzeit ist es möglich, auf historische Block -Hash in EVM zu verweisen, aber der Zugang ist auf die neuesten 256 Blöcke (ca. 50 Minuten) beschränkt.Der Zugriff auf ältere Blockdaten ist jedoch in einigen Fällen von entscheidender Bedeutung, insbesondere für Cross-Chain-Anwendungen (Daten, die nachgewiesene Blöcke erfordern) und auf Staateless Clients, die regelmäßig Zugriff auf frühe Blockhashes erfordern.

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

EIP-7623: Erhöhen Sie die Calldata-Kosten

Referenz: EIP-7623

Die CallData -Kosten reguliert die verfügbare Größe der Transaktionsnutzlast und kann in einigen Fällen groß sein (z. B. wenn sie große Arrays oder Binärpuffer als Parameter übergeben).Die Verwendung von Calldata wird hauptsächlich auf Rollups zurückgeführt, die Nutzlasten über CallData mit dem aktuellen Rollup -Status senden.

Die Einführung großer, nachgewiesener Binärdaten in Blockchain ist für das Rollen von entscheidender Bedeutung.Das Upgrade des Deneb-Cancun (Deneb-Cancun) führt zu einer wichtigen Innovation für solche Anwendungsfälle-BLOB-Transaktionen (EIP-4844).Blob -Transaktionen haben ihre eigenen speziellen „Blob“ -Gasgebühren.Daher bietet Blob eine bessere Lösung für das Rollup als die Verwendung von CallData zum Speichern von Daten.

Ermutigen Sie Rollup, seine Daten in den Blob zu übertragen.Die reduzierte Blob -Gasgebühr wird als „Karotten“ verwendet, und dieser EIP unterdrückt übermäßige Datenspeicher in Transaktionen, indem die CallData -Kosten als „Hebel“ erhöht werden.Dieser EIP ergänzt den nächsten EIP-7691 (erhöhter Blob-Durchsatz), wodurch die maximale Anzahl der zulässigen Blobs pro Block erhöht wird.

EIP-7691: Der BLOB-Durchsatz nimmt zu

Referenz: EIP-7691

Die Blobs wurden in der vorherigen Dencun -Hardgabel eingeführt, und die Anfangswerte der Maximum und der Zielzahl von „pro Block“ sind konservative Schätzungen.Dies ist auf die Komplexität der Vorhersage zurückzuführen, wie das P2P -Netzwerk mit der Ausbreitung großer binärer Objekte zwischen Validatorknoten umgeht.Die vorherige Konfiguration hat sich als gut erwiesen, was dies zum richtigen Zeitpunkt macht, um neue Werte zu testen.Zuvor wurde die Ziel-/Maximum -Blob -Nummer für jeden Block auf 3/6 eingestellt.Diese Einschränkungen werden nun auf 6/9 erhoben.

In Kombination mit früheren EIP-7623 (steigende CallData-Kosten) motiviert diese Anpassung das Rollup weiter, um seine Daten von Calldata auf Blobs zu übertragen.Die Arbeit, die besten Blob -Parameter zu finden, wird fortgesetzt.

EIP-7840: Fügen Sie der EL-Konfigurationsdatei den Blob-Zeitplan hinzu

Referenz: EIP-7840

Dieser EIP schlägt vor, das Ziel für das Ziel und das maximale „pro Block“ -BlOB (zuvor diskutiert) und den Basisfei-Ut-Wert zur Konfigurationsdatei Ethereum Execution Layer (EL) hinzuzufügen.Es ermöglicht Clients auch, diese Werte über die Knoten -API abzurufen.Diese Funktion ist besonders nützlich für Aufgaben wie die Schätzung der Blob -Gaskosten.

EIP-7702: EOA-Kontocode einrichten

Referenz: EIP-7702

Dies ist ein sehr wichtiger EIP, der signifikante Änderungen an den Nutzern von Ethereum einbringt.Wie wir wissen, kann EOA (externes Konto) keinen Code haben, sondern eine Transaktionssignatur (tx.origin) bereitstellen.Im Gegensatz dazu haben intelligente Verträge Bytecode, können jedoch keine direkte Signatur von „IT“ proaktiv vorschlagen.Jede Benutzerinteraktion, die eine zusätzliche, automatische und überprüfbare Logik erfordert, kann derzeit nur die erforderlichen Aktionen durch Aufrufen externer Verträge ausführen.In diesem Fall wird der externe Vertrag jedoch zum MSG.Sender des nachfolgenden Vertrags, wodurch der Aufruf zum „Aufruf aus dem Vertrag, nicht vom Benutzer“ geführt wird.

Dieser EIP führt einen neuen set_code_tx_type = 0x04 Transaktionstyp ein (wir hatten zuvor alte 0x1-Transaktionen, neue 0x02-Transaktionen von Berlin- und EIP-1559-Upgrades und in Dencun eingeführte 0x03-BLOB-Transaktionen).Dieser neue Transaktionstyp ermöglicht das Einstellen von Codes für EOA -Konten.Tatsächlich ermöglicht es EOA, externen Code „im Kontext eines eigenen EOA -Kontos“ auszuführen.Aus einer externen Perspektive scheint EOA während des Transaktionsprozesses den Code aus dem externen Vertrag zu „ausführen“ und ihn auszuführen.Technisch gesehen wird dies durch Hinzufügen eines speziellen autorisierten Daten -Tupels zum „Code“ -Speod der EOA -Adresse erreicht (dieser „Code“ -Speicher war für die EOA immer leer vor diesem EIP).

Derzeit enthält der neue von diesem EIP vorgeschlagene Transaktionstyp 0x04 ein Array:

Autorisierung_List = [[chain_id, adresse, nonce, y_parity, r, s], …]

Jedes Element ermöglicht das Konto den Code aus der angegebenen Adresse (aus dem letzten gültigen Autorisierungselement).Bei der Bearbeitung solcher Transaktionen wird der angegebene EOA -Code auf einen speziellen 0xef0100 || eingestellt kann nicht einbezogen werden (gemäß EIP-3541).Dieser magische Wert stellt sicher, dass diese EOA nicht als regulärer Vertrag angesehen werden kann, und sie kann auch nicht wie ein regulärer Vertrag genannt werden.

Wenn dieses EOA eine Transaktion initiiert, wird die angegebene Adresse verwendet, um den entsprechenden Code im Kontext des EOA aufzurufen.Während die vollständigen Implementierungsdetails dieses EIP nicht klar sind, ist es sicher, dass sie erhebliche Änderungen mit sich bringen wird.

Ein wesentlicher Einfluss ist die Fähigkeit, Multicalls direkt aus EOA zu machen.Mehrere Anrufe sind ein anhaltender Trend in Defi, und viele Protokolle bieten diese Funktion als leistungsstarkes Werkzeug (wie Uniswap V4, Balancer V3 oder Euler V2).Mit diesem EIP können Sie jetzt mehrere Anrufe direkt von EOA initiieren.

Beispielsweise löst diese neue Funktion ein gemeinsames Problem in Defi: genehmigen () + alles () erfordert eine Ineffizienz von zwei unabhängigen Transaktionen.Dieser EIP ermöglicht eine gemeinsame „Vorautorisierung“ -Logik, sodass (x) + Einzahlung (x) in einer einzelnen Transaktion abgeschlossen werden kann.

Ein weiterer Vorteil, in der Lage zu sein, die EOA -Transaktionsausführung „vertreten“ zu können, ist das Konzept des Sponsorings.Das Sponsoring ist eine häufig diskutierte und sehr gewünschte Funktion, mit der neue Benutzer in Ethereum eintreten können.

Die mit EOA verbundene programmierbare Logik ermöglicht viele Möglichkeiten wie die Implementierung von Sicherheitsbeschränkungen, das Festlegen von Ausgabenkappen, die obligatorischen KYC -Anforderungen und vieles mehr.

Diese Änderung wirft natürlich auch viele Designprobleme auf.Ein Problem ist die Verwendung von chain_id, die feststellt, ob die gleiche Signatur in mehreren Netzwerken gültig sein kann, je nachdem, ob sie in der Signatur enthalten ist oder nicht.Ein weiteres komplexes Problem ist die Wahl zwischen der Verwendung der Adresse des Zielcodes und der Einbettung des tatsächlichen Bytecode.Diese beiden Methoden haben ihre eigenen Merkmale und Einschränkungen.Darüber hinaus spielt die Verwendung von NonCE eine Schlüsselrolle bei der Definition, ob Berechtigungen „Mehrzweck“ oder „Einzelpur“ sind.Diese Elemente beeinflussen Funktions- und Sicherheitsprobleme, einschließlich Stapelfehlersignaturen und Benutzerfreundlichkeit.Vitalik warf diese Fragen in einer Diskussion (hier) auf und verdient weitere Erforschung.

Es ist erwähnenswert, dass diese Änderung einen Sicherheitsmechanismus von Ethereum, Tx.origin, beeinflusst.Weitere Details zu dieser EIP -Implementierung sind erforderlich, aber es sieht so aus, als würde sich das Verhalten von (tx.origin == msg.sender) ändern.Dieser Scheck war schon immer der zuverlässigste Weg, um sicherzustellen, dass MSG.Sender EOA ist, kein Vertrag.Andere Methoden, wie z. B. die Überprüfung von Extcodeze (um zu überprüfen, ob es sich um einen Vertrag handelt), schlägt normalerweise fehl und können umgangen werden (z. B. indem Sie den Konstruktor aufrufen oder den Code nach einer Transaktion an einer vordefinierten Adresse bereitstellen).Diese Schecks werden verwendet, um Wiedereintritts- und Blitzdarlehensangriffe zu verhindern, sind jedoch alles andere als ideal, da sie auch die Integration mit externen Protokollen behindern.Nach diesem EIP scheint selbst der zuverlässige Anforderungen (TX.ORIGIN == MSG.Sender) die Überprüfung veraltet zu sein.Das Protokoll muss angepasst werden, indem diese Schecks entfernt werden, da der Unterschied zwischen „EOA“ und „Vertrag“ nicht mehr gilt – jetzt gibt es für jede Adresse einen relevanten Code.

Die Trennung zwischen traditionellen EOA und intelligenten Verträgen ist weiterhin verschwommen.Dieser EIP bringt Ethereum näher an ein Design wie Ton, wobei jedes Konto im Wesentlichen ausführbarer Code ist.Wenn Interaktionen mit Protokollen komplexer werden, ist die Verwendung programmierbarer Logik zur Verbesserung der Endbenutzererfahrung ein natürlicher Prozess dieser Entwicklung.

abschließend

Das Upgrade von Prag /Electra (Pectra) ist für März 2025 geplant.Die wichtigsten Planänderungen sind:

• Variable -Verifier -gültige Einsätze bis zu 2048 ETH, was den Stakelverteilung, den Prüfplan erheblich verändert und das Management großer Beteiligungsanbieter durch Integration kleinerer Einsätze vereinfacht

• Verbessern Sie die Interaktion zwischen der Ausführungsschicht und der Konsensschicht und vereinfachen Sie den Datenaustausch zwischen dem ETH1 -Ausführungsblock und dem Beacon -Kettenblock.Dies vereinfacht Ablagerungen, Aktivierungen, Abhebungen und Ausgänge erheblich, beschleunigt diese Prozesse und basiert auf der weiteren Wechselwirkung zwischen der Konsensschicht und der Ausführungsschicht

• Unterstützung für billigere BLS-Signaturen und ZksNark-Überprüfung direkt mit neuen „pairfreundlichen“ BLS12-381-Vorkompilierung in Smart Contracts

• Ermutigen Sie Rollups, Blob -Transaktionen durch Erhöhen von Blob -Transaktions -Thresendern und die Erhöhung der CallData -Kosten anzunehmen

• Machen Sie EOA als programmierbares Konto und geben Ihnen mehrere Anrufe, Sponsoring und andere erweiterte Funktionen an

Wie Sie sehen können, hat Pectra einen erheblichen Einfluss auf die Endbenutzererfahrung der Einstellungs- und Konsensschicht sowie auf die Ausführungsschicht.Obwohl wir in dieser Phase nicht all diese Änderungen durch Code im Detail analysieren können, da die Entwicklung noch im Gange ist, werden wir diese Updates in zukünftigen Artikeln behandeln.