परिचय और पूर्व-आवश्यकताएं

Compound DeFi में सबसे महत्वपूर्ण लेंडिंग प्रोटोकॉल में से एक है, जिसने कई ब्लॉकचेन पर लगभग हर लेंडिंग प्रोटोकॉल के डिज़ाइन को प्रेरित किया है। यह लेख V3 के स्मार्ट कॉन्ट्रैक्ट आर्किटेक्चर की व्याख्या करता है।

चूंकि Compound एक लेंडिंग प्रोटोकॉल है, इसलिए हम मान कर चलते हैं कि पाठक इस बात से परिचित हैं कि how interest rates work in DeFi और DeFi लोन के संदर्भ में liquidations and collateral से वाकिफ हैं।

Compound V2 के विपरीत, Compound का प्रत्येक इंस्टेंस (instance) केवल एक ही एसेट उधार देता है। यानी, आप USDC मार्केट से केवल USDC और ETH मार्केट से केवल ETH ही उधार (borrow) ले सकते हैं – आप कुछ और उधार नहीं ले सकते। इन एसेट्स को उधार लेने के लिए, आपको मार्केट द्वारा निर्दिष्ट कोलैटरलाइजेशन रेशियो (collateralization ratio) के अनुसार कोलैटरल (collateral) प्रदान करना होगा (और यह रेशियो गवर्नेंस द्वारा तय किया जाता है)।

Compound V3 में उधार लेने योग्य एसेट को base asset कहा जाता है। चूंकि USDC उधार लेने और देने के लिए सबसे लोकप्रिय एसेट है, इसलिए हम अपने उदाहरणों में बेस एसेट के रूप में USDC का उपयोग करेंगे। वह स्मार्ट कॉन्ट्रैक्ट जो लेंडिंग और बॉरोइंग के कोर लॉजिक को संभालता है, उसे उनके साहित्य (literature) और कोडबेस में Comet कहा जाता है। लिखते समय, Compound के इंस्टेंस Ethereum मेननेट और विभिन्न L2s जैसे Polygon, Base और Arbitrum पर मौजूद हैं। उपलब्ध Compound V3 markets is here की सूची यहाँ दी गई है।

यह लेख इस स्मार्ट कॉन्ट्रैक्ट का उपयोग करने के तरीके और Solidity फ़ाइलों के आर्किटेक्चर का एक हाई-लेवल ओवरव्यू (high level overview) देता है।

भाग 1: Compound का उपयोग करना

Compound V3 के साथ तीन प्रमुख कार्य किए जा सकते हैं:

1. base asset को लेंड (उधार) करना

2. कोलैटरल की आपूर्ति (supply) करना और base asset को उधार (borrow) लेना

3. अंडर-कोलैटरलाइज्ड (under-collateralized) लोन को लिक्विडेट (liquidate) करना।

USDC लेंड करना

निम्नलिखित वीडियो Polygon नेटवर्क पर USDC लेंड करने की प्रक्रिया को दर्शाता है (USDC on Polygon market link)।

जो लोग प्रोटोकॉल में भाग लेते हैं उन्हें COMP टोकन रिवार्ड दिए जाते हैं। ऊपर दिए गए अकाउंट ने अब तक 0.0004 COMP रिवार्ड अर्जित किए हैं, जैसा कि pink arrow द्वारा दर्शाया गया है। इन रिवार्ड्स को अभी तक क्लेम (claim) नहीं किया गया है। इसके अतिरिक्त, इसने अब तक ब्याज के रूप में 6 सेंट से अधिक अर्जित किया है (4,602.0649 - 4,602.00 = 0.0649)।

green box और yellow box की कीमतों के बीच बेमेल होने का कारण यह है कि USDC हमेशा ठीक $1.00 नहीं होता है। नीचे दिया गया चार्ट Chainlink की हालिया oracle prices of USDC / USD on Polygon दिखाता है और पाठक देख सकते हैं कि यह हमेशा ठीक एक डॉलर नहीं होता है।

USDC उधार लेना (Borrowing)

निम्नलिखित वीडियो उधार (borrow) लेने की प्रक्रिया को दर्शाता है। इस बार अकाउंट ने कोलैटरल के रूप में 0.06 ETH ($110) प्रदान किया और $100 USDC उधार लिया। यह BASE L2 lending market पर किया गया था।

ब्राउज़र वॉलेट की जाँच करने पर, अकाउंट में अब 100 Base USDC हैं। USDCbC असल में Base पर ब्रिज (bridge) किया गया USDC है।

निम्नलिखित वीडियो उपयोगकर्ता को USDC वापस चुकाते हुए (ब्याज के काफी हद तक जमा होने से पहले) और ETH कोलैटरल को निकालते हुए (withdraw) दिखाता है।

Net borrow और net lending दरों (rates) को समझना

ऊपर दिए गए स्क्रीनशॉट में, ध्यान दें कि Net Supply APR (लेंडिंग ब्याज दर) Net Borrow APR (yellow circles) से अधिक है। यह आम तौर पर संभव नहीं है क्योंकि लेंडर्स (lenders) बॉरोअर्स (borrowers) के भुगतान से अधिक नहीं कमा सकते हैं। Compound गणना में COMP रिवार्ड्स की वैल्यू को शामिल कर रहा है। विशेष रूप से, बॉरोअर्स वर्तमान में 6.71% ब्याज देते हैं (top red circle) लेकिन COMP में 2.58% ब्याज कमाते हैं (top blue circle)। 6.71 - 2.58 = 4.13%, जो कि Net Borrow APR है।

इसी तरह, लेंडर्स वर्तमान में USDC लेंड करने से 6.47% कमाते हैं (lower red circle), लेकिन COMP रिवार्ड्स के मूल्य से 4.63% अतिरिक्त भी कमाते हैं (lower blue circle)। इन दोनों का योग 11.10% है।

चूंकि बॉरोअर्स USDC में 6.71% ब्याज दे रहे हैं और लेंडर्स 6.47% ब्याज प्राप्त कर रहे हैं, इसलिए USDC में 0.24% ब्याज प्रोटोकॉल को जा रहा है।

COMP रिवार्ड्स की दरें गवर्नेंस वोट्स (governance votes) के अधीन बदलती रहती हैं।

भाग 2: कोडबेस (codebase) को नेविगेट करना

Compound V3 में कमैंट्स या रिक्त स्थानों (blank spaces) को छोड़कर, 4,304 लाइन्स का Solidity कोड है।

10,000 फीट की ऊंचाई से Compound V3 आर्किटेक्चर

नीचे हमने GitHub repo of Compound V3 का स्क्रीनशॉट दिया है।

• green रंग में हाइलाइट की गई सभी फाइलें कोर बॉरोइंग और लेंडिंग कार्यक्षमता (functionality) रखती हैं। उनके बीच इनहेरिटेंस (inheritance) संबंध बाद में दिखाया जाएगा। Comet, Compound V3 का प्राथमिक लेंडिंग और बॉरोइंग स्मार्ट कॉन्ट्रैक्ट है।
• blue रंग में हाइलाइट की गई सभी फाइलें वह स्मार्ट कॉन्ट्रैक्ट बनाती हैं जो अपग्रेड के दौरान नए Comet इंस्टेंस को डिप्लॉय (deploy) करता है। फिर से, उनके बीच इनहेरिटेंस संबंध बाद में दिखाया जाएगा।
• pink रंग में हाइलाइट की गई फ़ाइल वह कॉन्ट्रैक्ट है जो रिवार्ड्स वितरित करता है।

