Originaltitel: „Ethereum Core Developer Meeting Update 014“

Originalquelle: AllCoreDevs Update

Ursprünglicher Autor: Tim Beiko

Ursprüngliche Zusammenstellung: Ethereum.cn

 

Willkommen zu einer neuen Ausgabe des AllCoreDevs-Updates (Ethereum Core Developer Conference) – der letzten von 2022.

 

Überblick

  1. Der Inhalt des Shanghai/Capella-Upgrades wurde fertiggestellt: Abhebungen, EOF und einige kleinere Änderungen ... sofern sie die Abhebungen nicht verzögern.

  2. Der Blob-Raum kommt: EIP-4844 wird im Mittelpunkt des nächsten Upgrades von Ethereum stehen, und seine Beschwörungszeremonie wird bald beginnen.

  3. Auf technischer Seite gibt es Bestrebungen, die Upgrade-Prozesse der Ausführungsschicht und der Konsensschicht zu koordinieren. Wir sehen auch aktive Diskussionen über eine bessere Einbindung von Community-Beiträgen in den Prozess.

  4. Die Protocol Guild hat einen mittelfristigen Pilotbericht und einen groben Plan veröffentlicht, um die Größe der First-Tier-Maintainer zu vergrößern und sie im Jahr 2023 besser zu unterstützen.

 

Shanghai/Capella-Upgrade

Bei einer kürzlichen AllCoreDevs-Veranstaltung erzielte das Kundenteam einen Konsens über den endgültigen Umfang des Shanghai/Capella-Upgrades. Während der Name des Upgrades möglicherweise zur Debatte steht, ist sich das Team über seinen Umfang im Klaren. Das Hauptmerkmal des Upgrades ist die Einführung von Beacon Chain-Abhebungen für Staker. Bei der schnellstmöglichen Einführung dieser Funktion möchte das Kundenteam keine Kompromisse eingehen. Daher müssen andere Funktionen des Upgrades gleichzeitig bereit sein, da sonst die Gefahr besteht, dass sie aufgegeben werden.

Die Shanghai Executive Layer Specification listet alle enthaltenen EIPs auf:

  1. EIP-3540: EVM Object Format (EOF) v1

  2. EIP-3651: Reduzieren Sie die Gaskosten für den Zugriff auf COINBASE-Adressen

  3. EIP-3670: EOF – Codeüberprüfung

  4. EIP-3855: Opcode PUSH 0 hinzugefügt

  5. EIP-3860: Initcode-Größe begrenzen und Gasmessung einführen

  6. EIP-4200: EOF – statischer relativer Sprung

  7. EIP-4750: EOF – Funktionen importieren

  8. EIP-4895: Push-Abhebungen der Beacon-Kette als Systembetrieb

  9. EIP-5450: EOF – Stapelverifizierung

Obwohl die Liste lang ist, lässt sie sich in drei verschiedene Teile unterteilen: kleinere Verbesserungen, EVM-Objektformate und Rücknahmen. Als nächstes stellen wir sie einzeln vor:

 

Kleinere Verbesserungen

EIP-3651: Warm COINBASE (Reduzieren Sie die Gaskosten für den Zugriff auf COINBASE-Adressen)

Diese EIP behebt ein Versehen in EIP-2929, bei dem die Gaskosten für den Zugriff auf bestimmte Datenfelder basierend darauf geändert wurden, ob sich die Daten bereits im Client-Speicher befanden (WARM) oder von der Festplatte abgerufen werden mussten (COLD).

EIP-2929 setzt zu Beginn jeder Transaktion zwei Daten im Client-Speicher auf WARM: die Sendeadresse und die Empfangsadresse. EIP-3651 fügt dieser Liste eine dritte Adresse hinzu, die COINBASE-Adresse (d. h. feeRecipient), da es sich auch um die Adresse handelt, die der Client bei der Verarbeitung von Blocktransaktionen im Speicher hat.

 

EIP-3855: PUSH 0-Anweisung (neuer Opcode „PUSH 0“)

Wie der Name schon sagt, führt EIP-3855 einen Opcode ein, der einen Wert von 0 auf den Stapel legt. Das Schieben von Nullen wird häufig zum Füllen von Werten im EVM verwendet. Dieser Opcode bietet eine effizientere und kostengünstigere Möglichkeit, dies zu tun.

 

EIP-3860: Initcode begrenzen und messen (Größe des Initcodes begrenzen und Gasmessung einführen)

