Logo
Nuevos usuarios de RPC: 35% de descuento el primer mesVer oferta
RPC Assistant

Base Node RPC: Configuración de Endpoint, Chain IDs y Depuración

Resumen

Base es una L2 de Ethereum construida sobre OP Stack, por lo que su superficie RPC resulta familiar para cualquier desarrollador de Ethereum: JSON-RPC sobre HTTP, los mismos métodos eth_* y chain ID 8453 para mainnet. Este artículo cubre la configuración del endpoint RPC del nodo Base que necesitas, cómo agregar Base a una billetera, cómo enviar tu primera solicitud y cómo depurar los fallos que aparecen con más frecuencia en producción. También explica cuándo un endpoint público es suficiente y cuándo un nodo Base dedicado es la mejor opción.

Base es una Layer 2 de Ethereum construida sobre OP Stack, lo que significa que su interfaz RPC de nodo es deliberadamente familiar: JSON-RPC estándar sobre HTTP, los mismos nombres de métodos eth_* que ya usas en Ethereum y un pequeño conjunto de métodos específicos de OP Stack adicionales. Si estás configurando una billetera, un indexador backend o una suite de pruebas, principalmente necesitas la configuración de cadena correcta, un endpoint funcional y una ruta de depuración clara cuando falla una solicitud.

Esta página es una referencia práctica para Base node RPC. Cubre la configuración que pegas en una billetera, cómo enviar una solicitud con curl y con viem, qué verificar cuando falla una llamada y cómo decidir entre un endpoint público y un nodo Base dedicado.

Configuración de cadena de un vistazo

Antes de escribir cualquier código, confirma los parámetros de red. Base mainnet y Base Sepolia son redes separadas con diferentes chain IDs, por lo que una billetera o SDK apuntado a la incorrecta parecerá funcionar mientras devuelve datos erróneos.

ConfiguraciónBase mainnetBase Sepolia
Chain ID845384532
Moneda nativaETH (18 decimales)ETH (18 decimales)
Explorador de bloqueshttps://basescan.orghttps://sepolia.basescan.org
Transporte RPCHTTP (JSON-RPC)HTTP (JSON-RPC)
Uso típicoAplicaciones en producción, valor realDesarrollo, pruebas, faucets

Una verificación rápida: llama a eth_chainId y confirma que devuelve 0x2105 para mainnet (8453 en decimal) o 0x14a34 para Sepolia (84532). Si el valor no coincide con la red que pretendías, detente y corrige la configuración antes de depurar cualquier otra cosa.

Agregar Base a una billetera

La mayoría de las billeteras aceptan una red personalizada. Los campos se asignan directamente a la tabla anterior:

  • Nombre de red: Base
  • URL RPC: tu endpoint Base
  • Chain ID: 8453
  • Símbolo de moneda: ETH
  • Explorador de bloques: https://basescan.org

Para Base Sepolia, usa chain ID 84532 y el explorador de Sepolia. Si estás construyendo un flujo de conexión de billetera, puedes solicitar la red programáticamente en lugar de pedir a los usuarios que la escriban:

await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0x2105",
    chainName: "Base",
    nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
    rpcUrls: ["https://base.api.onfinality.io/public"],
    blockExplorerUrls: ["https://basescan.org"]
  }]
});

Si usas OnFinality para Base, el endpoint público es https://base.api.onfinality.io/public y el equivalente para Base Sepolia es https://base-sepolia.api.onfinality.io/public. Para tráfico de producción, un nodo Base dedicado te proporciona un endpoint privado que puedes rotar sin tocar la configuración del usuario. Consulta la página de red Base y la página de red Base Sepolia para obtener detalles actuales.

Enviar tu primera solicitud Base RPC

La forma más rápida de confirmar que un endpoint funciona es una sola llamada curl. Esto verifica la conectividad, el chain ID y el último bloque en un solo intento:

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

curl -s https://base.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Una respuesta saludable devuelve un objeto JSON con un campo result. Si en su lugar obtienes un objeto de error, error.code y error.message te indican si el problema es la solicitud, el endpoint o la red.

En el código de la aplicación, la misma llamada se ve así con viem:

import { createPublicClient, http } from "viem";
import { base } from "viem/chains";

const client = createPublicClient({
  chain: base,
  transport: http("https://base.api.onfinality.io/public")
});

const blockNumber = await client.getBlockNumber();
const chainId = await client.getChainId();
console.log({ chainId, blockNumber });

Debido a que Base sigue las convenciones de Ethereum, la mayoría de las herramientas de Ethereum funcionan sin un adaptador específico para Base. Las principales diferencias son el chain ID, las URL del explorador y un puñado de métodos de OP Stack.

Qué métodos Base RPC importan en la práctica

No necesitas todos los métodos. La mayoría de las aplicaciones se apoyan en un conjunto pequeño, y saber cuáles son más pesados te ayuda a planificar la capacidad.

MétodoQué haceNotas para Base
eth_chainIdDevuelve el chain IDÚsalo para verificar que estás en 8453 o 84532
eth_blockNumberAltura del último bloqueBarato, bueno para health checks
eth_getBalanceSaldo de la cuentaComún en flujos de billetera
eth_callLlamada de contrato de solo lecturaNúcleo de la mayoría de las lecturas de dapp
eth_getLogsConsulta registros de eventosEl método común más pesado; delimita por rango de bloques
eth_getTransactionReceiptEstado de la transacciónConsulta después de enviar una tx
eth_estimateGasEstimación de gasEjecuta antes de enviar
eth_sendRawTransactionDifunde una tx firmadaDevuelve un hash de tx, no un recibo

eth_getLogs merece especial atención. Los rangos de bloques amplios y los filtros de temas generales pueden devolver cargas útiles grandes y son una causa frecuente de timeouts. Reduce el rango, filtra por dirección y pagina cuando sea posible.

Ruta de depuración para fallos comunes de Base RPC

Cuando algo se rompe, el mensaje de error generalmente apunta a la capa. Revisa esta tabla antes de asumir que el endpoint está caído.

SíntomaCausa probablePrimera verificación
chainId no coincideRed incorrecta configuradaLlama a eth_chainId, compara con 8453/84532
method not foundError tipográfico o método no soportadoConfirma el nombre del método y el transporte del endpoint
Timeout en eth_getLogsRango de bloques demasiado amplioReduce el rango, agrega filtro de dirección
nonce too lowNonce obsoleto después de una tx atascadaVuelve a leer eth_getTransactionCount con pending
insufficient fundsGas o valor excede el saldoVerifica saldo y estimación de gas
result vacío en una lecturaContrato no desplegado en esta redVerifica la dirección en el explorador correcto
429 intermitenteLímites de tasa del endpoint compartidoMueve las lecturas pesadas a un nodo dedicado

Dos patrones causan la mayor confusión. Primero, mezclar datos de mainnet y testnet: una dirección de contrato que existe en Base mainnet no existirá en Base Sepolia, y viceversa. Segundo, tratar eth_sendRawTransaction como final: devuelve un hash inmediatamente, pero debes consultar eth_getTransactionReceipt para saber si la transacción tuvo éxito.

¿Endpoint público o nodo Base dedicado?

Esta es la decisión que enfrentan la mayoría de los equipos una vez que una aplicación supera el prototipado. La respuesta correcta depende de la forma de tu carga de trabajo, no de un solo benchmark.

Carga de trabajoEndpoint públicoNodo Base dedicado
Prototipos y demosGeneralmente suficienteAún no es necesario
Lecturas de bajo volumenGeneralmente suficienteOpcional
Indexación pesada con eth_getLogsRiesgoso bajo cargaRecomendado
Trading de alta frecuencia o botsAplican límites compartidosRecomendado
Necesidades de cumplimiento o aislamiento de datosNo adecuadoRecomendado
Tráfico de producción predecibleCapacidad compartidaRecomendado

Una regla útil: si la confiabilidad de tu aplicación depende de un patrón de solicitud específico que un endpoint compartido no puede garantizar, aísla ese patrón en un nodo dedicado y deja todo lo demás en el endpoint público. Esto mantiene el costo proporcional a la necesidad real. OnFinality ofrece tanto acceso compartido a la API RPC como nodos Base dedicados; consulta Precios de RPC para las opciones actuales y redes RPC compatibles para la lista completa.

