Uniswap V2 को इस तरह डिज़ाइन किया गया था कि यह स्वैप फीस का 1/6 हिस्सा प्रोटोकॉल के लिए कलेक्ट करे। चूँकि एक स्वैप फीस 0.3% है, इसका 1/6 हिस्सा 0.05% होता है, इसलिए हर ट्रेड का 0.05% प्रोटोकॉल को जाएगा।

हालाँकि यह फीचर वास्तव में कभी चालू (activate) नहीं किया गया था, फिर भी हम इस फीचर पर चर्चा कर रहे हैं क्योंकि कुछ फोर्क्स (forks) इसका उपयोग कर सकते हैं। इसके अलावा, इसकी गणना में गलती होना बहुत आसान है, इसलिए इसे समझने में अभी समय निवेश करने से आपको बाद में इसी तरह की गणनाओं में त्रुटियों (errors) को पकड़ने में मदद मिलेगी।

पूर्वापेक्षाएँ (Prerequisites)

इसके साथ आगे बढ़ने के लिए आपको Uniswap V2 Book के सभी पिछले अध्यायों से परिचित होना चाहिए।

स्वैप के दौरान प्रोटोकॉल फीस कलेक्ट करना अकुशल (inefficient) है

हर ट्रेड पर 0.05% फीस कलेक्ट करना अकुशल (inefficient) होगा क्योंकि इसके लिए अतिरिक्त टोकन ट्रांसफर की आवश्यकता होगी। ERC20 टोकन ट्रांसफर करने के लिए स्टोरेज अपडेट की आवश्यकता होती है, इसलिए एक के बजाय दो एड्रेस पर ट्रांसफर करना काफी अधिक महंगा होगा।

इसलिए, जब कोई लिक्विडिटी प्रोवाइडर burn or mint कॉल करता है तब फीस कलेक्ट की जाती है। चूंकि ये ऑपरेशन्स [swapping tokens](swapping tokens) की तुलना में कम होते हैं, इसलिए इससे गैस की बचत होगी। mintFee कलेक्ट करने के लिए, कॉन्ट्रैक्ट पिछली बार के बाद से कलेक्ट की गई फीस की मात्रा की गणना करता है, और beneficiary एड्रेस पर पर्याप्त LP टोकन मिंट करता है ताकि beneficiary फीस के 1/6 हिस्से का हकदार हो सके।

fee और mintFee की शब्दावली (Terminology)

शब्दावली में भ्रम से बचने के लिए, हम स्वैप के दौरान ट्रेडर्स से कलेक्ट किए गए 0.3% को “fee” कहते हैं, और 0.3% फीस के 1/6 हिस्से को “mintFee” कहते हैं। हाँ, दोनों शब्दों में ‘fee’ का होना कोई बेहतरीन नामकरण (nomenclature) नहीं है, लेकिन हमें इसी के साथ काम करना है।

लिक्विडिटी पूल में मौजूद टोकन बैलेंस के गुणनफल (product) का वर्गमूल (square root) है। इस फॉर्मूले के औचित्य (justification) पर Uniswap V2 स्वैप फ़ंक्शन आर्टिकल में चर्चा की गई थी। कुछ साहित्य (literature) इसे $\sqrt{k}$ के रूप में संदर्भित करते हैं जहाँ $k = xy$ और $x$ और $y$ पूल में टोकन बैलेंस ($x$ और $y$ के रिज़र्व) हैं। हम लिक्विडिटी को $\ell$ से संदर्भित करते हैं क्योंकि इसे $\sqrt{k}$ की तुलना में लिखना छोटा है।

mintFee की गणना की मान्यताएँ (assumptions)

इसके काम करने के लिए, Uniswap V2 निम्नलिखित दो इनवेरिएंट्स (invariants) पर निर्भर करता है:

• यदि mint() और burn() कॉल नहीं किए जाते हैं, तो पूल की लिक्विडिटी केवल बढ़ सकती है।
• लिक्विडिटी में वृद्धि विशुद्ध रूप से फीस (या डोनेशन) के कारण होती है।
  पिछले mint() या burn() ट्रांजैक्शन के बाद से लिक्विडिटी में हुई वृद्धि को मापकर, पूल को यह पता चल जाता है कि कितनी फीस कलेक्ट की गई है।

लिखने के लिए ये अच्छे invariant tests हो सकते हैं, लेकिन अभी के लिए हम यह मानकर चलेंगे कि ये सत्य हैं।

mintFee की गणना का उदाहरण

मान लीजिए $t_1$ पर पूल 10 token0 और 10 token1 से शुरू होता है।

बहुत सारे ट्रेडिंग और फीस कलेक्शन के बाद, $t_2$ पर नया पूल बैलेंस 40 token0 और 40 token1 हो जाता है।

लिक्विडिटी को दो टोकनों के गुणनफल के वर्गमूल के रूप में मापा जाता है, यानी $\ell = \sqrt{k}$। $t_1$ पर लिक्विडिटी 10 थी और $t_2$ पर 40 थी। दूसरे शब्दों में, $\ell_1 = 10$ और $\ell_2 = 40$। हम 10 से 40 तक की वृद्धि पर फीस चार्ज करने जा रहे हैं।

$t_2$ पर कुल 40 में से 30 यूनिट लिक्विडिटी स्वैप फीस के कारण है।

हम पर्याप्त LP टोकन, यानी “mintFee” को मिंट करना चाहते हैं ताकि beneficiary को पूल के “फीस वाले हिस्से” का 1/6 हिस्सा मिल सके। अर्थात्, वे मुनाफे (profit) से आई 5 यूनिट लिक्विडिटी (30 / 6) के हकदार होने चाहिए।

प्रोटोकॉल को किसी भी “मूल लिक्विडिटी” (original liquidity) यानी $\ell_1$ पर फीस कलेक्ट नहीं करनी चाहिए। प्रोटोकॉल को केवल डेल्टा (delta), यानी $\ell_2 - \ell_1$ पर फीस कलेक्ट करनी चाहिए।

जब mint() या burn() कॉल किया जाता है, तो Uniswap प्रोटोकॉल फीस प्राप्तकर्ता (recipient) के लिए LP टोकन मिंट करता है। इसके कारण ऐसा डाइल्यूशन (dilution) होता है कि LP टोकन्स की वर्तमान सप्लाई (current supply) मूल लिक्विडिटी के साथ-साथ “प्रॉफिट लिक्विडिटी” (स्वैप फीस से प्राप्त लिक्विडिटी) के 5/6 हिस्से को रिडीम कर सकती है।

mint fee फॉर्मूले को डिराइव करना (Deriving)

आइए निम्नलिखित नोटेशन (notation) का उपयोग करें:

• $s$: डाइल्यूटिव प्रोटोकॉल फीस LP टोकन्स के मिंट होने से पहले LP टोकन्स की सप्लाई।

• $\eta$: प्रोटोकॉल के लिए मिंट किए जाने वाले LP टोकन्स की मात्रा है। यह प्रॉफिट लिक्विडिटी के 1/6 हिस्से को रिडीम करने के लिए पर्याप्त होनी चाहिए।

• $\ell_1$: मूल डिपॉजिट की लिक्विडिटी है, यानी वह लिक्विडिटी जो LPs ने प्रदान की थी।

• $\ell_2$: मूल डिपॉजिट और स्वैप फीस से उत्पन्न होने वाली लिक्विडिटी का योग (sum) है।

• $d$: प्रोटोकॉल फीस काटकर LPs को देय (owed) लिक्विडिटी की मात्रा है। अर्थात्, LPs अपने मूल डिपॉजिट और प्रॉफिट के 5/6 हिस्से के हकदार होने चाहिए।

• $p$: प्रोटोकॉल को देय (owed) लिक्विडिटी की मात्रा है। यह $\ell_2 - \ell_1$ का 1/6 हिस्सा है।

