Web3 ऑडिटिंग की दयनीय स्थिति, और क्या किया जा सकता है

Balancer, एक पुराना और अच्छी तरह से ऑडिट किया गया प्रोटोकॉल, हाल ही में "हैक" हुआ। इसी तरह अच्छी तरह से ऑडिट किया गया Yearn Finance भी। कई साल पहले Euler Finance को एक फंक्शन के जरिए "हैक" किया गया था जो पहले के ऑडिट के जवाब में पेश किया गया था। USPD को तैनाती से पहले ऑडिट किया गया था और फिर गैर-ऑडिट की गई तैनाती प्रक्रिया को ही हैक कर लिया गया, जिसके परिणामस्वरूप लॉन्च के लगभग 3 महीने के भीतर पूरी तरह से नुकसान हुआ। कोई भी जो ध्यान दे रहा है, वह नहीं मानता कि ऑडिट यह गारंटी हैं कि कुछ सुरक्षित है। कई लोग सवाल करते हैं कि क्या वे बिल्कुल भी मूल्यवान हैं।

यह नया नहीं है। यह web3 की समस्या नहीं है। और, वास्तव में, यह कोई विशेष रूप से गहरी टिप्पणी नहीं है। लेकिन ऑडिट अभी भी बहुत अधिक एक चीज हैं। प्रोजेक्ट ऑडिट के लिए भुगतान करते हैं। प्रोजेक्ट ऑडिट की घोषणा करते हैं। लोग ऑडिट पढ़ने का दिखावा करते हैं। अक्सर जब किसी ऑडिट किए गए उत्पाद का शोषण किया जाता है तो लोग पूछते हैं कि ऐसा क्यों और कैसे हुआ।

इनमें से किसी का भी सीधे जवाब देने के बजाय हम हाल ही में लॉन्च किए गए उत्पादों के कुछ हालिया ऑडिट पर काम करने जा रहे हैं। यहां लक्ष्य किसी का मजाक उड़ाना या आलोचना करना नहीं है। इन्हें यादृच्छिक रूप से चुना गया है, मुख्य रूप से हाल की चीजों पर ध्यान केंद्रित करने के कारण। इसका मतलब यह नहीं है कि वे विशेष रूप से खराब हैं। वे इतने भी खराब नहीं हैं!

हमारा यहां यह कहना नहीं है कि ऑडिटर कुछ गलत कर रहे हैं। ऑडिटर वही कर रहे हैं जो उन्हें नियुक्त करने वाले प्रोजेक्ट मांगते हैं। ऑडिट का दायरा प्रोजेक्ट द्वारा निर्धारित किया जाता है। एक चरम उदाहरण के रूप में: अगर Do Kwon ने अपनी स्टेबलकॉइन योजना के लिए ऑडिटर नियुक्त किए होते तो वे नोट करते कि यह संभावित रूप से अस्थिर थी। समस्या को "स्वीकार किया गया" के रूप में चिह्नित किया गया होता और कुछ भी नहीं किया गया होता या अलग नहीं होता।

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

इस सर्वेक्षण का उद्देश्य यह स्पष्ट करना है कि यहां असली समस्या उस प्रकार की बुनियादी प्रोग्रामिंग त्रुटियां नहीं हैं जिन्हें पहचानने के लिए ऑडिटर अच्छी स्थिति में हैं और ऑडिट प्रक्रिया को हल करने के लिए अच्छी तरह से डिज़ाइन किया गया है। ऑडिटर उन्हें पकड़ने में काफी अच्छे हैं। उस मामले के लिए, प्रोग्रामर भी जो पहली जगह में इन चीजों का निर्माण कर रहे हैं। अनुभवजन्य रूप से इस तरह की फीडबैक सही लोगों तक पहुंचती है और संकीर्ण मुद्दों को ठीक किया जाता है।

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

और फिर अंत में हम चर्चा करने जा रहे हैं कि विभिन्न पक्ष क्या कर सकते हैं जो दोनों मदद करेगा और अपने संकीर्ण स्वार्थों की सेवा करेगा। यदि ऑडिट को बेहतर बनाने के लिए आपके नुस्खे में परोपकार शामिल है तो, ठीक है, यह बहुत उपयोगी नहीं है।

