TON: recommandations et bonnes pratiques

Cet article est la traduction d'un document publié sur la page blockchain de TON: smc-guidelines.txt . Peut-être que cela aidera quelqu'un à faire un pas vers le développement de cette blockchain. De plus, à la fin, j'ai fait un bref résumé.

Messages internes

Les contrats intelligents interagissent les uns avec les autres en envoyant des messages dits internes. Lorsque le message interne atteint sa destination spécifiée, une transaction régulière est créée au nom du compte de destination et le message interne est traité selon le code spécifié et les données constantes de ce compte (contrat intelligent). En particulier, une transaction de traitement peut créer un ou plusieurs messages internes, dont certains peuvent être adressés à l'adresse source du message interne en cours de traitement. Cela peut être utilisé pour créer de simples «applications client-serveur» lorsqu'une demande est intégrée (encapsulée) dans un message interne et envoyée à un autre contrat intelligent qui traite la demande et renvoie la réponse, à nouveau sous forme de message interne.

Cette approche conduit à la nécessité de distinguer les messages internes à "demander" et "réponse" (en tant que "requête" ou en tant que "réponse"), ou qui ne nécessitent aucun traitement supplémentaire (comme un simple transfert d'argent). De plus, lorsqu'une réponse arrive, il doit y avoir un moyen de comprendre à quelle demande elle se rapporte.

Pour atteindre cet objectif, il est recommandé d'utiliser le modèle de message interne suivant (rappelez-vous que la blockchain TON n'impose aucune restriction au corps du message, c'est-à-dire qu'il s'agit simplement d'une recommandation):

0) Le corps du message peut être intégré dans le message lui-même, ou il peut être stocké dans une cellule distincte (cellule *), qui est référencée dans le message, comme indiqué dans le fragment TL-B du diagramme (en anglais, il est plus facile à comprendre: ou être stocké dans un autre cellule référencée dans le message, comme indiqué par le fragment de schéma TL-B):

message$_ {X:Type} ... body:(Either X ^X) = Message X; 

( https://core.telegram.org/mtproto - ici vous pouvez lire sur les schémas TL)

Le contrat intelligent de réception doit accepter au moins les messages internes avec le corps du message intégré (même s'ils sont placés dans la cellule contenant le message - chaque fois qu'ils s'insèrent dans la cellule contenant le message - il n'est pas très clair ce que cela signifie, par conséquent, joint le texte d'origine). Si le contrat accepte les corps de message dans des cellules distinctes (en utilisant le constructeur "droit" (Either X ^X) ), le traitement du message entrant ne devrait pas dépendre de la méthode particulière d'intégration du corps du message. D'un autre côté, il est absolument légal de ne pas prendre en charge le corps du message dans une cellule distincte pour simplifier les demandes et les réponses.

1) Le corps du message commence généralement par les champs suivants:

• op - Entier non signé 32 bits (big-endian) qui identifie l'opération à exécuter ou la méthode de contrat intelligent à appeler.
• query_id est un entier non signé 64 bits (big-endian) utilisé dans tous les messages de questions et réponses internes pour identifier la relation de la réponse à la demande (le query_id de la réponse doit être égal à la query_id de la demande correspondante). Si op n'est pas une méthode de demande-réponse (il appelle une méthode à partir de laquelle aucune réponse n'est attendue), alors query_id peut être omis.
• le reste du corps du message est spécifique à chaque valeur prise en charge du paramètre op

2) Si op est nul, le message est un simple message de transfert avec un commentaire. Le commentaire est contenu dans le reste du message (sans query_id et ainsi de suite, c'est-à-dire à partir du 5ème octet (explication: si query_id ne l' est pas, alors le champ op occupe les 4 premiers octets)). S'il ne commence pas par l'octet 0xff, le commentaire est un texte;); il peut être affiché pour l'utilisateur final du portefeuille "tel quel" (après avoir filtré les caractères invalides et de contrôle et vérifié qu'il s'agit d'une chaîne UTF-8 valide). Par exemple, les utilisateurs peuvent spécifier le but d'un simple transfert de leur portefeuille vers le portefeuille d'un autre utilisateur dans ce champ. En revanche, si un commentaire commence par l'octet 0xff, le reste du message est un «commentaire binaire» qui ne doit pas être affiché à l'utilisateur final sous forme de texte (uniquement sous forme de vidage hexadécimal si nécessaire). L'utilisation proposée des commentaires binaires, par exemple, est de contenir un identifiant de paiement pour le paiement dans le magasin, et d'être automatiquement généré et traité par le logiciel du magasin.

