وصف تفصيلي للميزات التقنية لـ TON ونموذج تطوير العقود الذكية

المؤلف:@Web3Mario

المقدمة

مع إطلاق Binance لـ Notcoin، أكبر لعبة في نظام TON البيئي، و نظرًا لتأثير الثروة الهائل الناجم عن النموذج الاقتصادي للتداول المميز، فقد اجتذبت TON اهتمامًا كبيرًا في فترة قصيرة من الزمن. بعد الدردشة مع أحد الأصدقاء، علمت أن الحد التقني لـ TON مرتفع نسبيًا، وأن نموذج تطوير التطبيقات اللامركزية يختلف تمامًا عن بروتوكولات السلسلة العامة السائدة، لذلك قضيت بعض الوقت في إجراء بحث متعمق حول الموضوعات ذات الصلة وشاركت بعض الأفكار معك. باختصار، يتمثل مفهوم التصميم الأساسي لـ TON في إعادة بناء بروتوكول blockchain التقليدي بطريقة "من الأسفل إلى الأعلى" وتحقيق التزامن العالي وقابلية التوسع العالية على حساب قابلية التشغيل البيني.

فكرة التصميم الأساسية لـ TON - التزامن العالي وقابلية التوسع العالية

يمكن القول أن الغرض من جميع اختيارات التكنولوجيا المعقدة في TON هو إنه يأتي من السعي وراء التزامن العالي وقابلية التوسع العالية. بالطبع، ليس من الصعب علينا أن نفهم هذا من خلفية ولادته. TON، أو الشبكة المفتوحة، هي شبكة حوسبة لا مركزية تحتوي على blockchain L1 ومكونات متعددة. تم تطوير TON في الأصل بواسطة مؤسس Telegram نيكولاي دوروف وفريقه، ويتم دعمه وصيانته الآن من قبل مجتمع عالمي من المساهمين المستقلين. يعود تاريخ ميلادها إلى عام 2017، عندما بدأ فريق Telegram في استكشاف حلول blockchain لأنفسهم. نظرًا لعدم وجود blockchain L1 موجود في ذلك الوقت يمكنه دعم قاعدة مستخدمي Telegram المكونة من تسعة أرقام، فقد قرروا تصميم blockchain خاص بهم، ثم أطلقوا عليه اسم Telegram Open Network. حان الوقت لعام 2018. ومن أجل الحصول على الموارد اللازمة لتنفيذ TON، أطلقت Telegram بيع رموز Gram (التي أعيدت تسميتها لاحقًا باسم Toncoin) في الربع الأول من عام 2018. في عام 2020، انسحب فريق Telegram من مشروع TON بسبب مشكلات تنظيمية. بعد ذلك، استحوذت مجموعة صغيرة من مطوري المصادر المفتوحة والفائزين في مسابقة Telegram على قاعدة كود TON، وأعادوا تسمية المشروع إلى The Open Network، واستمروا في تطوير blockchain بنشاط حتى يومنا هذا، مع الالتزام بالمبادئ الموضحة في ورقة TON البيضاء الأصلية.

نظرًا لأن هدف التصميم هو العمل كبيئة تنفيذ لامركزية لـ Telegram، فمن الطبيعي أن نواجه مشكلتين، الطلبات المتزامنة العالية والبيانات الضخمة، ونحن نعلم أنه مع تطور التكنولوجيا حتى الوقت الحاضر، أصبح الأمر معروفًا كأعلى TPS أعلى TPS تم قياسه لـ Solana هو 65000 فقط، ومن الواضح أن هذا لا يكفي لدعم نظام Telegram البيئي الذي يتطلب ملايين TPS. في الوقت نفسه، مع تطبيق Telegram على نطاق واسع، تجاوزت كمية البيانات التي يولدها السماء بالفعل، باعتبارها نظامًا موزعًا زائدًا عن الحاجة، تتطلب blockchain من كل عقدة في الشبكة حفظ نسخة كاملة من البيانات غير واقعي أيضا.

لذلك، من أجل حل المشكلتين المذكورتين أعلاه، أجرت TON تحسينين لبروتوكولات blockchain السائدة:

