Guide du débutant pour TON : comptes, tokens et sécurité

Contexte

TON (The Open Network) est une plateforme blockchain décentralisée initialement conçue et développée par l’équipe de Telegram. TON vise à fournir une plateforme blockchain performante et évolutive pour soutenir les applications décentralisées (DApps) et les contrats intelligents à grande échelle.

TON est unique en ce sens qu’il est facile à utiliser, profondément intégré à Telegram, permettant aux gens ordinaires d’utiliser facilement des jetons. En même temps, il est complexe, avec une architecture distincte des autres blockchains, et il utilise un langage de contrat intelligent non courant appelé FunC.

Aujourd’hui, nous allons examiner les caractéristiques des TON et la sécurité des actifs des utilisateurs du point de vue des comptes, des jetons et des transactions.

Caractéristiques du TON

Génération de comptes

La méthode de génération d’une adresse de compte sur TON est différente de la plupart des blockchains ; il s’agit d’une adresse de contrat intelligent. Tout commence par une clé privée. TON utilise principalement l’algorithme Ed25519 pour générer une clé publique, avec le processus suivant :

Il existe deux formes de clé publique : la première est la clé publique brute calculée à partir de la clé privée, qui se présente comme suit :

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

L’autre est une clé publique « embellie », qui comprend des informations et des bits de contrôle, et qui se présente comme suit :

Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Si vous pensez qu’il suffit d’obtenir la clé publique pour obtenir l’adresse du compte comme dans Ethereum, vous vous trompez. Il ne suffit pas d’avoir la clé publique de l’utilisateur pour calculer l’adresse de son compte.

Comme indiqué, l’adresse du compte de l’utilisateur est une adresse de contrat intelligent, mais comment déployer un contrat intelligent sans disposer d’un compte ?

La séquence correcte consiste à calculer d’abord l’adresse, à recevoir un montant initial de jetons, puis à déployer le contrat. Le processus de calcul de l’adresse du compte est illustré dans le diagramme suivant :

L’adresse d’un utilisateur se présente également sous plusieurs formes. Tout d’abord, il y a la forme brute, qui ressemble à :

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

Il existe ensuite un formulaire facile à utiliser, qui se présente comme suit :

Réseau principal :

• Rebondissable : EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
• Non rebondissable : UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Testnet :

• Rebondissable : kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
• Non rebondissable : 0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

En observant attentivement ces adresses, on constate qu’elles ne diffèrent que par les premiers et les derniers caractères, le account_id du milieu étant identique.

Cependant, nous ne pouvons toujours pas voir la relation entre la clé publique et l’adresse du compte.

Le secret réside dans le initial data au début, qui contient la clé publique de l’utilisateur, permettant à ce dernier de contrôler le contrat du portefeuille. Le workchainId est facile à comprendre : TON n’est pas une chaîne unique, mais se compose de nombreux fragments.

Chaque shard est une partie du réseau entier, gérant des comptes et des transactions spécifiques. Pour localiser et gérer les contrats intelligents, il est nécessaire de spécifier dans quel shard ils se trouvent. Quelle est la différence entre Bounceable et Non-bounceable ?

Cela concerne la façon dont contrats intelligents fonctionne, mais continuons à regarder plus loin.

Contrat de portefeuille

Vous trouverez ci-dessous un extrait du code source d’un contrat de portefeuille d’utilisateur. Il montre que lorsqu’il reçoit un message de l’utilisateur, il lit quatre paramètres : stored_seqno, stored_subwallet, public_key et plugins :

wallet-v4-code.fc



() recv_external(slice in_msg) impure {

var signature = in_msg~load_bits(512);

var cs = in_msg;

var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));

throw_if(36, valid_until <= now());

var ds = get_data().begin_parse();

var (stored_seqno, stored_subwallet, public_key, plugins) = (ds~load_uint(32), ds~load_uint(32), ds~load_uint(256), ds~load_dict()); ;;##The Initial Data

ds.end_parse();

throw_unless(33, msg_seqno == stored_seqno);

throw_unless(34, subwallet_id == stored_subwallet);

throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));

//...

}

En effet, lorsque ce contrat de portefeuille d’utilisateur est déployé, il requiert certains paramètres initiaux, dont un public_key de 256 bits. Cela permet de s’assurer que chaque utilisateur a une adresse de contrat unique, même s’il utilise le même code de contrat.

Chaque transaction initiée par l’utilisateur doit être signée avec in_msg, puis vérifiée par le contrat de portefeuille (check_signature), après quoi le contrat effectuera des opérations sur la blockchain. On peut en déduire que la clé publique d’un utilisateur peut correspondre à de nombreuses adresses de portefeuilles.

