ब्लॉकचैन स्टार्टअप के लिए सुरक्षा खतरे के रूप में स्मार्ट अनुबंध

आधिकारिक वेबसाइट के अनुसार, Ethereum स्मार्ट कॉन्ट्रैक्ट्स को "बिल्कुल प्रोग्राम्ड के रूप में निष्पादित किया जाता है, बिना डाउनटाइम, सेंसरशिप, धोखाधड़ी या तीसरे पक्ष के हस्तक्षेप के"। आज मैं यह पता लगाने की कोशिश करूंगा कि क्या वास्तव में सब कुछ इतना रसात्मक है, कुछ ऐसी समस्याओं की जांच की जा रही है जो स्मार्ट कॉन्ट्रैक्ट उपयोगकर्ताओं को व्यवहार में आती हैं।

लेख के अंत में, मैं एक संक्षिप्त मार्गदर्शिका के साथ सुरक्षित स्मार्ट अनुबंध लिखने के लिए अपने विचारों को संक्षेप में प्रस्तुत करता हूं।

टिप्पणी

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

स्मार्ट अनुबंध सुरक्षा मुद्दे

यह उन समस्याओं के बारे में होगा जो स्मार्ट कॉन्ट्रैक्ट के डेवलपर्स अंत में सामना करते हैं, और मंच की सुरक्षा के बारे में नहीं (हालांकि इसके बारे में थोड़ा सा)। हम इन समस्याओं को पारंपरिक रूप से निम्न प्रकारों में विभाजित करते हैं:

1. स्मार्ट अनुबंध कोड में समस्याएं;
2. विकास प्रक्रिया में समस्याएं;
3. भाषा में समस्याएं;
4. अवधारणा में समस्याएं।

1. स्मार्ट कॉन्ट्रैक्ट कोड में समस्याएं

यहाँ एक स्मार्ट अनुबंध के कोड में समस्याओं से, मेरा मतलब है कि .sol फ़ाइल को संपादित करके हल की गई समस्याएं। यह विशेष रूप से है:

• ज्ञात कमजोर निर्माण (जैसे फिर से प्रवेश )।
  जीवन उदाहरण : पुनः-प्रवेश, या, अधिक मोटे तौर पर, चेक-इफेक्ट्स-इंटरैक्शन पैटर्न का उल्लंघन - यहां तक ​​कि व्यापक रूप से ज्ञात (और पहले से शोषित ) कमजोरियों को नए अनुबंधों में पाया जाना जारी है।
• लेखक के कमजोर निर्माण (विशेष रूप से, कोड के तर्क में त्रुटियां)।
  जीवन उदाहरण : एक मल्टीसिग वॉलेट जो वास्तव में मल्टीसिग नहीं है। लेनदेन पर हस्ताक्षर करने और धन हस्तांतरित करने के लिए, आपको required बराबर बटुआ मालिकों के हस्ताक्षरों की संख्या की required । उसी समय, required परिवर्तन करने के required (उदाहरण के लिए, एक, अपने आप को लेन-देन को आगे बढ़ाने के लिए), केवल एक मालिक के हस्ताक्षर ही पर्याप्त हैं:

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

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

2. विकास प्रक्रिया में समस्याएं

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

• TK: अधिकांश Ethereum स्मार्ट अनुबंध तकनीकी कार्य के बिना लिखे गए हैं। यह क्या नेतृत्व कर सकता है, अनावश्यक रूप से समझाने के लिए।
• समय: औसतन, बहुत कम समय विकास के लिए आवंटित किया जाता है, लगभग एक महीने। मेरे अभ्यास से एक चरम उदाहरण: ग्राहक ने डेवलपर को ICO से 3 दिन पहले एक स्मार्ट अनुबंध लिखने के लिए कहा।
• डेवलपर स्तर: बहुत सारे लोग इस क्षेत्र में आते हैं, जिसमें बिना प्रोग्रामिंग पृष्ठभूमि भी शामिल है।
• पारिस्थितिकी तंत्र को समझना: और यहां तक ​​कि अगर एक पृष्ठभूमि के साथ भी, तो अक्सर डेवलपर्स विषय में गहराई से डूबे नहीं होते हैं और स्मार्ट अनुबंधों की बारीकियों को नहीं समझते हैं।
• विकास लागत: और फिर भी, जो स्मार्ट अनुबंध लिखते हैं, वे कम हैं; इससे भी कम जो उन्हें अच्छी तरह से लिखते हैं। इसलिए विकास की अनुचित उच्च लागत।

