एक smart contract audit ब्लॉकचेन सुरक्षा विशेषज्ञों द्वारा की जाने वाली एक समीक्षा (review) है, जो यह सुनिश्चित करती है कि किसी खराबी (malfunction) या सुरक्षा भेद्यता (security vulnerability) के कारण उपयोगकर्ताओं का फंड न डूबे। इसके अलावा, एक audit यह प्रयास करता है कि contract के deploy होने से पहले किसी भी अप्रत्याशित (unexpected) और अवांछनीय (undesirable) smart contract व्यवहार का अनुमान लगाया जा सके।

इस क्षेत्र को समझना थोड़ा मुश्किल है। दर्जनों audit firms हैं, और उनमें से कई से quotes प्राप्त करने में समय लगता है, और यह जानना कठिन होता है कि आपको उचित कीमत (fair price) मिल रही है या नहीं।

यह लेख एक smart contract audit प्राप्त करने के कार्य को समझने के लिए एक प्रारंभिक बिंदु (starting point) के रूप में काम करेगा।

इस लेख में auditing firms के संदर्भों को समर्थन (endorsement) के रूप में नहीं लिया जाना चाहिए।

Smart contract audit के लिए कोई आधिकारिक मानक (official standard) नहीं है

और उद्योग जिस तेजी से आगे बढ़ रहा है, उसे देखते हुए संभवतः निकट भविष्य में ऐसा कोई मानक होगा भी नहीं।

“Smart contract audit” शब्द उद्योग की शब्दावली (industry lingo) का एक विकास है, इसकी कोई सख्त परिभाषा (rigorous definition) नहीं है, और अलग-अलग लोगों के लिए इसके अलग-अलग अर्थ हो सकते हैं।

उन उद्योगों से आने वालों के लिए जहां ISO standards मानदंड (norm) हैं, smart contract auditing एक ‘wild west’ जैसा लगेगा (और सच कहूं तो, यह एक सटीक आकलन होगा)।

हालांकि कुछ smart contract vulnerabilities सर्वविदित हैं, अन्य जटिल प्रणालियों (complex systems) के उभरते हुए गुण (emergent properties) हैं और उन्हें व्यवस्थित रूप से खोजना कठिन है।

मानक (Standards) परिपक्व बाजारों (mature markets) की विशेषता होते हैं, और कुल मिलाकर web3 एक परिपक्व बाजार नहीं है।

Smart contract audits को “audits” कहना शब्दों का थोड़ा घालमेल (conflation) है। अकाउंटिंग के क्षेत्र में, “audit” की बहुत सख्त परिभाषा होती है; लेकिन blockchain इंजीनियरिंग में ऐसा नहीं है। ब्लॉकचेन में जिसे “audit” कहा जाता है, वह वास्तव में विशेषज्ञों की एक टीम द्वारा किया गया एक सुरक्षा समीक्षा (security review) होता है।

जो बात इसे और भी भ्रमित करने वाली बनाती है वह यह है कि smart contracts में किसी को auditor या सुरक्षा विशेषज्ञ (security expert) मानने की कोई औपचारिक परिभाषा या प्रमाणन (certification) नहीं है। हां, ऐसी कंपनियां हैं जो certifications बेच रही हैं, लेकिन इन certifications का उद्योग में कोई महत्व नहीं है।

जैसा कि आप उम्मीद कर सकते हैं, कई उद्यमशील व्यक्ति इस भ्रम का फायदा उठाकर ऐसी विशेषज्ञता (expertise) बेच रहे हैं जो उनके पास है ही नहीं — क्योंकि विशेषज्ञता को मापने का कोई स्थापित तरीका नहीं है।

Caveat emptor (क्रेता सावधान रहें)।

