Resumen
Base es una red Ethereum Layer 2 que liquida transacciones en Ethereum mientras las ejecuta en su propia cadena. Los desarrolladores interactúan con ella a través de un endpoint JSON-RPC compatible con EVM, lo que significa que la mayoría de las herramientas de Ethereum funcionan con solo cambiar el chain ID y la URL RPC. Este artículo explica qué es Base, cómo se relaciona con Ethereum y cómo conectarse a ella de forma fiable.
Encontrarás la configuración de la cadena, un ejemplo de conexión funcional y una guía práctica para elegir entre el endpoint público y la infraestructura de nodos gestionados o dedicados. El objetivo es ayudarte a decidir cómo integrar Base en tu stack y qué comprobar antes de pasar a producción.
Base es una red Ethereum Layer 2. Ejecuta transacciones en su propia cadena y publica los datos resultantes de vuelta a Ethereum, de ahí el término "L2 en Ethereum". Para los desarrolladores, la consecuencia práctica es simple: Base habla el mismo dialecto JSON-RPC que Ethereum, por lo que la mayoría de las herramientas, bibliotecas y contratos funcionan con solo cambiar el chain ID y la URL RPC.
Esta página responde a la pregunta inmediata y luego te ayuda a decidir cómo conectarte. Si ya sabes qué es Base y solo necesitas la configuración, salta a la tabla de configuración de la cadena. Si estás evaluando cómo ejecutar Base en producción, la sección de decisión a continuación es el punto de partida.
Recomendación rápida: qué ruta de conexión se adapta a tu carga de trabajo
No todos los proyectos necesitan la misma configuración de Base. Usa la siguiente tabla para relacionar tu situación con un enfoque de conexión. La respuesta correcta depende del volumen de solicitudes, de si necesitas datos de archivo o de traza, y de cuánto trabajo operativo quieres asumir.
| Tu situación | Enfoque sugerido | Qué tener en cuenta |
|---|---|---|
| Prototipado, scripts, lecturas de bajo volumen | Endpoint público de Base | Capacidad compartida; adecuado para pruebas, no para picos de tráfico |
| dApp en producción con tráfico constante | API RPC gestionada | Los límites de tasa, el failover y la monitorización importan |
| Indexación pesada, llamadas de archivo o traza | Nodo dedicado | El almacenamiento y el tiempo de sincronización son tu responsabilidad |
| Necesidades de cumplimiento o residencia de datos | Nodo dedicado | Tú controlas el entorno de despliegue |
| App multicadena que incluye Base | RPC multicadena gestionado | Un conjunto de herramientas consistente entre cadenas reduce errores |
Si no estás seguro, empieza con un endpoint gestionado y pasa a un nodo dedicado solo cuando puedas nombrar el límite específico que estás alcanzando. OnFinality ofrece tanto acceso a la API RPC como infraestructura de nodos dedicados, para que puedas escalar la misma carga de trabajo de Base sin cambiar el código de tu aplicación.
Qué es Base realmente, en un párrafo
Base es una Layer 2 construida sobre el OP Stack. Agrupa transacciones, las ejecuta fuera de Ethereum mainnet y publica datos comprimidos de vuelta a Ethereum para la liquidación y la disponibilidad de datos. Los usuarios pagan comisiones en ETH en Base, y la red expone una interfaz compatible con EVM. Eso significa que eth_call, eth_getLogs, eth_sendRawTransaction y el resto del conjunto estándar de métodos JSON-RPC de Ethereum se comportan como esperas.
El matiz importante para los desarrolladores es que Base no es Ethereum. Tiene su propio chain ID, su propio explorador de bloques y su propio mercado de gas. Los contratos desplegados en Ethereum mainnet no están disponibles automáticamente en Base; los despliegas por separado. Las direcciones pueden coincidir si usas el mismo deployer y nonce, pero eso es una conveniencia, no una garantía.
Configuración de la cadena de un vistazo
Usa estos valores al añadir Base a una cartera, una configuración de Hardhat, un perfil de Foundry o un cliente viem.
| Configuración | Base mainnet | Base Sepolia testnet |
|---|---|---|
| Chain ID | 8453 | 84532 |
| Moneda nativa | ETH (18 decimales) | ETH (18 decimales) |
| Explorador de bloques | https://basescan.org | https://sepolia.basescan.org |
| Transporte | HTTP | HTTP |
| RPC público de OnFinality | https://base.api.onfinality.io/public | https://base-sepolia.api.onfinality.io/public |
Para una referencia completa de la red, consulta la página de la red Base y la página de la red Base Sepolia.
Conexión con curl y JavaScript
La forma más rápida de confirmar que tu endpoint funciona es una única llamada JSON-RPC. Esto devuelve el número de bloque actual:
curl -X POST https://base.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
Una respuesta exitosa se ve así: {"jsonrpc":"2.0","id":1,"result":"0x..."}. Si en su lugar recibes un objeto de error, verifica la URL, el nombre del método y si tu cliente está enviando un POST con un cuerpo JSON.
En JavaScript, la misma llamada a través de viem se ve así:
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(blockNumber);
Si usas ethers, el patrón es similar: crea un JsonRpcProvider con la URL RPC de Base y llama a getBlockNumber(). La biblioteca valida el chain ID cuando pasas el objeto de cadena, lo que detecta endpoints mal configurados a tiempo.
Configuración de cartera y red
Añadir Base a una cartera es un primer paso común para testers y equipos de soporte. Los campos se corresponden directamente con la tabla de configuración de la cadena anterior. En MetaMask, elige "Añadir red manualmente" e introduce el chain ID, la URL RPC y la URL del explorador. Para Base Sepolia, usa el chain ID 84532 y el explorador de Sepolia.
Un error frecuente es mezclar valores de mainnet y testnet. Si tu cartera muestra un saldo de cero después de una reclamación exitosa en un faucet, confirma que estás en el chain ID de testnet y que el faucet envió fondos a la misma dirección que muestra la cartera. La disponibilidad de los faucets cambia con el tiempo, así que consulta la documentación actual de Base en lugar de confiar en un enlace en caché.
Dónde encaja Base en un stack de Ethereum
Base es una de varias L2 que comparten las herramientas de Ethereum. Si tu aplicación ya es compatible con Ethereum mainnet, añadir Base es principalmente un cambio de configuración. Las preguntas más difíciles son operativas: cómo manejas las reorganizaciones, cómo indexas los logs de manera eficiente y cómo mantienes la latencia predecible bajo carga.
Para equipos que ejecutan múltiples cadenas, una capa RPC consistente importa más que las peculiaridades de cualquier cadena individual. OnFinality es compatible con Base junto con Ethereum y otras redes, para que puedas usar un solo proveedor y un solo conjunto de credenciales en todo tu stack. Consulta redes RPC compatibles para ver la lista actual.
Lista de verificación para producción
Antes de dirigir usuarios reales a un endpoint de Base, revisa estos puntos. Están ordenados por la frecuencia con la que causan incidentes.
- Failover. ¿Tienes un segundo endpoint configurado? Una única URL es un único punto de fallo.
- Límites de tasa. ¿Conoces tu techo de solicitudes por segundo y tu cliente retrocede ante respuestas 429?
- Necesidades de archivo y traza. ¿Llamas a
eth_getLogsen rangos de bloques amplios o usas métodos de traza? Estos son más pesados y pueden necesitar un nodo dedicado. - Manejo de reorganizaciones. Base, como otras L2, puede reorganizarse. Tu indexador debe confirmar la finalidad antes de tratar los datos como liquidados.
- Monitorización. ¿Alertas sobre la tasa de errores y la latencia, no solo sobre el tiempo de inactividad total?
- Gestión de claves. ¿Las credenciales RPC se almacenan fuera de tu árbol de código fuente?
Si varios de estos puntos quedan sin respuesta, un proveedor gestionado elimina la mayor parte de la carga operativa. Si necesitas control sobre el nodo en sí, un nodo dedicado te lo proporciona a costa de ejecutar la infraestructura.
Modos de fallo comunes y cómo interpretarlos
La mayoría de los problemas de RPC en Base se dividen en un pequeño número de categorías. La siguiente tabla relaciona los síntomas con las causas probables.
| Síntoma | Causa probable | Siguiente paso |
|---|---|---|
method not found | Método no soportado por el endpoint | Confirma que el método forma parte del conjunto EVM estándar |
429 Too Many Requests | Límite de tasa alcanzado | Añade retroceso y considera un nivel superior |
Tiempos de espera en eth_getLogs | Rango de bloques demasiado amplio | Reduce el rango o usa un indexador |
| Datos de cadena incorrectos | El endpoint apunta a una red diferente | Verifica el chain ID con eth_chainId |
| Número de bloque obsoleto | Caché o un nodo retrasado | Compara con un segundo endpoint |
Un diagnóstico rápido es llamar a eth_chainId y comparar el resultado con el valor esperado. Para Base mainnet debería devolver 0x2105 (8453 en decimal). Para Base Sepolia debería devolver 0x14a34 (84532). Si no coinciden, estás hablando con la red incorrecta.
Elección entre público, gestionado y dedicado
El endpoint público es una buena opción por defecto para desarrollo y lecturas de bajo volumen. Es compartido, por lo que no es la elección adecuada para tráfico de producción que necesita latencia predecible.
Una API RPC gestionada se sitúa en el medio. Obtienes una URL estable, monitorización y la capacidad de escalar sin ejecutar nodos. Esta es la elección común para dApps, carteras y backends que necesitan Base y algunas otras cadenas.
Un nodo dedicado es para equipos que necesitan datos de archivo, llamadas de traza, configuración personalizada o un entorno de despliegue específico. La contrapartida es que asumes el tiempo de sincronización, el almacenamiento y las actualizaciones. Para la mayoría de los equipos, la decisión se reduce a si la carga de trabajo justifica esa propiedad. La página de precios de RPC de OnFinality describe las opciones si quieres comparar modelos de coste.
Puntos clave
- Base es una L2 de Ethereum con una interfaz JSON-RPC compatible con EVM, por lo que las herramientas de Ethereum funcionan con un cambio de chain ID y URL.
- Base mainnet usa el chain ID 8453; Base Sepolia usa 84532.
- Los endpoints públicos de OnFinality son
https://base.api.onfinality.io/publicyhttps://base-sepolia.api.onfinality.io/public. - Los endpoints públicos sirven para desarrollo; las cargas de trabajo en producción normalmente necesitan infraestructura gestionada o dedicada.
- Verifica siempre el chain ID con
eth_chainIdal depurar datos inesperados. - Planifica el failover, los límites de tasa y el manejo de reorganizaciones antes del lanzamiento.
Preguntas frecuentes
¿Base es lo mismo que Ethereum? No. Base es una red Layer 2 separada que liquida en Ethereum. Usa las herramientas de Ethereum y ETH como moneda nativa, pero tiene su propio chain ID y explorador de bloques.
¿Cuál es el chain ID de Base? Base mainnet es 8453. Base Sepolia es 84532.
¿Puedo usar métodos RPC de Ethereum en Base?
Sí. Los métodos JSON-RPC estándar de EVM como eth_call, eth_getLogs y eth_sendRawTransaction funcionan en Base. Algunos métodos específicos de Ethereum pueden no aplicarse.
¿Necesito un nodo dedicado para Base? Solo si necesitas datos de archivo, llamadas de traza, configuración personalizada o un entorno de despliegue específico. La mayoría de las aplicaciones funcionan bien con un endpoint gestionado.
¿Cómo puedo probar Base sin gastar ETH real? Usa Base Sepolia y un faucet. Confirma que estás en el chain ID 84532 y que el faucet envió fondos a la dirección de tu cartera.
¿Dónde puedo encontrar los endpoints de Base de OnFinality? Consulta la página de la red Base y la página de la red Base Sepolia. Para precios y detalles de planes, visita precios de RPC.