स्मार्ट अनुबंधों के स्वचालित ऑडिट के लिए गाइड। भाग 1: एक लेखा परीक्षा की तैयारी

परिचय

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

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

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

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

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

स्मार्ट कॉन्ट्रैक्ट कोड ऑडिट की विशेषताएं

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

डेवलपर के दृष्टिकोण से, सॉलिडिटी भी काफी विशिष्ट है, हालांकि पहले चरणों में लगभग किसी भी प्रोग्रामर द्वारा पढ़ना आसान है और बेहद सरल लगता है। सॉलिडिटी कोड को पढ़ना काफी आसान है, यह किसी भी डेवलपर से परिचित है जो सी / सी ++ सिंटैक्स और ओओपी को जानता है, जैसे कि जावास्क्रिप्ट।

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

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

गैस, गैस, गैस

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

यह प्रदर्शित करने के लिए कि आपको गैस का मूल्यांकन करने के लिए बहुत समय क्यों देना है, छद्म कोड के इस टुकड़े पर विचार करें (बेशक, अवास्तविक; ईथर के साथ लूप में फायरिंग एक बुरा विचार है):

//          function fixSomeAccountAction(uint _actionId) public onlyValidator { // … events[msg.sender].push(_actionId); } //   ,           function receivePaymentForSavedActions() { // ... for (uint256 i = 0; i < events[msg.sender].length; i++) { //  actionId   uint actionId = events[msg.sender][i]; //      action uint payment = getPriceByEventId(actionId); if (payment > 0) { paymentAccumulators[msg.sender] += payment; } emit LogEventPaymentForAction(msg.sender, actionId, payment); // … // delete “events[msg.sender][i]” from array } } 

तथ्य यह है कि अनुबंध में चक्र घटनाओं को निष्पादित किया जाता है [msg.sender] .length बार, और प्रत्येक पुनरावृत्ति ब्लॉकचेन (स्थानांतरण () और उत्सर्जन ()) में एक प्रविष्टि है। यदि सरणी की लंबाई छोटी है, तो चक्र अपने दस बार पूरा करता है, प्रत्येक क्रिया के लिए भुगतान वितरित करता है। लेकिन, अगर इवेंट [msg.sender] ऐरे बड़ा है, तो कई पुनरावृत्तियों होंगे और खर्च की गई गैस हार्ड-कोडेड अधिकतम गैस सीमा (~ 8,000,000) में चलेगी। लेन-देन में गिरावट आएगी, और अब कभी काम नहीं करेगा, क्योंकि अनुबंध में घटनाओं [msg.sender] सरणी की लंबाई कम करने का कोई तरीका नहीं है। यदि चक्र केवल एक इकाई मूल्य की गणना नहीं करता है, लेकिन ब्लॉकचेन को लिखता है (उदाहरण के लिए, कुछ कमीशन का भुगतान किया जाता है, कार्यों के लिए भुगतान), तो पुनरावृत्तियों की स्वीकार्य संख्या काफी सीमित है। खुद के लिए जज - सीमा: 8,000,000, एक नया 256-बिट मूल्य रिकॉर्डिंग: 20,000। आप मेटाडाटा को केवल कुछ मेटाडेटा के सैकड़ों-बिट पते के सैकड़ों के लिए बचा सकते हैं या अपडेट कर सकते हैं। एक और मजेदार हिस्सा यह है कि एक नया मूल्य लिखना: 20,000, और मौजूदा एक का अपडेट: 5,000, इसलिए जब आप एक हस्तांतरण करते हैं, तो आपके अनुबंध के सटीक समान वातावरण के साथ भी। एक पते पर टोकन जो पहले से ही टोकन है, आप एक रिकॉर्ड पर 4 गुना कम गैस (5,000 बनाम 20,000) खर्च करते हैं।