Jovay

Jovay एक L2 है जो Ant Financial या Alibaba या उस सामान्य क्षेत्र में कुछ से जुड़ा है। लेकिन यह वास्तव में मायने नहीं रखता कि Jovay क्या करता है। यह एक बड़े और अच्छी तरह से वित्त पोषित संगठन से सॉफ्टवेयर से बना एक चीज है। यह ऑडिट आठ मुद्दों को सूचीबद्ध करता है:

1. एक वैध प्रोग्रामिंग गलती जो बाद में ठीक की गई थी।
2. कि प्रोटोकॉल ट्रस्टलेस नहीं है। यह एक तरह की समस्या है लेकिन यह डिजाइन का एक मुख्य हिस्सा भी है।
3. "फेक-रिचार्ज" अटैक जो इकोसिस्टम के व्यापक हिस्से पर लागू होता है और प्रोजेक्ट के लिए विशिष्ट नहीं है।
4. RPC सर्वर HTTPS के बजाय HTTP का उपयोग करते हैं। ये इंटरफेस गुप्त जानकारी को प्रोसेस नहीं करते हैं। यह अरबों पूरी तरह से सुरक्षित रीड-ओनली वेबसाइटों पर लागू होता है।
5. क्वांटम कंप्यूटिंग Ethereum के लिए एक जोखिम पैदा करता है। ठीक है। बहुत ही विषयानुकूल वाला।
6. EVM स्मार्ट कॉन्ट्रैक्ट कमजोर हो सकते हैं। नहीं गंभीरता से। इसमें कहा गया है "Evm स्मार्ट कॉन्ट्रैक्ट अपरिवर्तनीय कोड तैनाती और जटिल इंटरैक्शन के कारण विभिन्न अटैक वेक्टर के लिए अतिसंवेदनशील हैं, जो संभावित रूप से फंड की चोरी का कारण बन सकते हैं,.." ठीक है। फिर से इस ऑडिट के संकीर्ण फोकस का वास्तव में सम्मान कर रहे हैं।
7. सीक्वेंसर डिजाइन MEV के अधीन है। बाकी पूरे Ethereum इकोसिस्टम की तरह। रात में भी बहुत अंधेरा है।
8. कोड की गुणवत्ता में सुधार किया जा सकता है। कंप्यूटिंग की शुरुआत के बाद से लिखे गए अधिकांश अन्य कोड के विपरीत।

इनमें से केवल एक ही वास्तविक मुद्दा है। हां यह ध्यान देने योग्य है कि उत्पाद स्वयं ट्रस्टलेस नहीं है यदि दस्तावेज़ अन्यथा बताता है कि यह ट्रस्टलेस है। लेकिन यह उत्पाद उस मोर्चे पर बहुत ठीक है। यह नोट करना कि क्वांटम कंप्यूटिंग संभावित रूप से भविष्य में जोखिम पैदा करता है और स्मार्ट कॉन्ट्रैक्ट जोखिम भरा हो सकता है... वे या तो बनाई गई समस्याओं को खोजकर रिपोर्ट को लंबा बनाने का प्रयास हैं या वे किसी तरह का "यह हमारी गलती नहीं है" प्रदान करने का प्रयास हैं यदि कुछ अंततः हैक हो जाता है। शायद दोनों का मिश्रण।

उन बिंदुओं की भावना में हम नौवीं समस्या के रूप में प्रस्तावित करते हैं कि जब तक हम एक अंतरतारकीय प्रजाति नहीं बन जाते और किसी तरह प्रकाश से तेज संचार का पता नहीं लगा लेते, तब तक सूरज मरने पर नेटवर्क डाउन हो जाएगा। अन्यथा सापेक्षता इस प्रणाली के उपयोगी जीवन को लगभग 5 अरब वर्षों तक सीमित करती है। ईमानदारी से यह कोड की गुणवत्ता में सुधार किया जा सकता है कहने से अधिक उपयोगी है क्योंकि सूर्य के मरने के बाद भी कहीं न कहीं खराब कोड निष्पादित हो रहा होगा। लेकिन हम मजाक कर रहे हैं।

