TON: अनुशंसाएँ और सर्वोत्तम प्रथाएँ

यह लेख TON ब्लॉकचैन पेज पर प्रकाशित एक दस्तावेज़ का अनुवाद है: smc-Guidelines.txt । शायद यह किसी को इस ब्लॉकचेन के लिए विकास की दिशा में कदम उठाने में मदद करेगा। इसके अलावा, अंत में मैंने एक संक्षिप्त सारांश बनाया।

आंतरिक संदेश

स्मार्ट कॉन्ट्रैक्ट तथाकथित आंतरिक संदेश भेजकर एक-दूसरे के साथ बातचीत करते हैं। जब आंतरिक संदेश अपने निर्दिष्ट गंतव्य तक पहुंचता है, तो गंतव्य खाते के नाम पर एक नियमित लेनदेन बनाया जाता है, और आंतरिक संदेश को निर्दिष्ट कोड और इस खाते के निरंतर डेटा (स्मार्ट अनुबंध) के अनुसार संसाधित किया जाता है। विशेष रूप से, एक प्रसंस्करण लेनदेन एक या अधिक आंतरिक संदेश बना सकता है, जिनमें से कुछ को संसाधित किए जा रहे आंतरिक संदेश के स्रोत पते पर संबोधित किया जा सकता है। इसका उपयोग सरल "क्लाइंट-सर्वर एप्लिकेशन" बनाने के लिए किया जा सकता है जब एक अनुरोध एक आंतरिक संदेश में एम्बेडेड (एनकैप्सुलेटेड) होता है और एक अन्य स्मार्ट अनुबंध पर भेजा जाता है जो अनुरोध को संसाधित करता है और प्रतिक्रिया को वापस भेजता है, फिर से एक आंतरिक संदेश के रूप में।

यह दृष्टिकोण आंतरिक संदेशों के बीच "अनुरोध" और "प्रतिक्रिया" ("क्वेरी" के रूप में या "प्रतिक्रिया" के रूप में) को भेद करने की आवश्यकता की ओर जाता है, या किसी अतिरिक्त प्रसंस्करण की आवश्यकता नहीं है (जैसे कि एक साधारण धन हस्तांतरण)। इसके अलावा, जब कोई उत्तर आता है, तो यह समझने का एक तरीका होना चाहिए कि यह किस अनुरोध से संबंधित है।

इस लक्ष्य को प्राप्त करने के लिए, निम्न आंतरिक संदेश टेम्प्लेट का उपयोग करने की अनुशंसा की जाती है (याद रखें कि TON ब्लॉकचेन संदेश निकाय पर कोई प्रतिबंध नहीं लगाता है, अर्थात यह सिर्फ एक सिफारिश है):

0) संदेश का मुख्य भाग संदेश में ही एम्बेड किया जा सकता है, या इसे एक अलग सेल (सेल *) में संग्रहीत किया जा सकता है, जिसे संदेश में संदर्भित किया जाता है, जैसा कि आरेख के टीएल-बी के टुकड़े में इंगित किया गया है (अंग्रेजी में इसे समझना आसान है: या एक अलग संग्रहित किया जा सकता है) सेल संदेश से संदर्भित है, जैसा कि टीएल-बी स्कीम खंड द्वारा दर्शाया गया है):

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

( https://core.telegram.org/mtproto - यहां आप TL-योजनाओं के बारे में पढ़ सकते हैं)

स्मार्ट कॉन्ट्रैक्ट को स्वीकार करने के लिए कम से कम आंतरिक संदेशों को संदेश बॉडी के साथ स्वीकार करना चाहिए (भले ही वे संदेश वाले सेल में रखे गए हों - जब भी वे संदेश वाले सेल में फिट होते हैं - यह बहुत स्पष्ट नहीं है कि इसका क्या अर्थ है, इसलिए, मूल पाठ संलग्न किया गया)। यदि अनुबंध अलग-अलग कक्षों में संदेश निकायों को स्वीकार करता है ("सही" कंस्ट्रक्टर (Either X ^X) का उपयोग करके), आने वाले संदेश का प्रसंस्करण संदेश शरीर को एम्बेड करने की विशेष विधि पर निर्भर नहीं होना चाहिए। दूसरी ओर, अनुरोधों और प्रतिक्रियाओं को सरल बनाने के लिए एक अलग सेल में संदेश निकाय का समर्थन नहीं करना बिल्कुल कानूनी है।

1) संदेश निकाय आमतौर पर निम्नलिखित क्षेत्रों से शुरू होता है:

• ऑप - 32-बिट (बड़ा-एंडियन) अहस्ताक्षरित पूर्णांक जो ऑपरेशन को निष्पादित करने के लिए पहचानता है, या कॉल करने के लिए स्मार्ट अनुबंध विधि।
• query_id एक 64-बिट (बिग-एंडियन) अहस्ताक्षरित पूर्णांक है जिसका उपयोग सभी आंतरिक प्रश्नों और उत्तर संदेशों में अनुरोध के प्रति प्रतिक्रिया के संबंध की पहचान करने के लिए किया जाता है (प्रतिक्रिया का query_id संबंधित अनुरोध के query_id के बराबर होना चाहिए)। यदि ऑप एक अनुरोध-प्रतिक्रिया विधि नहीं है (यह एक ऐसी विधि कहलाता है जिसमें कोई प्रतिक्रिया अपेक्षित नहीं है), तो query_id छोड़ा जा सकता है।
• संदेश का मुख्य भाग ऑप पैरामीटर के प्रत्येक समर्थित मान के लिए विशिष्ट है

2) यदि op शून्य है, तो संदेश एक टिप्पणी के साथ एक सरल हस्तांतरण संदेश है। यह टिप्पणी संदेश के शेष भाग में ( query_id के बिना और इसी तरह, यानी, 5 वीं बाइट से शुरू होती है) (स्पष्टीकरण: यदि query_id नहीं है, तो op फ़ील्ड पहले 4 बाइट्स लेता है)। यदि यह बाइट 0xff से शुरू नहीं होता है, तो टिप्पणी एक पाठ है;); इसे "के रूप में" वॉलेट के अंतिम उपयोगकर्ता के लिए प्रदर्शित किया जा सकता है (अमान्य और नियंत्रण वर्णों को छानने और जाँचने के बाद कि यह वैध UTF-8 स्ट्रिंग है)। उदाहरण के लिए, उपयोगकर्ता अपने बटुए से इस क्षेत्र में किसी अन्य उपयोगकर्ता के बटुए में एक सरल हस्तांतरण के उद्देश्य को निर्दिष्ट कर सकते हैं। दूसरी ओर, यदि कोई टिप्पणी बाइट 0xff से शुरू होती है, तो शेष संदेश एक "बाइनरी टिप्पणी" है, जिसे अंतिम उपयोगकर्ता को पाठ के रूप में प्रदर्शित नहीं किया जाना चाहिए (यदि आवश्यक हो तो केवल एक हेक्स डंप के रूप में)। उदाहरण के लिए, बाइनरी टिप्पणियों का प्रस्तावित उपयोग, स्टोर में भुगतान के लिए भुगतान पहचानकर्ता को शामिल करना है, और स्टोर सॉफ़्टवेयर द्वारा स्वचालित रूप से उत्पन्न और संसाधित किया जाना है।

अधिकांश स्मार्ट कॉन्ट्रैक्ट्स को "सरल स्थानांतरण संदेश" प्राप्त होने पर, नॉनवेजियल एक्शन करने या किसी आने वाले संदेश को अस्वीकार करने की आवश्यकता नहीं होती है। इस प्रकार, जब ऑप शून्य हो जाता है, तो आने वाले आंतरिक संदेशों को संसाधित करने के लिए स्मार्ट कॉन्ट्रैक्ट फ़ंक्शन (जिसे आमतौर पर recv_internal() कहा जाता है) को तुरंत कोड 0 से बाहर निकलना चाहिए, सफलता का संकेत देता है (उदाहरण के लिए, अपवाद को फेंकना यदि स्मार्ट कॉन्ट्रैक्ट में कस्टम हैंडलर स्थापित नहीं है अपवाद)। यह इस तथ्य को जन्म देगा कि संदेश द्वारा हस्तांतरित राशि बिना किसी और प्रभाव के प्राप्तकर्ता के खाते में जमा हो जाएगी।