निम्नलिखित चित्र (diagram) डिप्लॉय किए गए स्मार्ट कॉन्ट्रैक्ट्स का सारांश प्रस्तुत करता है जो Compound V3 बनाते हैं। यह केवल एक हाई-लेवल ओवरव्यू है, अधिक विस्तृत जानकारी बाद में दी जाएगी। ध्यान दें कि कलर कोडिंग ऊपर दिए गए हाइलाइट्स से मेल खाती है। विशेष रूप से, प्राथमिक लेंडिंग और बॉरोइंग कॉन्ट्रैक्ट (Comet) green है, नए Comet इंस्टेंस को डिप्लॉय करने से संबंधित कॉन्ट्रैक्ट्स नीले (blue) हैं, और रिवार्ड कॉन्ट्रैक्ट pink है।

अधिकांश उपयोगकर्ता Compound V3 के साथ comet प्रॉक्सी (GitHub में नहीं दिखाया गया) के माध्यम से या लेंडर अथवा बॉरोअर के रूप में भाग लेने पर COMP अर्जित करने के लिए rewards कॉन्ट्रैक्ट के माध्यम से इंटरैक्ट करेंगे। सभी यूज़र-फेसिंग (user-facing) लॉजिक comet कॉन्ट्रैक्ट में है जहां comet प्रॉक्सी अपनी कार्यक्षमता (functionality) को डेलिगेट (delegate) करता है।

जब गवर्नेंस किसी अपग्रेड के लिए वोट करता है, तब नए comet इंस्टेंस को डिप्लॉय करने के लिए configuration and factory कॉन्ट्रैक्ट्स का उपयोग किया जाता है।

एस्टरिस्क (*) वाले स्मार्ट कॉन्ट्रैक्ट्स के कई एंसेस्टर (ancestor) कॉन्ट्रैक्ट्स होते हैं। अगले भाग में, हम Comet की इनहेरिटेंस चेन (inheritance chain) दिखाएंगे।

Compound V3 में गवर्नेंस के आधार पर पैरामीटर्स को अपडेट करने का एक असामान्य तरीका है

यदि क्रिप्टो-आर्थिक (crypto-economic) स्थितियाँ बदलती हैं तो गवर्नेंस द्वारा इंटरेस्ट रेट मॉडल्स (Interest rate models) को बदला जा सकता है, और लिक्विडेशन फैक्टर्स (liquidation factors) को भी। Compound यह सारी जानकारी स्टोरेज (storage) के बजाय इम्यूटेबल वेरिएबल्स (immutable variables) में स्टोर करता है। इन वैल्यूज़ को बदलने के लिए, एक नया Comet इंस्टेंस डिप्लॉय किया जाना चाहिए, और प्रॉक्सी को नए इम्प्लीमेंटेशन (implementation) कॉन्ट्रैक्ट में अपडेट किया जाता है।

यह एक अजीब डिज़ाइन विकल्प (design choice) लग सकता है, लेकिन इसके कई फायदे हैं:

• इम्यूटेबल वेरिएबल्स स्टोरेज वेरिएबल्स की तुलना में बहुत अधिक गैस कुशल (gas efficient) होते हैं।
• कोर कॉन्ट्रैक्ट्स को सेटर फंक्शन्स (setter functions) के साथ खुद को अव्यवस्थित (clutter) करने की आवश्यकता नहीं होती है।

हम पैरामीटर परिवर्तन (parameter change) के जीवनचक्र (lifecycle) का बाद में परीक्षण करेंगे।

Comet इनहेरिटेंस (Inheritance)

Comet के पूर्वजों (ancestors) को नीचे दिए गए चित्र में दिखाया गया है। हम इस भाग में प्रत्येक एंसेस्टर कॉन्ट्रैक्ट का एक हाई-लेवल ओवरव्यू देंगे।

CometMath.sol (ऊपर बाएँ gray ellipse)

