Como escolher um provedor RPC

Escolha um provedor RPC pelo custo e pela confiabilidade para concluir sua tarefa real: primeiro verifique redes, métodos e cobertura histórica; depois meça a quantidade de consultas, a taxa de transferência e a capacidade de recuperação.

Liste as redes, os métodos, os blocos fixos, a distribuição diária de tráfego, o pico de concorrência e as dependências de notificações ou conjuntos de dados de que sua aplicação ou AI Agent precisa. Os valores públicos da BlockVectra abaixo vêm de GET /v1/plans e GET /v1/chains; consulte-os novamente antes de tomar uma decisão. A cobertura de dados vem de GET /v1/status. Uma declaração é o ponto de partida para um teste, não uma medição de latência ou um SLA.

Preços dos métodos e unidades de cobrança

Apenas o número de requisições não precifica uma carga de trabalho. Registre o peso de cobrança de cada método, a conversão para USD, os créditos incluídos, o excedente e qualquer taxa de assinatura ou serviço adicional. Créditos, CU e unidades de requisição precisam de sua própria conversão antes de comparar provedores.

Os pesos atuais de métodos e os preços de tabela da BlockVectra são lidos do endpoint público de planos quando a página é construída:

workload_cu = sum(calls_for_method × current_method_cu_weight)
cu_per_usd = pricing.units_per_usd × pricing.cu_per_unit
list_cost_usd = workload_cu / cu_per_usd
paid_compute_usd = max(0, workload_cu − available_free_cu) / cu_per_usd

Os preços de tabela excluem créditos gratuitos, gas, serviços adicionais e trabalho de migração. Distinga uma cota recorrente de um período de teste que expira, e o preço de créditos adicionais do custo médio das requisições incluídas. Consulte as regras de cobrança para saber quais respostas consomem CU.

Autoteste: reproduza uma amostragem pequena e representativa de métodos com blocos fixos e registre chamadas bem-sucedidas, novas tentativas e erros tarifáveis. Compare a alteração de uso da conta com o cálculo por peso de métodos. Calcule o orçamento pelo número de requisições que retornaram o resultado completo, incluindo paginação e preenchimento de histórico. Consulte Entendendo a precificação por CU para a conversão.

Intervalos de logs e estado histórico

Para eth_getLogs, verifique o intervalo de blocos, os limites de tamanho de resultado e o suporte a filtros para a rede e o plano específicos. Um intervalo amplo só é útil se a resposta for completa. Os intervalos autenticados da BlockVectra vêm do catálogo de redes:

Logs históricos e execução histórica de contratos são capacidades diferentes. Para eth_call, consulte state_window_blocks; para leituras sem chave, consulte também public.history_blocks. Um campo ausente ou nulo indica que não foi especificado, e não prova de histórico ilimitado. Consulte estado histórico da EVM.

Autoteste: escolha um intervalo fixo com um contrato e tópicos conhecidos, divida-o no intervalo declarado e compare a união dos resultados com consultas menores sobrepostas. Remova duplicatas por hash de bloco, hash de transação e índice de log, e verifique os limites dos intervalos. Leia separadamente o mesmo contrato em um bloco fixo recente e no bloco mais antigo exigido pela sua aplicação; registre o resultado real ou o erro JSON-RPC. Teste intervalos densos e esparsos e contabilize novas tentativas. Siga o guia intervalo de logs e recuperação para salvar pontos de verificação de progresso.

Créditos gratuitos, limites de taxa e pico de tráfego

O orçamento atual do ciclo da BlockVectra e as chamadas que ele pode cobrir são calculados a partir dos planos:

Limite de chamadas para contas gratuitas: até 25 chamadas por segundo, compartilhadas entre todas as chaves da conta, todas as redes e a Data API. Cada chave também possui limites de cu_per_sec e burst_cu. Uma renovação de ciclo elegível completa o saldo gratuito até sua meta; não se trata de uma concessão integral adicional. A primeira recarga paga interrompe as renovações de ciclo, preservando as CU gratuitas restantes. Consulte as regras do plano gratuito.

Mantenha cotas diárias, saldos de ciclo, requisições/s, CU/s, capacidade de rajada e requisições simultâneas separados. Pagar por mais uso não estabelece por si só uma taxa de transferência maior por chave.

Autoteste: use uma chave autenticada e um lote pequeno e limitado no ritmo e na concorrência de que sua tarefa precisa, dentro dos limites da conta. Registre o status HTTP, o erro JSON-RPC, os percentis de latência e as chamadas concluídas. Interrompa se a cota se esgotar; use espera com recuo limitado em caso de limitação de taxa e mantenha o progresso salvo. Repita com uma amostra de métodos mistos, pois métodos de maior custo consomem mais do orçamento de CU/s. Compare o tráfego de rajada com o tráfego constante e inclua o uso de outras chaves ao verificar o limite compartilhado da conta.

