Архивная нода: когда без неё не обойтись

Слово «архивная» звучит как техническая деталь для инженеров, но именно от неё зависит, ответит ли нода на вполне обычный вопрос: «какой был баланс этого адреса три месяца назад» или «что лежало в этой ячейке контракта на блоке номер таком-то». Разберём, чем архивная нода отличается от обычной и когда без неё правда не обойтись.

Что такое архивная нода

Любая нода хранит текущее состояние сети: балансы, код контрактов, последние транзакции. Этого достаточно для большинства повседневных запросов — узнать баланс сейчас, отправить транзакцию, посмотреть последний блок. Архивная нода хранит больше: полное состояние сети на каждый исторический блок, а не только на последний. За счёт этого она может ответить на запрос про любой момент в прошлом, а не только про «сейчас».

Расплата — место на диске. Полная история состояния растёт вместе с сетью и занимает заметно больше пространства, чем нода, которая хранит только актуальные данные. Именно поэтому не каждая нода в мире работает в архивном режиме по умолчанию.

Зачем нужна полная история

Типичные сценарии, где обычной ноды не хватает:

• Восстановить баланс адреса на конкретную дату — например, для сверки или бухгалтерии.
• Поднять полную историю операций смарт-контракта с момента его создания, а не только за последние дни.
• Проверить, что именно хранилось в памяти контракта на определённом блоке при разборе инцидента.
• Собрать выписку по адресу клиента целиком, включая старые переводы, для аудита или комплаенса.

Ни одна из этих задач не решается запросом «дай мне последнее состояние» — везде нужен конкретный номер блока или диапазон в прошлом.

Возьмём аудит: сервису нужно подтвердить, что на конкретную дату у адреса был именно такой баланс, каким его указали в отчёте. Обычная нода честно ответит на вопрос «сколько там сейчас», но у неё просто нет данных о состоянии на нужный момент времени — они были перезаписаны более свежими. Без архивных данных единственный обходной путь — пересчитывать баланс вручную по всем историческим транзакциям адреса, что медленнее и сложнее одного прямого запроса.

Какие методы требуют архивных данных

В EVM-совместимых сетях вроде Ethereum и Polygon это методы, которые принимают не только тег latest, но и произвольный номер блока: eth_getBalance, eth_call и eth_getStorageAt с историческим блоком вместо latest, а также методы трассировки вроде debug_traceTransaction. На обычной ноде такой запрос с историческим блоком часто просто не найдёт данные и вернёт ошибку.

# ethereum — имя ноды для примера, точное название — в личном кабинете
curl -X POST https://nodes-api.cryptosafe.pro/proxy/ethereum \
  -H "Authorization: <ваш-ключ>" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["<адрес>","0xc65d40"],"id":1}'

# "0xc65d40" — конкретный номер блока в прошлом вместо "latest"

У Bitcoin своя специфика: полнотекстовый поиск произвольной транзакции по её идентификатору требует включённого индекса транзакций, а не архивного режима как такового, но идея та же — по умолчанию нода рассчитана на текущую работу с сетью, а не на поиск чего угодно из всей истории. Без индекса нода Bitcoin по-прежнему хранит все блоки, но чтобы найти конкретную транзакцию по её идентификатору, ей пришлось бы перебрать блоки один за другим — это медленно и на практике так не делают.

Как понять, что вам нужна именно архивная нода

Если приложение всегда работает с состоянием «сейчас» — проверяет текущий баланс, отправляет транзакции, читает последние события — обычной ноды достаточно. Сигнал для архивной ноды другой: в коде периодически появляется конкретный номер блока вместо latest, или бизнесу регулярно нужны отчёты и выписки за прошлые периоды, а не только текущий срез. Если такие запросы разовые и редкие, проще обсудить их с поддержкой отдельно, чем заранее держать архивную ноду под задачу, которая возникает пару раз в квартал.

Что это значит для инфраструктуры

Держать архивную ноду самостоятельно — это не только больше диска, но и дольше первичная синхронизация: нода должна пересчитать и сохранить состояние на каждый блок с самого начала сети, а не только догнать текущий. Для команды, которая уже думает, поднимать свою инфраструктуру или пользоваться готовым доступом, это весомый аргумент — подробнее компромиссы разобраны в статье «Своя нода или провайдер: как выбрать».

На CryptoSafe Nodes доступ к Ethereum и Bitcoin устроен так, что через прокси проходит любой метод, который принимает нода, без дополнительного парсинга тела запроса. Если для задачи важны именно исторические данные — уточните у поддержки в чате, какой конкретно набор данных нужен, и мы поможем разобраться, какая нода подойдёт. Что делать дальше с полученными историческими данными — например, как отследить статус конкретной транзакции — описано в статье «Мониторинг транзакций».