Cómo elegir un proveedor RPC

Elija un proveedor RPC según el coste y la fiabilidad de completar su tarea real: primero verifique las cadenas, los métodos y la cobertura histórica; después mida el número de consultas, la capacidad de procesamiento y la recuperación.

Anote las cadenas, métodos, bloques fijos, distribución diaria del tráfico, concurrencia máxima y dependencias de avisos o conjuntos de datos que necesita su aplicación o agente de IA. Los valores públicos de BlockVectra siguientes proceden de GET /v1/plans y GET /v1/chains; vuelva a consultarlos antes de decidir. La cobertura de datos procede de GET /v1/status. Una declaración es el punto de partida de una prueba, no una medición de latencia ni un SLA.

Precios de métodos y unidades de facturación

El número de solicitudes por sí solo no determina el precio de una carga de trabajo. Registre el peso de facturación de cada método, la conversión a USD, los créditos incluidos, el uso adicional y cualquier tarifa de suscripción o complemento. Los créditos, CU y unidades de solicitud necesitan su propia conversión antes de comparar proveedores.

Los pesos actuales de métodos y precios de tarifa de BlockVectra se leen del endpoint público de planes al construir la página:

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

Los precios de tarifa excluyen créditos gratuitos, gas, complementos y trabajo de migración. Distinga una asignación recurrente de una prueba que caduca, y el precio de créditos adicionales del coste medio de las solicitudes incluidas. Consulte las reglas de facturación para saber qué respuestas consumen CU.

Prueba propia: reproduzca una combinación pequeña y representativa de métodos con bloques fijos y registre llamadas exitosas, reintentos y errores facturables. Compare el cambio de uso de la cuenta con el cálculo de pesos de métodos. Presupueste el número de solicitudes que devolvieron el resultado completo, incluidas la paginación y las recuperaciones de historial. Consulte Interpretar los precios CU para realizar la conversión.

Rangos de logs y estado histórico

Para eth_getLogs, compruebe la amplitud de bloques, los límites de tamaño de resultados y la compatibilidad con filtros de la cadena y el plan específicos. Una amplitud grande solo es útil si la respuesta está completa. Las amplitudes autenticadas de BlockVectra proceden del catálogo de cadenas:

Los logs históricos y la ejecución histórica de contratos son capacidades diferentes. Para eth_call, lea state_window_blocks; para lecturas sin clave, lea también public.history_blocks. Un campo ausente o null indica que no está especificado, no demuestra un historial ilimitado. Consulte Estado histórico EVM.

Prueba propia: elija un intervalo fijo con un contrato y topics conocidos, divídalo según el rango declarado y compare la unión de resultados con consultas menores superpuestas. Deduplique por hash de bloque, hash de transacción e índice del log, y compruebe los límites del intervalo. Por separado, lea el mismo contrato en un bloque fijo reciente y en el bloque más antiguo que necesita su aplicación; registre el resultado real o el error JSON-RPC. Pruebe intervalos densos y dispersos y cuente los reintentos. Siga Rango de logs y recuperación para guardar puntos de progreso.

Créditos gratuitos, límites de tasa y picos de tráfico

El presupuesto actual del ciclo de BlockVectra y las llamadas que puede cubrir se calculan a partir de los planes:

Límite de llamadas de una cuenta gratuita: hasta 25 llamadas por segundo, compartidas entre todas las API keys de la cuenta, todas las cadenas y la Data API. Cada clave también tiene límites cu_per_sec y burst_cu. Una reposición de ciclo elegible eleva el saldo gratuito hasta su nivel objetivo; no es una concesión completa adicional. La primera recarga de pago detiene las reposiciones de ciclo y conserva los CU gratuitos restantes. Consulte las reglas del plan gratuito.

Distinga las cuotas diarias, los saldos de ciclo, las solicitudes/s, los CU/s, la capacidad de ráfaga y las solicitudes concurrentes. Pagar por más uso no establece por sí solo una mayor capacidad de procesamiento por clave.

Prueba propia: utilice una clave autenticada y un lote pequeño y acotado con el ritmo y la concurrencia que necesita su tarea, dentro de los límites de la cuenta. Registre el estado HTTP, el error JSON-RPC, los percentiles de latencia y las llamadas completadas. Deténgase al agotar la cuota; aplique esperas progresivas acotadas ante limitaciones de tasa y guarde el progreso. Repita con una muestra de métodos variados porque los métodos costosos consumen una mayor parte del presupuesto CU/s. Compare una ráfaga con tráfico sostenido e incluya el uso de otras claves al comprobar el límite compartido de la cuenta.

