TON démarre une mise à niveau à l’échelle de la sous-seconde, activation complète du réseau principal le 7 avril

L’équipe TON Core annonce que la mise à niveau du mécanisme de consensus, Catchain 2.0 (mise à niveau en sous-secondes), est entrée dans la phase de déploiement sur le réseau principal. L’objectif est de réduire le temps de confirmation finale des blocs d’environ 10 secondes à environ 1 seconde, et de raccourcir l’intervalle entre les blocs d’environ 2,5 secondes à 200-400 millisecondes. Le 2 avril, les validateurs activent le nouveau consensus sur la chaîne de base par vote ; le 7 avril, la chaîne de base et la chaîne principale activent pleinement le mécanisme de consensus rapide.

Indicateurs techniques : Catchain 2.0 fait que la vitesse de confirmation de TON se rapproche de Web2

Catchain 2.0 est la mise à niveau majeure du cœur de la couche de consensus de TON. Son objectif de conception est d’obtenir une finalité en dessous de la seconde, afin que l’expérience on-chain se rapproche, en termes de vitesse de réponse, des services Web2 traditionnels. Voici une comparaison des trois dimensions clés de performance :

Sur le réseau principal actuel, l’intervalle entre les blocs est d’environ 2,5 secondes, soit environ 0,4 bloc par seconde, et un décalage de finalisation d’environ 10 secondes ; sur le réseau de test, l’intervalle entre les blocs est actuellement d’environ 450 millisecondes, et la finalisation d’environ 1-2 secondes ; après la mise à niveau, l’objectif du réseau principal est un intervalle entre les blocs de 200-400 millisecondes, soit environ 2,5-5 blocs par seconde, avec un décalage de finalisation d’environ 1 seconde.

Dans le même temps, TON Center a publié le Streaming API v2, qui fournit des mises à jour d’état des transactions avec des mécanismes de type push. La latence, de l’événement on-chain jusqu’au client, est de 30-100 millisecondes. MyTonWallet et tonscan.org ont déjà adopté cette nouvelle API : même avant l’activation de la confirmation en sous-secondes sur le réseau principal, le temps de réponse des transactions de ces produits a déjà été réduit d’environ moitié.

Calendrier de déploiement en trois phases : liste des tâches pour chaque nœud

Le déploiement sur le réseau principal de la mise à niveau en sous-secondes progresse selon des jalons temporels stricts :

31 mars : tous les nœuds de validation terminent la mise à jour de version, et passent à la dernière version prenant en charge Catchain 2.0

2 avril : les validateurs votent pour activer le nouveau mécanisme de consensus sur la chaîne de base, augmentant la fréquence de production de blocs ; le consensus rapide démarre officiellement

7 avril : la chaîne de base et la chaîne principale activent simultanément le mécanisme de consensus rapide ; la mise à niveau en sous-secondes se termine par l’activation sur l’ensemble du réseau principal TON

Le paradoxe central de la mise à niveau : la chaîne accélère, mais l’application ne suit pas

Dans son annonce technique, TON officiel souligne particulièrement le point aveugle clé le plus facilement négligé lors de cette mise à niveau : même si la blockchain sous-jacente génère des blocs à une vitesse 10 fois plus rapide, si les porteurs de projet continuent d’utiliser le polling HTTP au lieu du Streaming API, la latence des mises à jour d’état des transactions de l’interface utilisateur peut toujours dépasser 10 secondes.

Prenons l’exemple du polling HTTP : après que l’utilisateur clique sur « envoyer », la transaction est incluse dans un bloc de shard en environ 0,4 seconde, puis soumise à la chaîne principale en 0,8 seconde. Or, la mise à jour UI doit attendre la prochaine requête de polling, ce qui peut entraîner une latence dépassant 10 secondes. En revanche, après basculement vers le Streaming API v2, l’état pending (en cours de traitement) s’affiche en 0,1 seconde, l’état confirmed (confirmé) en 0,4 seconde, et l’état finalized (finalisé) en 0,8 seconde ; l’ensemble du processus est terminé en moins d’une seconde.

L’équipe TON Core met en garde de façon explicite : « Si l’application ne peut pas effectuer l’adaptation, même si le système sous-jacent fonctionne normalement, la mise à niveau semblera inefficace. Les projets prêts avant le lancement sur la chaîne principale pourront démontrer le comportement et l’expérience utilisateur attendus. »

Questions fréquentes

Quelle est la différence fondamentale entre Catchain 2.0 et les mécanismes de consensus TON précédents ?

Catchain 2.0 est une mise à niveau majeure de la couche de consensus de TON. Le changement central consiste à raccourcir fortement l’intervalle de production des blocs (d’environ 2,5 secondes à 200-400 millisecondes) ainsi que le temps de finalisation (d’environ 10 secondes à environ 1 seconde). Le débit de blocs par seconde augmente d’environ 2,5 à 5 fois, ce qui rapproche, dans sa conception, la vitesse de réponse des interactions on-chain TON des standards des services Web2 traditionnels.

Quelles adaptations concrètes les développeurs d’applications dans l’écosystème TON doivent-ils réaliser ?

Les adaptations se concentrent principalement sur trois aspects : premièrement, passer au TON Center Streaming API v2 pour recevoir des mises à jour d’état des transactions en mode push, en remplaçant le polling HTTP ; deuxièmement, traiter les quatre états de transaction (pending, confirmed, finalized, trace_invalidated) et mettre à jour la conception de l’UI en conséquence ; troisièmement, si vous exécutez des nœuds en autogestion (self-hosted), vous devez mettre à jour vers la dernière version prenant en charge Catchain 2.0 avant le 7 avril. Les échanges et services de paiement utilisant des API externes n’ont pas besoin d’effectuer d’actions supplémentaires.

Que signifie la mise à niveau en sous-secondes de TON pour les utilisateurs ordinaires ?

Pour les utilisateurs ordinaires, le changement le plus direct est le suivant : lors de l’utilisation de portefeuilles, d’un dApp et de services de paiement déjà adaptés à la mise à niveau, la vitesse de confirmation des transferts sera fortement réduite, passant d’environ 10 secondes à moins d’une seconde. Cependant, cette amélioration dépend entièrement de savoir si les porteurs de projet ont terminé l’adaptation du Streaming API : les applications non adaptées, même lorsqu’elles fonctionnent sur le réseau principal après la mise à niveau, n’auront aucune amélioration notable de l’expérience utilisateur.