• من خلال تصميم النظام باستخدام "نموذج المشاركة اللانهائية"، قمنا بحل مشكلة تكرار البيانات بحيث يمكنه حمل بيانات كبيرة وتخفيف مشكلة اختناق الأداء؛

• من خلال تقديم بيئة تنفيذ متوازية تمامًا تعتمد على نموذج الممثل، وتم تحسين TPS للشبكة بشكل كبير؛

بناء سلسلة blockchain - من خلال نقاط غير محدودة تسمح إمكانية المشاركة لكل حساب بالحصول على سلسلة حسابات حصرية

نحن نعلم الآن أن التقسيم أصبح حلاً رئيسيًا لمعظم بروتوكولات blockchain لتحسين الأداء وخفض التكاليف، وقد أخذت TON هذا إلى أقصى الحدود واقترحت نموذج تقسيم لا نهائي. يشير ما يسمى بنموذج التجزئة اللانهائي إلى السماح لـ blockchain بزيادة أو تقليل عدد الأجزاء ديناميكيًا وفقًا لتحميل الشبكة. يمكّن هذا النموذج TON من التعامل مع المعاملات واسعة النطاق وعمليات العقود الذكية مع الحفاظ على الأداء العالي، من الناحية النظرية، يمكن لـ TON إنشاء سلسلة حسابات حصرية لكل حساب وضمان قابلية التشغيل البيني بين هذه السلاسل من خلال قواعد معينة،

• سلسلة الحساب: تمثل سلسلة الطبقة هذه تتكون السلسلة من سلسلة من المعاملات المتعلقة بالحساب، والسبب في أن المعاملات يمكن أن تشكل بنية سلسلة هو أنه بالنسبة لآلة الحالة، طالما أن قواعد التنفيذ متسقة، فإن النتائج التي تحصل عليها آلة الحالة بعد تلقي نفس التسلسل. التعليمات متسقة، لذا فإن الترتيب المتسلسل للمعاملات مطلوب في جميع أنظمة blockchain الموزعة، وTON ليس استثناءً. سلسلة الحساب هي الوحدة المكونة الأساسية في شبكة TON عادةً ما تكون سلسلة الحساب مفهومًا افتراضيًا، ومن غير المحتمل وجود سلسلة حساب مستقلة بالفعل.

• ShardChain: في معظم السياقات بعد ذلك، سلسلة الجزء هي الفعلية الوحدة المكونة في TON ما يسمى بسلسلة Shard هي عبارة عن مجموعة من سلاسل الحسابات.

• WorkChain: يمكن أن يطلق عليها أيضًا مجموعة من قواعد التعريف لـ سلاسل التقسيم، مثل إنشاء سلسلة عمل قائمة على EVM وتشغيل عقود Solidity الذكية عليها. من الناحية النظرية، يمكن لكل فرد في المجتمع إنشاء سلسلة عمل خاصة به. في الواقع، يعد بنائها مهمة معقدة إلى حد ما، يسبقها دفع الرسوم (الباهظة الثمن) لإنشائها والحصول على ثلثي أصوات المصادقين للموافقة على إنشاء سلسلة العمل الخاصة بك.

• السلسلة الرئيسية (MasterChain): أخيرًا، هناك سلسلة خاصة في TON تسمى السلسلة بالسلسلة الرئيسية وهي مسؤولة عن تحقيق النهاية لجميع سلاسل القطع. بمجرد دمج تجزئة كتلة سلسلة الجزء في كتلة السلسلة الرئيسية، تعتبر كتلة سلسلة الجزء هذه وجميع الكتل الأصلية نهائية، مما يعني أنه يمكن اعتبارها ثابتة وغير قابلة للكسر. تتم الإشارة إلى المحتوى المتغير بواسطة الكتل اللاحقة لجميع الأجزاء السلاسل.

من خلال اعتماد مثل هذا النموذج، تتمتع شبكة TON بالخصائص الثلاث التالية:

• < p>المشاركة الديناميكية: يمكن لـ TON تقسيم سلاسل الأجزاء ودمجها تلقائيًا للتكيف مع التغييرات في التحميل. وهذا يعني أنه يتم دائمًا إنشاء الكتل الجديدة بسرعة ولا تتطلب المعاملات أوقات انتظار طويلة.

• قابلة للتطوير بشكل كبير:من خلال نموذج التجزئة اللانهائي، تستطيع TON الدعم يمكن لعدد غير محدود تقريبًا من القطع أن يصل نظريًا إلى 2 إلى القوة 60 لسلاسل العمل.

• القدرة على التكيف: عندما يزيد الحمل على جزء معين من الشبكة يمكن تقسيم هذا الجزء إلى أجزاء أكثر للتعامل مع حجم المعاملات المتزايد. وعلى العكس من ذلك، عندما ينخفض ​​الحمل، يمكن دمج الأجزاء لزيادة الكفاءة.

أول ما يجب على مثل هذا النظام متعدد السلاسل مواجهته هو مشكلة الاتصال عبر السلاسل، خاصة بسبب قدرة التجزئة غير المحدودة عندما يكون عدد تصل الشظايا في الشبكة بعد مستوى معين، سيصبح توجيه المعلومات بين السلاسل أمرًا صعبًا. تخيل أن هناك 4 عقد في الشبكة، كل عقدة مسؤولة عن الحفاظ على سلسلة عمل مستقلة، وتشير علاقة الارتباط إلى أنه بالإضافة إلى كونها مسؤولة عن فرز المعاملات في سلسلة العمل الخاصة بها، تحتاج العقدة أيضًا إلى مراقبة الحالة ومعالجتها. التغييرات في السلسلة المستهدفة، والتي يتم تنفيذها خصيصًا في TON من خلال مراقبة الرسائل في قائمة انتظار الإخراج،

لنفترض أن الحساب A في سلسلة العمل 1 يريد إرسال رسالة إلى الحساب C في سلسلة العمل 3. تحتاج إلى تصميم مشكلة توجيه الرسالة، في هذا المثال، هناك مساران للتوجيه، سلسلة العمل 1 -> سلسلة العمل 3 -> .

عند مواجهة مواقف أكثر تعقيدًا، تكون هناك حاجة إلى خوارزمية توجيه فعالة ومنخفضة التكلفة لإكمال اتصال الرسائل بسرعة. اختارت TON ما يسمى بـ "خوارزمية توجيه المكعب الفائق" لتحقيق اكتشاف مسار اتصالات الرسائل عبر السلسلة . يشير ما يسمى ببنية المكعب الفائق إلى طوبولوجيا شبكة خاصة، ويتكون المكعب الفائق ذو الأبعاد n من رؤوس 2^n، ويمكن تحديد كل قمة بشكل فريد من خلال رقم ثنائي مكون من n بت. في هذه البنية، يكون أي رأسين متجاورين إذا كانا يختلفان بمقدار بت واحد فقط في التمثيل الثنائي. على سبيل المثال، في المكعب الفائق ثلاثي الأبعاد، يكون الرأس 000 والرأس 001 متجاورين لأنهما يختلفان فقط في البت الأخير. المثال أعلاه هو مكعب فائق ثنائي الأبعاد.

في في بروتوكول توجيه المكعب الفائق، يتم تنفيذ عملية توجيه الرسالة من سلسلة عمل المصدر إلى سلسلة عمل مستهدفة من خلال مقارنة التمثيلات الثنائية لعناوين سلسلة عمل المصدر وسلسلة العمل المستهدفة. تعثر خوارزمية التوجيه على الحد الأدنى للمسافة (أي عدد البتات المختلفة في التمثيل الثنائي) بين هذين العنوانين وتقوم بإعادة توجيه المعلومات تدريجيًا عبر سلاسل العمل المجاورة حتى يتم الوصول إلى سلسلة العمل المستهدفة. تضمن هذه الطريقة نقل حزم البيانات عبر أقصر مسار، وبالتالي تحسين كفاءة الاتصال بالشبكة.

