Какого RPC-провайдера выбрать для разработки в Токио?

Источник: Alchemy•

Какого RPC-провайдера выбрать для разработки в Токио?

Мы провели сравнительный анализ пяти RPC-провайдеров, работающих в Токио, на пяти блокчейнах. Вот как они соотносятся друг с другом и почему различия важны для команд, чувствительных к задержкам.

Мы провели сравнительный анализ пяти RPC-провайдеров, работающих в Токио, на пяти блокчейнах. Вот как они соотносятся друг с другом и почему различия важны для команд, чувствительных к задержкам.

Узлы Alchemy RPC и WebSockets теперь доступны в Токио, работая до 8 раз быстрее, чем раньше. У команд, ведущих разработку в Японии, есть реальный выбор провайдеров, поэтому мы протестировали их напрямую из Токио на сетях Ethereum, Arbitrum, BNB Chain, Polygon и Robinhood Chain, чтобы помочь вам решить, на какого провайдера стоит положиться.

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

Как сравнивается «хвостовая» задержка (tail latency) в разных сетях?

Мы — единственный провайдер, вошедший в двойку лидеров во всех пяти сетях, и занявший первое место в Polygon, BNB Chain и Arbitrum.

Ниже представлены показатели p95 (медленный сегмент ответов) для каждого провайдера в разрезе сетей.

Провайдер

Polygon

BNB Chain

Ethereum

Arbitrum

Robinhood

Alchemy

44.4 мс

54.1 мс

23.4 мс

10.1 мс

17.5 мс

QuickNode

215.9 мс

88.5 мс

18.3 мс

10.6 мс

16.8 мс

Infura

307.1 мс

724.9 мс

197.5 мс

190.0 мс

Не поддерживается

dRPC

124.9 мс

129.4 мс

178.0 мс

18.4 мс

26.2 мс

Goldsky

278.2 мс

282.0 мс

95.2 мс

152.3 мс

75.6 мс

Самый большой разрыв наблюдается в сети Polygon. Там один из двадцати запросов занимает более 215 мс у QuickNode против 44 мс у нас. Большая часть этого разрыва связана с чтением состояния. Методы eth_call и eth_getBalance у QuickNode занимают более 215 мс на уровне p95, тогда как у нас — 13 мс и 11 мс соответственно; именно эти вызовы используют торговые системы для обновления котировок и цен.

По сравнению с остальными участниками рынка разрывы еще больше. Наш показатель p95 ниже, чем у dRPC, Infura и Goldsky в каждой протестированной сети: в 1,5 раза в Robinhood Chain и до 19 раз в Arbitrum.

В этом тесте Alchemy и QuickNode показали 100% успешность во всех сетях, за исключением Polygon, где у QuickNode показатель составил 99,96%.

Как провайдеры соотносятся в глобальном масштабе?

В нашем текущем глобальном бенчмарке по EVM-сетям Alchemy имеет самую низкую среднюю задержку среди всех провайдеров — 15,54 мс.

Провайдер

Средняя задержка

p50

p95

Успешность

Alchemy

15.54 мс

7.32 мс

32.03 мс

99.99%

QuickNode

41.81 мс

9.57 мс

194.20 мс

99.99%

dRPC

100.88 мс

22.76 мс

565.66 мс

99.99%

Infura

117.66 мс

104.11 мс

276.26 мс

99.99%

Goldsky

41.38 мс

14.45 мс

138.86 мс

99.98%

Снимок данных в реальном времени с alchemy.com/benchmarks, 29 сентября 2026 г., 19:22 UTC. Цифры обновляются каждые пять минут, и скоро мы добавим Токио для просмотра производительности в реальном времени; необработанные данные доступны на alchemy.com/benchmarks/data.md. Ознакомьтесь с методологией здесь.

Как мы проводили тестирование

