من المخاطر إلى الحماية: المخاطر الأمنية واقتراحات التحسين لعقود TON الذكية

المصدر: Beosin

مع التطور السريع لتقنية blockchain اليوم، تحظى TON (الشبكة المفتوحة)، باعتبارها منصة blockchain فعالة ومرنة، بمزيد من الاهتمام باهتمامات المطورين. توفر بنية وميزات TON الفريدة أدوات قوية وإمكانيات غنية لتطوير التطبيقات اللامركزية.

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

ستحلل هذه المقالة بالتفصيل بعض الميزات المتعلقة بالعقود الذكية على TON blockchain، بالإضافة إلى نقاط الضعف التي يتم التغاضي عنها بسهولة في العقود الذكية على TON.

عدد كبير من الميزات غير المتزامنة وتحليل آلية الحساب

مكالمة غير متزامنة للعقد الذكي

تقسيم الشبكة والاتصالات غير المتزامنة

تنقسم سلسلة TON blockchain إلى ثلاث سلاسل في التصميم: سلسلة السلسلة الرئيسية ( Masterchain)، سلاسل العمل (Workingchains) وShardchains (Shardchains).

السلسلة الرئيسية هي جوهر الشبكة بأكملها وهي مسؤولة عن تخزين البيانات التعريفية وآلية الإجماع للشبكة بأكملها. فهو يسجل حالة جميع سلاسل العمل وسلاسل الأجزاء ويضمن اتساق وأمن الشبكة بأكملها. سلسلة العمل عبارة عن blockchain مستقل، مع ما يصل إلى 2 ^ 32 كتلة، مسؤولة عن معالجة أنواع محددة من المعاملات والعقود الذكية. يمكن أن يكون لكل سلسلة عمل قواعدها وخصائصها الخاصة لتلبية احتياجات التطبيقات المختلفة. سلاسل المشاركة هي سلاسل فرعية من سلسلة العمل، تُستخدم لتقسيم حمل سلسلة العمل بشكل أكبر وتحسين قدرات المعالجة وقابلية التوسع. يمكن تقسيم كل سلسلة عمل إلى ما يصل إلى 2^60 سلسلة جزء، وتقوم سلاسل الجزء بمعالجة بعض المعاملات بشكل مستقل، وبالتالي تحقيق معالجة متوازية فعالة.

من الناحية النظرية، يمكن لكل حساب أن يشغل سلسلة شظية حصريًا، ويحتفظ كل حساب بشكل مستقل برصيد العملة/الرمز المميز الخاص به، ويمكن أن تكون المعاملات بين كل حساب متوازية تمامًا. يتم إرسال الحسابات من خلال رسائل غير متزامنة. مسار الرسائل المرسلة بين سلاسل الأجزاء هو log_16(N) - 1، حيث N هو عدد سلاسل الأجزاء.

مصدر الصورة: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574 في عالم web3

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

تنسيق الرسالة وبنيتها

في Ton، تتضمن الرسائل عادةً المرسل والمستلم والمبلغ ونص الرسالة ومعلومات أخرى. يمكن أن يكون نص الرسالة عبارة عن استدعاء دالة أو نقل بيانات أو أي محتوى مخصص آخر. يمكن تعريف تنسيق الرسالة الذي يستخدمه Ton وتوسيعه بمرونة، مما يسمح بنقل أنواع مختلفة من المعلومات بكفاءة بين العقود المختلفة.

الرسالة معالجة قائمة الانتظار والحالة

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

مزايا المراسلة غير المتزامنة

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

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

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

تحديات تصميم العقد غير المتزامن

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

• ظروف السباق والحماية: تؤدي معالجة الرسائل غير المتزامنة إلى حدوث مشكلات محتملة في حالة السباق، وقد تحاول رسائل متعددة تعديل حالة العقد في نفس الوقت. يحتاج المطورون إلى تقديم آليات قفل مناسبة أو استخدام عمليات المعاملات لمنع تعارضات الحالة.

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

نموذج دفتر الأستاذ

