لماذا يُقال إن Hook هو "سيف ذو حدين" في Uniswap V4؟

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

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

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

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

ميكانيكا ### Uniswap V4

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

1.1 خطاف

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

هناك ثمانية استدعاءات Hook حاليًا ، مقسمة إلى أربع مجموعات (كل مجموعة تحتوي على زوج من الاستدعاءات):

• قبل التهيئة/بعد التهيئة

• قبل تعديل الموضع/بعد تعديل الموضع

• قبل التبادل/بعد التبادل

• قبلالتبرع/بعدالتبرع

1.2 نمط المفرد، حساب البرق وآلية القفل

تهدف بنية النمط الفردي وتسجيل المعاملات السريعة إلى تحسين الأداء من خلال خفض التكاليف وضمان الكفاءة. إنها تقدم عقدًا جديدًا من نوع singleton، حيث يتم الاحتفاظ بجميع أحواض السيولة في نفس العقد الذكي. يعتمد هذا التصميم الفردي على PoolManager لتخزين وإدارة حالة جميع الأحواض.

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

آلية عمل نظام القفل كما يلي:

1. يطلب عقد locker معين القفل في PoolManager.

2. PoolManager يضيف عنوان عقد locker إلى قائمة lockData، ثم يستدعي رد الاتصال lockAcquired.

3. يتم تنفيذ منطق عقد الlocker في رد الاتصال. خلال عملية التنفيذ، قد تؤدي تفاعلات عقد الlocker مع المسبح إلى زيادة غير صفرية في العملات. ومع ذلك، يجب تسوية جميع الزيادات إلى صفر عند انتهاء التنفيذ. بالإضافة إلى ذلك، إذا كانت قائمة lockData غير فارغة، يمكن لعقد الlocker الأخير فقط تنفيذ العمليات.

4. يقوم PoolManager بفحص حالة قائمة lockData وزيادة العملة. بعد التحقق، سيقوم PoolManager بحذف عقدة الـ locker.

باختصار، تمنع آلية القفل الوصول المتزامن وتضمن تسوية جميع المعاملات. يتم تقديم طلب القفل حسب الترتيب من خلال عقد locker، ثم يتم تنفيذ المعاملة عبر رد الاتصال lockAcquired. قبل وبعد كل عملية في المسبح، سيتم تفعيل رد الاتصال المناسب. أخيرًا، سيتحقق PoolManager من الحالة.

هذه الطريقة تعني أن التعديلات التي تتم على العمليات تتعلق بالرصيد الصافي الداخلي، بدلاً من إجراء تحويلات فورية. سيتم تسجيل أي تعديلات في الرصيد الداخلي للخزانة، بينما تتم التحويلات الفعلية عند انتهاء العملية. تضمن هذه العملية عدم وجود رموز غير مسددة، مما يحافظ على سلامة الأموال.

نظرًا لوجود آلية القفل، لا يمكن لجميع الحسابات الخارجية (EOA) التفاعل مباشرة مع PoolManager. بدلاً من ذلك، يجب أن يتم أي تفاعل من خلال عقد. يعمل هذا العقد كقفل وسيط، ويجب طلب القفل قبل القيام بأي عمليات على المسبح.

يوجد نوعان رئيسيان من سيناريوهات التفاعل مع العقود:

• تمثل عقد locker معين من مكتبة الأكواد الرسمية، أو تم نشره بواسطة المستخدم. في هذه الحالة، يمكننا اعتبار التفاعل كونه يتم عبر جهاز التوجيه.

• يتم دمج عقد locker معين مع Hook في نفس العقد، أو يتم التحكم فيه بواسطة كيان طرف ثالث. في هذه الحالة، يمكننا اعتبار التفاعل يتم من خلال Hook. في هذه الحالة، يلعب Hook دور عقد locker ويتولى أيضًا معالجة الاستدعاء.

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

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

قبل مناقشة القضايا الأمنية ذات الصلة، نحتاج إلى تحديد نموذج التهديد. نحن نعتبر بشكل رئيسي الحالتين التاليتين:

• نموذج التهديد I: الـ Hook نفسه خيّر، لكنه يحتوي على ثغرات.

• نموذج التهديد II: هوك في حد ذاته ضار.

في الجزء التالي، سنناقش القضايا الأمنية المحتملة بناءً على هذين النموذجين للتهديد.

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

نموذج التهديد I يركز على الثغرات المتعلقة بالـ Hook نفسه. يفترض هذا النموذج أن المطور و Hook الخاص به ليس لهما نية خبيثة. ومع ذلك، يمكن أن تظهر الثغرات المعروفة الموجودة في العقود الذكية أيضًا في Hook. على سبيل المثال، إذا تم تنفيذ Hook كعقد قابل للتحديث، فقد يواجه مشكلات ذات صلة مثل ثغرات UUPSUpgradeable من OpenZeppelin.

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

بالتحديد، سنركز على نوعين من Hook:

• النوع الأول من hook، لحفظ أموال المستخدمين. في هذه الحالة، قد يهاجم المهاجم هذا hook لنقل الأموال، مما يتسبب في خسارة الأصول.

• النوع الثاني من hook، يخزن بيانات الحالة الحرجة التي تعتمد عليها المستخدمون أو بروتوكولات أخرى. في هذه الحالة، قد يحاول المهاجم تغيير الحالة الحرجة. عندما يستخدم مستخدمون أو بروتوكولات أخرى حالة خاطئة، قد يؤدي ذلك إلى مخاطر محتملة.