इन सबके बावजूद, उद्योग में व्यापक रूप से इस बात पर सहमति है कि “इस smart contract को audit किया गया है” कहने का मतलब है “सुरक्षा विशेषज्ञों के एक समूह को इस codebase की समीक्षा करने और कमियां खोजने के लिए भुगतान किया गया था।” चूंकि विशेषज्ञता की कोई औपचारिक परिभाषा नहीं है, इसलिए अक्सर उद्योग में प्रतिष्ठा (reputation) का उपयोग एक मानक (proxy) के रूप में किया जाता है।

Auditors के तीन मुख्य प्रकार

Smart Contract Audit Companies

ये ऐसी फर्म हैं जो सुरक्षा शोध (security research) में विशेषज्ञ हैं। कुछ केवल smart contracts का audit करती हैं, जबकि अन्य smart contracts और पारंपरिक कंप्यूटर एप्लिकेशन दोनों का audit करती हैं। आप इसे सुरक्षा शोधकर्ताओं (security researchers) से बनी एक एजेंसी के रूप में सोच सकते हैं। हाल तक, smart contract audit प्राप्त करने का यही मानक तरीका था। यदि आप smart contract auditing companies के लिए Google खोज करते हैं, तो आपको आमतौर पर इसी तरह के परिणाम मिलेंगे।

Independent security researchers

किसी कंपनी से जुड़ने के बजाय, कुछ security researchers स्वतंत्र रूप से (अपने लिए) काम करते हैं। उन्हें ढूंढना थोड़ा कठिन होता है क्योंकि एजेंसियों की तुलना में उनका मार्केटिंग बजट बहुत कम होता है, लेकिन चूंकि उनके पास कम ओवरहेड (overhead) होता है, वे अक्सर बेहतर कीमतें (better prices) प्रदान कर सकते हैं।

इसका एक नुकसान (drawback) यह है कि एक फर्म के पास आपके कोड की समीक्षा करने के लिए कई auditors हो सकते हैं, जबकि एक independent auditor के पास केवल एक reviewer होगा। लेकिन छोटे या कम जटिल codebases के लिए, यह अधिक किफ़ायती (cost-effective) हो सकता है।

Competitive audits

हाल ही में, कुछ प्लेटफ़ॉर्म (Code4rena, Sherlock DeFi) सामने आए हैं जहां audit का अनुरोध करने वाली कंपनियां एक मौद्रिक पुरस्कार पूल (monetary prize pool) के साथ प्लेटफ़ॉर्म पर अपना source code प्रकाशित करती हैं, और फिर स्वतंत्र प्रतियोगी (independent contestants) bugs और vulnerabilities खोजने का प्रयास करते हैं।

एक प्रतियोगी जितने अधिक bugs ढूंढता है, वह उतना ही अधिक पैसा कमाएगा, लेकिन यदि कोई दूसरा प्रतियोगी भी वही bug ढूंढ लेता है, तो भुगतान दोनों के बीच विभाजित (diluted) हो जाता है। अच्छी तरह से ज्ञात bugs के लिए, भुगतान काफी कम (diluted) हो सकता है।

इस प्रारूप में auditors की कमाई काफी औसत से कम (sub-par) होती है। प्रतियोगी काफी प्रयास करने के बावजूद शायद ही कभी प्रति प्रतियोगिता $1,000 से अधिक कमाने की उम्मीद कर सकते हैं। प्रतिभागियों के लिए प्राथमिक प्रोत्साहन (primary incentive) अपनी क्षमताओं को साबित करना होता है ताकि वे एक पारंपरिक audit फर्म में नौकरी पा सकें या एक solo auditor (independent researcher) के रूप में व्यवसाय आकर्षित कर सकें। प्रतियोगिता में भाग लेने वाले लोगों की गुणवत्ता के बारे में कोई गारंटी नहीं होती है, क्योंकि इसमें कोई भी भाग ले सकता है।

