Letzte Woche versammelten sich etwas mehr als 100 Ethereum-Kernmitwirkende nördlich des Polarkreises – in Longyearbyen, Spitzbergen – zur Soldøgn Interop: einer Woche intensiver Arbeit am Glamsterdam-Netzwerk-Upgrade.
Soldøgn folgte auf die letztjährige Berlinterop, kehrte aber zu dem Format zurück, das bei Amphora 🏺, Edelweiss 🏔️ und Nyota ✨ verwendet wurde: eine einspurige Woche mit fokussiertem, Multi-Client-Fortschritt in Richtung eines spezifischen Upgrades – in diesem Fall der Härtung von Glamsterdam.
Bis Freitag hatte die Gruppe ihre drei Hauptziele erreicht: Einigung auf eine Untergrenze für das Gaslimit nach Glamsterdam von 200M, stabile ePBS-Implementierungen, die mit externen Erstellern laufen, und die Festlegung der endgültigen EIP-8037-Repricing-Zahlen. Auch bei Hegotá-Funktionen wie FOCIL und nativer Kontoabstraktion sowie einer Reihe anderer Themen wurden bedeutende Fortschritte erzielt.
Warum Spitzbergen?
Spitzbergen ist einer der wenigen Orte auf der Erde, an dem jeder, unabhängig von seiner Nationalität, ohne Visum leben und arbeiten kann. Es beherbergt auch den Global Seed Vault und das Arctic World Archive, zwei Kühllager, die in den Permafrost außerhalb von Longyearbyen gegraben wurden. Zusammen bewahren sie Backups von Nutzpflanzen, Büchern, Filmen, Manuskripten und Quellcode auf, die die Menschheit in tausend Jahren benötigen könnte, einschließlich eines Snapshots des Ethereum-Quellcodes. Nicht zuletzt geht die Sonne in Spitzbergen von Ende April bis August nicht unter. Es hat eine 24/7-Verfügbarkeit, genau wie Ethereum, was die Kernentwickler während der Woche voll ausnutzten!
Glamsterdam härten, Ethereum skalieren
Das Ziel der Woche war es, die Glamsterdam-Implementierungen zu härten und ein Ziel für eine Gaslimit-Untergrenze nach dem Upgrade abzuleiten. Das sichere Anheben des Gaslimits ist ein mehrdimensionales Problem, und Glamsterdam geht mehrere davon an: wie Blöcke erstellt und vorgeschlagen werden, wie viel Spielraum Client-Implementierungen unter Last haben und wie die Kosten für die Zustandserstellung mit dem Transaktionsdurchsatz skalieren.
In der Praxis bedeutete das, die Woche mit einem stabilen Multi-Client-Glamsterdam-Devnet zu beenden, auf dem die neuesten Spezifikationen für ePBS, Repricing und Block-Zugriffslisten laufen, zusammen mit Benchmarking-Daten, um einen glaubwürdigen Gaslimit-Vorschlag zu untermauern.
Die meiste Zeit wurde hochkonzentriert mit dem Schreiben von Code verbracht, oft bis in die frühen Morgenstunden, unterbrochen von Breakout-Sessions, um sich über Designentscheidungen abzustimmen und längerfristige Roadmap-Punkte zu diskutieren.
Drei EF-Teams stellten die Infrastruktur für die Woche bereit: EthPandaOps lieferte ethIQ und einen panda MCP-Server, um die agentenbasierten Workflows der Teams zu unterstützen; Protocol Support richtete soldogn.xyz als zentrale Anlaufstelle für Interop-Ziele, Zeitpläne und Notizen ein; und das EF Digital Studio-Team hielt die Woche auf Film fest. Freut euch auf die allererste Interop-Dokumentation 🔜!
ePBS
Neben der Bereinigung der Beziehung zwischen Proposer und Ersteller strukturiert ePBS die Slots neu, indem Fristen für die Block-Erstellung, die Offenlegung der Payload und Attestierungen hinzugefügt werden. Dies macht deutlich, wie viel Zeit für die Ausführung zugewiesen werden kann, was unseren Spielraum zur Erhöhung des Gaslimits vergrößert.
Die Teams begannen die Woche mit dem Ziel, bis Montagabend ein 4 EL × 4 CL Glamsterdam-Devnet bereitzustellen. Die ersten Versuche brachten genügend Probleme zutage, um das Ziel auf Dienstag zu verschieben, als eine 4×3-Konfiguration stabil genug lief, um mit Stresstests zu beginnen.
Von da an war der Rest der Woche ein ePBS-Härtungszyklus: Stresstests, Aufdecken von Randfällen, Beheben, Wiederholen. Eine Breakout-Session zur Ersteller-API am Dienstagmorgen vereinfachte die Spezifikation rund um die Validator-Registrierung, den Ablauf von Geboten/Headern/Commitments, das Vertrauensmodell für Ersteller-Zahlungen und das Circuit-Breaker-Verhalten erheblich. Das Debugging zur Wochenmitte konzentrierte sich auf clientübergreifende Randfälle – insbesondere im Zusammenhang mit der Ungültigmachung von Beacon-Anfragen durch Ausführungsanfragen, wo eine neue Testsuite eine Lücke in jeder Client-Implementierung aufdeckte. Bis Donnerstagmorgen meldeten die CL-Teams ein stabiles ePBS, während die Gebotswege auf der EL-Seite noch debuggt wurden; diese wurden von Donnerstag bis Freitag gelöst. Zwei Fragen bleiben für ACD wirklich umstritten: ob eine Anfrage-Signatur an den empfangenden Ersteller binden sollte und wie ein Design mit 1 ETH-gestakten Erstellern widerstandsfähig gegen P2P-Sybil-basierte Liveness-Angriffe gehalten werden kann.
Bis Freitag liefen fast alle Clients zusammen auf glamsterdam-devnet-2, wobei die Pipeline für externe Ersteller durchgängig getestet wurde!
BAL-Optimierungen
Wenn ePBS die Seite der Konsens-Schicht in der Glamsterdam-Skalierungsgeschichte ist, hat das Gegenstück auf der Ausführungsschicht zwei dominierende Teile: Gas-Repricings und Block-Level Access Lists (Zugriffslisten auf Blockebene). Indem sie Clients im Voraus genügend Informationen über das Lese-/Schreib-Set eines Blocks geben, ermöglichen BALs parallele Ausführung, gebündelte I/O und parallele Zustandswurzel-Berechnung, was alles bestimmt, wie groß ein Block sein darf, damit Clients ihn problemlos verarbeiten können.
Der Soldøgn-BAL-Track lief auf eigenen Devnets, getrennt von den Glamsterdam-ePBS-Chains, sodass Optimierungs-Benchmarks nicht mit der Stabilisierungsarbeit auf der Konsens-Schicht verflochten waren. Jede Optimierung befand sich hinter einem eigenen Feature-Flag, sodass die Messarbeiten der Woche sie isoliert und nicht als einzelnes Bündel vergleichen konnten. Das BAL-Benchmark-Dashboard und die Rangliste zeigten die Worst-Case-Szenarien jedes Clients in der gesamten Testsuite auf – indem sie sich darauf konzentrierten, zuerst die langsamsten Pfade zu verbessern, konnten die Teams die Gaslimit-Untergrenze auf breiter Front anheben, nicht nur für die schnellste Implementierung.
Gas-Repricings
Glamsterdam beinhaltet eine Reihe von EL-Gas-Repricings, die die Kosten kalibrieren, um sie bei höherem Transaktionsdurchsatz besser an die Ressourcennutzung anzupassen. EIP-8037, die Erhöhung der Gaskosten für die Zustandserstellung, steht dabei im Mittelpunkt: Es erhöht den Preis für das Schreiben eines neuen Zustands, sodass ein höheres Gaslimit nicht zu einem unbegrenzten Zustandswachstum führt.
Zu Beginn von Soldøgn enthielt die 8037-Spezifikation eine dynamische Preisgestaltung pro Zustands-Byte, die an das Block-Gaslimit gebunden war, was das Testen kombinatorisch schmerzhaft (eine Fuzz-Matrix pro Gaslimit-Band) und das Benchmarking fast unlösbar machte. Die Teams einigten sich früh in der Woche darauf, die dynamische Preisgestaltung zugunsten eines festen cost_per_state_byte aufzugeben, wobei zukünftige Repricings an Fork-Grenzen und nicht innerhalb eines Forks gehandhabt werden.
Das Abrechnungsmodell selbst nahm einen iterativeren Weg. Die Breakout-Session am Montag verschob die Zustands-Gas-Abrechnung von der Mitte der Ausführung an das Ende des Call-Frames; ein Follow-up am Dienstag schloss die Kosten für die Kontoerstellung, die Code-Hinterlegungskosten und die Rückgängigmachung von CREATE-Transaktionen ab; am Mittwoch tauchten Randfälle bei der Rückerstattung/Wiederauffüllung von Reservoirs auf, die ein Umdenken erzwangen. Die Breakout-Session am Donnerstag setzte die Abrechnung wieder auf Opcode-Ebene zurück, nachdem man zu dem Schluss gekommen war, dass die eigentliche Komplexität im Reservoir-Modell lag und nicht in der Abrechnungsberechnung. Bis Freitag hatte sich die Spezifikation auf bal-devnet-6 stabilisiert, wobei der BAL-Track die endgültigen Repricing-Zahlen lieferte.
Dieser gesamte Bogen unterstreicht einen der wichtigsten Aspekte der Interop: die Fähigkeit, komplexe Spezifikations-, Implementierungs-, Test-, Debugging- und Designprobleme in Stunden statt in Wochen zu lösen. Im besten Fall können Interop-Wochen einen Monat asynchronen Fortschritts in jeden einzelnen Tag komprimieren!
Bis Freitag liefen die drei Stränge auf die Schlagzeilenzahl der Woche hinaus: eine glaubwürdige Untergrenze für das Gaslimit nach Glamsterdam von 200M. Diese signifikante Erhöhung ist möglich, weil ePBS den Slot so strukturiert, dass der Ausführung mehr Zeit eingeräumt wird, BAL-Optimierungen den Clients den Spielraum für den Transaktionsdurchsatz unter dieser Struktur geben und 8037 sicherstellt, dass das höhere Gaslimit nicht zu einem unkontrollierten Zustandswachstum führt.
Weitere Glamsterdam-Themen
Neben ePBS, BALs und Repricings wurde der Großteil des verbleibenden Glamsterdam-Umfangs in Breakout-Sessions ausgearbeitet.
Die CL-Teams schlossen Entscheidungen zu kleineren Glamsterdam-EIPs ab: EIP-8061 (Erhöhung der Austritts-/Konsolidierungs-Churn-Rate) wurde in glamsterdam-devnet-1 aufgenommen; EIP-8080 (Austritte über die Konsolidierungs-Warteschlange) wurde für die Aufnahme abgelehnt; EIP-8045 (Entfernung der Pflichten für geslashte Validatoren) wurde auf Proposer-Pflichten nur innerhalb des Look-Ahead-Fensters beschränkt; und EIP-7688 (stabile SSZ-Container) bleibt im Glamsterdam-Umfang, wird aber aus glamsterdam-devnet-1 herausgehalten, während das Team an der begrenzten Gossip-Nachrichtengröße für Attestierungen unter progressiven Listen arbeitet.
Eine Breakout-Session zur EL/CL-Synchronisierungsarchitektur am Mittwochmorgen verschob EIP-8237 aus Glamsterdam, um die Optionalität für eine längerfristige „Top-up-Synchronisierungs“-Architektur in einem zukünftigen Fork zu erhalten. Stattdessen einigte sich der Raum darauf, einen EIP zu entwerfen, der die Sequenzierung von forkchoiceUpdated / newPayload / getPayload normalisiert, einen Snap-Sync-Initiierungs-Handshake spezifiziert und die Gültig/Ungültig-Konsistenz zwischen den Engine-API-Oberflächen verschärft.
Härtung war ein ständiges Thema der Woche. Eine Sitzung am Donnerstag behandelte Frameworks für Fork-Choice-Compliance-Tests, das Diamond-Repo für reproduzierbare CL-Randfallszenarien und buildoor, das Test-Tool für externe Ersteller von PandaOps, das mitten in der Sitzung anhand einer langen Reihe von Angriffsszenarien demonstriert wurde, die die Teilnehmer vor Ort vorschlugen.
Jenseits von Glamsterdam
Mehrere Breakout-Sessions blickten auf Hegotá und die darauf folgenden Forks.
Eine bewusst vorschlagsunabhängige Sitzung zur nativen Kontoabstraktion machte den Anfang und arbeitete die Anforderungen und Einschränkungen durch, die jedes zukünftige Design erfüllen muss. Ziele für den Funktionsumfang wie alternative Signaturschemata, Aggregation, Bündelung, Wiederherstellung, Gas-Sponsoring, flexible Nonces und Schlüsselspeicher-Wallets standen neben harten Einschränkungen in Bezug auf die Kompatibilität mit öffentlichen Mempools, Zustandslosigkeit und L2-DoS-Resistenz.
Eine FOCIL-Breakout-Session am Donnerstag konzentrierte sich auf Implementierungs-Updates: Frühe Prototypen waren bereits funktionsfähig, wobei Multi-Client-Interop und ein dediziertes FOCIL-Devnet die unmittelbaren nächsten Schritte sind. Es wurden auch zwei bemerkenswerte Designentscheidungen getroffen: die Deaktivierung von FOCIL während einer 2-Epochen-Nicht-Endgültigkeit (was das Circuit-Breaker-Verhalten des Proposer-Boosts widerspiegelt) und die Übernahme eines indexbasierten Lesezeichen-Ansatzes für die Kompatibilität mit Frame-Transaktionen / EIP-7702.
Weiter in der Zukunft skizzierte ein lang laufender ETH P2P-Track einen QUIC-basierten Ersatz für libp2p mit standardmäßiger Privatsphäre und Slot-bewusster Integration, zusammen mit einem Erasure-codierten Broadcast-Prototyp, der eine ~6-mal schnellere Verbreitung als GossipSub bei 2,4 MB Payloads simulierte. Der CL-Track brachte auch eine starke Tendenz zutage, Konsolidierungen letztendlich ganz abzuschaffen – indem ein letzter Fork deklariert wird, der sie unterstützt, und danach ein Austritt-dann-Wiedereinzahlung-Verfahren erzwungen wird – als die sauberere langfristige Antwort auf das Zustandswachstum des Validator-Sets.
ACD-Prozess
Am Mittwochnachmittag leiteten Nixo und Ansgar, die beiden ACDE-Co-Leiter, eine Sitzung, um Feedback von Kernmitwirkenden zum ACD-Prozess zu sammeln. Die Sitzung griff das Headliner-Konstrukt wieder auf, debattierte die Vor- und Nachteile einer Strawmap und formalisierte die EIP SFI-Kriterien. Der Raum wollte Headliner im Großen und Ganzen beibehalten, aber die Starrheit von EIP-vs-Thema lockern und „Thema + Kandidaten-EIP“ als praktikables Muster akzeptieren. Die Zuweisungen der Strawmap pro Fork-Jahr nach 2026 wurden als überkanonisiert markiert und werden wahrscheinlich aufgeweicht. Eine neue Vier-Punkte-SFI-Definition wurde vorgeschlagen, wobei ACDT Bereitschaft signalisierte und ACDE/ACDC die endgültige Entscheidung behalten. Ein neuer Priorisierungs- und Ordnungsprozess – der nach CFI-Entscheidungen erstellt wird und sich im Meta-EIP widerspiegelt – wird die alte Rolle von SFI bei der Steuerung der Devnet-Aufnahme ersetzen, beginnend mit Hegotá.
Auf der Seite der Call-Koordination kündigte Alex Stokes an, dass er ab nächster Woche ein dreimonatiges Sabbatical einlegen wird, wobei Pari in der Zwischenzeit die ACDC-Moderation übernimmt und Barnabas für ACDT einspringt. Alles in allem: Nixo und Ansgar leiten ACDE, Pari ist interimistisch bei ACDC, und Mario, Barnabas und Danceratopz wechseln sich bei der ACDT-Moderation ab.
Alles Weitere
Zusätzlich zu all dem nutzten die Teams die persönliche Zeit, um Fortschritte bei allem zu machen, von besseren Testumgebungen (die Hive-Feedbackschleifen von Stunden auf Minuten komprimieren) über Verbesserungen der Engine-API-Infrastruktur (Gossip-Deduplizierung, gebündelte Aufrufe und Light-Client-gesteuerte Head-Erkennung) bis hin zu harten Kompromissen rund um die Client-Diversität und vielen anderen Themen. Die vollständige Liste der Sitzungsnotizen ist unter soldogn.xyz verfügbar.
Nächste Schritte
Von hier aus kehren die Teams nach Hause zurück, um das, was während der Woche als Prototyp entwickelt wurde, produktionsreif zu machen. Erwartet, dass die nächsten Wochen hochkonzentriert darauf verwendet werden, Client-Implementierungen gegen die neuen Spezifikationen zu härten, die Testabdeckung abzuschließen und die Entwurfs-PRs von Soldøgn in zusammengeführten Code zu verwandeln.
Wie immer werden die endgültigen Entscheidungen für Werte wie das 200M-Gaslimit-Ziel und die endgültigen Repricing-Zahlen in den AllCoreDevs-Calls getroffen und öffentlich geteilt. Erwartet, dass dies die Hauptthemen der nächsten Woche sein werden!
Vielen Dank an alle, die den weiten Weg bis auf 78°N auf sich genommen und diese Woche zu einem Erfolg gemacht haben! Ein besonderes Dankeschön geht an EthPandaOps, die die Gruppe jeden Tag auf Trab gehalten haben, und an alle, die unter der Mitternachtssonne gearbeitet haben, um sicherzustellen, dass wir unsere Tagesziele erreichen – einschließlich der Ethrex-Crew, die bei ihrer ersten Interop dabei war. Es war eine unglaublich produktive Woche, und zum Glück werden wir einen kompletten Kurzfilm haben, um uns daran zu erinnern ☀️