दिसम्बर 16/2021
परिचय
RSI 1inch टीम ने हमसे उनकी समीक्षा और ऑडिट करने के लिए कहा सीमा आदेश प्रोटोकॉल v2 स्मार्ट अनुबंध। हमने कोड को देखा और अब अपने परिणाम प्रकाशित करते हैं।
विस्तार
हमने ऑडिट किया 4d94eea25e4dac6271bfd703096a5c4a4d899b4a
का 1inch/limit-order-protocol
भण्डार. दायरे में निम्नलिखित अनुबंध थे:
- OrderMixin.sol
- OrderRFQMixin.sol
- PredicateHelper.sol
- RevertReasonParser.sol
- Permitable.sol
- ChainlinkCalculator.sol
- ArgumentsDecoder.sol
- AmountCalculator.sol
- NonceManager.sol
- LimitOrderProtocol.sol
- ImmutableOwner.sol
- InteractiveNotificationReceiver.sol
- AggregatorInterface.sol
- IDaiLikePermit.sol
बाहरी निर्भरता और परियोजनाओं, गेम सिद्धांत और प्रोत्साहन डिजाइन के साथ-साथ अन्य सभी परियोजना फाइलों और निर्देशिकाओं (परीक्षणों सहित) को भी इस ऑडिट के दायरे से बाहर रखा गया था। बाहरी कोड और अनुबंध निर्भरता को दस्तावेज़ के रूप में काम करने के लिए माना गया था और 1 इंच द्वारा प्रदान की गई बैक-एंड सेवाओं को प्रोटोकॉल के सर्वोत्तम हित में कार्य करने के लिए माना गया था।
संपूर्ण स्वास्थ्य
सामान्य तौर पर, हमने प्रोजेक्ट के कोडबेस को पठनीय और सुव्यवस्थित पाया, हालांकि यह अधिक व्यापक दस्तावेज़ीकरण से लाभान्वित हो सकता है, विशेष रूप से असेंबली कोड के ब्लॉक, प्रोटोकॉल के किनारे के मामलों, संपत्तियों/विधेयकों/बाह्य-संसाधनों के आसपास जिनका उपयोग किया जाएगा। प्रदान की गई बैक-एंड सेवा की ज़िम्मेदारियाँ/सीमाएँ, और अभिनेताओं के बीच बातचीत। कार्यों को गैस-कुशल बनाने के लिए परियोजना काफी प्रयास करती है, कभी-कभी कोड के बारे में तर्क करना अधिक कठिन बनाने के जोखिम पर भी; हम नीचे उससे संबंधित मुद्दे उठाते हैं। पूरे ऑडिट के दौरान, 1इंच टीम अत्यधिक उपलब्ध, उत्तरदायी और काम करने में बहुत आसान थी।
सिस्टम सारांश
लिमिट ऑर्डर प्रोटोकॉल ऑर्डर को सक्षम बनाता है makers
टोकन स्वैप के लिए ऑफ-चेन ऑर्डर पर हस्ताक्षर करना। इसके बाद प्रोटोकॉल पहले से हस्ताक्षरित आदेशों को ऑर्डर द्वारा भरने की सुविधा प्रदान करता है takers
. ऑर्डर अत्यधिक विस्तार योग्य हैं, और ऑर्डर भरने की प्रक्रिया के दौरान कई बिंदुओं पर बाहरी अनुबंधों को स्थिर-कॉल कर सकते हैं। यह विस्तारशीलता प्रोटोकॉल को उपयोगिता से भर देती है, लेकिन यह ऑर्डर के लिए जटिलता और अधिक हमले की सतह दोनों जोड़ती है।
यह टिप्पणी करना महत्वपूर्ण है कि ऑर्डर विवरण का कोई ऑन-चेन भंडारण नहीं है। ऑर्डर की भरण-स्थिति या रद्दीकरण स्थिति को केवल ऑर्डर हैश के माध्यम से ट्रैक किया जाता है। इसके लिए आवश्यक है कि ऑर्डर को पीयर-टू-पीयर या एक केंद्रीकृत पार्टी के माध्यम से साझा किया जाए। इस मामले में, 1इंच टीम उस केंद्रीकृत पार्टी के रूप में कार्य करने का इरादा रखती है, जो हस्ताक्षरित आदेशों को एकत्र करती है और उन आदेशों को अपने अन्य प्रोटोकॉल के लिए तरलता के स्रोत के रूप में उपयोग करती है। ऑर्डर उनके स्वयं के एपीआई के माध्यम से प्रकाशित किए जाएंगे ताकि उपयोगकर्ता उनके साथ बातचीत कर सकें।
यह केंद्रीकरण 1 इंच टीम को अत्यधिक नियंत्रण देता है कि कौन से ऑर्डर प्रकाशित किए जाते हैं और अंततः निष्पादित किए जाते हैं। यह उन्हें आदेशों को सेंसर करने की क्षमता भी देता है, जो दुर्भावनापूर्ण या भ्रामक आदेशों के मामले में उपयोगी हो सकता है, लेकिन इसका दुरुपयोग भी किया जा सकता है और अनुकूल आदेश के मामले में उन्हें एपीआई के माध्यम से न दिखाकर किसी अन्य उपयोगकर्ता को आगे बढ़ाने की अनुमति देता है।
विशेषाधिकार युक्त भूमिकाएँ
हालाँकि जिन अनुबंधों में इस भूमिका का उपयोग किया गया है वे दायरे से बाहर थे, एक विशेषाधिकार प्राप्त भूमिका की पहचान की गई थी। एक immutableOwner
निर्माण के समय प्रॉक्सी अनुबंध के निर्माता पर सेट किया जाता है, और प्रॉक्सी तक पहुंच को सीमित करने के लिए इसका उपयोग किया जाता है external
कार्य करता है.
बाहरी निर्भरता और विश्वास धारणाएँ
इस प्रोटोकॉल के डिज़ाइन के लिए ऑफ-चेन और ऑन-चेन घटकों की आवश्यकता होती है, और इस हाइब्रिड मॉडल का उपयोग हमारी रिपोर्ट में पहचाने गए कुछ आक्रमण वैक्टरों को कम करने के लिए किया जा सकता है, लेकिन उस क्षमता की लागत 1 इंच टीम और बुनियादी ढांचे पर बढ़ती निर्भरता है।
इसके अतिरिक्त, लिमिट ऑर्डर प्रोटोकॉल ऐसे फ़ंक्शन प्रदान करता है जो चेनलिंक ऑरेकल से कीमतें पुनर्प्राप्त करने के लिए हैं। हमने उन दैवज्ञों को ईमानदार, सुलभ और ठीक से काम करने वाला माना।
इसके अलावा, किसी ऑर्डर के लचीलेपन के कारण, बाहरी अनुबंधों के साथ संपर्क के कई बिंदु होते हैं जो मान्य नहीं होते हैं। इसका मतलब यह है कि एक दुर्भावनापूर्ण उपयोगकर्ता ऐसी कॉलों का दुरुपयोग कर सकता है और ऑर्डर भरने के दौरान कार्यों को निष्पादित करने के लिए दुर्भावनापूर्ण अनुबंधों के साथ विधेय, संपत्ति या दैवज्ञ का प्रतिरूपण कर सकता है। हालाँकि परियोजना को कुछ क्षेत्रों में पुनर्प्रवेश के विरुद्ध संरक्षित किया गया है, ऐसे वैक्टर सेवा हमलों या अनिर्धारित स्पैम आदेशों से इनकार कर सकते हैं। 1इंच टीम को पता है कि प्रोटोकॉल के लिए अपरिचित अनुबंधों का उपयोग करते समय कुछ मुद्दे सामने आ सकते हैं और उन्होंने अपने इरादे का संकेत दिया है कि केवल प्रमुख "ब्लू चिप" संपत्तियां ही परियोजना द्वारा पूरी तरह से समर्थित होंगी। हालाँकि, यह ध्यान दिया जाना चाहिए कि सबसे लोकप्रिय परिसंपत्तियों के साथ भी प्रत्येक परिसंपत्ति से आंतरिक व्यवहार होते हैं जो प्रोटोकॉल पर समस्याएँ पैदा कर सकते हैं जो उन्हें ठीक से संबोधित नहीं करते हैं, जैसे यूएसडीटी के साथ स्थानांतरण के दौरान शुल्क लेना या इसके बजाय एक त्रुटि कोड लौटाना cTokens के साथ सफलता बूलियन।
निष्कर्ष
यहां हम अपने निष्कर्ष प्रस्तुत करते हैं।
गंभीर गंभीरता
कोई नहीं.
उच्च गंभीरता
[एच01] असंगत डेटा पारित किया गया _makeCall
में OrderMixin
अनुबंध, _makeCall
फ़ंक्शन का उपयोग संपत्तियों को स्थानांतरित करने के लिए किया जाता है लेने वाले से बनाने वाले तक और फिर बनाने वाले से लेने वाले तक. बाद वाले स्थानांतरण में, _makeCall
फ़ंक्शन गलत तरीके से ऑर्डर पारित किया गया है makerAsset
अंतिम पैरामीटर के रूप में, जब यह ऑर्डर का होना चाहिए makerAssetData
.
परिणामस्वरूप, कोई भी प्रॉक्सी कार्यक्षमता जो पर निर्भर करती है makerAssetData
तर्क टूट जाएगा.
पहले की कॉल के अनुरूप होना _makeCall
और प्रॉक्सी कार्यक्षमता का पूर्ण समर्थन करने के लिए, इसे अद्यतन करने पर विचार करें order.makerAsset
करने के लिए पैरामीटर order.makerAssetData
.
अपडेट: में तय किया पुल अनुरोध # 57.
[एच02] आंशिक रूप से भरे गए निजी ऑर्डर कोई भी भर सकता है
प्रोटोकॉल निजी और सार्वजनिक ऑर्डर बनाने की अनुमति देता है। निजी आदेशों पर, केवल allowedSender
ऑर्डर के निर्माण के दौरान निर्माता द्वारा निर्दिष्ट पता, ऑर्डर को भरने में सक्षम है।
हालाँकि, में OrderMixin
अनुबंध, के लिए सत्यापन allowedSender
पता गलत तरीके से दायर किया गया है, जिसका अर्थ है कि इसका मूल्यांकन केवल उस तर्क के अंदर किया जाता है जो किसी ऑर्डर की पहली पूर्ति को संभालता है। यदि कोई निजी ऑर्डर आंशिक रूप से भरा हुआ है, तो उसके लिए चेक allowedSender
पता अब पहुंच योग्य नहीं है और ऑर्डर किसी के भी भरने योग्य हो गया है।
इस आशय को स्पष्ट करने के लिए कि क्या किसी उपयोगकर्ता को आंशिक रूप से भरे गए निजी ऑर्डर भरने में सक्षम होना चाहिए या नहीं, वर्तमान व्यवहार के कारण का दस्तावेजीकरण करने या इसे मान्य करने पर विचार करें allowedSender
यह सुनिश्चित करने के लिए कि हर बार भरने का प्रयास करने पर इसे मान्य किया जाएगा, पहले भरण के दायरे से बाहर का पता।
अपडेट: में तय किया पुल अनुरोध # 58.
[एच03] दुर्भावनापूर्ण निर्माता खरीदार की संपत्ति चुराने के लिए आंशिक भरण का लाभ उठा सकता है
से आदेश OrderMixin
अनुबंध आंशिक रूप से भरने की क्षमता रखता है। आंशिक भरण का समर्थन करने के लिए, प्रोटोकॉल को स्वैप के दोनों पक्षों की गणना करने के तरीके की आवश्यकता होती है। दोनों getMakerAmount
और getTakerAmount
फ़ील्ड्स को ऑर्डर के निर्माता द्वारा इसी सटीक उद्देश्य के लिए परिभाषित किया गया है।
ऑर्डर भरते समय, लेने वालों को इनमें से कोई एक प्रदान करना होगा makingAmount
या takingAmount
मूल्यों के साथ-साथ ए thresholdAmount
कीमत। यदि के आधार पर दो अलग-अलग कोड-पथ लिए जा सकते हैं makingAmount
या takingAmount
मुहैया कराया गया था।
पहला है जब makingAmount
पैरामीटर परिभाषित किया गया है. यह हो सकता है काट-छांट la makingAmount
मूल्य और भी इसे परिकलित करें takingAmount
इसके लिए मूल्य. इस स्थिति में, thresholdAmount
यह सुनिश्चित करता है कि takingAmount
लिया गया मूल्य है अप्रत्याशित रूप से बड़ा नहीं.
दूसरा वह है जब takingAmount
पैरामीटर परिभाषित किया गया है. ऐसी स्थिति में, यह होगा इसे परिकलित करें makingAmount
मूल्य, की संभावना के साथ इसे छोटा करना और की पुनर्गणना कर रहा हूँ takingAmount
यदि ऐसा होता है तो मूल्य। इस स्थिति में, thresholdAmount
मूल्य यह सुनिश्चित करता है कि makingAmount
लौटाया गया मान है अप्रत्याशित रूप से छोटा नहीं.
दो शोषण विधियाँ मौजूद हैं, जिनमें से प्रत्येक पिछले उल्लिखित कोड-पथों में से एक के लिए अद्वितीय है। इन शोषण विधियों के लिए दुर्भावनापूर्ण आवश्यकता होती है getMakerAmount
और getTakerAmount
कार्य. इन कार्यों का एक सरल कार्यान्वयन एक समान व्यवहार होगा AmountCalculator
की getMakerAmount
और getTakerAmount
कार्य करता है, लेकिन एक हार्ड-कोडित स्विच के साथ जो उन्हें जरूरत पड़ने पर हमलावर नियंत्रित मूल्य वापस करने के लिए मजबूर करेगा।
पहले, कम गंभीर शोषण पैटर्न में पहला कोड-पथ शामिल होता है makingAmount
मान निर्दिष्ट है एक भरण क्रम में. एक दुर्भावनापूर्ण निर्माता एक भरण आदेश की प्रतीक्षा करेगा जो निर्दिष्ट करता है makingAmount
इसे आगे बढ़ाने के लिए मेमपूल में दिखाना। वे निर्माता की ओर से 1 को छोड़कर बाकी सभी मूल्य निकाल लेंगे और फिर जबरदस्ती करेंगे _callGetTakerAmount
उपयोगकर्ता में निर्दिष्ट राशि वापस करने के लिए thresholdAmount
मूल्य (या यदि यह कम है तो उनका भत्ता)। जब उपयोगकर्ता का लेन-देन अंततः पूरा हो जाएगा, तो वे अपना पूरा लेनदेन स्वैप कर देंगे thresholdAmount
मूल्य का takerAsset
की एक इकाई के लिए makerAsset
. यह शोषण द्वारा दी गई राशि तक ही सीमित है thresholdAmount
का मूल्य या राशि takerAsset
उपयोगकर्ता ने इस पर अनुमति दी LimitOrderProtocol
अनुबंध।
दूसरे, अधिक गंभीर शोषण पैटर्न में दूसरा कोड-पथ शामिल है जहां takingAmount
मान निर्दिष्ट है. दुर्भावनापूर्ण निर्माता इसी तरह एक भरण आदेश की प्रतीक्षा करेगा जिसमें निर्दिष्ट किया गया हो takingAmount
मेमपूल में दिखाने के लिए मूल्य। वे लेन-देन में आगे रहेंगे और दबाव डालेंगे makingAmount
द्वारा लौटाया गया मान _callGetMakerAmount
दोनों से अधिक होने का कार्य remainingMakerAmount
और thresholdAmount
. वे भी सेट करेंगे takingAmount
द्वारा मूल्य लौटाया गया _callGetTakerAmount
की राशि होना takerAsset
पर संपत्ति की अनुमति है LimitOrderProtocol
लेने वाले द्वारा. जब लेने वाले का लेन-देन हो जाएगा, तो हो जाएगा को छोटा करें makingAmount
मूल्य और फिर पुनर्गणना करें takingAmount
कीमत। हालाँकि, इस पुनर्गणना के कम होने की गारंटी नहीं है, और इस मामले में लेने वाले का सारा पैसा ख़त्म हो जाएगा takerAsset
जिसकी उन्होंने अनुबंध पर अनुमति दी थी। इस कोड-पथ में, thresholdAmount
मूल्य है यह सुनिश्चित करना makingAmount
बहुत कम नहीं है, इसलिए सभी लेने वाले ले रहे हैं takerAsset
संपत्ति अनियंत्रित है. खोई गई धनराशि की राशि से सीमित होती है takerAsset
उपयोगकर्ता द्वारा अनुमत संपत्ति LimitOrderProtocol
अनुबंध।
ये कारनामे आंशिक आदेशों के बिना संभव नहीं हैं, और अधिक विशेष रूप से, दुर्भावनापूर्ण आंशिक आदेशों के बिना संभव नहीं हैं getMakerAmount
और getTakerAmount
कार्यान्वयन।
का मुख्य मुद्दा thresholdAmount
मूल्य जांच यह है कि यह स्वैप के केवल एक तरफ को कवर करता है, लेकिन दूसरे पक्ष को फ्रंटरनिंग के माध्यम से हेरफेर किया जा सकता है। इस बात का कोई आश्वासन नहीं है कि लेने वाले द्वारा मूल रूप से प्रस्तावित मूल्य अपरिवर्तित रहेगा। हटाने पर विचार करें makingAmount
यदि ऑर्डर अनुरोध के अनुसार बड़े पैमाने पर भरण का समर्थन नहीं कर सकता है तो दोनों कोड-पथों से काट-छाँट करना और पूर्ववत करना। ऐसा करने से thresholdAmount
इसका उपयोग स्वैप के दूसरे पक्ष को पर्याप्त रूप से प्रतिबंधित करने और अप्रत्याशित व्यवहार से बचने के लिए किया जा सकता है, यहां तक कि दुर्भावनापूर्ण आदेशों में भी।
अपडेट: में तय किया पुल अनुरोध # 83.
मध्यम गंभीरता
[एम01] गतिशील तर्कों के बाद स्थैतिक तर्क पारित हुए
में OrderMixin
अनुबंध, getTakerAmount
और getMakerAmount
बाइट्स फ़ील्ड का उपयोग तर्क के रूप में किया जाता है _callGetTakerAmount
और _callGetMakerAmount
कार्य. ये कॉल स्वैप के एक पक्ष के आधार पर दूसरे पक्ष की गणना करने का एक तरीका प्रदान करते हैं, और वे उपयोगकर्ताओं को आंशिक रूप से ऑर्डर भरने की अनुमति देते हैं।
RSI getTakerAmount
/getMakerAmount
फ़ील्ड गतिशील चर हैं और के सामने पैक किए गए हैं takerAmount
और makerAmount
में मान _callGetTakerAmount
और _callGetMakerAmount
कार्य. किसी दुर्भावनापूर्ण निर्माता के लिए अपेक्षा से अधिक डेटा प्रदान करना संभव है getTakerAmount
औरgetMakerAmount
धकेलने के लिए फ़ील्ड takerAmount
और makerAmount
अगले फ़ंक्शन में डिकोड किए जाने पर बाइट्स को वहीं माना जाता है जहां वे मौजूद हैं। यह निर्माता को पास किए गए टेकर या मेकर राशि को पूर्ण बाइट्स द्वारा दाईं ओर स्थानांतरित करने की अनुमति देता है और यदि अतिरिक्त 32 बाइट्स डेटा प्रदान किया जाता है तो उन्हें पूरी तरह से बदल भी देता है।
उपयोगकर्ताओं को पहले से ही मैन्युअल रूप से समीक्षा करनी होगी getTakerAmount
और getMakerAmount
क्रम में फ़ील्ड, लेकिन इस तकनीक को पहचानना कठिन है। यह भी ध्यान देने योग्य है कि यह हमला आंतरिक रूप से भरोसेमंद लोगों पर भी लागू होता है getMakerAmount
और getTakerAmount
कार्य. अधिकांश हमलों के लिए, उचित सीमा राशि प्रदान करने से धन की हानि को रोका जा सकेगा।
इसे रोकने के लिए, गतिशील तर्कों को स्थिर तर्कों को नियंत्रित करने की विधि देने से बचने के लिए गतिशील तर्कों से पहले स्थिर तर्कों को एन्कोड करने पर विचार करें।
अपडेट: पक्का नहीं है। 1इंच टीम ने कहा:
हम गेटर्स सत्यापन के संबंध में अतिरिक्त सावधानी बरतेंगे। हम अपने एसडीके में गेटर्स के विवेक सत्यापन को लागू करने का प्रयास करेंगे जो संभावित दुर्भावनापूर्ण आदेशों को फ़िल्टर करने में मदद करेगा।
[एम02] ईआरसी721 आदेशों में हेरफेर किया जा सकता है
इसके माध्यम से केवल ERC20 से अधिक का आदान-प्रदान संभव है OrderMixin
एक अनुबंध तैनात करके जो IERC20 के समान फ़ंक्शन चयनकर्ता को साझा करता है transferFrom
, और उस अनुबंध को प्रदान करना makerAsset
या takerAsset
एक क्रम में.
दायरे से बाहर प्रॉक्सी, अर्थात्, ERC721Proxy
, ERC721ProxySafe
, तथा ERC1155Proxy
समर्थन प्रदान करने के लिए अनुबंध इस पैटर्न का पालन करते हैं ERC721
और ERC1155
टोकन. चूँकि प्रॉक्सी को IERC20 के समान पैटर्न के साथ बुलाया जाना चाहिए transferFrom
कॉल करें, हस्ताक्षर की शुरुआत इससे होनी चाहिए address from
, address to
और uint256 amount
. प्रॉक्सी के लिए आवश्यक किसी भी अन्य चीज़ को बाद में पारित किया जा सकता है, और इसे क्रम में परिभाषित किया गया है makerAssetData
और takerAssetData
.
ERC1155 स्वाभाविक रूप से एक ही बार में एक ही आईडी टोकन के कई स्थानांतरित कर सकते हैं, जिसका अर्थ है ERC1155Proxy
अनुबंध का उपयोग करता है amount
मैदान। वहीं दूसरी ओर, ERC721
का कोई स्पष्ट उपयोग नहीं है amount
मैदान। चूँकि वे अपूरणीय टोकन का प्रतिनिधित्व करते हैं, एक विशिष्ट टोकनआईडी में केवल एक ही अस्तित्व में होगा, जो इसे प्रस्तुत करता है amount
क्षेत्र बेकार. इस वजह से, दोनों के लिए कार्यान्वयन ERC721Proxy
और ERC721ProxySafe
अनुबंध आवश्यक का उपयोग करते हैं amount
फ़ील्ड के रूप में tokenId
बजाय.
इस ओवरलोडिंग के amount
पैरामीटर आंशिक रूप से भरने की संभावना बनाता है ERC721
रियायती कीमतों पर अलग से सूचीबद्ध टोकन खरीदने के आदेश। उदाहरण के लिए, ऐसा मामला हो सकता है जहां एक ही उपयोगकर्ता के पास एकाधिक उपयोगकर्ता हों ERC721
द्वारा उसी अनुबंध को हस्तांतरित करने की अनुमति दी गई है ERC721Proxy
अनुबंध करें और उन्हें अलग-अलग सीमा आदेशों में सूचीबद्ध करें।
यदि सीमा आदेश भी प्रदान करते हैं getMakerAmount
और getTakerAmount
फ़ील्ड, इन्हें आंशिक रूप से भरना संभव होगा ERC721
आदेश. जब से आदेश हुआ है amount
फ़ील्ड वास्तव में से मेल खाती है tokenId
, एक दुर्भावनापूर्ण उपयोगकर्ता आंशिक भरण डाल सकता है ERC721
उच्चतर टोकनआईडी के साथ, जिसके परिणामस्वरूप a makingAmount
/takingAmount
एक की ERC721
यह निम्न के अनुरूप हो सकता है tokenId
. नतीजा यह है ERC721
निचले के साथ tokenId
की कीमत पर हस्तांतरित किया जाएगा (higher tokenId price) * (lower tokenId's id) / (higher tokenId's id)
.
इस शोषण की कुछ आवश्यकताएँ हैं:
- विभिन्न
ERC721
एक ही अनुबंध से दोनों में से किसी एक को अनुमति दी जाएगीERC721
एकल स्वामी द्वारा प्रॉक्सी. - इनमें से किसी एक के लिए खुला आदेश
ERC721
यह निम्नतम नहीं हैtokenId
जिनकी अनुमति है. - ऑर्डर पर आंशिक भरने की अनुमति है।
आंशिक की सम्भावना को पूर्णतया दूर करना ERC721
भरता है, अलग करने पर विचार करें amount
और tokenId
तर्क. चाहे तर्क अलग-अलग हों या नहीं, उपयोगकर्ताओं को इस व्यवहार के प्रति सचेत करने और भविष्य में इस पैटर्न से बचने के लिए इसे प्रलेखित करने पर भी विचार करें।
अपडेट: में तय किया पुल अनुरोध # 59.
[एम03] अप्रलेखित दशमलव धारणाएँ
RSI LimitOrderProtocol
अनुबंध विरासत में मिला है ChainlinkCalculator
के माध्यम से अनुबंध करें OrderMixin
अनुबंध। यह अनुबंध चेनलिंक ओरेकल के उपयोग को सक्षम करने के लिए दो कार्यों को उजागर करता है जाँच की भविष्यवाणी करता है और का लुकअप निर्माता राशि/लेने वाली राशि.
हालाँकि, अनुबंध उन दशमलवों की संख्या के बारे में अनिर्दिष्ट धारणाएँ बनाता है जिनमें चैनलिंक ओरेकल को रिपोर्ट करना चाहिए, साथ ही फ़ंक्शन पैरामीटर में दशमलवों की संख्या भी होनी चाहिए। कुछ परिदृश्यों में, इससे अप्रत्याशित व्यवहार हो सकता है, जिसमें परिसंपत्तियों का गलत मूल्य निर्धारण और धन की अनजाने में हानि शामिल है।
अधिक विशेष रूप से, पूरे अनुबंध में अंतर्निहित धारणा यह है कि चैनलिंक ओरेकल 18 दशमलव परिशुद्धता के साथ रिपोर्ट करेगा। हालाँकि, नहीं सभी चैनलिंक ओरेकल दशमलव की इस संख्या के साथ रिपोर्ट करें. वास्तव में, यदि ओरेकल एक टोकन जोड़ी की रिपोर्ट करता है जो मुद्रा (उदाहरण के लिए यूएसडी) के संदर्भ में है, तो इसमें केवल 8 दशमलव परिशुद्धता होगी। चूंकि इस पर कोई प्रतिबंध नहीं है कौन कौन से दैवज्ञों का उपयोग किया जा सकता है, वे कितने दशमलवों के साथ रिपोर्ट करेंगे, इसके बारे में अंतर्निहित धारणाएँ नहीं बनाई जानी चाहिए।
संबंधित रूप से, एक अंतर्निहित धारणा है कि amount
के लिए पैरामीटर ChainlinkCalculator
फ़ंक्शंस 18 दशमलव का उपयोग करेंगे, साथ ही भ्रामक स्पष्ट घोषणा भी करेंगे singlePrice
समारोह Calculates price of token relative to ETH scaled by 1e18
. हकीकत में, यहां तक कि एक दैवज्ञ के साथ भी कर देता है 18 दशमलव के साथ रिपोर्ट, का रिटर्न मान singlePrice
फ़ंक्शन को दशमलव की संख्या से स्केल किया जाएगा amount
पैरामीटर, जो जरूरी नहीं कि 18 दशमलव हो।
इसी तरह, doublePrice
फ़ंक्शन मानता है कि दो चैनलिंक ओरेकल समान संख्या में दशमलव के साथ रिपोर्ट करेंगे, जिससे फ़ंक्शन का परिणाम अपेक्षाओं से भटक जाएगा।
दशमलव की संख्या के संबंध में स्पष्ट रूप से दस्तावेजीकरण करने पर विचार करें जिसके अनुसार पैरामीटर और रिटर्न मान होने चाहिए। इसके अलावा, या तो उन गणनाओं को सीमित करने पर विचार करें जो उन धारणाओं को तोड़ने वाले दैवज्ञों पर निर्भर करती हैं, या प्रासंगिक गणना करने से दशमलव की वास्तविक संख्या को ध्यान में रखा जाता है।
अपडेट: में तय किया पुल अनुरोध # 75.
कम गंभीरता
[एल01] स्थिरांक स्पष्ट रूप से घोषित नहीं किए गए
कोडबेस में अस्पष्ट अर्थ के साथ शाब्दिक मूल्यों का उपयोग किए जाने की कुछ घटनाएं हुई हैं। उदाहरण के लिए:
- में
OrderMixin
अनुबंध,_remaining
मैपिंग शब्दार्थ की दृष्टि से अतिभारित है (जैसा कि अंक में बताया गया है)। मैपिंग का सिमेंटिक ओवरलोडिंग) आंशिक रूप से भरे गए ऑर्डर के लिए शेष संपत्ति की मात्रा को ट्रैक करने के लिए और यदि कोई ऑर्डर पूरी तरह से भर दिया गया है। विशेष रूप से,0
इसका मतलब है कि ऑर्डर से संबंधित कोई भी पूर्ति नहीं की गई है,1
इसका मतलब है कि एक ऑर्डर अब नहीं भरा जा सकता है, और इससे बड़ा कुछ भी नहीं1
इसका मतलब है कि ऑर्डर से जुड़ी एक शेष राशि है जिसे संभावित रूप से भरा जा सकता है। - में
ChainlinkCalculator
अनुबंध, शाब्दिक मूल्य1e18
में प्रयोग किया जाता हैsinglePrice
समारोह.
कोड की पठनीयता में सुधार करने और रीफैक्टरिंग की सुविधा के लिए, प्रत्येक जादुई संख्या के लिए एक स्थिरांक को परिभाषित करने पर विचार करें, इसे एक स्पष्ट और आत्म-व्याख्यात्मक नाम दें। जटिल मूल्यों के लिए, एक इनलाइन टिप्पणी जोड़ने पर विचार करें जिसमें बताया गया हो कि उनकी गणना कैसे की गई या उन्हें क्यों चुना गया।
अपडेट: में तय किया पुल अनुरोध # 75 और पुल अनुरोध # 76.
[एल02] दुर्भावनापूर्ण पक्ष स्वीकार्य आदेशों के निष्पादन को रोक सकते हैं
RSI OrderMixin
अनुबंध निर्माता उपयोगकर्ताओं को सबमिट करने की अनुमति देता है स्वीकार्य आदेश इसलिए इन्हें अनुमोदन के लिए अलग लेनदेन करने के बजाय एक ही लेनदेन में निष्पादित किया जा सकता है। इसके अलावा, ऑर्डर लेने वाले भी कर सकते हैं अपना स्वयं का परमिट जमा करें उसी उद्देश्य के लिए ऑर्डर भरने के दौरान।
हालाँकि, क्योंकि निर्माता का परमिट अंदर निहित है आदेश, ऑर्डर-भरण लेनदेन मेमपूल में होने पर निर्माता और लेने वाले दोनों के परमिट पहुंच योग्य होंगे। इससे किसी भी दुर्भावनापूर्ण उपयोगकर्ता के लिए उन परमिटों को लेना और भरण लेनदेन को आगे बढ़ाते समय उन्हें संबंधित परिसंपत्ति अनुबंधों पर निष्पादित करना संभव हो जाएगा। क्योंकि इन परमिटों में एक nonce
दोहरे खर्च के हमले को रोकने के लिए, ऑर्डर का भरण लेनदेन उसी परमिट का उपयोग करने की कोशिश के परिणामस्वरूप विफल हो जाएगा जो अभी फ्रंटरन के दौरान उपयोग किया गया था।
यद्यपि कोई सुरक्षा जोखिम नहीं है, और निर्माता एक नया ऑर्डर बना सकता है और लेनदेन को पूर्व-अनुमोदन दे सकता है, यह हमला निश्चित रूप से स्वीकार्य ऑर्डर की उपयोगिता को प्रभावित कर सकता है। दरअसल, एक प्रेरित हमलावर अवरोध पैदा कर सकता है सब इस हमले के साथ स्वीकार्य आदेश. यदि परमिट पहले ही जमा किया जा चुका है, या यदि भत्ता पर्याप्त है, तो ऑर्डर भरने के दौरान इसे मान्य करने पर विचार करें। ऑर्डर संरचना के दौरान उपयोगकर्ताओं को इस संभावित हमले के बारे में बताने पर भी विचार करें।
अपडेट: पक्का नहीं है। 1इंच टीम बताती है:
हमने पहले अनुमोदन जांच की थी लेकिन असफल अनुमोदनों पर वापस लौटने के लिए परमिट प्रवाह को सरल बनाने का निर्णय लिया। हम इस मुद्दे के बारे में निर्माताओं को सूचित करने के तरीकों के बारे में सोचेंगे।
[एल03] डुप्लिकेट कोड
कोडबेस के भीतर डुप्लिकेट कोड के उदाहरण हैं। कोड की नकल बनाने से विकास जीवनचक्र में बाद में समस्याएँ पैदा हो सकती हैं और परियोजना में त्रुटियाँ आने की संभावना अधिक हो जाती है। ऐसी त्रुटियाँ अनजाने में तब उत्पन्न हो सकती हैं जब कार्यक्षमता परिवर्तन कोड के सभी उदाहरणों में दोहराए नहीं जाते हैं जो समान होने चाहिए। डुप्लिकेट कोड के उदाहरणों में शामिल हैं:
कोड को डुप्लिकेट करने के बजाय, डुप्लिकेट कोड वाले केवल एक अनुबंध या लाइब्रेरी पर विचार करें और जब भी डुप्लिकेट कार्यक्षमता की आवश्यकता हो तो इसका उपयोग करें।
अपडेट: में आंशिक रूप से तय किया गया पुल अनुरोध # 60.
[एल04] त्रुटिपूर्ण या भ्रामक परीक्षण सूट
परीक्षण सुइट में ऐसे उदाहरण हैं जहां परीक्षण अपने अपेक्षित व्यवहार से विचलित हो जाते हैं। उदाहरण के लिए:
- RSI
ChainlinkCalculator
अनुबंध विरासत में मिला हैOrderMixin
अनुबंध। हालाँकि, परीक्षणों के दौरानAmountCalculator.arbitraryStaticCall
फ़ंक्शन का उपयोग कॉल करने के लिए किया जाता हैChainlinkCalculator
एक बाहरी, स्वतंत्र अनुबंध के रूप में अनुबंध। भले ही परिणाम अपेक्षित हो, परीक्षण को सिस्टम के वर्तमान डिज़ाइन और कॉल द्वारा प्रत्याशित उपयोग के मामले के साथ व्यवहार को प्रतिबिंबित करना चाहिएChainlinkCalculator
मनमाना स्थैतिक कॉल का उपयोग किए बिना सीधे कार्य करता है। - हालाँकि प्रॉक्सी अनुबंध दायरे से बाहर थे, हमने देखा कि ERC721 परिसंपत्तियों के साथ प्रोटोकॉल का परीक्षण करते समय,
ERC721Proxy
अनुबंध का उपयोग इसमें परिसंपत्तियों की अदला-बदली के लिए नहीं किया जाता है परीक्षण सूट.
चूंकि परीक्षण सूट स्वयं इस ऑडिट के दायरे से बाहर है, कृपया यह सुनिश्चित करने के लिए परीक्षण सूट की पूरी तरह से समीक्षा करने पर विचार करें कि सभी परीक्षण प्रोटोकॉल के विनिर्देशों के अनुसार सफलतापूर्वक चलते हैं।
अपडेट: में तय किया पुल अनुरोध # 57, पुल अनुरोध # 59, तथा पुल अनुरोध # 61.
[एल05] घटनाओं में त्रुटियां और चूक
पूरे कोडबेस में, जब अनुबंधों में संवेदनशील परिवर्तन किए जाते हैं तो घटनाएं आम तौर पर उत्सर्जित होती हैं। हालाँकि, कई घटनाओं में अनुक्रमित मापदंडों का अभाव है और/या महत्वपूर्ण पैरामीटर गायब हैं। उदाहरण के लिए:
ऐसी संवेदनशील कार्रवाइयां भी हैं जिनमें घटनाओं का अभाव है, जैसे:
मौजूदा घटनाओं को पूरी तरह से अनुक्रमित करने और जहां उनकी कमी है वहां नए पैरामीटर जोड़ने पर विचार करें। इसके अलावा, सभी घटनाओं को इस तरह से पूर्ण तरीके से उत्सर्जित करने पर विचार करें कि उनका उपयोग ऑफ-चेन सेवाओं द्वारा अनुबंध की स्थिति के पुनर्निर्माण के लिए किया जा सके।
अपडेट: पक्का नहीं है। हालाँकि, 1इंच टीम ने एक जोड़ा orderRemaining
के लिए पैरामीटर OrderCanceled
में घटना पुल अनुरोध # 62.
1इंच टीम बताती है:
हमने पाया कि फ्रंटएंड जरूरतों को पूरा करने के लिए डेटा के केवल एक सीमित उपसमूह की आवश्यकता होती है। व्यापक विश्लेषण के मामले में, सभी सुझाए गए फ़ील्ड ट्रेसिंग के माध्यम से उपलब्ध हैं। के लिए
OrderRFQMixin
हम उम्मीद करते हैं कि बाज़ार निर्माता रद्द किए गए ऑर्डरों पर नज़र रखने के लिए अपना स्वयं का परिष्कृत तरीका तैयार करेंगे।
[एल06] घटना उत्सर्जन के दौरान भंडारण में परिवर्तन होता है
में NonceManager
अनुबंध, जब NonceIncreased
घटना उत्सर्जित होती है, संदेश भेजने वाले की नॉनसेंस भी बढ़ जाती है.
एक साथ कई ऑपरेशन निष्पादित करने से कोडबेस के बारे में तर्क करना कठिन हो सकता है, त्रुटियों की संभावना अधिक हो सकती है, और ऑपरेशन को अनदेखा किया जा सकता है या गलत समझा जा सकता है।
कोड की समग्र मंशा, पठनीयता और स्पष्टता में सुधार करने के लिए, ईवेंट जारी करने से पहले नॉन वैल्यू बढ़ाने पर विचार करें।
अपडेट: में तय किया पुल अनुरोध # 63.
[एल07] असंगत डिकोडिंग पद्धतियां परिणाम विसंगतियों का कारण बन सकती हैं
इसकी सभी विस्तारशीलता और लचीलेपन का समर्थन करने के लिए, लिमिट ऑर्डर प्रोटोकॉल को नियमित रूप से गतिशील बाइट्स डेटा और बाहरी अनुबंधों से मनमाने रिटर्न मानों से निपटना पड़ता है। परिणामस्वरूप, प्रोटोकॉल में एक शामिल है ArgumentsDecoder
गतिशील बाइट्स मानों को बुनियादी डेटा प्रकारों में अधिक कुशलता से परिवर्तित करने के लिए लाइब्रेरी। हालाँकि, इस लाइब्रेरी का उपयोग विशेष रूप से और कुछ मामलों में नहीं किया जाता है abi.decode
इसके स्थान पर प्रयोग किया जाता है। इसके अतिरिक्त, कुछ अनुबंध उपयोग कर रहे हैं abi coder v1
जबकि अन्य उपयोग कर रहे हैं abi coder v2
. पूर्व वाला अधिक समान प्रदर्शन करता है ArgumentsDecoder
लाइब्रेरी, जबकि बाद वाला डिकोडिंग करते समय अतिरिक्त जांच करता है।
इन विभिन्न डिकोडिंग पद्धतियों के असंगत उपयोग के परिणामस्वरूप कोडबेस के इरादे और वास्तविक व्यवहार के बीच सूक्ष्म विसंगतियां हो सकती हैं।
उदाहरण के लिए, simulateCalls
फ़ंक्शन केवल इसका उपयोग करता है ArgumentsDecoder.decodeBool
समारोह। अगर द simulateCalls
फ़ंक्शन का उपयोग उन कॉलों की जांच करने के लिए किया जाता है जो किसी ऑर्डर के विधेय भाग में की जाएंगी, तो इसके परिणाम विधेय स्थितियों के मूल्यांकन के दौरान वास्तव में जो होता है उससे भिन्न हो सकते हैं, क्योंकि विभिन्न डिकोडिंग पद्धतियों को नियोजित किया जाता है।
इसलिए, उदाहरण के लिए, यदि कोई विधेय बाहरी बनाता है staticcall
किसी ऐसे फ़ंक्शन के लिए जो a लौटाता है uint256
मान अपेक्षा के बजाय एक से अधिक है bool
, तो वह कॉल वापस आ जाएगी, क्योंकि रिटर्न वैल्यू है के साथ डिकोड किया गया abi coder v2
की abi.decode
जो ऐसे मूल्यों को स्वीकार नहीं करेगा bool
. हालाँकि, यदि ठीक वैसी ही कॉल की जाती है simulateCalls
, तो यह बस के रूप में चिह्नित किया जाएगा true
, क्योंकि decodeBool
शून्य से बड़े किसी भी मान को शून्य मानता है true
.
बनाने के simulateCalls
फ़ंक्शन पूरी तरह से वास्तविक विधेय कॉल के व्यवहार को प्रतिबिंबित करता है, इसे उपयोग करने के लिए संशोधित करने पर विचार करें abi.decode
.
अपडेट: में तय किया पुल अनुरोध # 82.
[एल08] इनपुट सत्यापन का अभाव
RSI fillOrderToWithPermit
और fillOrderTo
के कार्य OrderMixin
अनुबंध, साथ ही साथ fillOrderRFQToWithPermit
और fillOrderRFQTo
के कार्य OrderRFQMixin
अनुबंध, मान्य न करें target
पता पैरामीटर.
इससे उपयोगकर्ता के लिए अनजाने में शून्य पता दर्ज करना संभव हो जाता है और परिणामस्वरूप, ऑर्डर भरने के बाद प्राप्त होने वाली संपत्तियों को लॉक कर दिया जाता है।
यह सुनिश्चित करने के लिए कि उपयोगकर्ता गलती से अपने फंड को लॉक न कर दें, इसे मान्य करने पर विचार करें target
उद्धृत फ़ंक्शन में पता शून्य पते के बराबर नहीं है।
अपडेट: में तय किया पुल अनुरोध # 78.
[एल09] कम यूनिट परीक्षण कवरेज
संपूर्ण परियोजना के लिए यूनिट परीक्षण कवरेज लगभग 75% है, कुछ अनुबंधों में विशेष रूप से कम कवरेज है।
कोड को मान्य करने और नए फीचर्स को विकसित करने और रीफैक्टरिंग करते समय रिग्रेशन को रोकने के लिए यूनिट परीक्षणों के महत्व को ध्यान में रखते हुए, हम यूनिट टेस्ट कवरेज को कम से कम 95% तक बढ़ाने के लिए प्रोत्साहित करते हैं, और ऐसे किनारे के मामलों को भी शामिल करते हैं जो असंभावित स्थितियों को भी कवर करते हैं।
अपडेट: निश्चित नहीं।
[L10] भ्रामक या अपूर्ण इनलाइन दस्तावेज़ीकरण
पूरे कोडबेस में, भ्रामक और/या अपूर्ण इनलाइन दस्तावेज़ीकरण के कुछ उदाहरणों की पहचान की गई और उन्हें ठीक किया जाना चाहिए।
भ्रामक इनलाइन दस्तावेज़ीकरण के उदाहरण निम्नलिखित हैं:
- में
ChainlinkCalculator
अनुबंध,singlePrice
समारोह के नैटस्पेक@notice
टैग कहते हैं कि यहCalculates price of token relative to ETH scaled by 1e18
, लेकिन वास्तव में, इसका परिणाम है मूल्य ofamount
टोकन द्वारा स्केल किया गया1e18
, जहां ओरेकल ईटीएच के संदर्भ में रिपोर्ट नहीं कर सकता है (उदाहरण के लिए ईटीएच को शामिल नहीं करने वाली जोड़ी के लिए)। - में
OrderRFQMixin
अनुबंध,invalidatorForOrderRFQ
समारोह के नैटस्पेक@return
टैग भ्रामक है, क्योंकि हो सकता है कि संबंधित अमान्यकर्ता बिट को सेट करने के लिए उद्धरण नहीं भरा गया हो। ऑर्डर कैंसिल भी हो सकता है. - पंक्तियों पर 147, 165, तथा 188 of
OrderMixin.sol
, नैटस्पेक@param
टैग अव्याकरणिक हैं. - लाइन पर 20 of
ERC1155Proxy.sol
,@notice
टैग बताता है कि गणना किया गया हैश हैशिंग का परिणाम हैfunc_733NCGU
फ़ंक्शन, जहां यह होना चाहिएfunc_301JL5R
इसके बजाय कार्य करें।
अपूर्ण इनलाइन दस्तावेज़ीकरण के उदाहरण निम्नलिखित हैं:
- में कार्य
AmountCalculator
अनुबंध किसी भी पैरामीटर का वर्णन नहीं करता है। - में
ChainlinkCalculator
अनुबंध,singlePrice
औरdoublePrice
फ़ंक्शन सभी पैरामीटरों का वर्णन नहीं करते हैं. - में
ImmutableOwner
अनुबंध, सार्वजनिक चर और संशोधक के पास कोई नेटस्पेक नहीं है। - में
InteractiveNotificationReceiver
अनुबंध,notifyFillOrder
फ़ंक्शन किसी भी पैरामीटर का वर्णन नहीं करता है। - में
LimitOrderProtocol
अनुबंध,DOMAIN_SEPARATOR
फ़ंक्शन में कोई नेटस्पेक नहीं है। - में घटनाएँ और मानचित्रण
NonceManager
कोई नेटस्पेक नहीं है। - में
OrderRFQMixin
अनुबंध,cancelOrderRFQ*
फ़ंक्शंस रिटर्न मानों का वर्णन नहीं करते हैं। - में
OrderMixin
अनुबंध, कई कार्यों में संपूर्ण नेटस्पेक का अभाव है। - लाइन पर 168 of
OrderMixin.sol
और ऑन लाइन 71 ofOrderRFQMixin.sol
, यह गायब है@dev
टैग। - में कार्य
PredicateHelper
अनुबंध सभी मापदंडों का वर्णन नहीं करता है।
कोड के इरादों को रेखांकित करने के लिए स्पष्ट इनलाइन दस्तावेज़ीकरण मौलिक है। इनलाइन दस्तावेज़ीकरण और कार्यान्वयन के बीच बेमेल होने से सिस्टम से कैसे व्यवहार करने की अपेक्षा की जाती है, इसके बारे में गंभीर ग़लतफ़हमियाँ पैदा हो सकती हैं। डेवलपर्स, उपयोगकर्ताओं और ऑडिटरों के लिए भ्रम से बचने के लिए इन त्रुटियों को ठीक करने पर विचार करें।
अपडेट: आंशिक रूप से ठीक किया गया. भ्रामक दस्तावेज का उल्लेख किया गया है पुल अनुरोध # 75 और पुल अनुरोध # 77.
1इंच टीम बताती है:
हमने भ्रामक दस्तावेज़ ठीक कर दिए हैं. दस्तावेज़ों को पूरा करने का कार्य बाद में किया जाएगा.
[एल11] हुक का उपयोग करते समय DoS ऑर्डर संभव है
RSI OrderMixin
अनुबंध सामान्य ऑफ-चेन स्वैप ऑर्डर को भरने के लिए कार्यक्षमता लागू करता है जिसमें उनकी सफलता के लिए शर्तें हो सकती हैं। ऑर्डर भरने के दौरान, ऑर्डर कर सकते हैं पूर्वनिर्धारित "विधेय" शर्तों की जाँच करें निष्पादन जारी रखने से पहले.
हालाँकि, क्योंकि ये विधेय स्थितियाँ किसी भी मनमाने अनुबंध के तर्क को लक्षित कर सकती हैं, एक दुर्भावनापूर्ण निर्माता लेने वालों को यह विश्वास दिला सकता है कि एक ऑर्डर सही ढंग से व्यवहार करता है और ऑफ-चेन की जाँच करते समय यह वैध है, लेकिन फिर उसी ऑर्डर को भरने का प्रयास करते समय विफल हो जाता है। ऑन-चेन। विधेय व्यवहार में यह परिवर्तन या तो कुछ परिवर्तनीय स्थिति को सामने रखकर किया जा सकता है, जिस पर विधेय निर्भर करता है, भेजे गए गैस की जांच करके या यहां तक कि कॉल में कौन से पते शामिल हैं, या किसी अन्य तर्क से।
इसके अलावा, यदि निर्माता ने परिभाषित किया है अदला-बदली के दौरान बातचीत, interactionTarget
सफल ऑर्डर भरने को रोकने के लिए अनुबंध स्वयं को वापस कर सकता है या भत्ते को रद्द कर सकता है, जिससे अनिवार्य रूप से दुर्भावनापूर्ण विधेय के समान परिणाम हो सकता है।
हालाँकि परिसंपत्तियाँ जोखिम में नहीं होंगी, अनुकूल ऑर्डर खोजने वाले उपयोगकर्ताओं या बॉट पर इस प्रकार के स्पैम ऑर्डर की पहचान करने का बोझ बढ़ जाएगा जो सतह पर वैध लग सकते हैं। ऐसी स्थिति में कि वे इस प्रकार के आदेशों की पहचान करने में विफल रहते हैं, उन्हें गैस की बर्बादी का खर्च उठाना पड़ेगा। स्पैम ऑर्डर की मात्रा कम करने के लिए, इन हुक के लिए उपलब्ध लक्ष्यों को सीमित करने पर विचार करें। ऑर्डर भरने का प्रयास करने से पहले उपयोगकर्ताओं को इस संभावना के बारे में चेतावनी देने पर भी विचार करें।
अपडेट: पक्का नहीं है। 1इंच टीम बताती है:
हम इसे अपने बैकएंड पर संभालते हैं और हम मुद्दे के बारे में संभावित खरीदारों को सूचित करने के तरीकों के बारे में सोचेंगे।
[एल12] गोलाई प्रतिकूल हो सकती है taker
में OrderMixin
और OrderRFQMixin
अनुबंध, जब कोई ऑर्डर भरा जा रहा हो और लेने वाला केवल एक प्रदान करता है makingAmount
or takingAmount
राशि, प्रोटोकॉल स्वैप की समकक्ष राशि की गणना करने का प्रयास करता है।
इन गणनाओं के साथ दो मुद्दे हैं, पहला यह कि राशि मापदंडों का उपयोग करने वाले दशमलव की संख्या को सीमित करने वाला कोई दस्तावेज या तर्क नहीं है, जिसे हमने संबोधित किया है अप्रलेखित दशमलव धारणाएँ मुद्दा।
दूसरा मुद्दा यह है कि, इन गणनाओं के दौरान, प्रोटोकॉल निर्माता के पक्ष में जाता है। जब अंतर्निहित दशमलव धारणाएँ टूट जाती हैं, तो पूर्णांकन की समस्या बहुत बढ़ सकती है, लेकिन जब सब कुछ अपेक्षित शर्तों में होता है, तब भी पूर्णांकन छोटी, विषम मात्राओं के साथ होगा।
लेने वाले को न्यूनतम राशि निर्दिष्ट करने की अनुमति देने पर विचार करें makerAsset
वह संपत्ति जिसे वे अधिकतम राशि के साथ प्राप्त करने के इच्छुक हैं takerAsset
वे परिसंपत्ति की अदला-बदली करने को तैयार हैं, ताकि किसी भी राउंडिंग की स्वीकृति अधिक स्पष्ट हो।
अपडेट: पक्का नहीं है। 1इंच टीम बताती है:
लेने वाले की सुरक्षा के लिए सीमा राशि पर्याप्त होनी चाहिए।
[एल13] पैरामीटर्स की कमी होने पर विरोधाभासी ऑर्डर हैंडलिंग
में OrderMixin
अनुबंध, fillOrderTo
फ़ंक्शन को आंतरिक कॉल करता है _callGetMakerAmount
और _callGetTakerAmount
जब भी भरने का प्रयास किया जाता है तो कार्य करता है और दोनों में से कोई भी makingAmount
या takingAmount
पैरामीटर क्रमशः शून्य हैं, या यदि makingAmount
मूल्य से बड़ा है remainingMakerAmount
मूल्य.
RSI _callGetMakerAmount
और _callGetTakerAmount
यदि ऑर्डर इसके साथ नहीं बनाया गया था तो कॉल प्रत्यावर्तन की ओर ले जाएंगी getMakerAmount
or getTakerAmount
पैरामीटर, क्रमशः, और आंशिक भरण निष्पादित किया जा रहा है।
An साथ में इनलाइन टिप्पणी _callGetMakerAmount
और एक साथ में इनलाइन टिप्पणी _callGetTakerAmount
दावा करें कि यदि ऑर्डर नहीं बनाया गया है तो "केवल पूर्ण भरने की अनुमति है"। getMakerAmount
or getTakerAmount
मापदंडों।
हालाँकि, ऐसे कोड पथ हैं जिनके लिए यह लागू नहीं होता है, क्योंकि वे पथ जाँच नहीं करते हैं length
दोनो का s getMakerAmount
और getTakerAmount
मापदंडों।
विशेष रूप से, जब एक taker
निर्दिष्ट करता है a takerAmount
एक ऑर्डर के लिए मूल्य जिसमें केवल एक है getMakerAmount
, जब तक कि वह कॉल न हो getMakerAmount
से बड़ी राशि लौटाता है remainingMakerAmount
, इनलाइन दस्तावेज़ीकरण के विपरीत आंशिक भरण निष्पादित किया जा सकता है।
इससे उन कोड पथों की मंशा अस्पष्ट हो जाती है। यदि यह अपेक्षित व्यवहार है, तो इनलाइन दस्तावेज़ को संशोधित करने पर विचार करें ताकि यह अधिक स्पष्ट हो। यदि यह अनजाने में किया गया व्यवहार है, तो हमेशा दोनों की लंबाई की जाँच करने पर विचार करें getMakerAmount
और getTakerAmount
पैरामीटर एक साथ ताकि कार्यान्वयन इनलाइन दस्तावेज़ीकरण द्वारा वर्णित व्यवहार को सुदृढ़ करे।
अपडेट: में तय किया पुल अनुरोध # 79.
[एल14] अप्रचलित चैनलिंक कॉल का उपयोग करना
RSI ChainlinkCalculator
अनुबंध का उद्देश्य चैनलिंक ओरेकल से पूछताछ करना है। यह उन्हें कॉल करके ऐसा करता है latestTimestamp
और latestAnswer
विधियों, जिनमें से दोनों को अस्वीकृत कर दिया गया है. वास्तव में, विधियाँ अब चैनलिंक एग्रीगेटर्स के एपीआई में मौजूद नहीं हैं संस्करण तीन के अनुसार.
चैनलिंक ओरेकल के साथ भविष्य में संभावित असंगतताओं से बचने के लिए, इसका उपयोग करने पर विचार करें latestRoundData
इसके बजाय विधि.
अपडेट: में तय किया पुल अनुरोध # 67.
नोट्स और अतिरिक्त जानकारी
[एन01] इंटरफ़ेस आयात नहीं किया जा रहा है
RSI AggregatorInterface
ऐसा प्रतीत होता है कि इंटरफ़ेस कॉपी किए गए कोड का एक सबसेट है ChainLink
का सार्वजनिक कोड भंडार. पूरा इंटरफ़ेस शामिल है ChainLink
का अनुबंध एनपीएम पैकेज.
जब संभव हो, इंटरफ़ेस बेमेल और परिणामी समस्याओं की संभावना को कम करने के लिए, किसी अन्य प्रोजेक्ट के इंटरफेस को फिर से परिभाषित करने और/या फिर से लिखने के बजाय, उनके आधिकारिक एनपीएम पैकेज के माध्यम से स्थापित इंटरफेस का उपयोग करने पर विचार करें।
अपडेट: में तय किया पुल अनुरोध # 66.
[एन02] पदावनत परियोजना निर्भरता
की स्थापना के दौरान परियोजना की निर्भरता, NPM चेतावनी देता है कि स्थापित संकुलों में से एक, Highlight
, "भविष्य में अब समर्थित नहीं होंगे या सुरक्षा अपडेट प्राप्त नहीं करेंगे"।
हालांकि यह संभावना नहीं है कि यह पैकेज सुरक्षा जोखिम पैदा कर सकता है, इस पैकेज का उपयोग करने वाली निर्भरता को एक अनुरक्षित संस्करण में अपग्रेड करने पर विचार करें।
अपडेट: में तय किया पुल अनुरोध # 64.
[एन03] देखने के तरीकों के लिए बाहरी कॉल स्टैटिक कॉल नहीं हैं
अधिकांश कोडबेस में, प्रोटोकॉल स्पष्ट रूप से OpenZeppelin के माध्यम से बाहरी कॉल करता है functionStaticCall
राज्य में परिवर्तन की संभावना को प्रतिबंधित करने की विधि जब वे या तो अपेक्षित नहीं हैं या वांछनीय नहीं हैं। हालाँकि, में ChainlinkCalculator
अनुबंध, केवल बाहरी कॉल करने के इरादे के बावजूद view
चैनलिंक ओरेकल पर विधियां, बाहरी कॉल singlePrice
और doublePrice
कार्य स्पष्ट रूप से नहीं किए जाते हैं staticcall
s.
हालाँकि हमने इससे उत्पन्न होने वाली किसी भी तत्काल सुरक्षा चिंता की पहचान नहीं की है, हमले की सतह को कम करने, स्थिरता में सुधार करने और इरादे को स्पष्ट करने के लिए, स्पष्ट का उपयोग करने पर विचार करें staticcall
s, सभी बाहरी कॉलों के लिए view
में कार्य करता है ChainlinkCalculator
अनुबंध।
अपडेट: पक्का नहीं है। 1इंच टीम बताती है:
हमारा मानना है कि सिंटैक्स जटिलता निरंतरता में सुधार को रद्द कर देती है।
[एन04] अमान्य आदेशों के साथ जल्दी असफल नहीं होना
में OrderMixin
अनुबंध, fillOrderTo
फ़ंक्शन उस विशेष स्थिति को संभालता है जब कोई ऑर्डर पहले सबमिट नहीं किया गया हो (remainingMakerAmount == 0
), लेकिन यह स्पष्ट रूप से उस स्थिति को संभाल नहीं पाता है जब ऑर्डर अब वैध नहीं है (remainingMakerAmount == 1
).
बाद के परिदृश्य में, फ़ंक्शन अंततः वापस आ जाएगा, लेकिन केवल गैर-तुच्छ मात्रा में गैस जलाने के बाद। इरादे को स्पष्ट करने, पठनीयता बढ़ाने और गैस के उपयोग को कम करने के लिए, फ़ंक्शन की शुरुआत में अमान्य-ऑर्डर परिदृश्य को स्पष्ट रूप से संभालने पर विचार करें।
अपडेट: में तय किया पुल अनुरोध # 68.
[एन05] सहायक अनुबंधों को सार के रूप में चिह्नित नहीं किया गया है
सॉलिडिटी में, कीवर्ड abstract
इसका उपयोग उन अनुबंधों के लिए किया जाता है जो या तो अपने आप में कार्यात्मक अनुबंध नहीं हैं, या इस तरह उपयोग किए जाने के लिए नहीं हैं। बजाय, abstract
स्टैंड-अलोन कार्यात्मक अनुबंध बनाने के लिए अनुबंधों को सिस्टम में अन्य अनुबंधों द्वारा विरासत में मिला है।
पूरे कोडबेस में, ऐसे सहायक अनुबंधों के उदाहरण हैं जिन्हें सार के रूप में चिह्नित नहीं किया गया है, इस तथ्य के बावजूद कि वे स्वयं तैनात करने के लिए नहीं हैं। उदाहरण के लिए, AmountCalculator
, ChainlinkCalculator
, ImmutableOwner
, NonceManager
, तथा PredicateHelper
सभी अनुबंधों में फ़ंक्शंस का एक आधार सेट शामिल होता है जिसका उपयोग अनुबंधों को प्राप्त करने के लिए किया जाता है।
सहायक अनुबंधों को इस रूप में चिह्नित करने पर विचार करें abstract
यह स्पष्ट रूप से इंगित करने के लिए कि वे पूरी तरह से उन अनुबंधों में कार्यक्षमता जोड़ने के लिए डिज़ाइन किए गए हैं जो उन्हें विरासत में मिले हैं।
अपडेट: पक्का नहीं है। 1इंच टीम बताती है:
उन मददगारों को अलग से तैनात किया जा सकता है. वे केवल गैस बचत के लिए विरासत में मिले हैं।
[एन06] असंगत फ़ंक्शन ऑर्डरिंग
पूरे कोडबेस में, फ़ंक्शन ऑर्डरिंग आम तौर पर इस प्रकार होती है सॉलिडिटी स्टाइल गाइड में अनुशंसित आदेश, जो है: constructor
, fallback
, external
, public
, internal
, private
.
हालाँकि, में OrderMixin
अनुबंध, public
checkPredicate
फ़ंक्शन स्टाइल गाइड से भटक जाता है, द्विभाजित हो जाता है external
कार्य करता है.
प्रोजेक्ट की समग्र पठनीयता में सुधार करने के लिए, सॉलिडिटी स्टाइल गाइड द्वारा अनुशंसित, पूरे कोडबेस में फ़ंक्शन ऑर्डरिंग को मानकीकृत करने पर विचार करें।
अपडेट: में तय किया पुल अनुरोध # 69.
[एन07] असंगत ऑर्डर भरण प्रवाह
RSI OrderMixin
और RFQOrderMixin
दोनों अनुबंध हस्ताक्षरित आदेशों को भरने का काम संभालते हैं, लेकिन दोनों अनुबंधों के बीच सामान्य ऑर्डर प्रवाह असंगत है।
OrderMixin
की fillOrderTo
फ़ंक्शन इस सामान्य प्रवाह (छद्म कोड) का अनुसरण करता है:
if ((takingAmount == 0) == (makingAmount == 0))
else if (takingAmount == 0)
else (handle makingAmount == 0) THEN swapTokens
जहाँ तक RFQOrderMixin
अनुरूप है fillOrderRFQTo
फ़ंक्शन इस प्रवाह का अनुसरण करता है (छद्म कोड):
if (takingAmount == 0 && makingAmount == 0)
else if (takingAmount == 0)
else if (makingAmount == 0)
else revert THEN swapTokens
दस्तावेज़ीकरण से इस बात की कोई जानकारी नहीं है कि इन दोनों कार्यों में से प्रत्येक में पहला सशर्त भिन्न क्यों है, या क्यों takingAmount
और makingAmount
बाद वाले फ़ंक्शन में दोनों शून्य नहीं हो सकते। साथ ही, वह मामला जहां दोनों ए makingAmount
और एक takingAmount
प्रदान किए गए हैं जिनके बारे में तर्क करना बहुत आसान है fillOrderRFQTo
फ़ंक्शन, क्योंकि इसे अंतिम रूप से स्पष्ट रूप से नियंत्रित किया जाता है else
ब्लॉक।
इरादे को स्पष्ट करने और कोड की समग्र पठनीयता को बढ़ाने के लिए, या तो इन दो अनुबंधों में सामान्य ऑर्डर प्रवाह को मानकीकृत करने पर विचार करें, या स्पष्ट रूप से दस्तावेज़ीकरण करें कि अंतर क्यों मौजूद हैं।
अपडेट: पक्का नहीं है। 1इंच टीम बताती है:
यह सीमा आदेशों में कस्टम मूल्य निर्धारण कार्यों के कारण है। तब से
getMakerAmount
संभावित रूप से काफी हद तक भिन्न हो सकता हैgetTakerAmount
, हमने सोचा कि लेने वाले के लिए डिफ़ॉल्ट विकल्प न बनाना बेहतर है क्योंकि यह संभवतः उन मामलों में उन्हें भ्रमित करेगा जब वे प्राप्तकर्ता अलग होंगे।
[एन08] त्रुटि संदेश असंगत रूप से स्वरूपित या भ्रामक हैं
पूरे कोडबेस में, require
और revert
त्रुटि संदेश, जो उपयोगकर्ताओं को लेन-देन विफल होने वाली विशेष स्थितियों के बारे में सूचित करने के लिए होते हैं, असंगत रूप से स्वरूपित पाए गए।
उदाहरण के लिए, लाइनों पर प्रत्येक त्रुटि संदेश 85 का OrderMixin.sol
, 16 का ERC721ProxySafe.sol
, तथा 26 का Permitable.sol
एक अलग शैली अपनाएं.
इसके अतिरिक्त, कुछ त्रुटि संदेश भ्रामक हैं:
त्रुटि संदेशों का उद्देश्य उपयोगकर्ताओं को विफल स्थितियों के बारे में सूचित करना है, इसलिए उन्हें पर्याप्त जानकारी प्रदान करनी चाहिए ताकि सिस्टम के साथ बातचीत करने के लिए उचित सुधार किए जा सकें। बिना सूचना वाले त्रुटि संदेश समग्र उपयोगकर्ता अनुभव को बहुत नुकसान पहुंचाते हैं, जिससे सिस्टम की गुणवत्ता कम हो जाती है। इसके अलावा, असंगत रूप से स्वरूपित त्रुटि संदेश अनावश्यक भ्रम पैदा कर सकते हैं। इसलिए, यह सुनिश्चित करने के लिए संपूर्ण कोडबेस की समीक्षा करने पर विचार करें require
और revert
कथन में एक त्रुटि संदेश है जो लगातार स्वरूपित, सटीक, सूचनात्मक और उपयोगकर्ता के अनुकूल है।
अपडेट: में आंशिक रूप से तय किया गया पुल अनुरोध # 81.
[एन09] नामित रिटर्न वेरिएबल्स का असंगत उपयोग
नामित रिटर्न वेरिएबल्स का असंगत उपयोग है OrderMixin
अनुबंध। कुछ कार्य नामित चर लौटाएँ, अन्य स्पष्ट मान लौटाएँ, और दूसरे एक नामित रिटर्न वैरिएबल घोषित करें लेकिन इसे ओवरराइड करें एक स्पष्ट रिटर्न स्टेटमेंट के साथ।
सभी नामित रिटर्न वेरिएबल्स को हटाकर, उन्हें स्पष्ट रूप से स्थानीय चर के रूप में घोषित करके, और जहां उपयुक्त हो वहां आवश्यक रिटर्न स्टेटमेंट जोड़कर पूरे कोडबेस में मूल्यों को वापस करने के लिए एक सुसंगत दृष्टिकोण अपनाने पर विचार करें। यह कोड की व्याख्या और पठनीयता दोनों में सुधार करेगा, और यह भविष्य के कोड रिफैक्टर के दौरान प्रतिगमन को कम करने में भी मदद कर सकता है।
अपडेट: में तय किया पुल अनुरोध # 73.
[एन10] ऑर्डर की हैश गणना एपीआई के लिए खुली नहीं है
RSI external
कार्यों remaining
, remainingRaw
और remainingsRaw
सभी सफल संचालन के लिए ऑर्डर हैश की अपेक्षा करते हैं।
हालाँकि, सहायक कार्य _hash
, जो किसी ऑर्डर का हैश लौटाता है private
दृश्यता. इसका मतलब यह है कि उपयोगकर्ताओं को ऑर्डर का हैश प्राप्त करने के लिए ऑर्डर के कुछ हिस्सों और डोमेन स्ट्रिंग्स को मैन्युअल रूप से पैक करना होगा।
ऑर्डर हैश की गणना करते समय गलतियों की संभावना से बचने के लिए और उपयोगकर्ताओं को ऑर्डर के संबंधित हैश उत्पन्न करने की एक विधि प्रदान करने के लिए, की दृश्यता बढ़ाने पर विचार करें _hash
कार्य करना public
और नाम को पुनः सक्रिय करना hash
शेष कोड के अनुरूप होना।
अपडेट: में तय किया पुल अनुरोध # 74.
[एन11] मैपिंग का सिमेंटिक ओवरलोडिंग
RSI _remaining
में मैपिंग OrderMixin
आदेशों की स्थिति और उन आदेशों के लिए उपलब्ध परिसंपत्तियों की शेष राशि को ट्रैक करने के लिए अनुबंध को शब्दार्थ रूप से अतिभारित किया गया है।
तीन स्थितियाँ जिन पर यह काम कर सकता है वे हैं:
0
: ऑर्डर हैश अभी तक नहीं देखा गया है।1
: ऑर्डर या तो रद्द कर दिया गया है या पूरी तरह भर दिया गया है।- कोई
uint
से भी बड़ा1
: शेषmakerAmount
ऑर्डर प्लस पर भरने के लिए उपलब्ध है1
.
इस सिमेंटिक ओवरलोडिंग के दौरान इस मान को लपेटने और खोलने की आवश्यकता होती है lookup
, cancellation
, initialization
, तथा storage
.
सिमेंटिक ओवरलोडिंग और इसे सक्षम करने के लिए आवश्यक तर्क से त्रुटि की संभावना हो सकती है और कोडबेस को समझना और तर्क करना कठिन हो सकता है, यह कोड के भविष्य के अपडेट में प्रतिगमन के लिए दरवाजा भी खोल सकता है।
कोड की पठनीयता में सुधार करने के लिए, एक अलग मैपिंग में ऑर्डर की पूर्णता स्थिति को ट्रैक करने पर विचार करें।
अपडेट: पक्का नहीं है। 1इंच टीम ने कहा कि सुधार से गैस की लागत बढ़ जाएगी fillOrder
समारोह.
[एन12] परमिट वाले ऑर्डर मनमाने अनुबंधों पर कॉल करने की अनुमति देते हैं
RSI OrderMixin
अनुबंध विरासत में मिला है Permitable
ऐसी परिसंपत्तियों को भरने के लिए एकल-लेन-देन आदेश की अनुमति देने का अनुबंध जो इसे स्वीकार करता है permit
भत्तों में संशोधन की मांग
हालांकि, को कॉल करता है Permitable
अनुबंध यह सत्यापित न करें कि लक्ष्य एक स्वीकार्य संपत्ति है या नहीं और न ही यह एक संपत्ति है, जो एक दुर्भावनापूर्ण उपयोगकर्ता को एक मनमाने अनुबंध के पते को पारित करने की अनुमति दे सकती है जो ऑर्डर भरने से पहले एक और कॉल निष्पादित कर सकती है।
हालांकि अनुबंध है पुनर्प्रवेश से सुरक्षित, हमले की सतह को कम करने और निष्पादन के दौरान बाहरी अनुबंधों को कॉल करने से रोकने की हमेशा अनुशंसा की जाती है। या तो परमिट में शामिल संपत्ति को ऑर्डर में शामिल संपत्ति तक या प्रोटोकॉल के लिए संपत्ति श्वेतसूची तक सीमित करने पर विचार करें।
अपडेट: पक्का नहीं है। 1इंच टीम बताती है:
OrderMixin
वास्तव में वास्तविक टोकन के बारे में जानकारी नहीं हैmakerAsset
औरtakerAsset
कभी-कभी प्रॉक्सी या अन्य मध्यवर्ती अनुबंध होते हैं और वास्तविक टोकन के बारे में जानकारी कुछ मनमाने बाइट्स में संग्रहीत होती है। इसलिए किस परिसंपत्ति को प्रतिबंधित करने का कोई व्यवहार्य तरीका नहीं हैpermit
बुलाया जाता है.
[एन13] solhint
कभी भी पुन: सक्षम नहीं किया जाता है
पूरे कोडबेस में, कुछ हैं solhint-disable
बयान, विशेष रूप से वे जो लाइन पर हैं 23 और ऑन लाइन 41 of RevertReasonParser.sol
, जिसे समाप्त नहीं किया गया है solhint-enable
.
स्पष्टता के पक्ष में और अक्षम करते समय यथासंभव प्रतिबंधात्मक होना चाहिए solhint
का उपयोग करने पर विचार करें solhint-disable-line
or solhint-disable-next-line
इसके बजाय, लाइन के समान 16 उसी फ़ाइल का.
अपडेट: में तय किया पुल अनुरोध # 72.
[एन ०५] टाइपोस
कोडबेस में निम्नलिखित टाइपो शामिल हैं:
इसके अतिरिक्त प्रोजेक्ट का README
(इस ऑडिट के दायरे से बाहर) में निम्नलिखित टाइपो त्रुटियाँ हैं:
कोड की पठनीयता में सुधार के लिए इन त्रुटियों को ठीक करने पर विचार करें।
अपडेट: में तय किया पुल अनुरोध # 71 और पुल अनुरोध # 77.
[एन15] का उपयोग uint
के बजाय uint256
स्पष्टता के पक्ष में, के सभी उदाहरण uint
के रूप में घोषित किया जाना चाहिए uint256
. विशेष रूप से, उन में for
लाइनों पर लूप 98 और 119 of OrderMixin.sol
और रेखाएं 16 और 30 of PredicateHelper.sol
.
अपडेट: में तय किया पुल अनुरोध # 70.
निष्कर्ष
3 उच्च गंभीरता के मुद्दे पाए गए। सर्वोत्तम प्रथाओं का पालन करने और संभावित हमले की सतह को कम करने के लिए कुछ बदलाव प्रस्तावित किए गए थे।
- &
- 7
- About
- पहुँच
- अनुसार
- लेखा
- के पार
- अधिनियम
- कार्रवाई
- अतिरिक्त
- पता
- लाभ
- सब
- की अनुमति दे
- पहले ही
- हालांकि
- राशियाँ
- विश्लेषण
- एपीआई
- दृष्टिकोण
- तर्क
- चारों ओर
- आस्ति
- संपत्ति
- आडिट
- बैक-एंड
- शुरू
- जा रहा है
- BEST
- सर्वोत्तम प्रथाओं
- बिट
- बॉट
- निर्माण
- कॉल
- कौन
- मामलों
- कारण
- चेन लिंक
- परिवर्तन
- जाँच
- जाँचता
- कोड
- जटिल
- शर्त
- भ्रम
- निर्माण
- शामिल हैं
- अनुबंध
- ठेके
- सुधार
- लागत
- सका
- युगल
- निर्माता
- मुद्रा
- वर्तमान
- तिथि
- सौदा
- सेवा से वंचित
- तैनाती
- डिज़ाइन
- डेवलपर्स
- विकास
- डीआईडी
- अलग
- विभिन्न
- डोमेन
- डबल
- गतिशील
- शीघ्र
- Edge
- प्रोत्साहित करना
- विशेष रूप से
- ETH
- कार्यक्रम
- घटनाओं
- सब कुछ
- उदाहरण
- एक्सचेंज
- अपेक्षित
- अनुभव
- शोषण करना
- विशेषताएं
- फ़ील्ड
- अंत में
- प्रथम
- फिक्स
- लचीलापन
- प्रवाह
- का पालन करें
- पाया
- पूर्ण
- समारोह
- धन
- भविष्य
- खेल
- गैस
- सामान्य जानकारी
- देते
- महान
- गाइड
- हैंडलिंग
- हैश
- हैशिंग
- होने
- मदद
- हाई
- अत्यधिक
- कैसे
- HTTPS
- संकर
- पहचान करना
- प्रभाव
- लागू करने के
- महत्वपूर्ण
- का आयात
- शामिल
- सहित
- बढ़ना
- वृद्धि हुई
- पता
- करें-
- इंफ्रास्ट्रक्चर
- अंतर्दृष्टि
- इरादा
- ब्याज
- इंटरफेस
- शामिल
- मुद्दों
- IT
- बड़ा
- बड़ा
- नेतृत्व
- प्रमुख
- पुस्तकालय
- सीमित
- लाइन
- चलनिधि
- सूचीबद्ध
- सूचियाँ
- स्थानीय
- देखा
- लुकअप
- प्रमुख
- निर्माता
- निर्माण
- बाजार
- याद रखना
- आईना
- आदर्श
- अधिकांश
- सबसे लोकप्रिय
- यानी
- नई सुविधाएँ
- गैर प्रतिमोच्य
- गैर-फंगेबल टोकन
- सरकारी
- खुला
- संचालन
- विकल्प
- पेशीनगोई
- आदेश
- आदेशों
- अन्य
- मालिक
- पैटर्न
- लोकप्रिय
- वर्तमान
- रोकने
- मूल्य
- कीमत निर्धारण
- निजी
- प्रक्रिया
- परियोजना
- परियोजनाओं
- सुरक्षा
- प्रोटोकॉल
- प्रदान करना
- प्रदान करता है
- प्रतिनिधि
- सार्वजनिक
- प्रकाशित करना
- क्रय
- गुणवत्ता
- उठाना
- वास्तविकता
- को कम करने
- रिलायंस
- रिपोर्ट
- रिपोर्ट
- कोष
- आवश्यकताएँ
- बाकी
- परिणाम
- रिटर्न
- की समीक्षा
- जोखिम
- राउंड
- रन
- एसडीके
- सुरक्षा
- सेवाएँ
- सेट
- साझा
- शेयरों
- पाली
- समान
- सरल
- छोटा
- स्मार्ट
- स्मार्ट अनुबंध
- So
- दृढ़ता
- स्पैम
- विशेष रूप से
- खर्च
- Spot
- प्रारंभ
- राज्य
- कथन
- राज्य
- स्थिति
- भंडारण
- अंदाज
- प्रस्तुत
- सफलता
- सफल
- सफलतापूर्वक
- समर्थन
- समर्थित
- सतह
- स्विच
- प्रणाली
- लक्ष्य
- परीक्षण
- परीक्षण
- परीक्षण
- यहाँ
- भर
- पहर
- एक साथ
- टोकन
- टोकन
- ट्रैक
- ट्रैकिंग
- ट्रांजेक्शन
- ट्रस्ट
- अद्वितीय
- अपडेट
- us
- प्रयोज्य
- यूएसडी
- USDT
- उपयोगकर्ताओं
- उपयोगिता
- मूल्य
- देखें
- दृश्यता
- प्रतीक्षा
- क्या
- श्वेत सूची
- अंदर
- बिना
- काम
- लायक
- शून्य