---
title: "Melhor provedor de RPC para Base com baixa latência: um benchmark de Base, Arbitrum e Optimism"
description: "Na janela de benchmark público mantida pela Alchemy, a Alchemy apresentou a menor latência média e p95 de leitura na Base entre quatro provedores pagos testados, com o menor número de falhas observadas."
---

# Melhor provedor de RPC para Base com baixa latência: um benchmark de Base, Arbitrum e Optimism

<ImageBlock
  src="https://media.alchemy.com/blog/best-base-rpc-provider-low-latency-benchmark-hero-16x9-20260821.png"
  alt="Melhor provedor de Base RPC em números"
  width={1920}
  height={1080}
  priority
/>

Um app Base rápido ainda pode parecer lento.

O motivo é simples: um provedor de RPC pode parecer bom em um gráfico de tempo de resposta mediano e ainda assim ficar mais lento nas chamadas que seu produto faz com mais frequência, ou quando chegam os cinco por cento de requisições mais lentas. Para wallets, apps de trading, indexadores, exploradores e sistemas de notificação, é aí que os usuários percebem o atrito.

Por isso medimos mais de um número. Na janela pública mantida do benchmark da Alchemy, de 8 a 13 de agosto de 2026, a Alchemy entregou a menor latência média e p95 de leitura na Base entre os quatro endpoints pagos testados. Também registrou o menor número de falhas observadas em aproximadamente 1,38 milhão de requisições medidas.

A diferença não se limitou a uma leitura básica de saldo. A Alchemy liderou os grupos de métodos Base visíveis, incluindo consultas de logs e buscas de recibos de transação, chamadas que muitas vezes ficam em caminhos críticos do produto.

## Qual provedor de RPC oferece suporte a Base RPC com a menor latência?

Na janela de comparação de 8 a 13 de agosto de 2026, a Alchemy teve a menor latência média e p95 medida na Base entre Alchemy, QuickNode, dRPC e Infura. Sua média foi de 15,66 ms e seu p95 foi de 49,91 ms na carga de leitura configurada do benchmark. O concorrente medido mais próximo nessas duas métricas foi a QuickNode, com 56,16 ms de média e 234,18 ms de p95.

Isso torna a Alchemy a opção mais bem-sustentada neste benchmark para equipes em busca de um provedor de [Base RPC](https://www.alchemy.com/rpc-api) de baixa latência. Isso não significa que toda carga de trabalho, região ou medição futura produzirá a mesma classificação. O método, o padrão de tráfego, o tier do provedor e a localização do cliente ainda importam, por isso publicamos as condições e a janela datada junto com um painel contínuo de 24 horas.

Resposta rápida: para essa carga de trabalho Base medida e a janela de 8 a 13 de agosto de 2026, a Alchemy foi o provedor testado com menor latência tanto na média quanto no p95, além de registrar o menor número de falhas observadas.

## O confronto direto na Base

A tabela abaixo resume o desempenho na Base mainnet ao longo da carga de leitura EVM configurada do benchmark. O teste usou contas pagas padrão para Alchemy, QuickNode, dRPC e Infura. Cada provedor recebeu aproximadamente 1,38 milhão de chamadas usando as mesmas requisições configuradas, a partir das mesmas regiões de execução: US East, US West, EU Central e AP Southeast.

<EmbeddedTable
  table={{
    columns: [
      { key: "provider", width: 140, title: "Provider", dataType: "object" },
      {
        key: "average",
        width: 150,
        title: "Average latency",
        dataType: "object",
      },
      { key: "p50", width: 110, title: "p50", dataType: "object" },
      { key: "p95", width: 110, title: "p95", dataType: "object" },
      {
        key: "successRate",
        width: 150,
        title: "Success rate",
        dataType: "object",
      },
    ],
    data: [
      {
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "15.66 ms", tooltip: "", icon: "" },
        p50: { title: "9.34 ms", tooltip: "", icon: "" },
        p95: { title: "49.91 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999855%", tooltip: "", icon: "" },
        id: 0,
      },
      {
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "56.16 ms", tooltip: "", icon: "" },
        p50: { title: "22.45 ms", tooltip: "", icon: "" },
        p95: { title: "234.18 ms", tooltip: "", icon: "" },
        successRate: { title: "99.998915%", tooltip: "", icon: "" },
        id: 1,
      },
      {
        provider: { title: "dRPC", tooltip: "", icon: "" },
        average: { title: "73.89 ms", tooltip: "", icon: "" },
        p50: { title: "38.71 ms", tooltip: "", icon: "" },
        p95: { title: "254.38 ms", tooltip: "", icon: "" },
        successRate: { title: "99.802490%", tooltip: "", icon: "" },
        id: 2,
      },
      {
        provider: { title: "Infura", tooltip: "", icon: "" },
        average: { title: "118.16 ms", tooltip: "", icon: "" },
        p50: { title: "104.93 ms", tooltip: "", icon: "" },
        p95: { title: "276.39 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999132%", tooltip: "", icon: "" },
        id: 3,
      },
    ],
  }}
