इकाइयाँ
1. ब्लॉकचेन और वेब3 में आर्टिफिशियल इंटेलिजेंस का परिचय: भूमिकाएँ, सीमाएँ, प्रमाणीकरण और सुरक्षा-महत्वपूर्णता 2. स्मार्ट कॉन्ट्रैक्ट राइटिंग सपोर्ट: सॉलिडिटी/वाइपर ड्राफ्ट और सिक्योर कोड जेनरेशन 3. स्मार्ट कॉन्ट्रैक्ट ऑडिट सपोर्ट: सुरक्षा समीक्षा और ड्राफ्ट निष्कर्ष 4. भेद्यता स्कैनिंग: सामान्य भेद्यता पैटर्न और स्वचालित विश्लेषण 5. ऑन-चेन डेटा विश्लेषण: ब्लॉक, लेनदेन और वॉलेट डेटा की समझ बनाना 6. डेफी और प्रोटोकॉल विश्लेषण: तरलता, एमईवी और आर्थिक हमले 7. टोकनोमिक मॉडलिंग: आपूर्ति, वितरण, प्रोत्साहन और सिमुलेशन 8. दस्तावेज़ीकरण और तकनीकी लेखन: श्वेतपत्र, नेटस्पेक और उपयोगकर्ता गाइड 9. धोखाधड़ी, रग-पुल और जोखिम का पता लगाना: ऑन-चेन रेड फ्लैग 10. सुरक्षा-महत्वपूर्ण ऑडिट, विशेषज्ञ अनुमोदन और जिम्मेदार उपयोग 11. शुरू से अंत तक कार्यप्रवाह, शासन, सत्यापन और नैतिकता
इकाई 3 / 11

स्मार्ट कॉन्ट्रैक्ट ऑडिट सपोर्ट: सुरक्षा समीक्षा और ड्राफ्ट निष्कर्ष

लाभ:

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

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

ऑडिटिंग सुरक्षा-महत्वपूर्ण क्यों है?

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

यह पास क्यों नहीं होता? क्योंकि:

  • AI उस अद्वितीय/नई भेद्यता को नहीं देख सकता जो प्रशिक्षण डेटा में नहीं है।
  • एआई अक्सर प्रोटोकॉल के व्यावसायिक तर्क में दोष को नजरअंदाज कर देता है - कि कोड तकनीकी रूप से सही है लेकिन आर्थिक रूप से शोषण योग्य है।
  • एआई धाराप्रवाह भाषा में "सुरक्षित" कहकर झूठा आश्वासन दे सकता है; यह सबसे खतरनाक परिणाम है.

नियंत्रण में एआई के उपयोग की परतें

1. प्रारंभिक स्कैन और पैटर्न अनुस्मारक। एआई एक चेकलिस्ट की तरह ज्ञात भेद्यता पैटर्न से गुजरता है: पुनर्प्रवेश, पहुंच नियंत्रण, ओरेकल हेरफेर, फ्रंट-रनिंग। यह सुनिश्चित करता है कि ऑडिटर कोई भी श्रेणी न चूके।

2. कोड स्पष्टीकरण. एआई को एक जटिल कार्य को सरल भाषा में समझाने से ऑडिटर को तर्क को जल्दी से समझने की अनुमति मिलती है; लेकिन विवरण की तुलना हमेशा कोड से की जाती है।

3. निष्कर्षों का मसौदा लिखना। जब ऑडिटर को कोई भेद्यता मिलती है, तो एआई रिपोर्ट का मसौदा (विवरण, प्रभाव, प्रस्तावित समाधान) लिखने में समय बचाता है।

4. प्रति-परिकल्पना उत्पन्न करना। एआई से पूछें "इस फ़ंक्शन का दुरुपयोग कैसे किया जा सकता है?" "पूछना" हमें आक्रामक दृष्टिकोण की याद दिलाता है।

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

गंभीरता के स्तर का पता लगाना

