Dans le domaine en constante évolution de la technologie blockchain, TON (The Open Network) attire de plus en plus l'attention des développeurs en tant que plateforme blockchain efficace et flexible. L'architecture unique et les fonctionnalités de TON offrent des outils puissants et de riches possibilités pour le développement d'applications décentralisées.

Cependant, avec l'augmentation de la fonctionnalité et de la complexité, la sécurité des contrats intelligents est devenue plus critique. FunC, le langage de programmation des contrats intelligents sur TON, est connu pour sa flexibilité et son efficacité, mais il présente également de nombreux risques et défis potentiels. Écrire des contrats intelligents sécurisés et fiables exige que les développeurs aient une compréhension approfondie des caractéristiques de FunC et des risques potentiels associés.

Cet article fournira une analyse détaillée des fonctionnalités liées aux contrats intelligents sur la blockchain TON, ainsi que des vulnérabilités dans les contrats intelligents TON qui sont souvent négligées.

Analyse des fonctionnalités asynchrones de TON et du mécanisme de compte

Appels asynchrones dans les contrats intelligents

Network Sharding et Communication Asynchrone

La blockchain TON est conçue avec trois types de chaînes : Masterchain, Workingchains et Shardchains.

Le Masterchain est le cœur de l'ensemble du réseau, responsable du stockage des métadonnées et du mécanisme de consensus de l'ensemble du réseau. Il enregistre les états de tous les Workingchains et Shardchains et garantit la cohérence et la sécurité du réseau. Les Workingchains sont des blockchains indépendantes, avec un maximum de 2^32 chaînes, responsables de la gestion de types spécifiques de transactions et de contrats intelligents. Chaque Workingchain peut avoir ses propres règles et caractéristiques pour répondre à différents besoins d'application. Les Shardchains sont des sous-chaînes de Workingchains, utilisées pour diviser davantage la charge de travail des Workingchains, améliorant la capacité de traitement et la scalabilité. Chaque Workingchain peut être divisé en jusqu'à 2^60 Shardchains, les Shardchains gérant certaines transactions de manière indépendante pour réaliser un traitement parallèle efficace.

En théorie, chaque compte peut occuper exclusivement un Shardchain, chaque compte maintenant indépendamment son solde COIN/TOKEN. Les transactions entre comptes peuvent être entièrement parallélisées. Les comptes communiquent via des messages asynchrones, et le chemin pour les messages voyageant entre les Shardchains est log_16(N) - 1, où N est le nombre de Shardchains.

Source de l'image: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574 du monde web3Dans Ton, les interactions se font par l’envoi et la réception de messages. Ces messages peuvent être internes (généralement envoyés par des contrats intelligents interagissant les uns avec les autres) ou externes (envoyés par des sources externes). Le processus de transmission des messages ne nécessite pas de réponses immédiates de la part du contrat cible, ce qui permet à l’expéditeur de continuer à exécuter la logique restante. Ce mécanisme de messagerie asynchrone offre une plus grande flexibilité et une plus grande évolutivité par rapport aux appels synchrones d’Ethereum, réduisant les goulots d’étranglement des performances causés par l’attente des réponses, tout en introduisant des défis dans la gestion de la concurrence et des conditions de concurrence.

Format et structure du message

Dans TON, les messages incluent généralement des informations telles que l'expéditeur, le destinataire, le montant et le corps du message. Le corps du message peut comporter des appels de fonction, des transferts de données ou d'autres contenus personnalisés. Le format des messages de TON est conçu pour être flexible et extensible, permettant une communication efficace de divers types d'informations entre différents contrats.

File d'attente de messages et traitement des statuts

Chaque contrat maintient une file d'attente de messages pour stocker les messages qui n'ont pas encore été traités. Pendant l'exécution, le contrat traite les messages un par un à partir de la file d'attente. Étant donné que le traitement des messages est asynchrone, l'état du contrat ne sera pas mis à jour immédiatement après la réception d'un message.

Avantages de la messagerie asynchrone

• Mécanisme de sharding efficace : Le mécanisme asynchrone de TON est hautement compatible avec sa conception de sharding. Chaque shard traite indépendamment les messages de contrat et les changements d'état, évitant les retards causés par la synchronisation inter-shard. Cette conception améliore le débit et la scalabilité globale du réseau.