Comet math में अनसाइंड इंटीजर्स (unsigned integers) को लोअर बिट वैल्यू (lower bit value) के अनसाइंड इंटीजर्स में कास्ट (cast) करने और अगर इससे ओवरफ्लो (overflow) होता है तो उसे रिवर्ट (revert) करने के लिए कई फंक्शन्स होते हैं। उदाहरण के लिए, यदि हम uint256 को uint104 में कास्ट करते हैं, लेकिन uint256 का मान uint104 में स्टोर किए जा सकने वाले मान से बड़ा है, तो यह रिवर्ट हो जाएगा। आप पूरे कोडबेस में safe64 जैसे फंक्शन्स देखेंगे। उम्मीद है कि ये आगे की व्याख्या के बिना समझने में काफी आसान हैं। फ़ाइल छोटी है, इसलिए हम इसे यहाँ पूरी तरह से दिखाते हैं:

CometStorage.sol (red ellipse)

Comet द्वारा उपयोग किया जाने वाला हर एक स्टोरेज वेरिएबल CometStorage.sol में परिभाषित किया गया है और कहीं नहीं। अर्थात्, CometStorage के अलावा Comet इनहेरिटेंस चेन के किसी अन्य कॉन्ट्रैक्ट में कोई स्टोरेज वेरिएबल नहीं है।

CometCore.sol (दूसरी पंक्ति gray ellipse)

CometCore.sol यह परिभाषित करता है कि Compound लेंडर्स और बॉरोअर्स के लिए ब्याज के संचय (accumulation) को कैसे ट्रैक और इंटरप्रेट (interpret) करता है। यह कुछ ग्लोबल कांस्टेंट्स (global constants) को भी परिभाषित करता है। जब हम Principal Value और Present Value पर चर्चा करेंगे, तो हम इस फ़ाइल में और अधिक गहराई से जाएंगे।

CometMainInterface.sol (बाएँ blue ellipse)

जैसा कि नाम से पता चलता है, CometMainInterface.sol केवल एक इंटरफ़ेस फ़ाइल है, बस इस विचित्रता (quirk) के साथ कि इसे एक एब्सट्रैक्ट कॉन्ट्रैक्ट (abstract contract) के रूप में परिभाषित किया गया है। चूंकि इंटरफ़ेस स्व-व्याख्यात्मक (self-explanatory) होते हैं, इसलिए हम इस पर चर्चा छोड़ देते हैं।

Comet.sol (green ellipse)

Comet.sol इस शो का मुख्य आकर्षण है। यह उपयोगकर्ताओं के लिए लेंड (lend), बॉरो (borrow), रिपे (repay) और लोन को लिक्विडेट (liquidate) करने के लिए सभी पब्लिक फेसिंग फंक्शन्स (public facing functions) प्रदान करता है।

CometExt, delegatecall के माध्यम से Comet का एक एक्सटेंशन (extension) है

24 KB की डिप्लॉयमेंट लिमिट से बचने के लिए, Comet fallback-extension pattern का उपयोग करके CometExt पर कई अतिरिक्त फंक्शन्स को ऑफलोड (offload) करता है। उदाहरण के लिए, name() फंक्शन Comet.sol में नहीं है और इस प्रकार इसे cannot be seen on Etherscan पर नहीं देखा जा सकता है।

हालाँकि, अगर हम उस फंक्शन को Foundry cast के माध्यम से कॉल करते हैं, तो हम देख सकते हैं कि कॉन्ट्रैक्ट ऐसे व्यवहार करता है जैसे वह मौजूद हो।

होता यह है कि फंक्शन कॉल फ़ॉलबैक फंक्शन (fallback function) से टकराती है और कॉल को CometExt को डेलिगेट (delegate) कर देती है, जिसमें name() नामक एक फंक्शन होता है।

यह महत्वपूर्ण है कि CometExt, Comet के स्टोरेज लेआउट (storage layout) का सम्मान करे और बिना क्लैश (clash) किए, इसे एक्सटेंड (extend) करे। यह CometExt द्वारा Comet के इनहेरिटेंस स्ट्रक्चर की नकल (mimic) कराकर प्राप्त किया जाता है।