Dieses EIP fügt eine Obergrenze für die Größe des Initcodes hinzu und führt eine Gasmessung basierend auf seiner Länge ein. Seine obere Größenbeschränkung fügt dem EVM eine Invariante hinzu, was das Verständnis und das Vorschlagen von Änderungen erleichtert.

Führt einen Overhead von 2 Gas pro 32 Byte für Initcode ein, der zur Bezahlung der Jumpdest-Analyse verwendet wird, die der Client vor der Ausführung durchführen muss und die nicht im Gaszähler aufgeführt ist.

 

Objektformat

Der größte Teil des im Shanghai-Upgrade enthaltenen EIP ist tatsächlich Teil einer einzigen Funktion: dem EVM Object Format (EOF). Die Arbeit wurde in fünf verschiedene EIPs unterteilt, um den Client-Entwicklern das Verständnis jeder einzelnen Änderung zu erleichtern. Um jedoch einen Überblick auf höherer Ebene zu bieten, veröffentlichten die Entwickler eine einheitliche Spezifikation. Die EIPs dieser fünf EOFs sind:

  1. EIP-3540: EVM-Objektformat Version 1

  2. EIP-3670: EOF – Codeüberprüfung

  3. EIP-4200: EOF – statischer relativer Sprung

  4. EIP-4750: EOF – Funktionen importieren

  5. EIP-5450: EOF – Stapelverifizierung

Es ist erwähnenswert, dass der erste Schritt von EOF das Londoner Upgrade EIP-3541 war, das das Präfix 0xEF 00 für den EOF-Vertrag reservierte. Auch der EOF-Umfang des Shanghai-Upgrades hat sich in den letzten Monaten geändert.

Im Februar einigte sich das Kundenteam darauf, eine Modernisierung in Shanghai in Betracht zu ziehen, um die beiden kleinsten EOF-EIPs aufzunehmen: EIPs 3540 und 3670. Sie dienen alle als Bausteine, bieten aber ohne die Einführung von EIP 4200, 4750 und 5450 nicht die volle Funktionalität. Obwohl es möglich ist, EOF zu erweitern, erfordert die Abwärtsinkompatibilität möglicherweise eine neue Version. Da Pre-EOF- oder EOF-Verträge mit einer bestimmten Version immer ausführbar sein müssen, bedeutet jede neue EOF-Version, dass Client-Entwickler einen neuen Satz EVM-Ausführungsregeln parallel zu den alten Regeln pflegen müssen.

Vor EOF verwalteten Clients jeweils nur einen Satz EVM-Regeln. Die Codebasis unterstützt auch frühere EVM-Regeln, die bei jedem Netzwerk-Upgrade geändert werden. Sobald sie jedoch den Kopf der Blockchain erreichen, müssen nur noch die neuesten Regeln angewendet werden. Nach der Bereitstellung von EOF verwaltet der Client zwei parallele Sätze von EVM-Regeln, sodass er Code in EOF- und Nicht-EOF-Verträgen ausführen kann. Mit anderen Worten: Je mehr EOF-Versionen es gibt, desto mehr parallele statt aufeinanderfolgende EVM-Regelsätze müssen beibehalten werden.

Zu diesem Zweck haben Kundenteams in den letzten Monaten begonnen, einen „großen EOF“-Ansatz zu bevorzugen. Obwohl sie größere Modifikationssätze implementieren müssen, hält die EOF-Version auf diese Weise länger und reduziert die Anzahl der „parallelen EVMs“, die gewartet werden müssen. Daher dachten die Entwickler über „großes EOF“ nach und schlossen es schließlich in das Shanghai-Upgrade ein.

Allerdings sind größere Funktionen offensichtlich schwieriger zu implementieren und zu testen, und das Team möchte nicht, dass EOF die Abhebungen von Beacon-Ketten erheblich verzögert. Wenn die Implementierung von EOF bis Januar noch nicht abgeschlossen ist und die Zusammenarbeit nicht schnell untereinander möglich ist, stimmt das Kundenteam daher zu, EOF zur Aktualisierung aus Shanghai zu verlegen.

 

Unter Berücksichtigung dieser Zusammenhänge wollen wir nun jedes EOF-EIP kurz vorstellen:

EIP-3540: EVM Object Format (EOF) v1 (EVM Object Format Version 1)

Dieses EIP führt „Container“ in den EOF-Vertrag ein. Es fügt Tags hinzu, um die Code- und Datenteile des Vertrags zu unterscheiden, und verhindert die Bereitstellung von EOF-Verträgen, die nicht dem Format entsprechen. Dies garantiert, dass jeder EOF-Vertrag in der Kette einem gültigen Format folgt, was die Interaktion mit diesen Verträgen sowie deren statische Analyse vereinfacht.

 