La plupart des contrats intelligents n'ont pas à effectuer d'actions non triviales ou à rejeter un message entrant lorsqu'ils reçoivent un «message de transfert simple». Ainsi, lorsque op s'avère être nul, la fonction de contrat intelligent pour le traitement des messages internes entrants (généralement appelée recv_internal() ) doit immédiatement se recv_internal() avec le code 0, indiquant le succès (par exemple, lever l'exception 0 si un gestionnaire personnalisé n'est pas installé dans le contrat intelligent exceptions). Cela entraînera le fait que le montant transféré par le message sera crédité sur le compte du destinataire sans autre effet.

3) "Un simple transfert de message sans commentaires" a un corps vide (même sans le champ op ). Les considérations ci-dessus s'appliquent à ces messages. Veuillez noter que ces messages doivent avoir leur propre corps intégré dans la cellule de message.

4) Nous nous attendons à ce que le champ op des messages de demande ait le premier bit ("bit de poids fort", traduit comme le premier, cela peut être incorrect, mais comme expliqué plus tard, il devient clair) est vide, c'est-à-dire que la valeur du champ doit être dans la plage 1 .. 2^31-1 , et pour les messages de réponse, le premier bit (de poids fort) doit être égal à 1, c'est-à-dire la valeur de champ dans la plage 2^31 .. 2^32-1 . Si le message n'est ni une demande ni une réponse (le corps ne contient pas le paramètre query_id ), il doit contenir le paramètre op dans la plage comme dans le message de demande: 1 .. 2^31 - 1 .

5) Il existe plusieurs messages de réponse «standard» pour lesquels op est 0xffffffff et 0xffffffffe. En général, les valeurs op de 0xfffffff0 à 0xffffffff sont réservées pour de telles réponses standard.

• op = 0xffffffff signifie "l'opération n'est pas prise en charge". Il est suivi d'un ID de requête 64 bits extrait de la requête d'origine et d'un op 32 bits de la requête d'origine. Tous les contrats intelligents, sauf les plus simples, doivent renvoyer cette erreur lorsqu'ils reçoivent une demande avec un op inconnu dans la plage 1 ... 2 ^ 31-1.
• op = 0xfffffffe signifie "opération non autorisée". Il est suivi par l' identifiant de requête 64 bits de la requête d'origine, puis par l'opération 32 bits extraite de la requête d'origine.

Notez que les "réponses" inconnues (avec op dans la plage 2 ^ 31 ... 2 ^ 32-1) doivent être ignorées (en particulier, vous ne devez pas générer de réponse avec op égal à 0xffffffff), ainsi qu'un retour inattendu ( messages rebondis (avec le drapeau "rebondi").

Paiement pour le traitement des demandes et l'envoi des réponses

En général, si un contrat intelligent souhaite envoyer une demande à un autre contrat intelligent, il doit payer pour envoyer un message interne au contrat intelligent cible (frais de transfert de message), pour traiter ce message à destination (frais de gaz: frais de gaz) et pour l'envoi d'une réponse si nécessaire (frais d'envoi de messages).

Dans la plupart des cas, l'expéditeur attachera une petite quantité de gramme au message interne (par exemple, 1 gramme) (assez pour payer pour le traitement de ce message) et définira le drapeau "rebond" dessus (c'est-à-dire qu'il enverra un message interne rebondissable); le destinataire retournera la partie inutilisée de la valeur reçue avec la réponse (en soustrayant les frais d'envoi du message). Ceci est généralement réalisé en appelant SENDRAWMSG avec mode = 64 (cf. Annexe A de la documentation TON VM).

