استكشاف الآليات الأساسية لـ Uniswapv4

المقدمة:

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

لا يقتصر تركيز ابتكار Uniswapv4 على تحسين تقنية AMM فحسب، بل أيضًا على توسيع النظام البيئي. على وجه التحديد، يتضمن هذا الابتكار الميزات الرئيسية التالية:

• محاسبة فلاش
• عقد سينجلتون
• هندسة هوكس

في الأقسام التالية، سأشرح بالتفصيل أهمية هذه الميزات ومبادئ تنفيذها.

المصدر: https://twitter.com/jermywkh/status/1670779830621851650

محاسبة فلاش

مسك الدفاتر ذات القيد المزدوج

تتبنى UniSwapv4 طريقة حفظ السجلات المشابهة لمسك الدفاتر ذات القيد المزدوج لتتبع تغييرات رصيد الرموز المميزة المقابلة لكل عملية. تتطلب طريقة مسك الدفاتر ذات القيد المزدوج تسجيل كل معاملة في حسابات متعددة في وقت واحد وضمان بقاء رصيد الأصول بين هذه الحسابات متوازنًا. على سبيل المثال، لنفترض أن المستخدم يتبادل 100 TokenA مقابل 50 TokenB من المجمع. سيكون السجل في دفتر الأستاذ كما يلي:

• المستخدم: انخفض TokenA بمقدار 100 وحدة (-100)، بينما زاد TokenB بمقدار 50 وحدة (+50).
• POOL: ارتفع TokenA بمقدار 100 وحدة (+100)، بينما انخفض TokenB بمقدار 50 وحدة (-50).

توكن دلتا والعمليات ذات الصلة

في UniSwapv4، تُستخدم طريقة حفظ السجلات هذه بشكل أساسي للعمليات الرئيسية، ومتغير تخزين يسمى Lockstate.currencyDelta [currency] يتم استخدامه في الكود لتسجيل مقدار تغييرات رصيد الرمز المميز. إذا كانت قيمة هذه الدلتا إيجابية، فإنها تمثل الزيادة المتوقعة في مبلغ الرمز المميز في المجمع، بينما تمثل القيمة السالبة الانخفاض المتوقع في مبلغ الرمز المميز. بدلاً من ذلك، إذا كانت القيمة موجبة، فإنها تشير إلى مقدار نقص الرمز المميز في المجمع (المبلغ المتوقع استلامه)، بينما تشير القيمة السالبة إلى الرمز الزائد في المجمع (المبلغ المتوقع أن يسحبه المستخدمون). تعرض القائمة التالية تأثيرات العمليات المختلفة على Token Delta:

• ModifyPosition: يمثل عملية إضافة/إزالة السيولة. بالنسبة لإضافة السيولة، يتم تحديث TokenDelta باستخدام الإضافة (التي تمثل الكمية المتوقعة من TokenA لإضافتها إلى المجمع). بالنسبة لإزالة السيولة، يتم تحديث TokenDelta باستخدام الطرح (الذي يمثل الكمية المتوقعة من TokenB ليتم سحبها من المجمع).
• المبادلة: تمثل عملية المبادلة. بأخذ مثال مبادلة TokenA بـ TokenB، يتم تحديث TokenAdelta باستخدام الإضافة، بينما يتم تحديث TokenBDelta باستخدام الطرح.
• settle: يرافق نقل الرموز إلى المجمع. يقوم المجمع بحساب الزيادة في مبلغ الرمز المميز قبل وبعد وتحديث TokenDelta باستخدام الطرح. إذا تلقى المجمع الكمية المتوقعة من الرموز، فإن عملية الطرح ستؤدي إلى إلغاء TokenDelta.
• خذ: يرافق سحب الرموز من المجمع. يتم تحديث TokenDelta باستخدام الإضافة، مما يشير إلى أنه تمت إزالة الرموز المميزة من المجموعة.
• النعناع: يشبه سلوك تحديث TokenDelta «take»، ولكن بدلاً من سحب الرموز المميزة فعليًا من المجمع، يتم إصدار رموز ERC1155 كدليل على السحب، بينما تظل الرموز المميزة في المجمع. في وقت لاحق، يمكن للمستخدمين استرداد الرموز من المجمع عن طريق حرق رموز ERC1155. قد يكون الغرض من هذا النهج ذا شقين: 1. وفر تكاليف الغاز لعمليات نقل رمز ERC20 (مكالمة تعاقدية + كتابة تخزين أقل)، واستخدم حرق رمز ERC1155 في المستقبل لتحديث TokenDelta للمعاملات. 2. حافظ على السيولة في المجمع للحفاظ على تجمع سيولة عميق لتجربة تبادل أفضل للمستخدمين.
• تبرع: تعلن هذه العملية عن التبرع بالرموز إلى المجمع، ولكن في الواقع، لا تزال هناك حاجة إلى نقل الرموز إلى المجمع باستخدام «settle». لذلك، يتم تحديث TokenDelta باستخدام الإضافة في هذه الحالة.

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