Hyperliquid

Hyperliquid ने कुछ ऑडिट रिपोर्ट प्रकाशित की हैं। पहली ऑडिट रिपोर्ट में छह समस्याएं पाई गईं और दूसरी रिपोर्ट ने पुष्टि की कि उन्हें हल किया गया। लेकिन ऑडिट के दायरे में शामिल नहीं था:

1. Hyperliquid सिस्टम का हिस्सा अन्य स्मार्ट कॉन्ट्रैक्ट
2. ऑफ-चेन कंपोनेंट, जैसे वैलिडेटर
3. फ्रंट-एंड कंपोनेंट
4. प्रोजेक्ट से संबंधित इंफ्रास्ट्रक्चर
5. की कस्टडी

वे संभावित समस्या क्षेत्रों की तरह लगते हैं! जो कुछ भी ऑडिट किया गया था वह एक एकल ब्रिज कॉन्ट्रैक्ट था। लेकिन सिस्टम, ठीक है, यह उससे बहुत अधिक जटिल है।

सिस्टम के एक छोटे से कोने का ऑडिट करना जो केवल कुछ कसकर परिभाषित चीजें करता है, काफी बेकार है। जिस तरह से Hyperliquid को डिज़ाइन किया गया है, ऑडिट किया गया कॉन्ट्रैक्ट सभी के लिए बाहरी प्रवेश और निकास बिंदु है। इसलिए यह एक गंभीर समस्या होगी यदि वह कॉन्ट्रैक्ट त्रुटियों से भरा होता। लेकिन यह पुष्टि करना कि कॉन्ट्रैक्ट काम करता है, बहुत कम या कोई आराम प्रदान नहीं करता है।

Ondo

यह ऑडिट "विश्वसनीय संस्थाओं और भूमिकाओं के लिए केंद्रीकरण जोखिम" को हाइलाइट करता है जिसे टीम ने स्वीकार किया। इसे रिपोर्ट में इस तरह कैपिटलाइज़ किया गया है। सही।

यह ऑडिट नोट करता है कि सिस्टम ढह सकता है यदि कोई शामिल स्टेबलकॉइन बहुत अधिक डीपेग हो जाता है। वे इसे इस तरह वाक्यांश करते हैं कि सिस्टम "USDC डीपेग इवेंट के दौरान अत्यधिक OUSG टोकन मिंटिंग की अनुमति देगा।" अंत में "समाधान" जो उन्होंने डाला वह एक Chainlink ओरेकल का संदर्भ था और एक ऑफ-स्विच यदि कीमत बहुत कम रिपोर्ट की जाती है। इसलिए मूल्य क्रैश होने के साथ इम्प्लोड होने के बजाय प्रोटोकॉल मूल्य क्रैश होने के साथ रुक जाएगा। सही। यह एक हल करने योग्य समस्या नहीं है क्योंकि कोई तंत्र नहीं है जो मूल्य-हारने वाले परिणाम से बचे यदि USDC उड़ जाता है। और, उस तथ्य के अनुरूप, समाधान वास्तव में कुछ भी ठीक नहीं करता है।

वे ऑडिट अपेक्षाकृत हाल के हैं। लेकिन कुछ संदर्भ देने के लिए अक्टूबर 2022 से यह ऑडिट बहुत सारे वास्तविक मुद्दों की पहचान करता है। लगभग 200 उनमें से। अधिकांश को ठीक किया गया था, कुछ उपरोक्त के समान थे और बस स्वीकार किए गए थे। बात यह है कि ऑडिटिंग कुछ ठोस और ठोस करती थी: प्रोग्रामिंग त्रुटियों की तलाश करें जो प्रोग्रामर के इरादे से नहीं हो सकती थीं। प्रोग्रामर इन त्रुटियों को ठीक करते थे क्योंकि वे, आप जानते हैं, वास्तविक गलतियां थीं न कि केवल उत्पाद में निर्मित संदिग्ध डिजाइन निर्णय।