हालाँकि, ये प्लेटफ़ॉर्म नए auditors के लिए बहुत शिक्षाप्रद (educational) हो सकते हैं। क्योंकि यह प्रारूप bugs खोजने पर गहन ध्यान केंद्रित करने को प्रोत्साहित करता है, और फिर इस बात पर प्रतिक्रिया (feedback) देता है कि कौन से bugs छूट गए थे, वे एक अपेक्षाकृत कड़ा (tight) feedback loop प्रदान कर सकते हैं जो सीखने की गति को बढ़ाने में मदद करता है। वास्तव में, हम अपने कुछ solidity bootcamp छात्रों को शैक्षिक उद्देश्यों के लिए इन प्रतियोगिताओं में भाग लेने के लिए मार्गदर्शन करते हैं।

सबसे अच्छे auditors प्रतियोगिताओं में ज्यादा समय नहीं बिताते हैं, क्योंकि वे अपने लिए या किसी फर्म के लिए काम करके कहीं अधिक पैसा कमाते हैं। इसलिए ध्यान रखें कि auditing प्रतियोगिता में अच्छा प्रदर्शन करने वाले किसी व्यक्ति का सीधा सा मतलब यह हो सकता है कि जिन प्रतियोगिताओं में उन्होंने भाग लिया, वहां उन्हें महत्वपूर्ण प्रतिस्पर्धा (competition) का सामना नहीं करना पड़ा। इसमें किस्मत (luck) का भी एक तत्व होता है जहां एक ही प्रतियोगिता किसी auditor की सार्वजनिक कमाई का एक महत्वपूर्ण हिस्सा बन जाती है। हालाँकि, इस प्रारूप में अन्य audit प्रारूपों की तुलना में कोड पर कई अधिक नज़रें होती हैं, और audit प्रतियोगिताओं ने ऐसे bugs पकड़े हैं जो अन्य auditors द्वारा छूट गए थे। वे कंपनियों के लिए डेवलपर और auditor समुदायों में अपने protocols को सूक्ष्मता से (subtly) मार्केट करने के एक चैनल के रूप में भी काम करते हैं, इसलिए वे इकोसिस्टम में एक मूल्यवान योगदान (valuable contribution) हैं।

Bonus: Informal code roasting

कुछ डेवलपर discord समूह आपके कोड की मुफ्त में समीक्षा करेंगे (मददगार होने की इच्छा से, इसलिए कृपया दूसरों की उदारता का दुरुपयोग न करें)। यदि आपके पास एक छोटा और सरल codebase है, तो कभी-कभी कुछ विशेषज्ञों से अपना समय दान करने के लिए कहना आपके लिए सबसे किफ़ायती मार्ग हो सकता है। इस तरह के रिव्यू को “audit” कहना अत्यधिक कपटपूर्ण (disingenuous) होगा, लेकिन अगर यही एकमात्र विकल्प उपलब्ध है, तो यह बिल्कुल भी समीक्षा न होने से निश्चित रूप से बेहतर है।

Smart contract audits में किन बातों का ध्यान रखें

फर्म के पिछले audits देखें

कुछ auditors smart contract vulnerabilities की सूची के लिए एक कठोर चेकलिस्ट (rigid checklist) का उपयोग करते हैं और जांचते हैं कि कोई समस्या मौजूद है या नहीं। यह एक पहले चरण (first pass) के रूप में तो अच्छा है, लेकिन कई bugs एप्लिकेशन-विशिष्ट (application-specific) होते हैं (जैसा कि हम उस लेख में नोट करते हैं)। आप यह सुनिश्चित करना चाहते हैं कि auditor आपके एप्लिकेशन की बारीकियों (nuances) और व्यावसायिक आवश्यकताओं (business requirements) पर विचार करेगा। उनके पिछले audits को देखकर, आप यह समझ सकते हैं कि क्या वे यंत्रवत् (mechanically) केवल एक सूची की जाँच करते हैं या आपके एप्लिकेशन की विशिष्टताओं में गहराई से उतरते हैं। एक auditor जो पिछले audits प्रदान नहीं करता है, वह आमतौर पर एक खतरे का संकेत (red flag) है।