•Consommation de ressources réduite : Les messages asynchrones ne nécessitent pas de réponses immédiates, permettant aux contrats TON de s'exécuter sur plusieurs blocs et évitant une consommation excessive de ressources au sein d'un seul bloc. Cela permet à TON de prendre en charge des contrats intelligents plus complexes et plus gourmands en ressources.

• Tolérance aux pannes et fiabilité : Le mécanisme de passage de messages asynchrones augmente la tolérance aux pannes du système. Par exemple, si un contrat ne peut pas répondre à un message en temps opportun en raison de limitations de ressources ou d'autres raisons, l'expéditeur peut continuer à traiter d'autres logiques, évitant ainsi que le système ne se bloque en raison de retards dans un seul contrat.

Défis de la conception de contrats asynchrones

• Problèmes de cohérence d'état: En raison de la nature asynchrone de la transmission de messages, les contrats peuvent recevoir différents messages à différents moments, ce qui oblige les développeurs à accorder une attention particulière à la cohérence de l'état. Lors de la conception de contrats, il est crucial de considérer comment différents ordres de messages peuvent affecter les modifications d'état et de garantir que le système maintient la cohérence dans toutes les conditions.

•Conditions de course et protection: Le traitement asynchrone des messages introduit des problèmes potentiels de conditions de course, où plusieurs messages peuvent simultanément tenter de modifier l'état du contrat. Les développeurs doivent mettre en place des mécanismes de verrouillage appropriés ou utiliser des opérations transactionnelles pour éviter les conflits d'état.

• Considérations de sécurité: Les contrats asynchrones sont susceptibles de risques tels que les attaques de type man-in-the-middle ou les attaques de relecture lors de la communication entre contrats croisés. Par conséquent, lors de la conception de contrats asynchrones, il est essentiel de prendre en compte ces risques potentiels de sécurité et de prendre des mesures préventives, telles que l'utilisation de tampons horodateurs, de nombres aléatoires ou d'approches multi-signatures.

Modèle de registre

TON (The Open Network) utilise un modèle unique d'abstraction de compte et de registre dans la conception de son infrastructure blockchain. La flexibilité de ce modèle se reflète dans la manière dont il gère les états de compte, le passage de messages et l'exécution des contrats.

Abstraction de compte

Le modèle de compte de TON utilise une abstraction basée sur les contrats, où chaque compte peut être considéré comme un contrat. Cela est quelque peu similaire au modèle d'abstraction de compte d'Ethereum, mais est plus flexible et général. Dans TON, les comptes ne sont pas simplement des conteneurs d'actifs ; ils incluent également du code de contrat et des données d'état. Chaque compte comprend son code, ses données et sa logique de gestion des messages.

Structure du compte : Chaque compte TON a une adresse unique, qui est générée à partir d'une combinaison de la valeur de hachage du code du compte, des données initiales au déploiement et d'autres paramètres. Cela signifie que le même code et les données initiales déployés dans des environnements différents (par exemple, des blockchains ou des shards différents) peuvent produire des adresses différentes.

Flexibilité : Comme chaque compte peut exécuter son propre code de contrat, les comptes TON peuvent mettre en œuvre une logique très complexe. Les comptes ne sont pas seulement des détenteurs de solde simples, mais peuvent gérer des transitions d'état complexes, une communication de messages entre comptes et même une automatisation basée sur des conditions spécifiques. Cela rend le modèle de compte de TON plus évolutif et flexible par rapport aux modèles de compte de chaîne de blocs traditionnels.

Structure du grand livre

La structure du grand livre de TON est conçue pour gérer efficacement des transactions concurrentes à grande échelle, en prenant en charge le passage de messages asynchrones et les opérations multi-shard. L'état de chaque compte est stocké dans une structure d'arbre de Merkle, offrant des capacités efficaces de validation de l'état.

Stockage d'état

Les informations sur l'état du compte sont stockées dans un stockage persistant et organisées via un arbre de Merkle pour garantir l'intégrité et la sécurité. Cette conception prend également en charge des requêtes et vérifications efficaces des états, notamment dans le cadre de transactions entre shards.

