Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

स्मार्ट-कॉन्ट्रैक्ट ऑडिट निर्धारित दायरे में कोड और आर्किटेक्चर की स्वतंत्र समीक्षा है। इसका उद्देश्य कमजोरियों, implementation त्रुटियों तथा अपेक्षित और वास्तविक व्यवहार के अंतर की पहचान करना है।

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

यह लेख केवल शैक्षिक उद्देश्यों के लिए है। ऑडिट सुरक्षा, धन की रिकवरी या प्रतिफल की गारंटी नहीं देता।

दायरा पहले तय होता है

उपयोगी रिपोर्ट स्पष्ट रूप से बताती है कि किसकी समीक्षा की गई:

• repository और commit hash;
• फ़ाइलें और कॉन्ट्रैक्ट;
• compiler संस्करण और build settings;
• निर्भरताएँ;
• आर्किटेक्चर और विशेषाधिकार प्राप्त भूमिकाएँ;
• branch या release;
• बहिष्करण, सीमाएँ और धारणाएँ;
• समीक्षा तिथि।

यह महत्वपूर्ण है क्योंकि वास्तविक ऑडिट पुराने संस्करण, अलग डिप्लॉयमेंट या बड़े सिस्टम के केवल एक हिस्से को कवर कर सकता है।

ऑडिटर सामान्यतः क्या जाँचते हैं

1. अपेक्षित व्यवहार और अपरिवर्तनीय शर्तें

ऑडिटर कोड की उसके specification से तुलना करते हैं:

• प्रत्येक फ़ंक्शन को कौन call कर सकता है;
• राशियाँ और शुल्क कैसे गिने जाते हैं;
• Status में बदलाव कब होते हैं;
• कौन-सी विशेषताएँ हमेशा सत्य रहनी चाहिए;
• edge cases और विफलताओं को कैसे संभाला जाता है।

यदि specification महत्वपूर्ण आवश्यकता छोड़ देता है, तो तकनीकी रूप से सही कोड भी असुरक्षित या अवांछित डिज़ाइन लागू कर सकता है।

2. एक्सेस नियंत्रण

समीक्षक owner, admin, operator और अन्य विशेषाधिकार प्राप्त भूमिकाओं की जाँच करते हैं, जिनमें ये शक्तियाँ शामिल हैं:

• अनुमतियाँ देना या रद्द करना;
• सिस्टम pause करना;
• शुल्क और सीमाएँ बदलना;
• टोकन mint करना;
• एसेट निकालना;
• implementation को upgrade करना।

वे यह भी देखते हैं कि क्या एक कुंजी महत्वपूर्ण बदलाव कर सकती है और क्या multisig या timelock जैसे नियंत्रण डिज़ाइन का हिस्सा हैं।

3. बाहरी कॉल और रीएंट्रेंसी

निष्पादन के दौरान कोई कॉन्ट्रैक्ट नियंत्रण दूसरे कॉन्ट्रैक्ट को दे सकता है। इससे रीएंट्रेंसी संभव हो सकती है, जिसमें मूल state transition पूरा होने से पहले बाहरी कॉन्ट्रैक्ट वापस कॉल करता है। Solidity का आधिकारिक मार्गदर्शन उचित स्थानों पर जाँच, state effects और बाहरी interactions का क्रम सावधानी से तय करने की सलाह देता है।

4. गणनाएँ और इकाइयाँ

ऑडिटर निम्न खोजते हैं:

• rounding और precision का नुकसान;
• टोकन decimals का मेल न होना;
• कार्रवाइयों का गलत क्रम;
• सीमांत मान;
• शून्य से भाग;
• unsafe unchecked arithmetic;
• आंतरिक और प्रदर्शित इकाइयों के बीच अंतर।

5. सेवा-अस्वीकरण और गैस

असीमित loops, बढ़ते arrays, विफल external calls या महँगी कार्रवाइयाँ किसी फ़ंक्शन का निष्पादन अव्यावहारिक बना सकती हैं। समीक्षक जाँचते हैं कि डेटा बढ़ने और असामान्य input पर भी डिज़ाइन उपयोग योग्य रहता है या नहीं।

6. प्रॉक्सी और अपग्रेड

अपग्रेड किए जा सकने वाले सिस्टम में समीक्षा में शामिल होना चाहिए:

• proxy और implementation कॉन्ट्रैक्ट;
• upgrader या admin अधिकार;
• आरंभीकरण;
• storage-layout संगतता;
• अनधिकृत upgrade मार्ग;
• ऑडिट के बाद लॉजिक बदलने का प्रभाव।

प्रॉक्सी नए लॉजिक को कार्य सौंपते हुए उपयोगकर्ता को दिखाई देने वाला पता समान रख सकता है। इसलिए “कॉन्ट्रैक्ट बदल नहीं सकता” जैसे दावे की वास्तविक आर्किटेक्चर के आधार पर जाँच करनी चाहिए।