Auditor specialization

यदि आपका प्रोजेक्ट विशेष DeFi tokenomics या Zero Knowledge Proofs का उपयोग करता है, तो आप यह सुनिश्चित करना चाहेंगे कि आपके चयनित auditor को इसका अनुभव हो। इसी तरह, यदि आप Solana जैसी गैर-EVM (non-evm) संगत चेन पर एक dapp बना रहे हैं, तो आपको उस ब्लॉकचेन में अनुभवी auditor की आवश्यकता होगी।

न्यूनतम लागत (Minimum cost)

कुछ audit फर्म छोटे codebases जैसे ERC20 टोकन या बुनियादी NFT पर ध्यान नहीं देंगी क्योंकि वे सेल्स कॉल (sales call) और अकाउंट मैनेजमेंट (account management) का खर्च उठाने के लिए पर्याप्त पैसा नहीं बना पाएंगी।

Rubber stamp auditors

चूँकि audit की कोई औपचारिक या स्वीकृत परिभाषा नहीं है, इसलिए कुछ ऐसी फर्में सामने आई हैं जो व्यंग्यात्मक रूप से “rubber stamp audits” पैदा करती हैं। ये फर्म केवल इसलिए audit रिपोर्ट प्रदान करती हैं क्योंकि खरीदार को एक audit चाहिए था ताकि वे अपने ग्राहकों से कह सकें, “देखो, हमारा audit हो गया है!”

हर protocol जानबूझकर rubber stamp audits नहीं करवाता है; हो सकता है कि उन्होंने अनजाने में उस auditor को चुन लिया हो जो rubber stamp auditors हैं।

Smart contract audits कितने विश्वसनीय (reliable) होते हैं?

यदि किसी smart contract का audit हो भी जाता है, तो भी वह बाद में हैक हो सकता है; यह कोई दुर्लभ घटना (rare occurrence) नहीं है।

Rekt.news का एक leaderboard है जो गंवाए गए धन की मात्रा के अनुसार smart contract हैक्स को ट्रैक करता है। यह देखना आसान है कि हैक किए गए अधिकांश protocols का बिल्कुल भी audit नहीं किया गया था।

हालाँकि, कुछ protocols के audits हुए थे, कुछ के एक से अधिक, फिर भी auditors ने कमियां छोड़ दीं। कुछ मामलों में, ऐसा इसलिए हो सकता है क्योंकि auditors अक्षम (incompetent) थे या उन्होंने पर्याप्त प्रयास नहीं किया, लेकिन सामान्य तौर पर, यह गारंटी देना संभव नहीं है कि कोई codebase बग-मुक्त (free of bugs) है।

अच्छी खबर यह है कि कुछ vulnerabilities केवल auditors से ही नहीं छूटती हैं; वे हैकर्स से भी छूट जाती हैं। कुछ smart contracts पैच (patch) होने से पहले एक सक्रिय भेद्यता (live vulnerability) के साथ महीनों तक चलते रहे। एक अच्छा audit यह सुनिश्चित करेगा कि हैकर्स के लिए “low-hanging fruit” (आसानी से मिलने वाले अवसर) को समाप्त कर दिया जाए।

क्या मुझे कई (multiple) audits करवाने चाहिए?

यह उन अच्छी तरह से वित्त पोषित (well-funded) DeFi protocols के साथ एक मानक अभ्यास (standard practice) है जो बहुत सारा पैसा रखने का इरादा रखते हैं; तीन या अधिक audit फर्मों से कोड की समीक्षा करवाना काफी सामान्य है।

जो एक auditor से छूट जाता है, दूसरा उसे पकड़ सकता है, और इसके विपरीत (vice versa)। इसी तरह, एक auditor को किसी vulnerability का पता चल सकता है, और डेवलपर्स उस vulnerability को पैच करते समय एक नई vulnerability पेश कर सकते हैं।