EIP-3670: EOF – Codevalidierung (EOF – Codevalidierung)

Aufbauend auf dem von 3540 eingeführten Container stellt EIP-3670 sicher, dass der Code im EOF-Vertrag gültig ist oder verhindert, dass er bereitgestellt wird.

Das bedeutet, dass undefinierte Opcodes nicht in EOF-Verträgen eingesetzt werden können, was den zusätzlichen Vorteil hat, dass die Anzahl der hinzuzufügenden EOF-Versionen reduziert wird. Wenn ein neuer Opcode hinzugefügt wird, können die Validierungsregeln einfach geändert werden, um ihn zu aktivieren und sicherzustellen, dass kein bereitgestellter EOF-Vertrag in seinem Codeabschnitt darauf verweist.

 

EIP-4200: EOF – Statische relative Sprünge (EOF – Statische relative Sprünge)

EIP-4200 führt die ersten EOF-spezifischen Opcodes ein: RJUMP, RJUMPI und RJUMPV, die Ziele als vorzeichenbehaftete Sofortwerte kodieren. Diese neuen JUMP-Opcodes können von Compilern zur Optimierung des Gas-Overheads verwendet werden, da sie die Notwendigkeit einer Jumpdest-Analyse zur Laufzeit überflüssig machen, die bei den vorhandenen JUMP- und JUMPI-Opcodes erforderlich ist.

 

EIP-4750: EOF – Funktionen (von EOF eingeführte Funktionen)

EIP-4750 geht einen Schritt weiter als 4200: Es verbietet die Verwendung von JUMP- und JUMPI-Opcodes und fügt Alternativen für Funktionen hinzu, die nicht kopiert werden können. Dies wird durch die Einführung spezifischer Funktionsabschnitte im EOF-Bytecode implementiert. Diese Funktionen können von den neuen JUMPF-, CALLF- und RETF-Opcodes springen und diese zum Aufrufen und Zurückkehren verwenden.

 

EIP-5450: EOF – Stack-Validierung (EOF-Stack-Validierung)

Schließlich fügt EIP-5450 eine weitere Validierungsprüfung für EOF-Verträge hinzu, diesmal rund um den Stack. Diese EIP verhindert, dass EOF-Verträge Code bereitstellen, der zu einem Stapelunterlauf und in einigen Fällen zu einem Stapelüberlauf führen kann. Mit diesem EIP können Kunden die Anzahl der Validierungsprüfungen bei der Ausführung von EOF-Verträgen reduzieren, da sie bessere Garantien für Stack-bezogene Ausnahmen haben.

Als Nicht-EVM-Experte, der sich sehr auf EIP selbst konzentriert, kann ich dazu nicht viel sagen! Wenn Leser mehr über EOF erfahren möchten, empfehle ich die entsprechenden Tweets von Lightclients vom Geth-Team und Leo vom Solidity-Team.

 

Auszahlung der Beacon-Kette

Zu guter Letzt ist der Hauptteil von „Shapella“ (Anmerkung des Übersetzers: der Sammelname von Shanghai/Capella) der Rückzug der Beacon-Kette. Dieser Teil der Änderung ist in der Consensus-Layer-Spezifikation und EIP-4895 beschrieben. Mittlerweile gibt es eine etwas veraltete Metaspezifikation, die diese Änderungen miteinander verknüpft.

Auf hohem Niveau sind die Abhebungsmechanismen wie folgt:

Beim Vorschlagen eines Blocks durchsucht der Validator linear den Validatorindex, um die ersten 16 Validatoren mit 0x01-Anmeldeinformationen zu finden, die eine der folgenden Bedingungen erfüllen müssen:

  1. Sie müssen ein Guthaben von über 32 ETH haben (d. h. Sie haben Validator-Belohnungen angesammelt)

  2. Sind auszahlbar (d. h. haben den Validator-Satz vollständig verlassen)

Der Saldo ist größer als 32 ETH (d. h. die Validator-Belohnung wurde erhalten)

Es ist ausziehbar (ausziehbar, d. h. es hat den Validatorsatz vollständig verlassen)

Daraus erstellt der Validierer eine Liste mit Abhebungen, die in seine ExecutionPayload aufgenommen werden sollen. Jedes Element in dieser Liste enthält Folgendes:

Der Validator erstellt aus diesen Validatoren eine Auszahlungsliste und packt sie in ihre ExecutionPayload. Jedes Element in der Liste enthält Folgendes:

  1. WithdrawalIndex: Index aller getätigten Auszahlungstransaktionen – dies hilft dabei, Auszahlungen desselben Betrags von derselben Adresse und demselben Prüfer zu unterscheiden

  2. ValidatorIndex: der Validator-Index, an dem der Saldo erhöht wurde

  3. ExecutionAddress: Die ETH-Adresse der Ausführungsschicht, an die Auszahlungen gesendet werden sollen

  4. Betrag: Der an ExecutionAddress gesendete Betrag. Dieser Betrag wird in Gwei gemessen (nicht in Wei).

Clients der Ausführungsschicht nehmen diese Abhebungen vor, nachdem Transaktionen beim Erstellen oder Verarbeiten von Blöcken ausgeführt wurden. Mit anderen Worten: Abhebungen werden auf ähnliche Weise wie die Protokollierung von Proof-of-Work-Belohnungen verarbeitet und konkurrieren nicht mit Benutzertransaktionen um Blockplatz.

Es gibt noch einige weitere erwähnenswerte Details:

  1. Bei der Bearbeitung von Auszahlungen gibt es keinen Unterschied in der Priorität/Reihenfolge zwischen „Vollguthaben“ und „Teilguthaben“. Vollständige Abhebungen erfolgen, wenn ein Validator das Exit-Team verlässt, während teilweise Abhebungen in regelmäßigen Abständen erfolgen, d. h. wenn ein linearer Scan des Validator-Sets durchgeführt und die Indexnummer eines bestimmten Validators gescannt wird.

  2. Damit Abhebungen verarbeitet werden können, müssen Validatoren 0x01-Anmeldeinformationen verwenden, die durch ETH-Adressen dargestellt werden. Wenn die Beacon-Kette online geht, sind nur Anmeldeinformationen des BLS-Schlüsselpaars 0x00 zulässig. Um eine Auszahlung einzuleiten, muss ein Validator mit 0x00-Anmeldeinformationen eine BLSToExecutionChange-Nachricht signieren. Diese werden im Capella-Upgrade aktiviert. Zum Signieren dieser Nachricht werden verschiedene Tools verwendet, und Validatoren können Unterstützung und Tutorials für diese Tools erwarten.

  3. Das Scannen von Validatoren erfolgt pro Block. Wenn nach dem Scannen einer Teilmenge des Prüfersatzes keine 16 Abhebungen zu verarbeiten sind, stoppt der Prüfer den Scanvorgang und der nächste Prüfer beginnt mit dem zuletzt gescannten Prüferindex.

Wie üblich wird es mehrere Entwickler-Testnetze und Testnetze (vielleicht sogar einige neue Testnetze!) geben, damit Validatoren den gesamten Prozess ausführen und etwaige Probleme beheben können, bevor das Hauptnetz in Betrieb geht.

Shanghai/Capella ist nicht das einzige Upgrade, das Fortschritte macht! Das Entwicklerteam freut sich immer noch auf das nächste Upgrade.

 

Cancun-Upgrade

Da der Inhalt des Shanghai-Upgrades bereits vollständig ist, konnten viele EIPs (CFI), die für das Upgrade in Betracht gezogen wurden, nicht am Shanghai-Upgrade teilnehmen. Das Kundenteam beginnt mit der Diskussion darüber, welche EIPs für das nächste Upgrade in Betracht gezogen werden sollten: das Cancun-Upgrade (Name der Konsensschicht wird noch festgelegt)

Was die Konsensschicht betrifft, ist EIP-4844 das erste EIP, das nach dem Capella-Upgrade in die Spezifikation aufgenommen wurde. Es gibt (noch) keine Spezifikation für die Führungsebene, die dieses Layout implementieren kann, aber das Team der Führungsebene stimmte zu, einen ähnlichen Weg zu gehen und EIP-4844 beim nächsten Upgrade in den Mittelpunkt zu stellen.

Der Konvention folgend, bei Upgrades die Namen der Städte zu verwenden, in denen Devcon stattfand, wurde cancun.md erstellt, wobei EIP-4844 offiziell in das Upgrade einbezogen wurde.

