उमा ऑडिट - चरण 6

परिचय

UMA एक ऐसा मंच है जो उपयोगकर्ताओं को एथेरियम ब्लॉकचेन पर विश्वास-न्यूनतम वित्तीय अनुबंध दर्ज करने की अनुमति देता है। हमने पहले ऑडिट किया था विकेन्द्रीकृत ओरेकल, एक विशेष वित्तीय अनुबंध टेम्पलेट, कुछ तदर्थ पुल अनुरोध, सदा बहुदलीय टेम्पलेट, लंबी व्यस्तता पर विभिन्न वृद्धिशील पुल अनुरोध और बीमित पुल.

इस ऑडिट में हमने एक नए शासन प्रस्ताव अनुबंध, कई श्रृंखलाओं में यूएमए पारिस्थितिकी तंत्र का विस्तार करने के लिए एक तंत्र, ऑफ-चेन विनिर्देश के अनुसार ईआरसी721 टोकन धारकों को पुरस्कार वितरित करने के लिए एक तंत्र और WETH का समर्थन करने के लिए बीमाकृत पुल के अपडेट की समीक्षा की। आशावाद श्रृंखला पर.

लेखापरीक्षित प्रतिबद्धता है 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc और दायरे में निम्नलिखित अनुबंध शामिल हैं:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (परीक्षण और बहुभुज अनुबंधों को छोड़कर)
• financial-templates/optimistic-rewarder/* (परीक्षण अनुबंधों को छोड़कर)

हमने सॉलिडिटी फाइलों में हुए बदलावों की भी समीक्षा की पुल अनुरोध 3611.

सभी बाहरी कोड और अनुबंध निर्भरता को दस्तावेज के रूप में काम करने के लिए मान लिया गया था।

सिस्टम सारांश

वर्तमान Governance अनुबंध रिस्क लैब्स फाउंडेशन को नए शासन कार्यों का प्रस्ताव करने की अनुमति देता है जिन्हें यूएमए टोकन धारकों द्वारा अनुमोदित किया जा सकता है। नई Proposer अनुबंध का उद्देश्य प्रस्तावक की भूमिका निभाना है, जिससे किसी को भी नए प्रस्ताव बनाने की इजाजत मिलती है, जब तक वे एक बांड प्रदान करते हैं जिसे प्रस्ताव विफल होने पर त्याग दिया जाएगा। प्रस्ताव बनाने के लिए कोई विशेष प्रोत्साहन नहीं है। इरादा यह सुनिश्चित करना है कि केवल वही कार्रवाइयां प्रस्तावित की जाएंगी जिनके स्वीकृत होने की बहुत अधिक संभावना है।

नया क्रॉस-चेन तंत्र शासन प्रस्ताव को एथेरियम मेननेट से ऑप्टिमिज्म और आर्बिट्रम श्रृंखलाओं में पारित करने की अनुमति देता है। इस तरह, परत 1 पर यूएमए शासन तंत्र का उपयोग समर्थित परत 2 श्रृंखलाओं पर यूएमए अनुबंधों को नियंत्रित करने के लिए किया जा सकता है। तंत्र परतों के बीच मूल्य अनुरोधों और प्रस्तावों को अग्रेषित करने की भी अनुमति देता है, इसलिए परत 2 श्रृंखलाओं पर आशावादी ओरेकल को मेननेट डेटा सत्यापन तंत्र द्वारा उसी तरह सुरक्षित किया जा सकता है जैसे परत 1 आशावादी ओरेकल को डीवीएम द्वारा सुरक्षित किया जाता है।

यह ध्यान देने योग्य है कि ये संदेश देशी ब्रिज यांत्रिकी का उपयोग करके भेजे जाते हैं, जिसका अर्थ है कि वे संबंधित परत 2 श्रृंखलाओं की विशेषताओं द्वारा सीमित हैं। विशेष रूप से, परत 2 से परत 1 तक संदेशों को पुल पारगमन में एक सप्ताह या उससे अधिक समय लग सकता है। इसके अलावा, यूएमए शासन तंत्र उन प्रस्तावों का समर्थन करता है जिनमें कई ऑर्डर किए गए लेनदेन शामिल हैं, लेकिन यह केवल उस क्रम को प्रतिबंधित करता है जिसमें उन्हें ब्रिज में जोड़ा जा सकता है। यह संभव है कि उनमें से कुछ लेनदेन को परत 2 पर एक अलग क्रम में निष्पादित किया जाए, या बिल्कुल नहीं।

ऑप्टिमिस्टिक रिवार्डर अनुबंध केवल अनुरोध करने वाले किसी भी व्यक्ति के लिए ERC721 टोकन ढालता है। यह किसी को भी किसी भी टोकन के साथ मनमाना डेटा जोड़ने और पुरस्कार के रूप में वितरित करने के लिए विभिन्न ईआरसी20 टोकन जमा करने की अनुमति देता है। मनमाने डेटा की व्याख्या और टोकन धारकों के बीच पुरस्कारों का अपेक्षित वितरण एक अनिर्दिष्ट ऑफ-चेन प्रक्रिया का उपयोग करके निर्धारित किया जाता है। यदि कोई बांड जमा करने को इच्छुक है तो कोई भी यह दावा कर सकता है कि एक विशिष्ट ईआरसी721 टोकन पर पुरस्कारों का एक सेट बकाया है। मानक आशावादी ओरेकल तंत्र का उपयोग किसी अन्य व्यक्ति को दावे पर विवाद करने की अनुमति देने के लिए किया जाता है, जिसे डीवीएम द्वारा हल किया जाएगा। जिन दावों पर समय पर विवाद नहीं होता, उन्हें वैध माना जाता है और अनुबंध तदनुसार पुरस्कार वितरित करता है। एकमात्र प्रतिबंध (लेखांकन को सरल बनाने के लिए) यह है कि ओरेकल बांड टोकन को इनाम टोकन के रूप में उपयोग नहीं किया जा सकता है।

अंत में, PR3611 ऑप्टिमिज्म टोकन ब्रिज पर WETH भेजने से बचने के लिए बीमित ब्रिज तंत्र को संशोधित करता है, जो समर्थित नहीं है। इसके बजाय, ऑप्टिमिज़्म डिपॉज़िट बॉक्स में जमा किया गया कोई भी L2 WETH ब्रिज को पार करने से पहले L2 ETH में लपेट दिया जाता है। परत 1 पर, ईटीएच को WETH ब्रिज पूल में अग्रेषित करने से पहले WETH में परिवर्तित किया जाता है।

गंभीर गंभीरता

[सी01] अमान्य इनाम पर विवाद नहीं किया जा सकता

इनाम अनुरोध पर विवाद करते समय, OptimisticRewardBase पहले अनुबंध एक प्रस्ताव ट्रिगर करता है पर SkinnyOptimisticOracle और फिर उस प्रस्ताव पर विवाद करता है. हालाँकि, प्रस्ताव समाप्ति समय निर्धारित करता है वर्तमान (विवाद) समय से ऑफसेट के रूप में, जबकि विवाद समाप्ति निर्दिष्ट करता है मूल इनाम अनुरोध के समय से ऑफसेट के रूप में। ज्यादातर मामलों में, यह विसंगति ओरेकल को विवादित प्रस्ताव की पहचान करने से रोक देगी, जिसका अर्थ है कि वैध विवादों पर कार्रवाई नहीं की जाएगी और अमान्य इनाम अनुरोध स्वीकार किए जाएंगे।

विवादित प्रस्ताव को सही ढंग से निर्दिष्ट करने के लिए विवाद आह्वान को अद्यतन करने पर विचार करें।

अपडेट: प्रतिबद्ध के रूप में निश्चित 9e15557 in PR3690.

[सी02] प्रस्तावों को बार-बार हल करें

RSI resolveProposal का कार्य Proposer अनुबंध बस मान्य करता है कि दैवज्ञ ने समाधान कर दिया है, लेकिन यह जाँच नहीं करता है कि बांड वितरित किया गया है या नहीं। इसका मतलब यह है कि एक ही प्रस्ताव को कई बार हल किया जा सकता है, जिसके परिणामस्वरूप डुप्लिकेट बांड भुगतान हो सकता है। मौजूदा प्रस्तावों का समाधान हो जाने पर उन्हें चिह्नित करने या हटाने पर विचार करें।

अपडेट: प्रतिबद्ध के रूप में निश्चित b152718 in PR3689.

उच्च गंभीरता

कोई नहीं.

मध्यम गंभीरता

[एम01] गलत ईवेंट पैरामीटर

RSI OptimisticRewarderBase अनुबंध परिभाषित करता है a Requested घटना जो से उत्सर्जित होता है requestRedemption जब मोचन का अनुरोध किया जाता है तो कार्य करें। इस घटना को उत्सर्जित करने के लिए परिभाषित किया गया है मोचन की समाप्ति समय इसके अंतिम पैरामीटर के रूप में। तथापि, जब घटना उत्सर्जित होती है, इसका अंतिम पैरामीटर गलत तरीके से सेट है वर्तमान समय.

इसी प्रकार Redeemed घटना रिकॉर्ड हटाए जाने के बाद समाप्ति समय पढ़ता है, इसलिए इसे गलत तरीके से शून्य पर सेट किया जाएगा।

यह देखते हुए कि इस घटना का उपयोग ऑफ-चेन गणनाओं को ट्रिगर करने के लिए किया जा सकता है, उत्सर्जित मूल्य को उचित रूप से अपडेट करने पर विचार करें।

अपडेट: प्रतिबद्ध के रूप में निश्चित f04eef9 in PR3694.

कम गंभीरता

[एल01] मोचन पर विवाद के बाद घटना उत्सर्जन का अभाव

RSI OptimisticRewarderBase अनुबंध परिभाषित करता है a Disputed घटना यदि कोई मोचन विवादित है तो इसे चालू करने का इरादा है। हालाँकि, यह घटना इसके भीतर या बाहर उत्सर्जित नहीं होती है OptimisticRewarderBase अनुबंध।

इसमें संवेदनशील परिवर्तन होने के बाद ईवेंट को उत्सर्जित करने पर विचार करें dispute समारोह, अनुबंध की गतिविधि के बाद ऑफ-चेन ग्राहकों को ट्रैक करने और सूचित करने की सुविधा के लिए।

अपडेट: प्रतिबद्ध के रूप में निश्चित c275e92 in PR3695.

[एल02] असंगत पुनर्प्रवेश गार्ड

RSI Optimism_ParentMessenger और Arbitrum_ParentMessenger अनुबंध असंगत रूप से लागू होते हैं nonReentrant संशोधक. इसे सभी सार्वजनिक समारोहों में शामिल करने पर विचार करें।

अपडेट: प्रतिबद्ध के रूप में निश्चित 6275c39 in PR3677.

[एल03] भ्रामक टिप्पणियाँ

यहां कुछ भ्रामक टिप्पणियाँ हैं जिन्हें हमने अपनी समीक्षा के दौरान पहचाना:

• ChildMessengerConsumerInterface.sol:
  • रेखा 5 "बाल संदेशवाहक" के स्थान पर "अभिभावक संदेशवाहक" कहता है
• GovernorSpoke.sol:
  • 49-51 लाइनों ए से लिंक Gnosis फ़ाइल भले ही टिप्पणी कहती है कि स्निपेट कॉपी किया गया था Governor.sol. इसके अतिरिक्त, स्निपेट इसमें दिए गए स्निपेट के समान नहीं है Governor.sol

अपडेट: प्रतिबद्ध के रूप में निश्चित cc350f9 in PR3678.

[एल04] सहायक डेटा स्टैम्प गुम

पर कीमत का अनुरोध करते समय OracleSpoke अनुबंध, प्रदान किया गया सहायक डेटा मुहर लगी है चाइल्ड चेन पहचानकर्ता के साथ। हालांकि hasPrice और getPrice मूल्य अनुरोध की पहचान करते समय फ़ंक्शन सहायक डेटा पर मुहर नहीं लगाते हैं। यह कॉलिंग कॉन्ट्रैक्ट्स को स्वयं स्टांप लागू करने के लिए मजबूर करता है, जो मूल्य अनुरोध और मूल्य पुनर्प्राप्ति तंत्र के बीच असंगतता का कारण बनता है। में स्टाम्प लगाने पर विचार करें hasPrice और getPrice कार्य करता है.

अपडेट: प्रतिबद्ध के रूप में निश्चित fdb845d in PR3668.

[एल05] नेटस्पेक पैरामीटर गुम है

में कई कार्य OptimisticRewarderBase अनुबंध की याद आ रही है @return उनकी प्राकृतिक विशिष्टता टिप्पणियों में पैरामीटर। संपूर्णता के लिए इसे शामिल करने पर विचार करें.

अपडेट: प्रतिबद्ध के रूप में निश्चित 8920f38 in PR3679.

[एल06] अवशिष्ट भत्ता

आशावादी ओरेकल का आह्वान करने के लिए, OptimisticRewarderBase अनुबंध इसे सांकेतिक भत्ता देता है, इसलिए यह बांड भुगतान खींच सकता है। यदि प्रस्ताव विफल हो जाता है, इनाम मोचन रद्द कर दिया गया है लेकिन भत्ता रीसेट नहीं किया गया है. इसलिए, आशावादी ओरेकल अगली बार विवाद शुरू होने तक अनावश्यक अवशिष्ट भत्ता बरकरार रखेगा। प्रस्ताव विफल होने पर भत्ता रद्द करने पर विचार करें।

अपडेट: प्रतिबद्ध के रूप में निश्चित c2d444b in PR3698.

[एल07] अमान्य धनवापसी पता

का रिफंड L2 पता Arbitrum_ParentMessenger प्रारंभ किया गया है अनुबंध स्वामी को, जो L1 गवर्नर होना चाहिए। इसी प्रकार, setRefundL2Address एक टिप्पणी है यह कहते हुए कि इसे राज्यपाल के पास भेजा जाना चाहिए। हालाँकि, पुल के ऊपर से संदेश भेजते समय, यह मान होता है L2 उपयोगकर्ता के रूप में सेट करें, जो आर्बिट्रम पर वह पता है जो टिकट के समाधान के बाद अतिरिक्त धनराशि प्राप्त करता है। चूंकि एल1 गवर्नर का पता आर्बिट्रम पर उपलब्ध नहीं होगा, इसलिए इस पते पर भेजा गया कोई भी फंड खो जाएगा।

इसे वैध L2 पते पर सेट करने पर विचार करें।

अपडेट: प्रतिबद्ध के रूप में निश्चित b3f2dd1 in PR3687.

[एल08] बाल संदेशवाहकों को बदलने का तंत्र

RSI GovernorSpoke और OracleSpoke प्रत्येक कॉन्ट्रैक्ट कंस्ट्रक्टर में चाइल्ड मैसेंजर को इनिशियलाइज़ करता है, इसे अपडेट करने के लिए कोई तंत्र नहीं है। इसका मतलब यह है कि जब बाल संदेशवाहक बदल दिया गया है, दोनों बोले गए अनुबंध अप्रचलित हो जाते हैं।

चूंकि स्पोक अनुबंध मैसेंजर की तुलना में अधिक स्थिर होने की संभावना है, इसलिए स्पोक्स पर मैसेंजर को अपडेट करने के लिए एक तंत्र शामिल करने पर विचार करें।

अपडेट: प्रतिबद्ध के रूप में निश्चित 7c9e061 in PR3688.

नोट्स और अतिरिक्त जानकारी

[एन01] बांड टोकन बदलें

RSI Proposer अनुबंध में शामिल हैं एक तंत्र मालिक के लिए प्रस्ताव बांड का आकार बदलना। विचार करें कि क्या उन्हें बांड टोकन बदलने में भी सक्षम होना चाहिए। ध्यान दें कि मौजूदा प्रस्तावों का समाधान होने पर सही बांड मुद्रा की पहचान करने के लिए एक तंत्र की आवश्यकता होगी।

अपडेट: मुद्दा नहीं। इस मुद्दे पर UMA का बयान:

N01 प्रस्तावक अनुबंध को बांड टोकन को UMA के अलावा किसी अन्य चीज़ में बदलने के लिए सक्षम करने की अनुशंसा करता है। इस फ़ंक्शन के लिए $UMA के अलावा किसी अन्य टोकन का समर्थन करने का हमारा कोई इरादा नहीं है और इसलिए हमने इस मुद्दे के लिए कोई बदलाव नहीं करने का विकल्प चुना है। इसके अलावा, प्रति अनुबंध एक एकल टोकन इस तर्क को यथासंभव सरल रखता है। अंत में, यदि परिवर्तन की आवश्यकता थी (उदाहरण के लिए, टोकन माइग्रेशन के मामले में), तो हम दूसरे टोकन के साथ एक नया प्रस्तावक अनुबंध तैनात कर सकते हैं और उस टोकन का उपयोग करने के लिए सिस्टम को माइग्रेट करने का प्रस्ताव शुरू कर सकते हैं।

[एन02] अधूरा इंटरफ़ेस

RSI ChildMessengerInterface एक निर्दिष्ट नहीं करता processMessageFromCrossChainParent फ़ंक्शन, भले ही इसे मूल दूतों द्वारा अस्तित्व में माना जाता है। संपूर्णता के लिए इसे शामिल करने पर विचार करें.

अपडेट: पक्का नहीं है। इस मुद्दे पर UMA का बयान:

हमने जानबूझकर इस इंटरफ़ेस को असंगत छोड़ना चुना क्योंकि चाइल्डमेसेंजरइंटरफ़ेस के भीतर इसे लागू करने से पॉलीगॉन_चाइल्डमेसेंजर के साथ संगतता टूट जाती है क्योंकि अन्य श्रृंखलाओं से संदेशों को संसाधित करने के लिए पॉलीगॉन की विधि को कुछ हद तक कस्टम तर्क की आवश्यकता होती है जिसमें एक आंतरिक विधि को _processMessageFromRoot कहा जाता है।

[एन03] गलत इंटरफ़ेस

RSI GovernorSpoke गलत तरीके से अनुबंध करना का उपयोग करता है ChildMessengerConsumerInterface टाइप इसका वर्णन करने के लिए messenger चर। का उपयोग करने पर विचार करें ChildMessengerInterface बजाय.

अपडेट: प्रतिबद्ध के रूप में निश्चित f31a527 in PR3680.

[एन04] स्टोर करने के लिए टोकन खींचें

में पिछला ऑडिट हमने इसके उद्देश्य पर सवाल उठाया Store ठेके payOracleFeesErc20 समारोह (अंक एल19 में)। उमा टीम फ़ंक्शन को बनाए रखने का विकल्प चुना संभावित भविष्य के संशोधनों के लिए इंटरफ़ेस को मानकीकृत करना। चूंकि फ़ंक्शन का उद्देश्य पूरी तरह से निर्दिष्ट नहीं है, इसलिए यह स्पष्ट नहीं है कि इसे तब ट्रिगर किया जाना चाहिए या नहीं Proposer अनुबंध एक बांड जब्त कर लेता है. इसका उपयोग संभवतः तब किया जाना चाहिए जब OracleHub मूल्य अनुरोध के लिए भुगतान करता है. विचार करें कि क्या फ़ंक्शन का उपयोग किसी भी परिदृश्य में किया जाना चाहिए।

अपडेट: स्वीकृत. इस मुद्दे पर UMA का बयान:

N04 स्टोर के उपयोग के अनुरूप होने के लिए प्रस्तावक और OracleHub दोनों अनुबंधों में शुल्क का भुगतान करने के लिए स्टोर के payOracleFeeErc20 पद्धति का उपयोग करने की अनुशंसा करता है। हमने इस फ़ंक्शन का उपयोग न करने का विकल्प चुना है क्योंकि इसका मतलब होगा कि एक अतिरिक्त इंटरफ़ेस (स्टोर के लिए) आयात करने की आवश्यकता होगी और बॉन्ड राशि को फिक्स्डपॉइंट में कास्टिंग करने की आवश्यकता होगी (जिसके लिए अतिरिक्त आयात की भी आवश्यकता होगी। कोड को सरल और साफ रखने के लिए) हमने ऐसा न करने का विकल्प चुना है। अप्रैल 20 में ऑडिट चरण 1 में payOracleFeeErc2020 पर OZ प्रतिक्रिया मान्य थी कि यह विधि वास्तव में उपयोगी नहीं है, जिससे इस तरह के एकीकरण के बारे में तर्क करना कठिन हो गया है।

[N05] कोड में TODOs

कोड बेस में "TODO" टिप्पणियाँ हैं जिन्हें प्रोजेक्ट के मुद्दों के बैकलॉग में ट्रैक किया जाना चाहिए। उदाहरण के लिए:

• लाइन 37 of Arbitrum_ParentMessenger अनुबंध
• लाइन 25 of Optimism_ChildMessenger अनुबंध
• पंक्तियां 83 और 146 of OracleHub अनुबंध।

विकास के दौरान, "TODO" टिप्पणियों का अच्छी तरह से वर्णन करने से उन्हें ट्रैक करने और हल करने की प्रक्रिया आसान हो जाएगी। उस जानकारी के बिना, ये टिप्पणियाँ सड़ सकती हैं और सिस्टम की सुरक्षा के लिए महत्वपूर्ण जानकारी उत्पादन के लिए जारी होने तक भुला दी जा सकती है।

इन TODO टिप्पणियों में लंबित कार्य का संक्षिप्त विवरण और प्रोजेक्ट रिपॉजिटरी में संबंधित मुद्दे का लिंक होना चाहिए।

इस जानकारी को जोड़ने के लिए TODO टिप्पणियों को अद्यतन करने पर विचार करें। पूर्णता और पता लगाने की क्षमता के लिए, एक हस्ताक्षर और एक टाइमस्टैम्प जोड़ा जा सकता है। उदाहरण के लिए:

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

अपडेट: प्रतिबद्ध के रूप में निश्चित 5d57b5b in PR3684.

[N06] टंकण संबंधी त्रुटियां

कोडबेस में निम्नलिखित मुद्रण संबंधी त्रुटियाँ हैं:

• में Admin_ChildMessenger अनुबंध, impleenting होना चाहिए implementing
• में OptimisticRewarderBase अनुबंध, timestap होना चाहिए timestamp.
• में OptimisticRewarderBase अनुबंध, liveness liveness होना चाहिए liveness.
• में GovernorSpoke अनुबंध, only called होना चाहिए only be called.
• में Optimism_ChildMessenger अनुबंध:

अपडेट: प्रतिबद्ध के रूप में निश्चित 9b92b0b in PR3681.

[एन07] अप्रयुक्त आयात

कोड की पठनीयता में सुधार के लिए, निम्नलिखित अप्रयुक्त आयातों को हटाने पर विचार करें:

अपडेट: प्रतिबद्ध के रूप में निश्चित 40b7221 in PR3682.

[एन08] एल2 लेनदेन आदेश

RSI Governor सुनिश्चित किसी प्रस्ताव के भीतर लेनदेन क्रम में निष्पादित किए जाते हैं। हालाँकि, जब उन लेनदेन में क्रॉस-चेन लेनदेन शामिल होता है, तो यह केवल गारंटी देता है कि वे सही क्रम में एल1 ब्रिज अनुबंध पर पहुंचते हैं। आर्बिट्रम मामले में, उन्हें L2 पर अंतिम रूप देने से पहले पुन: व्यवस्थित किया जा सकता है। इसलिए, पुन: व्यवस्थित एल2 लेनदेन की संभावना की अनुमति देने के लिए शासन प्रस्तावों का निर्माण किया जाना चाहिए।

अपडेट: प्रतिबद्ध के रूप में निश्चित 0fb2e7b in PR3703। GovernorHub अब L2 लेनदेन की एक श्रृंखला रिले कर सकता है।

निष्कर्ष

कोडबेस में दो महत्वपूर्ण मुद्दे पाए गए। एक मध्यम गंभीरता का मुद्दा और कई छोटी कमजोरियाँ पाई गई हैं, और समाधान के लिए सिफारिशें सुझाई गई हैं।

स्रोत: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-pass-6