Audit प्राप्त करने का सामान्य वर्कफ़्लो (Workflow)

1. Quotes प्राप्त करें
आप विभिन्न फर्मों से संपर्क करके quotes मांगेंगे, और आप उनकी उपलब्धता और अपनी लॉन्च तिथियों के आधार पर समन्वय (coordinate) करेंगे।

2. Audit शुरू होता है
जब आप audit के लिए जाते हैं तो आपको एक code freeze में होना चाहिए। यदि auditors उस codebase से भिन्न codebase की समीक्षा कर रहे हैं जिसे आप प्रोडक्शन (prod) में लॉन्च करेंगे, तो आप शायद पैसे बर्बाद कर रहे हैं!

3. Audit रिपोर्ट
अधिकांश audit रिपोर्ट्स (जो एक निश्चित चेकलिस्ट का पालन नहीं करती हैं) Critical, High, Medium, Low, Informational, और Gas Optimization के रूप में वर्गीकृत निष्कर्षों (findings) की एक सूची वापस करेंगी। इन्हें अगले भाग में समझाया गया है। प्रोजेक्ट के दायरे (scope) के आधार पर, एक audit कुछ दिनों से लेकर कुछ महीनों तक का हो सकता है।

4. फिक्सेस की समीक्षा (Review fixes)
समझौते (agreement) के आधार पर, auditor डेवलपर्स द्वारा किए गए परिवर्तनों की समीक्षा करेगा और सुनिश्चित करेगा कि फ़िक्स वास्तव में बग का समाधान करता है। संशोधन समीक्षाओं (revision reviews) की संख्या जिसे स्वीकार्य माना जाता है, वह auditor पर निर्भर करती है।

5. रिपोर्ट प्रकाशित करना (Publish Report)
Auditors आम तौर पर अपनी रिपोर्ट प्रकाशित करते हैं यदि ग्राहक अनुमति देता है (और ग्राहक आमतौर पर चाहते हैं कि audit सार्वजनिक हो ताकि यह दिखाया जा सके कि उनका audit किया गया है)।

Audit Finding Severity

अधिकांश audit रिपोर्ट्स सुरक्षा निष्कर्षों (security findings) को गंभीरता (severity) के आधार पर समूहित करती हैं:

• Critical
• High
• Medium
• Low
• Informational
• Gas Optimization

सभी फर्में समान लेबल (labels) का उपयोग नहीं करती हैं। जैसा कि हमने उल्लेख किया है, सार्वभौमिक मानकों (universal standards) की कमी के कारण, “high” या “medium” vulnerability किसे माना जाए, इसके लिए कोई एक समान परिभाषा नहीं है। कुछ auditors एक ही बग को सौंपे जाने वाले उचित रेटिंग के बारे में असहमत होते हैं, लेकिन यहाँ कुछ ऐसे कारक दिए गए हैं जिनका उपयोग auditors गंभीरता (severity) तय करने के लिए करते हैं:

• सबसे खराब स्थिति (Worst case outcome)। सभी फंड चोरी हो जाना विनाशकारी (catastrophic) है। ऐसे bugs जहां हैकर फंड चोरी नहीं कर सकता है, लेकिन उपयोगकर्ताओं को अपनी ही गलती से नुकसान उठाने (shooting themselves in the foot) से पर्याप्त रूप से सुरक्षित नहीं किया गया है, उन्हें low severity के साथ लेबल किया जाएगा।
• प्रभावित उपयोगकर्ताओं की संख्या। पूरे protocol का पैसा खोना एक व्यक्तिगत उपयोगकर्ता के पैसा खोने से अधिक गंभीर है।
• हमले को अंजाम देने का प्रोत्साहन (Incentive)। यदि किसी हमलावर को हमला करने के लिए उससे अधिक पूंजी खर्च करने की आवश्यकता है, जितना उसे इसे पूरा करने से प्राप्त होगा, तो गंभीरता कम हो जाती है। यह अभी भी एक vulnerability है क्योंकि हमलावर का हमला करने का कोई गैर-आर्थिक मकसद हो सकता है (दिखावा करना, व्यक्तिगत दुश्मनी आदि)।
• हमले की अस्पष्टता (Obscurity of the attack)। यदि vulnerability किसी missing access control (पहुंच नियंत्रण की कमी) जैसी है, तो एक अनुभवहीन हमलावर (unsophisticated attacker) हमले को अंजाम दे सकता है। यदि कमज़ोरी उन्नत गणित (advanced mathematics) का उपयोग करने वाले एक परिष्कृत (sophisticated) tokenomics तंत्र की गहरी समझ पर निर्भर करती है, तो इसकी संभावना कम है कि हमलावर को समस्या का पता चलेगा।

कुछ auditors अंतिम दो कारकों को एक में मिला देते हैं: हमले की संभावना (likelihood of an attack)। इस मॉडल के तहत, वे गंभीरता निर्दिष्ट करने के लिए निम्न तालिका (table) का उपयोग करते हैं:

Critical बनाम High बनाम Medium

कुछ auditors critical vulnerabilities और high vulnerabilities के बीच अंतर करते हैं, और अन्य auditors critical vulnerabilities को high vulnerabilities के साथ समूहित (group) करते हैं। दोनों ही मामलों में, इन्हें अत्यंत गंभीर bugs माना जाता है! जो लोग अंतर करते हैं, उनके लिए Critical का मतलब यह हो सकता है कि पूरा protocol गंभीर रूप से प्रभावित है, जबकि High का मतलब है कि व्यक्तिगत उपयोगकर्ता गंभीर रूप से प्रभावित हो सकते हैं।

Medium severity की समस्याओं का आमतौर पर अर्थ ऐसी समस्याएं हैं जो नुकसानदायक हो सकती हैं लेकिन उनके होने की संभावना कम (unlikely to occur) होती है।

Informational

कुछ auditors ऐसी समस्याओं को इंगित (point out) करेंगे, जैसे Solidity स्टाइल गाइड का पालन न करना या variable और function नाम होना जिनकी स्पेलिंग गलत है या जो भ्रामक (misleading) हैं। ये सुरक्षा भेद्यताएं (security vulnerabilities) नहीं हैं, लेकिन भविष्य में भ्रम पैदा कर सकती हैं। सभी auditors informational समस्याओं को इंगित नहीं करते हैं।

Gas Optimization

कुछ auditors smart contract की optimize the gas cost (गैस लागत को अनुकूलित) करने और सुधारने के तरीके सुझाएंगे। ये सुरक्षा से संबंधित नहीं हैं, लेकिन वे निश्चित रूप से उपयोगकर्ता अनुभव (user experience) में सुधार करेंगे।

Smart contract के audit में कितना खर्च आता है?

सार्वजनिक जानकारी के आधार पर अनुमान
यदि आप Fiverr पर देखते हैं, तो आपको कम कीमतों पर smart contracts का audit करने के लिए कुछ सेवाएं मिलेंगी, लेकिन क्या आप वास्तव में इतनी महत्वपूर्ण चीज़ के लिए इस तरह की सेवा पर निर्भर रहना चाहेंगे? क्योंकि contracts में आमतौर पर गैर-प्रकटीकरण समझौते (non-disclosure agreements) होते हैं, इसलिए दरों (rates) का निर्धारण करना कठिन हो सकता है, लेकिन यहाँ कुछ सार्वजनिक जानकारी दी गई है।