Diese Entscheidung fiel in letzter Minute des letzten AllCoreDevs-Treffens im Jahr 2022, sodass keine Zeit blieb, an anderen Vorschlägen zu arbeiten. Die EIPs, die am CFI-Upgrade in Shanghai teilnahmen, aber am Ende nicht aufgenommen wurden, wurden auf die CFI-Liste für das Cancun-Upgrade verschoben. Im Ethereum Magicians-Forum wurde auch ein Beitrag zur Diskussion der EIP-Kandidaten in Cancun eröffnet. Die Diskussionen über den Umfang der Modernisierungen in Cancun sollten Anfang nächsten Jahres ernsthaft beginnen.

 

KZG-Zeremonie

Eine weitere Sache, auf die Sie sich im Zusammenhang mit dem Cancun-Upgrade freuen können, ist die KZG-Zeremonie, die eine Anforderung von EIP-4844 ist.

Dieses Ritual erzeugt die nötige Zufälligkeit, um die Gültigkeit der Blob-Daten zu überprüfen. Damit es als sicher gilt, muss nur ein Teilnehmer ehrlich sein. Mit anderen Worten: Wenn alle bis auf einen Teilnehmer zusammenarbeiten, ist der gesamte Prozess kryptografisch sicher.

Die Zeremonie beginnt im Januar und wird mehrere Monate lang für jedermann zugänglich sein. Mit einem Ziel von 10.000 Teilnehmern soll es die bisher größte Zeremonie dieser Art werden! Wenn Sie sicherstellen möchten, dass Sie nichts verpassen, folgen Sie Trent Van Epps auf Twitter!

 

Upgrade-Prozess nach der Fusion

Wie im vorherigen Update erwähnt, ist nach der Fusion die Koordinierung des Ethereum-Upgrade-Prozesses auf der Ausführungsebene und der Konsensebene eine wichtige Aufgabe. Aus einer übergeordneten Perspektive verwendet die Ausführungsschicht Yellow Paper und EIP, um Änderungen zu beschreiben, während die Konsensschicht ausführbare Python-Spezifikationen verwendet.

Der Vorteil des Prozesses auf der Führungsebene besteht darin, dass die EIP der Community bekannt ist und so formatiert ist, dass die Argumentation hinter dem Vorschlag klar zum Ausdruck kommt. Gelbe Bücher mit vielen mathematischen Inhalten gepaart mit EIPs und die Notwendigkeit, die Spezifikationen wieder in den Kontext jedes EIP zu stellen, machen es schwierig, die Spezifikationen der Ausführungsschicht zu verstehen und zu erweitern.

Das Problem mit der Konsensschicht ist das Gegenteil: Sie verfügt über eine klare und verständliche Spezifikation in einem einzigen Repository, aber Änderungen sind nicht greifbar und die Vorschläge sind in anderen öffentlichen PRs im Repository vergraben.

Mit der Einführung der Spezifikation der Ethereum-Ausführungsschicht hoffen wir, diese Lücke auf der Seite der Ausführungsschicht schließen zu können. Und mit einigem Hin und Her im Prozess gelingt es uns möglicherweise, EIP in den Prozess der Konsensschicht einzuführen!

Als jedoch der Umfang des Shanghai-Upgrades besprochen und finalisiert wurde, wurde klar, dass ein weiterer Teil des Prozesses fehlen könnte: der Community die Möglichkeit zu geben, ihre relativen Präferenzen für Änderungen zu äußern und sich an Diskussionen über den gesamten Upgrade-Umfang zu beteiligen (statt …). (einzelne EIPs) Besprechen Sie dies vor Ort und machen Sie es zu einem Teil der AllCoreDevs- und Konsensschicht-Meetingentscheidungen.

Es ist noch nicht klar, wie das aussehen wird – ich würde mich über Vorschläge freuen! – Aber als die Zahl der Stakeholder, die sich aktiv an Protokolländerungen beteiligten, sowie die Zahl der Bereiche, die von Schicht-1-Änderungen betroffen waren, zunahm, war klar, dass wir etwas brauchten.

Glücklicherweise müssen wir nicht bei Null anfangen. Ethereum Magicians gibt es schon seit Jahren und seine Offline-Treffen, speziellen Gruppentreffen oder Community-Treffen könnten gute Ausgangspunkte für die Expansion sein.

Erwarten Sie Anfang 2023 weitere Fortschritte an dieser Front!

 

Update der Vereinbarungsgilde

Da das Pilotprojekt der Protocol Guild (PG) nun zur Hälfte abgeschlossen ist, haben sie einen Bericht veröffentlicht, um einen Blick auf den Stand der Dinge zu werfen und die nächsten Schritte für das Projekt zu prüfen.

 

