同じ「eth_chainId」リクエストでも、公式が掲載しているメインネットのアドレスはレスポンスが返ってこないのに、テストネットは正常に返ってきます。この結果を「メインネットはすでに停止している」というふうにすり替えることはできません。これは別の問題を露呈しています。@Dusk が入口をドキュメントに書いたことは、アドレスが宣言されていることを示すだけで、私のこのマシンがそれと信頼できる接続を確立できたことは証明しません。ドキュメントが存在しても、クライアントで使えることが保証されるわけではなく、間には証明書、ネットワーク、そしてチェーンの身元（チェーン・アイデンティティ）が挟まっています。

私は変数をかなり絞り込みました。クライアントの内容、POST の内容、そして 15 秒のタイムアウトは完全に同じで、RPC エンドポイントだけを入れ替えています。2026 年 8 月 24 日 00:08、テストネットは 0x2e9 を返し、その後ブロック 0x11bc06 を提示しました。一方、メインネットは厳格な証明書検証のもとで TLS で止まり、HTTP ステータスは 000、検証結果は 20 でした。アプリ層の chain ID はそもそも取得できていません。

この比較で最も有用なのは、テストネットの健全性判断ではありません。厳格な TLS の失敗は、証明書チェーンが原因である可能性もあれば、単に私の現在のネットワーク経路でだけ発生している可能性もあります。証明できる範囲は明確で、少なくともこのクライアント環境では、ドキュメント上のアドレスが可用性の検収を通過していないということです。接続失敗を「全ネットワーク障害」と書き換えるのは、失敗そのものを無視するよりもずっと雑です。

以前は RPC を見たらすぐにウォレット設定を始めていました。今は順序を変える必要があります。信頼できる接続は「扉」で、chain ID は「部屋番号」です。ブロックが継続的に進むことこそが、中に人がいることの証拠になります。ひとつでも欠ければ、実際の資金での試行錯誤に使うべきではありません。今回、テストネットは三項目すべてを継続して核（確認）できたのに対し、メインネットは最初の段階で止まったのです。違いは「速い／遅い」ではなく、「次の検証ステップに入れるかどうか」です。

$DUSK の EVM 入口が本当に利用可能であると確認するには、証明書が信頼できること、chain ID が期待値に一致すること、そしてブロック高が引き続き変化すること――この三つを同時に確認する必要があります。三つの証拠が揃っていない場合、私はそれを「利用可能」とはせず、「調査待ち」として記録するだけです。まして「メインネットが失効／停止している」とは書きません。一般ユーザーにとって最もお金が節約できる行動も具体的で、送金前にこの三回のチェックを先に行い、いずれかに結果がなければその時点で手を止めます。

ドキュメントにはアドレスを載せても、実測で初めて通行証を出せます。#dusk