Resumen
Base es una capa 2 de Ethereum construida sobre OP Stack, por lo que su interfaz RPC es compatible con JSON-RPC y con las herramientas de Ethereum. Te conectas apuntando un cliente a un endpoint de Base con el ID de cadena 8453, y la mayoría de las bibliotecas de Ethereum funcionan con pocos o ningún cambio. Las decisiones principales son qué endpoint usar, cómo manejar los límites de velocidad y cómo mantener las solicitudes confiables a medida que crece el tráfico.
Esta página cubre la configuración de la red principal de Base y Base Sepolia, ejemplos de solicitudes funcionales, modos de fallo comunes y cómo decidir entre un endpoint público, una API RPC gestionada y un nodo dedicado. OnFinality proporciona RPC de Base a través de su servicio de API RPC y opciones de nodo dedicado.
Base es una capa 2 de Ethereum construida sobre OP Stack. Para los desarrolladores, eso significa que la superficie RPC se parece casi exactamente a Ethereum: los mismos métodos JSON-RPC, el mismo espacio de nombres eth_ y las mismas bibliotecas cliente. Si ya tienes código de Ethereum, conectarte a Base suele ser cuestión de cambiar el ID de cadena y la URL RPC.
Esta página es una referencia práctica para el RPC de la red Base. Cubre la configuración de cadena que necesitas, ejemplos de solicitudes que puedes ejecutar de inmediato, los modos de fallo que aparecen con más frecuencia y cómo decidir entre un endpoint público, una API RPC gestionada y un nodo dedicado a medida que crece tu tráfico.
¿Qué endpoint de Base deberías usar?
Empieza por hacer coincidir el endpoint con tu carga de trabajo. La elección correcta depende menos de la cadena y más de cuánto tráfico envías, si necesitas datos de archivo o de traza, y cuánto te cuesta el tiempo de inactividad.
| Tu situación | Punto de partida sensato | Qué vigilar |
|---|---|---|
| Prototipado, scripts, lecturas puntuales | Endpoint público de Base | Capacidad compartida, sin SLA, adecuado para bajo volumen |
| Una dApp con usuarios reales | API RPC gestionada con una clave API | Límites de rendimiento, conmutación por error, cobertura de métodos |
Indexadores, analítica, eth_getLogs intensivo | RPC gestionado con acceso a archivo | Límites de rango de logs y coste de consulta |
| Trading, puentes, alto volumen de solicitudes | Nodo Base dedicado | Tiempo de aprovisionamiento, monitorización, redundancia |
Una regla rápida: si una solicitud fallida significa que un usuario ve un error, has superado un endpoint público compartido. Si una solicitud fallida significa que una posición de trading o una transferencia de puente está en riesgo, deberías estar considerando infraestructura dedicada con una ruta de conmutación por error.
OnFinality ofrece Base a través de su servicio de API RPC para acceso gestionado y nodos dedicados para capacidad aislada. Puedes comparar planes en la página de precios de RPC y ver la lista completa de redes RPC compatibles.
Configuración de la cadena Base de un vistazo
Estos son los valores que introduces en una billetera, una biblioteca o un archivo de configuración.
| Configuración | Base mainnet | Base Sepolia (testnet) |
|---|---|---|
| ID de cadena | 8453 | 84532 |
| Nombre de la cadena | Base | Base Sepolia Testnet |
| Moneda nativa | ETH (18 decimales) | ETH (18 decimales) |
| Explorador de bloques | https://basescan.org | https://sepolia.basescan.org |
| Transporte | HTTP | HTTP |
| Endpoint público de OnFinality | https://base.api.onfinality.io/public | https://base-sepolia.api.onfinality.io/public |
Base Sepolia es la testnet que usas antes de pasar a mainnet. Tiene su propio ID de cadena y su propio ecosistema de faucet, así que asegúrate de que tu configuración no mezcle las dos. Las páginas de red de OnFinality para Base y Base Sepolia enumeran los endpoints y detalles que necesitas.
Hacer tu primera solicitud JSON-RPC a Base
Base habla JSON-RPC estándar sobre HTTP. La comprobación más simple posible es una llamada curl al endpoint público.
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 la altura del último bloque en hexadecimal. A partir de ahí, se aplican los métodos habituales de Ethereum: eth_getBalance, eth_call, eth_getLogs, eth_getTransactionReceipt, etc. Como Base es equivalente a EVM, la mayoría de las herramientas de Ethereum funcionan sin modificaciones.
Si usas un endpoint gestionado con una clave API, la URL suele llevar la clave como parámetro de ruta o de consulta. Mantén esa clave fuera del código del lado del cliente y de repositorios públicos.
Conexión desde JavaScript con viem
En la práctica, te conectarás a través de una biblioteca en lugar de curl sin procesar. Aquí tienes una configuración mínima de viem para Base mainnet.
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()
console.log('Base block:', blockNumber)
Para un endpoint gestionado, cambia la URL por tu endpoint con clave. Para ethers, el patrón es el mismo: construye un proveedor con la URL RPC de Base y el ID de cadena, luego llama a tus métodos habituales. El detalle importante es que el ID de cadena en tu configuración coincida con el endpoint al que llamas. Apuntar un ID de cadena de mainnet a un endpoint de testnet es uno de los errores de configuración más comunes.
Añadir Base a una billetera
Las billeteras que admiten redes personalizadas aceptan los mismos valores. Una configuración de red típica se ve así:
{
"chainId": "0x2105",
"chainName": "Base",
"nativeCurrency": { "name": "Ether", "symbol": "ETH", "decimals": 18 },
"rpcUrls": ["https://base.api.onfinality.io/public"],
"blockExplorerUrls": ["https://basescan.org"]
}
Ten en cuenta que 0x2105 es la forma hexadecimal de 8453. Las billeteras esperan el valor hexadecimal, mientras que la mayoría de las bibliotecas de JavaScript aceptan el decimal. Si una billetera rechaza tu red, comprueba primero el formato del ID de cadena.
Dónde suelen fallar las solicitudes RPC de Base
La mayoría de los problemas de RPC de Base se dividen en unas pocas categorías. Conocerlos acorta considerablemente la depuración.
| Síntoma | Causa probable | Qué probar |
|---|---|---|
429 o respuestas limitadas | Límite de velocidad del endpoint compartido | Pasar a un endpoint con clave o dedicado, añadir reintentos con retroceso exponencial |
eth_getLogs devuelve un error | Rango de logs demasiado amplio para el endpoint | Reducir el rango de bloques, paginar o usar acceso a archivo |
| Datos vacíos o obsoletos | ID de cadena o endpoint de testnet incorrecto | Confirmar ID de cadena 8453 vs 84532 |
method not found | Método no habilitado en ese endpoint | Verificar cobertura de métodos, especialmente trace y debug |
| Tiempos de espera bajo carga | Saturación del endpoint | Añadir conmutación por error, aumentar el tiempo de espera del cliente, usar capacidad dedicada |
| Transacciones atascadas pendientes | Configuración de nonce o gas | Verificar el manejo de nonce y la estimación de gas |
Dos de estos merecen más detalle. Primero, eth_getLogs es el método con más probabilidades de alcanzar límites, porque un rango de bloques amplio puede significar un conjunto de resultados muy grande. Si estás indexando Base, planifica la paginación desde el principio en lugar de descubrir el límite en producción. Segundo, los problemas de nonce y gas en Base se comportan de manera muy similar a como lo hacen en Ethereum; si estás depurando una transacción atascada, se aplican las mismas reglas de nonce y reemplazo.
Público, gestionado y dedicado: elegir para producción
Un endpoint público es la forma más rápida de empezar y la más fácil de superar. Es compartido, no tiene compromiso con tu tráfico y es la herramienta adecuada para scripts, prototipos y lecturas ocasionales.
Una API RPC gestionada se sitúa en el medio. Obtienes un endpoint con clave, un rendimiento más predecible y soporte para los métodos que la mayoría de las aplicaciones necesitan. Esta es la opción común para dApps con usuarios reales, donde la fiabilidad importa pero no quieres ejecutar la infraestructura tú mismo.
Un nodo dedicado te da capacidad aislada. No compartes rendimiento con otros inquilinos, lo cual importa para alto volumen de solicitudes, consultas de logs intensivas o cargas de trabajo donde una solicitud fallida tiene un coste directo. La contrapartida es que asumes más responsabilidad operativa, o trabajas con un proveedor que la gestiona por ti.
El servicio de API RPC de OnFinality cubre el caso gestionado, y los nodos dedicados cubren el caso aislado. Si aún estás sopesando proveedores en general, la guía para elegir un proveedor RPC repasa los criterios con más profundidad.
Lista de verificación de preparación para producción en Base
Antes de dirigir tráfico real a un endpoint de Base, confirma lo siguiente:
- Tu ID de cadena y tu endpoint coinciden, y las configuraciones de mainnet y testnet están claramente separadas.
- Tienes lógica de reintentos con retroceso exponencial para fallos transitorios.
- Tienes al menos un endpoint de conmutación por error, o un plan documentado para uno.
- Tu uso de
eth_getLogsestá paginado y acotado. - Las claves API están solo en el lado del servidor y se rotan cuando es necesario.
- Monitorizas tasas de error y latencia, no solo el tiempo de actividad.
- Sabes de qué métodos dependes, incluidas las llamadas trace o debug.
Si falta alguno de estos, vale la pena solucionarlo antes del lanzamiento en lugar de después de un incidente.
Monitorización y conmutación por error
Una sonda de salud simple te mantiene por delante de los problemas. Consulta el último número de bloque de forma programada y alerta si deja de avanzar o si las solicitudes empiezan a fallar.
#!/usr/bin/env bash
RESP=$(curl -s -o /dev/null -w "%{http_code}" https://base.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
if [ "$RESP" != "200" ]; then
echo "Base RPC probe failed: $RESP"
fi
Para la conmutación por error, mantén un segundo endpoint configurado y cambia ante fallos repetidos en lugar de ante un solo error. Un único tiempo de espera es normal; una racha de ellos es una señal.
Puntos clave
- Base es una L2 de OP Stack con una interfaz JSON-RPC compatible con Ethereum, por lo que las herramientas EVM existentes funcionan con cambios mínimos.
- Base mainnet usa el ID de cadena 8453; Base Sepolia usa 84532. Mezclarlos es una fuente común de datos vacíos o incorrectos.
- Los endpoints públicos son adecuados para prototipos, pero son compartidos y fáciles de superar.
- Las API RPC gestionadas se adaptan a dApps con usuarios reales; los nodos dedicados se adaptan a cargas de trabajo de alto volumen o sensibles a la latencia.
eth_getLogses el método con más probabilidades de alcanzar límites, así que pagina desde el principio.- Planifica siempre la conmutación por error y monitoriza las tasas de error, no solo la disponibilidad.
Preguntas frecuentes
¿Cuál es la URL RPC de la red Base?
Para el endpoint público de Base mainnet de OnFinality, usa https://base.api.onfinality.io/public. Para Base Sepolia, usa https://base-sepolia.api.onfinality.io/public. Para cargas de trabajo en producción, un endpoint gestionado con clave o un nodo dedicado suele ser una mejor opción que una URL pública compartida.
¿Cuál es el ID de cadena de Base?
Base mainnet usa el ID de cadena 8453, que es 0x2105 en hexadecimal. Base Sepolia usa 84532.
¿El RPC de Base es lo mismo que el RPC de Ethereum?
Base es equivalente a EVM y está construida sobre OP Stack, por lo que los métodos JSON-RPC son en gran medida los mismos que los de Ethereum. La mayoría de las bibliotecas y herramientas de Ethereum funcionan con Base con solo cambiar el ID de cadena y la URL.
¿Por qué mi solicitud RPC a Base devuelve un 429?
Un 429 generalmente significa que has alcanzado un límite de velocidad en un endpoint compartido. Pasa a un endpoint gestionado con clave o capacidad dedicada, y añade reintentos con retroceso exponencial para casos transitorios.
¿Base admite suscripciones WebSocket?
El soporte de transporte depende del endpoint. Consulta la página de la red Base para ver los transportes disponibles, y confirma si tu proveedor ofrece acceso WebSocket si necesitas suscripciones.
¿Cómo obtengo ETH de testnet para Base Sepolia?
Base Sepolia tiene su propio ecosistema de faucet. Usa un faucet reconocido de Base Sepolia para fondear una billetera de prueba, y mantén las claves de testnet separadas de las claves de mainnet.
¿Puedo usar OnFinality para Base?
Sí. OnFinality proporciona RPC de Base a través de sus ofertas de servicio de API RPC y nodo dedicado. Consulta precios de RPC para detalles de planes y redes RPC compatibles para la lista completa de redes.