Hooks: أدوات قوية لتوسيع وظائف التطبيقات

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

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

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

! من بروتوكول Uniswap V4 إلى بروتوكول Artela الأصلي ، الرحلة المتقدمة لثورة DeFi Hooks

Uniswap V4: ثورة الخطافات

في يونيو 2023، أصدرت Uniswap مسودة ورقة بيضاء للإصدار V4، وأبرز ميزة فيها هي إدخال آلية Hooks.

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

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

تدعم Uniswap V4 حاليًا أربع مجموعات من استدعاءات Hook، تحتوي كل مجموعة على زوج من دوال الاستدعاء:

1. beforeInitialize/afterInitialize: تستخدم لتهيئة بركة السيولة
2. beforeModifyPosition/afterModifyPosition: تستخدم لإضافة أو تقليل أو إزالة السيولة
3. beforeSwap/afterSwap: تُستخدم لتبادل الرموز
4. beforeDonate/afterDonate: تستخدم لوظيفة التبرع (وظيفة جديدة في Uniswap V4، تقدم مكافآت لمقدمي السيولة الموجودين ضمن نطاق التداول)

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

من خلال Hooks، يربط Uniswap V4 السيولة بشكل وثيق مع تطوير DApp، مما يعزز من وظائف DApp ويقوي من تأثير الشبكة لـ Uniswap، مما يجعله البنية التحتية الأساسية لنظام DeFi البيئي.

تحديات الأمان في Uniswap V4 Hooks

قامت إحدى فرق الأمان بتحليل عميق للمخاطر الأمنية المحتملة لآلية Hooks في Uniswap V4. بالإضافة إلى مخاطر العقود الخبيثة الخاصة بـ Hook، قد تحتوي العقود الجيدة أيضًا على ثغرات. أظهرت التحليلات أن أكثر من 30% من المشاريع تعاني من مخاطر أمنية. تنبع هذه الثغرات بشكل رئيسي من التفاعلات المعقدة بين Hook و PoolManager وأطراف خارجية ثالثة، ويمكن تقسيمها إلى فئتين رئيسيتين:

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

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

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

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

بروتوكول أصلي لمنصة بلوكتشين معينة: دعم البرمجة باستخدام Hook على مستوى البروتوكول

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

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

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

1. تهيئة الكتلة
2. التحقق من المعاملات
3. قبل التنفيذ
4. بعد التنفيذ
5. تأكيد نهائي للكتلة

حاليًا، فإن هذا التوسع الأصلي يدعم فقط TypeScript، حيث يتم تجميع كوده إلى WebAssembly (WASM) بايت كود ويتم نشره على الشبكة. بعد الانتهاء من النشر، يمكن لمالك العقد الذكي ربط العقد بالتوسع الأصلي. يشير مالك العقد الذكي إلى الحساب الذي يمكنه التحقق من خلال isOwner(address) returns (bool).

تتمتع الامتدادات الأصلية للمنصة بتنفيذ على مستوى البروتوكول كـ Hooks، ولها مزايا ملحوظة مقارنة بـ Uniswap V4 Hooks:

أولاً، تستخدم الامتدادات الأصلية WASM لتنفيذ شفراتها، وكفاءة التنفيذ أعلى بعدة مرات من EVM.

ثانياً، يمكن للتوسعات الأصلية توصيل دورة حياة المعاملة بأكملها، وليس فقط منطق DeFi الأساسي، مما يسمح ببناء تطبيقات لامركزية أكثر ثراءً بالميزات.

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

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

! من Uniswap V4 إلى بروتوكول Artela الأصلي ، الرحلة المتقدمة لثورة DeFi Hooks

ملخص

بوصفها جهة مشاركة وقائدة هامة في مجال التمويل اللامركزي، لعبت Uniswap دورًا رئيسيًا في دفع تقدم الصناعة وتحسين الوظائف. من المؤكد أن Hooks المقدمة في Uniswap V4 ستوجه اتجاه تطوير بورصات التداول اللامركزية، لتصبح نموذجًا يحتذي به المتنافسون.

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

تمت مراعاة آلية التوسع الأصلية التي تعمل بشكل مستقل ضمن WASM منذ بداية تصميم بروتوكول شبكة blockchain Layer 1 المتوافقة مع EVM عالية الأداء. يوفر ذلك دعمًا أصليًا لبرمجة Hooks، مما يزيد بشكل كبير من الأمان. هذه توفر حلًا متقدمًا للبروتوكولات المالية اللامركزية التي تعتبر الأمان بمثابة شريان الحياة.

! رحلة متقدمة من Uniswap V4 إلى بروتوكول Artela الأصلي ، ثورة خطافات DeFi