3) "टिप्पणियों के बिना एक सरल संदेश स्थानांतरण" में एक खाली शरीर है (यहां तक ​​कि बिना ऑप फ़ील्ड के भी)। उपरोक्त विचार ऐसे संदेशों पर लागू होते हैं। कृपया ध्यान दें कि इस तरह के संदेशों का संदेश सेल में स्वयं का शरीर होना चाहिए।

4) हम उम्मीद करते हैं कि अनुरोध संदेशों के ऑप फ़ील्ड में पहले बिट ("उच्च-क्रम बिट" होगा, पहले के रूप में अनुवादित, यह गलत हो सकता है, लेकिन जैसा कि बाद में यह स्पष्ट हो गया है) खाली है, अर्थात फ़ील्ड का मान सीमा 1 .. 2^31-1 में होना चाहिए 1 .. 2^31-1 , और प्रतिक्रिया संदेशों के लिए पहला (उच्च-क्रम) बिट 1 के बराबर होना चाहिए, अर्थात 2^31 .. 2^32-1 रेंज में फ़ील्ड मान। यदि संदेश न तो अनुरोध है और न ही प्रतिक्रिया है (बॉडी में क्वेरी_ड पैरामीटर शामिल नहीं है), तो इसमें ऑप पैरामीटर को अनुरोध संदेश में होना चाहिए: 1 .. 2^31 - 1 ।

5) कई "मानक" प्रतिक्रिया संदेश हैं जिनके लिए op 0xffffffff और 0xffffffffe है। सामान्य तौर पर, 0xfffffff0 से 0xffffffff तक के मान ऐसे मानक उत्तरों के लिए आरक्षित होते हैं।

• op = 0xffffff का अर्थ है "ऑपरेशन समर्थित नहीं है।" इसके बाद मूल क्वेरी से निकाले गए 64-बिट क्वेरी_ड और मूल क्वेरी का 32-बिट ऑप होता है । सभी लेकिन सबसे सरल स्मार्ट कॉन्ट्रैक्ट्स को इस त्रुटि को वापस करना चाहिए जब उन्हें एक अज्ञात ओप के साथ सीमा 1 ... 2 ^ 31-1 में अनुरोध प्राप्त होता है।
• op = 0xffffff का अर्थ है "ऑपरेशन की अनुमति नहीं है।" यह मूल क्वेरी के 64-बिट query_id द्वारा पीछा किया जाता है, और फिर मूल क्वेरी से 32-बिट ऑप निकाला जाता है।

ध्यान दें कि अज्ञात "उत्तर" (2 से 31 ^ 2 ... 2 ^ 32-1 के साथ) को अनदेखा किया जाना चाहिए (विशेष रूप से, आपको 0xffffffff के बराबर op के साथ प्रतिक्रिया उत्पन्न नहीं करनी चाहिए), साथ ही साथ अप्रत्याशित वापसी ( बाउंस) -messages ("बाउंस" फ्लैग सेट के साथ)।

प्रसंस्करण अनुरोधों और जवाब भेजने के लिए भुगतान

सामान्य तौर पर, यदि कोई स्मार्ट कॉन्ट्रैक्ट किसी दूसरे स्मार्ट कॉन्ट्रैक्ट को रिक्वेस्ट भेजना चाहता है, तो उसे इस मैसेज को डेस्टिनेशन (गैस शुल्क) पर प्रोसेस करने के लिए टारगेट स्मार्ट कॉन्ट्रैक्ट (मैसेज फॉरवर्डिंग फीस) में इंटरनल मैसेज भेजने के लिए भुगतान करना होगा। गैस शुल्क) और यदि आवश्यक हो तो एक प्रतिक्रिया भेजने के लिए (संदेश अग्रेषण शुल्क)।

ज्यादातर मामलों में, प्रेषक आंतरिक संदेश (उदाहरण के लिए, 1 ग्राम) की एक छोटी राशि (इस संदेश को संसाधित करने के लिए भुगतान करने के लिए पर्याप्त) को संलग्न करेगा और उस पर "उछाल" ध्वज सेट करेगा (यह एक बाउंसर आंतरिक संदेश भेजेगा); प्राप्तकर्ता जवाब के साथ प्राप्त मूल्य का अप्रयुक्त भाग वापस कर देगा (इससे संदेश भेजने के लिए शुल्क घटाकर)। यह आमतौर पर SENDRAWMSG को मोड = 64 (cf. परिशिष्ट A से TON VM प्रलेखन) कहकर प्राप्त किया जाता है।

