Aktualisiert am 14. September 2026.
Ethereums Glamsterdam Devnet-11 erreicht am 14. September um 12:00 UTC seine Genesis. Das kurzlebige Netzwerk testet den kontrollierten Übergang zum Gloas-Fork, mit besonderem Fokus auf die Zusammenarbeit verschiedener Clients und das Vorbereitungsfenster für Layer-2-Betreiber.
Der Fork ist für Epoche 450 am 16. September um 12:00 UTC geplant. Danach soll ein optionales Experiment das Gas-Limit von 60 auf 200 Millionen erhöhen. Das ist kein Mainnet-Upgrade und keine Entscheidung für diesen Wert, sondern ein Test von Stabilität, Ausführungsdruck und Engpässen.
| Punkt | Devnet-11 |
|---|---|
| Genesis | 14. September, 12:00 UTC |
| Gloas-Fork | 16. September, 12:00 UTC |
| Validatoren | Rund 84.000 |
| Gas-Limit-Test | 60 auf 200 Millionen |
| Umfang | Multi-Client-Übergang, keine Angriffstests |
Was Glamsterdam Devnet-11 testet
EthPandaOps bezeichnet es als Happy-Path-Devnet. Geprüft wird der normale Fork-Übergang, nicht ein extremer Angriff. Die Struktur übernimmt sechs Consensus-Clients, sieben Execution-Clients und zwei Grid-Implementierungen von devnet-8. Lido, Optimism und Arbitrum gehören zu den Teams mit Interesse am Vorlauf.
Gloas führt eine im Protokoll verankerte Proposer-Builder-Trennung ein und verändert die Grenze zwischen Konsens und Blockbau. Vor langlebigen Testnets muss belegt werden, dass unabhängige Clients Payloads, Gebote und Gültigkeitsregeln gleich interpretieren.
Warum die Client-Bereitschaft unterschiedlich ist
Die veröffentlichte Matrix zeigt verschiedene Entwicklungsstände. Geth, Nethermind und Lodestar erfüllten die gesetzte Mindestbasis. Andere Clients hatten noch unvollständige Änderungen oder fehlerhafte Tests. Prysm und Reth lagen bei der Prüfung unter der verlangten Spezifikationsversion.
Genau dafür werden Devnets betrieben. Ein Multi-Client-Fork lässt sich nicht anhand einer Implementierung bewerten. Abweichungen bei Gebotsvalidierung oder Gas-Buchhaltung können ein Netzwerk teilen, obwohl jedes Programm isoliert gesund wirkt.
Der Test mit 200 Millionen Gas
Die Erhöhung bei Epoche 480 ist ein optionaler Belastungstest. Mehr Gas pro Block kann mehr Ausführung ermöglichen, erhöht aber Rechenarbeit, Zustandswachstum, Bandbreite und Hardwarebedarf. Sie verspricht weder niedrigere Gebühren noch bestätigt sie ein Mainnet-Ziel.
Unsere Analyse zur Gas-Neubewertung durch Glamsterdam trennt Kosten pro Operation von Gesamtkapazität. Der Bericht zu institutioneller Onchain-Abwicklung zeigt zusätzlich, warum berechenbare Infrastruktur wichtig ist.
Was der Start nicht bedeutet
Devnet-11 fügt seiner Basis keine neuen EIPs hinzu, ersetzt Platåberget nicht und setzt kein Mainnet-Datum. Die Ethereum Foundation beschreibt einen stufenweisen Weg: Devnets stabilisieren, Sepolia und Hoodi aktualisieren und erst danach den Mainnet-Übergang prüfen.
Welche Signale wichtig sind
Entscheidend sind Finalität nach dem Fork, Übereinstimmung der Clients, Leistung unter höherem Gas-Limit und die Behebung bekannter Inkompatibilitäten. Ein sinnvoller Test versteckt Fehler nicht, sondern findet sie, bevor Nutzer und reales Kapital vom Code abhängen.
Quellen: EthPandaOps Devnet-11; Ethereum Foundation.
Was Node- und Layer-2-Betreiber testen müssen
Für Betreiber ist ein erfolgreicher Fork nur der erste Schritt. Execution- und Consensus-Clients müssen synchron bleiben, Nodes sollen sich nach Unterbrechungen sauber erholen und die Blockverteilung muss der geplanten Last standhalten. Auch Monitoring, Protokolle und Upgrade-Abläufe müssen verständlich sein, bevor der Code öffentliche Netze erreicht.
Layer-2-Teams prüfen Datenverfügbarkeit, Blob-Kosten und die Kompatibilität ihrer Batch-Pipelines. Änderungen an Ethereum können Sequencer, Prover und Warnsysteme indirekt beeinflussen. Der Test betrifft deshalb eine breitere Betriebskette als nur die Client-Software.
Warum Devnet-11 kein ETH-Preissignal ist
Ein stabiles Devnet senkt technisches Risiko, bestimmt aber weder Nachfrage noch Preis von ETH. Zuvor braucht es belastbare öffentliche Testnets, endgültige Spezifikationen, breite Client-Unterstützung und einen Mainnet-Termin. Onchain-Aktivität, Anwendungserlöse, Liquidität und Makrolage bleiben eigenständige Faktoren. Devnet-11 ist ein Entwicklungsschritt und kein Renditeversprechen.
Welche Bestätigungen als Nächstes zählen
Aussagekräftig sind transparente Fehlerberichte, mehrere beteiligte Clients, stabile Finalität nach dem Fork und ein klarer Weg zur nächsten Testphase. Eine problematische Funktion zu verschieben wäre nicht zwingend ein Scheitern. Bei Protokoll-Upgrades ist ein kleinerer Umfang oft verantwortlicher, als instabilen Code Richtung Mainnet zu bewegen.
Glamsterdam Devnet-11 liefert daher auch dann wichtige Erkenntnisse, wenn Fehler auftreten. Das Ergebnis von Glamsterdam Devnet-11 sollte anhand der folgenden technischen Berichte bewertet werden und nicht nur daran, ob die Genesis gelingt.
Auch die Vielfalt der eingesetzten Software ist ein Sicherheitsmerkmal. Besteht das Netz überwiegend aus einem Client, kann ein einzelner Fehler große Teile des Tests gleichzeitig treffen. Entwickler sollten deshalb Ergebnisse getrennt nach Client-Kombination, Hardware und Knotentyp veröffentlichen. Für Staking-Anbieter zählt außerdem, wie sich Validatoren bei verpassten Slots, Reorganisationen oder verzögerter Finalität verhalten. Solche Daten zeigen, ob die Spezifikation nur unter idealen Laborbedingungen funktioniert oder auch bei realistischen Störungen robust bleibt. Erst danach lässt sich die nächste Testphase verantwortungsvoll planen.