$\eta$ की गणना करने के लिए, हम देखते हैं कि निम्नलिखित इनवेरिएंट (invariant) सत्य होना चाहिए:

दूसरे शब्दों में, पिछली कुल सप्लाई, $s$ LP टोकन LPs को देय (due) लिक्विडिटी को रिडीम कर सकते हैं, और $\eta$ LP टोकन प्रोटोकॉल को देय राशि को रिडीम कर सकते हैं।

नीचे दिया गया ग्राफ़िक लिक्विडिटी में परिवर्तन के संदर्भ में $\eta$ के लिए हल (solve) करता है।

Uniswap V2 का _mintFee() कोड

इस डेरिवेशन को ध्यान में रखते हुए, Uniswap V2 के _mintFee फ़ंक्शन का अधिकांश भाग स्व-व्याख्यात्मक (self-explanatory) होना चाहिए। यहाँ नोटेशन (notation) में कुछ बदलाव दिए गए हैं:

• फीस के बाद की वर्तमान लिक्विडिटी $\ell_2$ rootK है
• पिछली लिक्विडिटी $\ell_1$ kLast है
• डाइल्यूशन से पहले LP टोकन्स की सप्लाई $s$ totalSupply है
• यह फ़ंक्शन स्टेट चेंजिंग (state changing) है, यह mintFee की गणना को रिटर्न करने के बजाय फ़ंक्शन के अंदर ही mintFee को मिंट करता है (blue highlight)
• फीस को feeOn फ्लैग के साथ चालू और बंद (switched on and off) किया जा सकता है, जिस पर हमने अभी तक चर्चा नहीं की है

हम इस फ़ंक्शन में थोड़ा और गहराई से जाएँगे, लेकिन सबसे पहले हम यह देखना चाहते हैं कि kLast कहाँ अपडेट होता है।

klast कहाँ अपडेट होता है

उपरोक्त कोड में, kLast तब तक सेट नहीं होता जब तक कि feeOn को false पर स्विच नहीं किया जाता। इसे mint और burn के पूरा होने पर सेट किया जाता है लेकिन swap पर नहीं, क्योंकि हमारी दिलचस्पी लिक्विडिटी जमा (deposit) और निकासी (withdrawal) इवेंट्स के बीच स्वैप के कारण फीस की वृद्धि को मापने में है। जिस जगह पर kLast सेट किया गया है उसे पीले बॉक्स (yellow box) से मार्क किया गया है।

Mint फ़ंक्शन द्वारा klast को अपडेट करना

Burn फ़ंक्शन द्वारा klast को अपडेट करना

_mintFee कोड की शर्तें (conditions)

अब जब हम समझ गए हैं कि kLast कैसे अपडेट होता है, तो हम _mintFee फ़ंक्शन को पूरी तरह से समझा सकते हैं।

आइए ऊपर दिए गए कोड स्निपेट में संभावनाओं पर विचार करें, जिसे सुविधा के लिए दोहराया गया है।

1. feeOn की वैल्यू false है, कुछ भी मिंट नहीं होता है (green highlight)
2. feeOn की वैल्यू false है, kLast शून्य (zero) है (yellow highlight)
3. feeOn की वैल्यू false है, kLast शून्य नहीं है (yellow highlight)
4. feeOn की वैल्यू true है, लेकिन लिक्विडिटी में कोई वृद्धि नहीं हुई है (orange highlight)
5. feeOn की वैल्यू true है, और लिक्विडिटी में वृद्धि हुई है (orange highlight), इसलिए mint fee लागू होती है (blue highlight)

इस लॉजिक को डिसीजन ट्री (decision tree) में देखना अधिक आसान है, इसलिए यहाँ डिसीजन ट्री दिया गया है जिसकी शाखाएँ (branches) ‘if’ स्टेटमेंट्स के समान रंग की हैं।

RareSkills के साथ और जानें

हमारे कोर्स ऑफ़रिंग्स देखने के लिए कृपया हमारा blockchain bootcamp देखें।

मूल रूप से 14 नवंबर, 2023 को प्रकाशित