यदि प्राप्तकर्ता प्राप्त किए गए संदेश को संसाधित नहीं कर सकता है और गैर-शून्य निकास कोड (उदाहरण के लिए, एक अखंड सेल डिसेरिएलाइजेशन अपवाद के कारण) के साथ निष्पादन समाप्त नहीं हो सकता है, तो संदेश प्रेषक को वापस "बाउंस" हो जाएगा, और "बाउंस" ध्वज अनियंत्रित और सेट हो जाएगा। झंडा "बाउंस"। बाउंस किए गए संदेश का मुख्य भाग मूल संदेश के समान होगा; इसलिए, स्मार्ट कॉन्ट्रैक्ट में ऑप फ़ील्ड को पार्स करने और संबंधित अनुरोध को संसाधित करने से पहले आने वाले आंतरिक संदेश के "बाउंस" ध्वज की जांच करना महत्वपूर्ण है (अन्यथा एक जोखिम है कि बाउंस किए गए संदेश में शामिल अनुरोध को उसके मूल प्रेषक द्वारा एक नए अलग अनुरोध के रूप में संसाधित किया जाएगा)। यदि "बाउंस" ध्वज सेट किया गया है, तो विशेष कोड यह समझ सकता है कि कौन सा अनुरोध विफल हुआ (उदाहरण के लिए, एक संदेश से op और query_id को deserializing द्वारा) और उचित कार्रवाई करें। एक सरल स्मार्ट अनुबंध बस सभी लौटाए गए संदेशों को अनदेखा कर सकता है ("बाउंस" ध्वज सेट होने पर शून्य निकास कोड के साथ समाप्त)।

दूसरी ओर, रिसीवर आने वाले अनुरोध को सफलतापूर्वक पार्स कर सकता है और यह पता लगा सकता है कि अनुरोधित ऑप विधि समर्थित नहीं है या कि कोई अन्य त्रुटि स्थिति पूरी हो गई है। फिर 0xffffffff या एक अन्य उचित मूल्य के बराबर op के साथ एक प्रतिक्रिया मोड = 64 के साथ SENDRAWMSG का उपयोग करके वापस भेजा जाना चाहिए, जैसा कि ऊपर बताया गया है।

कुछ स्थितियों में, प्रेषक एक ही समय में एक निश्चित धनराशि स्थानांतरित करना चाहता है? प्रेषक को? (यहां, स्पष्ट रूप से, एक त्रुटि, और "प्राप्तकर्ता" के लिए थी) और एक पुष्टिकरण या एक त्रुटि संदेश प्राप्त करें। उदाहरण के लिए, एक वैध चुनाव स्मार्ट अनुबंध को एक मूल्य के रूप में एक बोली के साथ चुनाव में भाग लेने का अनुरोध प्राप्त होता है। ऐसे मामलों में, यह अनुमानित मूल्य [लागत] के लिए एक अतिरिक्त चना संलग्न करने के लिए समझ में आता है, (यहां शब्द मूल्य का उपयोग हर जगह किया जाता है, कुछ कार्रवाई के लिए भुगतान के अर्थ में, इसलिए मैंने "लागत" शब्द का उपयोग किया)। यदि कोई त्रुटि होती है (उदाहरण के लिए, बोली किसी भी कारण से स्वीकार नहीं की जा सकती), तो प्राप्त की गई पूरी राशि (ऋण प्रसंस्करण शुल्क) त्रुटि संदेश के साथ प्रेषक को वापस कर दी जानी चाहिए (उदाहरण के लिए, मोड = 64 के साथ SENDRAWMSG का उपयोग, जैसा कि वर्णित है) इसके बाद के संस्करण)। सफल होने पर, एक पुष्टिकरण संदेश बनाया जाता है और ठीक एक ग्राम वापस भेजा जाता है (इस मूल्य से संदेश हस्तांतरण शुल्क घटाया जाता है; यह SENDRAWMSG का मोड = 1 है)।

