Bei derselben eth_chainId-Anfrage lieferte die offiziell angegebene Mainnet-Adresse keine Antwort, während das Testnetz normal antwortete. Dieses Ergebnis darf nicht so umgedeutet werden, als wäre damit bewiesen, dass das Mainnet ausgefallen ist. Es legt ein Problem auf einer anderen Ebene offen. @Dusk : Dass der Einstiegspunkt in der Dokumentation steht, beweist nur, dass diese Adresse angegeben wurde – nicht, dass mein Rechner bereits eine vertrauenswürdige Verbindung zu ihr aufgebaut hat. Zwischen vorhandener Dokumentation und einem für den Client nutzbaren Endpunkt liegen noch Zertifikate, Netzwerk und Chain-Identität.
Ich habe die Variablen stark eingegrenzt. Client, POST-Inhalt und 15-Sekunden-Timeout waren identisch; nur der RPC-Endpunkt wurde ausgetauscht. Am 24. August 2026 um 00:08 Uhr antwortete das Testnetz mit 0x2e9 und lieferte anschließend den Block 0x11bc06. Beim Mainnet blieb die Verbindung unter strikter Zertifikatsprüfung auf der TLS-Ebene hängen: Der HTTP-Status war 000, das Prüfergebnis 20, und die Chain-ID auf Anwendungsebene ließ sich gar nicht erst abrufen.
Der größte Nutzen dieses Vergleichs besteht nicht darin, ein Urteil über den Zustand des Netzwerks zu fällen. Ein Fehler bei der strikten TLS-Prüfung kann an der Zertifikatskette liegen oder nur auf dem Netzwerkpfad auftreten, den ich gerade nutze. Was sich daraus ableiten lässt, ist klar begrenzt: Zumindest in dieser Client-Umgebung hat die dokumentierte Adresse den Verfügbarkeitstest noch nicht bestanden. Einen einzelnen Verbindungsfehler als Ausfall des gesamten Netzwerks darzustellen, wäre noch leichtfertiger, als den Fehler selbst zu ignorieren.
Früher sah ich einen RPC-Endpunkt und begann sofort, eine Wallet einzurichten. Jetzt muss ich die Reihenfolge ändern. Eine vertrauenswürdige Verbindung ist das Tor, die Chain-ID die Hausnummer, und erst wenn die Blockhöhe weiter steigt, ist klar, dass jemand im Haus ist. Fehlt auch nur einer dieser Schritte, sollte man nicht mit echtem Geld herumprobieren. Beim Testnetz lassen sich diesmal alle drei Punkte weiter überprüfen; beim Mainnet ist schon nach dem ersten Schluss. Der Unterschied liegt nicht darin, wie schnell es geht, sondern darin, ob die nächste Prüfung überhaupt möglich ist.
Damit der EVM-Endpunkt unter $DUSK wirklich nutzbar ist, müssen drei Dinge gleichzeitig bestätigt sein: ein vertrauenswürdiges Zertifikat, eine mit der erwarteten Chain-ID übereinstimmende ID und eine sich weiter verändernde Blockhöhe. Solange nicht alle drei Belege vorliegen, kennzeichne ich ihn als „muss noch untersucht werden“, nicht als „nutzbar“ – und erst recht nicht als „Mainnet ausgefallen“. Für normale Nutzer ist die günstigste Maßnahme ganz konkret: Vor einer Überweisung diese drei Prüfungen durchführen und abbrechen, wenn auch nur eine davon kein Ergebnis liefert.
Die Dokumentation nennt die Adresse; erst der Praxistest stellt den Passierschein aus. #dusk
Ich habe die Variablen stark eingegrenzt. Client, POST-Inhalt und 15-Sekunden-Timeout waren identisch; nur der RPC-Endpunkt wurde ausgetauscht. Am 24. August 2026 um 00:08 Uhr antwortete das Testnetz mit 0x2e9 und lieferte anschließend den Block 0x11bc06. Beim Mainnet blieb die Verbindung unter strikter Zertifikatsprüfung auf der TLS-Ebene hängen: Der HTTP-Status war 000, das Prüfergebnis 20, und die Chain-ID auf Anwendungsebene ließ sich gar nicht erst abrufen.
Der größte Nutzen dieses Vergleichs besteht nicht darin, ein Urteil über den Zustand des Netzwerks zu fällen. Ein Fehler bei der strikten TLS-Prüfung kann an der Zertifikatskette liegen oder nur auf dem Netzwerkpfad auftreten, den ich gerade nutze. Was sich daraus ableiten lässt, ist klar begrenzt: Zumindest in dieser Client-Umgebung hat die dokumentierte Adresse den Verfügbarkeitstest noch nicht bestanden. Einen einzelnen Verbindungsfehler als Ausfall des gesamten Netzwerks darzustellen, wäre noch leichtfertiger, als den Fehler selbst zu ignorieren.
Früher sah ich einen RPC-Endpunkt und begann sofort, eine Wallet einzurichten. Jetzt muss ich die Reihenfolge ändern. Eine vertrauenswürdige Verbindung ist das Tor, die Chain-ID die Hausnummer, und erst wenn die Blockhöhe weiter steigt, ist klar, dass jemand im Haus ist. Fehlt auch nur einer dieser Schritte, sollte man nicht mit echtem Geld herumprobieren. Beim Testnetz lassen sich diesmal alle drei Punkte weiter überprüfen; beim Mainnet ist schon nach dem ersten Schluss. Der Unterschied liegt nicht darin, wie schnell es geht, sondern darin, ob die nächste Prüfung überhaupt möglich ist.
Damit der EVM-Endpunkt unter $DUSK wirklich nutzbar ist, müssen drei Dinge gleichzeitig bestätigt sein: ein vertrauenswürdiges Zertifikat, eine mit der erwarteten Chain-ID übereinstimmende ID und eine sich weiter verändernde Blockhöhe. Solange nicht alle drei Belege vorliegen, kennzeichne ich ihn als „muss noch untersucht werden“, nicht als „nutzbar“ – und erst recht nicht als „Mainnet ausgefallen“. Für normale Nutzer ist die günstigste Maßnahme ganz konkret: Vor einer Überweisung diese drei Prüfungen durchführen und abbrechen, wenn auch nur eine davon kein Ergebnis liefert.
Die Dokumentation nennt die Adresse; erst der Praxistest stellt den Passierschein aus. #dusk