Le déploiement de différents contrats de portefeuilles ou l’utilisation de données d’initialisation différentes se traduira par des adresses de contrats entièrement différentes.

Jeton Jetton

Un jeton représente un actif sur la blockchain, ce qui en fait un élément fondamental que nous devons comprendre. Jetton est la forme standard des jetons TON et se compose de deux contrats : Jetton-minter et Jetton-wallet.

Lorsqu’un jeton est émis, un contrat Jetton-minter est créé. Cette initialisation du contrat enregistre des informations telles que la quantité totale de jetons, l’administrateur, le code du portefeuille et d’autres détails.

Lorsque les jetons sont distribués aux utilisateurs, le contrat Minter déploie un contrat de portefeuille pour chaque utilisateur. Lors de l’initialisation du contrat, il enregistre le solde de l’utilisateur, sa propriété, l’adresse du contrat Minter, le code du portefeuille de l’utilisateur et d’autres informations pertinentes. Chaque utilisateur dispose d’un contrat déployé individuellement.

Il est important de noter que le contrat créé ici est un contrat de portefeuille pour la gestion de jetons Jetton spécifiques, qui est différent du contrat de portefeuille du compte de l’utilisateur. Le owner_address enregistré ici est l’adresse du portefeuille du compte de l’utilisateur.

Lorsque l’utilisateur Alice transfère des jetons à l’utilisateur Bob, la relation d’invocation est la suivante :

Alice signe la transaction par le biais d’une application hors chaîne et envoie une commande opérationnelle via son contrat de portefeuille. Ces commandes invitent ensuite son portefeuille de jetons à exécuter le transfert. Lorsque le portefeuille de jetons de Bob reçoit les jetons, il en informe le contrat de portefeuille de Bob (l’adresse du propriétaire du portefeuille Jetton de Bob).

S’il reste du gaz pendant la transaction, il est renvoyé à l’adresse appropriée, généralement le contrat de compte d’Alice.

Vous trouverez ci-dessous un exemple de transfert de jeton Jetton analysé par le navigateur Tonviewer :

Alors qu’un transfert ERC20 ne nécessite qu’une seule invocation de contrat, un transfert de jeton Jetton nécessite au moins quatre invocations de contrat. Cette méthode est conçue pour permettre la concurrence sur la chaîne, améliorant ainsi l’efficacité des transactions.

Transactions

Lorsqu’un certain événement se produit sur un compte TON, il déclenche une transaction. L’événement le plus courant est la « réception d’un message ». Une transaction comprend les éléments suivants :

• Le message entrant qui déclenche initialement le contrat (avec des méthodes de déclenchement spéciales disponibles).
• Actions du contrat résultant du message entrant, telles que la mise à jour du stockage du contrat (facultatif).
• Messages sortants envoyés aux autres participants (facultatif).

Il y a plusieurs caractéristiques essentielles à connaître en ce qui concerne les transactions :

1. Asynchrone : Les transactions TON ne sont pas effectuées en un seul appel ; elles peuvent nécessiter le passage de messages à plusieurs contrats intelligents différents pour exécuter une série d’appels. En raison des différences d’acheminement dans les chaînes partagées, TON ne peut pas garantir l’ordre de livraison des messages entre plusieurs contrats intelligents.
2. Honoraires : La nature asynchrone des transactions rend difficile l’estimation des frais consommés. C’est pourquoi les portefeuilles envoient souvent un petit jeton supplémentaire à titre de frais lors de l’initiation d’une transaction. Si le contrat appelé dispose d’un bon mécanisme de gestion des frais, les frais restants seront reversés au portefeuille de l’utilisateur. Les utilisateurs peuvent remarquer que les jetons de leur portefeuille diminuent soudainement, puis augmentent à nouveau après quelques minutes, ce qui est dû à ce mécanisme.
3. Rebondir : Le rebond est un mécanisme de gestion des erreurs dans les contrats. Si le contrat appelé n’existe pas ou s’il émet une erreur, et que la transaction est définie comme pouvant être rebondie, un message de rebond sera renvoyé au contrat appelant. Par exemple, si un utilisateur initie un transfert et qu’une erreur survient au cours du processus, un message de rebond est nécessaire pour que le contrat du portefeuille de l’utilisateur puisse rétablir son solde. Presque tous les messages internes envoyés entre les contrats intelligents doivent pouvoir être renvoyés, ce qui signifie que le bit « bounce » doit être activé.

Sécurité des actifs

TON possède de nombreuses fonctionnalités qui peuvent entraîner des problèmes de sécurité, et les utilisateurs doivent donc être conscients des pièges les plus courants.

Attaque contre la retenue d’honoraires