يستخدم Ton (الشبكة المفتوحة) حسابًا فريدًا عند تصميم البنية التحتية لـ blockchain ونماذج التجريد ودفتر الأستاذ. تنعكس مرونة هذا النموذج في كيفية تعامله مع حالة الحساب والرسائل وتنفيذ العقد.

تجريد الحساب

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

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

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

هيكل دفتر الأستاذ

تم تصميم هيكل دفتر الأستاذ الخاص بـ Ton للتعامل بكفاءة مع المعاملات المتزامنة واسعة النطاق ويدعم المراسلة غير المتزامنة والعمليات متعددة الأجزاء. يتم تخزين حالة كل حساب في بنية شجرة Merkle، والتي تمكن دفتر حسابات Ton من التمتع بقدرات فعالة للتحقق من الحالة.

تخزين الحالة

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

عادةً ما تحتوي حالة الحساب أو العقد الذكي على ما يلي:

1. رصيد العملة الأساسية

2. رصيد العملات الأخرى

3. رمز العقد الذكي (أو تجزئة العقد الخاص به)

4. البيانات الثابتة للعقد الذكي (أو تجزئة Merkle الخاصة به)

5 وحدات التخزين المستمرة إحصائيات العدد الأولي للبايتات

6. آخر مرة تم فيها الدفع بواسطة العقد الذكي (في الواقع رقم كتلة السلسلة الرئيسية)

7 وأرسل من هذا الحساب المفتاح العام المطلوب للرسالة (اختياري؛ الافتراضي هو account_id نفسه). في بعض الحالات، على غرار ما يتم فعله مع مخرجات معاملات Bitcoin، يمكن العثور على رمز أكثر تعقيدًا للتحقق من التوقيع هنا؛ وسيكون account_id مساويًا لتجزئة هذا الرمز.

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

تمرير الرسائل ومعالجتها

تحتوي بنية دفتر الأستاذ في Ton على دعم مدمج للمراسلة غير المتزامنة، ويمكن لكل حساب معالجة الرسائل المستلمة وتحديث حالتها بشكل مستقل. تتيح آلية المراسلة غير المتزامنة هذه تفاعلات معقدة بين الحسابات دون التأثير على التشغيل العادي للحسابات الأخرى بسبب التأخير في عملية واحدة.

نموذج الغاز

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

قياس استهلاك الغاز المكرر

يمكن لنموذج Ton's Gas قياس موارد الحوسبة وعمليات التخزين وتكاليف تسليم الرسائل التي تستهلكها العقود الذكية أثناء التنفيذ بدقة. من خلال القياس الدقيق للموارد مثل الحوسبة والتخزين والمراسلة، يمكن لنموذج Ton's Gas منع بعض العمليات المعقدة للغاية من استهلاك الكثير من الموارد. من خلال الحد من استهلاك الغاز، يضمن Ton أن كل عقدة في الشبكة يمكنها تخصيص موارد الحوسبة بشكل عادل وتجنب الاستهلاك المفرط لموارد الشبكة من خلال عقد أو عملية واحدة.

المعالجة المتوازية وتحسين الغاز

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

آلية ضبط الغاز الديناميكي

يتضمن نموذج Ton's Gas آلية ضبط ديناميكية تسمح بتعديل رسوم الغاز بناءً على الحمل الفعلي للشبكة. وهذا يعني أنه عندما يكون حمل الشبكة منخفضًا، يمكن للمستخدمين تنفيذ العقود برسوم غاز أقل، وبالتالي تشجيع العمليات خلال فترات التحميل المنخفضة وتحقيق التوازن في استخدام موارد الشبكة. لا تعمل هذه الآلية على تحسين تجربة المستخدم فحسب، بل تتحكم أيضًا في الاستخدام الأقصى للموارد من خلال نهج موجه نحو السوق.

من السهل تجاهل العديد من العقود الذكية لنقاط الضعف

في تناولت مقالة تحليل أمان TON السابقة تفاصيل الثغرات الأمنية العامة لنظام Ton البيئي. يمكنك أيضًا الرجوع إلى الجدول التالي: p>

