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

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

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

تحليل ميزات TON الغير متزامنة وآلية الحساب

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

تجزئة الشبكة والاتصال الغير متزامن

صُمّمت بلوكشين TON بثلاثة أنواع من السلاسل: سلسلة رئيسية، وسلاسل عاملة، وسلاسل قطاعة.

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

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

مصدر الصورة: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574في Ton، تتم المعاملات عن طريق إرسال واستقبال الرسائل. يمكن أن تكون هذه الرسائل داخلية (عادة ما يتم إرسالها من قبل العقود الذكية التي تتفاعل مع بعضها البعض) أو خارجية (مرسلة من مصادر خارجية). عملية إرسال الرسائل لا تتطلب استجابات فورية من العقد المستهدف، مما يسمح للمرسل بمواصلة تنفيذ المنطق المتبقي. يوفر هذا الآلية الغير متزامنة للرسائل مرونة وقابلية توسع أكبر مقارنة بالمكالمات المتزامنة في Ethereum، مما يقلل من قيود الأداء الناتجة عن الانتظار للردود، في حين يتطلب التعامل مع التزامن وظروف السباق التحديات.

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

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

طابور الرسائل ومعالجة الحالة

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

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

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

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

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

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

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

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

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

نموذج الدفتر

TON (The Open Network) يستخدم تجربة حساب فريدة ونموذج دفتر الأستاذ في تصميم بنيته التحتية للبلوكشين. تتجلى مرونة هذا النموذج في كيفية إدارته حالات الحسابات وتمرير الرسائل وتنفيذ العقود.

تجريد الحساب

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

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

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

هيكل الدفتر

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

تخزين الحالة

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

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

1. رصيد العملة الأساسية 2. رصيد العملات الأخرى 3. رمز العقد الذكي (أو تجزئته) 4. البيانات المستمرة للعقد الذكي (أو تجزئة Merkle الخاصة به) 5. إحصائيات عن عدد وحدات التخزين الثابتة واستخدام البايت الخام 6. الطابع الزمني الأخير للمدفوعات إلى التخزين المستمر للعقد الذكي (بشكل أساسي رقم كتلة السلسلة الرئيسية) 7. المفتاح العام المطلوب لتحويل العملة وإرسال الرسائل من هذا الحساب (اختياري ؛ افتراضيا ، هذا يساوي account_id نفسه). في بعض الحالات ، يمكن العثور على رموز فحص توقيع أكثر تعقيدا هنا ، على غرار مخرجات معاملات Bitcoin ؛ في مثل هذه الحالات ، سيكون account_id تجزئة هذا الرمز.

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

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

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

نموذج الغاز

TON (The Open Network) تحسن بشكل كبير كفاءة تنفيذ العقود الذكية من خلال نموذج رسوم الغاز الفريد الخاص به. يُستخدم هذا النموذج لقياس وتحديد الموارد المستهلكة أثناء تنفيذ العقد الذكي. بالمقارنة مع سلاسل الكتل التقليدية مثل إيثريوم، فإن نموذج TON أكثر تعقيدًا وكفاءة، مما يسمح بإدارة أكثر دقة لاستهلاك الموارد أثناء تنفيذ العقد.

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

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

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

سهل تجاهل الثغرات في العقود الذكية TON

فيمقالنا السابق لتحليل الأمانفي TON ، قمنا بتفصيل الثغرات الأمنية الشائعة داخل بيئة TON. للمزيد من المراجعة ، يرجى الرجوع إلى الجدول أدناه:

سيتركز هذا المقال على الثغرات في عقود TON التي غالبًا ما يتم تجاهلها، كما تم تلخيصها من قبل فريقنا:

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

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

1. تحقق_std_addr(address)؛ كان msg = begin_cell() store_uint(0x18، 6) ؛ ؛ nobounce store_slice(address) store_coins(amount) store_uint(0، 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell()؛ send_raw_message(msg، 1)؛

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

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

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

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

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

هذا يتعلق بشكل رئيسي بالتوافق بين المتغيرات و uintأنواع التخزين. على سبيل المثال، في الشفرة التالية،store_int()تستخدم الوظيفة لتخزين intقيمة-42، ولكنload_uint() لتحميل هذه القيمة، مما قد يؤدي إلى استثناء.

(4) الاستخدام السليم لـinline_refوفي الخطالمعدلون

أولا، من المهم التمييز بين مضمنهوinline_ref معدلات:

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

inline_ref: الوظائف معinline_refيحفظ المعدل مدونته في خلية منفصلة. في كل مرة يتم استدعاء الوظيفة ، يقوم TVM بتنفيذ الرمز المخزن في الخلية عبر الـCALLREFالأمر، تجنب تكرار الشفرة وتحسين الكفاءة للوظائف المعقدة أكثر أو تلك التي تتم استدعاؤها عدة مرات.

في الختام، استخدمinlineللوظائف البسيطة لتقليل العبء النداء ، ولكن كن على دراية بتكرار الشفرة المحتملة. استخدمinline_refلتحسين الكفاءة وتجنب تكرار الشفرة للوظائف الكبيرة أو المستدعاة بشكل متكرر.

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

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

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

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

(7) تخزين البيانات والاستدعاءreturn() بعد اكتمال العملية

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

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {

int flags = cs~load_uint(4);

إذا (العلامات & 1) {

;; تجاهل جميع الرسائل المرتدة

return ();

}

شريحة sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

إذا ((op == op::op_1())) {

handle_op1();

save_data();

العودة ();

}

إذا ((op == op::op_2())) {

handle_op2();

save_data();

return ();

}

إذا ((op == op::op_3())) {

handle_op3();

save_data();

العودة ();

}

throw(0xffff);

}

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

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

يحتوي Beosin على العديد من الحالات الناجحة داخل نظام TON. سابقًا، أجرى Beosin تدقيقات أمان شاملة لمشروع Aqua Protocol للعملة المستقرة اللامركزية الرائدة وبنية التحويل المالي اللامركزية ONTON Finance. شمل التدقيق عدة جوانب، بما في ذلك أمان شفرة العقد الذكي، صحة تنفيذ منطق الأعمال، تحسين الغاز في شفرة العقد، واكتشاف ومعالجة الثغرات المحتملة.

بيان:

1. تم استنساخ هذه المقالة من [بيوسين] ، العنوان الأصلي "Beosin Hard Core Research | من المخاطر إلى الحماية: المخاطر الأمنية واقتراحات التحسين لعقود TON الذكية》 ، حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [Beosin ] ، إذا كان لديك أي اعتراض على إعادة الطبع ، يرجى الاتصال فريق جيت ليرن، سيتولى الفريق بمعالجتها في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.

2. تنويه: تعبر الآراء والآراء المعبر عنها في هذه المقالة فقط عن آراء الكاتب الشخصية ولا تشكل أي توصية استثمارية.

3. تتم ترجمة النسخ الأخرى من المقالة بواسطة فريق Gate Learn ولا يتم ذكرها.Gate.ioقد لا يتم تكرار أو توزيع أو نسخ المقال المترجم.