और फिर 2024 तक हम ऑडिट देखते हैं जो अपेक्षाकृत कम तकनीकी समस्याओं को पाते हैं और वित्तीय-संबंधित हमलों को दायरे से बाहर घोषित करते हैं। समय के साथ इस परिवर्तन की व्याख्या करने का एकमात्र समझदार तरीका यह है कि प्रोग्रामर, और ऑडिटर के रूप में प्रोग्रामर, ने पहचाना कि कार्यात्मक कोड ही एकमात्र जोखिम नहीं था। निश्चित रूप से प्रोग्रामिंग बग समय-समय पर शोषित होते थे। लेकिन 2024 के मध्य तक हर कोई देख सकता था कि दोषपूर्ण आर्थिक तंत्र भी एक बड़ा जोखिम था। वे सबसे बड़ा जोखिम थे।

प्रोजेक्ट जो बिल्कुल इरादे के अनुसार काम करते थे – सपने के अनुसार नहीं, वास्तविकता में इरादे के अनुसार – समय-समय पर विस्फोट हो जाते हैं क्योंकि डिजाइनरों के स्थिरता के सपने वास्तविक दुनिया का सामना करने पर टूट जाते हैं।

आप इस एक प्रोजेक्ट के ऑडिट में यह विकास देख सकते हैं।

Mutuum Finance

अब हमारे पास ऑडिट का रेडक्टियो एड एब्सर्डम है। यह एक एकल मुद्दे की पहचान करता है:

मुद्दा प्रारंभिक टोकन वितरण के आसपास पारदर्शिता की कमी है और यह कैसे केंद्रीकरण समस्याओं से संबंधित हो सकता है। इसे "शमित" किया गया है क्योंकि:

फिर बहुत सारे मल्टीसिग विवरण हैं। और अंत में ऑडिटर की प्रतिक्रिया:

तो प्रोजेक्ट के साथ जोखिम यह है कि एक छोटी टीम सब कुछ नियंत्रित करती है और जिस तरह से वह नियंत्रण होगा, या शायद नहीं होगा, फैलाया जाएगा वह पूरी तरह से गैर-पारदर्शी है। और टीम का प्रस्तावित समाधान अपने इरादे को स्पष्ट करने के लिए एक ब्लॉग पोस्ट लिखना किसी भी सख्त अर्थ में इसे ठीक नहीं करता है।

रिकॉर्ड के लिए टीम ने एक विस्तृत सूची प्रकाशित की है कि टोकन कब और कहां जाएंगे। और वे स्वीकार करते हैं कि यह अधूरा है जैसे टिप्पणियों के साथ "हम या तो ब्लॉक-बाय-ब्लॉक या साप्ताहिक वितरण मॉडल पर विचार कर रहे हैं।" वे यह भी स्वीकार करते हैं कि सब कुछ मैनुअल मल्टीसिग से प्रबंधित किया जाएगा। तो वे ईमानदार हो रहे हैं। यह सिर्फ इतना है कि ईमानदारी का मतलब है "हाँ हम अभी भी जो चाहें कर सकते हैं और आपको हम पर भरोसा करना होगा।"

इस ऑडिट का उद्देश्य क्या है? यदि कोड में कोई पहचान योग्य बग नहीं था तो ऑडिटर बस इतना लिख सकता था। कभी-कभी डॉक्टर या मैकेनिक के पास जाने से स्वास्थ्य का एक साफ बिल मिलता है। तो हम सोच रहे हैं कि क्या केवल एक तुच्छ मात्रा में कोड का ऑडिट किया गया था? या शायद प्रोजेक्ट स्वयं बस कोड की एक तुच्छ मात्रा है? क्या ऑडिटर ने रिपोर्ट में कुछ डालने की आवश्यकता महसूस की क्योंकि यह सब बहुत खाली था? किसी ने इनमें से किसी भी चीज की परवाह क्यों की?

