Bei einer identischen eth_chainId-Anfrage hat die offizielle Angabe der Mainnet-Adresse keine Antwort zurückgesendet, während das Testnetz normal antwortete. Dieses Ergebnis lässt sich nicht einfach so umdeuten, als sei das Mainnet bereits stillgelegt. Es legt vielmehr eine andere Problematik offen. Wenn man @Dusk den Einstieg in die Dokumentation schreibt, kann man damit nur belegen, dass die Adresse deklariert wurde—nicht, dass diese Maschine bereits eine vertrauenswürdige Verbindung zu ihr aufgebaut hat. Die Existenz der Dokumentation und die Nutzbarkeit für den Client sind gegeben; dazwischen liegen jedoch noch Zertifikate, das Netzwerk und die Kettenidentität.
Ich habe die Variablen sehr eng gehalten. Der Client, der POST-Inhalt und das 15-Sekunden-Timeout sind vollständig identisch; es wird nur der RPC-Endpunkt ausgetauscht. Am 24. August 2026 um 00:08 Uhr gab das Testnetz 0x2e9 zurück und anschließend den Block 0x11bc06. Das Mainnet blieb unter strenger Zertifikatsprüfung bei TLS stehen; der HTTP-Status ist 000, das Prüfergebnis ist 20—die Chain-ID auf Anwendungsebene wurde schlicht nicht erreicht.
Das Nützlichste an diesem Vergleich ist nicht, ein gesundes Urteil fürs Testnetz abzuleiten. Ein strikter TLS-Fehlschlag kann von der Zertifikatkette herrühren, oder er kann nur in meinem aktuellen Netzwerkpfad auftreten. Der damit belegbare Umfang ist klar begrenzt: Zumindest in dieser Client-Umgebung hat die Dokumentationsadresse die Verfügbarkeitsprüfung noch nicht bestanden. Einen einzelnen Verbindungsfehler als Ausfall des gesamten Netzes darzustellen wäre unvorsichtiger, als den Fehler selbst zu ignorieren.
Früher hätte ich direkt beim Sehen des RPC damit begonnen, ein Wallet einzurichten. Jetzt muss die Reihenfolge geändert werden. Eine vertrauenswürdige Verbindung ist die Tür, die Chain-ID ist die Zimmernummer; dass der Block kontinuierlich weiterläuft, zeigt erst, dass im Raum jemand ist. Weniger als eine dieser Stufen darf man nicht—sonst sollte man echte Gelder nicht zum Testen einsetzen. In diesem Testnetz können alle drei Prüfungen weiterlaufen; im Mainnet bleibt es bei der ersten Hürde stehen. Der Unterschied liegt nicht in der Geschwindigkeit, sondern darin, ob man die nächste Verifikationsstufe erreicht.
Für $DUSK ist der EVM-Einstieg wirklich nutzbar, wenn gleichzeitig nachgewiesen wird: Das Zertifikat ist vertrauenswürdig, die Chain-ID trifft die erwartete Vorgabe, und die Blockhöhe verändert sich weiterhin. Wenn nicht alle drei Beweise zusammenkommen, markiere ich es nur als „zur Überprüfung offen“, nicht als „verfügbar“—und erst recht nicht als „Mainnet-Ausfall“. Die kostensparendste Aktion für normale Nutzer ist ganz konkret: Vor einer Überweisung erst diese drei Checks durchführen; sobald bei irgendeinem Punkt kein Ergebnis vorliegt, sofort stoppen.
Die Dokumentation gibt die Adresse—erst die praktische Messung gibt das Ticket. #dusk
Ich habe die Variablen sehr eng gehalten. Der Client, der POST-Inhalt und das 15-Sekunden-Timeout sind vollständig identisch; es wird nur der RPC-Endpunkt ausgetauscht. Am 24. August 2026 um 00:08 Uhr gab das Testnetz 0x2e9 zurück und anschließend den Block 0x11bc06. Das Mainnet blieb unter strenger Zertifikatsprüfung bei TLS stehen; der HTTP-Status ist 000, das Prüfergebnis ist 20—die Chain-ID auf Anwendungsebene wurde schlicht nicht erreicht.
Das Nützlichste an diesem Vergleich ist nicht, ein gesundes Urteil fürs Testnetz abzuleiten. Ein strikter TLS-Fehlschlag kann von der Zertifikatkette herrühren, oder er kann nur in meinem aktuellen Netzwerkpfad auftreten. Der damit belegbare Umfang ist klar begrenzt: Zumindest in dieser Client-Umgebung hat die Dokumentationsadresse die Verfügbarkeitsprüfung noch nicht bestanden. Einen einzelnen Verbindungsfehler als Ausfall des gesamten Netzes darzustellen wäre unvorsichtiger, als den Fehler selbst zu ignorieren.
Früher hätte ich direkt beim Sehen des RPC damit begonnen, ein Wallet einzurichten. Jetzt muss die Reihenfolge geändert werden. Eine vertrauenswürdige Verbindung ist die Tür, die Chain-ID ist die Zimmernummer; dass der Block kontinuierlich weiterläuft, zeigt erst, dass im Raum jemand ist. Weniger als eine dieser Stufen darf man nicht—sonst sollte man echte Gelder nicht zum Testen einsetzen. In diesem Testnetz können alle drei Prüfungen weiterlaufen; im Mainnet bleibt es bei der ersten Hürde stehen. Der Unterschied liegt nicht in der Geschwindigkeit, sondern darin, ob man die nächste Verifikationsstufe erreicht.
Für $DUSK ist der EVM-Einstieg wirklich nutzbar, wenn gleichzeitig nachgewiesen wird: Das Zertifikat ist vertrauenswürdig, die Chain-ID trifft die erwartete Vorgabe, und die Blockhöhe verändert sich weiterhin. Wenn nicht alle drei Beweise zusammenkommen, markiere ich es nur als „zur Überprüfung offen“, nicht als „verfügbar“—und erst recht nicht als „Mainnet-Ausfall“. Die kostensparendste Aktion für normale Nutzer ist ganz konkret: Vor einer Überweisung erst diese drei Checks durchführen; sobald bei irgendeinem Punkt kein Ergebnis vorliegt, sofort stoppen.
Die Dokumentation gibt die Adresse—erst die praktische Messung gibt das Ticket. #dusk