يرجى ملاحظة أن الخطافات التي تقع خارج هذين النطاقين ليست ضمن نطاق مناقشتنا.

بشكل عام، وجدنا 22 مشروعًا ذا صلة (باستثناء المشاريع غير المتعلقة بـ Uniswap v4). من بين هذه المشاريع، نعتقد أن هناك 8 مشاريع (36%) بها ثغرات. من بين هذه المشاريع الثمانية التي تحتوي على ثغرات، يوجد 6 مشاريع بها مشاكل في التحكم بالوصول، ومشروعان عرضة لاستدعاءات خارجية غير موثوقة.

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

في هذا الجزء من المناقشة، نركز بشكل أساسي على المشكلات التي قد تسببها دوال الاستدعاء في v4، بما في ذلك 8 استدعاءات hook واستدعاء lock. بالطبع، هناك حالات أخرى تحتاج إلى التحقق، ولكن هذه الحالات تختلف حسب التصميم، وهي خارج نطاق مناقشتنا في الوقت الحالي.

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

لذلك، بالنسبة لـ hook، من الضروري إنشاء آلية قوية للتحكم في الوصول، خاصةً لأنها يمكن أن تُستدعى من قبل أطراف أخرى بخلاف المسبح نفسه. من خلال إدارة أذونات الوصول بشكل صارم، يمكن لبرك السيولة تقليل مخاطر التفاعل غير المصرح به أو التفاعل الضار بشكل كبير.

2.1.2 مشكلة التحقق من المدخلات

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

ومع ذلك، لا يزال هناك سيناريو محتمل للهجوم، وهو استدعاءات خارجية غير موثوقة بسبب عدم التحقق الصحيح من المدخلات في بعض تنفيذات Hook المعرضة للهجمات:

• أولاً، لم يتحقق الـ hook من حوض الأموال الذي ينوي المستخدم التفاعل معه. قد يكون هذا حوض أموال ضار يحتوي على رموز مزيفة وينفذ منطقًا ضارًا.

• ثانياً، بعض دوال hook الأساسية تسمح باستدعاءات خارجية عشوائية.

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

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

2.1.3 تدابير الحماية ضد نموذج التهديد I

لتجنب مثل هذه المشكلات الأمنية المتعلقة بالـ hook، من الضروري التحقق من التفاعلات من خلال تنفيذ التحكم الضروري في الوصول إلى الوظائف الخارجية/العامة الحساسة والتحقق من مدخلات المعلمات. بالإضافة إلى ذلك، قد يساعد حماية إعادة الدخول في ضمان عدم تنفيذ الـ hook بشكل متكرر في تدفق المنطق القياسي. من خلال تنفيذ تدابير الحماية الأمنية المناسبة، يمكن لصندوق الأموال تقليل المخاطر المرتبطة بمثل هذه التهديدات.

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

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

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

نظرًا لأن طريقة الوصول إلى hook تحدد الأذونات التي قد تُمنح لـ hook، نقوم بتصنيف hook إلى فئتين:

• نموذج الاستضافة Hook: hook ليست نقطة دخول. يجب على المستخدمين التفاعل مع hook من خلال جهاز التوجيه (الذي قد توفره Uniswap).

• نوع مستقل من الخطاف: الخطاف هو نقطة الدخول، يسمح للمستخدمين بالتفاعل مباشرة معها.

2.2.1 نوع الاحتفاظ Hook

في هذه الحالة، يتم نقل أو تفويض أصول المستخدم المشفرة (بما في ذلك الرموز الأصلية والرموز الأخرى) إلى router. نظرًا لأن PoolManager قام بإجراء فحص للرصيد، فمن الصعب على hook الخبيث سرقة هذه الأصول مباشرة. ومع ذلك، لا يزال هناك سطح هجوم محتمل. على سبيل المثال، قد يتمكن المهاجمون من التلاعب بآلية إدارة الرسوم في الإصدار v4 من خلال hook.

2.2.2 نوع مستقل من Hook

عندما يتم استخدام Hook كنقطة دخول، تصبح الحالة أكثر تعقيدًا. في هذه الحالة، نظرًا لأن المستخدم يمكنه التفاعل مباشرة مع hook، فإن hook يحصل على مزيد من القوة. من الناحية النظرية، يمكن لـ hook تنفيذ أي إجراء مرغوب فيه من خلال هذا التفاعل.

في الإصدار v4، يعد التحقق من منطق الشفرة أمرًا بالغ الأهمية. تتمثل المشكلة الرئيسية في ما إذا كان من الممكن التلاعب بمنطق الشفرة. إذا كان الـ hook قابلًا للتحديث، فهذا يعني أن الـ hook الذي يبدو آمنًا قد يصبح خبيثًا بعد التحديث، مما يشكل خطرًا كبيرًا. تشمل هذه المخاطر:

• وكيل قابل للتطوير (يمكن أن يتعرض لهجوم مباشر)؛

• تحتوي على منطق تدميري ذاتي. قد تتعرض للهجوم في حالة الاستدعاء المشترك لـ selfdestruct و create2.

2.2.3 تدابير الوقاية ضد نموذج التهديد II

النقطة الأهم هي تقييم ما إذا كانت الـ hook خبيثة. وبشكل أكثر تحديدًا، بالنسبة لـ hook المدارة، يجب أن نركز على سلوك إدارة الرسوم؛ أما بالنسبة لـ hook المستقلة، فإن النقطة الرئيسية هي ما إذا كانت قابلة للتحديث.

الاستنتاج

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

في المقالات القادمة، سنقوم بدراسة كل نموذج تهديد تحت