Как найти причину остановки Ethereum-ноды на одной высоте
Execution RPC может отвечать на запросы, даже когда его локальная цепочка отстаёт. Сопоставьте ответ о синхронизации со временем последних блоков, прежде чем направлять на ноду трафик.
Снимите показания дважды
Отправьте оба запроса на один сервер. Если HTTP RPC доступен локально, выполните команды ниже, запишите время и повторите через минуту. Если за адресом стоит балансировщик, для диагностики выберите отдельную ноду.
curl -sS -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","id":1,"method":"eth_syncing","params":[]}' http://127.0.0.1:8545
curl -sS -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","id":2,"method":"eth_getBlockByNumber","params":["latest",false]}' http://127.0.0.1:8545
Сравните number, hash и timestamp блока в двух замерах. Переведите шестнадцатеричный timestamp в секунды Unix и сравните со временем наблюдения. Небольшая пауза между блоками естественна. Давняя метка времени и неподвижный хеш при растущей высоте независимой доверенной ноды указывают на отставание.
Проверьте оба клиента ноды
Объект в ответе eth_syncing содержит данные о ходе синхронизации. Сравните поля между замерами и найдите текущий этап в логах клиента. Ответ false означает, что клиент не сообщает об активной синхронизации. Geth получает целевую вершину от клиента консенсуса. Проверьте его соединения с пирами и высоту, затем поищите в журналах обоих клиентов ошибки подключения или авторизации Engine API. После восстановления связи повторите оба RPC-запроса. geth.ethereum.org Как Geth получает цель синхронизации