Compound V3 में bulker contracts, कई transactions को एक साथ बैच (batching) करने के लिए multicall-like contracts होते हैं।
उदाहरण के लिए, यदि हम Ether, LINK, और wBTC को collateral (संपार्श्विक) के रूप में supply करना चाहते हैं और एक ही transaction में इसके बदले USDC borrow करना चाहते हैं, तो हम ऐसा कर सकते हैं।
जैसा कि नीचे दिया गया स्क्रीनशॉट दर्शाता है, हम एक ही transaction में collateral होल्डिंग्स को कम कर सकते हैं और लोन निकाल सकते हैं। बेशक, इसके लिए यह मान लिया जाता है कि हम collateral factor की सीमाओं के भीतर रहें।
invoke()
bulker एक पारंपरिक multicall की तरह व्यवहार नहीं करता है जो arbitrary calldata की एक सूची स्वीकार करता है। इसके बजाय, यह दो arguments लेता है: actions की एक सूची (जिसमें 6 विकल्प होते हैं) और उन्हें supply किए जाने वाले arguments। यह function नीचे दिखाया गया है। विशेष रूप से, हम यह कर सकते हैं:
- एक ERC-20 supply करना (
ACTION_SUPPLY_ASSET) - ETH supply करना (
ACTION_SUPPLY_NATIVE_TOKEN) - किसी एसेट को ट्रांसफर करना (
ACTION_TRANSFER_ASSET), यह कैसे काम करता है यह जानने के लिए हमारा आर्टिकल Compound V3 behaves like a rebasing ERC-20 token देखें - एक ERC-20 withdraw करना (
ACTION_WITHDRAW_ASSET) - ETH withdraw करना (
ACTION_WITHDRAW_NATIVE_TOKEN) - जमा हुए COMP rewards को क्लेम करना। अंतर्निहित (underlying) function claimReward मुख्य लेंडिंग कॉन्ट्रैक्ट (Comet.sol) के बजाय reward contract के साथ इंटरैक्ट करेगा।
Invoke इन actions के माध्यम से लूप करेगा और दिए गए arguments के साथ Comet (या rewards contract) को कॉल करेगा।
हालाँकि इस कोड को मुख्य कॉन्ट्रैक्ट में रखना अधिक gas efficient हो सकता था, लेकिन लूप में msg.value का उपयोग करना सुरक्षित नहीं है, विशेष रूप से तब जब delegatecall को invoke किया जा रहा हो। इस आर्टिकल के अंत में दी गई अभ्यास समस्या (practice problem) देखें।
Compound यह सुनिश्चित करने में सावधानी बरतता है कि msg.value का फिर से उपयोग (re-used) करने के बजाय उसे काटा (deducted) जाए, क्योंकि फिर से उपयोग करने से double spending हो सकती है — पीले बॉक्स देखें।
विवादित रूप से, actions को 32-byte ASCII स्ट्रिंग इंडिकेटर के बजाय 1 byte इंडिकेटर के साथ तय करके इसे gas-optimized किया जा सकता था।
The bulkers are non-custodial
bulker कभी भी यूज़र के टोकन होल्ड नहीं करता है। इसके बजाय, यूज़र bulker को approval देता है और bulker यूज़र की ओर से Compound को एसेट्स supply करता है। Compound यह नहीं मानता कि msg.sender ही depositor है; ऐसा करना आमतौर पर एक अच्छा डिज़ाइन पैटर्न नहीं है क्योंकि यह composability को तोड़ता है — यह अन्य कॉन्ट्रैक्ट्स को यूज़र की ओर से काम करने से रोकता है।
Rescuing tokens
यदि यूज़र गलती से bulker को टोकन ट्रांसफर कर देते हैं, तो उस स्थिति में एक एडमिन टोकन को हटा (remove) सकता है। ध्यान दें कि हमारे पास फंसे हुए ETH और फंसे हुए ERC-20 टोकन को हटाने के लिए अलग-अलग functions हैं।
Handling non-standard ERC-20 tokens
ERC-20 टोकन स्पेसिफिकेशन से सबसे आम विचलनों (deviations) में से एक है बूलियन (boolean) वैल्यू को रिटर्न न करना। कई ERC-20 टोकन बूलियन रिटर्न नहीं करते हैं, बल्कि फेल होने की स्थिति में revert हो जाते हैं।
ERC-20 एसेट्स के साथ काम करते समय दोनों स्थितियों को संभालने के लिए, Compound नीचे दिए गए कोड को लागू (implement) करता है:
IERC20NonStandard की कोई रिटर्न वैल्यू नहीं है — यदि यह किसी non-standard ERC-20 टोकन के साथ डील कर रहा है तो यह revert हो जाएगा। इस संभावना को संभालने के लिए कि यह वास्तव में एक standard ERC-20 टोकन है, वह स्थिति जहाँ रिटर्न डेटा का आकार 32 बाइट्स है, यह दर्शाएगी कि टोकन ने एक वैल्यू रिटर्न की है। यदि रिटर्न की गई वैल्यू 1 है, तो यह सफल रहा (succeeded), अन्यथा यह विफल (failed) हो गया। विभिन्न परिदृश्यों (scenarios) को नीचे दिए गए मैट्रिक्स में कैप्चर किया गया है।
मूल रूप से, हम उन मामलों में सफल होते हैं जहां (टोकन revert नहीं होता AND कुछ भी रिटर्न नहीं करता) OR (टोकन revert नहीं होता AND true रिटर्न करता है)। हम उन मामलों में विफल होते हैं जहां (टोकन revert होता है) OR (टोकन revert नहीं होता AND false रिटर्न करता है)।
IERC20Nonstandard interface बस एक ऐसे ERC20 टोकन को परिभाषित (define) करता है जो कोई बूलियन रिटर्न नहीं करता है।
Practice problems
लूप के अंदर msg.value का उपयोग करने पर गंभीर समस्याएं हो सकती हैं। इन दो अभ्यास प्रश्नों (practice problems) को देखें:
Learn More with RareSkills
अधिक जानने के लिए कृपया हमारा web3 bootcamp देखें।
मूल रूप से 9 जनवरी, 2024 को प्रकाशित