بعد استغلال Curve لإعادة الدخول مؤخرًا ، فكرت في الوقت الذي قضيته في JPL NASA ، حيث تعلمت المبادئ الأساسية لتطوير برامج موثوقة ومرنة. بالنسبة لصناعة التشفير ، أصبحت هذه الأفكار الآن أكثر أهمية من أي وقت مضى ، وإليك السبب:
في نهاية المطاف، هناك نوعان فقط من البرامج التي يهتم بها الأشخاص حقًا: البرامج التي يمكن أن تقتلك والبرامج التي يمكن أن تجعلك تخسر المال.
لا يتم تخصيص غالبية الميزانية (80٪ +) للبرامج المهمة لأي آلة فضائية للتطوير بحد ذاته، بل للتكامل والاختبار. إذا فشل البرنامج، تسقط المركبات الطائرة من السماء – الطائرات المقاتلة، والطائرات بدون طيار، والمركبات الفضائية، وما إلى ذلك.
تلتزم معظم الكودات في برامج الفضاء الجوي (إذا تم تصنيفها على أنها وحدة حرجة) بمعايير اختبار / تطوير صارمة للغاية ، مثل DO-178B المستوى أ. لا يحتاج كل سطر من التعليمات البرمجية إلى الاختبار فحسب، بل إذا كان هناك منطق متداخل، فسيتم أيضًا اختبار كل شرط منطقي على وجه التحديد.
في JPL NASA ، لا تتمثل فلسفة كتابة برامج رحلات الفضاء المتقدمة في كتابة أجمل وأنظف كود ، ولكن لكتابة كود يسهل اختبار الوحدة. لماذا؟ الأمر بسيط: عندما ترسل مركبة فضائية إلى الفضاء، فإنك تحصل على فرصة واحدة فقط، ولا أحد يرغب في المخاطرة مع احتمالية الفشل العالية. هذا هو نفس منطق blockchains ، نظرًا لأن الشفرة غير القابلة للتغيير هي ميزتها المهمة ، ولدينا فرصة واحدة فقط لإنفاق أموالنا بشكل صحيح في كل معاملة ، فلماذا لا نتعامل مع عملية تطوير dApps بجدية أكبر؟
على الرغم من عمليات التطوير والاختبار ومراجعة التعليمات البرمجية الصارمة، فمن الواضح أن هذه الوسائل ليست كافية للتخفيف من جميع الأخطاء والهجمات، لأنه في الواقع فإن القضاء على جميع أخطاء وقت التشغيل من خلال الاختبار والتدقيق هو أمر أقرب إلى المستحيل. إذن كيف نحمي برنامجنا من الفشل؟
حماية وقت التشغيل
الحماية في وقت التشغيل هي تقنية أمان تحمي التطبيقات البرمجية من الهجمات الضارة أثناء تشغيلها. مبدأها هو إجراء الكشف في الوقت الحقيقي عندما يكون الكود قيد التشغيل بالفعل، وتحليل السلوك الفعلي للبرنامج لحماية البرنامج من البيانات والهجمات الضارة.
تتطلب عمليات الحماية في وقت التشغيل للبرامج عالية الموثوقية جهدًا كبيرًا وتصميمًا لأنها تمثل خط الدفاع الأخير لضمان عدم دخول البرامج في حالات غير معروفة أو فشلها. هذه ليست مجرد حجة، بل عقود من الممارسة المثبتة.
اليوم في Web3، أعتقد أن تطبيقات DeFi تحتاج إلى نفس الموثوقية العالية ويجب أن تأخذ في الاعتبار نفس النهج. ومع ذلك، نظرًا للقيود المحتملة، لم يتم تصميم EVM للتعامل مع المهام المعقدة مثل الحماية أثناء التشغيل. إذًا، كيف يمكننا توفير الحماية أثناء التشغيل؟
إحدى الطرق هي من خلال برمجة Aspect، حيث تم تصميم Aspects بواسطة شبكة Artela blockchain، القادرة على تبديل سياق التنفيذ خلال دورة حياة أي معاملة عقد ذكية لإجراء فحوصات متقدمة على الحالة الفعلية للبرنامج. توفر Artela تصميمًا فريدًا للحماية أثناء التشغيل من خلال التوافق مع Aspect وEVM، ولديها الفرصة لتصبح الأساس المستقبلي لأمن العقود الذكية المشفرة.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
التفكير في حدث المنحنى لماذا نحتاج إلى الحماية وقت التشغيل
المؤلف الأصلي: كارل هوا ، الشريك والمدير التقني لشركة شيما كابيتال
بعد استغلال Curve لإعادة الدخول مؤخرًا ، فكرت في الوقت الذي قضيته في JPL NASA ، حيث تعلمت المبادئ الأساسية لتطوير برامج موثوقة ومرنة. بالنسبة لصناعة التشفير ، أصبحت هذه الأفكار الآن أكثر أهمية من أي وقت مضى ، وإليك السبب:
في نهاية المطاف، هناك نوعان فقط من البرامج التي يهتم بها الأشخاص حقًا: البرامج التي يمكن أن تقتلك والبرامج التي يمكن أن تجعلك تخسر المال.
لا يتم تخصيص غالبية الميزانية (80٪ +) للبرامج المهمة لأي آلة فضائية للتطوير بحد ذاته، بل للتكامل والاختبار. إذا فشل البرنامج، تسقط المركبات الطائرة من السماء – الطائرات المقاتلة، والطائرات بدون طيار، والمركبات الفضائية، وما إلى ذلك.
تلتزم معظم الكودات في برامج الفضاء الجوي (إذا تم تصنيفها على أنها وحدة حرجة) بمعايير اختبار / تطوير صارمة للغاية ، مثل DO-178B المستوى أ. لا يحتاج كل سطر من التعليمات البرمجية إلى الاختبار فحسب، بل إذا كان هناك منطق متداخل، فسيتم أيضًا اختبار كل شرط منطقي على وجه التحديد.
في JPL NASA ، لا تتمثل فلسفة كتابة برامج رحلات الفضاء المتقدمة في كتابة أجمل وأنظف كود ، ولكن لكتابة كود يسهل اختبار الوحدة. لماذا؟ الأمر بسيط: عندما ترسل مركبة فضائية إلى الفضاء، فإنك تحصل على فرصة واحدة فقط، ولا أحد يرغب في المخاطرة مع احتمالية الفشل العالية. هذا هو نفس منطق blockchains ، نظرًا لأن الشفرة غير القابلة للتغيير هي ميزتها المهمة ، ولدينا فرصة واحدة فقط لإنفاق أموالنا بشكل صحيح في كل معاملة ، فلماذا لا نتعامل مع عملية تطوير dApps بجدية أكبر؟
على الرغم من عمليات التطوير والاختبار ومراجعة التعليمات البرمجية الصارمة، فمن الواضح أن هذه الوسائل ليست كافية للتخفيف من جميع الأخطاء والهجمات، لأنه في الواقع فإن القضاء على جميع أخطاء وقت التشغيل من خلال الاختبار والتدقيق هو أمر أقرب إلى المستحيل. إذن كيف نحمي برنامجنا من الفشل؟
حماية وقت التشغيل
الحماية في وقت التشغيل هي تقنية أمان تحمي التطبيقات البرمجية من الهجمات الضارة أثناء تشغيلها. مبدأها هو إجراء الكشف في الوقت الحقيقي عندما يكون الكود قيد التشغيل بالفعل، وتحليل السلوك الفعلي للبرنامج لحماية البرنامج من البيانات والهجمات الضارة.
تتطلب عمليات الحماية في وقت التشغيل للبرامج عالية الموثوقية جهدًا كبيرًا وتصميمًا لأنها تمثل خط الدفاع الأخير لضمان عدم دخول البرامج في حالات غير معروفة أو فشلها. هذه ليست مجرد حجة، بل عقود من الممارسة المثبتة.
اليوم في Web3، أعتقد أن تطبيقات DeFi تحتاج إلى نفس الموثوقية العالية ويجب أن تأخذ في الاعتبار نفس النهج. ومع ذلك، نظرًا للقيود المحتملة، لم يتم تصميم EVM للتعامل مع المهام المعقدة مثل الحماية أثناء التشغيل. إذًا، كيف يمكننا توفير الحماية أثناء التشغيل؟
إحدى الطرق هي من خلال برمجة Aspect، حيث تم تصميم Aspects بواسطة شبكة Artela blockchain، القادرة على تبديل سياق التنفيذ خلال دورة حياة أي معاملة عقد ذكية لإجراء فحوصات متقدمة على الحالة الفعلية للبرنامج. توفر Artela تصميمًا فريدًا للحماية أثناء التشغيل من خلال التوافق مع Aspect وEVM، ولديها الفرصة لتصبح الأساس المستقبلي لأمن العقود الذكية المشفرة.