ستركز هذه المقالة على نقاط الضعف التي يتم التغاضي عنها بسهولة في عقد TON والتي لخصها فريقنا:

(1) تحسين إمكانية قراءة التعليمات البرمجية

< p>في العقود الذكية لـ TON، يتم استخدام الأرقام لتخزين البيانات ذات الصلة المرسلة عبر الرسائل، على سبيل المثال، في الكود التالي، يتم استخدام الأرقام عدة مرات لتمثيل التعريف المقابل وطول تخزين البيانات، مما يقلل بشكل كبير من سهولة القراءة وطول تخزين البيانات. قابلية الصيانة. عندما يقرأ المطورون الآخرون هذا الرمز، يكون من الصعب فهم معنى هذه الأرقام والغرض منها. من أجل تحسين إمكانية قراءة التعليمات البرمجية وصيانتها، يوصى بتحديد القيم الرقمية الرئيسية كثوابت مسماة، على سبيل المثال: تم تعريف 0x18 على أنها NON_BOUNCEABLE.

check_std_addr(address);var msg = begin_cell()   store_uint(0x18, 6) ; nobounce   store_slice( العنوان)   store_coins(amount)   store_uint(0, 1 + 4 + 4 + 64 + 32 + 1  ;+ 1)   end_cell();send_raw_message(msg, 1);

بالإضافة إلى ذلك، يوصى أيضًا بتحديد المتغيرات المقابلة لرسالة الخطأ في العقد شروط الحكم استبدال رمز الخطأ.

(2) الاستخدام تضمن end_parse() سلامة البيانات

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

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

(3) الاستثناءات الناتجة عن عدم التطابق بين سجلات البيانات وأنواع التخزين

الشيء الرئيسي الذي يجب ملاحظته هنا هو أن أنواع الوصول int وuint متطابقة في الكود الموضح أدناه، عند تخزين البيانات، يتم استخدام store_int() لتخزين قيمة النوع int كـ -42، ولكن يتم استخدامload_uint() لتحميل هذه القيمة.

(4)inline_ref والاستخدام المعقول للمعدلات المضمنة

أولاً وقبل كل شيء، من الضروري توضيح الفرق بين inline_ref والمعدلات المضمنة:

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

linline_ref: دالة تستخدم مُعدِّل inline_ref، ويتم تخزين كودها في خلية منفصلة. في كل مرة يتم فيها استدعاء وظيفة، يقوم TVM بتنفيذ التعليمات البرمجية المخزنة في الخلية من خلال أمر CALLREF بدلاً من إدخال رمز الوظيفة في موقع الاتصال.

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

(5) تحديد سلسلة العمل الصحيحة

يسمح TON بإنشاء ما يصل إلى 2^32 سلسلة عمل، ويمكن تقسيم كل سلسلة عمل إلى ما يصل إلى 2^60 نقطة هناك. هناك سلسلتين عمل فقط قبل الشريحة: السلسلة الرئيسية (-1) والسلسلة الأساسية (0). عند حساب العنوان الهدف في العقد، يجب تحديد معرف السلسلة الذي ينتمي إليه العنوان الهدف بوضوح للتأكد من أن عنوان المحفظة الذي تم إنشاؤه موجود في سلسلة العمل الصحيحة. لتجنب إنشاء عناوين خاطئة، يوصى باستخدام force_chain() لفرض تحديد معرف السلسلة.

(6) تجنب تعارض رموز الأخطاء

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

(7) بعد اكتمال العملية، تحتاج إلى تخزين البيانات وإرجاع الاتصال ()

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

() recv_internal(int my_balance, int msg_value, cell in_msg_full,lice in_msg_body) غير نقي {int flags = cs~load_uint(4); code>if (flags & 1) { ;; تجاهل جميع الرسائل المرتدة return (); slice sender_address = cs~load_msg_addr();load_data();int op = in_msg_body~load_op();if ((op == op::op_1())) {       ; return (); if ((op == op::op_2())) { Handle_op2();   save_data(); return (); if ((op == op::op_3() )) ) {     return (); throw(0xffff);

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

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