इसलिए, आश्चर्यचकित न हों कि स्मार्ट कॉन्ट्रैक्ट्स में गैस का मुद्दा कॉन्ट्रैक्ट्स की सुरक्षा से बहुत निकटता से जुड़ा हुआ है, क्योंकि जिस स्थिति में फंड्स स्थायी रूप से कॉन्ट्रैक्ट के दृष्टिकोण से अटके रहते हैं, वह उस स्थिति से बहुत कम होता है, जब वे चोरी किए गए थे। तथ्य यह है कि ADD निर्देश में 3 गैस की लागत होती है, और SSTORE (संग्रहण में बचत): 20 000 का मतलब है कि ब्लॉकचेन में सबसे महंगा संसाधन भंडारण है, और अनुबंधित कोड के अनुकूलन के कार्यों में एम्बेडेड के लिए C और ASM में निम्न-स्तरीय विकास के कार्य आम हैं। सिस्टम, जहां भंडारण भी एक बहुत ही सीमित संसाधन है।

सुंदर ब्लॉकचेन

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

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

अनुबंध की विधानसभा के लिए वातावरण

लेख लिखने के लिए, मैंने स्मार्टज़ डिज़ाइनर से घर की बुकिंग के लिए एक पुराना प्रायोगिक अनुबंध लिया: https://github.com/smartzplatform/constructor-eth-booking । अनुबंध आपको ऑब्जेक्ट (अपार्टमेंट या होटल के कमरे) का रिकॉर्ड बनाने की अनुमति देता है, कीमत और डिलीवरी की तारीखें निर्धारित करता है, जिसके बाद अनुबंध भुगतान के लिए इंतजार करता है और यदि प्राप्त होता है, तो बुकिंग अधिनियम को ठीक करता है, जब तक कि अतिथि कमरे में प्रवेश नहीं करता है, शेष राशि पर धनराशि रखता है। प्रविष्टि की पुष्टि नहीं करेगा। इस बिंदु पर, कमरे का मालिक भुगतान प्राप्त करता है। अनुबंध अनिवार्य रूप से एक राज्य मशीन है, जिसमें से राज्यों और बदलाव को Booking.sol में देखा जा सकता है। हमने इसे बहुत जल्दी किया, इसे विकास की प्रक्रिया के दौरान बदल दिया और बड़ी संख्या में परीक्षण करने का प्रबंधन नहीं किया, यह संकलक के एक नए संस्करण से दूर है और अधिक या कम समृद्ध आंतरिक तर्क है। तो चलिए देखते हैं कि विश्लेषक कैसे इसके साथ सामना करते हैं, वे क्या त्रुटियां पाएंगे, और यदि आवश्यक हो, तो हम अपना खुद का जोड़ लेंगे।

सोल के विभिन्न संस्करणों के साथ काम करें

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

1 रास्ता: ट्रफल के अंदर

इसके लिए किसी ट्रिक्स की जरूरत नहीं है, क्योंकि ट्रफल संस्करण 5.0.0 से शुरू करके, आप कंपाइलर संस्करण को सीधे truffle.js में निर्दिष्ट कर सकते हैं, जैसा कि इस अंतर में है ।

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

विधि 2: एनालाइज़र डॉकटर कंटेनर में यूएसआर / यूएसआर / बिन / सोल की जगह
यदि विश्लेषक को डॉकरफाइल के रूप में वितरित किया जाता है, तो आप इसे डॉकफाइल में एक पंक्ति जोड़कर एक डॉकटर छवि को इकट्ठा करते हुए प्रतिस्थापित कर सकते हैं जो छवि से सीधे वांछित संस्करण solc प्राप्त करता है, जो इसे नेटवर्क से खींचता है और / usr / bin / solc:

 COPY --from=ethereum/solc:0.4.19 /usr/bin/solc /usr/bin 

3 रास्ता: जगह / usr / बिन / solc