गैर-परिषदीय संदेशों का उपयोग करना

स्मार्ट कॉन्ट्रैक्ट्स के बीच भेजे गए लगभग सभी आंतरिक संदेशों को लौटाया जाना चाहिए (आप इसे "शेख़ी" के रूप में अनुवादित कर सकते हैं, लेकिन भ्रमित न होने के लिए, इस शब्दावली का उपयोग करना आसान है), अर्थात, उनके पास "बाउंस" बिट खाली नहीं होना चाहिए। फिर, यदि लक्ष्य स्मार्ट अनुबंध मौजूद नहीं है, या यदि यह इस संदेश को संसाधित करते समय एक अखंड अपवाद बनाता है, तो संदेश को प्रारंभिक लागत (मूल्य) के शेष (संदेशों और गैस के प्रसारण के लिए सभी शुल्क घटाकर) वापस "वापस" कर दिया जाएगा। लौटे संदेश में एक ही बॉडी होगी, लेकिन "बाउंस" फ्लैग क्लियर और "बाउंस" फ्लैग सेट के साथ। इसलिए, सभी स्मार्ट कॉन्ट्रैक्ट्स को आने वाले सभी संदेशों के "बाउंस" ध्वज की जांच करनी चाहिए और या तो चुपचाप उन्हें प्राप्त करना चाहिए (तुरंत एक शून्य निकास कोड के साथ समाप्त करना) या यह निर्धारित करने के लिए कुछ विशेष प्रसंस्करण करना कि कौन सा आउटगोइंग अनुरोध विफल रहा। दिए गए संदेश के मुख्य भाग में दिए गए अनुरोध को कभी भी निष्पादित नहीं किया जाना चाहिए।

कुछ मामलों में, गैर-बाउंस करने योग्य आंतरिक संदेशों का उपयोग किया जाना चाहिए। उदाहरण के लिए, कम से कम एक अपरिवर्तनीय आंतरिक संदेश भेजे बिना नया खाता नहीं बनाया जा सकता। यदि इस संदेश में नए स्मार्ट कॉन्ट्रैक्ट के कोड और डेटा के साथ StateInit शामिल नहीं है, तो यह एक गैर-खाली आंतरिक संदेश में एक गैर-खाली निकाय होने का कोई मतलब नहीं है।

यह एक अच्छा विचार है कि अंतिम उपयोगकर्ता (जैसे, बटुए) को अपरिवर्तनीय संदेश भेजने की अनुमति न दें जो बड़ी मात्रा में ले जाते हैं (जैसे, पांच ग्राम से अधिक), या कम से कम उन्हें चेतावनी दें यदि वे ऐसा करने की कोशिश करते हैं। पहले एक छोटी राशि भेजना बेहतर है, फिर एक नया स्मार्ट अनुबंध बनाएं, और फिर एक बड़ी राशि भेजें।

बाहरी संदेश

बाहरी संदेशों को TON ब्लॉकचेन पर स्थित स्मार्ट कॉन्ट्रैक्ट पर बाहरी रूप से भेजा जाता है ताकि उन्हें कुछ क्रियाएं करने के लिए मजबूर किया जा सके। उदाहरण के लिए, वॉलेट के स्मार्ट कॉन्ट्रैक्ट में ऑर्डर वाले बाहरी संदेश प्राप्त करने की उम्मीद है (उदाहरण के लिए, वॉलेट के स्मार्ट कॉन्ट्रैक्ट से भेजे जाने वाले आंतरिक संदेश) वॉलेट मालिक द्वारा हस्ताक्षरित होंगे; जब इस तरह के बाहरी संदेश को वॉलेट के स्मार्ट अनुबंध द्वारा प्राप्त किया जाता है, तो यह पहले हस्ताक्षर की पुष्टि करता है, फिर संदेश प्राप्त करता है (TVM ACCEPT आदिम लॉन्च करके), और फिर सभी आवश्यक कार्य करता है।

