Em qual provedor de RPC você deve construir em Tóquio?

Comparamos cinco dos provedores de RPC que atendem Tóquio em cinco chains. Veja como eles se comparam e onde as diferenças importam para equipes sensíveis à latência.

O Node RPC e os WebSockets da Alchemy já estão no ar em Tóquio, até 8x mais rápidos do que antes. Equipes que constroem no Japão têm uma escolha real de provedores, então os testamos frente a frente de dentro de Tóquio, em Ethereum, Arbitrum, BNB Chain, Polygon e Robinhood Chain, para ajudar você a decidir em qual provedor construir.

Nenhum provedor lidera em tudo. O que importa em fluxos sensíveis à latência é encontrar o provedor que serve ao seu caso de uso, tanto nas respostas típicas quanto nas mais lentas da cauda. Para traders, uma leitura que volta tarde significa um preço defasado e slippage quando o mercado se move.

Como a latência de cauda se compara entre chains?

Somos o único provedor no top dois em todas as cinco chains, e o primeiro em Polygon, BNB Chain e Arbitrum.

Este é o p95, a ponta lenta das respostas de cada provedor, por chain.

A maior diferença está na Polygon. Lá, uma em cada vinte requisições leva mais de 215 ms na QuickNode, contra 44 ms na nossa. A maior parte dessa diferença vem das leituras de estado. O eth_call e o eth_getBalance da QuickNode passam de 215 ms no p95, contra 13 ms e 11 ms nos nossos, e essas são as chamadas que sistemas de trading usam para atualizar cotações e preços.

Em relação ao resto do campo, as diferenças são maiores. Nosso p95 é menor que o da dRPC, Infura e Goldsky em cada chain em que os testamos, 1,5x na Robinhood Chain e até 19x na Arbitrum.

Nesta execução, Alchemy e QuickNode mantiveram taxa de sucesso de 100% em cada chain, exceto a QuickNode com 99,96% na Polygon.

Como os provedores se comparam globalmente?

No nosso benchmark global ao vivo entre chains EVM, a Alchemy tem a menor latência média de qualquer provedor, com 15,54 ms.

Instantâneo ao vivo de alchemy.com/benchmarks, 29 de setembro de 2026, 19:22 UTC. Os números atualizam a cada cinco minutos e vamos adicionar Tóquio em breve para visualizações ao vivo do desempenho; dados brutos em alchemy.com/benchmarks/data.md. Veja a metodologia aqui.

Como medimos

Uma configuração só, aplicada a cada provedor. Enviamos as mesmas leituras EVM JSON-RPC de instâncias controladas de AWS ECS em Tóquio, em contas pagas padrão, com o mesmo aquecimento para cada um. Os provedores rodaram um de cada vez, a 20 requisições por segundo.

As requisições cobriram sete leituras comuns: eth_blockNumber, eth_getBalance, um eth_call leve (um balanceOf() de ERC-20), eth_getBlockByNumber, eth_getLogs em um intervalo de 10 blocos, eth_getBlockReceipts e eth_getTransactionReceipt.

Cada requisição teve uma tentativa, sem novas tentativas. Uma nova tentativa pode esconder uma resposta lenta ou com falha, então toda resposta lenta conta contra o provedor que a deu. O p95 vem da latência p95 apenas das respostas bem-sucedidas, e as falhas são reportadas à parte.

Como testar o RPC que serve à sua aplicação

Nossos resultados são um ponto de partida. O provedor que serve à sua aplicação é o que se sustenta nas suas chains, nos seus métodos e nas regiões onde estão seus usuários ou sistemas. Você pode testar isso com um script e alguns endpoints pagos.

1. Teste as chamadas que seus usuários sentem. Por exemplo, se você constrói uma aplicação de trading em uma chain EVM, teste chamadas como eth_call para cotações e estado do pool, e eth_getBlockByNumber para obter a informação mais recente.

2. Mantenha tudo igual. Envie o mesmo payload a cada provedor, da mesma máquina, na região em que seu app roda. Use as mesmas contas pagas, o mesmo aquecimento, conexões reutilizadas, o mesmo timeout e uma tentativa por requisição, sem novas tentativas. Faça o benchmark de cada chain separadamente, porque um resultado em uma chain não se transfere para outra.

3. Rode tempo suficiente para ver a cauda. Para confiar no p95, colete vários milhares de requisições por provedor em cada chain, em horários diferentes do dia. Teste os provedores no RPS típico de produção para ver como se comportam sob carga real.

4. Leia quatro números juntos.

• Média e p50 da requisição típica
• p95 da ponta lenta, de onde vêm a maioria dos preços defasados e o slippage
• Taxa de sucesso, contando timeouts, limites de taxa e erros como falhas, e deixando requisições com falha fora dos números de latência
• Resultados por método, porque um provedor pode liderar em uma chamada e ficar atrás em outra

Em cargas de trading, meça também com que rapidez cada provedor entrega blocos novos.

Comece a construir em Tóquio

Fale com nosso time sobre suas chains e métodos, ou comece no dashboard.

Perguntas frequentes

A Alchemy é mais rápida que a QuickNode em Tóquio?

Depende da sua carga. Na Polygon, no p95, a Alchemy é cerca de 17x mais rápida que a QuickNode em uma leitura de contrato ou de saldo (eth_call e eth_getBalance). No p95, a ponta lenta, a Alchemy é quase 5x mais rápida na Polygon e 1,6x mais rápida na BNB Chain. Em Ethereum, Arbitrum e Robinhood Chain, as duas ficam a cerca de 5 ms uma da outra no p95, então teste as chains e as chamadas das quais sua carga depende.

Como uso a infraestrutura da Alchemy em Tóquio? Preciso mudar meu endpoint?

Use seu endpoint da Alchemy. Nenhuma configuração é necessária. Roteamos as requisições automaticamente para a região disponível mais próxima.

Quais redes são servidas a partir de Tóquio?

A infraestrutura da Alchemy em Tóquio começa com Base, BNB Chain, Robinhood Chain, Ethereum, Polygon, Arbitrum, HyperEVM, Arc e outras. A Alchemy construiu relações com mais de 100 chains em quase 10 anos, e seguimos adicionando redes a Tóquio de forma contínua.