مثال على توكن دلتا

هنا نستخدم مثالًا بسيطًا لتوضيح كيفية تحديث TokenDelta. لنفترض أننا اليوم نتبادل 100 توكن أ مقابل 50 توكينب:

1. قبل بدء المعاملة، يكون كل من TokenAdelta و TokenBDelta 0.
2. المبادلة: احسب مقدار TokenA الذي يحتاجه المجمع ومقدار TokenB الذي سيحصل عليه المستخدم. عند هذه النقطة، توكن دلتا = 100، توكن دلتا = -50.
3. التسوية: أرسل 100 توكن A إلى المجمع وقم بتحديث TokenAdelta = 100 - 100 = 0.
4. خذ: نقل 50 TokenB من المجمع إلى حساب المستخدم وتحديث TokenBDelta = -50 + 50 = 0.
5. بعد اكتمال المعاملة، يصبح كل من TokenAdelta و TokenBDelta 0.

عند اكتمال عملية التبادل بأكملها، تتم إعادة تعيين كل من TokenAdelta و TokenBDelta إلى 0. وهذا يعني أن العملية كانت متوازنة تمامًا، مما يضمن اتساق أرصدة الحسابات.

EIP-1153: رموز التخزين العابر

في السابق، ذُكر أن UniSwapv4 يستخدم متغيرات التخزين لتسجيل TokenDelta. ومع ذلك، ضمن العقد، تعد القراءة والكتابة إلى Storage Variables مكلفة للغاية. هذا يقودنا إلى EIP آخر قدمته Uniswap: EIP1153 - رموز تشغيل التخزين العابر.

تخطط UniSwapv4 لاستخدام أكواد تشغيل TSTORE و TLOAD التي توفرها EIP1153 لتحديث توكيندلتا. سيتم تجاهل متغيرات التخزين التي تعتمد رموز تشغيل التخزين العابر بعد نهاية المعاملة (على غرار متغيرات الذاكرة)، وبالتالي تقليل رسوم الغاز.

تم تأكيد تضمين EIP1153 في ترقية كانكون القادمة، وذكر UnisWAPv4 أيضًا أنه سيتم تشغيله بعد ترقية كانكون، كما ورد هنا.

المصدر: https://etherworld.co/2022/12/13/transient-storage-for-beginners/

محاسبة فلاش - لوك

يقدم Uniswapv4 آلية قفل، مما يعني أنه قبل إجراء أي عملية تجميع، يجب عليك أولاً الاتصال بـ Poolmanager.lock () للحصول على قفل. أثناء تنفيذ lock ()، يتحقق مما إذا كانت قيمة TokenDelta هي 0، وإلا فسوف تعود. بمجرد الحصول على poolmanager.lock () بنجاح، فإنه يستدعي وظيفة lockAgained () الخاصة بـ msg.sender. داخل وظيفة lockAquered ()، يتم تنفيذ العمليات المتعلقة بالمجمع، مثل المبادلة وmodifyPosition.

العملية موضحة أدناه. عندما يحتاج المستخدم إلى تنفيذ عملية Token Swap، يجب عليه استدعاء عقد ذكي مع وظيفة lockAquared () (المشار إليها باسم عقد رد الاتصال). يستدعي عقد رد الاتصال أولاً poolmanager.lock ()، ثم يقوم PoolManager باستدعاء وظيفة lockAquared () لعقد رد الاتصال. داخل الدالة lockAquered ()، يتم تعريف المنطق المرتبط بعمليات التجميع، مثل المبادلة، والتسوية، والأخذ. أخيرًا، عندما يكون القفل () على وشك الانتهاء، يتحقق PoolManager مما إذا كان TokenDelta المرتبط بهذه العملية قد تمت إعادة تعيينه إلى 0، مما يضمن بقاء رصيد الأصول في المجمع سليمًا.

عقد سينجلتون