कृपया ध्यान दें कि सभी बाहरी संदेशों को फिर से खेलना हमलों से बचाया जाना चाहिए। सत्यापनकर्ता आमतौर पर प्रस्तावित बाहरी संदेशों (नेटवर्क से प्राप्त) के पूल से एक बाहरी संदेश निकालते हैं; हालाँकि, कुछ स्थितियों में, एक अन्य सत्यापनकर्ता एक ही बाहरी संदेश को दो बार संसाधित कर सकता है (इस प्रकार एक ही बाहरी संदेश के लिए दूसरा लेन-देन बना सकता है, जो मूल क्रिया के दोहराव की ओर जाता है)। इससे भी बदतर, एक हमलावर एक ब्लॉक से एक बाहरी संदेश निकाल सकता है जिसमें एक प्रसंस्करण लेनदेन होता है और बाद में इसे फिर से भेज सकता है। यह, उदाहरण के लिए, भुगतान को दोहराने के लिए एक स्मार्ट वॉलेट अनुबंध हो सकता है।

बाहरी संदेशों से जुड़े सूंघने वाले हमलों से स्मार्ट कॉन्ट्रैक्ट्स को बचाने का सबसे आसान तरीका स्मार्ट कॉन्ट्रैक्ट निरंतर डेटा में 32-बिट क्यूर-सेक्नो काउंटर को स्टोर करना है और किसी भी आने वाले बाहरी संदेशों के (हस्ताक्षरित भाग) में री-सेक्नो वैल्यू की प्रतीक्षा करना है। तब बाहरी संदेश स्वीकार किया जाता है (ACCEPTed - आदिम ACCEPT का एक संकेत) केवल तभी जब हस्ताक्षर वैध हो और req-seqno cur-seqno के बराबर हो। सफल प्रसंस्करण के बाद, लगातार डेटा में cur-seqno का मूल्य एक से बढ़ जाता है, इसलिए एक ही बाहरी संदेश फिर से प्राप्त नहीं होगा।

आप किसी बाह्य संदेश में समाप्ति- क्षेत्र को भी शामिल कर सकते हैं और संदेश को तभी स्वीकार कर सकते हैं जब वर्तमान यूनिक्स समय इस क्षेत्र के मान से कम हो। इस दृष्टिकोण का उपयोग सेक्नो के संयोजन में किया जा सकता है; वैकल्पिक रूप से, प्राप्त करने वाला स्मार्ट कॉन्ट्रैक्ट अपने स्थायी डेटा में प्राप्त सभी अंतिम (समाप्त नहीं) के एक सेट (हैश) को स्टोर कर सकता है और यदि वह सहेजे गए संदेशों में से एक का डुप्लिकेट है तो एक नए बाहरी संदेश को अस्वीकार कर सकता है। लगातार डेटा की असीमित वृद्धि से बचने के लिए आपको इस सेट में समाप्त संदेशों के संग्रह और निष्कासन को भी लागू करना चाहिए।

आमतौर पर, एक बाहरी संदेश 256-बिट हस्ताक्षर (यदि आवश्यक हो), 32-बिट req-seqno (यदि आवश्यक हो), 32-बिट एक्सपायर-ऑन (यदि आवश्यक हो), और संभवतः 32-बिट ऑप और अन्य आवश्यक मापदंडों के साथ शुरू होता है। सेशन के आधार पर। बाहरी संदेश टेम्पलेट को आंतरिक संदेश टेम्पलेट के रूप में मानकीकृत करने की आवश्यकता नहीं है, क्योंकि बाहरी संदेशों का उपयोग विभिन्न स्मार्ट अनुबंधों (विभिन्न डेवलपर्स द्वारा लिखित और विभिन्न मालिकों द्वारा प्रबंधित) के बीच बातचीत के लिए नहीं किया जाता है।

विधियां प्राप्त करें

कुछ स्मार्ट कॉन्ट्रैक्ट्स को कुछ अच्छी तरह से परिभाषित गेट-विधियों को लागू करने की उम्मीद है। उदाहरण के लिए, TON DNS के लिए किसी भी डीएनएस रिज़ॉल्वर स्मार्ट अनुबंध से उम्मीद है कि dnsresolve पाने का तरीका लागू किया जाएगा। कस्टम स्मार्ट कॉन्ट्रैक्ट्स उनके विशिष्ट तरीकों को परिभाषित कर सकते हैं। इस समय हमारी एकमात्र सामान्य अनुशंसा "सेक्नो" प्राप्त करने की विधि (मापदंडों के बिना) को लागू करना है, जो स्मार्ट अनुबंध के वर्तमान सेक्नो को लौटाता है, जो कि जब भी ऐसी विधि होती है तो आने वाले बाहरी तरीकों से जुड़े प्लेबैक हमलों को रोकने के लिए अनुक्रम संख्या का उपयोग करता है। जिसका अर्थ है।

