الدروس المستفادة من كود Uniswap وتقنيات تطوير العقود التي تعلمتها، أكثر إثارة من الكتب التعليمية

مؤخرًا، أثناء إعداد دروس تطوير بورصات لامركزية، قمت بدراسة عميقة لطريقة تنفيذ Uniswap V3، واكتشفت أن بعض الطرق في البرمجة فعلاً عبقرية. سابقًا، كتبت عقود NFT بسيطة فقط، وهذه المرة كانت أول مرة أدرس بجدية كود عقود DeFi، ووجدت العديد من الأمور التي أود مشاركتها مع من يرغب في تعلم Uniswap.

أولاً، أود أن أذكر مفاجأتي الأكبر — هل يمكن التنبؤ بعنوان العقد مسبقًا؟

عادةً، العناوين التي تحصل عليها عند نشر عقد تكون عشوائية، لكن Uniswap استخدم طريقة ذكية. عبر إضافة معلمة الملح (salt) عند إنشاء العقد، واستخدام رمز CREATE2، يمكن جعل العنوان الناتج قابلًا للتوقع. الطريقة المحددة هي: «pool = address(new UniswapV3Pool{salt: keccak256(abi.encode(token0, token1, fee))}());» هذا هو الكود. الميزة هنا أن معرفة زوج التداول والرسوم فقط تتيح لك حساب عنوان العقد الخاص بالمجمع، دون الحاجة لنشره فعليًا أولًا. هذا مفيد جدًا للتحقق من صلاحية المعاملات أو تحديد المجمع بسرعة.

تصميم وظيفة الاسترجاع (callback) أيضًا عبقري جدًا.

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

طريقة التقدير المسبق للصفقة أيضًا ذكية — باستخدام الاستثناءات لنقل المعلومات.

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

حلول مشكلة الدقة (الضبط) تستحق الدراسة.

عند حساب تبادل الرموز، إذا قمت بقسمة مباشرة، ستفقد الدقة. طريقة Uniswap هي أن ترفع القيمة 96 بت (أي تضرب في 2^96)، ثم تقوم بالقسمة، وأثناء الحساب تُقَصّ 2^96. هكذا، ضمن نطاق uint256، تضمن الدقة وتمنع الانفجار العددي. المتغيرات مثل sqrtRatioAX96 و sqrtRatioBX96 تعتمد على هذا المفهوم، على الرغم من أن الكود يبدو معقدًا، إلا أن المنطق واضح.

طريقة حساب أرباح الرسوم أيضًا ذكية جدًا.

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

أيضًا، من المهم أن نعرف أن بعض المعلومات لا تحتاج أن تكون على السلسلة (على البلوكشين).

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

وأخيرًا، تنظيم الكود.

مشاريع معقدة عادةً تُقسم العقود إلى أجزاء متعددة للصيانة، وUniswap ورث الكثير من ذلك. كما أنه من الحكمة استخدام العقود القياسية الموجودة، مثل استخدام OpenZeppelin's ERC721 لإدارة المراكز، مما يسرع التطوير ويضمن جودة الكود.

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