Si le destinataire ne peut pas traiter le message reçu et que l'exécution se termine avec un code de sortie différent de zéro (par exemple, en raison d'une exception de désérialisation de cellule non gérée), le message sera automatiquement «renvoyé» à l'expéditeur et l'indicateur «rebond» sera décoché et défini. drapeau "rebondi". Le corps du message renvoyé sera le même que le message d'origine; par conséquent, il est important de vérifier l'indicateur "renvoyé" du message interne entrant avant d'analyser le champ op dans le contrat intelligent et de traiter la demande correspondante (sinon il existe un risque que la demande contenue dans le message renvoyé soit traitée par son expéditeur d'origine comme une nouvelle demande distincte). Si l'indicateur "rebondi" est défini, un code spécial peut comprendre quelle demande a échoué (par exemple, en désérialisant op et query_id à partir d'un message renvoyé) et prendre les mesures appropriées. Un contrat intelligent plus simple peut simplement ignorer tous les messages retournés (se terminer par un code de sortie nul si l'indicateur "rebondi" est défini).

D'un autre côté, le récepteur peut analyser correctement la demande entrante et constater que la méthode op demandée n'est pas prise en charge ou qu'une autre condition d'erreur a été remplie. Ensuite, une réponse avec op égal à 0xffffffff ou une autre valeur appropriée doit être renvoyée en utilisant SENDRAWMSG avec mode = 64, comme mentionné ci-dessus.

Dans certaines situations, l'expéditeur souhaite transférer une certaine somme d'argent en même temps? à l'expéditeur? (ici, apparemment, une erreur, et était destiné au "destinataire") et recevoir soit une confirmation soit un message d'erreur. Par exemple, un contrat intelligent d'élections de validateur reçoit une demande de participation à une élection ainsi qu'une offre en tant que valeur ajoutée. Dans de tels cas, il est logique d'attacher, par exemple, un gramme supplémentaire à la valeur estimée [coût] (Ici, le mot valeur est utilisé partout, dans le sens de paiement pour une action, j'ai donc utilisé le mot "coût"). Si une erreur se produit (par exemple, l'offre ne peut être acceptée pour une raison quelconque), le montant total reçu (moins les frais de traitement) doit être retourné à l'expéditeur avec le message d'erreur (par exemple, en utilisant SENDRAWMSG avec le mode = 64, comme décrit ci-dessus). En cas de succès, un message de confirmation est créé et exactement un gramme est renvoyé (les frais de transfert du message sont soustraits de cette valeur; il s'agit du mode = 1 de SENDRAWMSG).

Utilisation de messages non rebondissables

