يعتقد معظم المؤسسين أن الأمان يعني فقط تأمين العقد الذكي. لكن إليكم بعض الخرافات الشائعة مقابل الواقع التي يجب على كل مؤسس فهمها. > خرافة: بمجرد أن نجتاز التدقيق، نحن آمنون. الواقع: بحسب رأيي، هذه واحدة من أكبر التصورات الخاطئة في Web3. التدقيق ليس شهادة أمان، بل هو مراجعة لشفرتك في لحظة زمنية محددة. في اللحظة التي تُطلق فيها ميزة جديدة، أو تُدمج بروتوكولًا آخر، أو تُحدّث مصدر بيانات، أو تغيّر بنية خلفيتك، يتغير ملف المخاطر الخاص بك. التدقيق يساعد على تقليل المخاطر، لكن كل تحديث بعد ذلك يستحق نفس مستوى الاهتمام. > خرافة: القراصنة يستغلون العقود الذكية فقط. الواقع: لا أعتقد أن هذا صحيح بعد الآن. ما رأيناه خلال السنوات القليلة الماضية هو أن بعض أكبر الخسائر لم تأتِ من أخطاء في Solidity، بل من مفاتيح خاصة مخترقة، أو هجمات التصيد، أو فشل في التحكم بالوصول، أو بنية تحتية خلفية، أو موقّعي مصادر البيانات، أو أخطاء تشغيلية. واجهتك الأمامية، وواجهات برمجة التطبيقات، وخطوة النشر، والمحفظات، والبنية التحتية — كلها جزء من سطح الهجوم الخاص بك. برأيي، يحتاج المؤسسون إلى التفكير أبعد من العقد الذكي. بنية تحتية ومفاتيح وعمليات تشغيلك مهمة بنفس القدر. > خرافة: نحن صغار جدًا لكي نكون هدفًا. الواقع: المهاجمون لا يهتمون عادةً بعدد المتابعين لمشروعك. إنما يهتمون بشيء واحد: هل يمكنهم استخراج قيمة منه؟ إذا كان بروتوكولك يحتوي على أصول أو لديه مستخدمين، فأنت بالفعل مثير للاهتمام لشخص ما. الانتظار حتى تصبح كبيرًا بما يكفي للاستثمار في الأمان غالبًا ما يكون متأخرًا جدًا. > خرافة: موقّع واحد موثوق أو مفتاح إداري واحد كافٍ. الواقع: برأيي، يجب التعامل مع كل مفتاح ذو صلاحيات خاصة كما لو كان خزانتك. مفاتيح مصادر البيانات، ومفاتيح النشر، ومفاتيح التحديث، وموقّعي التوقيع المتعدد، وبيانات اعتماد الخلفية — كلها يمكن أن تصبح نقطة فشل واحدة. مفتاح واحد مخترق يمكن أن يعرض بروتوكولًا بأكمله للخطر. > خرافة: سنحسن الأمان بعد الإطلاق. الواقع: المهاجمون لن ينتظروا حتى تلك النقطة. غالبًا ما يعتقد المؤسسون أنه يمكن إضافة الأمان في الإصدارات اللاحقة. لسوء الحظ، لا تتبع الاستغلالات جداول زمنية المنتجات. أفضل وقت لبناء الرصد والاستجابة للحوادث والأمان التشغيلي هو قبل أن يثق المستخدمون بك بأصولهم. > خرافة: الاختبار الداخلي كافٍ. الواقع: فريقك يعرف كيف يجب أن يعمل البروتوكول. باحث خارجي يفكر في كيفية فشله. لهذا السبب تلعب التدقيقات، والمراجعات التنافسية، وبرامج المكافآت للعثور على الأخطاء، والاختبار المستمر أدوارًا مختلفة. الأمان يستفيد من وجهات نظر جديدة. > خرافة: المصدر المفتوح يعني أن شخصًا ما سيكتشف الأخطاء. الواقع: المصدر المفتوح يحسن الشفافية. لكنه لا يضمن أن أحدًا سيقوم بمراجعة كل سطر من الشفرة أو الإبلاغ المسؤول عن كل ثغرة. نشر الشفرة ليس نفس التحقق منها. > خرافة: الأمان مسؤولية المدقق. الواقع: ربما هذا هو أكبر تغيير في التفكير الذي يحتاج المؤسسون إلى إجرائه. المدققون يساعدون على تقليل المخاطر. لكن الأمان يُبنى من قبل الجميع: المؤسسون الذين يتخذون قرارات المنتج، والمطورون الذين يكتبون الشفرة، وفرق DevOps التي تدير البنية التحتية، وفرق العمليات التي تحمي الوصول. لطالما اعتقدت أن الأمان ليس شيئًا تنتهي منه، بل هو شيء تحسنه باستمرار. الاستنتاج النهائي: لقد تغير مشهد الأمان. وأعتقد أن طريقة تفكيرنا تجاه الأمان يجب أن تتغير معه. لم يعد كافيًا التركيز فقط على العقود الذكية. كمؤسسين، نحتاج إلى التفكير في تأمين البروتوكول بأكمله — من العقود والبنية التحتية إلى المفاتيح وضوابط الوصول وكل نظام يحافظ على عمل البروتوكول.