آلية Hook في Uniswap v4: الإمكانات والمخاطر تتعايش
ستطلق Uniswap v4 قريبًا، حيث تتضمن هذه التحديثات العديد من الميزات الجديدة، بما في ذلك دعم عدد غير محدود من أحواض السيولة لكل زوج تداول و رسوم ديناميكية، تصميم أحادي، محاسبة فورية، آلية Hook، ودعم معيار ERC1155 للرموز. من بين هذه الميزات، أثارت آلية Hook اهتمامًا واسعًا بسبب إمكانياتها القوية.
تسمح آلية Hook بتنفيذ الشيفرة المخصصة في نقاط محددة خلال دورة حياة تجمع السيولة، مما يعزز بشكل كبير قابلية التوسع والمرونة للتجمع. ومع ذلك، يمكن أن تكون آلية Hook سلاحًا ذا حدين. على الرغم من أنها قوية ومرنة، إلا أن الاستخدام الآمن لـ Hook يمثل تحديًا كبيرًا. لا مفر من أن تعقيد Hook يجلب معه نقاط هجوم محتملة جديدة.
ستتناول هذه المقالة المفاهيم ذات الصلة بآلية Hook في Uniswap v4، وتقدم نظرة عامة على المخاطر الأمنية الموجودة.
الآلية الأساسية لـ Uniswap v4
قبل الخوض في تفاصيل أعمق، نحتاج إلى فهم أساسي لآلية Uniswap v4. وفقًا للإعلانات الرسمية والورقة البيضاء، فإن Hook، والهندسة المعمارية الأحادية، والمحاسبة الفورية هي ثلاث ميزات مهمة لتحقيق برك السيولة المخصصة والتوجيه الفعال عبر عدة برك.
آلية Hook
تشير Hook إلى العقود التي تعمل في مراحل مختلفة من دورة حياة تجمع السيولة، وتهدف إلى تمكين أي شخص من اتخاذ قرارات متوازنة. من خلال هذه الطريقة، يمكن تحقيق دعم أصلي للرسوم الديناميكية، وإضافة أوامر سعرية على السلسلة، أو من خلال صانع سوق متوسط مرجح زمنياً (TWAMM) لتوزيع الطلبات الكبيرة.
يوجد حاليًا ثمانية استدعاءات من نوع Hook، مقسمة إلى أربع مجموعات ( كل مجموعة تحتوي على زوج من الاستدعاءات ):
قبل التهيئة/بعد التهيئة
قبل تعديل الموضع/بعد تعديل الموضع
قبل التبادل/بعد التبادل
قبل التبرع/بعد التبرع
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
نمط وحيد، محاسبة سريعة وآلية القفل
تهدف بنية النموذج الأحادي والمحاسبة الفورية إلى تحسين الأداء من خلال خفض التكاليف وضمان الكفاءة. إنها تقدم عقدًا جديدًا أحاديًا، حيث يتم الاحتفاظ بجميع برك السيولة في نفس العقد الذكي. يعتمد هذا التصميم الأحادي على PoolManager لتخزين وإدارة حالة جميع البرك.
أدخل إصدار v4 آلية المحاسبة السريعة وآلية القفل. طريقة عمل آلية القفل هي كما يلي:
يطلب عقد locker قفل على PoolManager.
يقوم PoolManager بإضافة عنوان عقد locker إلى قائمة lockData، ويستدعي رد الاتصال lockAcquired الخاص به.
يتم تنفيذ منطق عقد locker في الاستدعاء. قد يؤدي التفاعل مع المسبح أثناء عملية التنفيذ إلى زيادة غير صفرية في العملات، ولكن عند الانتهاء من التنفيذ، يجب تسوية جميع الزيادات إلى الصفر.
يقوم PoolManager بفحص حالة صف lockData وزيادة العملة. بعد التحقق، يتم حذف عقدة الـ locker.
بشكل عام، تمنع آلية القفل الوصول المتزامن وتضمن تسوية جميع المعاملات. تعني هذه الطريقة أن التعديلات التشغيلية تتعلق بالرصيد الصافي الداخلي، بدلاً من تنفيذ التحويل الفوري. سيتم تسجيل أي تعديلات في الرصيد الداخلي للمسبح، بينما يتم تنفيذ التحويل الفعلي عند انتهاء العملية.
نظرًا لوجود آلية القفل، لا يمكن لجميع الحسابات الخارجية (EOA) التفاعل مباشرة مع PoolManager. يجب أن تتم أي تفاعلات من خلال العقد. هناك نوعان رئيسيان من سيناريوهات التفاعل مع العقد:
عقد locker يأتي من مكتبة الشيفرة الرسمية أو يتم نشره بواسطة المستخدم. يمكن اعتبار هذه الحالة تفاعل من خلال جهاز التوجيه.
تم دمج عقد locker و Hook في نفس العقد، أو يتم التحكم بهما من قبل كيان طرف ثالث. يمكن اعتبار هذه الحالة تفاعلًا من خلال Hook.
نموذج التهديد
قبل مناقشة القضايا الأمنية ذات الصلة، نحتاج إلى تحديد نموذج التهديد. يتم النظر في حالتين رئيسيتين:
نموذج التهديد I: هوك نفسه خبيث ولكن هناك ثغرات.
نموذج التهديد II: هوك نفسه خبيث.
مشاكل الأمان في نموذج التهديد I
تتناول نموذج التهديد I الثغرات المرتبطة بـ Hook نفسه. يفترض هذا النموذج أن المطورين و Hook الخاص بهم ليسوا ضارين. ومع ذلك، قد تظهر الثغرات المعروفة الموجودة في العقود الذكية أيضًا في Hook.
نحن نختار التركيز على الثغرات المحتملة الفريدة من نوعها في الإصدار v4، مع التركيز بشكل أساسي على نوعي Hook التاليين:
هوك لحفظ أموال المستخدمين. قد يهاجم المهاجمون هذا الهوك لنقل الأموال، مما يتسبب في خسارة الأصول.
هوك لتخزين بيانات الحالة الأساسية التي يعتمد عليها المستخدمون أو بروتوكولات أخرى. قد يحاول المهاجمون تغيير الحالة الأساسية، مما قد يؤدي إلى مخاطر محتملة عندما يستخدم مستخدمون آخرون أو بروتوكولات حالة خاطئة.
بعد الدراسة، اكتشفنا عدة ثغرات خطيرة، تنبع أساساً من التفاعلات بين Hook و PoolManager والأطراف الخارجية، ويمكن تقسيمها إلى فئتين: مشاكل في التحكم بالوصول ومشاكل في التحقق من المدخلات.
مسائل التحكم في الوصول
قد تسبب دوال الاستدعاء في v4 مشكلات، بما في ذلك 8 دوال استدعاء Hook واستدعاء lock. يجب أن يتم استدعاء هذه الدوال فقط من قبل PoolManager، ولا يمكن استدعاؤها من قبل عناوين أخرى. بالنسبة لـ Hook، من الضروري إنشاء آلية تحكم وصول قوية، خاصةً لأنها يمكن أن تُستدعى من قبل أطراف أخرى بخلاف المجموعة نفسها.
مشكلة تحقق الإدخال
على الرغم من وجود آلية القفل، لا يزال هناك سيناريو هجوم محتمل، وهو استدعاء خارجي غير موثوق به نتيجة للتحقق غير الصحيح من المدخلات في بعض تنفيذات Hook القابلة للاختراق:
لم تتحقق Hook من تجمع الأموال الذي ينوي المستخدم التفاعل معه. قد يكون هذا تجمعًا خبيثًا يحتوي على رموز مزيفة وينفذ منطقًا ضارًا.
بعض الدوال الرئيسية Hook تسمح بالاستدعاءات الخارجية العشوائية.
الاستدعاءات الخارجية غير الموثوقة خطيرة للغاية، وقد تؤدي إلى أنواع مختلفة من الهجمات، بما في ذلك هجمات إعادة الدخول.
تدابير الوقاية
لتجنب مثل هذه المشكلات الأمنية المتعلقة بـ Hook، من الضروري تنفيذ التحكم في الوصول اللازم بشكل مناسب على الوظائف الخارجية / العامة الحساسة والتحقق من معلمات الإدخال، وبالتالي التحقق من التفاعل. بالإضافة إلى ذلك، قد تساعد حماية إعادة الدخول في ضمان عدم تنفيذ Hook بشكل متكرر في تدفق المنطق القياسي.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
قضايا الأمان في نموذج التهديد II
في نموذج التهديد هذا، نفترض أن المطور وHook الخاص بهما ضارا. المفتاح هو ما إذا كان Hook المقدم قادرا على معالجة تحويلات المستخدم أو تفويض الأصول المشفرة.
وفقًا لطريقة الوصول إلى Hook، نقسم Hook إلى نوعين:
Hook المدارة: Hook ليست نقطة دخول. يجب على المستخدمين التفاعل مع Hook عبر الموجه.
النوع المستقل من Hook: Hook هو نقطة الدخول، يسمح للمستخدمين بالتفاعل مباشرة معها.
نوع الاستضافة Hook
تم تحويل أصول المستخدم المشفرة أو تفويضها إلى router. نظرًا لأن PoolManager قد نفذ فحص الرصيد، فإن من الصعب على Hook الخبيث سرقة هذه الأصول مباشرة. ومع ذلك، لا يزال هناك سطح هجوم محتمل، مثل آلية إدارة الرسوم في الإصدار v4 التي قد يتم التلاعب بها من قبل المهاجمين من خلال Hook.
هوك مستقل
عندما يتم استخدام Hook كنقطة دخول، تصبح الحالة أكثر تعقيدًا. حصل Hook على مزيد من القوة، نظريًا يمكنه تنفيذ أي عملية مرغوبة من خلال هذا التفاعل.
في إصدار v4، فإن التحقق من منطق الكود أمر بالغ الأهمية. تتمثل المشكلة الرئيسية في ما إذا كان يمكن التلاعب بمنطق الكود. إذا كان Hook قابلاً للتحديث، فهذا يعني أن Hook الذي يبدو آمناً قد يصبح خبيثاً بعد التحديث، مما يشكل خطراً كبيراً. تشمل هذه المخاطر:
يمكن مهاجمة الوكيل القابل للتطوير ( مباشرةً )
يحتوي على منطق التدمير الذاتي. قد يتعرض للهجوم في حالة استدعاء selfdestruct و create2 معًا.
تدابير الوقاية
النقطة الأساسية هي تقييم ما إذا كانت الـ Hook خبيثة. بشكل أكثر تحديداً، بالنسبة للـ Hook المدارة، يجب أن نركز على سلوك إدارة الرسوم؛ بينما بالنسبة للـ Hook المستقلة، فإن النقطة الرئيسية هي ما إذا كانت قابلة للتحديث.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp)
الخاتمة
تقدم هذه المقالة نظرة عامة موجزة عن الآليات الأساسية المتعلقة بمشكلات أمان Hook في Uniswap v4، وتقترح نموذجين للتهديدات والمخاطر الأمنية ذات الصلة. على الرغم من أن آلية Hook قوية، إلا أنها تجلب أيضًا تحديات أمنية جديدة. يحتاج المطورون والمستخدمون إلى أن يكونوا على دراية كاملة بهذه المخاطر المحتملة واتخاذ التدابير المناسبة لضمان أمان الأصول عند استخدام Uniswap v4.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
آلية Hook في Uniswap v4: تحديات الأمان وراء الوظائف القوية
آلية Hook في Uniswap v4: الإمكانات والمخاطر تتعايش
ستطلق Uniswap v4 قريبًا، حيث تتضمن هذه التحديثات العديد من الميزات الجديدة، بما في ذلك دعم عدد غير محدود من أحواض السيولة لكل زوج تداول و رسوم ديناميكية، تصميم أحادي، محاسبة فورية، آلية Hook، ودعم معيار ERC1155 للرموز. من بين هذه الميزات، أثارت آلية Hook اهتمامًا واسعًا بسبب إمكانياتها القوية.
تسمح آلية Hook بتنفيذ الشيفرة المخصصة في نقاط محددة خلال دورة حياة تجمع السيولة، مما يعزز بشكل كبير قابلية التوسع والمرونة للتجمع. ومع ذلك، يمكن أن تكون آلية Hook سلاحًا ذا حدين. على الرغم من أنها قوية ومرنة، إلا أن الاستخدام الآمن لـ Hook يمثل تحديًا كبيرًا. لا مفر من أن تعقيد Hook يجلب معه نقاط هجوم محتملة جديدة.
ستتناول هذه المقالة المفاهيم ذات الصلة بآلية Hook في Uniswap v4، وتقدم نظرة عامة على المخاطر الأمنية الموجودة.
الآلية الأساسية لـ Uniswap v4
قبل الخوض في تفاصيل أعمق، نحتاج إلى فهم أساسي لآلية Uniswap v4. وفقًا للإعلانات الرسمية والورقة البيضاء، فإن Hook، والهندسة المعمارية الأحادية، والمحاسبة الفورية هي ثلاث ميزات مهمة لتحقيق برك السيولة المخصصة والتوجيه الفعال عبر عدة برك.
آلية Hook
تشير Hook إلى العقود التي تعمل في مراحل مختلفة من دورة حياة تجمع السيولة، وتهدف إلى تمكين أي شخص من اتخاذ قرارات متوازنة. من خلال هذه الطريقة، يمكن تحقيق دعم أصلي للرسوم الديناميكية، وإضافة أوامر سعرية على السلسلة، أو من خلال صانع سوق متوسط مرجح زمنياً (TWAMM) لتوزيع الطلبات الكبيرة.
يوجد حاليًا ثمانية استدعاءات من نوع Hook، مقسمة إلى أربع مجموعات ( كل مجموعة تحتوي على زوج من الاستدعاءات ):
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-f652bf2a22ca7f28f19b4ce9880d0548.webp)
نمط وحيد، محاسبة سريعة وآلية القفل
تهدف بنية النموذج الأحادي والمحاسبة الفورية إلى تحسين الأداء من خلال خفض التكاليف وضمان الكفاءة. إنها تقدم عقدًا جديدًا أحاديًا، حيث يتم الاحتفاظ بجميع برك السيولة في نفس العقد الذكي. يعتمد هذا التصميم الأحادي على PoolManager لتخزين وإدارة حالة جميع البرك.
أدخل إصدار v4 آلية المحاسبة السريعة وآلية القفل. طريقة عمل آلية القفل هي كما يلي:
يطلب عقد locker قفل على PoolManager.
يقوم PoolManager بإضافة عنوان عقد locker إلى قائمة lockData، ويستدعي رد الاتصال lockAcquired الخاص به.
يتم تنفيذ منطق عقد locker في الاستدعاء. قد يؤدي التفاعل مع المسبح أثناء عملية التنفيذ إلى زيادة غير صفرية في العملات، ولكن عند الانتهاء من التنفيذ، يجب تسوية جميع الزيادات إلى الصفر.
يقوم PoolManager بفحص حالة صف lockData وزيادة العملة. بعد التحقق، يتم حذف عقدة الـ locker.
بشكل عام، تمنع آلية القفل الوصول المتزامن وتضمن تسوية جميع المعاملات. تعني هذه الطريقة أن التعديلات التشغيلية تتعلق بالرصيد الصافي الداخلي، بدلاً من تنفيذ التحويل الفوري. سيتم تسجيل أي تعديلات في الرصيد الداخلي للمسبح، بينما يتم تنفيذ التحويل الفعلي عند انتهاء العملية.
نظرًا لوجود آلية القفل، لا يمكن لجميع الحسابات الخارجية (EOA) التفاعل مباشرة مع PoolManager. يجب أن تتم أي تفاعلات من خلال العقد. هناك نوعان رئيسيان من سيناريوهات التفاعل مع العقد:
عقد locker يأتي من مكتبة الشيفرة الرسمية أو يتم نشره بواسطة المستخدم. يمكن اعتبار هذه الحالة تفاعل من خلال جهاز التوجيه.
تم دمج عقد locker و Hook في نفس العقد، أو يتم التحكم بهما من قبل كيان طرف ثالث. يمكن اعتبار هذه الحالة تفاعلًا من خلال Hook.
نموذج التهديد
قبل مناقشة القضايا الأمنية ذات الصلة، نحتاج إلى تحديد نموذج التهديد. يتم النظر في حالتين رئيسيتين:
مشاكل الأمان في نموذج التهديد I
تتناول نموذج التهديد I الثغرات المرتبطة بـ Hook نفسه. يفترض هذا النموذج أن المطورين و Hook الخاص بهم ليسوا ضارين. ومع ذلك، قد تظهر الثغرات المعروفة الموجودة في العقود الذكية أيضًا في Hook.
نحن نختار التركيز على الثغرات المحتملة الفريدة من نوعها في الإصدار v4، مع التركيز بشكل أساسي على نوعي Hook التاليين:
هوك لحفظ أموال المستخدمين. قد يهاجم المهاجمون هذا الهوك لنقل الأموال، مما يتسبب في خسارة الأصول.
هوك لتخزين بيانات الحالة الأساسية التي يعتمد عليها المستخدمون أو بروتوكولات أخرى. قد يحاول المهاجمون تغيير الحالة الأساسية، مما قد يؤدي إلى مخاطر محتملة عندما يستخدم مستخدمون آخرون أو بروتوكولات حالة خاطئة.
بعد الدراسة، اكتشفنا عدة ثغرات خطيرة، تنبع أساساً من التفاعلات بين Hook و PoolManager والأطراف الخارجية، ويمكن تقسيمها إلى فئتين: مشاكل في التحكم بالوصول ومشاكل في التحقق من المدخلات.
مسائل التحكم في الوصول
قد تسبب دوال الاستدعاء في v4 مشكلات، بما في ذلك 8 دوال استدعاء Hook واستدعاء lock. يجب أن يتم استدعاء هذه الدوال فقط من قبل PoolManager، ولا يمكن استدعاؤها من قبل عناوين أخرى. بالنسبة لـ Hook، من الضروري إنشاء آلية تحكم وصول قوية، خاصةً لأنها يمكن أن تُستدعى من قبل أطراف أخرى بخلاف المجموعة نفسها.
مشكلة تحقق الإدخال
على الرغم من وجود آلية القفل، لا يزال هناك سيناريو هجوم محتمل، وهو استدعاء خارجي غير موثوق به نتيجة للتحقق غير الصحيح من المدخلات في بعض تنفيذات Hook القابلة للاختراق:
لم تتحقق Hook من تجمع الأموال الذي ينوي المستخدم التفاعل معه. قد يكون هذا تجمعًا خبيثًا يحتوي على رموز مزيفة وينفذ منطقًا ضارًا.
بعض الدوال الرئيسية Hook تسمح بالاستدعاءات الخارجية العشوائية.
الاستدعاءات الخارجية غير الموثوقة خطيرة للغاية، وقد تؤدي إلى أنواع مختلفة من الهجمات، بما في ذلك هجمات إعادة الدخول.
تدابير الوقاية
لتجنب مثل هذه المشكلات الأمنية المتعلقة بـ Hook، من الضروري تنفيذ التحكم في الوصول اللازم بشكل مناسب على الوظائف الخارجية / العامة الحساسة والتحقق من معلمات الإدخال، وبالتالي التحقق من التفاعل. بالإضافة إلى ذلك، قد تساعد حماية إعادة الدخول في ضمان عدم تنفيذ Hook بشكل متكرر في تدفق المنطق القياسي.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-ba4bfa88e0ac0b6246e82ad879361ff3.webp)
قضايا الأمان في نموذج التهديد II
في نموذج التهديد هذا، نفترض أن المطور وHook الخاص بهما ضارا. المفتاح هو ما إذا كان Hook المقدم قادرا على معالجة تحويلات المستخدم أو تفويض الأصول المشفرة.
وفقًا لطريقة الوصول إلى Hook، نقسم Hook إلى نوعين:
Hook المدارة: Hook ليست نقطة دخول. يجب على المستخدمين التفاعل مع Hook عبر الموجه.
النوع المستقل من Hook: Hook هو نقطة الدخول، يسمح للمستخدمين بالتفاعل مباشرة معها.
نوع الاستضافة Hook
تم تحويل أصول المستخدم المشفرة أو تفويضها إلى router. نظرًا لأن PoolManager قد نفذ فحص الرصيد، فإن من الصعب على Hook الخبيث سرقة هذه الأصول مباشرة. ومع ذلك، لا يزال هناك سطح هجوم محتمل، مثل آلية إدارة الرسوم في الإصدار v4 التي قد يتم التلاعب بها من قبل المهاجمين من خلال Hook.
هوك مستقل
عندما يتم استخدام Hook كنقطة دخول، تصبح الحالة أكثر تعقيدًا. حصل Hook على مزيد من القوة، نظريًا يمكنه تنفيذ أي عملية مرغوبة من خلال هذا التفاعل.
في إصدار v4، فإن التحقق من منطق الكود أمر بالغ الأهمية. تتمثل المشكلة الرئيسية في ما إذا كان يمكن التلاعب بمنطق الكود. إذا كان Hook قابلاً للتحديث، فهذا يعني أن Hook الذي يبدو آمناً قد يصبح خبيثاً بعد التحديث، مما يشكل خطراً كبيراً. تشمل هذه المخاطر:
تدابير الوقاية
النقطة الأساسية هي تقييم ما إذا كانت الـ Hook خبيثة. بشكل أكثر تحديداً، بالنسبة للـ Hook المدارة، يجب أن نركز على سلوك إدارة الرسوم؛ بينما بالنسبة للـ Hook المستقلة، فإن النقطة الرئيسية هي ما إذا كانت قابلة للتحديث.
! [لماذا يعتبر Hook "سيف ذو حدين" ل Uniswap V4؟] ](https://img-cdn.gateio.im/webp-social/moments-97c1e5846e4f09953053f0fb97876f16.webp)
الخاتمة
تقدم هذه المقالة نظرة عامة موجزة عن الآليات الأساسية المتعلقة بمشكلات أمان Hook في Uniswap v4، وتقترح نموذجين للتهديدات والمخاطر الأمنية ذات الصلة. على الرغم من أن آلية Hook قوية، إلا أنها تجلب أيضًا تحديات أمنية جديدة. يحتاج المطورون والمستخدمون إلى أن يكونوا على دراية كاملة بهذه المخاطر المحتملة واتخاذ التدابير المناسبة لضمان أمان الأصول عند استخدام Uniswap v4.