بالطبع، من أجل تبسيط هذه العملية، اقترحت TON أيضًا حلاً تقنيًا متفائلًا عندما يتمكن المستخدم من تقديم دليل صالح لمسار توجيه معين، والذي عادةً ما يكون عبارة عن جذر Merkle trie، والعقدة. يمكن التعرف عليها مباشرة من خلال موثوقية الرسائل المقدمة من قبل المستخدم، والتي تُعرف أيضًا باسم توجيه المكعب الفائق الفوري.

لذلك يمكننا أن نرى أن هناك اختلافات واضحة بين العناوين في TON وبروتوكولات blockchain الأخرى. تستخدم معظم بروتوكولات blockchain السائدة الأخرى التجزئة المقابلة للمفتاح العام في المفاتيح العامة والخاصة الناتجة عن التشفير البيضاوي الخوارزمية كعنوان، لأن العنوان مخصص فقط للتمييز الفريد ولا يحتاج إلى حمل وظيفة التوجيه والعنونة. يتكون العنوان في TON من جزأين، (workchain_id، account_id)، حيث يتم تشفير Workchain_id وفقًا لتوجيه المكعب الفائق. عنوان الخوارزمية هنا لن أخوض في التفاصيل.

هناك نقطة أخرى من السهل أن تثير الشكوك ربما لاحظت أن السلسلة الرئيسية وكل سلسلة عمل لها علاقة ارتباط، لذا ألا يكفي أن تكون جميع المعلومات عبر السلسلة موجودة. يتم ترحيلها من خلال السلسلة الرئيسية، تماما مثل الكون؟ في مفهوم تصميم TON، يتم استخدام السلسلة الرئيسية فقط للتعامل مع المهام الأكثر أهمية، أي الحفاظ على نهائية العديد من سلاسل العمل. ليس من المستحيل توجيه الرسائل عبر السلسلة الرئيسية، ولكن رسوم المعالجة الناتجة ستكون باهظة الثمن .

أخيرًا، دعنا نذكر بإيجاز خوارزمية الإجماع الخاصة بها. تتبنى TON طريقة BFT+PoS، أي أن أي صاحب مصلحة لديه الفرصة للمشاركة في عقد إدارة الانتخابات الخاص بـ TON، وسيقوم بالاختيار من بين جميع أصحاب المصلحة على فترات منتظمة قم باختيار مجموعة أدوات التحقق المعبأة بشكل عشوائي، وستقوم العقدة المحددة المسماة أداة التحقق بحزم الكتلة من خلال خوارزمية BFT. إذا كانت الحزمة تحتوي على معلومات خاطئة أو تقوم بأعمال شريرة، فسيتم مصادرة الرمز المميز الخاص بها، وإلا فإنها ستتلقى مكافأة الكتلة. هذا خيار شائع في الأساس، لذا لن أعرضه هنا.

العقود الذكية وبيئة التنفيذ المتوازية تمامًا استنادًا إلى نموذج الممثل

هناك اختلاف آخر بين TON وبروتوكولات blockchain السائدة وهو بيئة تنفيذ العقود الذكية. من أجل اختراق قيود بروتوكول blockchain السائد TPS، اعتمدت TON فكرة تصميم من أسفل إلى أعلى واستخدمت نموذج Actor لإعادة بناء العقود الذكية وطرق تنفيذها، مما يمنحها القدرة على التوازي بشكل كامل.

