¿Cómo se elige un proveedor de Stellar RPC para aplicaciones Soroban?

Lista de verificación para elegir un proveedor de Stellar RPC

Antes de comparar proveedores, define qué necesita tu aplicación de Stellar RPC. Esta lista cubre las decisiones que enfrentan la mayoría de los equipos.

• Confirma qué redes necesitas: Mainnet, Testnet o Futurenet. Algunos proveedores solo exponen una o dos.
• Decide si necesitas datos de archive. Si tu aplicación muestra historial de ledger, verifica si el proveedor soporta el método de archive getLedgers.
• Estima tu tráfico. Un endpoint público compartido puede ser suficiente para desarrollo, pero las aplicaciones Soroban en producción a menudo necesitan un endpoint privado o un nodo dedicado.
• Prueba con solicitudes reales. Llama a los mismos métodos JSON-RPC que usarás en producción, no solo una verificación de salud.
• Revisa los límites de tasa y las políticas de uso justo. Los endpoints públicos suelen tener límites más estrictos que las opciones dedicadas.
• Verifica la compatibilidad del SDK. Los SDK de Stellar (stellar-sdk, soroban-client) deberían funcionar con el endpoint del proveedor sin envoltorios personalizados.
• Planifica la conmutación por error. Varios endpoints o un proveedor con enrutamiento redundante reducen la posibilidad de un punto único de fallo.
• Compara los precios con tu volumen esperado, incluidos los extras de archive o WebSocket.

Si además estás comparando ventajas y desventajas generales de proveedores de RPC, consulta cómo elegir un proveedor de RPC. Para una lista completa de cadenas y tipos de endpoint compatibles, consulta la página de redes RPC compatibles.

¿Qué es Stellar RPC?

Stellar RPC es una API JSON-RPC que brinda a las aplicaciones acceso en tiempo real a los datos de la red Stellar. Originalmente se introdujo como Soroban RPC para soportar contratos inteligentes Soroban, y pasó a llamarse Stellar RPC a finales de 2024. Hoy es la forma estándar de:

• Consultar el ledger actual y el estado de la red
• Leer entradas del ledger para cuentas, contratos y activos
• Enviar transacciones y seguir su estado
• Obtener eventos y simulaciones de contratos inteligentes

Stellar RPC es intencionalmente más ligero que Horizon. Expone un conjunto pequeño de métodos y mantiene una ventana limitada de historial reciente, unos siete días por defecto. No es un reemplazo de Horizon, ni un indexador de datos históricos. Esta distinción importa al evaluar proveedores, porque el soporte de archive es una capacidad separada del acceso RPC normal.

La documentación oficial de Stellar RPC y el repositorio de GitHub stellar-rpc son buenas referencias cuando quieres entender el protocolo en sí. Sin embargo, al comparar opciones alojadas, los siguientes criterios importan más que la implementación subyacente del servidor.

Qué comparar entre proveedores de Stellar RPC

Usa esta tabla como punto de partida cuando evalúes proveedores de Stellar RPC.

Muchos de los mismos criterios aplican a cualquier cadena, pero Stellar tiene algunos ángulos únicos. Primero, como RPC es la interfaz principal para los contratos Soroban, tu elección de proveedor afecta directamente la fiabilidad con la que puedes enviar llamadas de contrato y rastrear transacciones. Segundo, la distinción entre RPC normal y RPC de archive aún es nueva para Stellar, por lo que no todos los proveedores soportan getLedgers todavía. La página de la red Stellar muestra RPC mainnet, soporte de archive y nodos dedicados como opciones disponibles de OnFinality, lo que coincide con el conjunto de características que muchos equipos de producción necesitan.

Ejemplo: consultar el último ledger con cURL

La forma más rápida de probar un proveedor de Stellar RPC es llamar a getLatestLedger. La solicitud sigue el formato JSON-RPC 2.0:

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

Una respuesta exitosa se ve así:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "hash": "8e8d0b...",
    "seq": 1283922,
    "ledgerCloseTime": 1699999999,
    "protocolVersion": 22
  }
}

El campo seq te indica el número de secuencia del último ledger, y protocolVersion te indica qué versión del protocolo Stellar está ejecutando el nodo. Si la solicitud falla, el proveedor puede estar caído, atrasado en la sincronización o bloqueando solicitudes de tu región. Prueba la misma solicitud contra tu propio nodo o un segundo proveedor para acotar la causa.

Para aplicaciones con muchas transacciones, también usarás métodos como sendTransaction, getTransaction, getLedgerEntries y getEvents. Prueba estos métodos antes de comprometerte, porque las implementaciones de los proveedores pueden diferir en cómo manejan la codificación de parámetros y los formatos de respuesta.

Errores comunes al usar un proveedor de Stellar RPC

Como Stellar RPC sigue siendo una capa relativamente nueva sobre Stellar Core, los desarrolladores suelen encontrarse con los mismos problemas.

Tratar RPC como un indexador. RPC mantiene una ventana limitada de historial. Si tu aplicación necesita mostrar transacciones o saldos pasados, necesitas una solución de indexación separada o un proveedor con soporte de archive. Para el historial completo del ledger, pregunta si el proveedor soporta el método getLedgers.

Ignorar las diferencias entre redes. Mainnet, Testnet y Futurenet tienen configuración y datos diferentes. Una transacción que funciona en Testnet puede fallar en Mainnet si fijaste manualmente la passphrase de la red o una dirección de contrato de testnet.

