Die All-Core-Developer-Aufrufe von Ethereum sind eine Menge, mit denen man Schritt halten muss, daher „KontrollpunktDie „Serie“ zielt darauf ab, etwa alle 4 bis 8 Wochen High-Level-Updates durchzuführen, je nachdem, was in der Kernentwicklung passiert. Sehen Sie sich das vorherige Update an Hier.
Wenn Sie gerne wichtige Entwicklungsaktualisierungen lesen, möchten Sie vielleicht jetzt auch mehr über Forkcast erfahren veröffentlicht Anrufzusammenfassungen, Chats und Transkripte für jeden All Core Dev (ACD)-Anruf und einige Breakout-Anrufe, normalerweise innerhalb weniger Stunden nach dem Anruf verfügbar.
tl;dr:
Der Gesichts-Upgrade Wird zusammen mit der Möglichkeit zur Anpassung geliefert Klecks Parameter unabhängig aus Gabelzyklen. Das nächste Upgrade, Glamsterdamist vollständig umfangreich und die Fortschritte sind im Gange, während die Hauptfunktion(en) des folgenden Upgrades, Hegotasind jetzt vorgeschlagenmit einer Vorschlagsfrist bis zum 4. Februar.
Gesicht
Seit dem letzten Checkpoint ist das Fusaka-Upgrade live gegangen und hat eine Skalierung in Form von gebracht Datenverfügbarkeitsstichprobe zu Ethereum.
Sowohl @ethereum als auch Vitalik nutzten Twitter, um dies zu tun PeerDAS erklärenWarum Sichere Skalierung ist wichtigUnd wie diese Verbesserungen passen im größeren Schema der Dinge.
BPO-Gabeln
Blob-Parameter-Only-Forks sind jetzt Realität – Ethereum kann nun die Blob-Anzahl erhöhen und hat dies bereits getan, ohne einen gesamten Fork-Zyklus abwarten zu müssen, und skaliert je nach Bedarf für die L2-Nutzung. Die ersten beiden BPO-Forks wurden erfolgreich einem Stresstest unterzogen und in Fusaka integriert, wobei der erste einige Tage nach Fusaka und der zweite Anfang Januar in Betrieb ging. Ethereum strebt nun 14 Blobs pro Block an und erlaubt maximal 21 – eine 2,3-fache Steigerung des L2-Datenraums im Vergleich zu vor Fusaka!
Die Entwickler sprachen darüber, was erforderlich ist, um für einen dritten BPO-Fork bereit zu sein, waren sich jedoch einig, dass dies keine Priorität hat, bis die Blob-Nutzung zunimmt, um die bestehenden Steigerungen nutzen zu können.
Glamsterdam
Die Fortschritte bei Glamsterdams beiden Hauptdarstellern, der Enshrined Proposer Builder Separation (ePBS) und Block-Level Access Lists (BALs), schreiten voran, aber ePBS ist eine viel komplexere Änderung als BALs, während letztere dies bereits getan haben Devnetses wird etwas länger dauern, bis wir ein Entwicklungsnetz für ePBS sehen.
Zeitleiste
Wie bei jedem Fork müssen die Headliner an einen stabilen Platz auf den Devnets gebracht werden, bevor mit dem Hinzufügen von Variablen in Form weiterer EIPs begonnen wird. Da die Entwickler die Liste der vorgeschlagenen, nicht im Vordergrund stehenden Funktionen endlich von 50 auf einen überschaubareren Satz von 17 notwendigen und wirkungsvollen Funktionen reduziert haben, werden sie diese Funktionen in kleinen Gruppen zu den Devnets hinzufügen, bis der Fork fertig ist. Wenn sich einige als problematisch erweisen oder zu einer zu starken Verzögerung der gesamten Abzweigung führen könnten, könnten sie sich dafür entscheiden, sie aus der Gruppe „In Betracht gezogen“ zu entfernen. Die vollständige Liste von Berücksichtigt Funktionen sind:
- EIP-2780: Intrinsisches Transaktionsgas reduzieren
- EIP-7688: Vorwärtskompatible Konsensdatenstrukturen
- EIP-7708: ETH-Transfers geben ein Protokoll aus
- EIP-7778: Gasabrechnung ohne Rückerstattung sperren
- EIP-7843: SLOTNUM-Opcode
- EIP-7904: Allgemeine Preisanpassung
- EIP-7954: Maximale Vertragsgröße erhöhen
- EIP-7976: Erhöhen Sie die Grundkosten für Anrufdaten
- EIP-7981: Erhöhen Sie die Kosten für die Zugriffsliste
- EIP-7997: Deterministische Factory-Vorbereitung
- EIP-8024: Abwärtskompatibel SWAPN, DUPN, EXCHANGE
- EIP-8037: Erhöhung der Gaskosten für die staatliche Schaffung
- EIP-8038: Erhöhung der Gaskosten für den staatlichen Zugang
- EIP-8045: Gekürzte Validatoren vom Vorschlag ausschließen
- EIP-8061: Erhöhen Sie die Ausstiegs- und Konsolidierungsfluktuation
- EIP-8070: Spärlicher Blobpool
- EIP-8080: Exits die Konsolidierungswarteschlange verwenden lassen
Erwarten Sie einen besseren Zeitplan, sobald wir ein stabiles erstes ePBS-Devnet haben, und dann noch mehr Klarheit, sobald jedes EIP in einem Devnet getestet wurde.
Hegotha
Eine kurze Anmerkung zur Namensänderung: Der ursprüngliche H-Star-Name, Heka, wurde danach durch Heze ersetzt bemerkte ein Community-Entwickler dass „Heka“ nicht im Katalog der International Astronomers Union steht, wie alle bisher gewählten Sternnamen. Der Gabelname ist Heze + Bogotá: Hegotá.
FOCILL
Fork-Choice-Inclusion-Lists (FOCIL), ein Mechanismus zur Zensurresistenz, wurde aus Glamsterdam verlegt, um den Umfang der Fork einzuschränken. Aufgrund seiner starken Unterstützung unter Kernentwicklern und der allgemeinen Ethereum-Community wurde es für Hegotá in den Status „Berücksichtigt“ verschoben und wird zusammen mit allen anderen Headliner-Vorschlägen bewertet – zum Zeitpunkt dieses Beitrags gibt es nur solche ein konkurrierender Vorschlag.
Sehen Sie sich einen Überblick über FOCIL und seine Bereitschaft für Hegotá an Hier.
Zeitleiste
Jeder kann Schlagen Sie ein Headliner-Feature vor für Hegotá vor Ablauf der Frist am 4. Februar die Vorlage im Ethereum Magicians-Forum.
Die Vorschläge werden dann vom Antragsteller in ACD-Aufrufen vorgestellt und um Feedback aus der Community gebeten. Ziel ist es, bis zum 26. Februar über die Hauptbeiträge von Hegota zu entscheiden. Nach dieser Entscheidung können kleinere (nicht schlagzeilenträchtige) Features vorgeschlagen werden – es wird eine Frist für diese Vorschläge gegeben, also halten Sie sich unbedingt über Checkpoint auf dem Laufenden. Wie bei den Headliner-Vorschlägen kann auch jeder einen Nicht-Headliner vorschlagen – er sollte nur dazu bereit sein sehe es durch.
8. Januar – 4. Februar: Headliner-Vorschläge [ NOW ]
5. Februar – 26. Februar: Diskussion und Finalisierung des Headliners
30 Tage nach Headliner-Entscheidung, Frist wird noch bekannt gegeben: Nicht-Headliner-EIP-Vorschläge
Verfahren
Wenn Sie sich jemals gefragt haben, wie eine Person ein gewünschtes Feature in Ethereum bekommt, gibt es einen Leitfaden von 2026, wie man ein Feature in einen Fork einfügt Hier. Eine vorgeschlagene Funktion für Ethereum, genannt Ethereum Improvement Proposal (EIP), wird zunächst anhand des allerersten EIP als Leitfaden spezifiziert: EIP-1dann während eines bestimmten Zeitfensters vorgeschlagen und von einem technischen Ansprechpartner im gesamten Prozess begleitet.
Es war ein absolutes Biest, die 50 vorgeschlagenen Nicht-Headliner-Features für Glamsterdam durchzuarbeiten, und jeder spürte es. Dass dieser Fork so viele Vorschläge hat, könnte das Ergebnis einer größeren Anzahl von High-Context-Teilnehmern oder ein Ergebnis davon sein, dass der Prozess etwas klarer ist – das wissen die Entwickler jetzt Wann Und Wie ihre Eigenschaften vorzuschlagen. Da es sich bei den Kunden- und Testteams um die tatsächliche Umsetzung dieser Änderungen handelt, müssen sie sich mit den Vorschlägen vertraut machen und Empfehlungen zu den dringendsten und wirkungsvollsten Änderungen aussprechen – 50 Spezifikationen durchzugehen, um fundierte Empfehlungen abzugeben, ist eine Menge Hausaufgaben!
Ich gehe davon aus, dass weitere Hegotá-Headliner-Vorschläge mit FOCIL und verschlüsselten Mempools konkurrieren werden. FOCIL ist ein schichtübergreifendes EIP, das heißt, es betrifft sowohl die Konsens- als auch die Ausführungsschicht und insbesondere die Engine-API, was die Kombination mit einer anderen komplexen Funktionsänderung etwas kompliziert macht. Es gab einige Gespräche 6-Sekunden-Slots aber es ist unklar, ob es für Hegotá vorgeschlagen wird oder auf I-Star wartet. Welches Hauptmerkmal Sie auch bevorzugen, ich empfehle Ihnen, während der Diskussionsphase im Februar aktiv Ihre Unterstützung dafür zu zeigen.
Relevante ACD-Anrufe:
[ November 14th – January 19th ]
