من المؤكد أن التمويل اللامركزي يمكن أن يحقق فوائد كبيرة للمستخدمين، ولكن الأمن المالي هو جوهر النمو المطرد للأصول. قام فريق أمان Cobo بفرز المخاطر الأمنية الشائعة في تفاعلات DeFi والاحتياطات الأمنية المقابلة، على أمل إلهام ومساعدة تفاعلات DeFi الأمنية للجميع في السوق الصاعدة.
منذ إطلاق DeFi Summer في عام 2019، ظهر المزيد والمزيد من البروتوكولات المالية اللامركزية الإبداعية (DeFi)، بقيادة بروتوكول Ethereum)، مما يثري بشكل كبير توفر الأصول الموجودة على السلسلة، مما يسمح لمستخدمي blockchain بالاستفادة بشكل أفضل من الأصول الموجودة على السلسلة لإجراء أنشطة مالية أكثر تنوعًا وتحقيق عوائد كبيرة. ولكن مع ظهور المزيد والمزيد من بروتوكولات التمويل اللامركزي، تظهر أيضًا تحديات أمنية. وفقًا لإحصائيات غير كاملة، في عام 2023 وحده، وصلت خسائر الأصول الناجمة عن هجمات blockchain إلى 2.61 مليار دولار أمريكي. يمكن ملاحظة أنه في عملية المشاركة في بروتوكول DeFi، بالإضافة إلى تقييم توقعات الإيرادات المقابلة، لا يمكن تجاهل تقييم أمان البروتوكول، وإلا فإنه سيجلب خسائر كبيرة للمستخدمين.
بشكل عام، التعريف السائد الحالي لتقييم أمان البروتوكول هو تقييم أمان الكود. بُعد هذا التعريف فردي نسبيًا. المشكلة هنا هي التقييم نفسه يأخذ في الاعتبار فقط أمان البروتوكول في العملية الثابتة، بينما في عملية تفاعل DeFi، غالبًا ما يكون الأمان ديناميكيًا، بما في ذلك إدارة الحساب والتحضير قبل تفاعل البروتوكول وإدارة الأصول بعد اكتمال التفاعل ومراقبة البيانات ومراحل متعددة بما في ذلك الإنقاذ الذاتي بعد خسارة الأصول في ظل الظروف القصوى.
باعتبارك مستخدمًا على وشك الدخول إلى DeFi Novice Village، كيف يمكنك تحقيق أقصى قدر من الأمان لأموالك مع تحقيق الدخل؟ قام فريق Cobo الأمني بفرز المخاطر الأمنية الشائعة في تفاعلات DeFi والاحتياطات الأمنية المقابلة، على أمل إلهام ومساعدة تفاعلات DeFi الأمنية للجميع في السوق الصاعدة.
المخاطر الأمنية الشائعة والاحتياطات في تفاعلات DeFi
1. تسرب المفتاح الخاص للحساب
تسرب المفتاح الخاص للحساب هذا هو إحدى المشاكل التي من المرجح أن يقع فيها المستخدمون المبتدئون، نظرًا للتنوع الكبير للمحافظ في السوق، يفتقر المستخدمون المبتدئون إلى القدرة على الحكم على مدى أمان المحافظ بأنفسهم، حيث يقوم العديد من المستخدمين المبتدئين بتنزيل بعض المحافظ غير الآمنة واستخدامها لإنشاء مفاتيح خاصة، مما يتسبب في نقل المفتاح الخاص بشكل ضار مرة أخرى إلى المهاجم، مما يتسبب في تسرب المفتاح الخاص. وجد العديد من المستخدمين ذوي الخبرة أن جميع أصولهم تم نقلها من حسابهم الرئيسي في يوم معين، وبعد تحليل معظم اليوم، وجدوا أن جميع السلوكيات كانت طبيعية، وفي معظم هذه الحالات، استخدم الحساب محفظة غير آمنة لإنشاء مفتاحه الخاص. لقد تم تسريب المفتاح الخاص منذ فترة طويلة.
في الوقت نفسه، نظرًا لتأثير الثروة الناجم عن عمليات الإسقاط الجوي لـ blockchain، سينقر العديد من المستخدمين المبتدئين بشكل أعمى على بعض ما يسمى بمواقع الإسقاط الجوي. حزم مواقع الإسقاط الجوي هذه أنفسهم كصفحة ويب لمشروع جاد للغاية وإبلاغ المستخدمين بوجود عدد كبير من الرموز المميزة التي لم تتم المطالبة بها. مدفوعًا بالربح، سيتم حث العديد من المستخدمين المبتدئين من خلال صفحات الويب على ملء المفاتيح الخاصة لحسابهم الخاص، مما يتسبب في تسرب المفاتيح الخاصة.
لمنع تسرب المفاتيح الخاصة، يحتاج المستخدمون إلى القيام بما يلي لمنع ذلك:
استخدم محفظة blockchain معروفة وقم بتنزيل المحفظة من الموقع الرسمي المقابل. يُنصح المستخدمون المؤهلون باستخدام محافظ الأجهزة.
لا تعرض مطلقًا مفتاحك الخاص بنص عادي على الإنترنت، ولا تكشف مفتاحك الخاص بشكل تعسفي مفتاح الإنترنت أدخل مفتاحك الخاص في أي صفحة ويب.
2. خطر التصيد الاحتيالي للتوقيع
مخاطر التصيد الاحتيالي للتوقيع هي نفس مخاطر تسرب المفتاح الخاص، وهي أيضًا المنطقة الأكثر تضرراً بالنسبة للمستخدمين المبتدئين. ويختلف هذا النوع من هجمات التصيد الاحتيالي عن مطالبة المستخدمين مباشرة بملء مفاتيحهم الخاصة، وهو يحث المستخدمين على بدء معاملة أو توقيع للحصول على ترخيص للأصول المتعلقة بالمستخدم. وهو مخفي إلى حد كبير، ويصعب تحليله، ويصعب اكتشافه.
عادةً ما يقوم المهاجم أولاً بحث المستخدم على الوصول إلى صفحة ويب للتصيد الاحتيالي، والسماح للمستخدم ببدء التوقيع باسم تلقي عمليات الإنزال الجوي، والتحقق من تسجيل الدخول، وما إلى ذلك. في هذا الوقت، يقوم تصفح المستخدم لمحفظة الخادم بمطالبة المستخدم بإكمال التوقيع.
قد يكون هناك العديد من أنواع معاملات التصيد الاحتيالي:
نوع النقل المباشر. قم بتحويل ETH مباشرة أو قم بإجراء مكالمة تحويل ERC20 لنقل أصول المحفظة إلى عنوان المهاجم.
الموافقة على النوع. اتصل بطريقة ERC20 Approve لتخويل محفظة المهاجم. لا يحدث أي نقل للأصول عندما يقوم المستخدم بالتوقيع. ومع ذلك، يمكن لمحفظة المهاجم نقل أصول المستخدم عن طريق استدعاء TransferFrom.
توقيع الرسالة EIP712. مثل طريقة تصريح ERC20، وتفويض Permit2، وتوقيع أمر NFT المعلق، وما إلى ذلك. عادةً ما يتم عرض هذه التوقيعات في المحفظة كبيانات Json أو بيانات شجرة جيدة التنسيق. لن يتم بدء أي معاملة عندما يقوم المستخدم بالتوقيع، ولن يكون هناك استهلاك للغاز. ومع ذلك، سيتم تسجيل نتيجة التوقيع بواسطة موقع التصيد الاحتيالي، ويمكن للمهاجم استخدام نتيجة التوقيع لنقل أصول ERC20 أو NFT الخاصة بالضحية.
توقيع التجزئة الأصلي. بيانات التوقيع هي بيانات تجزئة سداسية عشرية، ولا يمكن استنتاج محتوى التوقيع المحدد من بيانات التوقيع نفسها. قد يكون خلف التجزئة أنواع البيانات 1-3 المذكورة أعلاه. من المرجح أن تؤدي التوقيعات إلى خسارة الأصول. ومع ذلك، عادةً ما تحظر المحافظ السائدة الحالية طريقة التوقيع هذه أو تقدم تحذيرات واضحة بشأن المخاطر.
في الحالات الأخيرة، تبين أن بعض مواقع التصيد الاحتيالي ستطلب من المستخدمين التوقيع عدة مرات متتالية، وسيقوم التوقيعات القليلة الأولى هي توقيع عادي غير ضار. ثم قم بخلط التوقيع الخبيث. استخدم القصور الذاتي التشغيلي للمستخدم لحث المستخدم على إكمال عملية التوقيع.
من أجل منع الخسائر المالية الناجمة عن التصيد الاحتيالي، الأساس هو رفض التوقيع الأعمى. راجع كل توقيع بعناية وارفض التوقيع على المعاملات ذات المحتوى غير المؤكد. على وجه التحديد، يمكنك الانتباه إلى ما يلي أثناء عملية التوقيع:
تأكيد التفاعل الموقع هو الموقع الرسمي لمشروع DeFi، تحقق من اسم النطاق الكامل.
التحقق من الطرق التي يستدعيها العقد، مع التركيز على طرق النقل والموافقة.
تحقق من تحويل ETH المرفق بالمعاملة. ستحاول بعض مواقع التصيد الاحتيالي إنشاء طرق تبدو آمنة (مثل المطالبة)، ولكنها ستتضمن في الواقع نقل ETH عند الاتصال، مما يتسبب في فقدان الرموز المميزة للسلسلة مثل ETH.
لا توقع على محتوى التجزئة الأصلي.
3. تسميم عنوان النقل
< p style="text-align: left;">يعد تسميم عنوان النقل طريقة هجوم جديدة نسبيًا مؤخرًا. تتمثل طريقة الهجوم في استخدام نفس الطريقة المستلمة في المعاملة عندما يبدأ المستخدم عملية نقل (ERC20، الرمز المميز الأصلي، وما إلى ذلك). ) ترسل العناوين ذات العناوين المتشابهة للمستخدمين معاملة بنفس المبلغ، أو معاملة بنفس المبلغ ولكن الرمز المميز المقابل هو رمز مزيف.
مثال:
تقوم أليس بتحويل 1 ETH إلى Bob براتب كل شهر. راقب تشارلي هذه المعاملة وأرسل 0.001 إيثريوم إلى أليس باستخدام عنوان مشابه لعنوان بوب (أول 8 أرقام وآخر 8 أرقام من العنوان هي نفسها). بعد هذه العملية، في المرة التالية التي تقوم فيها أليس بتحويل الأموال إلى بوب، من الممكن استخدام عنوان تشارلي كعنوان استلام المعاملة. السبب وراء حدوث ذلك هو أن عناوين blockchain طويلة وغير منتظمة، مما يجعل من الصعب على المستخدمين تذكرها. ونتيجة لذلك، يقوم المستخدمون في كثير من الأحيان بنسخ العنوان مباشرة من سجل المعاملة الأخيرة من أجل الراحة. نظرًا لأن عنواني تشارلي وبوب متشابهان جدًا، فمن الصعب على أليس التمييز بينهما، مما يؤدي في النهاية إلى خسارة الأصول.
من أجل منع تسميم عناوين النقل، يمكن للمستخدمين اتخاذ الاحتياطات التالية:
تحقق من عنوان النقل لكل معاملة، وتحقق من المحتوى الكامل بدلاً من مجرد مقارنة بضع بايتات قبل وبعد.
قم بتعيين العناوين المستخدمة بشكل متكرر في القائمة البيضاء للعناوين (دفتر العناوين) وقم بتعيين الأسماء المستعارة قدر الإمكان استخدم فقط العناوين الموجودة في دفتر العناوين الخاص بك لعمليات النقل.
تجنب استخدام القنوات الموجودة على السلسلة (بما في ذلك متصفحات blockchain وسجلات معاملات المحفظة وما إلى ذلك) نسخ العنوان كوجهة النقل.
4. الإفراط في تفويض الرموز المميزة
يعد ترخيص الرمز المميز تقريبًا الخطوة الأولى في تفاعل DeFi. عند تنفيذ عمليات DeFi، نظرًا لأنه يتم إنشاء بيانات المعاملة من خلال صفحة الويب الخاصة بالمشروع بدلاً من بنية المستخدم، في ظل الظروف العادية، من أجل تسهيل تفاعلات المستخدم المتعددة دون إذن متكرر، تقوم صفحة الويب الخاصة بالمشروع عادةً بإنشاء معاملة ترخيص غير محدودة للمستخدم. لافتة. نقطة البداية هي توفير الوقود للمستخدمين، ولكن هذا يخلق أيضًا مخاطر خفية على أمن الأموال لاحقًا. على افتراض حدوث مشاكل في رموز المشروع اللاحقة، مثل الواجهات غير المصرح بها أو ثغرات الاتصال التعسفية، سيتم استغلال التفويض غير المحدود للمستخدم للعقد من قبل المهاجمين، مما يؤدي إلى نقل أصول المستخدم. يعد سيناريو الهجوم هذا أكثر شيوعًا في الجسور عبر السلسلة وبروتوكولات DEX.
من أجل منع المشاريع اللاحقة من إدخال تعليمات برمجية محفوفة بالمخاطر في الترقيات أو من نقاط الضعف غير المكتشفة في رمز المشروع نفسه، يجب على المستخدمين اعتماد مبدأ الحد الأدنى من التفويض وحاول فقط اعتماد المبلغ المستخدم في هذه المعاملةلمنع مخاطر المشروع اللاحقة من التسبب في خسائر لأصولك.
5. عمليات التمويل اللامركزي غير الآمنة
بالإضافة إلى التحضير قبل التفاعل، هناك أيضًا العديد من المخاطر التي يمكن التغاضي عنها بسهولة أثناء عملية التفاعل. تنشأ هذه المخاطر عادة من عدم فهم المستخدمين للمشروع نفسه. الأمثلة المحددة هي:
الانزلاق أثناء تبادل الرمز المميز من خلال بروتوكول التبادل على السلسلة إذا كان الإعداد إذا كانت كبيرة جدًا أو لم يتم تعيين الحد الأدنى لكمية الاستلام في البرنامج النصي للمبادلة (تم ضبطها على 0 لسهولة الكتابة)، فستتعرض المعاملة لهجوم "ساندويتش" بواسطة روبوت MEV.
عند إجراء عمليات الإقراض من خلال اتفاقية الإقراض عبر السلسلة، لم تتم إدارة صحة الموقف في الوقت المناسب، مما أدى إلى في خسارة المراكز خلال تقلبات السوق الكبيرة.
عند التفاعل مع بعض المشاريع، لم يتم الاحتفاظ ببيانات اعتماد طرف المشروع بشكل جيد، مثل التعامل مع بيانات اعتماد NFT الخاصة بـ Uniswap V3 على أنها NFT العادي يباع في OpenSea.
من أجل منع هذه المخاطر، يجب على المستخدمين إجراء بحث المشروع المقابل وتوضيح آلية المشروع والميزات ذات الصلة لمنع فقدان الأصول .
نموذج DeFi الجديد للمعاملات الآمنة - Cobo Argus
يقدم ما ورد أعلاه مخاطر التفاعل الشائعة لأنشطة DeFi على blockchain. إذا وقع المستخدم عن طريق الخطأ في أحد هذه الفخاخ، فقد يضيع سنوات من العمل الشاق، وحتى أدنى إهمال سيؤدي إلى ضرر لا يمكن إصلاحه. إذًا، هل هناك خطة للتحكم في المخاطر آمنة وفعالة وسهلة الإدارة؟ الخيار الجديد هو Cobo Argus.
Cobo Argus هو منتج للتحكم في المخاطر على السلسلة تم تطويره بواسطة فريق Cobo ومبني على Gnosis Safe. وتتمثل المهمة الرئيسية في تحليل معاملات المستخدم من خلال بناء استراتيجيات مختلفة لـ ACL واعتراض المعاملات التي لا تتوافق مع قواعد مراقبة المخاطر، وبالتالي ضمان سلامة أموال المستخدم.
كيف يتعامل Cobo Argus مع المخاطر الأمنية في بيئة DeFi؟
1. محفظة متعددة التوقيع على المستوى السفلي، وتفويض توقيع فردي على المستوى العلوي: تجنب النقطة الواحدة خطر تسرب المفتاح الخاص، والإبطاء، والقضاء على مخاطر التصيد الاحتيالي مع ضمان الكفاءة التشغيلية
Cobo Argus هو منتج مبني على ميزات Safe {Wallet} المتعددة -محفظة التوقيع أساسها وجوهرها محفظة عقود متعددة التوقيع. لذلك، يرث Cobo Argus بشكل طبيعي أمان المحفظة متعددة التوقيع Safe {Wallet}.
من خلال تغيير إدارة الأموال من مفتاح خاص واحد إلى الصيانة المشتركة لمفاتيح خاصة متعددة، فإن خطر فقدان/قفل الأصول الناجم عن تسرب مفتاح خاص يمكن التخلص من مفتاح خاص واحد. تتطلب المحفظة متعددة التوقيع نفسها توقيعات متعددة لبدء تنفيذ المعاملات، ولن يؤثر تسرب المفتاح الخاص لعنوان واحد على الأمان العام للأموال. بالإضافة إلى ذلك، يمكن بدء معاملات متعددة التوقيع لاستبدال عناوين التوقيع الفردي المفقودة أو المحفوفة بالمخاطر لضمان أمان المحفظة متعددة التوقيع.
بالإضافة إلى ذلك، بعد التبديل من عنوان توقيع واحد إلى عنوان متعدد التوقيع، يُطلب من كل مستخدم التوقيع على معاملة عند التوقيع على معاملة، وهو أمر مناسب للتدقيق المتبادل ومحتوى المعاملات، مما يقلل بشكل كبير من احتمالية التعرض للتصيد الاحتيالي.
تتطلب التوقيعات المتعددة مراجعة عدة أشخاص، وهو ما له تأثير معين على الكفاءة التشغيلية. يسمح Cobo Argus للمستخدمين بتكوين قواعد ترخيص مرنة، مما يسمح بترخيص بعض العمليات عالية التردد منخفضة المخاطر (مثل المطالبات المنتظمة بالدخل أثناء الزراعة) إلى عنوان EOA معين. يمكن لهذا العنوان بدء العمليات بدلاً من المحفظة متعددة التوقيع لتحسين كفاءة العمل. وفي الوقت نفسه، نظرًا لأن أذونات العنوان مقيدة بشكل صارم، فلن يتأثر الأمان العام للمحفظة بشكل كبير.
2. روبوت مخصص: مراقبة المخاطر والاستجابة لها تلقائيًا على مدار 7*24 ساعة
من خلال تكوين روبوت المراقبة Cobo Argus، يمكنك تخصيص الظروف التي تحتاج إلى مراقبة والعمليات التي يجب تنفيذها عند تشغيل الظروف.
خذ إدارة الرافعة المالية لمشاريع الإقراض كمثال. يمكن للمستخدمين تكوين روبوت Argus لمراقبة عامل صحتهم. عندما يقترب المركز من التصفية، يقوم الروبوت يمكن أن تكمل الرهن العقاري عمليات خفض الرافعة المالية مثل الممتلكات والسداد.
3. سياسة ACL المخصصة
بالإضافة إلى الذات - بالإضافة إلى تعريف روبوتات المراقبة، يمكن للمستخدمين الذين يتمتعون بقدرات تطوير معينة أيضًا تطوير عقود ACL (قائمة التحكم في الوصول) المخصصة لتحقيق إدارة أذونات أكثر مرونة. هذه إحدى الميزات الأساسية لـ Cobo Argus. فيما يلي بعض الأمثلة للشعور بسحر هذه الميزة:
الموضع يعتمد على العنوان لمنع الهجمات السامة، يمكنك كتابة عقد ACL. يمكن للمستخدمين تحديد العناوين شائعة الاستخدام كقوائم بيضاء في عقد ACL. أثناء عملية المعاملة، سيقوم عقد ACL بتحليل عنوان الاستلام في المعاملة (ERC20/الرمز المميز الأصلي). و قارن عناوين القائمة البيضاء التي حددها المستخدم، وإذا لم يكن عنوان الاستلام ضمن العنوان المقابل، فلا يمكن إكمال المعاملة بنجاح.
لمعالجة مشكلة الإفراط في التفويض، يمكن للمستخدمين كتابة عقد سياسة ACL لتعيين حد التفويض في الموافقة على المعاملات، قم بتحليل وتقييد مبلغ تفويض الموافقة للرمز المميز بما لا يزيد عن القيمة المحددة مسبقًا للمستخدم. أو 1، يمكنك تكوين روبوت مخصص لمسح ترخيص الرموز المميزة ذات الصلة بانتظام.
بالنسبة لعمليات DeFi غير الآمنة، مثل معاملات المبادلة دون التحقق من الانزلاق، يمكنك كتابة قائمة Argus ACL يحدد عقد الإستراتيجية الحد الأدنى من الانزلاق المقبول لمعاملات الصرف، وبعد اكتمال الإعداد، يمكن لعقد إستراتيجية ACL تحليل معاملات المبادلة المختلفة بناءً على الانزلاق المحدد، إذا لم يتم استيفاء انزلاق الصرف، فيمكن اعتراض المعاملة.
الملخص
هناك العديد من المخاطر التي يصعب منعها في تفاعلات DeFi، وعلى الرغم من أن المحتوى المذكور في المقالة يغطي العديد من السيناريوهات الشائعة، إلا أنه لا يمكن أن يغطي جميع نقاط الخطر بشكل كامل. يحتاج المستخدمون إلى التعامل مع كل معاملة بعناية.
يمكن أن يوفر Cobo Argus للمستخدمين وسائل موثوقة وسهلة التكوين لمنع بعض المخاطر الأمنية الشائعة. يمكن إكمال إدارة التفويض المرنة والآمنة من خلال ACL، مما يحسن الكفاءة التشغيلية مع ضمان الأمان؛ يمكن للروبوتات المخصصة تقليل العمليات اليدوية، بينما يمكن لقدرات المراقبة في الوقت الفعلي ضمان أمان أموال المستخدم 7 * 24 ساعة.
من المؤكد أن التمويل اللامركزي يمكن أن يحقق فوائد كبيرة للمستخدمين، ولكن الأمن المالي هو جوهر النمو المطرد للأصول. سيعمل Cobo Argus على حماية كل مزارع DeFi ومساعدة الجميع على خلق قيمة أكبر في السوق الصاعدة.
JinseFinance
Darren
Tech Flow
Coindesk
Coinlive 
Bitcoinist
Cointelegraph