ما يجب أن يعرفه مطورو Web3: الدروس القيمة المستفادة من عقد Uniswap
مؤخراً، أثناء كتابتي لدليل تطوير تبادل لامركزي، قمت بدراسة متعمقة لتنفيذ كود Uniswap V3، وجنيت فوائد كبيرة. كوني مبتدئاً في تطوير عقود DeFi، فإن هذه التقنيات كانت بلا شك بمثابة إلهام لي. أعتقد أن هذه الخبرات ستفيد أيضاً الأصدقاء الذين يرغبون في دخول عالم تطوير العقود الذكية.
حيل لتوقع عنوان العقد
عادةً ما يبدو العنوان الذي تم الحصول عليه بعد نشر العقد عشوائيًا ويصعب التنبؤ به. ولكن في Uniswap، يمكننا استنتاج عنوان العقد من خلال أزواج التداول والمعلومات ذات الصلة. وهذا مفيد جدًا في سيناريوهات مثل تحديد صلاحيات التداول أو الحصول على عنوان المسبح.
يستخدم Uniswap طريقة CREATE2 لإنشاء العقود، من خلال إضافة معلمة "salt" لجعل العنوان الناتج قابلاً للتنبؤ. منطق توليد العنوان المحدد هو: العنوان الجديد = hash("0xFF"، عنوان المنشئ، salt، initcode).
الاستخدام الذكي للدوال العكسية
في بعض السيناريوهات، فإن الاستدعاءات المتبادلة بين العقود تكون مفيدة جداً. على سبيل المثال، تستدعي طريقة A الطريقة B، وتقوم B بالاستدعاء مرة أخرى لـ A في الطريقة التي تم استدعاؤها.
في Uniswap، عند استدعاء طريقة swap لعقد UniswapV3Pool لإجراء صفقة، ستقوم باستدعاء swapCallback، مع تمرير الكمية الفعلية المطلوبة من الرموز المحسوبة. يتعين على الطرف المستدعي نقل الرموز المطلوبة إلى UniswapV3Pool في الاستدعاء الراجع. يضمن هذا التصميم أمان طريقة swap وسلامتها المنطقية، دون الحاجة إلى تسجيل متغيرات معقدة.
تمرير معلومات استثنائية، تنفيذ تقدير المعاملات باستخدام try-catch
في عقد Quoter الخاص بـ Uniswap، يتم استخدام try-catch لتغليف تنفيذ طريقة swap الخاصة بـ UniswapV3Pool. وذلك لمحاكاة swap لتقدير الرموز المطلوبة للتداول. نظرًا لأن التقدير لا يقوم فعليًا بتبادل الرموز، فإنه سيؤدي إلى حدوث خطأ. يقوم Uniswap بإلقاء خطأ خاص في دالة رد الاتصال للتداول، ثم يلتقط هذا الخطأ ويحلل منه المعلومات المطلوبة.
تبدو هذه الطريقة وكأنها حيلة، لكنها عملية للغاية. لا حاجة لتعديل طريقة swap خصيصًا لتقدير متطلبات التداول، حيث أن المنطق أكثر بساطة.
حل مشاكل الدقة في العمليات العددية الكبيرة
يتضمن كود Uniswap الكثير من المنطق الحسابي، مثل حساب كمية التوكنات المتبادلة بناءً على السعر الحالي والسيولة. لتجنب فقدان الدقة الناتج عن عمليات القسمة، يتم استخدام عملية "<< FixedPoint96.RESOLUTION" بشكل متكرر في عملية الحساب، أي التحويل لليسار بمقدار 96 بت، وهو ما يعادل الضرب في 2^96. في ظل عدم وجود تجاوز في المعاملات العادية، يتم عادةً استخدام uint256 لحساب (، وهذه الطريقة تضمن فعالية الدقة.
![سلسلة المبتدئين في Web3: نصائح صغيرة لتطوير العقود تعلمتها من كود Uniswap])https://img-cdn.gateio.im/webp-social/moments-b0c3d4eb7e8ca88cc4cfc9476a34437a.webp(
حساب الأرباح من آلية المشاركة
يحتاج Uniswap إلى تسجيل عائدات رسوم مقدمي السيولة LP). من الواضح أنه لا يمكن تسجيل الرسوم لكل LP بشكل منفصل في كل عملية تداول، لأن ذلك سيستهلك كمية كبيرة من غاز.
حل Uniswap هو تعريف feeGrowthInside0LastX128 و feeGrowthInside1LastX128 في هيكل Position، لتسجيل رسوم العمولة المستحقة لكل وحدة من السيولة عند سحب الرسوم في المرة الأخيرة لكل مركز.
تتطلب هذه الطريقة فقط تسجيل إجمالي الرسوم وتوزيع الرسوم على كل وحدة من السيولة. عند سحب LP، يمكن حساب الرسوم القابلة للسحب بناءً على السيولة المحتفظ بها. هذا مشابه لكيفية حساب حامل الأسهم للأرباح القابلة للسحب الحالية بناءً على تاريخ أرباح السهم الواحد للشركة والأرباح في آخر سحب.
التوازن في الحصول على المعلومات على السلسلة
تخزين البيانات على السلسلة مكلف نسبيًا، وليس كل المعلومات بحاجة إلى أن تكون على السلسلة أو الحصول عليها من السلسلة. على سبيل المثال، العديد من واجهات الـ API التي يستدعيها موقع Uniswap الأمامي هي واجهات تقليدية من Web2.
يمكن تخزين قائمة أحواض التداول ومعلومات أحواض التداول في قاعدة بيانات عادية، وقد يحتاج البعض إلى المزامنة من السلسلة بشكل دوري. لا حاجة لاستدعاء واجهات RPC لخدمات السلسلة أو العقد للحصول على البيانات ذات الصلة في الوقت الحقيقي.
بالطبع، يجب أن تتم المعاملات الرئيسية على السلسلة. الآن، يقدم العديد من مزودي RPC في البلوكشين واجهات متقدمة للحصول على بعض البيانات بشكل أسرع وأقل تكلفة.
تقسيم العقود وإعادة استخدام العقود القياسية
قد يحتوي المشروع على عدة عقود تم نشرها بالفعل. حتى إذا كان هناك عقد واحد فقط تم نشره فعليًا، يمكننا أيضًا تقسيم الكود إلى عدة عقود من خلال وراثة الكود للحفاظ عليه.
على سبيل المثال ، فإن عقد NonfungiblePositionManager الخاص بـ Uniswap يرث من عدة عقود. بالإضافة إلى ذلك ، فإن عقد ERC721Permit يستخدم مباشرة عقد ERC721 القياسي من OpenZeppelin. وهذا لا يسهل فقط إدارة المراكز بطريقة NFT ، بل يمكنه أيضًا تحسين كفاءة التطوير من خلال استخدام العقود القياسية الحالية.
الخاتمة
الممارسة تجلب المعرفة الحقيقية. المشاركة الشخصية في تطوير نسخة مبسطة من بورصة لا مركزية ستساعدك على فهم أعمق لتطبيقات كود Uniswap، وفي نفس الوقت ستتعلم المزيد من النقاط المعرفية في المشاريع العملية. إذا كنت مهتمًا بتطوير مشاريع Web3 وDefi، يمكنك الرجوع إلى الدورات التدريبية العملية ذات الصلة، وإكمال بورصة مبسطة خطوة بخطوة. أعتقد أن هذا سيكون مفيدًا جدًا لتعلمك.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 6
أعجبني
6
4
مشاركة
تعليق
0/400
AirdropHunter9000
· 08-04 14:09
DeFi ليست سوى لعبة انخفاض إلى الصفر... من يفهم يفهم
شاهد النسخة الأصليةرد0
TokenAlchemist
· 08-04 14:09
هههه تخيل أنك لا تعرف عن CREATE2 لعناوين حتمية... لن أنجح بصراحة
شاهد النسخة الأصليةرد0
RugpullAlertOfficer
· 08-04 14:08
هذا بالتأكيد هو دليل مبتدئ بدون أساسيات
شاهد النسخة الأصليةرد0
AllTalkLongTrader
· 08-04 14:02
لا تنظر إلى الكود، انظر إلى العنوان. هل هو كسول أم عالٍ؟
7 تقنيات لشرح عقود Uniswap الذكية: يجب على مطوري Web3 قراءتها
ما يجب أن يعرفه مطورو Web3: الدروس القيمة المستفادة من عقد Uniswap
مؤخراً، أثناء كتابتي لدليل تطوير تبادل لامركزي، قمت بدراسة متعمقة لتنفيذ كود Uniswap V3، وجنيت فوائد كبيرة. كوني مبتدئاً في تطوير عقود DeFi، فإن هذه التقنيات كانت بلا شك بمثابة إلهام لي. أعتقد أن هذه الخبرات ستفيد أيضاً الأصدقاء الذين يرغبون في دخول عالم تطوير العقود الذكية.
حيل لتوقع عنوان العقد
عادةً ما يبدو العنوان الذي تم الحصول عليه بعد نشر العقد عشوائيًا ويصعب التنبؤ به. ولكن في Uniswap، يمكننا استنتاج عنوان العقد من خلال أزواج التداول والمعلومات ذات الصلة. وهذا مفيد جدًا في سيناريوهات مثل تحديد صلاحيات التداول أو الحصول على عنوان المسبح.
يستخدم Uniswap طريقة CREATE2 لإنشاء العقود، من خلال إضافة معلمة "salt" لجعل العنوان الناتج قابلاً للتنبؤ. منطق توليد العنوان المحدد هو: العنوان الجديد = hash("0xFF"، عنوان المنشئ، salt، initcode).
الاستخدام الذكي للدوال العكسية
في بعض السيناريوهات، فإن الاستدعاءات المتبادلة بين العقود تكون مفيدة جداً. على سبيل المثال، تستدعي طريقة A الطريقة B، وتقوم B بالاستدعاء مرة أخرى لـ A في الطريقة التي تم استدعاؤها.
في Uniswap، عند استدعاء طريقة swap لعقد UniswapV3Pool لإجراء صفقة، ستقوم باستدعاء swapCallback، مع تمرير الكمية الفعلية المطلوبة من الرموز المحسوبة. يتعين على الطرف المستدعي نقل الرموز المطلوبة إلى UniswapV3Pool في الاستدعاء الراجع. يضمن هذا التصميم أمان طريقة swap وسلامتها المنطقية، دون الحاجة إلى تسجيل متغيرات معقدة.
تمرير معلومات استثنائية، تنفيذ تقدير المعاملات باستخدام try-catch
في عقد Quoter الخاص بـ Uniswap، يتم استخدام try-catch لتغليف تنفيذ طريقة swap الخاصة بـ UniswapV3Pool. وذلك لمحاكاة swap لتقدير الرموز المطلوبة للتداول. نظرًا لأن التقدير لا يقوم فعليًا بتبادل الرموز، فإنه سيؤدي إلى حدوث خطأ. يقوم Uniswap بإلقاء خطأ خاص في دالة رد الاتصال للتداول، ثم يلتقط هذا الخطأ ويحلل منه المعلومات المطلوبة.
تبدو هذه الطريقة وكأنها حيلة، لكنها عملية للغاية. لا حاجة لتعديل طريقة swap خصيصًا لتقدير متطلبات التداول، حيث أن المنطق أكثر بساطة.
حل مشاكل الدقة في العمليات العددية الكبيرة
يتضمن كود Uniswap الكثير من المنطق الحسابي، مثل حساب كمية التوكنات المتبادلة بناءً على السعر الحالي والسيولة. لتجنب فقدان الدقة الناتج عن عمليات القسمة، يتم استخدام عملية "<< FixedPoint96.RESOLUTION" بشكل متكرر في عملية الحساب، أي التحويل لليسار بمقدار 96 بت، وهو ما يعادل الضرب في 2^96. في ظل عدم وجود تجاوز في المعاملات العادية، يتم عادةً استخدام uint256 لحساب (، وهذه الطريقة تضمن فعالية الدقة.
![سلسلة المبتدئين في Web3: نصائح صغيرة لتطوير العقود تعلمتها من كود Uniswap])https://img-cdn.gateio.im/webp-social/moments-b0c3d4eb7e8ca88cc4cfc9476a34437a.webp(
حساب الأرباح من آلية المشاركة
يحتاج Uniswap إلى تسجيل عائدات رسوم مقدمي السيولة LP). من الواضح أنه لا يمكن تسجيل الرسوم لكل LP بشكل منفصل في كل عملية تداول، لأن ذلك سيستهلك كمية كبيرة من غاز.
حل Uniswap هو تعريف feeGrowthInside0LastX128 و feeGrowthInside1LastX128 في هيكل Position، لتسجيل رسوم العمولة المستحقة لكل وحدة من السيولة عند سحب الرسوم في المرة الأخيرة لكل مركز.
تتطلب هذه الطريقة فقط تسجيل إجمالي الرسوم وتوزيع الرسوم على كل وحدة من السيولة. عند سحب LP، يمكن حساب الرسوم القابلة للسحب بناءً على السيولة المحتفظ بها. هذا مشابه لكيفية حساب حامل الأسهم للأرباح القابلة للسحب الحالية بناءً على تاريخ أرباح السهم الواحد للشركة والأرباح في آخر سحب.
التوازن في الحصول على المعلومات على السلسلة
تخزين البيانات على السلسلة مكلف نسبيًا، وليس كل المعلومات بحاجة إلى أن تكون على السلسلة أو الحصول عليها من السلسلة. على سبيل المثال، العديد من واجهات الـ API التي يستدعيها موقع Uniswap الأمامي هي واجهات تقليدية من Web2.
يمكن تخزين قائمة أحواض التداول ومعلومات أحواض التداول في قاعدة بيانات عادية، وقد يحتاج البعض إلى المزامنة من السلسلة بشكل دوري. لا حاجة لاستدعاء واجهات RPC لخدمات السلسلة أو العقد للحصول على البيانات ذات الصلة في الوقت الحقيقي.
بالطبع، يجب أن تتم المعاملات الرئيسية على السلسلة. الآن، يقدم العديد من مزودي RPC في البلوكشين واجهات متقدمة للحصول على بعض البيانات بشكل أسرع وأقل تكلفة.
تقسيم العقود وإعادة استخدام العقود القياسية
قد يحتوي المشروع على عدة عقود تم نشرها بالفعل. حتى إذا كان هناك عقد واحد فقط تم نشره فعليًا، يمكننا أيضًا تقسيم الكود إلى عدة عقود من خلال وراثة الكود للحفاظ عليه.
على سبيل المثال ، فإن عقد NonfungiblePositionManager الخاص بـ Uniswap يرث من عدة عقود. بالإضافة إلى ذلك ، فإن عقد ERC721Permit يستخدم مباشرة عقد ERC721 القياسي من OpenZeppelin. وهذا لا يسهل فقط إدارة المراكز بطريقة NFT ، بل يمكنه أيضًا تحسين كفاءة التطوير من خلال استخدام العقود القياسية الحالية.
الخاتمة
الممارسة تجلب المعرفة الحقيقية. المشاركة الشخصية في تطوير نسخة مبسطة من بورصة لا مركزية ستساعدك على فهم أعمق لتطبيقات كود Uniswap، وفي نفس الوقت ستتعلم المزيد من النقاط المعرفية في المشاريع العملية. إذا كنت مهتمًا بتطوير مشاريع Web3 وDefi، يمكنك الرجوع إلى الدورات التدريبية العملية ذات الصلة، وإكمال بورصة مبسطة خطوة بخطوة. أعتقد أن هذا سيكون مفيدًا جدًا لتعلمك.