¿Qué es un nodo público de TON y cuándo deberías usar uno?

¿Es un nodo público de TON el punto de partida adecuado?

Un nodo público de TON es un endpoint RPC compartido que permite a tu aplicación leer la blockchain de TON y enviar transacciones sin ejecutar tu propia infraestructura. Es el punto de entrada predeterminado para la mayoría de los desarrolladores: copias una URL, envías una solicitud y obtienes una respuesta. Sin sincronización, sin disco, sin servidor que mantener.

El problema es que "público" significa compartido. Eres uno de muchos llamadores que acceden al mismo endpoint, sin control sobre la capacidad, sin acuerdo de nivel de servicio y sin garantía de que un método que utilizas siga disponible. Eso está bien para un prototipo, un script o una billetera que estás probando. Se convierte en un problema en el momento en que usuarios reales dependen de tu aplicación.

Usa este artículo para decidir en qué lado de esa línea te encuentras y qué hacer a continuación.

Recomendación rápida: ¿nodo público, RPC gestionado o nodo dedicado?

Si solo necesitas responder "¿funciona mi código con TON?", un nodo público es el camino más rápido. Si necesitas responder "¿se mantendrá mi aplicación en funcionamiento bajo carga?", lo has superado.

En qué se diferencia TON RPC de las cadenas EVM

Si vienes de Ethereum, BNB Chain o Polygon, TON te resultará desconocido. TON no es una cadena EVM, por lo que no llamarás a eth_getBalance o eth_call. En su lugar, TON expone su propia superficie de API basada en HTTP, y la forma de direccionar cuentas, enviar mensajes y leer el estado es diferente.

Algunas diferencias prácticas importan cuando eliges un endpoint:

• Las cuentas se direccionan de forma diferente. TON utiliza sus propios formatos de dirección, y la misma cuenta puede representarse de más de una forma. Tus herramientas deben normalizar las direcciones antes de compararlas o almacenarlas.
• Las transacciones están impulsadas por mensajes. No simplemente "envías una transacción" como lo harías en una cadena EVM. Construyes y envías mensajes, y la transacción resultante es producida por la red.
• Los nombres de los métodos son específicos de TON. En lugar de métodos eth_*, trabajas con los endpoints propios de TON para el estado de la cuenta, bloques, transacciones y envío de mensajes.
• Las bibliotecas importan. La mayoría de los desarrolladores interactúan a través de un SDK de TON en lugar de HTTP sin procesar, porque el SDK se encarga del análisis de direcciones, la serialización de celdas y la construcción de mensajes por ti.

Debido a esto, "¿qué nodo público de TON debería usar?" es en realidad dos preguntas: qué endpoint y qué biblioteca cliente se sitúa encima de él.

Conexión a un endpoint de TON

OnFinality expone un endpoint RPC de TON sobre HTTP. Puedes ver los detalles actuales del endpoint en la página de la red TON. El patrón para una llamada estilo JSON-RPC sin procesar es así:

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

Para la mayoría del código de aplicación, no llamarás al endpoint directamente. Apuntarás un SDK de TON hacia él. Una configuración típica es así:

import { TonClient } from "@ton/ton";

const client = new TonClient({
  endpoint: "https://ton.api.onfinality.io/public",
  apiKey: process.env.ONFINALITY_API_KEY, // required for managed plans
});

const masterchain = await client.getMasterchainInfo();
console.log(masterchain);

Dos cosas a tener en cuenta. Primero, la ruta exacta del endpoint y si se requiere una clave API dependen del plan que tengas, así que confírmalo en la página de la red TON en lugar de copiar una URL de un tutorial antiguo. Segundo, mantén el endpoint en una variable de entorno. Codificarlo de forma fija dificulta el cambio entre un endpoint público, uno gestionado y uno de testnet.

Cambiar a TON Testnet