1. Competitive audits के लिए इनाम पूल (Reward pools)
Competitive audit प्लेटफॉर्म reward pool का विज्ञापन करते हैं, और निश्चित रूप से, यह पैसा audit के लिए भुगतान करने वाले ग्राहक से आता है। यहां आप पुरस्कार पूल (prize pools) 5k (5 हजार) जितना कम और कभी-कभी बहुत बड़ी परियोजनाओं के लिए सैकड़ों-हजारों डॉलर तक देख सकते हैं। चरम मामलों में, 1 मिलियन डॉलर से अधिक के prize pools भी दिए गए हैं। बेशक, प्रतियोगिता चलाने वाले लोग प्लेटफॉर्म चलाने के लिए शुल्क (fee) की उम्मीद करते हैं, इसलिए वास्तविक लागत अधिक होगी।

2. Contractor salaries (अनुबंधकर्ताओं का वेतन)
Auditing फर्म Spearbit ने उन rates को प्रकाशित किया, जिन पर वे अपने auditors (जो कर्मचारी नहीं, बल्कि contractors हैं) को भुगतान करते हैं, ताकि कोई यह अनुमान लगा सके कि इसके आधार पर audit की लागत कितनी होगी (संचालन और लाभ मार्जिन को छोड़कर)। वरिष्ठता (seniority) के आधार पर प्रति auditor का वेतन 3k से 20k प्रति सप्ताह होता है। ध्यान रखें कि यह एक पूर्णकालिक नौकरी (full time job) नहीं है, बल्कि प्रति-एंगेजमेंट (per-engagement) है।

3. Independent auditors
हमारे पास एक और डेटा पॉइंट independent auditors का है जो अपनी कमाई के बारे में सार्वजनिक रहे हैं। एक दावा करता है कि वह अच्छे महीनों में $40k per month कमाता है, जो प्रति माह लगभग चार audits लेता है, दूसरे ने पांच audits के साथ $50,000 in one month का दावा किया है। यह एक independent auditor की कमाई के उच्च स्तर (high end) पर है, लेकिन यह संभावना के दायरे से बाहर नहीं है; शीर्ष Silicon Valley कंपनियों में स्टाफ इंजीनियर इससे अधिक कमाते हैं।

Auditors quotes कैसे तैयार करते हैं

कोई मानक मूल्य निर्धारण मॉडल (standard pricing model) नहीं है, लेकिन यहां कुछ तरीके (practices) दिए गए हैं जिनका उपयोग auditors उनके द्वारा दी जाने वाली कीमत (quote) निर्धारित करने के लिए करते हैं।

कोड की प्रति पंक्ति डॉलर (Dollars per lines of code)
सबसे आम मूल्य निर्धारण मॉडल $ / lines of code (कोड की पंक्तियां) है। इसकी लागत प्रति लाइन कुछ डॉलर से लेकर दसियों डॉलर के बीच हो सकती है।

आकार और जटिलता (Size and complexity)
अन्य auditors आकार और जटिलता के संयोजन (combination) का उपयोग करते हैं। 1,000 लाइन का NFT एक 1,000 लाइन की गणित लाइब्रेरी की तुलना में काफी सरल होता है। Auditing फर्म इन कारकों के संयोजन के आधार पर एक व्यक्तिपरक निर्णय (subjective judgement) लेगी।

मौजूदा protocols के साथ समानता (Similarity to existing protocols)
कुछ auditors छूट (discount) देंगे यदि audit किया जाने वाला प्रोजेक्ट किसी स्थापित प्रोजेक्ट का फोर्क (forked) है, या उसके बहुत समान है, क्योंकि वे यह निर्धारित करने के लिए पिछले audits का लाभ उठा सकते हैं कि क्या आपके प्रोजेक्ट ने पिछली गलतियों से सीखा है। इसके अलावा, जिन पंक्तियों की समीक्षा नहीं की गई है, उनकी कुल संख्या प्रोजेक्ट का एक छोटा प्रतिशत होती है। स्थापित परियोजनाओं के “समान” (similar) क्या माना जाएगा, इसके लिए विभिन्न auditors की अलग-अलग सीमा (threshold) होगी।

