Auteur original : Johan

arrière-plan

TON (The Open Network) est une plateforme blockchain décentralisée conçue et développée à l'origine par l'équipe Telegram. L'objectif de TON est de fournir une plate-forme blockchain hautes performances et évolutive pour prendre en charge les applications décentralisées (DApps) et les contrats intelligents à grande échelle.

TON est si spécial, il est facile à utiliser, il est profondément intégré à Telegram, ce qui permet aux gens ordinaires d'utiliser facilement des jetons, il est également complexe, il a une architecture complètement différente des autres blockchains et il utilise du FunC non traditionnel ; Langage de contrat intelligent. Aujourd'hui, nous discuterons des caractéristiques des problèmes de sécurité du TON et des actifs des utilisateurs du point de vue des comptes, des jetons et des transactions.

Caractéristiques de TON

Génération de compte

L'adresse du compte TON est générée différemment de la plupart des blockchains. Il s'agit d'une adresse de contrat intelligent. Tout d’abord, commencez par une clé privée. TON utilise principalement l’algorithme Ed 25519 pour générer une clé publique. Le processus de génération est le suivant :

Il existe deux formes de clés publiques. L'une est la clé publique originale calculée à partir de la clé privée, qui ressemble à :

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

L'autre est la clé publique « embellie », qui contient des informations et des chiffres de contrôle de la clé publique, sous la forme : Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2.

Il serait trop naïf de penser que vous pouvez obtenir l'adresse du compte comme Ethereum en obtenant la clé publique. Il ne suffit pas de disposer simplement de la clé publique de l'utilisateur pour calculer l'adresse du compte de l'utilisateur. Nous venons de dire que l'adresse du compte de l'utilisateur est une adresse de contrat intelligent, mais nous n'avons même pas de compte. Comment pouvons-nous déployer un contrat intelligent ? 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 la figure ci-dessous :

L'adresse de l'utilisateur se présente également sous plusieurs formes. La première est la forme originale, qui ressemble à :

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

et un formulaire convivial, comme :

Réseau principal :

Rebondissant :

EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX

Non rebondissant :

UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Testnet :

Rebondissant :

kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd

Non rebondissant :

0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Si vous observez attentivement ces adresses, vous pouvez voir qu'elles ne diffèrent que par le premier et le dernier caractère, et que le « account_id » au milieu est le même. Cependant, nous ne pouvons toujours pas voir la relation entre la clé publique et l'adresse du compte. En fait, le mystère réside dans le fait que les « données initiales » contiennent au début la clé publique d'un utilisateur, grâce à laquelle l'utilisateur contrôle la propriété du contrat du portefeuille. `workchainId` est facile à comprendre. TON n'est pas simplement une chaîne unique. Il est composé de nombreux fragments. Chaque fragment fait partie de l'ensemble du réseau et gère un ensemble spécifique de comptes et de transactions. Afin de localiser et gérer les smart contracts, il est nécessaire d’indiquer clairement dans quel shard ils se trouvent. Quelle est la différence entre « rebondissant » et « non rebondissant » ? Ceci est lié au mécanisme de fonctionnement des contrats intelligents, continuons à regarder ci-dessous.

contrat de portefeuille

Ce qui suit est le code source d'un contrat de portefeuille utilisateur. Vous pouvez voir qu'il lit 4 paramètres (stored_seqno, store_subwallet, public_key, plugins) lors de la réception du message de l'utilisateur :

portefeuille-v4-code.fc

() recv_external(tranche in_msg) impur {

var signature = in_msg~load_bits( 512);

var cs = in_msg;

var (sous-portefeuille_id, valid_until, msg_seqno) = (cs~load_uint( 32), cs~load_uint( 32), cs~load_uint( 32));

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

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()); ;;#Lesdonnées initiales

ds.end_parse();

throw_unless( 33, msg_seqno == storage_seqno);

throw_unless( 34, subwallet_id == sous-portefeuille_stocké);

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

//...

}

C'est vrai, lors du déploiement du contrat de portefeuille de cet utilisateur, vous devez transmettre certains paramètres initiaux, qui incluent une information de clé publique de 256 bits. Cela garantit que chaque utilisateur dispose d'un contrat indépendant lorsqu'il utilise la même adresse de contrat. Toutes les transactions initiées par l'utilisateur doivent signer « in_msg », puis vérifier la signature (check_signature) via leur propre contrat de portefeuille, puis le contrat appellera toutes les opérations de la chaîne. De là, nous pouvons également déduire que la clé publique d'un utilisateur peut en réalité correspondre à d'innombrables adresses de portefeuille. Il suffit de déployer des portefeuilles avec des codes sources différents ou des données d'initialisation différentes pour obtenir des adresses de contrat complètement différentes.

