Endpoint RPC de Sepolia: URL públicas, configuración de cadena y cuándo dejar de usarlas

Sepolia es la testnet proof-of-stake de Ethereum de larga duración, y "endpoint RPC público" es la frase que la mayoría de los desarrolladores buscan cuando quieren conectarse a ella sin registrarse en nada. Ese es un punto de partida razonable: un endpoint público es una URL HTTPS compartida que habla JSON-RPC, y es suficiente para agregar la red a una billetera, ejecutar un script rápido o desbloquear un trabajo de CI.

El problema es que los endpoints públicos son compartidos por todos los que los encuentran. Están bien para exploración y pruebas ligeras, y se convierten en un cuello de botella en el momento en que necesitas un rendimiento constante, datos de archivo o llamadas de trace. Esta página te proporciona la configuración exacta de la cadena Sepolia, un endpoint público funcional y un marco breve para decidir cuándo pasar a infraestructura gestionada o dedicada.

Configuración de la cadena de un vistazo

Antes de pegar cualquier cosa en una billetera o un archivo de configuración, asegúrate de que estos valores sean correctos. La mayoría de los informes de "Sepolia RPC no funciona" se reducen a un ID de cadena incorrecto o una URL que apunta a una testnet diferente.

Si trabajas en una testnet L2, los valores son diferentes. Base Sepolia usa el ID de cadena 84532, y Arbitrum Sepolia usa el ID de cadena 421614. Confundirlos es una fuente común de transacciones fallidas que parecen problemas de RPC pero en realidad son problemas de red incorrecta.

¿Es suficiente un endpoint público para tu carga de trabajo?

Usa esto como un triaje rápido antes de invertir tiempo en la configuración. La pregunta no es si un endpoint público funciona, sino si funciona para lo que estás a punto de hacer con él.

Una regla útil: si más de un proceso depende del mismo endpoint al mismo tiempo, o si una solicitud fallida rompe un flujo visible para el usuario, has superado el nivel público. OnFinality ejecuta infraestructura compartida y dedicada de Sepolia, y puedes comparar opciones en la página de red Sepolia y precios de RPC.

Conexión con curl y JSON-RPC

La verificación más rápida es una llamada JSON-RPC sin procesar. Esto confirma que el endpoint es accesible y devuelve la cadena que esperas.

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

Una respuesta correcta devuelve el ID de cadena en hexadecimal:

{"jsonrpc":"2.0","id":1,"result":"0xaa36a7"}

0xaa36a7 es 11155111 en decimal, que es Ethereum Sepolia. Si obtienes un valor diferente, estás apuntando a la red incorrecta. Si obtienes un tiempo de espera o un 429, el endpoint es accesible pero tiene límite de velocidad, lo que es la señal para considerar un plan gestionado.

Otras dos llamadas vale la pena mantener en tu kit de herramientas. eth_blockNumber te dice si el nodo está sincronizado y siguiendo la cabeza de la cadena. eth_getBalance con una dirección conocida confirma que las lecturas de estado funcionan de extremo a extremo.

Configuración de billetera y biblioteca

En una billetera de navegador como MetaMask, agrega una red manualmente e ingresa la configuración de la cadena de la tabla anterior. El campo URL de RPC toma el endpoint público, y el ID de cadena debe ser el valor decimal 11155111. Las billeteras que piden un ID de cadena hexadecimal quieren 0xaa36a7.

En JavaScript, se aplica la misma configuración. Con viem:

import { createPublicClient, http } from 'viem'
import { sepolia } from 'viem/chains'

const client = createPublicClient({
  chain: sepolia,
  transport: http('https://eth-sepolia.api.onfinality.io/public'),
})

const blockNumber = await client.getBlockNumber()
console.log('Sepolia head:', blockNumber)

Con ethers v6:

import { JsonRpcProvider } from 'ethers'

const provider = new JsonRpcProvider(
  'https://eth-sepolia.api.onfinality.io/public',
  { chainId: 11155111, name: 'sepolia' }
)

console.log(await provider.getBlockNumber())

Pasar el ID de cadena explícitamente vale la línea extra. Hace que los errores de red incorrecta fallen ruidosamente en lugar de enviar silenciosamente una transacción a la cadena incorrecta.

Obtener ETH de prueba de un faucet

El ETH de Sepolia no tiene valor de mercado, pero aún lo necesitas para pagar gas. Los faucets son independientes de los endpoints RPC, y la mayoría restringe el acceso mediante un inicio de sesión, una verificación de saldo en mainnet o un desafío de proof-of-work para limitar el abuso.

Algunas notas prácticas:

• Los goteos de faucet son pequeños y tienen límite de velocidad por dirección. No esperes financiar una gran suite de pruebas con una sola solicitud.
• Si un faucet rechaza tu dirección, generalmente se debe a que la dirección ya tiene un saldo superior al umbral del faucet.
• La disponibilidad de los faucets cambia con el tiempo. Si uno está caído, prueba otro en lugar de asumir que tu endpoint RPC está roto.
• Mantén una dirección de reserva pequeña para gas para no tener que volver a solicitar fondos a mitad de la prueba.

Modos de fallo comunes y cómo interpretarlos

La mayoría de los problemas de RPC de Sepolia se dividen en un pequeño número de categorías. El texto del error generalmente te dice en cuál estás.

Si estás depurando una transacción específica, que eth_getTransactionReceipt devuelva null generalmente significa que la transacción aún está pendiente o nunca se transmitió, no que el endpoint esté roto. Verifica el estado del mempool antes de asumir un problema de infraestructura.

Dónde los endpoints públicos dejan de ser suficientes