याद रखें, इनहेरिटेंस केवल एक अर्थपूर्ण विवरण (semantic description) है — जब कॉन्ट्रैक्ट्स डिप्लॉय किए जाते हैं, तो पूरी इनहेरिटेंस चेन एक कॉन्ट्रैक्ट बन जाती है। किसी डिप्लॉय किए गए कॉन्ट्रैक्ट का दूसरे डिप्लॉय किए गए कॉन्ट्रैक्ट से इनहेरिट होना संभव नहीं है।

Comet और CometExt के बीच के संबंध को दर्शाने वाला एक अधिक विस्तृत (verbose) चित्र यहाँ दिखाया गया है।

रिवार्ड्स जारी करना (Rewards Issuance)

नॉन-इंटरेस्ट रिवार्ड (non-interest reward) जारी करने को संभालने के लिए केवल एक ही कॉन्ट्रैक्ट है जिसे pink box में दिखाया गया है।

इकोसिस्टम में भागीदारी के लिए लेंडर्स और बॉरोअर्स को COMP टोकन से पुरस्कृत किया जाता है। Comet कॉन्ट्रैक्ट भागीदारी पर नज़र रखता है, लेकिन यह रिवार्ड्स जारी करने का काम नहीं संभालता है। Reward कॉन्ट्रैक्ट Comet के स्टेट (state) को पढ़ता है और COMP टोकन जारी करता है। जिस दर पर रिवार्ड्स जारी किए जाते हैं, वे Reward कॉन्ट्रैक्ट के अंदर के पैरामीटर होते हैं जिन्हें गवर्नेंस द्वारा सेट किया जाता है।

पैरामीटर अपडेट का जीवनचक्र (Lifecycle)

जैसा कि पहले बताया गया है, Comet को इम्यूटेबल वेरिएबल्स द्वारा पैरामीटराइज़ (parameterize) किया जाता है। इन पैरामीटर्स को बदलने के लिए Configuration कॉन्ट्रैक्ट्स द्वारा डिप्लॉय किए गए एक नए इम्प्लीमेंटेशन की ओर पॉइंट करने के लिए प्रॉक्सी को अपडेट करने की आवश्यकता होती है।

व्यवहार में, इंटरेस्ट रेट कर्व्स (interest rate curves) को बदलना बहुत दुर्लभ है। मेननेट कॉन्ट्रैक्ट में अब तक केवल तीन बार इंटरेस्ट रेट कर्व अपडेट हुए हैं:

https://compound.finance/governance/proposals/162 (May 30, 2023)

https://compound.finance/governance/proposals/168 (July 17, 2023)

https://compound.finance/governance/proposals/201 (Dec 11, 2023)

इंटरेस्ट रेट्स ही एकमात्र पैरामीटर नहीं हैं जो बदल सकते हैं – अन्य उल्लेखनीय बातों में लिक्विडेशन रेशियो और यहां तक कि अनुमत कोलैटरल एसेट्स (permitted collateral assets) को बदलना भी शामिल है। जिज्ञासु पाठक गवर्नेंस प्रपोज़ल्स (governance proposals) का अवलोकन कर सकते हैं।

नीचे दिया गया GIF दिखाता है कि Configuration स्मार्ट कॉन्ट्रैक्ट कैसे स्ट्रक्चर किया गया है और गवर्नेंस अपडेटेड पैरामीटर्स के साथ नए Comet इंस्टेंस को कैसे डिप्लॉय करता है।

CometConfiguration.sol और ConfiguratorStorage.sol

CometConfiguration.sol उस स्ट्रक्ट (struct) को परिभाषित करता है जो Comet के पूरे व्यवहार को पैरामीटराइज़ करता है। CometStorage बस उन स्ट्रक्ट्स को स्टोर करता है।

यदि आपने How DeFi Interest Rates Work और DeFi Collateral and Liquidations पर हमारा लेख पढ़ा है, तो उम्मीद है कि स्ट्रक्ट में वेरिएबल नाम (variable names) ज्यादातर स्व-व्याख्यात्मक हैं। ConfiguratorStorage इन परिभाषाओं को इनहेरिट करता है और स्ट्रक्ट्स को मैपिंग्स (mappings) में स्टोर करता है।