Zur Erinnerung: PG ist ein erlaubnisfreier Finanzierungsmechanismus für Ethereum Layer 1-Client-Entwickler, Protokollforscher und unterstützende Mitwirkende (wie Sie).

Dieser Mechanismus konzentriert sich auf den Einzelnen, nicht auf die Organisation. Kurz gesagt, jedes Mitglied hat Anspruch auf einen Anteil an den Token der Gilde, gewichtet danach, wie lange es zu Ethereum beigetragen hat. Das Hinzufügen und Löschen von Mitgliedern erfolgt auf echte Ethereum-Art – basierend auf einer Reihe von Standards und einem groben Konsens innerhalb von PG. Diese Liste wird dann mithilfe des 0xSplit-Split-Vertrags in die Kette gestellt. Der Spender kann dann Gelder direkt an die Adresse des Empfängers senden oder einen Vesting-Vertrag abschließen, der Gelder an die Adresse des Empfängers freigibt.

Der Zwischenbericht des Piloten ist in diesem Tweet zusammengefasst. Hier sind einige Highlights

Das Pilotprojekt sammelte 9,7 Millionen US-Dollar von Organisationen wie Lido, Uniswap, ENS, NounsDAO und MolochDAO sowie regelmäßigen Spendern von Einzelpersonen (danke Tetranode!) – vielen Dank an alle, die dies möglich gemacht haben!

PG hatte beim Start 90 Mitglieder und hat jetzt 128, wobei 5 Millionen US-Dollar an sie verteilt wurden

Im Durchschnitt erhielt jedes Mitglied 39.000 US-Dollar, wobei der niedrigste Betrag 13.000 US-Dollar und der höchste 79.000 US-Dollar betrug

Die Architektur von PG ändert sich und wird L2 unterstützen und die Notwendigkeit von Mehrfachsignaturen zur Aktualisierung von Gewichten überflüssig machen

Diese ersten Ergebnisse zeigen, dass PG wie geplant funktioniert: ein Mechanismus zur Verteilung eines Korbs mit Token an eine selbstbrütende, wachsende Gruppe von Protokollmitwirkenden. Ohne die großzügige Unterstützung von Pilotspendern wäre dieses Projekt nicht das, was es heute ist.

Mit Blick auf die Zukunft ist es jetzt an der Zeit, die Reichweite von PG zu erweitern und sein volles Potenzial auszuschöpfen: den Ethereum-Betreuern eine wettbewerbsfähige, risikoangepasste Vergütung zu bieten. Am einfachsten ist es, wenn das Projekt von Anfang an an PG spendet, wie Danny Ryan in dem Tweet zur Einführung von PG sagte.

Die meisten Spenden im Pilotprojekt stammten von Großprojekten mit hohen Fördersummen. Wenn die Protocol Guild diese Projekte davon überzeugen kann, vom ersten Tag an an PG zu spenden, wenn ihre Token noch wirklich „wertlos“ sind, können die Betreuer von Ethereum von der gesamten Aufwärtsentwicklung dieser erfolgreichen Projekte profitieren.

Wenn genügend Projekte beteiligt sind, können Anreize dafür sorgen, dass die besten Talente im Rahmen von Wartungsverträgen gehalten werden, anstatt sie abzuziehen.

Um diese und viele andere Spendenarten zu unterstützen, muss PG technologisch überarbeitet werden. Die nächste Version wird L1 und L2 unterstützen und den On-Chain-Governance-Fußabdruck weiter reduzieren.

Wenn Sie ein Projekt sind, das an die Protocol Guild spenden möchte, kontaktieren Sie mich bitte – meine DMs sind offen!

 

Nachverfolgen

Damit endet das Jahr 2022... Was für ein außergewöhnliches Jahr! Vor drei Monaten wurden wir noch nicht einmal fusioniert! Da bei Ethereum nun der Proof of Stake im Hintergrund läuft, hat sich der Fokus auf zukünftige Transaktionen verlagert.

Da alle im Januar zurückkehren, können Sie Folgendes erwarten:

  1. Shanghai/Capella hat das Entwickler-Testnetz und den Shadow Fork aktualisiert

  2. KZG-Zeremonie geht online

  3. Diskussionen rund um Cancun und wie sich der Netzwerk-Upgrade-Prozess weiterentwickeln sollte, um die Vorlieben der Community besser zu berücksichtigen

Das Pilotprojekt der Protokollgilde endet und wir werden die Struktur nach dem Pilotprojekt bekannt geben.