نصائح صغيرة لتطوير العقود: الدروس المستفادة من كود Uniswap

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

عنوان العقد القابل للتنبؤ

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

أنشأت Uniswap العقود باستخدام طريقة CREATE2 ، مضيفةً معلمة salt. وبالتالي ، فإن عنوان العقد الذي تم إنشاؤه يمكن التنبؤ به ، ويتبع منطق "عنوان جديد = hash('0xFF', عنوان المنشئ, salt, initcode)".

استخدام دوال الاسترجاع بذكاء

في Solidity، يمكن للعقود استدعاء بعضها البعض. في بعض الأحيان، يقوم عقد A باستدعاء طرق عقد B، ثم يقوم B باستدعاء طرق A، وهذا مفيد في بعض السيناريوهات.

على سبيل المثال، في عملية تداول Uniswap، عند استدعاء طريقة swap لعقد UniswapV3Pool، ستقوم باستدعاء swapCallback، مع تمرير الكمية الفعلية المطلوبة من الرموز. يجب على المتصل أن يقوم بإدخال الرموز المطلوبة في الاستدعاء، مما يضمن سلامة وأمان منطق التداول بأكمله.

استخدام الاستثناءات لنقل المعلومات ، وتنفيذ تقدير المعاملات باستخدام try catch

في عقد Quoter الخاص بـ Uniswap، يتم استخدام try catch لتغليف تنفيذ طريقة swap في UniswapV3Pool. وذلك لمحاكاة تقدير الصفقة المطلوبة للرمز، ولكن أثناء التقدير لن يتم تبادل الرموز فعليًا، لذا سيظهر خطأ.

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

مشكلة دقة معالجة الأعداد الكبيرة

يتضمن كود Uniswap الكثير من الحسابات، مثل حساب عدد الرموز المميزة التي يتم تبادلها بناءً على السعر الحالي والسيولة. لتجنب فقدان الدقة في عمليات القسمة، غالبًا ما تستخدم عملية "<< FixedPoint96.RESOLUTION"، والتي تعادل الضرب في 2^96.

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

حساب الأرباح بطريقة المشاركة

تحتاج Uniswap إلى تسجيل عائدات رسوم مقدمي السيولة (LP). لتجنب تسجيل الرسوم لكل LP في كل صفقة (مما يتطلب الكثير من الغاز)، اعتمدت Uniswap طريقة ذكية.

في بنية Position تم تعريف feeGrowthInside0LastX128 و feeGrowthInside1LastX128، لتسجيل رسوم المعاملات المستحقة لكل وحدة من السيولة عند آخر سحب للرسوم من كل مركز. وبالتالي، يكفي تسجيل إجمالي الرسوم وحصة كل وحدة من السيولة، وعند سحب LP، يتم حساب الرسوم القابلة للسحب بناءً على السيولة المحتفظ بها.

التوازن في الحصول على المعلومات على السلسلة وخارج السلسلة

تخزين البيانات على السلسلة مكلف نسبيًا، وليست كل المعلومات بحاجة إلى أن تكون على السلسلة أو يتم الحصول عليها من السلسلة. على سبيل المثال، العديد من الواجهات التي تستدعيها واجهة Uniswap الأمامية هي واجهات ويب تقليدية.

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

توفر بعض مزودي خدمة RPC في البلوكشين واجهات متقدمة للحصول على البيانات بشكل أسرع وأرخص. عادةً ما تعمل هذه الواجهات على تحسين الأداء والكفاءة من خلال التخزين المؤقت.

تقسيم العقود واستخدام العقود القياسية

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

على سبيل المثال، فإن عقد NonfungiblePositionManager الخاص بـ Uniswap يرث من عدة عقود. حيث يستخدم عقد ERC721Permit مباشرة عقد ERC721 القياسي من OpenZeppelin، مما يسهل إدارة المراكز بطريقة NFT، ويزيد من كفاءة التطوير.

الخاتمة

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