शब्दकोश:

• सेल - एक टीवीएम सेल में डेटा के अधिकांश 1023 बिट्स होते हैं, और अन्य कोशिकाओं के लिए अधिकतम चार संदर्भ होते हैं। TON ब्लॉकचैन में सभी लगातार डेटा (TVM कोड सहित) TVM कोशिकाओं के संग्रह (cf. [1, 2.5.14]) के रूप में दर्शाया गया है। - एक टीवीएम सेल में 1023 बिट्स से अधिक डेटा नहीं होता है और अन्य कोशिकाओं के लिए चार लिंक से अधिक नहीं होते हैं। TON ब्लॉकचेन में सभी लगातार डेटा (TVM कोड सहित) TVM कोशिकाओं (cf. [1, 2.5.14]) के एक सेट के रूप में प्रस्तुत किया जाता है। - TON वर्चुअल मशीन विवरण ( https://test.ton.org/tvm.pdf ) के अंश

मैंने जो पढ़ा है, उसके आधार पर क्या निष्कर्ष निकाला जा सकता है?

1. आप कार्रवाई को ट्रिगर करने के लिए अनुबंध पर बाहरी संदेश भेज सकते हैं।
2. हमलों - उदाहरण के लिए, हमलों को फिर से खेलना है
3. रिप्ले हमलों से बचाने के लिए यह सेक्नो विधि बनाने के लायक है।
4. Dns रिसोल्वर में dnsresolve विधि है
5. आप हमलों से बचाने के लिए बाहरी संदेशों की हैश स्टोर कर सकते हैं, लेकिन आपको उन्हें समय पर हटाने की आवश्यकता है, इसके लिए बाहरी संदेशों के लिए समय सीमा समाप्त हो गई है।
6. गैर-वापसी संदेश केवल अनुबंध बनाने के लिए आवश्यक हैं, अन्यथा, सभी आंतरिक संदेश वापस आ जाते हैं
7. अनुरोध-प्रतिक्रिया संदेशों में निम्नलिखित फ़ील्ड शामिल होने चाहिए: op, query_id - वैकल्पिक, और कुछ और op के मूल्य के आधार पर
8. आप लोगों के लिए UTF-8 प्रारूप में पाठ टिप्पणियां और तीसरे पक्ष के सॉफ़्टवेयर द्वारा स्वचालित पढ़ने और प्रसंस्करण के लिए "द्विआधारी टिप्पणियां" संलग्न कर सकते हैं।
9. अपवादों को संभालना और इसे समझदारी से पूरा करना
10. "टिप्पणियों के बिना सरल संदेश" - एक खाली शरीर होना चाहिए
11. अनुरोध-प्रतिक्रिया संदेशों के उच्च-क्रम बिट अनुरोध संदेशों के लिए 0 का मान लेता है, और प्रतिक्रिया संदेशों के लिए 1 का मान
12. त्रुटियों की पहचान करने के लिए प्रतिक्रिया संदेशों के लिए मानक op मान हैं
13. यदि किसी अज्ञात ऑप के साथ प्रतिक्रिया संदेश प्राप्त होता है, तो इसे अनदेखा किया जाना चाहिए, अर्थात कोड 0 के साथ पूर्ण निष्पादन
14. आपको संदेश भेजने के लिए, गैस के लिए और प्रतिक्रिया भेजने के लिए भुगतान करना होगा। उसी समय, यदि उसने आवश्यकता से अधिक भेजा, तो उत्तर में अतिरिक्त वापस आ जाएगा।
15. संदेश प्राप्त करते समय, पहले बाउंस किए गए झंडे की जांच करना हमेशा योग्य होता है ।

आपका ध्यान के लिए धन्यवाद, मुझे रचनात्मक प्रतिक्रिया के लिए खुशी होगी!