Consideraciones sobre WebSocket y suscripciones

Base soporta JSON-RPC sobre HTTP, que es lo que usan la mayoría de las aplicaciones. Si necesitas actualizaciones tipo push, verifica si tu proveedor expone transporte WebSocket para Base antes de diseñar en torno a suscripciones. El polling HTTP de eth_blockNumber o eth_getTransactionReceipt es un respaldo confiable y es más fácil de razonar en caso de fallo.

Si usas suscripciones, planifica la lógica de reconexión. Las conexiones de larga duración se caen, y una suscripción que deja de entregar eventos silenciosamente es peor que una que falla ruidosamente. Trata la conexión como algo que necesitará restablecerse.

Lista de verificación operativa antes del lanzamiento

Antes de dirigir tráfico de producción a cualquier endpoint Base, confirma lo siguiente:

  • El chain ID se verifica en tiempo de ejecución, no solo en la configuración.
  • El endpoint es accesible desde tu entorno de despliegue, no solo desde tu laptop.
  • Los métodos pesados como eth_getLogs están delimitados y paginados.
  • Tienes un endpoint de respaldo o un plan para uno.
  • Los errores se registran con el código de error JSON-RPC, no solo con un mensaje genérico.
  • Sabes a qué red pertenece cada dirección de contrato.

Una sonda de monitoreo simple te mantiene por delante de los problemas:

async function probe(endpoint) {
  const res = await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] })
  });
  const json = await res.json();
  return { ok: res.ok && !!json.result, block: json.result };
}

Ejecuta esto en un horario y alerta sobre fallos repetidos. Es una pequeña cantidad de código que detecta una gran clase de incidentes temprano.

Puntos clave

  • Base usa JSON-RPC estándar de Ethereum; chain ID 8453 para mainnet y 84532 para Sepolia.
  • Verifica eth_chainId en tiempo de ejecución para evitar consultar silenciosamente la red incorrecta.
  • eth_getLogs es la fuente más común de timeouts; delimita rangos de bloques y filtros.
  • eth_sendRawTransaction devuelve un hash, no un recibo; consulta el recibo para confirmar el éxito.
  • Los endpoints públicos sirven para prototipos y lecturas ligeras; los nodos Base dedicados sirven para cargas de trabajo pesadas, predecibles o aisladas.
  • OnFinality proporciona acceso a la API RPC de Base y nodos dedicados; consulta Precios de RPC y redes compatibles.

Preguntas frecuentes

¿Cuál es el chain ID de Base? Base mainnet usa chain ID 8453. Base Sepolia usa 84532. Confirma siempre con eth_chainId en tiempo de ejecución.

¿Cuál es el endpoint RPC de Base? Cualquier endpoint JSON-RPC que sirva a la red Base. OnFinality expone un endpoint público de Base y opciones dedicadas; consulta la página de red Base para obtener detalles actuales.

¿Puedo usar herramientas de Ethereum con Base? Sí. Base sigue las convenciones de Ethereum, por lo que la mayoría de las bibliotecas y billeteras de Ethereum funcionan una vez que configuras el chain ID y el endpoint correctos.

¿Por qué mi transacción en Base aparece como pendiente? eth_sendRawTransaction devuelve un hash antes de que la transacción se incluya. Consulta eth_getTransactionReceipt hasta que devuelva un recibo, y verifica la configuración de gas si se estanca.

¿Necesito un nodo Base dedicado? Solo si tu carga de trabajo necesita capacidad privada, aislamiento o comportamiento predecible bajo lecturas pesadas. Los prototipos y aplicaciones ligeras generalmente no lo necesitan.

¿Cómo depuro un timeout de Base RPC? Comienza con el método. eth_getLogs con un rango amplio es el culpable habitual; reduce el rango y agrega filtros antes de investigar el endpoint en sí.

Base de conocimiento RPC

Detalles RPC relacionados

Nunca te preocupes por la infraestructura nuevamente

OnFinality elimina la carga pesada de DevOps para que puedas construir de forma más inteligente y rápida.

Comenzar