عقد Singleton يعني أن Uniswapv4 قد تخلى عن نموذج Factory-Pool السابق. لم يعد كل تجمع عقدًا ذكيًا مستقلاً، ولكن جميع المجمعات تشترك في عقد فردي واحد. يتطلب هذا التصميم، جنبًا إلى جنب مع آلية محاسبة الفلاش، تحديث متغيرات التخزين الضرورية فقط، مما يقلل من تعقيد العمليات وتكلفتها.

في المثال أدناه، باستخدام Uniswapv3 كمثال، سيتطلب تبادل ETH مقابل DAI أربع عمليات نقل رمزية على الأقل (عمليات كتابة التخزين). يتضمن ذلك العديد من التغييرات المسجلة لرموز USDC و USDT و DAI. ومع ذلك، مع التحسينات في Uniswapv4، إلى جانب آلية محاسبة الفلاش، هناك حاجة إلى نقل رمز واحد فقط (نقل DAI من المجمع إلى المستخدم)، مما يقلل بشكل كبير من عدد العمليات والتكاليف.

المصدر: https://twitter.com/Uniswap/status/1671208668304486404

هندسة هوكس

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

• قبل التهيئة/بعد التهيئة
• قبل تعديل الموضع/بعد تعديل الموضع
• قبل المبادلة/بعد المبادلة
• قبل التبرع/بعد التبرع

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

المصدر: https://github.com/Uniswap/v4-core/blob/main/whitepaper-v4-draft.pdf

مثال هوك - ربط الحد من الطلب

بعد ذلك، سنستخدم مثالاً على أمر الحد لشرح عملية التشغيل الفعلية لـ Hooks في Uniswapv4. قبل أن نبدأ، دعونا نشرح بإيجاز مبدأ تنفيذ أوامر الحد في Uniswapv4.

آلية ترتيب الحد الخاصة بـ Uniswapv4

يعمل تطبيق UniSwapv4 لأمر الحد عن طريق إضافة السيولة إلى نطاق سعري محدد ثم تنفيذ عملية إزالة السيولة إذا تم تبديل السيولة في هذا النطاق.

على سبيل المثال، لنفترض أننا أضفنا السيولة في النطاق السعري 1900-2000 لـ ETH، ثم يرتفع سعر ETH من 1800 إلى 2100. في هذه المرحلة، تم استبدال كل سيولة ETH التي أضفناها سابقًا في النطاق السعري 1900-2000 بـ USDC (بافتراض ذلك في مجمع ETH-USDC). من خلال إزالة السيولة في هذه اللحظة، يمكننا تحقيق تأثير مماثل لتنفيذ أمر سوق ETH في النطاق السعري الحالي من 1900-2000.

عقد ربط الطلبات المحدودة

هذا المثال مأخوذ من GitHub من Uniswapv4. في هذا المثال، يوفر عقد ربط الحد من الطلبات خطافين، وهما AfterInitialize و AfterSwap. يُستخدم خطاف AfterInitialize لتسجيل النطاق السعري (العلامة) عند إنشاء تجمع، من أجل تحديد أوامر الحد التي تمت مطابقتها بعد مقايضة شخص ما.

شارك في الاشتراك

عندما يحتاج المستخدم إلى تقديم طلب، يقوم عقد Hook بتنفيذ عملية إضافة السيولة بناءً على النطاق السعري والكمية المحددين من قبل المستخدم. في عقد هوك لأوامر الحد، يمكنك رؤية وظيفة place (). المنطق الرئيسي هو استدعاء وظيفة lockAcquiredPlace () بعد الحصول على القفل لتنفيذ عملية إضافة السيولة، وهو ما يعادل وضع أمر الحد.

المصدر: https://github.com/Uniswap/v4-periphery/blob/main/contracts/hooks/examples/LimitOrder.sol#L246

خطاف ما بعد المبادلة

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

المصدر: https://github.com/Uniswap/v4-periphery/blob/main/contracts/hooks/examples/LimitOrder.sol#L192

الحد من تدفق الطلبات

فيما يلي مخطط انسيابي يوضح عملية تنفيذ أمر الحد:

1. يرسل مقدم الطلب الطلب إلى عقد هوك.
2. ينفذ عقد Hook عمليات إضافة السيولة بناءً على معلومات الطلب.
3. يقوم المستخدمون العاديون بعمليات Token Swap في المجمع.
4. بعد الانتهاء من عملية Swap Token، يستدعي المجمع وظيفة AfterSwap () لعقد هوك.
5. ينفذ عقد هوك عمليات إزالة السيولة لأوامر الحد المملوءة بناءً على اختلاف النطاق السعري للرموز التي تم تبديلها.