Cobertura de cadenas, métodos y protocolos

Utilice el catálogo de cadenas para comprobar la identidad de red, jsonrpc, methods.allow, methods.deny, public.methods, ws y subscriptions. El nombre de una cadena no demuestra que todos los métodos o protocolos estén disponibles. Los métodos sin clave y los autenticados pueden tener límites diferentes.

Prueba propia: copie la public.url de la red elegida y llame a un método de public.methods. Para el ejemplo de Ethereum siguiente, compruebe el ID de red y después ejecute los métodos que requiere la aplicación con una clave autenticada y los mismos bloques fijos. Compruebe tanto las reglas de denegación como las de autorización; compare los hashes de bloques al 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":[]}'

Esto comprueba un método público, no la cobertura de archivo ni la capacidad autenticada. Si su aplicación necesita sockets, pruebe la suscripción requerida y el proceso de desconexión y reanudación en una red que declare compatibilidad ws. Consulte Suscripciones WebSocket.

Entrega de Push y datos indexados

Para avisos de direcciones, revise la declaración push de la cadena y su configuración de confirmaciones. BlockVectra puede supervisar el mismo conjunto de direcciones en las cadenas compatibles mediante una suscripción y un receptor HTTPS; compare la capacidad de autoservicio y empresarial con su número de direcciones. Para consultas de Data API, revise los conjuntos de datos y el rango indexado en GET /v1/status. Los registros indexados no implican ejecución histórica arbitraria de contratos. El sondeo RPC, los mensajes WebSocket, los eventos Push entregados y las direcciones-día supervisadas utilizan diferentes medidas de facturación; calcule cada flujo necesario con los pesos aplicables de los planes.

Prueba propia: para Push, utilice un receptor HTTPS que controle, verifique las firmas y pruebe la gestión de duplicados, los reintentos y el replay con un evento de una dirección que controle. Para Data API, consulte una transacción o transferencia indexada conocida, compare su hash de bloque con RPC, agote la paginación y guarde el cursor antes de reanudar. Registre las lagunas de cobertura y el número de eventos o llamadas facturados. Utilice Webhook Push, Webhook frente a WebSocket y la referencia de Data API para elegir el proceso de recuperación adecuado.

Autenticación y acceso de agentes

Compruebe si su cliente puede proporcionar una clave de forma segura, descubrir documentación legible por máquinas, crear una cuenta y recuperarse de errores. El RPC de BlockVectra acepta una clave en la ruta en POST /v1/{chain}/{api_key} o un encabezado x-api-key en POST /v1/{chain}. La Data API utiliza x-api-key. Mantenga las claves en entornos de servidor y fuera de bundles de navegador, logs y mensajes de chat.

Los desarrolladores y agentes de IA utilizan los mismos precios y límites. El registro programático documenta la creación de cuentas mediante billeteras, y la guía de agentes proporciona entradas a la documentación y MCP. Los agentes pueden financiar el saldo de uso de la cuenta con stablecoins mediante el flujo de recarga documentado, sin una suscripción RPC mensual. Las redes, tokens y mínimos de recarga proceden de GET /v1/topup/status.

Prueba propia: haga que el cliente previsto descubra la cadena y el método, lea la documentación, cargue una clave de su entorno y ejecute una solicitud autenticada acotada. Revise tanto el estado HTTP como el error JSON-RPC. Compruebe una respuesta sin clave sin registrar credenciales. Verifique que el cliente guarde el progreso ante saldo insuficiente, lea la red y el token de recarga habilitados y siga el flujo de recarga documentado; los pasos de creación de cuenta y pago deben utilizar cuentas que controle. No considere una conexión al MCP de documentación como prueba de que el agente puede ejecutar una llamada RPC autenticada.

Registrar la decisión

Mantenga una hoja breve de resultados: fuente y fecha de muestreo; cadena y método; hash de bloque fijo; integridad del resultado; total de llamadas y reintentos; cuota disponible; coste pagado de la tarea; latencia y limitación de tasa; lagunas de historial y protocolo; pasos de recuperación; esfuerzo de migración. Si la carga de trabajo requiere soporte contractual o un SLA, obtenga las condiciones aplicables por separado de estas pruebas de API.

Una vez definida su carga de trabajo, compare con proveedores específicos:

• Comparar con proveedores específicos: precios de cómputo y rangos de logs.
• Comparar con proveedores específicos: facturación de pruebas y suscripciones.
• Comparar con proveedores específicos: costes de solicitudes HTTPS.
• Comparar con proveedores específicos: presupuestos diarios y de ciclo.
• Comparar con proveedores específicos: solicitudes incluidas y uso adicional.