Un compte ou l'état du contrat intelligent comprend généralement ce qui suit:

1. Solde de la monnaie de base 2. Solde des autres devises 3. Code du contrat intelligent (ou son hachage) 4. Données persistantes du contrat intelligent (ou son hachage Merkle) 5. Statistiques sur le nombre d'unités de stockage persistant et l'utilisation brute des octets 6. Horodatage récent des paiements vers le stockage persistant du contrat intelligent (essentiellement le numéro de bloc de la chaîne principale) 7. Clé publique nécessaire pour transférer des devises et envoyer des messages à partir de ce compte (facultatif; par défaut, cela équivaut à l'identifiant du compte lui-même). Dans certains cas, des codes de vérification de signature plus complexes peuvent être trouvés ici, similaires aux sorties de transactions Bitcoin; dans ce cas, l'identifiant du compte sera le hachage de ce code.

Toutes les informations ne sont pas requises pour chaque compte. Par exemple, le code du smart contract est uniquement pertinent pour les smart contracts, pas pour les comptes « simples ». De plus, bien que chaque compte doive avoir un solde non nul de la monnaie de base (par exemple, le Gram pour la chaîne de travail de base et les chaînes de fragments), les soldes des autres devises peuvent être nuls. Pour éviter de conserver des données inutilisées, un type de produit somme est défini lors de la création d'une chaîne de travail, en utilisant différents octets de marquage pour distinguer diverses « fonctions de constructeur ». En fin de compte, l'état du compte est enregistré sous la forme d'une collection d'unités dans le stockage persistant de TVM.

Passage et traitement de messages

La structure de registre de TON comprend une prise en charge intégrée de la transmission de messages asynchrones. Chaque compte peut traiter de manière indépendante les messages reçus et mettre à jour son état. Ce mécanisme de messagerie asynchrone permet des interactions complexes entre les comptes sans affecter le fonctionnement normal des autres comptes en raison de retards dans une seule opération.

Modèle de gaz

TON (The Open Network) optimise significativement l'efficacité d'exécution des smart contracts grâce à son modèle unique de frais de gaz. Ce modèle de frais de gaz est utilisé pour mesurer et limiter les ressources consommées lors de l'exécution des smart contracts. Comparé aux blockchains traditionnelles comme Ethereum, le modèle de TON est plus complexe et efficace, permettant une gestion plus précise de la consommation des ressources lors de l'exécution du contrat.

Le modèle de gaz de TON peut mesurer de manière précise les ressources de calcul, les opérations de stockage et les coûts de transmission de messages consommés lors de l'exécution des contrats intelligents. En fournissant des mesures détaillées pour des ressources telles que le calcul, le stockage et les messages, le modèle de gaz de TON empêche les opérations d'une complexité excessive de consommer trop de ressources. En limitant la consommation de gaz, TON garantit que chaque nœud du réseau peut allouer équitablement les ressources de calcul, évitant une surutilisation des ressources du réseau par un seul contrat ou une seule opération.

TON prend en charge le traitement parallèle des smart contracts, permettant à plusieurs contrats de s'exécuter simultanément sur différents shards sans se bloquer mutuellement. Dans cette conception, le modèle de gaz est étroitement intégré aux mécanismes d'exécution parallèle et de sharding. En traitant les contrats en parallèle sur plusieurs shards, TON peut répartir le calcul et le paiement du gaz sur différents nœuds et chaînes, évitant la congestion du réseau tout en maximisant l'utilisation des ressources.

Le modèle de gaz de TON comprend un mécanisme d'ajustement dynamique qui permet d'ajuster les frais de gaz en fonction de la charge en temps réel du réseau. Cela signifie que pendant les périodes de charge réseau plus faible, les utilisateurs peuvent exécuter des contrats à des frais de gaz moins élevés, ce qui encourage les opérations pendant les heures creuses et équilibre l'utilisation des ressources du réseau. Ce mécanisme améliore non seulement l'expérience utilisateur, mais contrôle également l'utilisation maximale des ressources grâce à une approche axée sur le marché.

Les contrats intelligents TON sont faciles à ignorer les failles

En notre article précédent d'analyse de sécuritéSur TON, nous avons détaillé les vulnérabilités de sécurité courantes au sein de l'écosystème TON. Pour plus de références, veuillez consulter le tableau ci-dessous:

Cet article portera sur les vulnérabilités des contrats TON qui sont souvent négligées, comme résumé par notre équipe :

(1) Optimisation de la lisibilité du code

Dans les contrats intelligents TON, les chiffres sont souvent utilisés pour stocker des données relatives à l’envoi de messages. Par exemple, dans le code ci-dessous, plusieurs instances de nombres sont utilisées pour représenter les identifiants et les longueurs de stockage de données correspondants, ce qui réduit considérablement la lisibilité et la maintenabilité du code. D’autres développeurs peuvent avoir du mal à comprendre la signification et l’objectif de ces nombres lors de la lecture du code. Pour améliorer la lisibilité et la maintenabilité, il est recommandé de définir les valeurs numériques clés sous forme de constantes nommées. Par exemple, définissez 0x18commeNON_BOUNCEABLE.

1. check_std_addr(address);was msg = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(address) store_coins(amount) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);

