الوضع المؤسف لتدقيق Web3، وما يمكن فعله

تعرض Balancer، وهو بروتوكول قديم تم تدقيقه جيداً، مؤخراً للاختراق. وكذلك Yearn Finance الذي تم تدقيقه جيداً أيضاً. منذ سنوات، تم اختراق Euler Finance عبر وظيفة تم إدخالها استجابةً لتدقيق سابق. تم تدقيق USPD قبل النشر ثم تم اختراق عملية النشر نفسها غير المدققة مما أدى إلى شطب كامل في غضون حوالي 3 أشهر من الإطلاق. لا أحد ممن كانوا يتابعون يعتقد أن عمليات التدقيق تضمن أن شيئاً ما آمن. يتساءل الكثيرون عما إذا كانت تستحق أي قيمة على الإطلاق.

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

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

نقطتنا هنا ليست أن المدققين يفعلون أي شيء خاطئ. المدققون يفعلون ما تطلبه منهم المشاريع التي تتعامل معهم. يتم تحديد نطاق التدقيق من قبل المشروع. كمثال متطرف واحد فقط: لو كان Do Kwon قد تعامل مع مدققين لمخططه للعملة المستقرة لكانوا قد لاحظوا أنه من المحتمل أن يكون غير مستقر. كانت المشكلة ستُوسم بـ "معترف بها" ولن يتم فعل أي شيء أو تغييره.

هذه المشكلة لا علاقة لها بالدراسات مثل تلك التي ادعت أن نظام Terra-LUNA البيئي لـ Do كان قوياً للغاية. من الصعب التنبؤ بالمستقبل وتُنظر إلى هذه الأنواع من الدراسات بحق على أنها تسويق يخدم المصلحة الذاتية والذي، في النهاية، يعترف بالمشاكل الأساسية. من المتوقع أن تصور الأبحاث التي ترعاها المشاريع الأمور بطريقة إيجابية. الهدف الكامل من عمليات التدقيق هو توفير منظور موضوعي من الطرف الثالث. لا يمكن الوثوق بالمبالغة وعمليات التدقيق ليست ضمانات أو تأمين. هكذا هي الحياة.

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

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

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

Jovay

Jovay هو L2 مرتبط بـ Ant Financial أو Alibaba أو شيء ما في تلك المنطقة العامة. لكن لا يهم حقاً ما يفعله Jovay. إنه شيء مبني من برمجيات من منظمة كبيرة وممولة جيداً. يسرد هذا التدقيق ثماني مشكلات:

1. خطأ برمجي مشروع تم إصلاحه لاحقاً.
2. أن البروتوكول ليس بدون ثقة. هذه مشكلة من نوع ما ولكنها أيضاً جزء أساسي من التصميم.
3. هجوم "إعادة الشحن المزيفة" الذي يُطبق على نطاق واسع من النظام البيئي وليس خاصاً بالمشروع.
4. خوادم RPC تستخدم HTTP بدلاً من HTTPS. هذه الواجهات لا تعالج معلومات سرية. ينطبق هذا على مليارات المواقع الآمنة تماماً للقراءة فقط.
5. الحوسبة الكمومية تشكل خطراً على Ethereum. حسناً. موضوع ذو صلة جداً.
6. العقود الذكية EVM يمكن أن تكون عرضة للخطر. لا، بجدية. يقول "العقود الذكية Evm عرضة لمتجهات هجوم مختلفة بسبب نشر الكود غير القابل للتغيير والتفاعلات المعقدة، مما قد يؤدي إلى سرقة الأموال،.." حسناً. مرة أخرى نحترم حقاً التركيز الضيق لهذا التدقيق.
7. تصميم المسلسل يخضع لـ MEV. مثل بقية النظام البيئي Ethereum بأكمله. إنه أيضاً مظلم جداً في الليل.
8. يمكن تحسين جودة الكود. على عكس معظم الأكواد الأخرى المكتوبة منذ فجر الحوسبة.

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

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

Hyperliquid

نشر Hyperliquid بعض تقارير التدقيق. وجد تقرير التدقيق الأول ست مشاكل وأكد التقرير الثاني حلها. لكن نطاق التدقيق استثنى:

1. العقود الذكية الأخرى جزء من نظام Hyperliquid
2. المكونات خارج السلسلة، مثل المدققين
3. مكونات الواجهة الأمامية
4. البنية التحتية المتعلقة بالمشروع
5. حفظ المفاتيح

تبدو تلك مثل مجالات مشاكل محتملة! كل ما تم تدقيقه كان عقد جسر واحد. لكن النظام، حسناً، إنه أكثر تعقيداً من ذلك بكثير.

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

Ondo

يُبرز هذا التدقيق "مخاطر المركزية للكيانات والأدوار الموثوقة" التي اعترف بها الفريق. إنها بأحرف كبيرة هكذا في التقرير. صحيح.

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

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

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

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

يمكنك رؤية هذا التطور في عمليات التدقيق لهذا المشروع الواحد.

Mutuum Finance

الآن لدينا الاختزال إلى الهراء من عمليات التدقيق. يحدد هذا مشكلة واحدة:

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

ثم هناك الكثير من تفاصيل التوقيع المتعدد. وأخيراً استجابة المدقق:

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

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

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

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

التحسينات

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

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

تُظهر Ethena أن الصدق لا يُهلك المشروع! يمكنك أن تجادل بأنه بكونه أكثر صدقاً جذب المشروع المزيد من الاهتمام. الصدق له أيضاً ميزة إضافية تتمثل في توفير المزيد من التغطية القانونية إذا حدث خطأ ما. يجب أن ترغب المشاريع في القيام بذلك بالفعل.

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

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

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

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

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

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