ये स्टोरेज वेरिएबल्स Comet का हिस्सा नहीं हैं। Configurator कॉन्ट्रैक्ट इन स्टोर किए गए कॉन्फ़िगरेशन (configurations) का उपयोग करके Comet इंस्टेंस को डिप्लॉय करता है।

नीचे हम CometConfiguration और ConfiguratorStorage के लिए कोड का एक स्नैपशॉट (snapshot) दिखा रहे हैं।

कॉलडेटा (calldata) में एक बहुत बड़ा स्ट्रक्ट प्रदान करने की तुलना में यह नए Comet इंस्टेंस को डिप्लॉय करने का कहीं अधिक बेहतर तरीका है।

जब एक नया Comet इंस्टेंस किसी अपडेट के साथ डिप्लॉय किया जाता है, तो हमें अन्य को अपरिवर्तित (unchanged) छोड़ते हुए केवल एक विशेष स्टोरेज वेरिएबल को अपडेट करने की आवश्यकता होती है। उदाहरण के लिए, यदि हम कोलैटरल wBTC के लिए लिक्विडेशन थ्रेशोल्ड (liquidation threshold) बदलते हैं, तो configurator में केवल वही स्टोरेज वेरिएबल प्रभावित होगा।

Configurator.sol

Configurator.sol कॉन्ट्रैक्ट ConfigurationStorage को इनहेरिट करता है और केवल गवर्नेंस-ओनली (governance-only) सेटर फंक्शन्स (setter functions) प्रदान करता है। Configurator.sol file काफी बड़ी है, इसलिए हम पूरी फ़ाइल नहीं दिखा रहे हैं। हालाँकि, केवल इसमें परिभाषित इवेंट्स (events) को देखकर, हम इस बात का एक अच्छा विचार प्राप्त कर सकते हैं कि यह कॉन्ट्रैक्ट क्या करता है — स्ट्रक्ट में व्यक्तिगत फ़ील्ड्स (individual fields) को अपडेट करना जो नए Comet इंस्टेंस के डिप्लॉयमेंट को पैरामीटराइज़ करते हैं।

Configurator.sol नए Comet इंस्टेंस को डिप्लॉय करने के लिए deploy() फंक्शन भी रखता है।

ऊपर दिए गए कोड में CometFactory, CometFactory.sol में परिभाषित किया गया है और यह काफी छोटा है, इसलिए हम फ़ाइल को पूरी तरह से दिखाते हैं। फंक्शन “clone” थोड़ा भ्रामक (misleading) है क्योंकि यह proxy clones नहीं बनाता है – यह एक नया इंस्टेंस बनाता है।

हम अपनी पिछली सभी चर्चाओं को एक साथ जोड़ने के लिए पहले वाले ही एनिमेशन (animation) का संदर्भ लेते हैं।

पैरामीटर चेंज (Parameter Change) का वास्तविक उदाहरण

आइए एक उदाहरण के रूप में गवर्नेंस Proposal 162 का उपयोग करें। हम देखते हैं कि इसने पैरामीटर्स को अपडेट करने के लिए Configurator पर कुछ सेटर फंक्शन्स को कॉल किया, फिर अंतिम चरण (चरण 8) में एक नया Comet इंस्टेंस डिप्लॉय किया।

सब एक साथ (All Together)

नीचे हम सभी फ़ाइलों के बीच संबंध दिखाते हैं और वे एक-दूसरे के साथ कैसे इंटरैक्ट करती हैं। इंटरफ़ेस फ़ाइलों को अनदेखा (ignore) कर दिया गया है।

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

अधिक जानने के लिए कृपया हमारा blockchain bootcamp देखें।

मूल रूप से 3 जनवरी, 2024 को प्रकाशित