FAQ - Конечные точки Solana RPC

Q. Сколько токенов потребляет каждый метод?

Сейчас мы готовим подробную таблицу потребления токенов. В период бесплатного пробного доступа вы можете свободно протестировать все методы и на практике понять примерный расход.
Для ориентира базовая ставка составляет 42 токена за метод.

Q. В каких регионах расположены ваши ноды?

Сейчас мы эксплуатируем ноды в следующих регионах:
  • Frankfurt (FRA)
  • Amsterdam (AMS)
  • London (LON)
  • New York (NY)
  • Chicago (CHI)
  • Tokyo (TY)
  • Singapore (SGP)
RPC endpoints ERPC работают через Cloudflare и используют глобальную сеть из более чем 300 edge-серверов. Запросы автоматически направляются через ближайшую edge-локацию Cloudflare, а затем пересылаются на оптимальную ноду ERPC, что обеспечивает максимально короткий сетевой маршрут и стабильно низкую задержку из любой точки мира.
Эта архитектура устраняет влияние географической удаленности и сложной маршрутизации, обеспечивая всегда оптимизированное подключение к нодам Solana с максимальной стабильностью и производительностью.
Официальный Discord Validators DAO: https://discord.gg/C7ZQSrCkYR

Q. Можно ли использовать WebSocket?

Да, WebSocket поддерживается. Он работает через тот же endpoint и позволяет эффективно получать обновления данных в реальном времени.

Q. Почему я получаю ошибку 401?

Ошибка 401 указывает на проблему с аутентификацией. Проверьте следующее:
  • Началась ли ваша подписка
  • Остались ли у вас кредиты
Если кредиты закончились, рассмотрите возможность перехода на более высокий план.

Q. Почему я получаю ошибку 429?

Ошибка 429 означает, что вы достигли лимита rate limit. Если такая ошибка возникает часто и влияет на ваш сервис, рассмотрите возможность обновления плана.

Q. Почему dedicated endpoints быстрее?

Shared endpoints используются несколькими клиентами, которые делят одни и те же ресурсы. По мере роста трафика задержка становится более вероятной. Серверные ресурсы физически ограничены, и объем работы, который они могут обработать, конечен. Когда одновременно приходит слишком много запросов, их приходится обрабатывать последовательно, что приводит к более медленному времени ответа.
Хотя мы применяем различные меры для оптимизации производительности даже на shared endpoints, на dedicated endpoints вы являетесь единственным пользователем ресурса. Это означает, что другие пользователи никак на вас не влияют, и вы получаете стабильно быстрые и предсказуемые ответы.
Кроме того, dedicated endpoints поддерживают варианты соединения без TLS, например HTTP. За счет пропуска TLS handshake (около 20ms) соединение становится еще быстрее по сравнению с HTTPS.

Q. Я хочу платить криптовалютой

Сейчас ERPC разрабатывает “Subscription NFTs”. Этот механизм выпускает права подписки в виде NFT, позволяя ими владеть, передавать и перепродавать их, что значительно улучшает процесс оплаты криптовалютой. Релиз запланирован на конец 2025 года. Подробности по ссылке ниже:
Однако на разработку и релиз потребуется время, поэтому, если вы хотите начать платить криптовалютой уже сейчас, мы рекомендуем попробовать сервисы, позволяющие использовать криптовалюту для оплаты как банковской картой:
С помощью этих сервисов вы можете сразу начать оплачивать подписку криптовалютой так же, как обычной банковской картой.

Q. Мне нужна задержка примерно ~400ms или ниже.

Чтобы добиться задержки на уровне примерно 400ms или ниже, учитывайте следующие ключевые моменты:
  • Реалистичное понимание значений ping: Значения ping отражают идеальные условия и не показывают фактическую задержку при потоковой передаче данных, где задержка обычно составляет примерно 5 раз от ping. Например, ping 100ms между континентами на практике означает около 500ms задержки. Поэтому для достижения ~400ms инфраструктуру необходимо размещать в том же регионе.
    • Типичные ориентиры по ping:
      • Одна сеть: ~0.1ms
      • Private Network Interconnect (PNI): ~0.2ms
      • Один дата-центр: ~0.3ms
      • Один город: ~1ms
      • Соседняя страна: ~5–10ms
      • Межконтинентально: ~100–300ms
  • Не полагайтесь на среднюю задержку: Валидаторы Solana географически распределены по всему миру, а leader schedule случайным образом меняется с каждой эпохой. Ориентироваться на среднюю задержку, чтобы добиться ~400ms, непрактично. Вместо этого нужно точно отслеживать расписание валидаторов в нужном вам регионе и выявлять slots с наименьшей задержкой. Чтобы стабильно добиваться минимальной задержки, нужна инфраструктура во всех релевантных регионах. Внутри одного региона данные можно получать за десятки миллисекунд, а передавать за считаные миллисекунды.
  • Отслеживание leader schedule: Непрерывно отслеживайте leader schedule для вашего региона с помощью ERPC Leader Slot API (getLeaderSlots).
    Он предоставляет данные в реальном времени о ближайших лидерах, геолокации валидаторов и эталонных значениях ping, позволяя точно находить оптимальные торговые slots с минимальной задержкой.
    Это снимает ограничения публичных источников данных, таких как Solana Beach или нативные RPC APIs, у которых ниже частота обновления и точность.
