آلية Hook في Uniswap v4: الفرص والتحديات موجودة

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

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

الآلية الأساسية لـ Uniswap V4

قبل الخوض في مسائل الأمان، نحتاج أولاً إلى فهم بعض الآليات الأساسية لـ Uniswap v4:

آلية هوك

Hook هو عقد يعمل في مراحل مختلفة من دورة حياة تجمع السيولة. يوجد حاليًا 8 استدعاءات لـ Hook، مقسمة إلى 4 مجموعات:

• قبل التهيئة/بعد التهيئة
• قبل تعديل الموضع/بعد تعديل الموضع
• قبل التبديل/بعد التبديل
• قبل التبرع/بعد التبرع

من خلال آلية Hook، يمكن تحقيق دعم أصلي للرسوم الديناميكية، وإضافة أوامر سعرية على السلسلة، وتنفيذ صفقات سوقية موزعة على أوامر كبيرة باستخدام المتوسط المرجح زمنياً (TWAMM).

! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)

بنية الأحادية وتسجيل الحسابات السريعة

اعتمد Uniswap v4 بنية أحادية، حيث يتم حفظ جميع برك السيولة في نفس العقد الذكي. يعتمد ذلك على PoolManager لتخزين وإدارة حالة جميع البرك.

تعتبر المحاسبة الفورية آلية جديدة للمحاسبة. لم تعد العمليات تنقل الرموز مباشرة، بل تعدل الرصيد الصافي الداخلي. يتم إجراء التحويل الفعلي في نهاية العملية.

آلية القفل

آلية القفل لمنع الوصول المتزامن، وضمان تسوية جميع المعاملات. تتلخص العملية الرئيسية فيما يلي:

1. طلب قفل عقد locker
2. يقوم PoolManager بإضافة عنوان القفل إلى قائمة الانتظار واستدعاء رد النداء الخاص به.
3. منطق تنفيذ القفل، التفاعل مع الحوض
4. يقوم PoolManager بفحص الحالة، وحذف القفل

بسبب آلية القفل، لا يمكن للحسابات الخارجية التفاعل مباشرة مع PoolManager، بل يجب القيام بذلك من خلال العقد.

نموذج التهديد

نحن نفكر بشكل أساسي في نوعين من نماذج التهديد:

• نموذج التهديد I: Hook نفسه غير ضار، ولكن يوجد ثغرات
• نموذج التهديد II: هوك نفسه خبيث

قضايا الأمان في نموذج التهديد I

نحن نركز بشكل أساسي على الثغرات المحتملة الخاصة بالإصدار v4، خاصة تلك التي تتعلق بمنطق واجهة Hook القياسية. نركز بشكل خاص على نوعين من Hooks:

1. هوك لحفظ أموال المستخدمين
2. هوك لتخزين بيانات الحالة الرئيسية

من خلال تحليل مشاريع أمثلة المجتمع، اكتشفنا بعض الثغرات الخطيرة، والتي تنقسم بشكل أساسي إلى فئتين:

مشكلة التحكم في الوصول

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

مشكلة تحقق الإدخال

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

! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)

مشاكل الأمان في نموذج التهديد II

نحن نقسم Hook إلى فئتين للنقاش:

نموذج الاستضافة Hook

يتفاعل المستخدمون مع Hook من خلال أجهزة التوجيه. على الرغم من صعوبة سرقة الأصول مباشرة، إلا أنه قد يكون من الممكن التلاعب بآلية إدارة الرسوم.

نوع مستقل من هوك

يمكن للمستخدمين التفاعل مباشرة مع Hook، مما يمنح Hook المزيد من القوة. إذا كان Hook قابلاً للتحديث، فقد يشكل ذلك خطرًا كبيرًا.

تدابير الوقاية

بالنسبة لنموذج التهديد I:

• تنفيذ ضوابط الوصول اللازمة
• التحقق من معلمات الإدخال
• إضافة حماية من إعادة الدخول

نموذج التهديد الثاني:

• تقييم ما إذا كان Hook ضارًا
• متابعة سلوك إدارة التكاليف ( نموذج وصاية )
• متابعة ما إذا كان من الممكن ترقية ( نوع مستقل )

تناقش هذه المقالة بشكل أولي قضايا الأمان المتعلقة بآلية Hook في Uniswap v4. في المقالات اللاحقة، سنقوم بإجراء تحليل أعمق لقضايا الأمان تحت كل نموذج تهديد.

! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp)