صدق أو لا تصدق، سيقابل Uniswap v4 الجميع قريبًا!

هذه المرة ، وضع فريق Uniswap أهدافا وخططا طموحة لتقديم العديد من الميزات الجديدة ، بما في ذلك عدد غير محدود من مجمعات السيولة والرسوم الديناميكية لكل زوج تداول ، وتصميم فردي ، ومحاسبة فلاش ، و Hook ، ودعم معيار الرمز المميز ERC1155. باستخدام التخزين العابر الذي قدمه EIP-1153 ، من المتوقع إصدار Uniswap v4 بعد ترقية Ethereum Cancun. من بين العديد من الابتكارات ، اكتسبت آلية Hook اهتماما واسعا بسبب إمكاناتها القوية. تسمح آلية الخطاف بتنفيذ كود محدد في نقاط محددة في دورة حياة مجمع السيولة ، مما يعزز بشكل كبير قابلية التوسع والمرونة في المجمعات. ومع ذلك ، يمكن أن تكون آلية الخطاف أيضا سيفا ذا حدين. في حين أنه قوي ومرن ، فإن استخدام Hook بأمان يمثل أيضا تحديا كبيرا. تعقيد هوك يجلب حتما ناقلات هجوم محتملة جديدة. لذلك ، نأمل في كتابة سلسلة من المقالات لتقديم القضايا الأمنية والمخاطر المحتملة المتعلقة بآلية هوك بشكل منهجي ، من أجل تعزيز التنمية الأمنية للمجتمع. نعتقد أن هذه الأفكار ستساعد في بناء خطافات Uniswap v4 آمنة. كمقالة افتتاحية لهذه السلسلة ، تقدم هذه المقالة المفاهيم المتعلقة بآلية Hook في Uniswap v4 وتحدد المخاطر الأمنية المرتبطة بآلية Hook.

- 1 - آلية Uniswap V4

قبل الانغماس في العمق، نحتاج إلى فهم أساسي للآليات الكامنة وراء Uniswap v4. وفقًا للإعلان الرسمي [1] والورقة البيضاء [2]، الخطافات، الهندسة المعمارية الفردية، والمحاسبة الفورية هي ثلاث ميزات مهمة تمكّن تجمعات السيولة المخصصة وتوجيه فعال عبر تجمعات متعددة.

1.1 هوك

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

• beforeInitialize/afterInitialize
• beforeModifyPosition/afterModifyPosition
• قبل الاستبدال/بعد الاستبدال
• beforeDonate/afterDonate

أدناه تدفق تبديل الخطاف المقدم في الورقة البيضاء [2].

الشكل 1: تدفق خطاف الإبدال

قدم فريق Uniswap المنهجية مع بعض الأمثلة (على سبيل المثال، TWAMM Hook [3])، ولقد قام المشاركون في المجتمع أيضًا بتقديم مساهمات. الوثائق الرسمية [4] تشير أيضًا إلى مستودع Awesome Uniswap v4 Hooks [5]، الذي يجمع المزيد من أمثلة الـ Hook.

1.2 وحيد، محاسبة فلاش، وآلية القفل

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

👇🏻 يعمل آلية القفل على النحو التالي: 1. يُطلب قفل عقد الخزانة من PoolManager. 2. يُضيف PoolManager عنوان عقد الخزانة إلى طابور البيانات المؤقتة ويُدعو لاستدعاء قفله. 3. يُنفذ عقد الخزانة منطقه في استدعاء الاستجابة. قد تؤدي التفاعلات مع الخزانة خلال التنفيذ إلى زيادات في العملة غير الصفرية. ومع ذلك، بحلول نهاية التنفيذ، يجب أن تكون جميع الزيادات صافية على الصفر. بالإضافة إلى ذلك، إذا كان طابور بيانات القفل غير فارغ، يمكن لعقد الخزانة الأخير فقط تنفيذ العمليات. 4. يُتحقق PoolManager من حالة طابور بيانات القفل وزيادات العملة. بعد التحقق، يقوم PoolManager بإزالة عقد الخزانة.

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

👇🏻 هناك سيناريوهات تفاعل العقد الرئيسية:

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

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

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

• نموذج التهديد I: الخطاف نفسه هو غير ضار ولكنه يحتوي على ثغرات.
• نموذج التهديد II: الخطاف نفسه خبيث.

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

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

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

👇🏻 تحديدًا، سنركز على النوعين التاليين من الخطافات:

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

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

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

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

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

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

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

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

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

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

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

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

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

• Managed Hooks: الخطاف ليس نقطة دخول. يجب على المستخدمين تفاعل مع الخطاف عبر جهاز التوجيه (المقدم ربما من قبل Uniswap).
• الخطاف المستقل: الخطاف هو نقطة الدخول، مما يسمح للمستخدمين بالتفاعل معه مباشرة.

الشكل 2: مثال على خطاف خبيث

2.2.1 الخطافات المُدارة

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

2.2.2 خطافات مستقلة

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

• الوكلاء القابلة للترقية (التي يمكن مهاجمتها مباشرة)
• المنطق مع التدمير الذاتي. قد يتعرض للهجوم بالتزامن مع استدعاء selfdestruct و create2.

2.2.3 إجراءات الصد النشطة لنموذج التهديد الثاني

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

- 3 - الاستنتاج

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

المراجع

[1] رؤيتنا ليونيسواب V4
https://blog.uniswap.org/uniswap-v4

[2] مسودة كتاب أبيض Uniswap v4
https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

[3] هوك TWAMM Uniswap v4
https://blog.uniswap.org/v4-twamm-hook

[4] أمثلة الخطاف
https://docs.uniswapfoundation.org/hooks/hook-examples

[5] خطافات رائعة Uniswap v4
https://github.com/fewwwww/awesome-uniswap-hooks

[6] ترقية عرضية للضعف بعد الوفاة
https://forum.openzeppelin.com/t/uupsupgradeable-vulnerability-post-mortem/15680

حول كتلة الأمان كتلة هي شركة رائدة عالميًا في مجال أمان سلسلة الكتل تأسست في عام 2021 من قبل خبراء مشهورين في صناعة الأمان. تكرس الشركة جهودها لتعزيز الأمان والقابلية للإستخدام لعالم Web3 لتعزيز اعتماد Web3 على نطاق واسع. من أجل تحقيق ذلك، تقدم كتلة خدمات تدقيق أمان العقود الذكية وسلسلة EVM، نظام تطوير، اختبار، واعتراض القراصنة يسمى Phalcon لأصحاب المشاريع، منصة تتبع الصندوق والتحقيق تسمى MetaSleuth، بالإضافة إلى مكونات إضافية لبناء web3 تسمى MetaDock. حاليًا، خدمت الشركة أكثر من 300 عميل، بما في ذلك مشاريع معروفة مثل MetaMask، Compound، Uniswap Foundation، Forta، PancakeSwap، وقد حصلت على جولتي تمويل تبلغ أكثر من عشرات الملايين من الدولارات من مؤسسات استثمارية مثل Oasis Capital، IDG Capital، و Distributed Capital. الصفحة الرئيسية:www.blocksec.com

تويتر：https://twitter.com/كتلةSecTeam

Phalcon: https://phalcon.xyz/

ميتاسلوث: https://metasleuth.io/

ميتادوك: https://blocksec.com/metadock

إخلاء المسؤولية:

1. تم نقل هذه المقالة من [ كتلةSec]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [كتلةSec]. إذا كانت هناك اعتراضات على هذا النشر، يرجى التواصل معبوابة تعلمالفريق، وسيتولون على التعامل معها بسرعة.
2. إخلاء المسؤولية عن المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك التي تنتمي إلى المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر غير ذلك، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.