ऑडिट निष्कर्षों को उनकी गंभीरता के स्तर के अनुसार वर्गीकृत किया जाता है। ड्राफ्ट बनाते समय AI को इस ढांचे का उपयोग करना चाहिए:

स्तर

मतलब

उदाहरण

आलोचनात्मक

सीधे तौर पर धन हानि/तालाबंदी संभव

पुनर्प्रवेश के साथ धनराशि निकालना

उच्च

कुछ स्थितियों में गंभीर प्रभाव

अनधिकृत मुद्रण (टकसाल)

मध्यम

सीमित प्रभाव या कठिन परिस्थिति

Oracle विचलन के साथ छोटा नुकसान

कम

मामूली जोखिम, अच्छे अभ्यास का उल्लंघन

अनुपलब्ध घटना प्रसारण

जानकारी

गैर-सुरक्षा, पठनीयता

नेटस्पेक का अभाव

कमजोर संकेत/मजबूत संकेत

कमजोर संकेत:

क्या यह अनुबंध सुरक्षित है?

यह प्रश्न एआई को "हां/नहीं" जैसे पूर्ण, अनुचित निर्णय लेने के लिए मजबूर करता है - बिल्कुल वही जो हम नहीं चाहते हैं।

शक्तिशाली संकेत:

आपकी भूमिका: वरिष्ठ स्मार्ट अनुबंध लेखा परीक्षक के सहायक। सुरक्षा के लिए निम्नलिखित अनुबंध को स्कैन करें। निम्नलिखित श्रेणियों को एक-एक करके देखें: पुनर्प्रवेश, अभिगम नियंत्रण, पूर्णांक संचालन, इनपुट सत्यापन, ऑरेकल/बाहरी डेटा, फ्रंट-रनिंग, गैस सीमा। प्रत्येक खोज के लिए: (1) कोड की प्रासंगिक पंक्ति, (2) जोखिम का कारण, (3) अनुमानित गंभीरता (गंभीर/उच्च/मध्यम/निम्न), (4) समाधान प्रस्ताव। ये ऐसी परिकल्पनाएँ हैं जिनकी पुष्टि की जानी चाहिए; "सुरक्षित" फैसला न दें. उन क्षेत्रों को चिह्नित करें जिनके बारे में आप स्पष्ट रूप से "ऑडिटर को पुष्टि करने दें" कहने के बारे में निश्चित नहीं हैं।

चार प्रतिलिपि योग्य टेम्पलेट

1) श्रेणी आधारित ब्राउज़िंग:

निम्नलिखित श्रेणियों के लिए इस अनुबंध को स्कैन करें: पुनर्प्रवेश, अभिगम नियंत्रण, पूर्णांक अतिप्रवाह, इनपुट सत्यापन, ओरेकल निर्भरता, फ्रंट-रनिंग, DoS/गैस। प्रत्येक श्रेणी के लिए, कहें "वहाँ कोई जोखिम नहीं है/मुझे यकीन नहीं है" और अपने औचित्य को कोड की पंक्ति से जोड़ें। अंतिम निर्णय न लें.

2) हमलावर के दृष्टिकोण से प्रति-परिकल्पना:

एक हमलावर की तरह सोचें: इस फ़ंक्शन का दुरुपयोग करने के तरीके क्या हैं? प्रत्येक परिदृश्य को चरण दर चरण लिखें और बताएं कि किन स्थितियों की आवश्यकता है। ये परिदृश्य परीक्षण की जाने वाली परिकल्पनाएँ हैं; वास्तविक शोषण कोड उत्पन्न न करें, केवल जोखिम का वर्णन करें।

3) मसौदा निष्कर्ष रिपोर्ट:

औपचारिक ऑडिट भाषा में निम्नलिखित सत्यापित निष्कर्ष की रिपोर्ट करें: शीर्षक, गंभीरता, विवरण, प्रभाव, प्रभावित कोड, पुनरुत्पादन के चरण, प्रस्तावित समाधान। नपी-तुली और तकनीकी भाषा का प्रयोग करें; अतिशयोक्ति. मान लें कि ऑडिटर ने निष्कर्ष की पुष्टि कर दी है, कोई नया निष्कर्ष न निकालें।

