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

Smart contract audit হলো নির্ধারিত পরিসরের মধ্যে code ও architecture-এর স্বাধীন পর্যালোচনা। এর উদ্দেশ্য vulnerability, implementation error এবং প্রত্যাশিত ও প্রকৃত আচরণের অমিল শনাক্ত করা।

Audit অনিশ্চয়তা কমাতে পারে, কিন্তু কন্ট্র্যাক্টকে ঝুঁকিমুক্ত করে না। Ethereum-এর সরকারি নিরাপত্তা নির্দেশিকায় audit-কে অতিরিক্ত review বলা হয়েছে, সব bug ধরার অব্যর্থ সমাধান নয়।

এই article শুধু শিক্ষামূলক। Audit নিরাপত্তা, fund recovery বা return নিশ্চিত করে না।

Scope আগে নির্ধারণ করুন

উপযোগী রিপোর্টে ঠিক কী পর্যালোচনা করা হয়েছে তা চিহ্নিত থাকে:

• Repository ও commit hash;
• File ও contract;
• Compiler version ও build setting;
• Dependency;
• Architecture ও privileged role;
• Branch বা release;
• Exclusion, limitation ও assumption;
• Review date।

এটি গুরুত্বপূর্ণ, কারণ genuine audit পুরোনো version, অন্য deployment বা বড় system-এর শুধু একটি অংশ cover করতে পারে।

Auditor-রা সাধারণত কী পরীক্ষা করেন

1. প্রত্যাশিত আচরণ ও অপরিবর্তনীয় শর্ত

Auditor code-কে specification-এর সঙ্গে তুলনা করেন:

• প্রতিটি function কে call করতে পারে;
• Amount ও fee কীভাবে হিসাব হয়;
• Status change কখন ঘটে;
• কোন property সব সময় true থাকতে হবে;
• Edge case ও failure কীভাবে handle করা হয়।

Specification গুরুত্বপূর্ণ requirement বাদ দিলে technically correct code-ও unsafe বা unwanted design implement করতে পারে।

2. অ্যাক্সেস নিয়ন্ত্রণ

Reviewer-রা owner, admin, operator ও অন্যান্য privileged role পরীক্ষা করেন, যার মধ্যে নিচের ক্ষমতাগুলো রয়েছে:

• Permission grant বা revoke করা;
• System pause করা;
• Fee ও limit বদলানো;
• Token mint করা;
• Asset withdraw করা;
• Implementation upgrade করা।

একটি key critical change করতে পারে কি না এবং multisig বা timelock-এর মতো control design-এর অংশ কি না, তাও দেখা হয়।

3. বাহ্যিক কল ও reentrancy

কোনো কন্ট্র্যাক্ট কার্যকর হওয়ার সময় অন্য কন্ট্র্যাক্টকে নিয়ন্ত্রণ দিতে পারে। এতে reentrancy সম্ভব হয়, যেখানে মূল state transition শেষ হওয়ার আগেই বাহ্যিক কন্ট্র্যাক্ট আবার কল করে। Solidity-এর সরকারি নির্দেশনা অনুযায়ী প্রযোজ্য স্থানে check, state effect ও external interaction সাবধানে ক্রমানুসারে সাজাতে হবে।

4. হিসাব ও একক

Auditor যা খোঁজেন:

• Rounding ও precision loss;
• Mismatched token decimal;
• Operation-এর ভুল order;
• Boundary value;
• Zero দিয়ে division;
• unsafe unchecked arithmetic;
• Internal ও displayed unit-এর অমিল।

5. ডিনায়াল-অফ-সার্ভিস ও গ্যাস

Unbounded loop, growing array, failed external call বা expensive operation কোনো function execute করা impractical করতে পারে। Data বাড়লে ও unusual input-এ design usable থাকে কি না reviewer-রা পরীক্ষা করেন।

6. প্রক্সি ও আপগ্রেড

Upgradeable system-এর review-এ থাকতে হবে:

• Proxy ও implementation contract;
• Upgrader বা admin right;
• Initialization;
• Storage-layout-এর compatibility;
• অননুমোদিত upgrade-এর path;
• Audit-এর পর logic change-এর effect।

Proxy নতুন logic-এ দায়িত্ব অর্পণ করেও ব্যবহারকারীর সামনে একই address রাখতে পারে। তাই “কন্ট্র্যাক্ট পরিবর্তন করা যায় না” এমন দাবি প্রকৃত architecture-এর সঙ্গে মিলিয়ে দেখতে হবে।

7. ইন্টিগ্রেশন

Contract token, price oracle, bridge, DEX, signature বা অন্য contract-এর ওপর নির্ভর করতে পারে। Auditor এসব dependency, stale data, unusual token behavior ও external failure mode সম্পর্কে assumption পরীক্ষা করেন।

8. ইভেন্ট ও পর্যবেক্ষণ