De plus, pour le message d'erreur dans les conditions de jugement du contrat, il est également recommandé de définir des variables correspondantes pour remplacer les codes d'erreur.

(2) Utilisation end_parse()pour garantir l'intégrité des données

Dans les contrats TON, l'analyse des données suit un ordre fixe, chargeant les types de données spécifiés étape par étape à partir des données brutes. Cette méthode d'analyse garantit la cohérence et l'exactitude des données, comme illustré ci-dessous:

Notez que end_parse() permet de vérifier si une tranche de données est vide. Si la tranche n’est pas vide, la fonction lève une exception. Cela permet de s’assurer que le format et le contenu des données sont conformes aux attentes. Si l’option end_parse() détecte les données restantes dans la tranche, elle peut indiquer que l’analyse des données ne s’est pas déroulée comme prévu ou qu’il y a un problème avec le format des données. Par conséquent, en appelant end_parse(), vous pouvez vérifier s'il y a des omissions ou des anomalies pendant le processus d'analyse.

(3) Exceptions causées par un stockage de données et des types incompatibles

Cela concerne principalement la correspondance deint et uinttypes de stockage. Par exemple, dans le code suivant, le store_int()La fonction est utilisée pour stocker un intvaleur de-42, mais load_uint()est utilisé pour charger cette valeur, ce qui peut entraîner une exception.

(4) Utilisation appropriée deinline_refeten ligneModificateurs

Tout d'abord, il est important de distinguer entre le Inline et inline_ref Modificateurs:

inline: Fonctions avec le inlineLes modificateurs ont leur code inséré directement sur le site d'appel à chaque fois qu'ils sont appelés. Cela signifie que le code réel de la fonction est copié à l'emplacement d'appel plutôt que d'être exécuté par un saut de fonction, ce qui réduit les frais généraux des appels de fonction mais peut entraîner une duplication de code.

inline_ref: Fonctionne avec l’attribut inline_refLe modificateur stocke leur code dans une cellule distincte. À chaque fois que la fonction est appelée, TVM exécute le code stocké dans la cellule via leCALLREFcommande, évitant la duplication de code et améliorant l'efficacité pour des fonctions plus complexes ou appelées plusieurs fois.

En résumé, utilisez Inline pour des fonctions simples afin de réduire la surcharge d’appel, mais soyez conscient de la duplication potentielle du code. Utiliser inline_refpour les fonctions plus grandes ou fréquemment appelées afin d'améliorer l'efficacité et d'éviter la répétition du code.

(5) Détermination du bon Workchain

TON permet la création de jusqu'à 2^32 workchains, chacune pouvant être subdivisée en jusqu'à 2^60 shards. Initialement, il y a deux workchains : la masterchain (-1) et la basechain (0). Lors du calcul des adresses cibles dans les contrats, il est crucial de spécifier le bon ID de workchain pour s'assurer que l'adresse de portefeuille générée se trouve sur le bon workchain. Pour éviter de générer des adresses incorrectes, il est recommandé d'utiliser force_chain()pour spécifier explicitement l'identifiant de chaîne.