ما ورد أعلاه هو العملية الكاملة لتنفيذ Limit-Order باستخدام آلية Hook.

هوك: ميزات أخرى

تحتوي Hooks على العديد من النقاط المثيرة للاهتمام التي أجدها تستحق المشاركة.

بت عنوان عقد هوكس

يتم تحديد قرار تنفيذ عمليات محددة قبل/بعد بواسطة 1 بايت في أقصى اليسار من عنوان عقد هوك. 1 بايت يساوي 8 بت، وهو ما يتوافق مع 8 إجراءات إضافية. سيتحقق المجمع مما إذا كان جزء هذا الإجراء هو 1 لتحديد ما إذا كان سيتم استدعاء وظيفة الخطاف المقابلة لعقد الخطاف. هذا يعني أيضًا أن عنوان عقد Hook يجب أن يتم تصميمه بطريقة محددة ولا يمكن اختياره بشكل تعسفي كعقد Hook. يهدف هذا التصميم بشكل أساسي إلى تقليل استهلاك الغاز وتحويل التكلفة إلى نشر العقد لتحقيق عمليات أكثر كفاءة. (ملاحظة: من الناحية العملية، يمكن استخدام أملاح CREATE2 المختلفة لحساب القوة الغاشمة لعناوين العقود التي تستوفي الشروط)

رسوم ديناميكية

بالإضافة إلى القدرة على إجراء عمليات إضافية قبل وبعد كل إجراء، تدعم Hooks أيضًا تنفيذ الرسوم الديناميكية. عند إنشاء تجمع، يمكنك تحديد ما إذا كنت تريد تمكين الرسوم الديناميكية. في حالة تمكين الرسوم الديناميكية، يتم استدعاء وظيفة getFee () لعقد Hook عند تبديل الرموز المميزة. يمكن أن يحدد عقد Hook مقدار الرسوم التي سيتم تحصيلها بناءً على الحالة الحالية للمسبح. يسمح هذا التصميم بحساب الرسوم المرن بناءً على الظروف الفعلية، مما يزيد من مرونة النظام.

إنشاء حمام السباحة

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

إلى؛ جاف

• يتم استخدام Flash Accounting لتتبع التغييرات الكمية لكل رمز لضمان إلغاء جميع التغييرات بعد إكمال المعاملة. لتوفير رسوم الغاز، تستخدم Flash Accounting طريقة تخزين خاصة مقدمة من EIP1153.
• يساعد تصميم Singleton Contract على تقليل استهلاك الغاز عن طريق تجنب التحديثات لمتغيرات التخزين المتعددة.
• توفر بنية Hooks عمليات إضافية، مقسمة إلى مراحل ما قبل التنفيذ وما بعد التنفيذ. وهذا يسمح بمزيد من المرونة في كل عملية تجمع ولكنه يجعل أيضًا توجيه التجمعات أكثر تعقيدًا.

يؤكد Uniswapv4 بوضوح على توسيع نظام Uniswap البيئي بأكمله، وتحويله إلى بنية تحتية لتمكين بناء المزيد من الخدمات على أساس Uniswap Pools. هذا يساعد على تعزيز القدرة التنافسية لـ Uniswap ويقلل من مخاطر الخدمات البديلة. ومع ذلك، يبقى أن نرى ما إذا كانت ستحقق النجاح المتوقع. تتضمن بعض النقاط البارزة الجمع بين Flash Accounting و EIP1153، ونعتقد أن المزيد من الخدمات ستعتمد هذه الميزات في المستقبل، مما يؤدي إلى سيناريوهات تطبيق مختلفة. هذا هو المفهوم الأساسي لـ Uniswapv4، ونأمل أن يوفر فهمًا أعمق لكيفية عمل Uniswapv4. إذا كانت هناك أي أخطاء في المقالة، فلا تتردد في الإشارة إليها. نرحب أيضًا بالمناقشات والتعليقات.

أخيرًا، نود أن نشكر أنطون تشينج وبينغ تشين على مراجعة المقالة وتقديم ملاحظات قيمة!

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

1. تمت إعادة طباعة هذه المقالة من [medium]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [Albert Lin]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn（gatelearn@gate.io）، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. يقوم فريق Gate Learn بترجمة المقالة إلى لغات أخرى. ما لم يُذكر، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.