Pourquoi TON déjoue les explorateurs ordinaires
TON est construit sur un modèle d’acteurs. Chaque contrat est un acteur indépendant avec son propre état, et les contrats communiquent uniquement en envoyant des messages. Il n’y a pas d’appels synchrones — un contrat ne peut pas en appeler un autre et attendre la réponse au sein de la même exécution.
Une seule action utilisateur se décompose donc en une séquence. Vous envoyez un message à votre contrat de portefeuille. Il envoie un message à un portefeuille jetton. Celui-ci envoie un message au portefeuille jetton du destinataire. Celui-ci peut envoyer une notification plus loin. Chaque saut est une transaction on-chain distincte, dans un bloc distinct, éventuellement dans un shard distinct.
Un explorateur qui vous montre « la transaction » vous montre le premier saut. Tout ce qui comptait s’est passé après, et si quelque chose a échoué trois sauts plus loin, le premier saut paraît quand même entièrement réussi.
C’est le même schéma structurel que les reçus NEAR et le XCM de Polkadot, et cela produit la même catégorie de confusion. Sur TON, c’est plus aigu car cela affecte même le plus simple transfert de token.
Les portefeuilles jetton, et où sont réellement vos tokens
Le standard de token de TON s’appelle Jetton et il ne fonctionne pas comme l’ERC-20.
Sur Ethereum, un contrat de token détient un mapping du solde de chaque détenteur. Sur TON, chaque détenteur reçoit son propre contrat de portefeuille jetton, déployé séparément, ne détenant que son solde. Le contrat maître régit le token ; il ne stocke pas qui possède quoi.
C’est une décision de mise à l’échelle délibérée — elle évite qu’un contrat unique ne devienne un goulot d’étranglement à travers les shards — et elle produit une confusion spécifique et récurrente : votre solde de token n’est pas à l’adresse de votre portefeuille. Il est à une adresse de portefeuille jetton dérivée que votre portefeuille possède.
Les gens envoient constamment des tokens vers le mauvais de ces portefeuilles. Tonviewer les étiquette explicitement, montrant le propriétaire aux côtés de chaque portefeuille jetton, ce qui rend le modèle compréhensible plutôt qu’alarmant.
L’autre conséquence est que recevoir un jetton pour la première fois nécessite de déployer votre portefeuille jetton, ce qui coûte un petit montant attaché au transfert. Si l’expéditeur en a attaché trop peu, le transfert rebondit — et c’est le mode d’échec que la section suivante couvre.
Les messages rebondis, la version TON d’un revert
Quand un message TON ne peut pas être traité, il rebondit : la valeur retourne à l’expéditeur, moins les frais. C’est le mode d’échec normal et cela ne ressemble en rien à un revert EVM, car la transaction originale a déjà réussi au moment où le rebond se produit.
L’implication pratique vaut la peine d’être dite deux fois. Sur TON, une transaction réussie ne signifie pas un résultat réussi. Cela signifie que votre message a été accepté pour livraison. Ce qui s’est passé à l’autre bout est un événement séparé qui peut arriver quelques secondes plus tard.
Tonviewer marque clairement les messages rebondis dans la trace. Si un transfert « est passé » et que le destinataire ne signale rien, c’est le premier endroit à regarder, et cela explique l’écrasante majorité de ces cas.
Dans nos propres tests, nous avons tracé un transfert de jetton que deux explorateurs montraient comme réussi. Le premier saut a réussi, le second a réussi, et le troisième a rebondi car le portefeuille jetton du destinataire n’avait pas été déployé et la valeur attachée était insuffisante pour le déployer. Seule la trace de messages complète l’a révélé.
Travailler avec TON sans surprises
Trois habitudes rendent TON nettement moins déroutant.
D’abord, regardez toujours la trace complète plutôt que la transaction. Si votre explorateur n’en propose pas, vous utilisez le mauvais explorateur pour cette question.
Ensuite, identifiez les jettons par leur adresse de contrat maître plutôt que par leur nom. Les noms de jettons sont arbitraires et dupliqués librement, exactement comme les noms de tokens sur chaque autre chaîne, et l’architecture à portefeuilles séparés rend légèrement plus facile la confusion sur le contrat que vous regardez réellement.
Enfin, gardez les deux explorateurs en favoris. Sur une chaîne aussi structurellement inhabituelle, un second rendu des mêmes données a résolu plus de confusion pour nous que sur tout autre réseau. Quand Tonviewer et Tonscan sont en désaccord, le désaccord lui-même est une information — cela signifie généralement que l’un d’eux traite différemment un schéma de message inhabituel, et la vue brute est celle à laquelle faire confiance pendant que vous déterminez lequel.
Les shards, et pourquoi les hauteurs de bloc ne signifient pas ce que vous attendez
TON est partitionné (sharded), et le partitionnement est dynamique — le réseau divise et fusionne les shards selon la charge plutôt que de fonctionner avec un nombre fixe.
La conséquence pour quiconque lit un explorateur est qu’il n’existe pas de hauteur de bloc unique. Il y a une masterchain, qui coordonne, et des shards de workchain produisant chacun leurs propres blocs. Une transaction vit dans un bloc de shard, qui est ensuite référencé par un bloc de la masterchain.
Comparer des chiffres de « hauteur de bloc » entre TON et une autre chaîne est donc dénué de sens, et les comparer entre deux explorateurs TON peut revenir à comparer des choses différentes. Les explorateurs mettent généralement en avant le numéro de séquence de la masterchain comme chiffre principal, ce qui est le choix judicieux et non le seul défendable.
La finalité suit la masterchain. Une transaction incluse dans un bloc de shard est finale une fois que ce bloc de shard est référencé par un bloc de la masterchain, ce qui se produit rapidement mais constitue une deuxième étape plutôt que la première.
Rien de tout cela n’affecte l’usage ordinaire. Cela compte quand vous réconciliez des données entre outils, construisez quoi que ce soit qui suit les confirmations, ou essayez de comprendre pourquoi deux explorateurs rapportent des chiffres différents pour ce qui semble être la même chose.
C’est aussi la raison sous-jacente de l’asynchronie qui domine le reste de cette page. Les contrats sur des shards différents ne peuvent pas s’appeler synchroniquement car les shards ne sont pas synchronisés au même rythme — le modèle de messages n’est pas une préférence de conception, c’est une conséquence du partitionnement.