Los endpoints públicos son un recurso compartido, y los recursos compartidos tienen modos de fallo compartidos. Tres patrones aparecen repetidamente en el trabajo con testnets:

CI en paralelo. Los trabajos de despliegue de contratos que se ejecutan en cada pull request pueden disparar docenas de transacciones en el mismo segundo. En un endpoint compartido, algunas de esas solicitudes serán limitadas, y el trabajo falla de forma intermitente de una manera difícil de reproducir localmente.

Indexación con muchos logs. eth_getLogs en un rango amplio de bloques es costoso. Los endpoints públicos normalmente limitan el rango o rechazan la consulta directamente. Si tu configuración de prueba imita un indexador de producción, necesitas acceso a archivo y un límite de rango más alto.

Llamadas de trace y debug. Los métodos debug_traceTransaction y trace_* no están habilitados en la mayoría de los endpoints públicos porque son computacionalmente pesados. Si tus pruebas dependen de ellos, necesitas un nodo configurado para ello.

Cuando te encuentras con cualquiera de estos, la solución no es una mejor URL pública. Es un endpoint gestionado con una capacidad definida, o un nodo dedicado que controlas. OnFinality ofrece ambos, y el artículo cómo elegir un proveedor de RPC repasa los criterios de evaluación con más detalle.

Pasar de un endpoint público a gestionado o dedicado

La migración en sí suele ser un cambio de configuración, no una reescritura. El trabajo está en elegir el nivel correcto y configurar respaldos.

1. Inventario de tus métodos. Enumera cada método JSON-RPC que llama tu aplicación. Marca las llamadas eth_getLogs, debug_* y trace_*, ya que estas determinan el tipo de nodo que necesitas.
2. Mide tu pico, no tu promedio. El tráfico de testnet es a ráfagas. Dimensiona para el minuto más ocupado que esperas, no para la media diaria.
3. Decide compartido versus dedicado. Los endpoints gestionados compartidos se adaptan a la mayoría de las dApps. Los nodos dedicados tienen sentido cuando necesitas capacidad aislada, configuración personalizada o rendimiento predecible bajo carga. Consulta nodos dedicados para saber qué implica.
4. Agrega un respaldo. Incluso con un endpoint gestionado, configura una segunda URL para que un problema de un solo proveedor no derribe tu entorno de prueba.
5. Mantén el endpoint público para pruebas de humo. No hay razón para eliminarlo. Úsalo para verificaciones rápidas y mantén el endpoint gestionado para todo lo que importa.

Si también pruebas en L2s, se aplica el mismo patrón a Base Sepolia, que usa el ID de cadena 84532 y una URL pública diferente. Mantener las configuraciones de testnet en un solo lugar, con los ID de cadena y los endpoints uno al lado del otro, evita la mayoría de los errores entre redes.

Puntos clave

• Ethereum Sepolia usa el ID de cadena 11155111, símbolo ETH, y el explorador sepolia.etherscan.io.
• Un endpoint RPC público de Sepolia es suficiente para billeteras, scripts únicos y pruebas manuales.
• Los endpoints públicos son compartidos y tienen límite de velocidad, por lo que CI en paralelo, indexación de logs y llamadas de trace alcanzarán los límites.
• Siempre pasa el ID de cadena explícitamente en tu cliente para que los errores de red incorrecta fallen ruidosamente.
• Los faucets son independientes de los endpoints RPC y tienen límite de velocidad por dirección.
• Cuando superes el nivel público, pasa a un endpoint gestionado o dedicado y mantén un respaldo configurado.
• Explora las redes RPC compatibles y compara precios de RPC antes de comprometerte con un plan.

Preguntas frecuentes

¿Cuál es el endpoint RPC público para Sepolia?

OnFinality publica un endpoint público en https://eth-sepolia.api.onfinality.io/public. Habla JSON-RPC estándar sobre HTTPS y no requiere clave de API. Es compartido, así que considéralo adecuado para desarrollo y pruebas ligeras en lugar de tráfico a escala de producción.

¿Cuál es el ID de cadena de Sepolia?

Ethereum Sepolia usa el ID de cadena 11155111, que es 0xaa36a7 en hexadecimal. Base Sepolia usa 84532 y Arbitrum Sepolia usa 421614. Siempre confirma que el ID de cadena coincida con la red que pretendes usar.

¿El endpoint público admite suscripciones WebSocket?

El soporte de transporte varía según la red y el endpoint. Si tu aplicación depende de eth_subscribe para nuevos heads o logs, consulta la página de la red para ver los transportes disponibles, o usa un endpoint gestionado o dedicado donde el soporte de WebSocket sea parte del plan.

¿Por qué recibo errores 429 en un endpoint público de Sepolia?

Un 429 significa que has superado el límite de velocidad compartido. Reduce tu tasa de solicitudes, agrupa llamadas cuando sea posible y considera un plan gestionado si el límite te bloquea constantemente. Es una señal de capacidad, no un error en tu código.

¿Puedo usar un endpoint público de Sepolia para pipelines de CI?

Para trabajos secuenciales de bajo volumen puede funcionar. Para trabajos en paralelo que despliegan contratos en cada push, los límites de velocidad compartidos causarán fallos intermitentes. Un endpoint gestionado con capacidad definida es la opción más confiable.

¿Necesito un nodo de archivo para pruebas en Sepolia?

Solo si consultas estado histórico o rangos amplios de logs. La mayoría de los flujos de trabajo de prueba no necesitan acceso a archivo, pero las pruebas estilo indexador y los scripts de backfill sí. Verifica los requisitos de los métodos antes de asumir que un nodo estándar es suficiente.