Reviewer-রা event-এ role change, upgrade, pause ও transfer-এর মতো গুরুত্বপূর্ণ action সঠিকভাবে প্রকাশিত হয়েছে কি না দেখেন। Event monitoring-এ সহায়ক, তবে state inspection-এর বিকল্প নয়।

Audit-এ ব্যবহৃত পদ্ধতি

পর্যালোচনায় সাধারণত যা একত্রে থাকে:

• Manual code ও architecture analysis;
• Unit ও integration testing;
• Static ও dynamic analysis;
• Generated input দিয়ে fuzzing;
• Property-based testing;
• Known vulnerability class-এর পরীক্ষা;
• Build ও deployment review;
• কখনো selected property-এর formal verification।

একটি পদ্ধতি সবকিছু যাচাই করতে পারে না। Formal verification প্রমাণ করতে পারে যে code formal specification পূরণ করে; কিন্তু specification-এ উল্লেখ না থাকা কোনো property এটি প্রমাণ করতে পারে না।

ব্যবহারকারী কীভাবে অডিট পড়বেন

1. পর্যালোচিত সংস্করণের সঙ্গে মিলিয়ে দেখুন

Commit hash খুঁজে নির্ধারণ করুন:

• Current implementation ওই code থেকে build করা হয়েছিল কি না;
• Report date-এর পর upgrade হয়েছে কি না;
• Chain ও deployed address মেলে কি না;
• Critical dependency scope-এর মধ্যে ছিল কি না।

এটি প্রতিষ্ঠা করা না গেলে report live deployment সম্পর্কে সীমিত evidence দেয়।

2. শুধু সারাংশ নয়, পর্যবেক্ষণগুলোও পড়ুন

প্রতিটি finding-এর জন্য দেখুন:

• Severity ও scenario;
• প্রভাবিত code;
• Recommendation;
• Developer response;
• Current status;
• Auditor fix আবার test করেছেন কি না।

Fixed or Resolved is meaningful only when tied to a specific corrected version.

3. সীমাবদ্ধতা পড়ুন

Report-এ বাদ থাকতে পারে:

• Frontend ও backend system;
• Key management;
• Economic design;
• Third-party contract;
• Deployment-এর infrastructure;
• Production configuration;
• Legal ও operational issue।

User শুধু Solidity file নয়, পুরো system-এর সঙ্গে interact করেন।

4. প্রশাসনিক ঝুঁকি পর্যালোচনা করুন

জিজ্ঞাসা করুন:

• Upgrade কে control করে;
• Operation pause করা যায় কি না;
• Fee বা linked address বদলাতে পারে কি না;
• Timelock আছে কি না;
• Multisig ব্যবহৃত হয় কি না;
• User কীভাবে change সম্পর্কে জানেন।

Code-এ কোনো discovered vulnerability না থাকলেও এগুলো governance ও trust-এর প্রশ্ন।

5. অডিটের পরের নিরাপত্তাও যাচাই করুন

চলমান যেসব measure উপযোগী:

• প্রতিটি release test করা;
• গুরুত্বপূর্ণ upgrade review করা;
• একটি bug-bounty program;
• Role ও implementation monitoring;
• Incident মোকাবিলার procedure;
• Exposure-এ থাকা asset-এর পরিমাণ সীমিত করা।

What an audit does not guarantee

অডিট যেসব বিষয়ে নিশ্চয়তা দেয় না:

• প্রতিটি bug-এর অনুপস্থিতি;
• Review-এর পর changed code-এর safety;
• Website, wallet, DNS বা server-এর safety;
• Privileged key-এর security;
• External token, oracle ও bridge-এর correctness;
• প্রতিটি economic attack-এর বিরুদ্ধে resistance;
• Team-এর integrity;
• Legal compliance;
• Token liquidity;
• Fund return;
• Fixed বা অন্য যেকোনো return।

সতর্ক user-এর যেসব প্রশ্ন করা উচিত

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.

Report-এর checklist

• Report auditor-এর কাছ থেকে পাওয়া যায়।
• Repository ও commit hash উল্লেখ করা হয়েছে।
• Critical contract ও dependency scope-এর মধ্যে আছে।
• Reviewed version live deployment-এর সঙ্গে মেলে।
• Proxy, implementation ও admin অন্তর্ভুক্ত করা হয়েছে।
• Finding status ও retesting নথিভুক্ত।
• ধারণা ও বর্জনগুলো পড়া হয়েছে।
• Code-এর বাইরের risk আলাদাভাবে মূল্যায়ন করা হয়েছে।

উৎস ও আরও পড়ুন

1. Ethereum.org — স্মার্ট কন্ট্র্যাক্টের নিরাপত্তা
2. Ethereum.org — Smart Contract পরীক্ষা
3. Ethereum.org — Smart Contract-এর Formal Verification
4. Solidity Documentation — নিরাপত্তাসংক্রান্ত বিবেচনা
5. OpenZeppelin Docs — Proxy Upgrade Pattern