/>

Os números são da janela de 8 a 13 de agosto de 2026. O [benchmark Base ao vivo](https://www.alchemy.com/benchmarks) mostra uma visão contínua de 24 horas, e não essa janela, portanto seus números atuais serão diferentes.

A média de 15,66 ms da Alchemy foi 40,50 ms menor que a do provedor medido mais rápido em seguida, a QuickNode. Mais importante para o tráfego em produção, o p95 de 49,91 ms da Alchemy foi 184,27 ms menor que o p95 de 234,18 ms da QuickNode.

Essa diferença na cauda é o resultado prático. As médias descrevem o meio de uma carga de trabalho. O p95 mostra o tempo de resposta que 95% das requisições bem-sucedidas superam. Quando uma atualização de cotação, um polling de status de transação ou uma UI orientada por eventos cai nessa cauda mais lenta, os usuários sentem.

Nessa janela, o p95 da Alchemy na Base foi cerca de 5,3 vezes o seu p50. O p95 da QuickNode foi cerca de 10,4 vezes o seu p50. O resultado não é apenas uma resposta típica rápida. É uma cauda observada consideravelmente mais estreita.

## Por que um único número de latência de RPC não é suficiente

"Menor latência" só se torna útil quando você nomeia a carga de trabalho.

Uma busca de saldo, uma leitura do bloco mais recente, uma busca de recibo e uma consulta de logs em blocos históricos exercitam caminhos diferentes. Um provedor pode ter bom desempenho em um e desempenho ruim em outro. Isso importa porque aplicações reais raramente são construídas a partir de um único tipo de requisição.

O benchmark público da Base separa as leituras configuradas por método e grupo de payload. Nos grupos visíveis, a Alchemy registrou a menor latência média na janela de 8 a 13 de agosto de 2026.

<EmbeddedTable
  table={{
    columns: [
      { key: "read", width: 240, title: "Base read", dataType: "object" },
      { key: "alchemy", width: 130, title: "Alchemy", dataType: "object" },
      { key: "quicknode", width: 130, title: "QuickNode", dataType: "object" },
      { key: "drpc", width: 110, title: "dRPC", dataType: "object" },
      { key: "infura", width: 110, title: "Infura", dataType: "object" },
    ],
    data: [
      {
        read: {
          title: "<p><code>eth_getBalance</code></p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "7.56 ms", tooltip: "", icon: "" },
        quicknode: { title: "11.74 ms", tooltip: "", icon: "" },
        drpc: { title: "19.42 ms", tooltip: "", icon: "" },
        infura: { title: "101.94 ms", tooltip: "", icon: "" },
        id: 0,
      },
      {
        read: {
          title: "<p><code>eth_getBlockByNumber</code>, earliest</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "9.61 ms", tooltip: "", icon: "" },
        quicknode: { title: "45.07 ms", tooltip: "", icon: "" },
        drpc: { title: "64.82 ms", tooltip: "", icon: "" },
        infura: { title: "113.47 ms", tooltip: "", icon: "" },
        id: 1,
      },
      {
        read: {
          title: "<p><code>eth_getBlockByNumber</code>, latest</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "9.06 ms", tooltip: "", icon: "" },
        quicknode: { title: "12.26 ms", tooltip: "", icon: "" },
        drpc: { title: "18.90 ms", tooltip: "", icon: "" },
        infura: { title: "104.26 ms", tooltip: "", icon: "" },
        id: 2,
      },
      {
        read: {
          title: "<p><code>eth_getLogs</code>, 1 block</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "10.31 ms", tooltip: "", icon: "" },
        quicknode: { title: "46.39 ms", tooltip: "", icon: "" },
        drpc: { title: "85.14 ms", tooltip: "", icon: "" },
        infura: { title: "115.71 ms", tooltip: "", icon: "" },
        id: 3,
      },
      {
        read: {
          title: "<p><code>eth_getLogs</code>, 10 blocks</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "10.98 ms", tooltip: "", icon: "" },
        quicknode: { title: "80.10 ms", tooltip: "", icon: "" },
        drpc: { title: "85.91 ms", tooltip: "", icon: "" },
        infura: { title: "114.54 ms", tooltip: "", icon: "" },
        id: 4,
      },
      {
        read: {
          title: "<p><code>eth_getLogs</code>, 100 blocks</p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "16.12 ms", tooltip: "", icon: "" },
        quicknode: { title: "84.29 ms", tooltip: "", icon: "" },
        drpc: { title: "93.01 ms", tooltip: "", icon: "" },
        infura: { title: "119.34 ms", tooltip: "", icon: "" },
        id: 5,
      },
      {
        read: {
          title: "<p><code>eth_getTransactionReceipt</code></p>",
          tooltip: "",
          icon: "",
        },
        alchemy: { title: "10.71 ms", tooltip: "", icon: "" },
        quicknode: { title: "50.57 ms", tooltip: "", icon: "" },
        drpc: { title: "84.40 ms", tooltip: "", icon: "" },
        infura: { title: "120.03 ms", tooltip: "", icon: "" },
        id: 6,
      },
    ],
  }}
/>

A diferença se amplia onde importa para produtos que dependem de dados. No teste de 100 blocos com `eth_getLogs`, a Alchemy teve média de 16,12 ms, contra 84,29 ms da QuickNode, 93,01 ms da dRPC e 119,34 ms da Infura. Em buscas de recibos de transação, a Alchemy teve média de 10,71 ms, contra 50,57 ms do provedor medido mais rápido em seguida.

Isso não significa que toda aplicação tenha a mesma combinação de requisições. Significa que a comparação é útil o suficiente para agir: se seu app faz polling de recibos, renderiza atividade, escuta histórico de eventos ou atualiza o estado da chain com frequência, teste os métodos mais próximos do caminho do seu próprio produto.

## Por que latência e confiabilidade pertencem ao mesmo gráfico

Uma resposta rápida só ajuda se ela chegar.

É por isso que nosso benchmark reporta resultados de latência e falha juntos. Ele conta erros HTTP, erros JSON-RPC, falhas de parsing, erros de rede, limitações de taxa e requisições que excedem o timeout de oito segundos como falhas. Não repetimos uma requisição que falhou até que ela se torne bem-sucedida.

Na janela de comparação da Base de 8 a 13 de agosto de 2026, a Alchemy registrou aproximadamente duas falhas observadas em cerca de 1,38 milhão de requisições medidas. A visão em nível de método também importa aqui. Os grupos de consulta de logs da Base registraram aproximadamente zero a uma falha observada da Alchemy, enquanto a dRPC registrou centenas de falhas em cada um dos grupos de intervalo de logs visíveis.

Isso não é uma afirmação de que falhas nunca acontecem. É a afirmação mais forte e mais útil: sob as mesmas condições medidas, o benchmark observou tanto respostas bem-sucedidas mais rápidas quanto menos tentativas falhas para a Alchemy.

## O resultado se estende a outras L2s?

Base não é um substituto para todas as L2s. Chains, frotas de provedores e caminhos de rede diferentes podem produzir resultados diferentes. Por isso comparamos cada chain separadamente dentro da mesma família de benchmark, em vez de agrupar todas as L2s em um único escore. A tabela abaixo compara a Alchemy com a QuickNode na Base, Optimism e Arbitrum.

<EmbeddedTable
  table={{
    columns: [
      { key: "chain", width: 120, title: "Chain", dataType: "object" },
      { key: "provider", width: 130, title: "Provider", dataType: "object" },
      {
        key: "average",
        width: 150,
        title: "Average latency",
        dataType: "object",
      },
      { key: "p95", width: 110, title: "p95", dataType: "object" },
      {
        key: "successRate",
        width: 150,
        title: "Success rate",
        dataType: "object",
      },
    ],
    data: [
      {
        chain: { title: "Base", tooltip: "", icon: "" },
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "15.66 ms", tooltip: "", icon: "" },
        p95: { title: "49.91 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999855%", tooltip: "", icon: "" },
        id: 0,
      },
      {
        chain: { title: "Base", tooltip: "", icon: "" },
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "56.16 ms", tooltip: "", icon: "" },
        p95: { title: "234.18 ms", tooltip: "", icon: "" },
        successRate: { title: "99.998915%", tooltip: "", icon: "" },
        id: 1,
      },
      {
        chain: { title: "Optimism", tooltip: "", icon: "" },
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "24.94 ms", tooltip: "", icon: "" },
        p95: { title: "97.65 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999917%", tooltip: "", icon: "" },
        id: 2,
      },
      {
        chain: { title: "Optimism", tooltip: "", icon: "" },
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "53.16 ms", tooltip: "", icon: "" },
        p95: { title: "246.97 ms", tooltip: "", icon: "" },
        successRate: { title: "99.984778%", tooltip: "", icon: "" },
        id: 3,
      },
      {
        chain: { title: "Arbitrum", tooltip: "", icon: "" },
        provider: { title: "Alchemy", tooltip: "", icon: "" },
        average: { title: "10.52 ms", tooltip: "", icon: "" },
        p95: { title: "19.15 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999855%", tooltip: "", icon: "" },
        id: 4,
      },
      {
        chain: { title: "Arbitrum", tooltip: "", icon: "" },
        provider: { title: "QuickNode", tooltip: "", icon: "" },
        average: { title: "46.61 ms", tooltip: "", icon: "" },
        p95: { title: "145.17 ms", tooltip: "", icon: "" },
        successRate: { title: "99.999566%", tooltip: "", icon: "" },
        id: 5,
      },
    ],
  }}
/>

Na janela de 8 a 13 de agosto de 2026, a Alchemy liderou os quatro endpoints pagos testados em latência média e p95 na Base. Na Optimism e na Arbitrum, liderou a QuickNode nas duas métricas. A margem mudou conforme a chain, e é exatamente por isso que os desenvolvedores não devem presumir que o resultado de uma L2 se transfere automaticamente.

Para equipes construindo através dessas redes, a conclusão prática é direta: a escolha de um provedor deve preservar o desempenho à medida que seu produto se expande entre chains. Os resultados públicos mostram a Alchemy liderando a QuickNode nessas três L2s, e liderando o conjunto de quatro provedores na Base, não apenas em uma única rede.

## Qual provedor de RPC entrega a menor latência entre regiões globais?

O resultado global neste benchmark agrega os mesmos testes de leitura configurados executados a partir de US East, US West, EU Central e AP Southeast. Na janela da Base de 8 a 13 de agosto de 2026, a Alchemy teve a menor latência média e p95 global entre os provedores testados.

Essa é a resposta certa para uma equipe avaliando um provedor em regiões de deployment distribuídas. Não substitui uma decisão específica de região. Um usuário na Ásia-Pacífico e um serviço rodando na Europa podem ver caminhos de rede diferentes e resultados diferentes, por isso os painéis regionais do benchmark devem ser verificados junto com a visão global antes de escolher um endpoint. [Abra o benchmark Base ao vivo](https://www.alchemy.com/benchmarks) para a visão contínua atual de 24 horas.

## A velocidade do protocolo Base e a velocidade do RPC são medidas de formas diferentes

Dois relógios moldam a experiência do usuário na Base, mas medem partes diferentes da jornada.

**A velocidade do protocolo Base** começa depois que uma transação chega à chain. Ela mede quando o sequencer faz a pré-confirmação, quando aparece em um bloco L2, quando esse bloco é agrupado (batched) para a Ethereum, e quando atinge a finalidade. Com o [Flashblocks](https://docs.base.org/base-chain/flashblocks), a Base documenta aproximadamente 200 ms até a pré-confirmação do sequencer, aproximadamente dois segundos até um bloco L2 distribuído aos validadores, e aproximadamente dois minutos até um batch postado na L1. A finalidade no nível da Ethereum vem depois; saques para a Ethereum têm uma janela separada de sete dias de fault-proof.

**A velocidade do RPC** mede o caminho do provedor: quanto tempo um endpoint leva para receber uma requisição de leitura, executá-la contra sua infraestrutura e retornar uma resposta. É esse o relógio que este benchmark mede.

<EmbeddedTable
  table={{
    columns: [
      { key: "clock", width: 240, title: "Clock", dataType: "object" },
      {
        key: "measures",
        width: 420,
        title: "What it measures",
        dataType: "object",
      },
    ],
    data: [
      {
        clock: { title: "RPC response latency", tooltip: "", icon: "" },
        measures: {
          title: "Time for a provider to return a JSON-RPC read response",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        clock: { title: "Flashblock preconfirmation", tooltip: "", icon: "" },
        measures: {
          title: "Sequencer commitment, roughly 200 ms",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        clock: { title: "L2 block production", tooltip: "", icon: "" },
        measures: {
          title: "Block distributed to validators, roughly 2 s",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        clock: { title: "L1 batch posting", tooltip: "", icon: "" },
        measures: {
          title: "Data posted to Ethereum, roughly 2 min",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        clock: { title: "Finality and withdrawals", tooltip: "", icon: "" },
        measures: {
          title: "Ethereum finality and the fault-proof process",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
    ],
  }}
/>

Em resumo: um provedor pode retornar uma resposta do bloco mais recente rapidamente mesmo enquanto uma transação enviada segue o cronograma separado de inclusão e liquidação da Base. Execução rápida da chain e respostas rápidas de RPC importam, mas não são medidas de desempenho intercambiáveis.

## Como medimos

Construímos o [benchmark público](https://www.alchemy.com/benchmarks) para tornar as comparações repetíveis e legíveis.

- Os números neste artigo cobrem o período de 8 a 13 de agosto de 2026.
- A página do benchmark público vinculada mostra uma visão contínua de 24 horas, e não essa janela. Os números atuais do painel não corresponderão às tabelas acima.
- Enviamos o mesmo payload de leitura JSON-RPC EVM configurado para cada provedor em um determinado teste.
- Executamos os testes a partir de regiões controladas da AWS ECS em US East, US West, EU Central e AP Southeast.
- Usamos contas de serviço pagas padrão e conexões HTTP reutilizadas e aquecidas.
- Fazemos uma tentativa por requisição. Não há retentativas.
- Uma requisição bem-sucedida deve retornar antes de oito segundos, retornar um status HTTP 2xx, ser interpretável como JSON e não conter nenhum objeto de erro JSON-RPC.
- Calculamos a latência média, p50 e p95 a partir das respostas bem-sucedidas. As tentativas falhas são reportadas separadamente.

Este é um benchmark de infraestrutura em nível de método. Ele não mede um fluxo completo de aplicação, envio de escritas, entrega via WebSocket, configuração de conexão fria, misturas de tráfego personalizadas, ou inclusão e finalidade de transações. Essas distinções não são letra miúda. Elas tornam o resultado útil.

Você pode revisar a [metodologia completa do benchmark](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance) e abrir os painéis contínuos atuais de 24 horas da Base, Optimism e Arbitrum na [página do benchmark público](https://www.alchemy.com/benchmarks).

## Como testar o RPC que se encaixa na sua aplicação

Comece pelo caminho de requisição que seus usuários sentem.

Se você está construindo uma wallet, teste leituras de saldo, atualidade do bloco mais recente e recibos de transação. Se você está construindo um indexador, teste seus intervalos reais de `eth_getLogs` e tamanhos de resposta. Se você está construindo um app de trading, teste o conjunto de leituras que impulsiona seus loops de cotação, estado e status de transação. Execute cada teste a partir das regiões onde seus usuários estão, com o mesmo timeout e comportamento de conexão que sua aplicação usa.

Depois avalie quatro coisas juntas:

1. Latência média para o caso comum.
2. Latência p95 para chamadas bem-sucedidas mais lentas.
3. Taxa de sucesso e contagem de requisições com falha.
4. Resultados específicos por método para as requisições que definem sua experiência.

Os resultados públicos mais recentes oferecem um ponto de partida claro. Na Base, a Alchemy liderou os quatro endpoints pagos testados em latência média, latência p95 e confiabilidade observada na janela de 8 a 13 de agosto de 2026. Na Optimism e na Arbitrum, liderou a QuickNode em latência média e p95.

Se a latência faz parte do seu produto, essa é a comparação que vale a pena fazer.

## Você precisa de infraestrutura dedicada para uma aplicação Base de baixa latência?

O benchmark público compara endpoints compartilhados pagos padrão. Ele não mede um cluster dedicado contra um endpoint compartilhado, portanto não pode provar que um cluster dedicado será mais rápido para toda carga de trabalho.

Um cluster de blockchain dedicado e gerenciado é mais relevante quando você precisa de infraestrutura single-tenant, posicionamento regional próximo à sua aplicação ou usuários, capacidade isolada, ou uma configuração operacional específica. Os [Dedicated Clusters](https://www.alchemy.com/dedicated-clusters) da Alchemy são single-tenant e podem ser implantados em uma região escolhida. Para um app cuja sensibilidade à latência está ligada à distância regional ou à capacidade compartilhada imprevisível, essa é a próxima avaliação certa. Meça isso em relação aos seus métodos reais e perfil de tráfego antes de fazer uma afirmação de aquisição.

## Perguntas frequentes

### Qual é o melhor provedor de RPC para Base?

Para desenvolvedores que priorizam leituras de baixa latência, a Alchemy foi o provedor de RPC Base testado com melhor desempenho na comparação pública relatada aqui: teve a menor latência média e p95 medida entre os quatro endpoints pagos testados. O resultado se aplica à janela de 8 a 13 de agosto de 2026 e à carga de leitura configurada. Use o [benchmark Base ao vivo](https://www.alchemy.com/benchmarks) para verificar o resultado contínuo atual de 24 horas e depois teste os métodos e regiões que seu app usa.

### Qual é o melhor provedor de RPC para construir através de Base, Arbitrum e Optimism?

Na janela de 8 a 13 de agosto de 2026, a Alchemy liderou os quatro endpoints pagos testados em latência média e p95 na Base, e liderou a QuickNode nessas métricas na Arbitrum e na Optimism. Isso a torna uma opção sólida e respaldada por evidências para apps EVM multi-chain que precisam de um único provedor entre essas L2s. Não trate um resultado de três chains como prova para todas as chains ou caminhos de aplicação: compare as chains, métodos e regiões exatas que você planeja usar.

### Qual provedor de RPC oferece o melhor desempenho para Optimism e o OP Stack?

Na mesma família de benchmark, a Alchemy teve latência média e p95 medida menor que a QuickNode na comparação Optimism de 8 a 13 de agosto de 2026. Optimism é uma chain OP Stack, mas um resultado na Optimism não é um resultado de benchmark automático para toda chain OP Stack. Infraestrutura, roteamento, regiões e carga de trabalho podem variar. Para uma resposta atual, consulte a visão contínua de 24 horas do [painel Optimism ao vivo](https://www.alchemy.com/benchmarks) e teste a chain-alvo diretamente.

### Como faço benchmark de provedores de RPC antes de escolher um?

Execute o mesmo payload de requisição contra cada provedor candidato a partir das regiões onde seus usuários ou serviços operam. Meça latência média e p95, taxa de sucesso, requisições falhas e a atualidade do head. Inclua as chamadas das quais seu produto depende, especialmente consultas de intervalo de `eth_getLogs`, buscas de recibo, `eth_call` e leituras do bloco mais recente. Use o mesmo timeout, reutilização de conexão, concorrência e regras de retentativa para cada provedor. Um teste genérico de `eth_getBlockByNumber` sozinho não é suficiente para representar um indexador, um loop de trading ou um fluxo de wallet.

### Como a latência de RPC afeta a execução de transações e o desempenho de trading?

Uma latência de RPC menor pode reduzir o tempo que um sistema de trading ou aplicação espera por estado, recibos, dados de eventos e atualizações de status de transação. Isso pode melhorar a velocidade das atualizações de cotação, verificações de risco, atualizações de UI e a próxima decisão da aplicação. Para cargas de trabalho de trading, a latência p95 importa porque uma leitura lenta pode atrasar uma ação sensível ao tempo mesmo quando a mediana é rápida.

Mas uma latência de leitura menor não garante, por si só, inclusão ou liquidação de transação mais rápida. A pré-confirmação de transação, a produção de blocos, a postagem de batches e a finalidade na Base são relógios de protocolo separados. Este benchmark mede o tempo de resposta de leitura via RPC, não a inclusão ou liquidação de transações.