माथे में सबसे गंदा तरीका, अगर कोई रास्ता बिल्कुल भी नहीं है, तो आप इस तरह से स्क्रिप्ट के साथ / usr / bin / solc बाइनरी को सख्ती से बदल सकते हैं (मूल फ़ाइल को सहेजना न भूलें):

 #!/bin/bash # run Solidity compiler of given version, pass all parameters # you can run “SOLC_DOCKER_VERSION=0.4.20 solc --version” SOLC_DOCKER_VERSION="${SOLC_DOCKER_VERSION:-0.4.24}" docker run \ --entrypoint "" \ --tmpfs /tmp \ -v $(pwd):/project \ -v $(pwd)/node_modules:/project/node_modules \ -w /project \ ethereum/solc:$SOLC_DOCKER_VERSION \ /usr/bin/solc \ "$@" 

यह solc के सही संस्करण के साथ solc की छवि को डाउनलोड और कैश करता है, वर्तमान निर्देशिका में जाता है और पास किए गए मापदंडों के साथ /usr/bin/solc चलाता है। बहुत अच्छा तरीका नहीं है, लेकिन शायद कुछ कार्यों के लिए यह आपके अनुरूप होगा।

चपटा कोड

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

ऐसा करने के लिए, नियमित ट्रफल-फ्लैटनर का उपयोग करें।

यह एक मानक npm मॉड्यूल है, इसका उपयोग बहुत ही सरलता से किया जाता है:

 truffle-flattener contracts/Booking.sol > contracts/flattened.sol 

: https://github.com/trailofbits/slither
यदि आपको किसी तरह चपटे को अनुकूलित करने की आवश्यकता है, तो आप अपना स्वयं का फ्लैटनर लिख सकते हैं, उदाहरण के लिए, इससे पहले कि हमने अजगर आधारित विकल्प का उपयोग किया: https://github.com/mixbytes/solidity-flattener

चलो विश्लेषण शुरू करते हैं।

उसी पुराने आदमी के उदाहरण का उपयोग करके, https://github.com/smartzplatform/constructor-eth-booking हम विश्लेषण जारी रखते हैं। अनुबंध संकलक "0.4.20" के पुराने संस्करण को इंगित करता है, और मैंने जानबूझकर संकलक के साथ समस्याओं को हल करने के लिए पुराने अनुबंध को लिया। स्थिति को इस तथ्य से भी बदतर बना दिया जाता है कि उदाहरण के लिए, बायोटेक का अध्ययन करने वाला एक ऑटोइंजीनियर, सोल के इस संस्करण पर निर्भर हो सकता है, और यहां संस्करणों में अंतर परिणामों को बहुत प्रभावित कर सकता है या यहां तक ​​कि सब कुछ तोड़ भी सकता है। यहां तक ​​कि अगर आप नवीनतम संस्करणों का उपयोग करके सब कुछ कर रहे हैं, तो आप अभी भी एक विश्लेषक में चल सकते हैं जिसे कंपाइलर के पिछले संस्करण में ट्यून किया गया है।
संकलन और परीक्षण चल रहा है

आरंभ करने के लिए, बस प्रोजेक्ट को गिटब से खींचें और संकलन करने का प्रयास करें।

 git clone https://github.com/smartzplatform/constructor-eth-booking.git cd constructor-eth-booking npm install truffle compile 

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

भी चलाते हैं

 truffle-flattener contracts/Booking.sol > contracts/flattened.sol 

जैसा कि चपटेपन के बारे में पैराग्राफ में संकेत दिया गया है, यह contracts/flattened.sol हम विभिन्न विश्लेषणकर्ताओं को विश्लेषण के लिए देंगे।
परिचय का निष्कर्ष

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

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

भाग 1. परिचय। संकलन, चपटा, सॉलिडिटी के संस्करण (यह लेख)
भाग 2. खिसकना
भाग 3. मिथक
भाग 4. मटियार
भाग 5. इचिदना
भाग 6. अज्ञात उपकरण 1
भाग 7. अज्ञात उपकरण 2

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

शायद एक विस्तृत अध्ययन की प्रक्रिया में, नए उम्मीदवार विचार के लिए दिखाई देंगे, या लेखों का क्रम बदल जाएगा, इसलिए बने रहें। अगले भाग पर जाने के लिए, "यहाँ क्लिक करें"