Solana Validators Solana Beach

Q. Как добиться zero-block (zero-slot) trading?

Чтобы успешно добиться zero-block (zero-slot) trading, нужны более продвинутые стратегии, в частности:
  • Определение зон возможностей: Валидаторы Solana распределены по всему миру, и физически невозможно обеспечить оптимальную задержку для каждого slot. Поэтому отслеживайте leader schedule валидаторов в регионе, где размещена ваша инфраструктура, и определяйте наиболее выгодные зоны возможностей. Размещение инфраструктуры в нескольких регионах также может дать преимущество. Например, Frankfurt является ключевым регионом из-за высокой плотности валидаторов, поэтому лидеры там выбираются чаще и торговых возможностей больше.
    Используйте ERPC Leader Slot API (getLeaderSlots), чтобы получать leader schedule в реальном времени, геоданные валидаторов и эталонные значения ping с существенно более высокой точностью, чем у Solana Beach или нативных RPC APIs. Это позволяет точнее прогнозировать зоны возможностей и исполнять сделки почти с нулевой задержкой.
  • Развертывание dedicated nodes: Если вам сложно конкурировать, рассмотрите развертывание dedicated nodes. На shared nodes возникает задержка из-за трафика других пользователей, поэтому они не рекомендуются. Кроме того, размещение dedicated node в той же сети, что и ваше приложение, значительно снижает сетевую задержку и оптимизирует производительность.

Q. Как добиться минимально возможной задержки?

Идеальная конфигурация для минимальной задержки - это dedicated RPC node в сочетании с нашими Bare-Metal servers. Они находятся в одной сети и обеспечивают приватную связь с нулевой дистанцией и ping около 0.1ms.
Свяжитесь с нами в Discord, если нужны подробности.

Q. На моей dedicated node низкий процент успешных транзакций

На успешность и скорость транзакций сильно влияет механизм под названием QoS (Quality of Service). Мы предоставляем QoS специально для dedicated nodes. Подробности смотрите на страницах ниже или уточняйте через наш официальный Discord.

Q. Какая здесь задержка?

Задержка зависит от способа измерения и вашей конкретной среды использования. Важнее не точное числовое значение, а то, соответствует ли задержка вашим реальным рабочим требованиям.
Мы предоставляем бесплатный пробный период для всех планов, чтобы вы могли протестировать производительность прямо в вашей реальной среде. Кроме того, у нас есть простые в использовании инструменты на TypeScript и Rust для измерения задержки. Смело используйте их параллельно с бесплатным пробным периодом.

Q. Этот RPC (gRPC, Shreds) быстрее других?

Мы рекомендуем воспользоваться бесплатным пробным периодом и сравнить производительность с другими сервисами. Если окажется, что наш сервис медленнее, сообщите нам в Discord конкретные условия и с какими конкурентами вы сравнивали. Мы разберемся в причине и дополнительно улучшим скорость.
Мы постоянно улучшаем задержку на основе обратной связи клиентов. Если вам нужен максимально быстрый endpoint, поделитесь с нами подробной информацией. Конкретные метрики и условия сравнения с конкурентами помогают нам обеспечивать более высокую производительность. Именно такой подход, основанный на обратной связи, уже не раз позволял нам улучшать сервис.

Q. Какой план обеспечивает самую высокую производительность?

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

Q. У меня высокая задержка. Почему?

Задержка увеличивается с расстоянием до endpoint. Мы рекомендуем подключаться с серверов, расположенных близко к предоставленному endpoint. Самые быстрые среды доступны через наши Bare-Metal servers и VPS services.

Q. Что быстрее: WebSockets, gRPC или Shreds?

По отзывам клиентов порядок производительности обычно такой:
Shreds > gRPC > WebSockets
Если у вас наблюдаются другие результаты, сообщите нам.

Q. Задержка оказалась не такой, как я ожидал.

Производительность может заметно различаться в зависимости от выбранного языка программирования. Обычно порядок такой:
Rust > Go > TypeScript (JavaScript) > Python
Для более подробного сравнения смотрите:
Если вам нужна максимальная производительность, мы настоятельно рекомендуем Rust.