لا تكتب فقط عبارات تتطلب لوظائف محددة ؛ اكتب عبارات تتطلب لبروتوكولاتك. فحوصات الامتثال الوظيفي (المتطلبات) - الفعالية (التأثيرات) - التفاعلات (التفاعلات) + ثوابت البروتوكول (العاملون) أو وضع FREI-PI يمكن أن يساعد عقدك في أن يكون أكثر أمانًا ، لأنه يجبر المطورين على التركيز على الأمان على مستوى الوظيفة ، احترس أيضًا للثوابت على مستوى البروتوكول.
تحفيز
في مارس 2023 ، تم اختراق شركة Euler Finance وخسر 200 مليون دولار. Euler Finance هو سوق إقراض حيث يمكن للمستخدمين إيداع الضمانات والاقتراض بضمانها. لديها بعض الميزات الفريدة ، في الواقع إنها سوق إقراض يمكن مقارنتها بـ Compound Finance و Aave.
يمكنك قراءة تشريح الجثة حول هذا الاختراق هنا. محتواه الرئيسي هو عدم وجود فحوصات صحية في وظيفة معينة ، مما يسمح للمستخدمين بكسر الثبات الأساسي لسوق الإقراض.
الأساسيات الأولياء
في جوهر معظم بروتوكولات DeFi هو الثبات ، خاصية حالة البرنامج التي من المتوقع أن تكون دائمًا صحيحة. من الممكن أيضًا أن يكون لديك العديد من الثوابت ، ولكنها بشكل عام مبنية على فكرة أساسية. وهنا بعض الأمثلة:
كما هو الحال في سوق الإقراض: لا يمكن للمستخدمين اتخاذ أي إجراء لوضع أي حساب في وضع ضمان غير آمن أو أقل أمانًا (يعني "أقل أمانًا" أنه بالفعل أقل من الحد الأدنى للأمان وبالتالي لا يمكن سحبه مرة أخرى).
في AMM DEX: x \ * y == k ، x + y == k ، إلخ.
في تعدين السيولة: يجب أن يكون المستخدمون قادرين فقط على سحب مبلغ الـ Staking Tokens الذي قاموا بإيداعه.
لم يكن الخطأ الذي حدث في Euler Finance بالضرورة هو أنهم أضافوا ميزات ، أو لم يكتبوا اختبارات ، أو لم يتبعوا أفضل الممارسات التقليدية. قاموا بتدقيق الترقية وأجروا الاختبارات ، لكنها لا تزال تتسلل عبر الشقوق. المشكلة الأساسية هي أنهم ينسون عنصرًا أساسيًا ثابتًا في سوق الإقراض (كما يفعل المدققون!).
ملاحظة: أنا لا أحاول اختيار أويلر ، فهم فريق موهوب ، لكن هذه حالة حديثة. *
جوهر المشكلة
ربما تفكر في "حسنًا ، هذا صحيح. لهذا السبب تم اختراقهم ؛ لقد نسوا بيان مطلوب". نعم و لا.
لكن لماذا ينسون بيان الطلب؟
تحقق - تحقق - التفاعل ليس جيدًا بما يكفي
النمط الشائع الموصى به لمطوري الصلابة هو نمط Checks-Effects-Interactions. إنه مفيد جدًا للتخلص من الأخطاء المتعلقة بالعودة ، وغالبًا ما يزيد من مقدار التحقق من صحة الإدخال الذي يتعين على المطور القيام به. \ _ولكن \ _ فهو عرضة لمشكلة عدم رؤية الغابة للأشجار.
ما يعلمه المطور هو: "أولاً أكتب بيان الطلب الخاص بي ، ثم أقوم بالتحقق ، ثم ربما أقوم بأي تفاعل ، ثم أكون آمنًا". المشكلة هي ، في أغلب الأحيان ، أنها تصبح مزيجًا من الضوابط والتأثيرات - ليس سيئًا ، أليس كذلك؟ لا تزال التفاعلات نهائية ، لذا فإن عودة الدخول ليست مشكلة. لكنه يجبر المستخدمين على التركيز على وظائف أكثر تحديدًا وتحولات الدولة الفردية بدلاً من السياق العالمي الأوسع. هذا يعني ذاك:
إن مجرد نمط التفاعل والتحقق من الصحة يجعل المطورين ينسون الثوابت الأساسية لبروتوكولاتهم.
لا يزال هذا نمطًا ممتازًا للمطورين ، ولكن يجب دائمًا ضمان ثبات البروتوكول (بجدية ، لا يزال يتعين عليك استخدام CEI!).
افعلها بشكل صحيح: وضع FREI-PI
خذ على سبيل المثال هذا المقتطف من عقد SoloMargin الخاص بـ dYdX (رمز المصدر) ، وهو سوق إقراض وعقد تداول مع الرافعة المالية. هذا مثال جيد لما أسميه بنمط متطلبات الوظيفة - التأثيرات - التفاعلات + بروتوكول Iniants ، أو نمط FREI-PI.
على هذا النحو ، أعتقد أن هذا هو سوق الإقراض الوحيد في سوق الإقراض في المرحلة المبكرة الذي لا يحتوي على أي نقاط ضعف مرتبطة بالسوق. لا يوجد لدى Compound و Aave مشاكل مباشرة ، ولكن لها مفترق طرق. وقد تم اختراق bZx عدة مرات.
افحص الكود أدناه ولاحظ التجريدات التالية:
تحقق من معلمات الإدخال (\ _verifyInputs).
الإجراء (تحويل البيانات ، معالجة الحالة)
تحقق من الحالة النهائية (\ _verifyFinalState).
لا يزال يتم تنفيذ عمليات الفحص والتأثيرات والتفاعلات المعتادة. من الجدير بالذكر أن عملية التحقق من الصحة والتفاعل مع عمليات التحقق الإضافية لا تعادل FREI-PI - فهي متشابهة ولكنها تخدم أهدافًا مختلفة اختلافًا جوهريًا. لذلك ، يجب على المطورين اعتبارهم مختلفين: FREI-PI ، باعتباره تجريدًا أعلى ، يهدف إلى أمان البروتوكول ، بينما يهدف CEI إلى السلامة الوظيفية.
هيكل هذا العقد مثير للاهتمام حقًا - يمكن للمستخدمين تنفيذ الإجراءات التي يريدونها (الإيداع ، والاقتراض ، والتجارة ، والتحويل ، والتصفية ، وما إلى ذلك) في سلسلة من الإجراءات. هل تريد إيداع 3 رموز مختلفة ، وسحب الرابع ، وتصفية حساب؟ إنها مكالمة واحدة.
هذه هي قوة FREI-PI: يمكن للمستخدمين فعل ما يريدون ضمن البروتوكول ، طالما أن ثوابت سوق الإقراض الأساسي في نهاية المكالمة: لا يمكن لمستخدم واحد اتخاذ أي إجراء من شأنه أن يجعل أي حساب غير آمن أو أكثر من مواقع الضمانات غير الآمنة. بالنسبة لهذا العقد ، يتم تنفيذ ذلك في \ _verifyFinalState ، والتحقق من ضمانات كل حساب متأثر للتأكد من أن الاتفاقية أفضل مما كانت عليه عندما بدأت المعاملة.
هناك بعض الثوابت الإضافية المضمنة في هذه الوظيفة التي تكمل الثوابت الأساسية وتساعد في الوظائف الجانبية مثل إغلاق الأسواق ، لكن عمليات الفحص الأساسية هي التي تحافظ حقًا على أمان البروتوكول.
FREI-PI المرتكزة على الكيان
مشكلة أخرى مع FREI-PI هي مفهوم الكيان. خذ سوق الإقراض والثوابت الأساسية المفترضة كمثال:
من الناحية الفنية ، ليس هذا هو المتغير الوحيد ، ولكنه يتعلق بكيان المستخدم (لا يزال أحد البروتوكولات الأساسية الثابتة ، وعادة ما تكون ثوابت المستخدم هي ثوابت البروتوكول الأساسية). عادة ما يكون لأسواق الإقراض كيانان إضافيان:
وحي
الإدارة / الحوكمة
كل ثبات إضافي يجعل البروتوكول أكثر صعوبة في ضمانه ، وبالتالي كلما كان ذلك أفضل. هذا في الواقع ما قاله دان إليتسر في مقالته بعنوان: لماذا تم كسر DeFi وكيف يتم إصلاحه # 1 بروتوكول أقل أوراكل (تلميح: المقالة لا تقول في الواقع أن الأوراكل هي المشكلة).
وحي
بالنسبة إلى oracles ، خذ استغلال Cream Finance بقيمة 130 مليون دولار. الثبات الأساسي لكيانات أوراكل:
كما اتضح ، فإن التحقق من oracles في وقت التشغيل باستخدام FREI-PI أمر صعب ، ولكنه ممكن ، مع بعض التفكير. بشكل عام ، يعد Chainlink خيارًا جيدًا للاعتماد عليه في الغالب ، مما يرضي معظم الثبات. في حالة نادرة من التلاعب أو المفاجأة ، قد يكون من المفيد أن يكون لديك ضمانات تقلل المرونة لصالح الدقة (مثل التحقق من أن آخر قيمة معروفة كانت أكبر بنسبة مئوية قليلة من القيمة الحالية). أيضًا ، يقوم نظام SoloMargin الخاص بـ dYdX بعمل رائع مع أوراكل DAI ، إليك الكود (إذا كنت لا تستطيع معرفة ذلك ، أعتقد أنه أفضل نظام عقد ذكي معقد تمت كتابته على الإطلاق).
لمزيد من المعلومات حول تقييم oracle ، وتسليط الضوء على قدرات فريق Euler ، كتبوا مقالة جيدة عن التلاعب الحسابي بأسعار Uniswap V3 TWAP oracle.
الإدارة / الحكم
يعد إنشاء الثوابت للكيانات المُدارة هو الأصعب. هذا يرجع بشكل أساسي إلى حقيقة أن معظم دورهم هو تغيير الثوابت الأخرى الموجودة. ومع ذلك ، إذا كان بإمكانك تجنب استخدام الأدوار الإدارية ، فيجب عليك ذلك.
بشكل أساسي ، قد تكون الثوابت الأساسية للكيان المُدار هي:
التفسير: يمكن للمسؤولين القيام بأشياء يجب أن تنتهي بعدم كسر الثوابت ، ما لم يغيروا الأشياء بشكل جذري لحماية أموال المستخدمين (على سبيل المثال: نقل الأصول إلى عقد الإنقاذ هو إزالة الثوابت). يجب أيضًا اعتبار المسؤولين مستخدمين ، لذلك يجب أيضًا أن يكون ثبات المستخدم في سوق الإقراض الأساسي مناسبًا لهم (بمعنى أنهم لا يستطيعون مهاجمة المستخدمين الآخرين أو البروتوكولات). حاليًا ، من المستحيل التحقق من بعض إجراءات المسؤول في وقت التشغيل عبر FREI-PI ، ولكن مع وجود ثوابت قوية بدرجة كافية في أماكن أخرى ، نأمل أن يتم تخفيف معظم المشكلات. أقول حاليًا ، لأنه يمكن للمرء أن يتخيل استخدام نظام zk proof الذي قد يتحقق من حالة العقد بالكامل (لكل مستخدم ، لكل أوراكل ، إلخ).
كمثال على كسر المسؤول للثبات ، اتخذ إجراء الحوكمة المركب الذي عمل على اختراق سوق CETH في أغسطس 2022. بشكل أساسي ، تكسر هذه الترقية ثبات Oracle: توفر Oracle معلومات دقيقة (نسبيًا) في الوقت الفعلي. نظرًا لعدم وجود وظائف ، يمكن أن توفر Oracle معلومات غير صحيحة. يمكن أن يؤدي التحقق من FREI-PI في وقت التشغيل ، والتحقق من أن Oracle المتأثرة إلى توفير معلومات في الوقت الفعلي ، إلى منع حدوث ذلك مع الترقية. يمكن دمج هذا في \ _setPriceOracle للتحقق مما إذا كانت جميع الأصول قد تلقت معلومات الوقت الفعلي. الشيء الجميل في FREI-PI لأدوار المسؤول هو أن أدوار المسؤول غير حساسة نسبيًا للسعر (أو على الأقل يجب أن تكون كذلك) ، لذلك لا ينبغي أن يكون استخدام الغاز مشكلة كبيرة.
التعقيد خطير
لذا في حين أن أهم الثوابت هي الثوابت الأساسية للبروتوكول ، يمكن أن يكون هناك أيضًا بعض الثوابت التي تتمحور حول الكيان والتي يجب أن تحتفظ بها الثوابت الأساسية. ومع ذلك ، فإن أبسط (وأصغر) مجموعة من الثوابت هي على الأرجح الأكثر أمانًا. البساطة جيدة والمثال الساطع هو Uniswap ...
لماذا لم يتم اختراق Uniswap مطلقًا (ربما)
يمكن أن تحتوي AMMs على أبسط ثوابت أساسية لأي DeFi بدائي: tokenBalanceX \ * tokenBalanceY == k (مثل نموذج المنتج الثابت). تدور كل وظيفة في Uniswap V2 حول هذا الثابت البسيط:
النعناع: يضاف إلى k
حرق: طرح من k
المبادلة: نقل x و y ، لكن احتفظ بـ k.
المقشود: أعد ضبط tokenBalanceX \ * tokenBalanceY لجعله مساويًا لـ k ، وقم بإزالة الجزء الزائد.
السر الأمني لـ Uniswap V2: الجوهر هو ثبات بسيط ، وجميع الوظائف في خدمته. الكيان الآخر الوحيد الذي يمكن الجدال فيه هو الحوكمة ، والتي يمكنها تشغيل مفتاح الرسوم ، والذي لا يمس الثبات الأساسي ، بل فقط توزيع ملكية رصيد الرمز المميز. هذه البساطة في بيان الأمان الخاص بهم هو سبب عدم اختراق Uniswap مطلقًا. البساطة في الواقع ليست ازدراء للمطورين الممتازين لعقود Uniswap الذكية ، بل على العكس من ذلك ، يتطلب الأمر مهندسين ممتازين لإيجاد البساطة.
مشكلة الغاز
يمتلئ موقع تويتر الخاص بي بالفعل بصراخ المتفائلين من الرعب والألم بأن هذه الفحوصات غير ضرورية وغير فعالة. شيئين حول هذا السؤال:
هل تعرف ما هو غير فعال؟ اضطررنا إلى إرسال رسائل إلى ~~ Laurence ~~ المتسللين الكوريين الشماليين عبر etherscan ، وتحويل الأموال باستخدام ETH ، والتهديد بأن مكتب التحقيقات الفيدرالي سيتدخل.
من المحتمل أنك قمت بالفعل بتحميل جميع البيانات التي تحتاجها من التخزين ، لذا في نهاية المكالمة ، ما عليك سوى إضافة القليل من التحقق إلى البيانات الساخنة. هل تريد أن تكلف موافقتك رسومًا لا تذكر ، أو تتركها تموت؟
إذا كانت التكلفة باهظة ، فأعد التفكير في المتغيرات الأساسية وحاول التبسيط.
ماذا يعني هذا بالنسبة لي؟
بصفتك مطورًا ، من المهم تحديد الثوابت الأساسية والتعبير عنها في وقت مبكر من عملية التطوير. كاقتراح ملموس: الوظيفة الأولى لكتابة نفسك هي \ _verifyAfter ، للتحقق من ثوابتك بعد كل مكالمة لعقدك. ضعها في عقدك ، وانشرها هناك. قم بتكملة هذا المتغير (وغيره من الثوابت المتمركزة حول الكيان) باختبارات ثابتة أوسع يتم فحصها قبل النشر (دليل المسبك).
تفتح المتاجر العابرة بعض التحسينات والتحسينات المثيرة للاهتمام التي ستختبرها شركة Nascent - أقترح عليك التفكير في كيفية استخدام المتاجر المؤقتة كأداة لتحسين الأمان عبر سياقات المكالمات.
في هذه المقالة ، لم يتم قضاء الكثير من الوقت في إدخال نموذج FREI-PI للتحقق من صحة الإدخال ، ولكنه أيضًا مهم جدًا. يعد تحديد حدود الإدخال مهمة صعبة لتجنب الفائض والمواقف المماثلة. ضع في اعتبارك التحقق من ومتابعة تقدم أداتنا: البيرومتر (حاليًا في مرحلة تجريبية ، يرجى إعطائنا نجمة). يمكن أن يتعمق ويساعدك في العثور على الأماكن التي قد لا تقوم فيها بالتحقق من صحة الإدخال.
ختاماً
علاوة على أي اختصار جذاب (FREI-PI) أو اسم مخطط ، فإن الجزء المهم حقًا هو:
ابحث عن البساطة في الثبات الأساسي للبروتوكول الخاص بك. واعمل مثل الجحيم للتأكد من عدم تدميره (أو الإمساك به قبل أن يحدث).
شاهد النسخة الأصلية
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
نموذج جديد لأمان عقد DeFi: التركيز على بروتوكول الثوابت
ملخص
لا تكتب فقط عبارات تتطلب لوظائف محددة ؛ اكتب عبارات تتطلب لبروتوكولاتك. فحوصات الامتثال الوظيفي (المتطلبات) - الفعالية (التأثيرات) - التفاعلات (التفاعلات) + ثوابت البروتوكول (العاملون) أو وضع FREI-PI يمكن أن يساعد عقدك في أن يكون أكثر أمانًا ، لأنه يجبر المطورين على التركيز على الأمان على مستوى الوظيفة ، احترس أيضًا للثوابت على مستوى البروتوكول.
تحفيز
في مارس 2023 ، تم اختراق شركة Euler Finance وخسر 200 مليون دولار. Euler Finance هو سوق إقراض حيث يمكن للمستخدمين إيداع الضمانات والاقتراض بضمانها. لديها بعض الميزات الفريدة ، في الواقع إنها سوق إقراض يمكن مقارنتها بـ Compound Finance و Aave.
يمكنك قراءة تشريح الجثة حول هذا الاختراق هنا. محتواه الرئيسي هو عدم وجود فحوصات صحية في وظيفة معينة ، مما يسمح للمستخدمين بكسر الثبات الأساسي لسوق الإقراض.
الأساسيات الأولياء
في جوهر معظم بروتوكولات DeFi هو الثبات ، خاصية حالة البرنامج التي من المتوقع أن تكون دائمًا صحيحة. من الممكن أيضًا أن يكون لديك العديد من الثوابت ، ولكنها بشكل عام مبنية على فكرة أساسية. وهنا بعض الأمثلة:
لم يكن الخطأ الذي حدث في Euler Finance بالضرورة هو أنهم أضافوا ميزات ، أو لم يكتبوا اختبارات ، أو لم يتبعوا أفضل الممارسات التقليدية. قاموا بتدقيق الترقية وأجروا الاختبارات ، لكنها لا تزال تتسلل عبر الشقوق. المشكلة الأساسية هي أنهم ينسون عنصرًا أساسيًا ثابتًا في سوق الإقراض (كما يفعل المدققون!).
جوهر المشكلة
ربما تفكر في "حسنًا ، هذا صحيح. لهذا السبب تم اختراقهم ؛ لقد نسوا بيان مطلوب". نعم و لا.
لكن لماذا ينسون بيان الطلب؟
تحقق - تحقق - التفاعل ليس جيدًا بما يكفي
النمط الشائع الموصى به لمطوري الصلابة هو نمط Checks-Effects-Interactions. إنه مفيد جدًا للتخلص من الأخطاء المتعلقة بالعودة ، وغالبًا ما يزيد من مقدار التحقق من صحة الإدخال الذي يتعين على المطور القيام به. \ _ولكن \ _ فهو عرضة لمشكلة عدم رؤية الغابة للأشجار.
ما يعلمه المطور هو: "أولاً أكتب بيان الطلب الخاص بي ، ثم أقوم بالتحقق ، ثم ربما أقوم بأي تفاعل ، ثم أكون آمنًا". المشكلة هي ، في أغلب الأحيان ، أنها تصبح مزيجًا من الضوابط والتأثيرات - ليس سيئًا ، أليس كذلك؟ لا تزال التفاعلات نهائية ، لذا فإن عودة الدخول ليست مشكلة. لكنه يجبر المستخدمين على التركيز على وظائف أكثر تحديدًا وتحولات الدولة الفردية بدلاً من السياق العالمي الأوسع. هذا يعني ذاك:
إن مجرد نمط التفاعل والتحقق من الصحة يجعل المطورين ينسون الثوابت الأساسية لبروتوكولاتهم.
لا يزال هذا نمطًا ممتازًا للمطورين ، ولكن يجب دائمًا ضمان ثبات البروتوكول (بجدية ، لا يزال يتعين عليك استخدام CEI!).
افعلها بشكل صحيح: وضع FREI-PI
خذ على سبيل المثال هذا المقتطف من عقد SoloMargin الخاص بـ dYdX (رمز المصدر) ، وهو سوق إقراض وعقد تداول مع الرافعة المالية. هذا مثال جيد لما أسميه بنمط متطلبات الوظيفة - التأثيرات - التفاعلات + بروتوكول Iniants ، أو نمط FREI-PI.
على هذا النحو ، أعتقد أن هذا هو سوق الإقراض الوحيد في سوق الإقراض في المرحلة المبكرة الذي لا يحتوي على أي نقاط ضعف مرتبطة بالسوق. لا يوجد لدى Compound و Aave مشاكل مباشرة ، ولكن لها مفترق طرق. وقد تم اختراق bZx عدة مرات.
افحص الكود أدناه ولاحظ التجريدات التالية:
لا يزال يتم تنفيذ عمليات الفحص والتأثيرات والتفاعلات المعتادة. من الجدير بالذكر أن عملية التحقق من الصحة والتفاعل مع عمليات التحقق الإضافية لا تعادل FREI-PI - فهي متشابهة ولكنها تخدم أهدافًا مختلفة اختلافًا جوهريًا. لذلك ، يجب على المطورين اعتبارهم مختلفين: FREI-PI ، باعتباره تجريدًا أعلى ، يهدف إلى أمان البروتوكول ، بينما يهدف CEI إلى السلامة الوظيفية.
هيكل هذا العقد مثير للاهتمام حقًا - يمكن للمستخدمين تنفيذ الإجراءات التي يريدونها (الإيداع ، والاقتراض ، والتجارة ، والتحويل ، والتصفية ، وما إلى ذلك) في سلسلة من الإجراءات. هل تريد إيداع 3 رموز مختلفة ، وسحب الرابع ، وتصفية حساب؟ إنها مكالمة واحدة.
هذه هي قوة FREI-PI: يمكن للمستخدمين فعل ما يريدون ضمن البروتوكول ، طالما أن ثوابت سوق الإقراض الأساسي في نهاية المكالمة: لا يمكن لمستخدم واحد اتخاذ أي إجراء من شأنه أن يجعل أي حساب غير آمن أو أكثر من مواقع الضمانات غير الآمنة. بالنسبة لهذا العقد ، يتم تنفيذ ذلك في \ _verifyFinalState ، والتحقق من ضمانات كل حساب متأثر للتأكد من أن الاتفاقية أفضل مما كانت عليه عندما بدأت المعاملة.
هناك بعض الثوابت الإضافية المضمنة في هذه الوظيفة التي تكمل الثوابت الأساسية وتساعد في الوظائف الجانبية مثل إغلاق الأسواق ، لكن عمليات الفحص الأساسية هي التي تحافظ حقًا على أمان البروتوكول.
FREI-PI المرتكزة على الكيان
مشكلة أخرى مع FREI-PI هي مفهوم الكيان. خذ سوق الإقراض والثوابت الأساسية المفترضة كمثال:
من الناحية الفنية ، ليس هذا هو المتغير الوحيد ، ولكنه يتعلق بكيان المستخدم (لا يزال أحد البروتوكولات الأساسية الثابتة ، وعادة ما تكون ثوابت المستخدم هي ثوابت البروتوكول الأساسية). عادة ما يكون لأسواق الإقراض كيانان إضافيان:
كل ثبات إضافي يجعل البروتوكول أكثر صعوبة في ضمانه ، وبالتالي كلما كان ذلك أفضل. هذا في الواقع ما قاله دان إليتسر في مقالته بعنوان: لماذا تم كسر DeFi وكيف يتم إصلاحه # 1 بروتوكول أقل أوراكل (تلميح: المقالة لا تقول في الواقع أن الأوراكل هي المشكلة).
وحي
بالنسبة إلى oracles ، خذ استغلال Cream Finance بقيمة 130 مليون دولار. الثبات الأساسي لكيانات أوراكل:
كما اتضح ، فإن التحقق من oracles في وقت التشغيل باستخدام FREI-PI أمر صعب ، ولكنه ممكن ، مع بعض التفكير. بشكل عام ، يعد Chainlink خيارًا جيدًا للاعتماد عليه في الغالب ، مما يرضي معظم الثبات. في حالة نادرة من التلاعب أو المفاجأة ، قد يكون من المفيد أن يكون لديك ضمانات تقلل المرونة لصالح الدقة (مثل التحقق من أن آخر قيمة معروفة كانت أكبر بنسبة مئوية قليلة من القيمة الحالية). أيضًا ، يقوم نظام SoloMargin الخاص بـ dYdX بعمل رائع مع أوراكل DAI ، إليك الكود (إذا كنت لا تستطيع معرفة ذلك ، أعتقد أنه أفضل نظام عقد ذكي معقد تمت كتابته على الإطلاق).
لمزيد من المعلومات حول تقييم oracle ، وتسليط الضوء على قدرات فريق Euler ، كتبوا مقالة جيدة عن التلاعب الحسابي بأسعار Uniswap V3 TWAP oracle.
الإدارة / الحكم
يعد إنشاء الثوابت للكيانات المُدارة هو الأصعب. هذا يرجع بشكل أساسي إلى حقيقة أن معظم دورهم هو تغيير الثوابت الأخرى الموجودة. ومع ذلك ، إذا كان بإمكانك تجنب استخدام الأدوار الإدارية ، فيجب عليك ذلك.
بشكل أساسي ، قد تكون الثوابت الأساسية للكيان المُدار هي:
التفسير: يمكن للمسؤولين القيام بأشياء يجب أن تنتهي بعدم كسر الثوابت ، ما لم يغيروا الأشياء بشكل جذري لحماية أموال المستخدمين (على سبيل المثال: نقل الأصول إلى عقد الإنقاذ هو إزالة الثوابت). يجب أيضًا اعتبار المسؤولين مستخدمين ، لذلك يجب أيضًا أن يكون ثبات المستخدم في سوق الإقراض الأساسي مناسبًا لهم (بمعنى أنهم لا يستطيعون مهاجمة المستخدمين الآخرين أو البروتوكولات). حاليًا ، من المستحيل التحقق من بعض إجراءات المسؤول في وقت التشغيل عبر FREI-PI ، ولكن مع وجود ثوابت قوية بدرجة كافية في أماكن أخرى ، نأمل أن يتم تخفيف معظم المشكلات. أقول حاليًا ، لأنه يمكن للمرء أن يتخيل استخدام نظام zk proof الذي قد يتحقق من حالة العقد بالكامل (لكل مستخدم ، لكل أوراكل ، إلخ).
كمثال على كسر المسؤول للثبات ، اتخذ إجراء الحوكمة المركب الذي عمل على اختراق سوق CETH في أغسطس 2022. بشكل أساسي ، تكسر هذه الترقية ثبات Oracle: توفر Oracle معلومات دقيقة (نسبيًا) في الوقت الفعلي. نظرًا لعدم وجود وظائف ، يمكن أن توفر Oracle معلومات غير صحيحة. يمكن أن يؤدي التحقق من FREI-PI في وقت التشغيل ، والتحقق من أن Oracle المتأثرة إلى توفير معلومات في الوقت الفعلي ، إلى منع حدوث ذلك مع الترقية. يمكن دمج هذا في \ _setPriceOracle للتحقق مما إذا كانت جميع الأصول قد تلقت معلومات الوقت الفعلي. الشيء الجميل في FREI-PI لأدوار المسؤول هو أن أدوار المسؤول غير حساسة نسبيًا للسعر (أو على الأقل يجب أن تكون كذلك) ، لذلك لا ينبغي أن يكون استخدام الغاز مشكلة كبيرة.
التعقيد خطير
لذا في حين أن أهم الثوابت هي الثوابت الأساسية للبروتوكول ، يمكن أن يكون هناك أيضًا بعض الثوابت التي تتمحور حول الكيان والتي يجب أن تحتفظ بها الثوابت الأساسية. ومع ذلك ، فإن أبسط (وأصغر) مجموعة من الثوابت هي على الأرجح الأكثر أمانًا. البساطة جيدة والمثال الساطع هو Uniswap ...
لماذا لم يتم اختراق Uniswap مطلقًا (ربما)
يمكن أن تحتوي AMMs على أبسط ثوابت أساسية لأي DeFi بدائي: tokenBalanceX \ * tokenBalanceY == k (مثل نموذج المنتج الثابت). تدور كل وظيفة في Uniswap V2 حول هذا الثابت البسيط:
السر الأمني لـ Uniswap V2: الجوهر هو ثبات بسيط ، وجميع الوظائف في خدمته. الكيان الآخر الوحيد الذي يمكن الجدال فيه هو الحوكمة ، والتي يمكنها تشغيل مفتاح الرسوم ، والذي لا يمس الثبات الأساسي ، بل فقط توزيع ملكية رصيد الرمز المميز. هذه البساطة في بيان الأمان الخاص بهم هو سبب عدم اختراق Uniswap مطلقًا. البساطة في الواقع ليست ازدراء للمطورين الممتازين لعقود Uniswap الذكية ، بل على العكس من ذلك ، يتطلب الأمر مهندسين ممتازين لإيجاد البساطة.
مشكلة الغاز
يمتلئ موقع تويتر الخاص بي بالفعل بصراخ المتفائلين من الرعب والألم بأن هذه الفحوصات غير ضرورية وغير فعالة. شيئين حول هذا السؤال:
إذا كانت التكلفة باهظة ، فأعد التفكير في المتغيرات الأساسية وحاول التبسيط.
ماذا يعني هذا بالنسبة لي؟
بصفتك مطورًا ، من المهم تحديد الثوابت الأساسية والتعبير عنها في وقت مبكر من عملية التطوير. كاقتراح ملموس: الوظيفة الأولى لكتابة نفسك هي \ _verifyAfter ، للتحقق من ثوابتك بعد كل مكالمة لعقدك. ضعها في عقدك ، وانشرها هناك. قم بتكملة هذا المتغير (وغيره من الثوابت المتمركزة حول الكيان) باختبارات ثابتة أوسع يتم فحصها قبل النشر (دليل المسبك).
تفتح المتاجر العابرة بعض التحسينات والتحسينات المثيرة للاهتمام التي ستختبرها شركة Nascent - أقترح عليك التفكير في كيفية استخدام المتاجر المؤقتة كأداة لتحسين الأمان عبر سياقات المكالمات.
في هذه المقالة ، لم يتم قضاء الكثير من الوقت في إدخال نموذج FREI-PI للتحقق من صحة الإدخال ، ولكنه أيضًا مهم جدًا. يعد تحديد حدود الإدخال مهمة صعبة لتجنب الفائض والمواقف المماثلة. ضع في اعتبارك التحقق من ومتابعة تقدم أداتنا: البيرومتر (حاليًا في مرحلة تجريبية ، يرجى إعطائنا نجمة). يمكن أن يتعمق ويساعدك في العثور على الأماكن التي قد لا تقوم فيها بالتحقق من صحة الإدخال.
ختاماً
علاوة على أي اختصار جذاب (FREI-PI) أو اسم مخطط ، فإن الجزء المهم حقًا هو:
ابحث عن البساطة في الثبات الأساسي للبروتوكول الخاص بك. واعمل مثل الجحيم للتأكد من عدم تدميره (أو الإمساك به قبل أن يحدث).