Testnet es una red separada con su propio endpoint. Apunta tu cliente a la configuración de TON Testnet RPC cuando quieras probar flujos de mensajes sin tocar los saldos de mainnet. Mantén la configuración de testnet y mainnet en archivos de entorno separados para que nunca envíes accidentalmente un mensaje de mainnet desde una ejecución de prueba.

Dónde fallan los nodos públicos de TON

Los endpoints públicos no están rotos por diseño; simplemente no están construidos para tráfico de producción. Los modos de fallo son predecibles:

• Límite de velocidad. Los endpoints compartidos limitan a los llamadores para proteger el grupo. Una ráfaga desde tu backend puede ser rechazada incluso si tu carga promedio es baja.
• Varianza de latencia. Compartes capacidad con todos los demás, por lo que los tiempos de respuesta varían con la demanda general.
• Brechas de métodos. Algunos endpoints exponen un subconjunto de métodos. Si necesitas un historial más profundo o consultas más pesadas, un nodo público puede no servirlas.
• Sin ruta de soporte. Cuando algo falla, no hay nadie a quien escalar. Depuras solo.
• Sin visibilidad. No puedes ver si una ralentización es tu código o el endpoint.

Ninguno de estos es fatal para un prototipo. Todos son fatales para un producto con usuarios.

Lista de verificación de preparación para producción

Antes de lanzar una aplicación TON en cualquier endpoint, incluido uno público, revisa esta lista:

1. El endpoint es configurable. Vive en una variable de entorno, no en el código fuente.
2. Existe failover. Tienes al menos un endpoint de respaldo, o un proveedor que gestiona el failover por ti.
3. Los reintentos están acotados. Reintentas en errores transitorios con retroceso exponencial y te detienes después de un límite.
4. Puedes ver los errores. El registro captura los fallos del endpoint por separado de los errores de la aplicación.
5. Conoces tu perfil de solicitudes. Aproximadamente cuántas llamadas por segundo y qué métodos dominan.
6. Tienes una ruta de testnet. Puedes reproducir problemas en TON Testnet sin arriesgar fondos de mainnet.
7. Conoces tu disparador de actualización. Decide ahora qué métrica (tasa de error, latencia o volumen de solicitudes) significa "pasar a RPC gestionado".

Si no puedes marcar la mayoría de estas casillas, un nodo público sigue siendo el lugar correcto. Si puedes marcarlas y el endpoint es el eslabón débil, es hora de cambiar.

Cuándo pasar a RPC gestionado o a un nodo dedicado

RPC gestionado y nodos dedicados resuelven problemas diferentes, y ayuda separarlos.

Una API RPC gestionada te da un endpoint estable con una clave, monitoreo y una ruta de soporte. No ejecutas nada. Este es el movimiento correcto para la mayoría de las aplicaciones en producción: elimina las sorpresas de límite de velocidad y te da alguien con quien hablar cuando falla una consulta. OnFinality ofrece esto como un servicio de API RPC en muchas redes, con TON incluido.

Un nodo dedicado te da capacidad aislada. No compartes rendimiento con otros llamadores, lo cual importa para indexación de alto volumen, analítica o cargas de trabajo con necesidades de latencia ajustadas. Este es el movimiento correcto cuando tu perfil de solicitudes es lo suficientemente pesado como para que la capacidad compartida sea el cuello de botella. Consulta nodos dedicados para saber cómo funciona.

Una forma sencilla de decidir:

• Prototipo, script o herramienta de bajo volumen: nodo público.
• Aplicación con usuarios y un backend: API RPC gestionada.
• Carga pesada, sostenida o sensible a la latencia: nodo dedicado.

Puedes comparar el coste y las expectativas de rendimiento en la página de precios de RPC, y ver qué redes están cubiertas en redes RPC compatibles.

Depuración de llamadas TON RPC

Cuando falla una llamada a TON, el error suele caer en uno de unos pocos grupos. Relaciona el síntoma con la causa probable antes de cambiar el código.

Un hábito útil es registrar la URL del endpoint junto con cada error. La mitad de los informes de "TON RPC está roto" resultan ser dos entornos apuntando a endpoints diferentes.