Jeton Jetton

Le jeton est la représentation des actifs sur la chaîne, c'est donc un élément de base que nous devons comprendre. Jetton est la forme standard du jeton TON. Jetton se compose de deux contrats, Jetton-minter et Jetton-wallet :

Lorsqu'un jeton est émis, un contrat Jetton-minter sera créé. L'initialisation du contrat enregistre le montant total des jetons, des administrateurs, des codes de portefeuille et d'autres informations.

Lorsque les jetons sont distribués aux utilisateurs, le contrat Minter déploiera un contrat de portefeuille pour l'utilisateur et enregistrera le solde de l'utilisateur, la propriété, l'adresse du contrat Minter du jeton, le code du portefeuille utilisateur et d'autres informations lors de l'initialisation du contrat. Chaque utilisateur déploiera un contrat. indépendamment. Notez que le contrat créé ici est un contrat de portefeuille utilisé pour gérer un jeton Jetton spécifique, qui est différent du contrat de portefeuille du compte de l'utilisateur. L'adresse du propriétaire enregistre ici l'adresse du portefeuille du compte de l'utilisateur.

Lorsque l'utilisateur Alice transfère de l'argent à l'utilisateur Bob, la relation d'appel est la suivante :

Alice signe l'application hors chaîne et émet des instructions de fonctionnement en appelant son contrat de portefeuille. Ces instructions appellent en outre son portefeuille de jetons pour effectuer le transfert. Lorsque le portefeuille de jetons de Bob recevra le jeton, il en informera le contrat du portefeuille de Bob (c'est-à-dire l'adresse du propriétaire du portefeuille de Bob Jetton). S'il reste du Gaz pendant la transaction, il sera renvoyé à l'adresse de réponse, généralement le contrat de compte d'Alice.

Il s'agit d'un transfert de jeton Jetton analysé par le navigateur Tonviewer :

Un transfert ERC 20 ne doit appeler qu'au moins un contrat, tandis qu'un transfert de jetons Jetton doit appeler au moins quatre contrats. Ceci est fait pour permettre aux transferts d'être effectués simultanément sur la chaîne et améliorer l'efficacité des transactions.

commerce

Lorsque quelque chose arrive à un compte dans TON, cela déclenche une transaction. L'événement le plus courant est la « réception d'un message ». La transaction comprend les éléments suivants :

  • Le message entrant qui déclenche initialement le contrat (il existe une méthode de déclenchement spéciale)

  • Actions du contrat provoquées par des messages entrants, telles que la mise à jour du stockage du contrat (facultatif)

  • Messages sortants vers les autres participants (facultatif)

Il y a plusieurs caractéristiques auxquelles vous devez prêter attention lors du trading :

1. Asynchrone : les transactions TON ne sont pas effectuées en un seul appel. Il peut être nécessaire de transmettre des messages à plusieurs contrats intelligents différents pour exécuter une série d'appels. En raison du routage différent dans les chaînes de fragments, TON ne peut pas garantir l'ordre de livraison des messages entre plusieurs contrats intelligents.

2. Frais de traitement : La nature asynchrone pose également un problème, c'est-à-dire que les frais de traitement consommés sont difficiles à estimer. Par conséquent, lors du lancement d’une transaction, le portefeuille envoie généralement des jetons supplémentaires à titre de frais de traitement. Si le contrat appelé dispose d'un bon mécanisme de frais de traitement, les frais de traitement restants seront finalement reversés dans le portefeuille de l'utilisateur. Les utilisateurs peuvent constater que leurs jetons de portefeuille deviennent soudainement de moins en moins nombreux après quelques minutes, pour cette raison.

3. Rebond : le rebond est un mécanisme de gestion des erreurs du contrat. Lorsque le contrat appelant n'existe pas ou qu'une erreur est générée, si la transaction est définie sur rebondable, un message rebondi sera renvoyé au contrat appelant. Par exemple, si un utilisateur initie un transfert et qu'une erreur se produit dans le processus d'appel, un message de rebond est nécessaire pour que le contrat de portefeuille de l'utilisateur puisse rétablir son solde. Presque tous les messages internes envoyés entre contrats intelligents doivent pouvoir être rebondis, c'est-à-dire que leur bit « rebond » doit être défini.

Sécurité des actifs

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

Attaque d'interception de frais

