العقد الذكي كتهديد أمني لبدء تشغيل blockchain

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

في نهاية المقال ، ألخص أفكاري بدليل موجز لكتابة عقود ذكية آمنة.

ملاحظات

1. ستركز هذه المقالة فقط على العقود الذكية لـ Ethereum. حدد المجتمع ضمنيًا العقود الذكية مع عقود Ethereum الذكية. وفي الوقت نفسه ، الأول هو أكثر من مفهوم ، والثاني هو التنفيذ ، ويمكن مناقشة مسألة كيفية تلبية هذا التنفيذ لهذا المفهوم (وكذلك من حيث المبدأ مفهوم العقود الذكية والتطبيقات المحتملة الأخرى). هذا الموضوع معقد ومقدّر حقًا ومثير للاهتمام ، لكن هذا ليس موضوع هذا المقال ، لذلك سأحيل الأشخاص المهتمين بأعمال نيك زابو . وفقًا لذلك ، في كل مكان أبعد ، حيث أقول "العقود الذكية" ، أعني في الواقع "العقود الذكية لـ Ethereum".
2. ستركز المقالة فقط على لغة العقود الذكية Solidity باعتبارها الأكثر شيوعًا ولمستخدم Ethereum في الواقع الوحيد في الوقت الحالي.

قضايا أمن العقود الذكية

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

1. مشاكل في قانون العقد الذكي ؛
2. مشاكل في عملية التنمية ؛
3. مشاكل في اللغة ؛
4. مشاكل في المفهوم.

1. مشاكل في كود العقد الذكي

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

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

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

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

2. مشاكل في عملية التطوير

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

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

3. مشاكل في اللغة

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

• الوراثة المتعددة ، using for ، call / delegate call - كل هذا يبدأ الرمز ليس من المصدر الحالي ، مما يعني أنه يقلل من إمكانية القراءة ، ونتيجة لذلك ، أمن الشفرة.
• نمط الشيكات والتأثيرات والتفاعلات - إذا كانت الإنشاءات التي تنتهك CEI غير آمنة ، فلماذا لا تمنعها (وغيرها الكثير) ببساطة على مستوى اللغة؟
• من خلال استدعاء عقد آخر ، يمكنك أن تقع فجأة في وظيفته الاحتياطية مع عواقب غير متوقعة.

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

4. مشاكل في المفهوم

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

1. غير ذكي:

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

2. ليس عقدًا:

   
   
   • لا تسجل التزامات الأطراف - على سبيل المثال ، تبيع ICO رموزها المميزة لـ ETH ، لكن الرموز هي في الأساس أغلفة حلوى ، لأن لا تفرض على من أفرج عنه أية قيود أو التزامات.
   • يسمح بتغييرات من جانب واحد - وتبين أنه يمكن لأحد الطرفين تغيير العقد بعد توقيعه.
     
     مثال على الحياة : يمكن لمالك العقد أن يغير بشكل تعسفي الرسملة ومعدل ومدة البيع المميز:
     
     
   
   

3. غير مطلوب:

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

العقد الذكي كتهديد أمني لبدء تشغيل blockchain

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

كيفية كتابة عقود ذكية آمنة

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

إذا قرر القارئ كتابة عقد ذكي ، أنصحك بما يلي:

• فهم سبب الحاجة إلى عقد ذكي (وما إذا كان مطلوبًا) ؛
• تلقي من العميل أو كتابة المعارف التقليدية ؛
• حساب الوقت
• استخدام أدوات التطوير والاختبار ( Truffle أو Remix أو SmartCheck أو Solhint أو Solium linter ) ؛
• كتابة الاختبارات
• إجراء العديد من عمليات تدقيق الحسابات المستقلة ومكافأة الأخطاء ؛
• مراقبة سلامة المكونات المتبقية من المشروع (موقع الويب ، تويتر ، إلخ.).

باتباع هذه التوصيات البسيطة ، يمكنك تجنب معظم المشاكل الموضحة أعلاه (من شوكة صلبة ، ومع ذلك ، لن يتم حفظ ذلك).

تم إنشاء المقالة بالاشتراك مع Eugene Marchenko ( eMarchenko ).