Cobertura de redes, métodos e protocolos

Use o catálogo de redes para verificar a identidade da rede, jsonrpc, methods.allow, methods.deny, public.methods, ws e subscriptions. O nome de uma rede não estabelece que todos os métodos ou protocolos estejam disponíveis. Métodos sem chave e métodos autenticados podem ter limites diferentes.

Autoteste: copie a public.url da rede escolhida e chame um método em public.methods. Para o exemplo de Ethereum abaixo, verifique o ID da rede e, em seguida, execute os métodos necessários da aplicação com uma chave autenticada e os mesmos blocos fixos. Verifique as regras de bloqueio (deny) bem como as de permissão (allow); compare os hashes de bloco ao comparar resultados entre endpoints.

curl --fail-with-body -sS --max-time 15 https://api.blockvectra.com/v1/eth_mainnet/public \
  -H 'Content-Type: application/json' \
  -H 'User-Agent: curl BlockVectraQA/1' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

Isso verifica um método público, e não a cobertura de arquivamento ou a capacidade autenticada. Se sua aplicação precisar de sockets, teste a assinatura necessária, a desconexão e o caminho de retomada em uma rede que declare suporte a ws. Consulte assinaturas WebSocket.

Entrega de Push e dados indexados

Para notificações de endereços, inspecione a declaração de push da rede e suas configurações de confirmação. A BlockVectra pode monitorar o mesmo conjunto de endereços em várias redes suportadas em uma única assinatura com um único receptor HTTPS; compare a capacidade self-service e corporativa com a sua contagem de endereços. Para consultas da Data API, verifique os conjuntos de dados e o intervalo indexado em GET /v1/status. Registros indexados não implicam execução histórica arbitrária de contratos. Polling RPC, mensagens WebSocket, eventos de Push entregues e endereços-dia monitorados usam medidores de cobrança diferentes; calcule cada fluxo de trabalho necessário a partir dos pesos aplicáveis em planos.

Autoteste: para Push, use um receptor HTTPS sob seu controle, verifique assinaturas e teste o tratamento de duplicatas, novas tentativas e reexecução usando um evento de um endereço que você controla. Para a Data API, consulte uma transação ou transferência indexada conhecida, compare o hash de bloco com o RPC, percorra toda a paginação e salve o cursor antes de retomar. Registre lacunas de cobertura e o número de eventos ou chamadas cobrados. Use Webhook Push, Webhook versus WebSocket e a referência da Data API para o caminho de recuperação apropriado.

Autenticação e acesso de Agents

Verifique se o seu cliente pode fornecer uma chave com segurança, descobrir documentação legível por máquina, criar uma conta e se recuperar de erros. O RPC da BlockVectra aceita uma chave no caminho em POST /v1/{chain}/{api_key} ou um cabeçalho x-api-key em POST /v1/{chain}. A Data API utiliza x-api-key. Mantenha as chaves em ambientes de servidor e fora de bundles do navegador, logs e mensagens de chat.

Desenvolvedores e AI Agents utilizam os mesmos preços e limites. O cadastro programático documenta a criação de conta baseada em carteira, e o guia de Agents fornece documentação e pontos de entrada MCP. Os Agents podem financiar o saldo de uso da conta com stablecoins por meio do fluxo de recarga documentado, sem uma assinatura mensal de RPC. Redes de recarga, tokens e valores mínimos vêm de GET /v1/topup/status.

Autoteste: faça com que o cliente pretendido descubra a rede e o método, leia a documentação, carregue uma chave de seu ambiente e execute uma requisição autenticada e limitada. Inspecione tanto o status HTTP quanto o error JSON-RPC. Verifique a resposta de chave ausente sem registrar credenciais em log. Certifique-se de que o cliente salva o progresso quando o saldo é insuficiente, lê a rede e o token de recarga habilitados e segue o fluxo de recarga documentado; as etapas de criação de conta e pagamento devem usar contas que você controla. Não trate uma conexão MCP de documentação como prova de que o Agent pode executar uma chamada RPC autenticada.

Registrar a decisão

Mantenha uma folha de resultados concisa: fonte e data de amostragem; rede e método; hash do bloco fixo; integridade do resultado; total de chamadas e novas tentativas; cota disponível; custo da tarefa paga; latência e limitação de taxa; lacunas de histórico e protocolo; etapas de recuperação; esforço de migração. Se a carga de trabalho exigir suporte contratual ou um SLA, obtenha os termos aplicáveis separadamente desses testes de API.

Depois de definir sua carga de trabalho, compare com provedores específicos:

• Compare com provedores específicos: precificação de computação e intervalos de logs.
• Compare com provedores específicos: cobrança por período de teste e assinatura.
• Compare com provedores específicos: custos de requisição HTTPS.
• Compare com provedores específicos: orçamentos diários e de ciclo.
• Compare com provedores específicos: requisições incluídas e excedente.