फिर से हम वास्तव में यहां ऑडिटर को दोष नहीं दे रहे हैं। जिस हद तक कोई यहां कुछ गलत कर रहा है, यह लगभग निश्चित रूप से एक प्रोत्साहन समस्या है जिसने भी ऑडिट को कमीशन किया। और यह तथ्य कि वे एक मार्केटिंग उद्देश्य के लिए एक ज्यादातर बेकार दस्तावेज़ तैयार करने के लिए निवेशक के पैसे खर्च कर रहे हैं। यह ऑडिटर का काम नहीं है!

सुधार

यह एक स्पष्ट अच्छी बात है कि अधिक बग पकड़े जाते हैं, कम टूटा हुआ कोड प्रोडक्शन में जारी किया जाता है और अधिक प्रस्तावित फिक्स लागू किए जाते हैं। और हम यह सुझाव देने के लिए काफी अपरिपक्व नहीं हैं कि समस्या यह है कि उपयोगकर्ता और निवेशक गलत चीजों की परवाह करते हैं, उदाहरण के लिए, ऑडिट पर मूल्य और विश्वास रखना जिनका अधिक मतलब नहीं है। लोग जिसकी परवाह करते हैं उसकी परवाह करते हैं और इसे बदलने की कोशिश करना एक मूर्खतापूर्ण काम है।

लेकिन कुछ वास्तविक सुधार हैं जिनका हम सुझाव दे सकते हैं। Ethena ने अपने उत्पाद के कई विफलता तरीकों को अग्रिम में समझाकर मार्ग का नेतृत्व किया। टीम इस संदेश के साथ सुसंगत थी कि USDe जोखिम रहित नहीं था। और उन्होंने उन तरीकों को रेखांकित किया जिनसे इसे परेशानी हो सकती थी। उत्पाद जीवित रहा है, कुछ धक्कों के साथ, और आज काफी बड़ा है। यह हमें निवेशकों के लिए एक एक्शन पॉइंट देता है: जोर दें कि प्रोजेक्ट किसी भी "वित्तीय-संबंधित हमलों" के बारे में ईमानदार हों जो मौजूद हो सकते हैं।

Ethena दिखाता है कि ईमानदार होना प्रोजेक्ट को बर्बाद नहीं करता! आप तर्क दे सकते हैं कि अधिक ईमानदार होने से प्रोजेक्ट ने अधिक रुचि आकर्षित की। ईमानदारी में यह भी अतिरिक्त बोनस है कि यदि कुछ गलत हो जाता है तो अधिक कानूनी कवर प्रदान करता है। प्रोजेक्ट को पहले से ही ऐसा करना चाहिए।

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

लेकिन यह बिंदु चूक जाता है। क्वांटम सुरक्षा एक सिस्टम के लिए एक "महत्वपूर्ण" जोखिम हो सकता है – लेकिन यह एक खराब सिग्नेचर चेक या गलत माइनस साइन से पूरी तरह से अलग चरित्र का है! इन चीजों को अलग अनुभागों में रखें। इसी तरह "यह स्टेबलकॉइन योजना उचित रूप से संभावित परिस्थितियों में अस्थिर है" कोड में लॉजिक बग जैसा कुछ भी नहीं है। इस भ्रम को दूर करने से ऑडिट दस्तावेजों की उपस्थिति में सुधार होना चाहिए और ऑडिटर की प्रतिष्ठा में निखार आना चाहिए।

अंत में, एक्सचेंज इसमें मदद कर सकते हैं। बड़े एक्सचेंज भयानक प्रोजेक्ट सूचीबद्ध करने, या जंगली रूप से उतार-चढ़ाव वाले जोखिम भरे मेमकॉइन जो लोगों को पैसे खर्च करते हैं, या नुकसान-पहुंचाने वाले अन्य सभी तरह के अजीब व्यावसायिक निर्णयों के लिए बहुत कुछ प्राप्त करते हैं। क्या होगा अगर एक्सचेंज उचित ऑडिट पर जोर दें जो आर्थिक स्थिरता को ईमानदारी से कवर करते हैं और "स्मार्ट कॉन्ट्रैक्ट कमजोर हो सकते हैं" जैसे जोखिमों को वास्तविक लॉजिक चेक के साथ भ्रमित नहीं करते हैं?

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

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

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