نحن نعلم أن معظم بروتوكولات blockchain السائدة تستخدم بيئة تنفيذ تسلسلية أحادية الخيط. وبأخذ Ethereum كمثال، فإن بيئة التنفيذ الخاصة بها EVM هي آلة حالة يتم فيها إجراء المعاملات كمدخلات عند عقدة إنتاج الكتلة يتم فرزها حسب كتل التعبئة، وسيتم تنفيذ المعاملات من خلال EVM بهذا الترتيب. العملية بأكملها تسلسلية بالكامل وذات خيط واحد، أي أنه يمكن تنفيذ معاملة واحدة فقط في وقت معين طالما تم التأكد من أن تسلسل المعاملة ونتائج التنفيذ متسقان في نطاق واسع من المجموعات الموزعة في نفس الوقت، نظرًا لأنه يتم تنفيذ معاملة واحدة فقط بشكل تسلسلي في نفس الوقت، فهذا يعني أنه لا يمكن أن تكون هناك معاملة أخرى أثناء عملية التنفيذ. المعاملات التي تحتاج إلى الوصول إليها يتم تعديل بيانات الحالة، وبالتالي تحقيق قابلية التشغيل البيني بين العقود الذكية. على سبيل المثال، نستخدم USDT لشراء ETH من خلال Uniswap. عند تنفيذ المعاملة، يكون توزيع LP في زوج التداول بقيمة معينة، وبهذه الطريقة، يمكن الحصول على النتيجة المقابلة من خلال نماذج رياضية معينة، ولكن بافتراض ذلك ليس هذا هو الحال، عند إجراء حساب منحنى ربط معين، إذا أضافت LPs الأخرى سيولة جديدة، فإن نتيجة الحساب ستكون نتيجة قديمة، وهو أمر غير مقبول بشكل واضح.

لكن هذه البنية أيضًا لها حدود واضحة، وهي عنق الزجاجة لـ TPS، ويبدو هذا عنق الزجاجة قديمًا جدًا في ظل المعالجات الحالية متعددة النواة، تمامًا مثلما تستخدم أحدث جهاز كمبيوتر للعب بعض الألعاب القديمة في ألعاب الكمبيوتر ، مثل Red Alert، عندما يصل عدد الوحدات القتالية إلى عدد معين، ستظل تجد أنها عالقة. هذه مشكلة في بنية البرنامج.

قد تسمع أن بعض البروتوكولات تهتم بالفعل بهذه المشكلة واقترحت حلولًا موازية خاصة بها. خذ Solana، الذي يدعي حاليًا أنه يتمتع بأعلى TPS، على سبيل المثال، فهو أيضًا لديه القدرة على ذلك تنفيذ بالتوازي. ومع ذلك، تختلف فكرة تصميمها عن TON، حيث تتمثل فكرتها الأساسية في تقسيم جميع المعاملات إلى عدة مجموعات وفقًا لتبعيات التنفيذ، ولا تتم مشاركة بيانات الحالة بين المجموعات المختلفة. أي أنه لا توجد تبعيات متطابقة، لذلك يمكن تنفيذ المعاملات في مجموعات مختلفة بالتوازي دون القلق بشأن التعارضات، في حين لا يزال يتم تنفيذ المعاملات داخل نفس المجموعة بالطريقة التسلسلية التقليدية.

في TON، يتخلى تمامًا عن بنية التنفيذ التسلسلي ويعتمد بدلاً من ذلك نموذج تطوير مصمم خصيصًا للتوازي، وهو نموذج الممثل، لإعادة بناء بيئة التنفيذ. تم اقتراح ما يسمى بنموذج الممثل لأول مرة بواسطة كارل هيويت في عام 1973 لحل تعقيد الحالة المشتركة في البرامج المتزامنة التقليدية من خلال تمرير الرسائل. يتمتع كل ممثل بحالته وسلوكه الخاص، ولا يشارك أي معلومات عن الحالة مع الممثلين الآخرين. نموذج الممثل هو نموذج حوسبة حاسوبية متزامنة ينفذ الحوسبة المتوازية من خلال تمرير الرسائل. في هذا النموذج، "الممثل" هو وحدة العمل الأساسية، القادر على معالجة الرسائل المستلمة، وإنشاء ممثلين جدد، وإرسال المزيد من الرسائل، وتحديد كيفية الرد على الرسائل اللاحقة. يجب أن يتمتع نموذج الممثل بالخصائص التالية:

• التغليف والاستقلال: يكون كل ممثل مستقلاً تمامًا عند معالجة الرسائل بالتوازي التدخل مع بعضها البعض.

• تمرير الرسائل: يتفاعل الممثلون مع بعضهم البعض فقط عن طريق إرسال واستقبال الرسائل، ويتم تمرير الرسائل بشكل غير متزامن .

• البنية الديناميكية: يمكن للممثل إنشاء المزيد من الممثلين في وقت التشغيل. هذه الطبيعة الديناميكية تجعل نماذج الممثل تمكن النظام ليتم توسيعها حسب الحاجة.

تعتمد TON هذه البنية لتصميم نماذج العقود الذكية، مما يعني أنه في TON، كل عقد ذكي هو نموذج ممثل مع تخزين مستقل تمامًا. لأنه لا يعتمد على أي بيانات خارجية. بالإضافة إلى ذلك، لا يزال يتم تنفيذ المكالمات لنفس العقد الذكي وفقًا لترتيب الرسائل في قائمة انتظار الاستلام، لذلك يمكن تنفيذ المعاملات في TON بكفاءة بالتوازي دون القلق بشأن التعارضات.

ومع ذلك، فإن خطة التصميم هذه تجلب أيضًا بعض التأثيرات الجديدة بالنسبة لمطوري التطبيقات اللامركزية، سيتم كسر نموذج التطوير المعتاد الخاص بهم، على النحو التالي:

1.< strong>المكالمات غير المتزامنة بين الأذكياء. العقود: لا يمكن استدعاء العقود الخارجية بشكل ذري أو الوصول إلى بيانات العقد الخارجية ضمن عقود TON الذكية، ونحن نعلم أنه في Solidity، يتم استدعاء العقد B في الوظيفة 1 للعقد A. الوظيفة 2، أو الوصول إلى بيانات حالة معينة من خلال وظيفة القراءة فقط 3 للعقد C. العملية بأكملها ذرية ويتم تنفيذها في معاملة واحدة، وهذا أمر سهل للغاية، ومع ذلك، في TON، لن يكون هذا ممكنًا المعاملات التي تبدأ بواسطة العقد الذكي تسمى أيضًا الرسائل الداخلية. ولا يمكن حظره أثناء التنفيذ للحصول على نتائج التنفيذ.

على سبيل المثال، إذا قمنا بتطوير DEX، وإذا اعتمدنا النموذج المشترك في EVM، فسيكون هناك عادةً عقد توجيه موحد لإدارة توجيه المعاملات، وسيقوم كل تجمع بشكل مستقل بإدارة بيانات LP المتعلقة بـ زوج تداول معين، ثم افترض أن هناك حاليًا مجموعتين USDT-DAI وDAI-ETH. عندما يريد المستخدم شراء ETH مباشرة من خلال USDT، يمكنه أن يطلب هاتين المجموعتين بالتسلسل في معاملة واحدة من خلال عقد جهاز التوجيه لإكمال المعاملة الذرية. ومع ذلك، ليس من السهل تنفيذه في TON. نحتاج إلى التفكير في نموذج تطوير جديد. إذا كنا لا نزال نعيد استخدام هذا النموذج، فقد يكون تدفق المعلومات على هذا النحو وتم إكمال ثلاث رسائل داخلية (لاحظ أن هذا يستخدم لتوضيح الفرق. في التطوير الحقيقي، حتى نموذج ERC20 يجب إعادة تصميمه).

2 .من الضروري النظر بعناية في عملية معالجة أخطاء التنفيذ عند الاتصال عبر العقود، وتصميم وظائف الارتداد المقابلة لكل مكالمة بين العقود. نحن نعلم أنه في نظام EVM السائد، عند مواجهة مشكلة أثناء تنفيذ المعاملة، سيتم إرجاع المعاملة بأكملها، أي إعادة التعيين إلى حالة التنفيذ الأولية. من السهل فهم ذلك في النموذج التسلسلي أحادي الخيط. ومع ذلك، في TON، نظرًا لأن الاستدعاءات بين العقود يتم تنفيذها بشكل غير متزامن، حتى في حالة حدوث خطأ في رابط لاحق، نظرًا لأن المعاملة التي تم تنفيذها بنجاح مسبقًا تم تنفيذها وتأكيدها بالفعل، فقد يتسبب ذلك في حدوث مشكلات. لذلك، يتم إعداد نوع رسالة خاص في TON، يسمى الرسالة المرتدة، أي أنه عند حدوث خطأ في عملية التنفيذ اللاحقة الناتجة عن رسالة داخلية، يمكن للعقد الذي تم تشغيله تشغيل رسالة معينة في العقد من خلال وظيفة الارتداد. محجوزة بواسطة عقد الزناد. بعض عمليات إعادة تعيين الحالة.