Hábitos operativos que ahorran tiempo después

Algunas prácticas pequeñas hacen que el paso de nodo público a producción sea mucho más fluido:

• Fija endpoints por entorno. Desarrollo, staging y producción deben tener cada uno un endpoint claramente nombrado.
• Separa las rutas de lectura y escritura. Las lecturas a menudo pueden tolerar un endpoint compartido; las escrituras suelen merecer el más fiable que tengas.
• Vigila la tasa de error, no solo la latencia. Un endpoint rápido que rechaza el 5% de las llamadas es peor que uno más lento que las acepta todas.
• Mantén una vía de escape. Conoce la URL a la que cambiarías si tu endpoint principal se degrada, y prueba ese cambio antes de necesitarlo.
• Documenta tus métodos. Enumera los métodos de TON que tu aplicación realmente llama. Esa lista es lo que entregas a un proveedor cuando evalúas planes.

Estos hábitos cuestan poco ahora y eliminan la mayor parte del dolor de escalar después.

Puntos clave

• Un nodo público de TON es un endpoint compartido para leer datos de TON y enviar mensajes sin ejecutar infraestructura.
• TON no es una cadena EVM, por lo que los nombres de métodos, el manejo de direcciones y el flujo de transacciones difieren del RPC estilo Ethereum.
• Los nodos públicos son ideales para prototipos, scripts y herramientas de bajo volumen, pero son compartidos, tienen límite de velocidad y no tienen soporte.
• Pasa a una API RPC gestionada cuando tengas usuarios reales; pasa a un nodo dedicado cuando la capacidad compartida se convierta en tu cuello de botella.
• Mantén los endpoints en variables de entorno, planifica el failover y decide tu disparador de actualización antes de lanzar.
• OnFinality ofrece TON RPC a través de su servicio de API RPC y nodos dedicados; consulta precios de RPC y redes RPC compatibles para más detalles.

Preguntas frecuentes

¿Qué es un nodo público de TON?

Es un endpoint RPC compartido que te permite interactuar con la blockchain de TON sin ejecutar tu propio nodo. Envías solicitudes a una URL y recibes respuestas, pero compartes capacidad con otros usuarios y no tienes garantía de servicio.

¿Es gratuito un nodo público de TON?

Los endpoints públicos suelen ser gratuitos, por eso son populares para pruebas. El acceso gratuito normalmente conlleva límites de velocidad y sin soporte, por lo que no es adecuado para tráfico de producción.

¿Puedo usar un nodo público de TON en producción?

Puedes, pero no deberías confiar en él. Los endpoints compartidos limitan a los llamadores y no ofrecen failover ni soporte. Para aplicaciones con usuarios reales, una API RPC gestionada es la opción más segura.

¿Cuál es la diferencia entre un nodo público de TON y un nodo dedicado?

Un nodo público se comparte con otros llamadores. Un nodo dedicado da a tu carga de trabajo capacidad aislada, lo cual importa para aplicaciones de alto volumen o sensibles a la latencia.

¿Cómo me conecto a TON desde JavaScript?

Usa un SDK de TON como @ton/ton y apúntalo a un endpoint. Mantén el endpoint y cualquier clave API en variables de entorno para que puedas cambiar entre configuraciones públicas, gestionadas y de testnet.

¿Necesito un endpoint separado para TON Testnet?

Sí. Testnet es una red separada con su propio endpoint. Consulta la página de TON Testnet RPC para la configuración actual.

¿Dónde puedo encontrar el endpoint RPC de TON actual?

Consulta la página de la red TON para los detalles del endpoint que se aplican a tu plan, en lugar de copiar una URL de un tutorial más antiguo.

¿Cuándo debería dejar de usar un nodo público?

Cuando tengas usuarios reales, un backend o un bot que dependa de respuestas consistentes. Si los errores del endpoint o los límites de velocidad están afectando tu aplicación, es hora de pasar a RPC gestionado o a un nodo dedicado.