Depender de un endpoint público compartido en producción. Los endpoints públicos son convenientes para prototipos, pero se comparten entre muchos usuarios y pueden estar limitados o no disponibles temporalmente. Las aplicaciones de producción deberían usar endpoints autenticados o un nodo dedicado, según el tráfico.

No verificar el soporte de archive antes de crear una función de historial. Los documentos de Stellar ahora listan proveedores con capacidad de "RPC Archive". Si necesitas historial del ledger, elige un proveedor que lo soporte explícitamente en lugar de asumir que todos los proveedores RPC lo hacen.

Enviar transacciones sin tarifa o simulación suficiente. Las llamadas a contratos Soroban a menudo requieren simulación antes del envío. Asegúrate de que tu proveedor te permita llamar a simulateTransaction y de que estás usando la versión del SDK que tu proveedor espera.

Nodos dedicados vs endpoints compartidos de Stellar RPC

Tu patrón de tráfico determina si un endpoint compartido es suficiente. El desarrollo, las carteras pequeñas y los oyentes de eventos de baja frecuencia a menudo pueden usar un endpoint público o autenticado compartido. El trading de alto rendimiento, los pipelines de indexación o las aplicaciones que necesitan latencia constante deberían considerar un nodo dedicado.

Los nodos dedicados te brindan:

• Capacidad de solicitudes aislada
• Más control sobre los límites de tasa
• La capacidad de ajustar la configuración del nodo
• Menos efectos de vecino ruidoso

OnFinality ofrece tanto un servicio de API RPC como nodos dedicados. Los nodos dedicados de Stellar son útiles cuando quieres el control operativo de ejecutar un nodo sin administrar el hardware tú mismo. Si no estás seguro de qué opción se ajusta a tu carga de trabajo, contacta al equipo de OnFinality a través de la página de la red y describe tu perfil de tráfico.

Cómo empezar con un proveedor de Stellar RPC

Si estás listo para probar Stellar RPC, comienza con un flujo de trabajo sencillo:

1. Elige un proveedor que soporte las redes que necesitas.
2. Usa el endpoint público o gratuito para ejecutar el ejemplo de getLatestLedger anterior.
3. Escribe un pequeño script que envíe una transacción a Testnet y consulte getTransaction.
4. Revisa la página de precios del proveedor y estima tu volumen mensual de solicitudes.
5. Una vez que la aplicación funcione, muévete a un endpoint autenticado o a un nodo dedicado.

OnFinality proporciona un endpoint gestionado de Stellar RPC en https://stellar.api.onfinality.io/public para mainnet. Consulta la página de la red Stellar para ver los últimos detalles del endpoint e información sobre el acceso a testnet. Para orientación sobre precios, consulta la página de precios de RPC.

La clave es validar con los mismos métodos, tamaños de payload y patrones de tráfico que esperas en producción. Un proveedor que parece rápido en una verificación de salud puede tener dificultades con un tráfico intenso de getEvents o simulaciones de contratos grandes.

Preguntas frecuentes

¿Cuál es la diferencia entre Stellar RPC y Horizon?

Stellar RPC es una API JSON-RPC ligera centrada en el estado del ledger, los contratos inteligentes y el envío de transacciones. Horizon es una API con más funciones que soporta consultas históricas e indexación. RPC no es un reemplazo directo de Horizon.

¿Soporta Stellar RPC los contratos inteligentes Soroban?

Sí. Stellar RPC se creó para soportar contratos Soroban. Incluye métodos para simular transacciones, obtener eventos de contratos y leer entradas del ledger.

¿Puedo obtener datos históricos del ledger de un proveedor de Stellar RPC?

El Stellar RPC normal solo retiene una ventana limitada del historial reciente. Algunos proveedores ahora ofrecen soporte de RPC de archive mediante el método getLedgers, que puede devolver datos más antiguos del ledger.

¿Qué redes soportan los proveedores de Stellar RPC?

La mayoría de los proveedores soportan Mainnet y Testnet, y un número menor soporta Futurenet. Confirma siempre la lista de redes del proveedor antes de comenzar el desarrollo.

¿Es un endpoint público de Stellar RPC suficientemente bueno para producción?

Para aplicaciones de bajo tráfico, puede serlo. Para aplicaciones de nivel de producción, normalmente quieres un endpoint autenticado o un nodo dedicado para obtener límites de tasa y fiabilidad predecibles. Evalúa tus necesidades de tráfico antes de decidir.

Conclusiones clave

• Stellar RPC es la interfaz JSON-RPC principal para los contratos inteligentes Soroban y el estado del ledger, y no es un indexador.
• Al elegir un proveedor, compara cobertura de red, soporte de archive, disponibilidad de nodos dedicados, límites de tasa y compatibilidad del SDK.
• Prueba con métodos reales como getLedgerEntries, sendTransaction y getEvents, no solo getHealth.
• El soporte de archive para getLedgers es una capacidad distinta que no todos los proveedores ofrecen.
• Los endpoints públicos compartidos son buenos para desarrollo; las aplicaciones de producción deberían considerar endpoints privados o nodos dedicados.
• OnFinality lista Stellar RPC en su página de red y ofrece opciones tanto de RPC compartido como de nodos dedicados.