3 .في بعض المواقف المعقدة، قد لا يتم تنفيذ المعاملة التي تم استلامها أولاً أولاً، لذلك لا يمكن ضبط علاقة التوقيت هذه مسبقًا. في مثل هذا النظام من مكالمات العقود الذكية غير المتزامنة والمتوازية، قد يكون من الصعب تحديد الترتيب الذي تتم به معالجة العمليات. هذا هو السبب في أن كل رسالة في TON لها وقتها المنطقي وقت Lamport (المشار إليه فيما يلي باسم lt). يتم استخدامه لفهم الحدث الذي أدى إلى حدوث حدث آخر وما يحتاج المدقق إلى التعامل معه أولاً. بالنسبة للنموذج البسيط، يجب تنفيذ المعاملة المستلمة أولاً أولاً.

في في هذا النموذج، يمثل A وB عقدين ذكيين على التوالي، وتوجد علاقة توقيت بحيث إذا كانت msg1_lt <، فإن tx1_lt <

ومع ذلك، في المواقف الأكثر تعقيدًا، سيتم كسر هذه القاعدة. يوجد مثال على ذلك في الوثائق الرسمية لنفترض أن لدينا ثلاثة عقود A وB وC. في إحدى المعاملات، يرسل A رسالتين داخليتين msg1 وmsg2: واحدة إلى B والأخرى إلى C. على الرغم من أنها تم إنشاؤها بالترتيب الدقيق (msg1 أولاً، ثم msg2)، إلا أننا لا نستطيع التأكد من أن msg1 ستتم معالجتها قبل msg2. وذلك لأن المسارات من A إلى B ومن A إلى C قد تختلف في الطول ومجموعة أدوات التحقق. إذا كانت هذه العقود موجودة في سلاسل أجزاء مختلفة، فقد تستغرق إحدى الرسائل عدة كتل للوصول إلى العقد المستهدف. أي أن لدينا مسارين محتملين للتداول، كما هو موضح في الشكل.

4 .في TON، يستخدم التخزين المستمر لعقوده الذكية رسمًا بيانيًا حلقيًا موجهًا مع الخلية كوحدة كبنية البيانات، وسيتم ضغط البيانات بشكل مضغوط في خلية وفقًا لقواعد التشفير، وفي نفس الوقت وفقًا إلى الرسم البياني الحلقي الموجه. يمتد الرسم البياني إلى الأسفل. ويختلف هذا عن التنظيم الهيكلي لبيانات الحالة القائمة على التجزئة في EVM. نظرًا لاختلاف خوارزميات طلب البيانات، تحدد TON أسعارًا مختلفة للغاز لأعماق مختلفة من معالجة البيانات. كلما كانت الخلية أعمق، كلما زاد الغاز المطلوب لمعالجة البيانات، لذلك يوجد نموذج لهجوم DOS في TON، أي أن بعض المستخدمين الضارين يشغلون جميع الخلايا الضحلة في عقد ذكي عن طريق إرسال عدد كبير من رسائل البريد العشوائي، مما يعني أن تكاليف تخزين المستخدمين الصادقين سوف تصبح أعلى وأعلى. في EVM، نظرًا لأن تعقيد استعلام hashmap هو o(1)، فهو يحتوي على نفس الغاز ولن تكون هناك مشاكل مماثلة. لذلك، يجب على مطوري TON Dapp محاولة تجنب أنواع البيانات غير المحدودة في العقود الذكية. عندما تظهر أنواع البيانات غير المحدودة، يجب تقسيمها من خلال التقسيم.

5 .هناك أيضًا ميزات أقل خصوصية، مثلالعقود الذكية التي تتطلب دفع الإيجار للتخزين، والعقود الذكية القابلة للترقية بشكل طبيعي في TON، ووظيفة الحساب المجرد الأصلي، أي أن جميع عناوين المحفظة في TON هي عقود ذكيةلم تتم تهيئتها، وما إلى ذلك. وهذا يتطلب من المطورين الانتباه بعناية.