Comme nous l’avons mentionné, les portefeuilles ont souvent besoin d’envoyer un petit supplément pour éviter l’échec de la transaction, ce qui offre une opportunité aux attaquants. Si vous utilisez un portefeuille TON, vous avez peut-être rencontré une situation où votre portefeuille reçoit fréquemment divers NFT ou jetons.

Au départ, ces jetons semblent être des déchets, mais en vérifiant les détails de la transaction, vous vous apercevez qu’ils peuvent être vendus pour une somme d’argent non négligeable. Cependant, lorsque vous tentez d’initier une transaction, vous remarquez que les frais exigés sont extrêmement élevés (1 TON). À ce stade, vous devriez être prudent, car il pourrait s’agir d’une escroquerie sur les frais.

Les attaquants créent un contrat de jeton soigneusement élaboré qui amène le portefeuille à estimer des frais de transfert excessivement élevés, alors qu’en réalité, seuls les frais sont retenus et aucun message de transfert n’est envoyé.

Hameçonnage par le premier et le dernier chiffre

L’hameçonnage par le premier et le dernier chiffre n’est pas propre à TON ; cette attaque d’hameçonnage existe sur de nombreuses blockchains majeures. Les attaquants génèrent un faux compte pour chaque adresse d’utilisateur sur le réseau avec les mêmes premier et dernier chiffres.

Lorsqu’un utilisateur initie un transfert, l’attaquant envoie également un petit transfert, à la suite de la transaction de l’utilisateur, afin de laisser un enregistrement dans l’historique des transactions de l’utilisateur. Lorsque l’utilisateur destinataire souhaite renvoyer des jetons, il peut copier l’adresse de son historique de transactions, qui pourrait être l’adresse de l’attaquant, ce qui entraînerait un transfert à la mauvaise adresse. L’attaquant a exploité avec précision le comportement de l’utilisateur.

Commentaire Phishing

Lors du transfert de jetons sur TON, les utilisateurs peuvent ajouter un commentaire pour annoter la transaction. Cette fonction est souvent utilisée pour effectuer des dépôts sur les bourses, qui exigent généralement que les utilisateurs incluent leur identifiant dans le commentaire du dépôt. Cependant, cette fonctionnalité est fréquemment exploitée par des acteurs malveillants, qui écrivent des informations frauduleuses dans les commentaires pour voler les actifs des utilisateurs. En voici un exemple :

Les utilisateurs doivent être particulièrement prudents en ce qui concerne le NFT « Numéro de télégramme anonyme ». Si un utilisateur active son compte Telegram avec un numéro Telegram anonyme mais n’active pas la vérification en deux étapes, et que ce NFT est hameçonné, le pirate peut directement se connecter au compte Telegram cible et procéder au vol d’actifs et aux activités frauduleuses qui s’ensuivent.

Vulnérabilités des contrats intelligents

Les failles de sécurité dans les contrats intelligents peuvent entraîner la perte des fonds stockés dans le contrat. Les utilisateurs devraient choisir des projets qui ont fait l’objet d’un audit approfondi. Les contrats intelligents de TON sont principalement programmés à l’aide du langage FunC, bien que certains utilisent le langage plus avancé Tact ou le langage de niveau inférieur Fift.

Tous ces langages sont très originaux. Les nouveaux langages de programmation entraînent de nouveaux risques pour la sécurité, en particulier pour les développeurs, qui doivent adopter des habitudes de codage sûres, maîtriser les meilleures pratiques en matière de sécurité et se soumettre à des audits de sécurité rigoureux avant de déployer le logiciel dans l’environnement de production. Pour des raisons d’espace, cet article n’abordera pas en détail la sécurité des contrats.

Attaque par faux dépôt

Les utilisateurs de portefeuilles ou de bourses d’échange doivent être conscients des attaques par faux dépôts, qui se présentent généralement sous deux formes :

1. Faux jetons : Un attaquant émet un jeton dont les métadonnées sont identiques à celles du jeton cible. Si le programme de dépôt automatisé ne vérifie pas si le jeton provient du bon contrat de frappe, il peut entraîner des dépôts incorrects.
2. Rebondir : Le processus de transfert de TON nécessite une relation d’invocation entre les contrats de portefeuille de deux utilisateurs. Si le contrat de portefeuille du destinataire n’existe pas et que la transaction est définie comme pouvant être annulée, le message sera annulé et les fonds originaux, moins les frais, seront renvoyés à l’expéditeur. Les personnes intéressées par les détails peuvent se référer à notre précédent article sur les faux dépôts.

Conclusion

Cet article a présenté certains principes techniques fondamentaux des TON du point de vue de la création des clés et des portefeuilles, des formes de jetons et des caractéristiques des transactions. Il a également exploré les problèmes de sécurité potentiels liés à l’utilisation des TON, en espérant qu’il vous inspirera dans votre démarche d’apprentissage.