(6) Éviter les conflits de codes d'erreur

La gestion efficace des codes d'erreur est cruciale pour la conception de contrats afin d'assurer la cohérence et d'éviter la confusion. Pour les contrats intelligents TON, assurez-vous que chaque code d'erreur est unique dans le contrat pour éviter les conflits et les messages d'erreur ambigus. Évitez également les conflits avec les codes d'erreur standard définis par la plate-forme TON ou le système sous-jacent. Par exemple, le code d'erreur 333 indique une incompatibilité d'ID de chaîne. Il est conseillé d'utiliser des codes d'erreur entre 400 et 1000 pour éviter de tels conflits.

(7) Stockage de données et Appelreturn() Après la fin de l’opération

Dans les contrats intelligents TON, la gestion des messages implique la sélection de différentes logiques en fonction de l'op-code. Après avoir terminé la logique correspondante, deux étapes supplémentaires sont nécessaires : premièrement, si les données ont été modifiées, appelersave_data() pour s’assurer que les modifications sont stockées ; Dans le cas contraire, les modifications seront inefficaces. Deuxièmement, appelez return()indiquer que l'opération est terminée; sinon, un jeter(0xffff)une exception sera déclenchée.

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {

int flags = cs~load_uint(4);

if (flags & 1) {

;; ignorer tous les messages rebondis

return ();

}

slice sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

if ((op == op::op_1())) {

handle_op1();

save_data();

return ();

}

if ((op == op::op_2())) {

handle_op2();

enregistrer_les_données();

return ();

}

if ((op == op::op_3())) {

handle_op3();

save_data();

return ();

}

throw(0xffff);

}

En résumé, la blockchain TON, avec son architecture innovante et son environnement de développement flexible, devient une plateforme idéale pour les développeurs d'applications décentralisées. Cependant, à mesure que les contrats intelligents jouent un rôle de plus en plus crucial dans l'écosystème TON, les problèmes de sécurité ne peuvent être négligés. Les développeurs doivent comprendre profondément les caractéristiques de l'écosystème TON, respecter strictement les meilleures pratiques et renforcer les processus d'audit de sécurité pour garantir la robustesse et la sécurité des contrats. Ce n'est qu'en agissant ainsi que les avantages de la plateforme TON peuvent être pleinement réalisés, en construisant des applications décentralisées plus sûres et plus fiables et en protégeant le développement sain de l'ensemble de l'écosystème.

L'écosystème TON connaît actuellement une croissance rapide, attirant des financements importants et des utilisateurs actifs. Cependant, les problèmes de sécurité qui l'accompagnent ne peuvent être ignorés. Pour garantir la sécurité et la fiabilité de l'écosystème TON, Beosin propose des audits de sécurité complets et professionnels adaptés aux caractéristiques des appels et des opérations de contrats intelligents TON, soutenant le développement de l'écosystème.

Beosin a de nombreux cas de réussite au sein de l'écosystème TON. Auparavant, Beosin a effectué des audits de sécurité approfondis pour le projet de stablecoin décentralisé leader Aqua Protocol et l'infrastructure DeFi ONTON Finance. L'audit a couvert plusieurs aspects, y compris la sécurité du code du contrat intelligent, la correction de la mise en œuvre de la logique métier, l'optimisation du code du contrat de gaz, et la détection et la résolution des vulnérabilités potentielles.

Déclaration :

1. Cet article est reproduit à partir de [ Beosin]], titre original "Beosin Hard Core Research | De la menace à la protection : Risques de sécurité et suggestions d'optimisation des contrats intelligents TON》, les droits d'auteur appartiennent à l'auteur original [Beosin], si vous avez des objections à la reproduction, veuillez contacterÉquipe Gate Learn, l’équipe s’en occupera dans les plus brefs délais selon les procédures applicables.

2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article ne représentent que les opinions personnelles de l'auteur et ne constituent en aucun cas des conseils en matière d'investissement.

3. Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn et ne sont pas mentionnées dans Gate.io, l’article traduit ne peut être reproduit, distribué ou plagié.