4) सत्यापन ठीक करें:

नीचे एक भेद्यता और डेवलपर द्वारा लागू समाधान दिया गया है। जांच करें कि क्या सुधार वास्तव में भेद्यता को बंद करता है; चिह्नित करें कि क्या यह कोई नया दुष्प्रभाव या भेद्यता पैदा करता है। निश्चित रूप से "बंद" मत कहें; "परीक्षण द्वारा पुष्टि की जानी चाहिए" के साथ समाप्त करें।

तीन मिनी केस (संख्या में)

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

केस 2 - झूठा "सुरक्षित" आश्वासन। एक अन्य टीम ने एआई से पूछा "क्या यह सुरक्षित है?" उसने पूछा; एआई ने कहा, "कोई खास समस्या नहीं दिखती।" चालक दल का निरीक्षण हल्का था। तब स्वतंत्र लेखा परीक्षक को एक व्यवसाय-तर्क दोष मिला: एक गणना जो तकनीकी रूप से सही थी लेकिन जिसके प्रोत्साहन शोषण योग्य थे। पाठ: AI व्यावसायिक तर्क त्रुटि को भूल जाता है; उसे "सुरक्षित" कहने पर भरोसा नहीं किया जा सकता।

केस 3 - रिपोर्ट का मसौदा तैयार करने में 3 घंटे की बचत हुई। ऑडिटर आधा दिन मैन्युअल रूप से 8 निष्कर्षों की रिपोर्ट करने में बिता रहा था। एक बार जब मैंने एआई को सत्यापित निष्कर्ष दिए और आधिकारिक मसौदा मुद्रित किया, तो समय ~3 घंटे कम हो गया; ऑडिटर ने गहनता के लिए समय समर्पित किया। पाठ: एआई रिपोर्टिंग में सुरक्षित और कुशल है क्योंकि निष्कर्षों को पहले ही मानवीय रूप से सत्यापित किया जा चुका है।

व्यावसायिक तर्क भेद्यता: एआई का अंध स्थान

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

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

सामान्य गलतियाँ

  • एआई से पूछें "क्या यह सुरक्षित है?" पूछना और अपनी हाँ पर भरोसा करना। पूर्ण निर्णय की आवश्यकता नहीं है.
  • जब एआई कहता है "मुझे यह नहीं मिला" तो समीक्षा रोक देना। अनुपस्थिति साक्ष्य नहीं है.
  • एआई को व्यावसायिक तर्क समीक्षा सौंपना। यह उसका सबसे बड़ा ब्लाइंड स्पॉट है।
  • स्वतंत्र उपकरणों (स्लाइदर आदि) का उपयोग न करना। अकेले AI पर्याप्त नहीं है.
  • एआई द्वारा निकाले गए निष्कर्ष को बिना सत्यापित किए रिपोर्ट में डालना। मतिभ्रम का खतरा.
  • एआई पर नियंत्रण की जिम्मेदारी डालने की कोशिश की जा रही है। जिम्मेदारी विशेषज्ञ की है.

संक्षेप में

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

आवेदन कार्य

एक नमूना अनुबंध खोजें जिसमें ज्ञात भेद्यता शामिल हो (शैक्षणिक उद्देश्यों के लिए, "असुरक्षित अनुबंध" के उदाहरण खुले स्रोत में उपलब्ध हैं)। एआई पर "श्रेणी आधारित स्कैनिंग" संकेत लागू करें। ध्यान दें कि क्या एआई ने: (1) वास्तविक भेद्यता पाई, (2) मनगढ़ंत/झूठे निष्कर्ष निकाले, (3) "सुरक्षित" जैसे पूर्ण निर्णय लिए। फिर इसकी तुलना एक स्थैतिक विश्लेषण उपकरण से करें।

चेकलिस्ट

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