Pour une même requête eth_chainId, l’adresse du réseau principal listée officiellement n’a pas renvoyé de réponse, alors que le testnet a renvoyé correctement. Ce résultat ne peut pas être remplacé par l’idée que le réseau principal est déjà arrêté. Il révèle plutôt un autre problème. @Dusk , écrire l’entrée dans la documentation, ne fait que prouver que l’adresse est déclarée ; cela ne prouve pas que cette machine a établi une connexion fiable avec elle. La documentation existe et le client peut la lire, mais entre les deux il reste encore les certificats, le réseau et l’identité de la chaîne.
J’ai resserré les variables au maximum. Le client, le contenu POST et le délai d’attente de 15 secondes sont strictement identiques ; seule l’extrémité RPC change. Le 24 août 2026 à 00h08, le testnet a renvoyé 0x2e9, puis a fourni le bloc 0x11bc06. Le réseau principal, avec une vérification stricte des certificats, s’est arrêté au niveau TLS ; l’état HTTP est 000, le résultat de vérification est 20, et le chain ID côté application n’a jamais été obtenu.
L’intérêt de cette comparaison n’est pas de porter un jugement de santé “sur tout le réseau”. Un échec TLS strict peut venir de la chaîne de certificats, ou peut n’apparaître que sur mon chemin réseau actuel. Le périmètre qu’elle prouve est très clair : au moins dans cet environnement client, l’adresse de la documentation n’a pas encore passé l’acceptation de la disponibilité. Écrire un échec de connexion comme si tout le réseau était en panne serait plus imprudent que d’ignorer le fait même de l’échec.
Avant, je voyais le RPC et je commençais à configurer le wallet. Maintenant, l’ordre doit changer. La connexion fiable est la porte ; le chain ID est le numéro de la pièce. C’est seulement quand le bloc continue d’avancer qu’on sait qu’il y a quelqu’un dans la salle. Il ne faut jamais essayer avec des fonds réels si une étape manque. Cette fois, le testnet a pu continuer à valider les trois points ; le réseau principal s’est arrêté à la première porte. La différence n’est pas une question de vitesse : c’est la capacité à entrer dans l’étape de validation suivante.
$DUSK : pour que l’entrée EVM soit réellement utilisable, il faut à la fois constater que le certificat est fiable, que le chain ID correspond à l’attendu, et que la hauteur du bloc continue de changer. Les trois preuves ne sont pas réunies : je ne le considérerai que comme “à vérifier”, et non comme “disponible”, et encore moins comme “le réseau principal est en panne”. L’action la plus économique pour les utilisateurs ordinaires est aussi très concrète : avant tout virement, effectuez d’abord ces trois contrôles ; si l’un d’eux ne donne aucun résultat, stoppez-vous.
La documentation donne l’adresse ; ce n’est qu’après les tests en conditions réelles qu’on obtient le laissez-passer. #dusk
J’ai resserré les variables au maximum. Le client, le contenu POST et le délai d’attente de 15 secondes sont strictement identiques ; seule l’extrémité RPC change. Le 24 août 2026 à 00h08, le testnet a renvoyé 0x2e9, puis a fourni le bloc 0x11bc06. Le réseau principal, avec une vérification stricte des certificats, s’est arrêté au niveau TLS ; l’état HTTP est 000, le résultat de vérification est 20, et le chain ID côté application n’a jamais été obtenu.
L’intérêt de cette comparaison n’est pas de porter un jugement de santé “sur tout le réseau”. Un échec TLS strict peut venir de la chaîne de certificats, ou peut n’apparaître que sur mon chemin réseau actuel. Le périmètre qu’elle prouve est très clair : au moins dans cet environnement client, l’adresse de la documentation n’a pas encore passé l’acceptation de la disponibilité. Écrire un échec de connexion comme si tout le réseau était en panne serait plus imprudent que d’ignorer le fait même de l’échec.
Avant, je voyais le RPC et je commençais à configurer le wallet. Maintenant, l’ordre doit changer. La connexion fiable est la porte ; le chain ID est le numéro de la pièce. C’est seulement quand le bloc continue d’avancer qu’on sait qu’il y a quelqu’un dans la salle. Il ne faut jamais essayer avec des fonds réels si une étape manque. Cette fois, le testnet a pu continuer à valider les trois points ; le réseau principal s’est arrêté à la première porte. La différence n’est pas une question de vitesse : c’est la capacité à entrer dans l’étape de validation suivante.
$DUSK : pour que l’entrée EVM soit réellement utilisable, il faut à la fois constater que le certificat est fiable, que le chain ID correspond à l’attendu, et que la hauteur du bloc continue de changer. Les trois preuves ne sont pas réunies : je ne le considérerai que comme “à vérifier”, et non comme “disponible”, et encore moins comme “le réseau principal est en panne”. L’action la plus économique pour les utilisateurs ordinaires est aussi très concrète : avant tout virement, effectuez d’abord ces trois contrôles ; si l’un d’eux ne donne aucun résultat, stoppez-vous.
La documentation donne l’adresse ; ce n’est qu’après les tests en conditions réelles qu’on obtient le laissez-passer. #dusk