Comme mentionné ci-dessus, les portefeuilles doivent souvent envoyer davantage de frais de traitement pour éviter les échecs d'exécution des transactions, ce qui permet aux attaquants de trouver des opportunités de faire le mal. Si vous êtes un utilisateur du portefeuille TON, vous avez peut-être rencontré cette situation. Vous recevez toujours divers NFT ou jetons dans votre portefeuille. Vous pensiez qu'il s'agissait simplement de largages de jetons indésirables, mais lorsque vous avez vérifié les informations de transaction, vous avez constaté que vous ne pouviez pas le faire. les vendre. Moins d'argent? Cependant, lorsque vous lancez une transaction, vous constatez que les frais de traitement requis sont extrêmement élevés (1 TON). À ce stade, vous devez faire attention. Il peut s'agir d'une fraude aux frais de traitement.

L'attaquant a utilisé un contrat de jeton soigneusement construit pour rendre les frais de transfert estimés du portefeuille extrêmement élevés, mais lors de l'exécution réelle, il a seulement retenu les frais et n'a pas envoyé de message de transfert.

Pêche au premier et au dernier numéro

Le phishing par numéro de tête et de queue n'est pas propre à TON. Ce type d'attaque de phishing existe dans toutes les grandes chaînes publiques. L'attaquant générera un compte à haute imitation avec les mêmes premier et dernier numéros pour chaque adresse d'utilisateur sur l'ensemble du réseau. Lorsque l'utilisateur envoie un transfert, l'attaquant utilisera également le compte à haute imitation pour envoyer un petit transfert dans le compte de l'utilisateur. reçu. Laissez une trace dans le dossier de paiement. Lorsque l'utilisateur destinataire souhaite retransférer un jeton, il peut copier l'adresse de l'enregistrement historique. À ce stade, il est probable qu'elle soit copiée à l'adresse de l'attaquant, ce qui entraînera le transfert vers une mauvaise adresse. le comportement de l'utilisateur.

commentaire sur la pêche

TON peut ajouter un commentaire lors du transfert d'argent pour noter les informations de transaction. Cette fonction est fréquemment utilisée lors du rechargement sur les échanges. Les échanges exigent généralement que les utilisateurs notent l'identifiant de l'utilisateur lors du rechargement. Cependant, cette fonction est souvent exploitée de manière malveillante, les attaquants escroquant les utilisateurs de leurs actifs en écrivant des informations frauduleuses dans des notes. Comme le montre l'image :

Les utilisateurs doivent accorder une attention particulière au numéro de télégramme anonyme NFT. Si l'utilisateur utilise le numéro de télégramme anonyme pour ouvrir un compte TG mais n'ouvre pas la vérification en deux étapes, une fois le NFT hameçonné, les pirates peuvent se connecter directement au compte TG cible. et procéder à des vols d’actifs ultérieurs et à des comportements trompeurs.

Vulnérabilité des contrats intelligents

Les vulnérabilités de sécurité dans les contrats intelligents causeront des dommages aux fonds des utilisateurs placés dans des contrats intelligents. Les utilisateurs doivent choisir des projets bien audités lors du choix des projets. Les contrats intelligents de TON sont principalement programmés à l'aide du langage FunC, mais utilisent également le plus avancé Tact, ou le Fift de niveau inférieur, qui sont tous des langages très originaux. Les nouveaux langages de programmation entraîneront de nouveaux risques de sécurité. En particulier pour les développeurs, ils doivent avoir de bonnes habitudes de programmation sécurisée, maîtriser les meilleures pratiques de sécurité et se soumettre à des audits de sécurité stricts avant de se déployer dans l'environnement de production. En raison des limitations d'espace, cet article. pas discuter de la sécurité du contrat pour l’instant.

Fausse attaque de recharge

Les utilisateurs de portefeuilles ou d’échanges doivent faire attention aux fausses attaques de recharge. Il existe généralement deux types de fausses attaques de recharge :

  • Pour les pièces contrefaites, l'attaquant émet un jeton avec les mêmes métadonnées que le jeton cible. Si le programme de saisie automatisée ne vérifie pas s'il s'agit du bon contrat de monnayeur, cela entraînera une saisie incorrecte.

  • Bounce, le processus de transfert de TON nécessite une relation d'appel entre les contrats de portefeuille des deux utilisateurs. Si le contrat de portefeuille du destinataire n'existe pas et que la transaction est définie sur Bounceable, le message sera renvoyé et les fonds d'origine seront déduits du. frais de traitement. Retour à l'expéditeur. Les amis intéressés par les détails peuvent consulter l’article sur la fausse recharge que nous avons précédemment divulgué.

Résumer

Cet article présente quelques principes techniques de base de TON du point de vue de la création de clés publiques et privées de TON, du contrat de portefeuille, du formulaire de jeton, des caractéristiques de la transaction, etc., et aborde également les problèmes de sécurité possibles lors de l'utilisation de TON. J'espère que cela pourra vous aider. tout le monde apprend. Apportez de l’inspiration.

Liens de référence :

https://docs.ton.org/

https://github.com/ton-blockchain/wallet-contract