Чем приватная RPC-нода отличается от публичной

Почти у каждой популярной сети есть бесплатный публичный RPC-эндпоинт: адрес, на который можно отправить запрос прямо сейчас, без регистрации и настройки. Для теста в консоли или разовой проверки баланса это удобно. Но когда на этом адресе начинает работать боевой сервис — обменник, кошелёк, платёжный бэкенд — у публичного доступа быстро находятся границы.

Что такое публичный RPC-эндпоинт

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

Загвоздка в том, что этим же адресом одновременно пользуются десятки и сотни других людей и ботов. Оператор публичной ноды не обязан вас предупреждать об изменениях, обслуживании или временной недоступности — вы для него один из множества анонимных потребителей.

Чтобы защитить свою инфраструктуру от перегрузки, операторы публичных эндпоинтов почти всегда ограничивают интенсивность запросов с одного адреса. Пока запросов немного, это незаметно. Но стоит увеличить частоту обращений — и часть запросов начинает возвращаться с ошибкой или зависать в очереди, причём заранее понять момент, когда это случится, обычно нельзя: у вас нет ни своего лимита, ни канала, по которому оператор предупредил бы об изменениях.

Где публичный эндпоинт работает нормально

Для разработки и локальных тестов публичные ноды — отличный вариант: не нужно ничего разворачивать, чтобы проверить, как ведёт себя eth_call или как выглядит ответ на getblockcount. Так же они подходят для редких, нерегулярных запросов, где задержка в секунду-другую не критична. Многие сети сети, представленные на CryptoSafe Nodes, и совместимые с ней EVM-цепи вроде Polygon изначально разрабатывались с расчётом на такие публичные шлюзы для сообщества.

Что скрывается за словами «просто работает»

У публичного доступа есть несколько типичных слабых мест, которые редко видны на старте, но становятся заметны при регулярной нагрузке.

• Запрос конкурирует за очередь с чужим трафиком — время ответа плавает.
• Нет отдельного ключа — сложно понять, чей именно запрос вызвал проблему.
• Оператор может ограничить или отключить адрес без предупреждения.
• Тело запроса и адрес кошелька проходят через инфраструктуру, которую вы не выбирали.

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

Что даёт приватный доступ к ноде

Приватный доступ — это, по сути, тот же протокол сети, но за отдельным адресом и со своим ключом. На CryptoSafe Nodes это выглядит так: вы отправляете обычный HTTP-запрос на общий адрес прокси, а нода определяется по имени сети в пути. Тело запроса прокси не парсит и не меняет — оно проходит к ноде как есть, и ответ возвращается без модификаций.

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

Ключ выпускается в личном кабинете и не имеет общих очередей с чужими запросами. Его можно привязать к IP-адресам ваших серверов — тогда запрос с любого другого адреса не пройдёт, даже если ключ утёк. Для сервисов, где через ноду проходят платёжные операции — например, приём и проверку переводов в сетях вроде Bitcoin или Solana — это разница между «сеть иногда медленная» и «сеть недоступна ровно тогда, когда нужнее всего».

Как понять, что пора переходить на приватный доступ

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

Полезно смотреть не только на нагрузку, но и на то, что стоит на кону при сбое. Если недоступность ноды на минуту-другую означает пропущенный платёж или зависшую проверку баланса у клиента, дешевле подключить приватный доступ заранее, чем разбираться с последствиями после инцидента.

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