TON inicia una actualización a nivel de milisegundos y completa la activación total de la red principal el 7 de abril

El equipo central de TON anunció que la actualización del mecanismo de consenso Catchain 2.0 (actualización de Sub-Second) ya está en la fase de despliegue en la red principal. El objetivo es reducir el tiempo de confirmación final del bloque, que actualmente es de aproximadamente 10 segundos, a aproximadamente 1 segundo; el intervalo entre bloques, de aproximadamente 2,5 segundos, se acortará a 200-400 milisegundos. El 2 de abril, los validadores votaron para activar el nuevo consenso en la cadena base; el 7 de abril, la cadena base y la cadena principal habilitaron completamente el mecanismo de consenso rápido.

Indicadores técnicos: Catchain 2.0 hace que la velocidad de confirmación de TON se acerque a Web2

Catchain 2.0 es la actualización principal del consenso en TON. Su objetivo de diseño es lograr finalización de nivel subsegundo, haciendo que la experiencia on-chain en velocidad de respuesta se aproxime a los servicios tradicionales de Web2. A continuación, se muestra la comparación de tres dimensiones clave de rendimiento:

El intervalo entre bloques en la red principal actual es de aproximadamente 2,5 segundos, con alrededor de 0,4 bloques por segundo; el desfase de confirmación final es de aproximadamente 10 segundos. En la red de pruebas, el intervalo entre bloques es actualmente de aproximadamente 450 milisegundos, con una confirmación final de aproximadamente 1-2 segundos. Tras la actualización, el objetivo para la red principal es un intervalo entre bloques de 200-400 milisegundos, alrededor de 2,5-5 bloques por segundo, y un desfase de confirmación final de aproximadamente 1 segundo.

Al mismo tiempo, TON Center publicó Streaming API v2, que ofrece actualizaciones de estado de transacciones mediante empuje (push). La latencia, desde los eventos en la cadena hasta el cliente, es de 30-100 milisegundos. MyTonWallet y tonscan.org ya adoptaron esta nueva API; incluso antes de habilitar confirmaciones a nivel de subsegundos en la red principal, el tiempo de respuesta de transacciones de estos productos ya se ha reducido a casi la mitad.

Calendario de despliegue en tres fases: lista de tareas para cada nodo

El despliegue en la red principal de la actualización Sub-Second avanza con nodos impulsados por hitos temporales estrictos:

31 de marzo: todos los nodos validadores completan la actualización de versión y se actualizan a la versión más reciente que admite Catchain 2.0

2 de abril: los validadores votan para activar el nuevo mecanismo de consenso en la cadena base, aumentando la frecuencia de generación de bloques; el consenso rápido se pone en marcha oficialmente

7 de abril: la cadena base y la cadena principal habilitan de forma sincronizada y completa el mecanismo de consenso rápido; la actualización Sub-Second completa la activación en toda la red principal de TON

La paradoja central de la actualización: más velocidad de cadena, pero las APP no siguen

En su anuncio técnico, el equipo oficial de TON enfatizó especialmente el punto ciego clave de esta actualización que es más fácil pasar por alto: aunque la blockchain subyacente genere bloques a una velocidad 10 veces mayor, si los proyectos continúan usando sondeos (polling) HTTP en lugar de Streaming API, la latencia de actualización del estado de las transacciones en la interfaz de usuario aún podría superar los 10 segundos.

Por ejemplo, usando sondeo HTTP: después de que el usuario haga clic en «Enviar», la transacción se incluye en el bloque de fragmentos en aproximadamente 0,4 segundos y se envía a la cadena principal en 0,8 segundos; pero la actualización de la interfaz debe esperar a la siguiente solicitud de sondeo, lo que puede provocar una latencia superior a 10 segundos. En cambio, al cambiar a Streaming API v2, en 0,1 segundos se muestra el estado pending (pendiente), en 0,4 segundos el estado confirmed (confirmado) y en 0,8 segundos el estado finalized (confirmado definitivamente); todo el proceso se completa en menos de 1 segundo.

El equipo central de TON advirtió de manera explícita: «Si la aplicación no puede adaptarse, incluso si el sistema subyacente funciona con normalidad, la actualización parecerá no ser efectiva. Los proyectos que estén listos antes del lanzamiento en la cadena principal podrán mostrar el comportamiento y la experiencia de usuario esperados».

Preguntas frecuentes

¿Cuál es la diferencia fundamental entre Catchain 2.0 y el mecanismo de consenso de TON anterior?

Catchain 2.0 es una actualización importante del consenso en TON. El cambio clave es reducir drásticamente el intervalo de generación de bloques (de aproximadamente 2,5 segundos a 200-400 milisegundos) y el tiempo de confirmación final (de aproximadamente 10 segundos a aproximadamente 1 segundo). El rendimiento de bloques por segundo aumenta aproximadamente 2,5-5 veces, haciendo que, por diseño, la velocidad de respuesta de las interacciones on-chain de TON se acerque al estándar de los servicios tradicionales Web2.

¿Qué adaptaciones concretas necesitan los desarrolladores de aplicaciones en el ecosistema TON?

Las adaptaciones principales se concentran en tres aspectos: primero, cambiar a TON Center Streaming API v2 para recibir actualizaciones de estado de transacciones mediante empuje y reemplazar el sondeo HTTP; segundo, procesar los cuatro estados completos de transacciones (pending, confirmed, finalized, trace_invalidated) y actualizar el diseño de la UI en consecuencia; tercero, si ejecutan nodos de autogestión, necesitan actualizarse a la última versión que admita Catchain 2.0 antes del 7 de abril. Los exchanges y servicios de pagos que usan API externas no necesitan realizar ninguna acción adicional.

¿Qué significa para los usuarios comunes la actualización Sub-Second de TON?

Para los usuarios comunes, el cambio más directo es que, al usar carteras, dApps y servicios de pago que ya estén adaptados a la actualización, la velocidad de confirmación de las transferencias se reducirá drásticamente de aproximadamente 10 segundos a dentro de 1 segundo. Pero esta mejora depende completamente de si el proyecto ha completado la adaptación de Streaming API: las aplicaciones no adaptadas, aunque se ejecuten en la red principal después de la actualización, no tendrán ninguna mejora evidente en la experiencia del usuario.