تدقيق العقود الذكية: دليل شامل لتحليل الثغرات الأمنية

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

ما هو تدقيق العقود الذكية؟

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

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

لماذا يعتبر تدقيق العقود الذكية مهماً؟

لا يمكن المبالغة في أهمية تدقيق العقود الذكية. يمكن أن تكون عواقب نشر العقود الذكية الضعيفة وخيمة، مما يؤدي إلى:

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

التاريخ الحديث مليء بأمثلة على عمليات الاستغلال التي أدت إلى خسائر بملايين الدولارات. يمكن للتدقيق أن يمنع هذه الخسائر ويبني الثقة في المنصة.

الثغرات الشائعة في العقود الذكية

يعد فهم الثغرات الشائعة في العقود الذكية أمرًا ضروريًا لكل من المطورين والمدققين. فيما يلي بعض أنواع الثغرات الأكثر انتشارًا:

1. إعادة الدخول (Reentrancy)

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

مثال:

فكر في عقد يسمح للمستخدمين بسحب الإيثر. إذا أرسل العقد الإيثر للمستخدم قبل تحديث رصيده الداخلي، يمكن للمستخدم الاتصال مرة أخرى بالعقد وسحب الإيथर عدة مرات قبل تحديث رصيده.

التخفيف:

• استخدم نمط "Checks-Effects-Interactions"، والذي يتضمن إجراء الفحوصات قبل إجراء الاستدعاءات الخارجية، وتحديث الحالة قبل إجراء الاستدعاءات الخارجية، وتقييد التفاعلات مع العقود الخارجية.
• استخدم دالتي `transfer()` أو `send()` لإرسال الإيثر، حيث تحد هاتان الدالتان من كمية الغاز التي يمكن للمستلم استخدامها، مما يمنعه من الاتصال مرة أخرى بالعقد.
• نفّذ حراس إعادة الدخول (reentrancy guards)، التي تمنع استدعاء دالة بشكل متكرر.

2. فيضان وتدفق الأعداد الصحيحة (Integer Overflow and Underflow)

يحدث فيضان وتدفق الأعداد الصحيحة عندما تؤدي عملية حسابية إلى قيمة خارج نطاق نوع البيانات المستخدم لتخزين النتيجة. على سبيل المثال، إذا تم زيادة عدد صحيح غير موقّع بحجم 8 بت (uint8) إلى ما بعد 255، فسوف يلتف ويعود إلى 0. وبالمثل، إذا تم إنقاصه إلى ما دون 0، فسوف يلتف ويعود إلى 255.

مثال:

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

التخفيف:

• استخدم مكتبات الرياضيات الآمنة، مثل مكتبة SafeMath من OpenZeppelin، التي توفر وظائف تتحقق من الفيضان والتدفق وتعكس المعاملة إذا حدثت.
• استخدم أنواع بيانات أعداد صحيحة أكبر، مثل uint256، لتقليل احتمالية حدوث الفيضان والتدفق.

3. هجمات حجب الخدمة (Denial of Service - DoS)

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

مثال:

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

التخفيف:

• تجنب الحلقات والتكرارات غير المحدودة، حيث يمكن أن تستهلك غازًا مفرطًا.
• نفّذ الترقيم (pagination) أو المعالجة على دفعات (batch processing) للحد من كمية الغاز المطلوبة لكل معاملة.
• استخدم مدفوعات السحب (pull payments) بدلاً من مدفوعات الدفع (push payments)، حيث تسمح مدفوعات السحب للمستخدمين بسحب الأموال بالسرعة التي تناسبهم، مما يقلل من مخاطر مشكلات حدود الغاز.
• نفّذ قواطع الدائرة (circuit breakers)، التي يمكنها تعطيل وظائف معينة في العقد مؤقتًا إذا تم الكشف عن هجوم DoS.

4. الاعتماد على الطابع الزمني (Timestamp Dependence)

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

مثال:

فكر في عقد مقامرة يستخدم طابع الكتلة الزمني لتوليد رقم عشوائي. يمكن للمهاجم التأثير على نتيجة اللعبة عن طريق تعدين كتلة بطابع زمني يفضل نتيجته المرجوة.

التخفيف:

• تجنب استخدام طابع الكتلة الزمني للمنطق الحاسم.
• استخدم مصادر أكثر موثوقية للعشوائية، مثل Chainlink VRF أو RANDAO.
• نفّذ ضمانات لضمان أن يكون الطابع الزمني ضمن نطاق معقول.