7. एकीकरण

कॉन्ट्रैक्ट token, price oracle, bridge, DEX, हस्ताक्षर या अन्य कॉन्ट्रैक्ट पर निर्भर हो सकते हैं। ऑडिटर इन निर्भरताओं, पुराने डेटा, असामान्य token व्यवहार और बाहरी विफलता परिस्थितियों से जुड़ी मान्यताओं की जाँच करते हैं।

8. इवेंट और निगरानी

समीक्षक जाँच सकते हैं कि क्या इवेंट भूमिका परिवर्तन, अपग्रेड, pause और ट्रांसफ़र जैसी महत्वपूर्ण कार्रवाइयों को सही तरह दिखाते हैं। इवेंट निगरानी में सहायक हैं, लेकिन वे स्थिति की जाँच का स्थान नहीं लेते।

ऑडिट में उपयोग की जाने वाली विधियाँ

समीक्षा में सामान्यतः ये शामिल होते हैं:

• कोड और आर्किटेक्चर का मैनुअल विश्लेषण;
• unit और integration testing;
• static और dynamic विश्लेषण;
• बनाए गए inputs के साथ fuzzing;
• property-based परीक्षण;
• ज्ञात vulnerability classes की जाँच;
• build और deployment समीक्षा;
• कभी-कभी चुनी गई विशेषताओं का औपचारिक सत्यापन।

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

उपयोगकर्ता को ऑडिट कैसे पढ़ना चाहिए

1. समीक्षा किए गए संस्करण का मिलान करें

Commit hash खोजें और निर्धारित करें:

• क्या वर्तमान implementation उसी कोड से बनाया गया था;
• क्या रिपोर्ट की तारीख के बाद upgrades हुए;
• क्या chain और deployed पते मेल खाते हैं;
• क्या महत्वपूर्ण निर्भरताएँ समीक्षा के दायरे में थीं।

यदि यह स्थापित न हो सके, तो रिपोर्ट सक्रिय deployment के बारे में सीमित प्रमाण देती है।

2. केवल सारांश नहीं, निष्कर्ष भी पढ़ें

हर निष्कर्ष के लिए समीक्षा करें:

• गंभीरता और परिदृश्य;
• प्रभावित कोड;
• अनुशंसा;
• डेवलपर की प्रतिक्रिया;
• वर्तमान Status;
• क्या ऑडिटर ने सुधार का दोबारा परीक्षण किया।

ठीक किया गया या हल हो गया is meaningful only when tied to a specific corrected version.

3. सीमाएँ पढ़ें

रिपोर्ट में ये शामिल न हों:

• frontend और backend सिस्टम;
• कुंजी प्रबंधन;
• आर्थिक डिज़ाइन;
• तृतीय-पक्ष कॉन्ट्रैक्ट;
• deployment बुनियादी ढाँचा;
• production कॉन्फ़िगरेशन;
• कानूनी और परिचालन संबंधी समस्याएँ।

उपयोगकर्ता पूरे सिस्टम से इंटरैक्ट करते हैं, केवल उसकी Solidity फ़ाइलों से नहीं।

4. प्रशासनिक जोखिम की समीक्षा करें

पूछें:

• upgrades को कौन नियंत्रित करता है;
• क्या कार्रवाइयाँ pause की जा सकती हैं;
• क्या शुल्क या जुड़े पते बदल सकते हैं;
• क्या timelock मौजूद है;
• क्या multisig उपयोग होता है;
• उपयोगकर्ताओं को बदलावों की जानकारी कैसे मिलती है।

कोड में कोई ज्ञात कमज़ोरी न मिलने पर भी ये governance और विश्वास से जुड़े प्रश्न हैं।

5. ऑडिट के बाद की सुरक्षा जाँचें

उपयोगी निरंतर उपायों में शामिल हैं:

• हर release का परीक्षण;
• महत्वपूर्ण upgrades की समीक्षा;
• bug-bounty कार्यक्रम;
• भूमिकाओं और implementations की निगरानी;
• incident-response प्रक्रियाएँ;
• जोखिम में आए एसेट की मात्रा सीमित करना।

एक ऑडिट किस बात की गारंटी नहीं देता है

ऑडिट निम्न की गारंटी नहीं देता:

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

सावधान उपयोगकर्ता को पूछे जाने वाले प्रश्न

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

रिपोर्ट चेकलिस्ट

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

स्रोत और आगे पढ़ने की सामग्री

1. Ethereum.org — स्मार्ट कॉन्ट्रैक्ट सुरक्षा
2. Ethereum.org — स्मार्ट कॉन्ट्रैक्ट का परीक्षण
3. Ethereum.org — स्मार्ट कॉन्ट्रैक्ट का औपचारिक सत्यापन
4. Solidity Documentation — सुरक्षा संबंधी विचार
5. OpenZeppelin Docs — Proxy Upgrade Pattern