3. भाषा में समस्या

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

• मल्टीपल इनहेरिटेंस, call / delegate call using for - यह सब वर्तमान स्रोत से नहीं कोड शुरू होता है, जिसका अर्थ है कि यह पठनीयता को कम करता है और परिणामस्वरूप, कोड सुरक्षा।
• चेक्स-इफेक्ट्स-इंटरैक्शन पैटर्न - अगर CEI का उल्लंघन करने वाले निर्माण असुरक्षित हैं, तो उन्हें (और कई अन्य) भाषा स्तर पर ही क्यों नहीं प्रतिबंधित किया जाए?
• किसी अन्य अनुबंध को कॉल करके, आप अनपेक्षित परिणामों के साथ अचानक इसके पतन समारोह में गिर सकते हैं।

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

4. अवधारणा में समस्याएं

हालाँकि, सबसे गंभीर समस्या और भी गहरी है - कि बहुत से लोग इस बात को अच्छी तरह से समझ नहीं पाते हैं कि स्मार्ट कॉन्ट्रैक्ट्स की आवश्यकता क्यों है, वे क्या कर सकते हैं, वे क्या नहीं कर सकते हैं और कैसे काम करते हैं। सबसे खराब स्थिति में, यह इस तथ्य की ओर जाता है कि स्मार्ट अनुबंध:

1. स्मार्ट नहीं:

   
   
   • खराब रूप से लिखा गया है - जो लिखा गया है वह है, लेकिन जो इरादा नहीं है।
   • यह दृढ़ता से बैकएंड और / या फ्रंटेंड से जुड़ा हुआ है - और यह कोड अब एक स्मार्ट अनुबंध नहीं है, इसे सामान्य तरीके से निष्पादित किया जाता है, और इसके कार्यान्वयन को सर्वर व्यवस्थापक द्वारा पूरी तरह से नियंत्रित किया जाता है।
   
   

2. अनुबंध नहीं:

   
   
   • यह पार्टियों के दायित्वों को रिकॉर्ड नहीं करता है - उदाहरण के लिए, ICO ETH के लिए अपने टोकन बेचता है, लेकिन टोकन अनिवार्य रूप से कैंडी रैपर हैं, क्योंकि उन्हें जारी करने वाले पर किसी तरह का प्रतिबंध या दायित्व न थोपें।
   • एक तरफा परिवर्तन की अनुमति देता है - और यह पता चलता है कि पार्टियों में से एक अपने हस्ताक्षर के बाद अनुबंध को बदल सकता है।
     
     जीवन उदाहरण : अनुबंध का मालिक मनमाने ढंग से टोकन बिक्री के पूंजीकरण, दर और अवधि को बदल सकता है:
     
     
   
   

3. जरूरत नहीं:

   
   
   • स्मार्ट कॉन्ट्रैक्ट इसलिए नहीं जोड़ा गया क्योंकि यह तकनीकी रूप से आवश्यक था, लेकिन यह पता लगाने की कोशिश में कि स्मार्ट कॉन्ट्रैक्ट पर क्या करना है और प्रचार की लहर की सवारी करना;
   • हमने यह पता लगाने की कोशिश की कि मौजूदा उत्पाद के लिए स्मार्ट अनुबंधों को कैसे टाई जाए।
     
     
   
   

ब्लॉकचैन स्टार्टअप के लिए सुरक्षा खतरे के रूप में स्मार्ट अनुबंध

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

सुरक्षित स्मार्ट अनुबंध कैसे लिखें

वास्तव में, निश्चित रूप से, सब कुछ इतना बुरा नहीं है। मैं अपनी राय में, कुछ महत्वपूर्ण बातों पर ध्यान आकर्षित करने के प्रयास में अतिशयोक्ति करता हूं। सामान्य तौर पर, क्षेत्र विकसित हो रहा है, लोग सीख रहे हैं, जिसमें सुरक्षा भी शामिल है।

अगर पाठक एक स्मार्ट अनुबंध लिखने का फैसला करता है, तो मैं सलाह दूंगा:

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

इन सरल अनुशंसाओं के बाद, आप ऊपर वर्णित अधिकांश समस्याओं से बच सकते हैं (एक कठिन कांटा से, हालांकि, यह अभी भी नहीं बचाएगा)।

लेख यूजीन मार्चेंको ( eMarchenko ) के साथ मिलकर बनाया गया था।