प्रति vulnerability भुगतान (Pay per vulnerability)
यह मॉडल independent auditors के बीच आम है। Security researcher को एक छोटा डाउनपेमेंट (downpayment) दिया जाता है और पाए गए प्रत्येक बग के लिए एक भुगतान (payout) प्राप्त होता है, जिसमें उच्च गंभीरता (higher severity) वाले मुद्दों के लिए उच्च कीमत होती है। इसका फायदा यह है कि यह auditor को अधिक मेहनत से खोजने के लिए प्रोत्साहित (incentivize) करता है, लेकिन यह bugs की गंभीरता को बढ़ा-चढ़ाकर बताने (exaggerating) के लिए भी प्रेरित कर सकता है।

Audits इतने महंगे क्यों हैं?

वकीलों जैसे अन्य अत्यधिक विशिष्ट ज्ञान कार्यकर्ताओं (highly specialized knowledge workers) की तुलना में (जिनमें से सर्वश्रेष्ठ प्रति माह one million dollars per month से अधिक कमा सकते हैं), smart contract audits अत्यधिक महंगे (prohibitively expensive) नहीं हैं, लेकिन वे छोटी कंपनियों के लिए एक महत्वपूर्ण बोझ (significant burden) हो सकते हैं।
एक smart contract auditor बनना आसान नहीं है। आम तौर पर, आवश्यक कौशल स्तर (skill level) सिलिकॉन वैली (Silicon Valley) में अत्यधिक प्रतिस्पर्धी नौकरी पाने की कोशिश करने के बराबर होता है, जिसका अर्थ है कि शुरुआती वेतन आसानी से छह-आंकड़ों (six-figure) के क्षेत्र में होने वाला है। लाभदायक (profitable) बने रहने के लिए एक auditing फर्म को उन वेतन के ऊपर एक महत्वपूर्ण मार्जिन (margin) वसूलने की आवश्यकता होती है, इसलिए यह आश्चर्यजनक नहीं होना चाहिए कि audits की लागत हजारों डॉलर, या यहां तक कि सैकड़ों हजारों डॉलर भी हो सकती है।

पहले अपने कोड का परीक्षण (Test) करें!

आश्चर्यजनक संख्या में smart contracts को अपर्याप्त unit testing के साथ audits के लिए भेजा जाता है। मूर्खतापूर्ण bugs होने से auditor का समय अधिक गंभीर bugs खोजने के बजाय बर्बाद (saps up) हो जाता है, इसलिए अपने contract को बग-मुक्त सुनिश्चित करने के लिए अपने निपटान (disposal) में मौजूद प्रत्येक परीक्षण और smart contract सुरक्षा उपकरण (security tool) का उपयोग करें।

क्या आप RareSkills से मदद चाहते हैं?

RareSkills एक auditing फर्म नहीं है, लेकिन हमारे कई instructors पेशेवर auditors हैं, और हम security research में संलग्न (engage) हैं। हमारे पास एक अंदरूनी दृष्टिकोण (insider view) है कि कौन सी फर्में प्रतिष्ठित (reputable) हैं और कौन सी नहीं। अपनी ज़रूरतों के बारे में बताने के लिए बेझिझक हमसे contact us (संपर्क करें), और हम आपकी स्थिति के आधार पर आपको सही संसाधन (resource) का संदर्भ (refer) देंगे।

यदि आप अपने इंजीनियरों को यह प्रशिक्षित करना चाहते हैं कि सुरक्षित smart contracts कैसे विकसित किए जाएं, तो पेशेवर इंजीनियरों के लिए हमारा उद्योग-अग्रणी (industry-leading) smart contract bootcamp आपके लिए रुचिकर हो सकता है।

मूल रूप से 24 जून, 2023 को प्रकाशित