5. استدعاء المفوَّض (Delegatecall)

`delegatecall` هي دالة منخفضة المستوى تسمح لعقد بتنفيذ كود من عقد آخر في سياق العقد المستدعي. هذا يعني أن العقد المستدعى يمكنه تعديل متغيرات التخزين والحالة للعقد المستدعي. إذا تم استخدامها بشكل غير صحيح، يمكن أن تؤدي `delegatecall` إلى ثغرات أمنية خطيرة.

مثال:فكر في عقد وكيل (proxy contract) يستخدم `delegatecall` لإعادة توجيه الاستدعاءات إلى عقد منطقي. إذا كان للعقد المنطقي تخطيط تخزين مختلف عن العقد الوكيل، فيمكنه الكتابة فوق متغيرات التخزين الحاسمة للعقد الوكيل، مما قد يسمح للمهاجم بالسيطرة على العقد الوكيل.

التخفيف:

• تأكد من أن تخطيط التخزين للعقد الوكيل والعقد المنطقي متوافقان.
• دقق بعناية في كود العقد المنطقي للتأكد من أنه لا يحتوي على أي كود خبيث.
• استخدم أنماط الوكيل التي تم اختبارها وتدقيقها جيدًا، مثل نمط UUPS (Universal Upgradeable Proxy Standard).

6. التحكم في الوصول (Access Control)

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

مثال:

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

التخفيف:

• استخدم معدّل `onlyOwner` لتقييد الوصول إلى وظائف معينة لمالك العقد.
• نفّذ المصادقة متعددة التوقيعات لطلب موافقة أطراف متعددة على الإجراءات الحاسمة.
• استخدم التحكم في الوصول المستند إلى الأدوار (RBAC) لتحديد أدوار وأذونات مختلفة لمستخدمين مختلفين.
• نفّذ قوائم التحكم في الوصول (ACLs) لمنح أو إلغاء الوصول إلى موارد محددة.

7. الاستثناءات غير المعالجة (Unhandled Exceptions)

في لغة Solidity، يمكن إطلاق الاستثناءات باستخدام دوال `revert()` و `require()` و `assert()`. إذا لم يتم التعامل مع استثناء بشكل صحيح، فقد يؤدي ذلك إلى سلوك غير متوقع وثغرات أمنية.

مثال:

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

التخفيف:

• استخدم نمط "Checks-Effects-Interactions" لتقليل مخاطر حدوث استثناءات أثناء الاستدعاءات الخارجية.
• استخدم كتل try-catch للتعامل مع الاستثناءات وعكس المعاملة إذا لزم الأمر.
• تجنب إجراء استدعاءات خارجية من المحتمل أن تطلق استثناءات.

8. الاستباق (Front Running)

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

مثال:

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

التخفيف:

• استخدم مخططات الالتزام والكشف (commit-reveal schemes)، التي تتطلب من المستخدمين الالتزام بمعاملاتهم قبل الكشف عنها على السلسلة.
• استخدم بيئات التنفيذ خارج السلسلة، مثل حلول التوسع من الطبقة الثانية، لتقليل رؤية المعاملات.
• نفّذ خوارزميات مطابقة الطلبات المقاومة للاستباق.

منهجيات تدقيق العقود الذكية

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

1. المراجعة اليدوية للكود

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

أفضل الممارسات:

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

2. التحليل الثابت (Static Analysis)

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

أدوات شائعة:

• Slither
• Mythril
• Securify
• Oyente

3. التحليل الديناميكي (Dynamic Analysis)

يتضمن التحليل الديناميكي تنفيذ كود العقد الذكي في بيئة خاضعة للرقابة لمراقبة سلوكه وتحديد الثغرات المحتملة. يمكن القيام بذلك باستخدام تقنيات الاختبار الضبابي (fuzzing)، والتي تتضمن تزويد العقد بعدد كبير من المدخلات العشوائية لمحاولة إثارة سلوك غير متوقع، أو من خلال التنفيذ الرمزي (symbolic execution)، والذي يتضمن استكشاف جميع مسارات التنفيذ الممكنة للعقد.

أدوات شائعة:

• Echidna
• MythX
• Manticore

4. التحقق الرسمي (Formal Verification)

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

أدوات شائعة:

• Certora Prover
• K Framework
• Isabelle/HOL

5. تحسين استهلاك الغاز (Gas Optimization)

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

أفضل الممارسات:

• استخدم هياكل بيانات وخوارزميات فعالة.
• قلل من عدد عمليات قراءة وكتابة التخزين.
• استخدم `calldata` بدلاً من `memory` لوسائط الدوال.
• خزّن البيانات التي يتم الوصول إليها بشكل متكرر مؤقتًا.
• تجنب الحلقات والتكرارات غير الضرورية.

عملية تدقيق العقود الذكية

تتضمن عملية تدقيق العقود الذكية النموذجية الخطوات التالية:

1. تحديد النطاق: حدد نطاق التدقيق، بما في ذلك العقود التي سيتم تدقيقها، والوظائف التي سيتم اختبارها، والأهداف الأمنية التي يتعين تحقيقها.
2. جمع المعلومات: اجمع معلومات حول المشروع، بما في ذلك البنية، والمنطق التجاري، وبيئة النشر، وناقلات الهجوم المحتملة.
3. مراجعة الكود: قم بإجراء مراجعة يدوية للكود لتحديد الثغرات المحتملة والأخطاء البرمجية والأخطاء المنطقية.
4. التحليل الآلي: استخدم أدوات التحليل الثابت والديناميكي لأتمتة عملية مراجعة الكود وتحديد الثغرات الإضافية.
5. الاختبار: قم بإجراء اختبارات الوحدة واختبارات التكامل واختبارات Fuzzing للتحقق من وظائف وأمان العقد.
6. إعداد التقارير: وثّق جميع النتائج والتوصيات في تقرير تدقيق شامل.
7. المعالجة: اعمل مع فريق التطوير لمعالجة الثغرات المحددة وتنفيذ التدابير الأمنية الموصى بها.
8. إعادة التدقيق: قم بإجراء إعادة تدقيق للتحقق من أن الثغرات التي تم إصلاحها قد تمت معالجتها بنجاح.

اختيار شركة التدقيق

يعد اختيار شركة التدقيق المناسبة أمرًا بالغ الأهمية لضمان أمان عقودك الذكية. فيما يلي بعض العوامل التي يجب مراعاتها عند اختيار شركة تدقيق:

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

أفضل الممارسات لأمان العقود الذكية

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

• اكتب كودًا واضحًا وموجزًا: استخدم أسماء متغيرات وتعليقات ذات معنى، ونمط ترميز ثابت لجعل الكود أسهل في الفهم والمراجعة.
• اتبع أفضل الممارسات الأمنية: التزم بأفضل الممارسات الأمنية المعمول بها، مثل قائمة OWASP لأفضل 10 ثغرات في العقود الذكية.
• استخدم مكتبات تم اختبارها وتدقيقها جيدًا: استخدم مكتبات تم اختبارها وتدقيقها جيدًا، مثل عقود OpenZeppelin، لتجنب إعادة اختراع العجلة وإدخال ثغرات جديدة.
• نفّذ تحكمًا مناسبًا في الوصول: استخدم معدّل `onlyOwner` والمصادقة متعددة التوقيعات والتحكم في الوصول المستند إلى الأدوار لتقييد الوصول إلى الوظائف الحساسة.
• تعامل مع الاستثناءات بشكل صحيح: استخدم كتل try-catch للتعامل مع الاستثناءات وعكس المعاملة إذا لزم الأمر.
• اختبر بدقة: قم بإجراء اختبارات الوحدة واختبارات التكامل واختبارات Fuzzing للتحقق من وظائف وأمان العقد.
• ابقَ على اطلاع بأحدث التهديدات الأمنية: ابقَ على علم بأحدث التهديدات والثغرات الأمنية، وقم بتحديث الكود الخاص بك وفقًا لذلك.
• فكر في التحقق الرسمي للعقود الحرجة: استخدم التحقق الرسمي لإثبات صحة العقود الحرجة رياضيًا.
• نفّذ المراقبة والتنبيه: نفّذ أنظمة المراقبة والتنبيه لاكتشاف الحوادث الأمنية المحتملة والاستجابة لها.
• لديك برنامج مكافآت الأخطاء: قدم برنامج مكافآت الأخطاء (bug bounty) لتحفيز باحثي الأمن على العثور على الثغرات والإبلاغ عنها.

مستقبل تدقيق العقود الذكية

يتطور مجال تدقيق العقود الذكية باستمرار مع ظهور تقنيات وثغرات جديدة. فيما يلي بعض الاتجاهات التي تشكل مستقبل تدقيق العقود الذكية:

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

الخاتمة

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

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