Presque tous les messages internes envoyés entre les contrats intelligents doivent être retournés (vous pouvez le traduire par "rebondir", mais afin de ne pas vous tromper, il est plus facile d'utiliser cette terminologie), c'est-à-dire qu'ils doivent avoir le bit "rebond" non vide. Ensuite, si le contrat intelligent cible n'existe pas ou s'il crée une exception non gérée lors du traitement de ce message, le message sera «renvoyé» en retour, supportant le reste du coût initial (valeur) (moins tous les frais de transmission des messages et du gaz). Le message renvoyé aura le même corps, mais avec le drapeau "bounce" effacé et le drapeau "bounce" défini. Par conséquent, tous les contrats intelligents doivent vérifier le drapeau "rebondi" de tous les messages entrants et les recevoir en silence (se terminant immédiatement avec un code de sortie nul) ou effectuer un traitement spécial pour déterminer quelle demande sortante a échoué. La demande contenue dans le corps du message renvoyé ne doit jamais être exécutée.

Dans certains cas, des messages internes non rebondissants doivent être utilisés. Par exemple, un nouveau compte ne peut pas être créé sans qu'au moins un message interne irrévocable ne lui soit envoyé. Si ce message ne contient pas StateInit avec le code et les données du nouveau contrat intelligent, cela n'a aucun sens d'avoir un corps non vide dans un message interne non retourné.

C'est une bonne idée de ne pas permettre à l'utilisateur final (par exemple, le portefeuille) d'envoyer des messages irrévocables qui contiennent une grande quantité (par exemple, plus de cinq grammes), ou au moins de les avertir s'ils essaient de le faire. Il est préférable d'envoyer d'abord un petit montant, puis de créer un nouveau contrat intelligent, puis d'envoyer un montant plus important.

Messages externes

Les messages externes sont envoyés en externe aux contrats intelligents situés sur la blockchain TON pour les forcer à effectuer certaines actions. Par exemple, le contrat intelligent du portefeuille s'attend à recevoir des messages externes contenant des commandes (par exemple, des messages internes qui seront envoyés à partir du contrat intelligent du portefeuille) signés par le propriétaire du portefeuille; lorsqu'un tel message externe est reçu par le contrat intelligent du portefeuille, il vérifie d'abord la signature, puis reçoit le message (en lançant la primitive TVM ACCEPT), puis effectue toutes les actions nécessaires.

Veuillez noter que tous les messages externes doivent être protégés contre les attaques par rejeu. Les validateurs suppriment généralement un message externe du pool de messages externes proposés (reçus du réseau); cependant, dans certaines situations, un autre validateur peut traiter deux fois le même message externe (créant ainsi une deuxième transaction pour le même message externe, ce qui conduit à la duplication de l'action d'origine). Pire encore, un attaquant peut extraire un message externe d'un bloc contenant une transaction de traitement et le renvoyer ultérieurement. Cela peut entraîner, par exemple, un contrat de portefeuille intelligent pour répéter le paiement.

Le moyen le plus simple de protéger les contrats intelligents contre les attaques de reniflement associées aux messages externes consiste à stocker le compteur cur-seqno 32 bits dans les données constantes du contrat intelligent et à attendre la valeur req-seqno dans la (partie signée) de tous les messages externes entrants. Le message externe n'est alors accepté (ACCEPTÉ - un indice de la primitive ACCEPT) que si la signature est valide et que req-seqno est égal à cur-seqno . Après un traitement réussi, la valeur de cur-seqno dans les données persistantes augmente de un, de sorte que le même message externe ne sera plus jamais reçu.

Vous pouvez également inclure le champ expirer à dans un message externe et accepter le message uniquement si l'heure Unix actuelle est inférieure à la valeur de ce champ. Cette approche peut être utilisée en combinaison avec seqno ; en variante, le contrat intelligent de réception peut stocker un ensemble (hachages) de tous les derniers messages externes reçus (non expirés) dans ses données permanentes et rejeter un nouveau message externe s'il s'agit d'un doublon de l'un des messages enregistrés. Vous devez également implémenter la collecte et la suppression des messages expirés dans cet ensemble pour éviter une croissance illimitée des données persistantes.

En règle générale, un message externe commence par une signature 256 bits (si nécessaire), une requête req-seqno 32 bits (si nécessaire), une expiration 32 bits (si nécessaire), et éventuellement une opération 32 bits et d'autres paramètres nécessaires dans selon op . Le modèle de message externe ne doit pas être aussi standardisé que le modèle de message interne, car les messages externes ne sont pas utilisés pour l'interaction entre différents contrats intelligents (écrits par différents développeurs et gérés par différents propriétaires).

Obtenir des méthodes

Certains contrats intelligents devraient implémenter certaines méthodes get bien définies. Par exemple, tout contrat intelligent de résolution DNS pour TON DNS devrait implémenter la méthode get dnsresolve. Les contrats intelligents personnalisés peuvent définir leurs méthodes d'obtention spécifiques. Notre seule recommandation générale pour le moment est d'implémenter la méthode get "seqno" (sans paramètres), qui renvoie le seqno actuel du contrat intelligent, qui utilise des numéros de séquence pour empêcher les attaques de lecture associées aux méthodes externes entrantes chaque fois qu'une telle méthode a sens.

Dictionnaire:

• Cellule - Une cellule TVM se compose d'au plus 1023 bits de données et d'au plus quatre références à d'autres cellules. Toutes les données persistantes (y compris le code TVM) dans la blockchain TON sont représentées comme une collection de cellules TVM (cf. [1, 2.5.14]). - une cellule TVM ne comprend pas plus de 1 023 bits de données et pas plus de quatre liens vers d'autres cellules. Toutes les données persistantes (y compris le code TVM) dans la blockchain TON sont présentées comme un ensemble de cellules TVM (cf. [1, 2.5.14]). - extrait de la description de la machine virtuelle TON ( https://test.ton.org/tvm.pdf )

Quelles conclusions peut-on tirer sur la base de ce que j'ai lu?

1. Vous pouvez envoyer des messages externes aux contrats pour déclencher une action.
2. Attaques - il y a, par exemple, des attaques par rejeu
3. Cela vaut la peine d’ utiliser la méthode seqno pour se protéger contre les attaques par rejeu.
4. Les résolveurs DNS ont la méthode dnsresolve
5. Vous pouvez stocker des hachages de messages externes pour vous protéger contre les attaques, mais vous devez les supprimer à temps, pour cela, il vaut la peine d'utiliser le champ expired_at pour les messages externes
6. Les messages de non-retour ne sont nécessaires que pour créer des contrats; sinon, tous les messages internes sont renvoyés
7. Les messages de demande-réponse doivent contenir les champs suivants: op, query_id - facultatif, et certains autres en fonction de la valeur de op
8. Vous pouvez joindre des commentaires de texte au format UTF-8 pour les personnes et des «commentaires binaires» pour une lecture et un traitement automatiques par un logiciel tiers.
9. Cela vaut la peine de gérer les exceptions et de le faire judicieusement
10. "Message simple sans commentaires" - doit avoir un corps vide
11. Le bit de poids fort des messages de réponse à la demande prend une valeur de 0 pour les messages de demande et une valeur de 1 pour les messages de réponse
12. Il existe des valeurs opérationnelles standard pour les messages de réponse afin d'identifier les erreurs
13. Si un message de réponse est reçu avec une opération inconnue, il doit être ignoré, c'est-à-dire terminer l'exécution avec le code 0
14. Vous devez payer pour envoyer des messages, pour le gaz et pour envoyer une réponse. Dans le même temps, s'il a envoyé plus que nécessaire, l'excédent reviendra dans la réponse.
15. Lors de la réception de messages, il est toujours utile de vérifier d'abord le drapeau rebondi.

Merci de votre attention, je serai heureux de recevoir des commentaires constructifs!