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

المصدر: Mario Kan Web3

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

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

يمكن أن يكون الأمر على هذا النحو يمكن القول أن الغرض من جميع اختيارات التكنولوجيا المعقدة في TON يأتي من السعي وراء التزامن العالي وقابلية التوسع العالية، بالطبع، ليس من الصعب فهم ذلك من خلفية ولادته. TON، أو The Open Network، هي شبكة حوسبة لا مركزية تتضمن 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، فمن الطبيعي أن نواجه مشكلتين، الطلبات المتزامنة العالية والبيانات الضخمة ونحن نعلم ذلك مع تطور التكنولوجيا حتى الوقت الحاضر، فإن Solana، الذي يُقال إنه يتمتع بأعلى TPS، لديه حد أقصى مُقاس لـ TPS يبلغ 65000 فقط، وهو ما لا يكفي بوضوح لدعم نظام Telegram البيئي الذي يتطلب ملايين TPS. في الوقت نفسه، مع تطبيق Telegram على نطاق واسع، تجاوزت كمية البيانات التي يولدها السماء بالفعل، باعتبارها نظامًا موزعًا زائدًا عن الحاجة، تتطلب blockchain من كل عقدة في الشبكة حفظ نسخة كاملة من البيانات غير واقعي أيضا.

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

• من خلال اعتماد نظام التصميم "Infinite Sharding Paradigm" (نموذج المشاركة اللانهائية)، تم حل مشكلة تكرار البيانات ويمكن تحميل البيانات الضخمة ، مع تخفيف اختناقات الأداء؛

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

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

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

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

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

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

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

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

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

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

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

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

لنفترض أن الحساب A في سلسلة العمل 1 يريد إرسال رسالة إلى الحساب C في سلسلة العمل 3. ثم تحتاج إلى تصميم مشكلة توجيه الرسائل. في هذا المثال، هناك مساران للتوجيه، سلسلة العمل 1 -> سلسلة العمل 3 -> 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، أي أن أي صاحب مصلحة لديه الفرصة للمشاركة في انتخاب الكتلة عقد الحوكمة بين الحين والآخر، سيتم اختيار مجموعة أدوات التحقق من الصحة بشكل عشوائي من جميع Stakers، وسيتم تجميع العقدة المحددة، التي تسمى أداة التحقق، لإنتاج كتل من خلال خوارزمية BFT سيتم مصادرة الرموز المميزة، وإلا سوف تحصل على مكافأة الكتلة. هذا خيار شائع في الأساس، لذا لن أعرضه هنا.

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

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

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

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

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

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

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

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

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

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

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

1. المكالمات غير المتزامنة بين العقود الذكية: لا يمكن استدعاء العقود الخارجية بشكل تلقائي أو الوصول إلى بيانات العقود الخارجية ضمن عقود TON الذكية الوظيفة 2 من العقد B في الوظيفة 1 من العقد A، أو الوصول إلى بيانات حالة معينة من خلال وظيفة القراءة فقط 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 < msg2_lt، فإن tx1_lt < tx2_lt.

ومع ذلك، في المواقف الأكثر تعقيدًا، سيتم كسر هذه القاعدة. يوجد مثال على ذلك في الوثائق الرسمية، على افتراض أن لدينا ثلاثة عقود أ، ب، ج. في إحدى المعاملات، يرسل 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، جميع عناوين المحفظة الموجودة هي عقود ذكية، ولكن لم تتم تهيئتها، وما إلى ذلك. يحتاج المطورون إلى الاهتمام بها بعناية.

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