Один и тот же запрос eth_chainId: официальный адрес основной сети не вернул ответ, а тестовая сеть ответила нормально. Этот результат нельзя подменять утверждением, что основная сеть уже остановилась. Он указывает на проблему другого уровня. @Dusk : запись адреса в документации доказывает лишь то, что адрес заявлен, но не то, что мой компьютер уже установил с ним доверенное соединение. Между наличием документации и доступностью для клиента стоят сертификат, сеть и идентичность сети.
Я свёл переменные к минимуму. Клиент, содержимое POST-запроса и тайм-аут в 15 секунд остались одинаковыми — я заменил только RPC-эндпоинт. 24 августа 2026 года в 00:08 тестовая сеть вернула 0x2e9, а затем блок 0x11bc06. Основная сеть при строгой проверке сертификата остановилась на TLS: статус HTTP — 000, результат проверки — 20, а идентификатор chain ID на уровне приложения получить так и не удалось.
Главная ценность этого сравнения не в том, чтобы выносить вердикт о состоянии сети. Ошибка строгой проверки TLS может быть связана с цепочкой сертификатов, а может возникать только на текущем сетевом маршруте. Предел того, что можно утверждать, ясен: по крайней мере в этой среде клиента адрес из документации пока не прошёл проверку доступности. Записывать единичный сбой подключения как отказ всей сети было бы ещё более опрометчиво, чем просто не обращать на него внимания.
Раньше я видел RPC и сразу начинал настраивать кошелёк. Теперь порядок придётся изменить. Доверенное соединение — это дверь, chain ID — номер дома, а непрерывное продвижение блоков показывает, что внутри кто-то есть. Если не пройдена хотя бы одна проверка, не стоит проверять сеть на реальных средствах. В этот раз в тестовой сети можно продолжить проверку по всем трём пунктам, а основная остановилась уже на первом. Разница не в скорости, а в том, можно ли перейти к следующему этапу проверки.
Чтобы EVM-эндпоинт $DUSK действительно можно было использовать, нужно одновременно убедиться в доверенности сертификата, соответствии chain ID ожидаемому значению и дальнейшем изменении высоты блока. Пока не собраны все три подтверждения, я помечу его как требующий проверки, а не как доступный для использования — и тем более не стану писать, что основная сеть не работает. Пользователям проще всего сэкономить вот так: перед переводом провести эти три проверки и остановиться, если хотя бы одна из них не дала результата.
Документация указывает адрес, а пропуск даёт только проверка на практике. #dusk
Я свёл переменные к минимуму. Клиент, содержимое POST-запроса и тайм-аут в 15 секунд остались одинаковыми — я заменил только RPC-эндпоинт. 24 августа 2026 года в 00:08 тестовая сеть вернула 0x2e9, а затем блок 0x11bc06. Основная сеть при строгой проверке сертификата остановилась на TLS: статус HTTP — 000, результат проверки — 20, а идентификатор chain ID на уровне приложения получить так и не удалось.
Главная ценность этого сравнения не в том, чтобы выносить вердикт о состоянии сети. Ошибка строгой проверки TLS может быть связана с цепочкой сертификатов, а может возникать только на текущем сетевом маршруте. Предел того, что можно утверждать, ясен: по крайней мере в этой среде клиента адрес из документации пока не прошёл проверку доступности. Записывать единичный сбой подключения как отказ всей сети было бы ещё более опрометчиво, чем просто не обращать на него внимания.
Раньше я видел RPC и сразу начинал настраивать кошелёк. Теперь порядок придётся изменить. Доверенное соединение — это дверь, chain ID — номер дома, а непрерывное продвижение блоков показывает, что внутри кто-то есть. Если не пройдена хотя бы одна проверка, не стоит проверять сеть на реальных средствах. В этот раз в тестовой сети можно продолжить проверку по всем трём пунктам, а основная остановилась уже на первом. Разница не в скорости, а в том, можно ли перейти к следующему этапу проверки.
Чтобы EVM-эндпоинт $DUSK действительно можно было использовать, нужно одновременно убедиться в доверенности сертификата, соответствии chain ID ожидаемому значению и дальнейшем изменении высоты блока. Пока не собраны все три подтверждения, я помечу его как требующий проверки, а не как доступный для использования — и тем более не стану писать, что основная сеть не работает. Пользователям проще всего сэкономить вот так: перед переводом провести эти три проверки и остановиться, если хотя бы одна из них не дала результата.
Документация указывает адрес, а пропуск даёт только проверка на практике. #dusk