Единая настройка, примененная к каждому провайдеру. Мы отправляли идентичные EVM JSON-RPC запросы на чтение с контролируемых инстансов AWS ECS в Токио, используя стандартные платные аккаунты с одинаковым прогревом для каждого. Провайдеры тестировались по очереди при стабильной нагрузке 20 запросов в секунду.

Запросы охватывали семь распространенных операций чтения: eth_blockNumber, eth_getBalance, легкий eth_call (ERC-20 balanceOf()), eth_getBlockByNumber, eth_getLogs в диапазоне 10 блоков, eth_getBlockReceipts и eth_getTransactionReceipt.

Каждый запрос выполнялся один раз без повторных попыток. Повторная попытка может скрыть медленный или неудачный ответ, поэтому каждый медленный ответ засчитывается против провайдера, который его предоставил. Результат p95 рассчитывается на основе отслеживания задержки только успешных ответов, а сбои фиксируются отдельно.

Как протестировать RPC, подходящий для вашего приложения

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

1. Тестируйте вызовы, которые влияют на пользователей. Например, если вы создаете торговое приложение в EVM-сети, тестируйте такие вызовы, как eth_call для получения котировок и состояния пула, а также eth_getBlockByNumber для получения актуальной информации.

2. Сохраняйте условия неизменными. Отправляйте идентичные полезные нагрузки каждому провайдеру с одной и той же машины в регионе, где работает ваше приложение. Используйте одинаковые платные аккаунты, одинаковый прогрев, повторно используемые соединения, одинаковый тайм-аут и одну попытку на запрос без повторов. Тестируйте каждую сеть отдельно, так как результат в одной сети не переносится на другую.

3. Тестируйте достаточно долго, чтобы увидеть «хвост» распределения. Чтобы доверять показателю p95, соберите несколько тысяч запросов для каждого провайдера в каждой сети в разное время суток. Тестируйте провайдеров при типичной для вас производственной нагрузке (RPS), чтобы увидеть, как они работают в реальных условиях.

4. Анализируйте четыре показателя вместе.

  • Среднее значение и p50 для типичного запроса
  • p95 для медленного сегмента, где чаще всего возникают устаревшие цены и проскальзывание
  • Уровень успешности, учитывающий тайм-ауты, лимиты запросов и ошибки как сбои, исключая неудачные запросы из показателей задержки
  • Результаты по методам, так как провайдер может лидировать в одном вызове и отставать в другом

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

Начните разработку в Токио

Свяжитесь с нашей командой, чтобы обсудить ваши сети и методы, или начните работу в панели управления.

Часто задаваемые вопросы

Является ли Alchemy быстрее, чем QuickNode в Токио?

Это зависит от вашей рабочей нагрузки. В сети Polygon Alchemy примерно в 17 раз быстрее, чем QuickNode по показателю p95 при чтении контракта или баланса (eth_call и eth_getBalance). На уровне p95 (медленный сегмент) Alchemy почти в 5 раз быстрее в Polygon и в 1,6 раза быстрее в BNB Chain. В сетях Ethereum, Arbitrum и Robinhood Chain показатели обоих провайдеров различаются не более чем на 5 мс на уровне p95, поэтому тестируйте именно те сети и вызовы, от которых зависит ваша нагрузка.

Как я могу использовать инфраструктуру Alchemy в Токио? Нужно ли мне менять эндпоинт?

Используйте свой эндпоинт Alchemy. Никакой настройки не требуется. Мы автоматически направляем запросы в ближайший доступный регион.

Какие сети обслуживаются из Токио?

Инфраструктура Alchemy в Токио запускается с поддержкой Base, BNB Chain, Robinhood Chain, Ethereum, Polygon, Arbitrum, HyperEVM, Arc и других. За почти 10 лет работы Alchemy выстроила партнерские отношения с более чем 100 сетями, и мы на постоянной основе добавляем новые сети в Токио.

О чём эта статья

Ещё в разделе «Web3 и блокчейн»

Все →

Ещё от Alchemy