ریسک قرارداد هوشمند چیست؟ چک‌لیست امنیت پروژه‌های کریپتو

قرارداد هوشمند چیست؟

قرارداد هوشمند برنامه‌ای است که روی بلاکچین مستقر می‌شود و پس از دریافت تراکنش یا ورودی مشخص، مجموعه‌ای از دستورها را اجرا می‌کند.

قراردادهای هوشمند می‌توانند:

• موجودی توکن‌ها را ثبت کنند؛
• انتقال دارایی انجام دهند؛
• وام و وثیقه را مدیریت کنند؛
• معاملات صرافی غیرمتمرکز را اجرا کنند؛
• سود استیکینگ را محاسبه کنند؛
• رأی‌گیری حاکمیتی برگزار کنند؛
• NFT صادر کنند؛
• دارایی را میان شبکه‌ها انتقال دهند؛
• خزانه یک DAO را کنترل کنند؛
• قیمت و داده خارجی را از Oracle دریافت کنند.

قدرت اجرای خودکار، وابستگی به واسطه انسانی را کاهش می‌دهد؛ اما یک خطای کوچک در کد یا طراحی می‌تواند به‌طور خودکار روی تمام کاربران اثر بگذارد.

چرا ریسک قرارداد هوشمند اهمیت دارد؟

در نرم‌افزار سنتی، شرکت می‌تواند خطا را اصلاح، پایگاه داده را بازگردانی یا تراکنش مشکوک را متوقف کند. در قرارداد هوشمند غیرقابل‌ارتقا، اصلاح کد مستقرشده ممکن نیست و باید قرارداد جدیدی ساخته شود.

حتی در قراردادهای Upgradeable نیز تغییر منطق به دسترسی مدیر، Proxy Admin، رأی حاکمیتی یا Multisig وابسته است. همین قابلیت ارتقا یک لایه ریسک تازه ایجاد می‌کند.

طبق 🔗 راهنمای امنیت قرارداد هوشمند Ethereum.org، کد مستقرشده معمولاً به‌سادگی قابل‌اصلاح نیست و دارایی سرقت‌شده نیز به‌دلیل ماهیت تراکنش‌های بلاکچین ممکن است قابل‌بازگشت نباشد.

انواع ریسک قرارداد هوشمند

ریسک را نباید فقط به «وجود باگ در کد» محدود کرد. یک پروژه ممکن است از نظر کدنویسی مناسب باشد، اما به‌دلیل ساختار مدیریتی، اوراکل ضعیف یا مدل اقتصادی شکننده زیان ایجاد کند.

حمله Reentrancy چیست؟

Reentrancy یا ورود مجدد زمانی رخ می‌دهد که قرارداد، پیش از تکمیل تغییرات داخلی خود، کنترل را به قرارداد دیگری منتقل کند. قرارداد خارجی می‌تواند در همان میان دوباره تابع قبلی را فراخوانی کند.

سناریوی ساده:

1. کاربر مخرب درخواست برداشت می‌دهد.

2. قرارداد پیش از صفرکردن موجودی، دارایی را ارسال می‌کند.

3. قرارداد مهاجم هنگام دریافت دارایی، تابع برداشت را دوباره فراخوانی می‌کند.

4. موجودی هنوز در قرارداد قربانی به‌روزرسانی نشده است.

5. برداشت چند بار تکرار می‌شود.

این حمله فقط به انتقال ETH محدود نیست. هر فراخوانی خارجی می‌تواند کنترل اجرای برنامه را موقتاً به قرارداد مقصد واگذار کند.

راهکارهای توسعه‌دهندگان شامل الگوی Checks-Effects-Interactions، قفل Reentrancy، محدودکردن فراخوانی خارجی و آزمایش مسیرهای بازگشتی است.

کاربر عادی نمی‌تواند با مشاهده رابط سایت تشخیص دهد قرارداد در برابر Reentrancy ایمن است؛ گزارش Audit، کد تأییدشده و سابقه بررسی مستقل اهمیت دارند.

ریسک Access Control چیست؟

Access Control تعیین می‌کند چه آدرس‌هایی اجازه اجرای توابع حساس قرارداد را دارند.

توابع حساس می‌توانند شامل این موارد باشند:

• ساخت توکن جدید؛
• توقف انتقال؛
• تغییر کارمزد؛
• برداشت از خزانه؛
• افزودن وثیقه جدید؛
• تغییر Oracle؛
• ارتقای Implementation؛
• مسدودکردن آدرس؛
• تغییر مدیر؛
• انتقال مالکیت؛
• تعیین پارامترهای لیکوییدیشن.

اگر تابع حساس بدون محدودیت مناسب باشد، هر کاربر یا مهاجم می‌تواند آن را اجرا کند. اگر تمام دسترسی‌ها نیز در اختیار یک کیف پول شخصی باشد، سرقت کلید همان کیف پول می‌تواند کل پروتکل را در معرض خطر قرار دهد.

مستندات رسمی 🔗 Access Control در OpenZeppelin توضیح می‌دهد که دسترسی مدیر می‌تواند بر Mint، Freeze، Upgrade و سایر عملیات مهم اثر بگذارد. استفاده از Role، Multisig و Timelock می‌تواند نقطه شکست واحد را کاهش دهد.

ریسک کلید مدیریتی

قرارداد بدون باگ نیز ممکن است به یک کلید مدیریتی قدرتمند وابسته باشد.

پیش از سرمایه‌گذاری بررسی کنید:

• مالک قرارداد چه آدرسی است؟
• مالک یک کیف پول عادی است یا Multisig؟
• چند امضا برای اجرای تراکنش لازم است؟
• اعضای Multisig چه کسانی هستند؟
• امکان تعویض اعضا وجود دارد؟
• عملیات حساس Timelock دارد؟
• مدیر می‌تواند قرارداد را Pause کند؟
• امکان برداشت اضطراری وجود دارد؟
• مدیر می‌تواند موجودی کاربر را مسدود کند؟
• مالکیت واقعاً Renounce شده یا فقط ادعا شده است؟

Renounce Ownership نیز همیشه مزیت نیست. حذف کامل مدیریت می‌تواند اصلاح خطا یا واکنش اضطراری را غیرممکن کند.

قرارداد Proxy چیست؟

در قرارداد Upgradeable، آدرسی که کاربر با آن تعامل می‌کند معمولاً یک Proxy است. Proxy داده‌ها را نگه می‌دارد، اما منطق اجرا را از قرارداد دیگری به نام Implementation دریافت می‌کند.

ساختار ساده:

کاربر → Proxy → Implementation

مدیر می‌تواند Implementation قبلی را با نسخه جدید جایگزین کند. در نتیجه، آدرس قرارداد برای کاربر ثابت می‌ماند، ولی منطق آن تغییر می‌کند.

مزیت Proxy

• اصلاح آسیب‌پذیری؛
• افزودن قابلیت؛
• تغییر پارامترها؛
• مهاجرت آسان‌تر کاربران؛
• واکنش به مشکلات عملیاتی.

ریسک Proxy

• ارتقای مخرب؛
• سرقت کلید Proxy Admin؛
• تغییر منطق برداشت؛
• حذف کنترل‌های امنیتی؛
• خطای Storage Layout؛
• مقداردهی اولیه نادرست؛
• ارتقا بدون اطلاع کاربران؛
• تمرکز قدرت در یک آدرس.

OpenZeppelin در 🔗 مستندات Proxy هشدار می‌دهد که پیاده‌سازی امن قراردادهای Upgradeable نیازمند شناخت عمیق Proxy Pattern، Solidity و EVM است.

چگونه Proxy بودن قرارداد را تشخیص دهیم؟

در Explorer شبکه بررسی کنید:

• آیا برچسب Proxy نمایش داده می‌شود؟
• آدرس Implementation چیست؟
• کد Implementation تأیید شده است؟
• آخرین Upgrade چه زمانی انجام شده؟
• چه آدرسی اجازه ارتقا دارد؟
• مدیر EOA است یا Multisig؟
• رویدادهای `Upgraded` وجود دارند؟
• Timelock برای ارتقا اعمال می‌شود؟
• گزارش Audit کدام نسخه Implementation را پوشش داده است؟

Audit نسخه قدیمی، امنیت نسخه‌ای را که بعداً ارتقا یافته تضمین نمی‌کند.

ریسک Oracle چیست؟

بلاکچین به‌طور مستقیم از قیمت صرافی‌ها، نرخ ارز، آب‌وهوا یا داده بانکی اطلاع ندارد. Oracle اطلاعات بیرونی را به قرارداد می‌رساند.

اگر Oracle قیمت اشتباه یا دست‌کاری‌شده ارائه کند، قرارداد نیز براساس همان داده نادرست عمل می‌کند.

پیامدها:

• لیکوییدشدن اشتباه وام؛
• برداشت بیش از وثیقه؛
• Mint دارایی بدون پشتوانه؛
• معامله با قیمت غیرواقعی؛
• محاسبه نادرست سود؛
• ایجاد بدهی برای پروتکل.

خطر استفاده از قیمت Spot یک استخر کوچک

اگر قرارداد قیمت را از یک استخر کم‌عمق دریافت کند، مهاجم ممکن است با معامله بزرگ یا Flash Loan قیمت را برای مدت کوتاهی جابه‌جا کند.

قرارداد قربانی قیمت دست‌کاری‌شده را معتبر می‌بیند و تصمیم مالی اشتباه می‌گیرد.

راهکارهای توسعه‌دهنده می‌تواند شامل Oracle چندمنبعی، TWAP، محدودیت انحراف، بررسی Staleness و Circuit Breaker باشد.

Flash Loan Attack چیست؟

Flash Loan وامی است که در همان تراکنش دریافت و بازپرداخت می‌شود. اگر وام تا پایان تراکنش بازگردانده نشود، کل تراکنش Revert خواهد شد.

Flash Loan به‌خودی‌خود باگ نیست. این ابزار سرمایه موقت بزرگی فراهم می‌کند و می‌تواند ضعف‌های موجود را تشدید کند.

مهاجم می‌تواند از Flash Loan برای این اهداف استفاده کند:

• دست‌کاری قیمت استخر کم‌عمق؛
• خرید قدرت رأی موقت؛
• سوءاستفاده از محاسبه وثیقه؛
• اجرای آربیتراژ مخرب میان چند پروتکل؛
• تغییر قیمت سهم Vault؛
• دورزدن فرض‌های اقتصادی قرارداد.

عبارت «هک با Flash Loan» معمولاً به این معنی است که ضعف اصلی در Oracle، Governance یا منطق اقتصادی وجود داشته و Flash Loan سرمایه لازم برای بهره‌برداری را فراهم کرده است.

ریسک دست‌کاری حاکمیت

پروتکل DAO ممکن است تغییرات را از طریق رأی دارندگان توکن اجرا کند. حاکمیت زنجیره‌ای نیز بدون ریسک نیست.

خطرها:

• تمرکز توکن رأی‌دهی؛
• مشارکت پایین کاربران؛
• خرید یا وام‌گرفتن قدرت رأی؛
• پیشنهاد دارای کد مخرب؛
• متن گمراه‌کننده پیشنهاد؛
• اجرای فوری بدون Timelock؛
• واگذاری رأی به نماینده آلوده؛
• کنترل خزانه توسط گروه کوچک.

Timelock میان تصویب و اجرا به کاربران زمان می‌دهد تغییر را بررسی و در صورت مخالفت از پروتکل خارج شوند. بااین‌حال، Timelock بسیار کوتاه یا قابل‌لغو توسط مدیر محافظت مؤثری ایجاد نمی‌کند.

ریسک Composability چیست؟

پروتکل‌های DeFi از قراردادهای دیگر مانند قطعات لگو استفاده می‌کنند. یک پروتکل می‌تواند به این اجزا وابسته باشد:

• استیبل‌کوین؛
• Oracle؛
• صرافی غیرمتمرکز؛
• Lending Protocol؛
• Bridge؛
• Liquid Staking Token؛
• Vault؛
• توکن Wrapped؛
• Keeper یا Automation Network.

این ترکیب‌پذیری نوآوری را سریع‌تر می‌کند، اما ریسک سرایت ایجاد می‌کند. اگر یکی از اجزای پایه هک، متوقف یا Depeg شود، قراردادهای وابسته نیز می‌توانند زیان ببینند.

بررسی فقط قرارداد اصلی کافی نیست؛ وابستگی‌های مهم و محدودیت اضطراری آن‌ها نیز باید شناخته شوند.

ریسک Bridge و قراردادهای میان‌زنجیره‌ای

Bridge دارایی یا پیام را میان شبکه‌ها منتقل می‌کند. این فرایند ممکن است به قرارداد، Validator، Relayer، Oracle یا Multisig وابسته باشد.

سناریوهای خطر:

• صدور Wrapped Token بدون پشتوانه؛
• پذیرش پیام جعلی از شبکه دیگر؛
• سرقت کلید Validator؛
• عبور امضای تکراری؛
• خطای Proof Verification؛
• تغییر مخرب قرارداد مقصد؛
• توقف شبکه مبدأ؛
• قفل‌شدن دارایی پشتوانه؛
• تمرکز بیش‌ازحد Multisig؛
• ناهماهنگی میان نسخه قراردادها.

داشتن Audit در هر دو شبکه نیز امنیت کل مسیر پیام‌رسانی را تضمین نمی‌کند.

خطر Integer Overflow و Underflow

در عملیات عددی، نتیجه ممکن است از محدوده نوع داده خارج شود. در نسخه‌های قدیمی Solidity، این وضعیت می‌توانست مقدار عدد را به ابتدای محدوده برگرداند و نتیجه غیرمنتظره ایجاد کند.

از Solidity نسخه ۰.۸ به بعد، بسیاری از Overflow و Underflowها به‌طور پیش‌فرض باعث Revert می‌شوند. بااین‌حال:

• قراردادهای قدیمی همچنان وجود دارند؛
• بلوک‌های `unchecked` کنترل را غیرفعال می‌کنند؛
• خطای Precision و Rounding باقی می‌ماند؛
• تبدیل نوع داده می‌تواند مشکل ایجاد کند؛
• محاسبات مالی پیچیده ممکن است از نظر منطقی اشتباه باشند.

رفع یک کلاس خطا به معنی ایمن‌شدن کامل محاسبات قرارداد نیست.

ریسک Precision و Rounding

قراردادهای هوشمند معمولاً از اعداد صحیح استفاده می‌کنند. تقسیم، درصد سود و تبدیل واحد می‌توانند با گردکردن همراه شوند.

خطای کوچک در هر تراکنش ممکن است در حجم زیاد به اختلاف قابل‌توجه تبدیل شود.

موارد حساس:

• محاسبه سهم Vault؛
• نرخ تبدیل توکن؛
• بهره وام؛
• Reward استیکینگ؛
• کارمزد؛
• تبدیل Decimalهای متفاوت؛
• Liquidation Threshold؛
• قیمت دارایی Wrapped.

باید مشخص شود گردکردن به نفع کاربر، پروتکل یا نزدیک‌ترین مقدار انجام می‌شود.

حمله Front-Running و MEV

تراکنش پیش از ثبت در بلاک می‌تواند در Mempool قابل‌مشاهده باشد. Validator یا ربات ممکن است تراکنش دیگری را پیش، پس یا اطراف آن قرار دهد.

نمونه‌ها:

• خرید پیش از سفارش بزرگ؛
• Sandwich Attack؛
• رقابت برای Liquidation؛
• Front-Running رأی یا Mint؛
• ربودن فرصت آربیتراژ؛
• اجرای معامله کاربر با Slippage بیشتر.

MEV همیشه باگ قرارداد نیست؛ اما طراحی ضعیف Slippage، Deadline یا Commit-Reveal می‌تواند کاربر را آسیب‌پذیرتر کند.

حمله Denial of Service به قرارداد

قرارداد ممکن است طوری طراحی شده باشد که یک کاربر یا مجموعه داده بزرگ مانع اجرای تابع شود.

دلایل:

• Loop بدون سقف روی فهرست بزرگ؛
• وابستگی به انتقالی که Revert می‌شود؛
• مصرف Gas بیش‌ازحد؛
• قفل سراسری قرارداد؛
• درخواست خارجی نامطمئن؛
• صف پردازش غیرقابل‌مدیریت.

در این حالت، دارایی الزاماً سرقت نمی‌شود؛ اما برداشت، انتقال یا اجرای عملیات می‌تواند متوقف شود.

Honeypot چیست؟

Honeypot توکن یا قراردادی است که خرید آن ممکن است آسان باشد، اما فروش یا انتقال با محدودیت پنهان روبه‌رو شود.

روش‌های احتمالی:

• Blacklist خریداران؛
• کارمزد فروش بسیار بالا؛
• تغییر پویا در محدودیت انتقال؛
• مجوز فروش فقط برای آدرس‌های خاص؛
• سقف تراکنش غیرعملی؛
• تابع مخفی Mint؛
• تشخیص Router و مسدودکردن فروش؛
• Proxy با قابلیت افزودن محدودیت بعدی.

یک خرید آزمایشی موفق، فروش‌پذیری آینده را تضمین نمی‌کند. مدیر می‌تواند پس از جذب نقدینگی پارامترها را تغییر دهد.

تفاوت ریسک قرارداد هوشمند و Rug Pull

Rug Pull معمولاً اقدام عمدی تیم یا مدیر برای خارج‌کردن نقدینگی، Mint توکن یا رهاکردن پروژه است. ریسک قرارداد هوشمند مفهوم گسترده‌تری دارد و خطاهای غیرعمدی را نیز شامل می‌شود.

مجوز Token Approval چیست؟

برای استفاده از توکن ERC-20 در صرافی غیرمتمرکز یا پروتکل DeFi، کاربر معمولاً اجازه می‌دهد قرارداد مقدار مشخصی از توکن او را خرج کند.

این مجوز با انتقال فوری متفاوت است. Approval اجازه آینده ایجاد می‌کند و می‌تواند پس از پایان کار نیز فعال بماند.

خطر Approval نامحدود

بعضی برنامه‌ها برای کاهش تعداد تراکنش‌ها، مجوز نامحدود درخواست می‌کنند. اگر قرارداد، Proxy یا کلید مدیریتی بعداً آلوده شود، مجوز باقی‌مانده می‌تواند دارایی بیشتری را در معرض خطر قرار دهد.

🔗 راهنمای رسمی MetaMask درباره Token Approval هشدار می‌دهد که Approval مخرب یا بیش‌ازحد می‌تواند امکان دسترسی غیرمجاز به توکن‌های کاربر را فراهم کند.

چگونه Approvalهای کیف پول را مدیریت کنیم؟

• دامنه رسمی پروژه را بررسی کنید.
• آدرس قرارداد را با مستندات رسمی تطبیق دهید.
• مبلغ Approval را بخوانید.
• در صورت امکان، مجوز محدود بدهید.
• Approvalهای قدیمی را دوره‌ای بررسی کنید.
• مجوز برنامه‌های بدون استفاده را Revoke کنید.
• دارایی بلندمدت را در کیف پول عملیاتی نگه ندارید.
• تراکنش ناشناخته را کورکورانه امضا نکنید.
• Permit و Signature را نیز مانند تراکنش جدی بگیرید.
• پس از هک پروتکل، Approvalهای مرتبط را فوراً بررسی کنید.

Revoke نیز یک تراکنش زنجیره‌ای است و باید با آدرس صحیح قرارداد انجام شود.

امضای پیام چه خطری دارد؟

همه حملات نیازمند تراکنش `Approve` آشکار نیستند. کاربر ممکن است پیام یا داده ساختاریافته‌ای را امضا کند که به مهاجم اجازه انتقال یا ثبت سفارش بدهد.

پیش از امضا بررسی کنید:

• دامنه سایت صحیح است؟
• شبکه درست انتخاب شده؟
• Spender چه آدرسی است؟
• مقدار و توکن چیست؟
• Deadline چه زمانی است؟
• Nonce چیست؟
• امضا برای Login است یا انتقال؟
• امکان Permit یا Permit2 وجود دارد؟
• کیف پول هشدار امنیتی نمایش می‌دهد؟
• متن خوانا با داده واقعی مطابقت دارد؟

عبارت «این امضا Gas ندارد» به معنی بی‌خطر‌بودن آن نیست.

آیا Verified بودن قرارداد به معنی امن‌بودن است؟

خیر. Source Code Verification فقط نشان می‌دهد کد منتشرشده با Bytecode مستقر در آن آدرس مطابقت دارد.

یک قرارداد تأییدشده همچنان ممکن است:

• باگ داشته باشد؛
• Backdoor داشته باشد؛
• دسترسی مدیریتی خطرناک داشته باشد؛
• از Oracle ضعیف استفاده کند؛
• Proxy باشد؛
• منطق اقتصادی معیوب داشته باشد؛
• عمداً Honeypot طراحی شده باشد.

Ethereum.org در 🔗 راهنمای تأیید قرارداد تفاوت Source Verification و Formal Verification را توضیح می‌دهد. تأیید Source، درستی رفتار قرارداد را ثابت نمی‌کند.

Audit قرارداد هوشمند چیست؟

Audit بررسی مستقل کد، معماری و منطق قرارداد توسط متخصصان امنیت است. Audit می‌تواند شامل این موارد باشد:

• بررسی دستی کد؛
• Static Analysis؛
• تست واحد و Integration؛
• Fuzzing؛
• بررسی Invariant؛
• تحلیل Access Control؛
• مدل‌سازی تهدید؛
• بررسی منطق اقتصادی؛
• آزمایش Upgrade؛
• تحلیل Dependency؛
• Formal Verification محدود.

گزارش Audit معمولاً آسیب‌پذیری‌ها را براساس شدت دسته‌بندی و وضعیت اصلاح آن‌ها را ثبت می‌کند.

چرا Audit امنیت را تضمین نمی‌کند؟

Ethereum.org صراحتاً توصیه می‌کند Audit را راه‌حل جادویی در نظر نگیریم؛ زیرا Audit نمی‌تواند تمام خطاها را پیدا کند.

محدودیت‌ها:

• فقط نسخه مشخصی از کد بررسی می‌شود؛
• Scope ممکن است محدود باشد؛
• Frontend یا Oracle خارج از Scope است؛
• تغییرات بعدی بررسی نشده‌اند؛
• برخی مشکلات اقتصادی در تست ظاهر نمی‌شوند؛
• Auditor ممکن است مسیر حمله را پیدا نکند؛
• رفع Issue ممکن است خطای تازه ایجاد کند؛
• Dependencyها تغییر می‌کنند؛
• گزارش قدیمی می‌شود؛
• زمان بررسی محدود است.

عبارت «Audited» بدون گزارش مستقیم، Commit بررسی‌شده و وضعیت اصلاح مشکلات ارزش محدودی دارد.

گزارش Audit را چگونه بخوانیم؟

1. نام شرکت Auditor را بررسی کنید.

2. لینک گزارش را از وب‌سایت رسمی Auditor باز کنید.

3. تاریخ Audit را ببینید.

4. آدرس قرارداد یا Commit Hash را تطبیق دهید.

5. Scope بررسی را بخوانید.

6. تعداد مشکلات Critical، High و Medium را ثبت کنید.

7. وضعیت هر Issue را بررسی کنید.

8. موارد Acknowledged اما رفع‌نشده را جدا کنید.

9. نسخه فعلی قرارداد را با نسخه Audit مقایسه کنید.

10. بررسی کنید Proxy یا Upgrade بعدی انجام شده است.

11. محدودیت‌ها و Disclaimer گزارش را بخوانید.

12. وجود Auditهای مستقل متعدد را بررسی کنید.

لوگوی Auditor در سایت پروژه، جایگزین گزارش قابل‌تأیید نیست.

Formal Verification چیست؟

Formal Verification بررسی ریاضی تطابق قرارداد با مجموعه‌ای از مشخصات تعریف‌شده است.

این روش می‌تواند ثابت کند که یک Property مشخص در تمام حالت‌های بررسی‌شده نقض نمی‌شود. برای مثال:

• فقط Owner می‌تواند Mint کند؛
• مجموع برداشت‌ها از موجودی بیشتر نمی‌شود؛
• یک تابع دوبار اجرا نمی‌شود؛
• مقدار وثیقه از حد مقرر پایین‌تر نمی‌رود.

بااین‌حال، اگر Specification ناقص یا اشتباه باشد، اثبات ریاضی نیز ویژگی درست را تضمین نمی‌کند. Formal Verification فقط تطابق کد با تعریف رسمی ارائه‌شده را بررسی می‌کند.

Bug Bounty چه اهمیتی دارد؟

برنامه Bug Bounty به پژوهشگران مستقل پاداش می‌دهد تا آسیب‌پذیری را مسئولانه گزارش کنند.

برنامه قوی معمولاً دارای این ویژگی‌هاست:

• Scope عمومی و روشن؛
• پاداش متناسب با ارزش در معرض خطر؛
• سطح Critical مشخص؛
• روش تماس امن؛
• سابقه پرداخت؛
• فرایند پاسخ‌گویی؛
• به‌روزرسانی Scope پس از Upgrade؛
• ممنوع‌نبودن غیرمنطقی روش‌های تست.

وجود Bug Bounty ریسک را حذف نمی‌کند، اما احتمال کشف مستقل ضعف را افزایش می‌دهد.

چگونه ریسک قرارداد هوشمند را بررسی کنیم؟

مرحله اول: آدرس رسمی قرارداد را پیدا کنید

نام و نماد توکن کافی نیست. آدرس را از وب‌سایت، مستندات و حساب‌های رسمی پروژه تطبیق دهید.

مرحله دوم: شبکه را کنترل کنید

یک توکن می‌تواند در چند شبکه نسخه اصلی، Wrapped یا جعلی داشته باشد.

مرحله سوم: Source Code را بررسی کنید

وجود کد تأییدشده شفافیت را افزایش می‌دهد، اما به‌تنهایی کافی نیست.

مرحله چهارم: Proxy را شناسایی کنید

Implementation، Proxy Admin، سابقه Upgrade و Timelock را بررسی کنید.

مرحله پنجم: دسترسی‌های مدیریتی را استخراج کنید

توابع Mint، Pause، Blacklist، Fee Change، Withdraw و Upgrade اهمیت ویژه دارند.

مرحله ششم: Auditها را تطبیق دهید

گزارش باید همان آدرس یا Commit فعلی را پوشش دهد.

مرحله هفتم: Oracle و وابستگی‌ها را بررسی کنید

مشخص کنید قیمت و داده از کجا دریافت می‌شوند و قرارداد به چه پروتکل‌هایی وابسته است.

مرحله هشتم: سابقه عملیاتی را ببینید

TVL، مدت فعالیت، تعداد کاربران و سابقه Incident مفیدند؛ اما امنیت آینده را تضمین نمی‌کنند.

مرحله نهم: اندازه سرمایه را محدود کنید

سرمایه‌گذاری در یک پروتکل نباید صرفاً به‌دلیل نرخ سود بالاتر بزرگ شود. بازده بیشتر ممکن است پاداش پذیرش ریسک پنهان باشد.

مرحله دهم: Approvalها را مدیریت کنید

مجوزهای فعال را پس از استفاده بررسی و موارد غیرضروری را لغو کنید.

برای یادگیری اصول ارزیابی پروژه، کیف پول و ریسک‌های پایه می‌توانید از 🔗 دوره آموزشی شروع قدرتمند ارزهای دیجیتال استفاده کنید.

نشانه‌های هشدار پروژه پرریسک

• قرارداد تأییدنشده؛
• آدرس قرارداد مبهم؛
• Audit بدون گزارش مستقیم؛
• Audit مربوط به نسخه قدیمی؛
• Proxy با مدیر ناشناس؛
• امکان Mint نامحدود؛
• تغییر نامحدود کارمزد؛
• Blacklist دلخواه؛
• برداشت اضطراری بدون Timelock؛
• Multisig با امضاکنندگان نامشخص؛
• TVL بسیار متمرکز؛
• Oracle از استخر کم‌عمق؛
• سود غیرعادی بدون منبع درآمد؛
• وابستگی زیاد به توکن بومی؛
• نبود Bug Bounty؛
• مستندات ناقص؛
• کپی‌بودن کد همراه تغییرات ناشناخته؛
• Approval نامحدود؛
• Frontend روی دامنه تازه یا مشکوک؛
• تیمی که پرسش امنیتی را فقط با عبارت «Audited» پاسخ می‌دهد.

چگونه ریسک قرارداد هوشمند را کاهش دهیم؟

سرمایه را تقسیم کنید

قرار‌دادن تمام دارایی در یک پروتکل، ریسک یک نقطه شکست را افزایش می‌دهد.

کیف پول عملیاتی جدا داشته باشید

کیف پول تعامل با DApp را از کیف پول نگهداری بلندمدت جدا کنید.

ابتدا با مبلغ کم آزمایش کنید

واریز و برداشت را با مقدار محدود بررسی کنید. این کار امنیت آینده را تضمین نمی‌کند، اما خطاهای ابتدایی را آشکار می‌سازد.

Approval محدود بدهید

در صورت امکان فقط مبلغ موردنیاز را مجاز کنید.

گزارش‌های امنیتی را دنبال کنید

Upgrade، Incident، Pause و تغییر Oracle می‌توانند وضعیت ریسک را تغییر دهند.

از نرخ سود بالا نتیجه‌گیری نکنید

APY بالا می‌تواند از انتشار توکن، اهرم، ریسک نقدینگی یا مشوق موقت ناشی شود.

برنامه خروج داشته باشید

بدانید در صورت Pause، Depeg، هک Dependency یا افزایش زمان برداشت چه اقدامی انجام می‌دهید.

برای طراحی چارچوب متناسب با سرمایه و تحمل ریسک می‌توانید از 🔗 آموزش خصوصی آنلاین و حضوری ارز دیجیتال استفاده کنید؛ این آموزش جای بررسی فنی قرارداد و مشاوره مالی شخصی را نمی‌گیرد.

مزایای قرارداد هوشمند

• اجرای خودکار قواعد؛
• شفافیت تراکنش‌ها؛
• امکان بررسی کد؛
• کاهش نیاز به واسطه؛
• تسویه شبانه‌روزی؛
• ترکیب‌پذیری پروتکل‌ها؛
• دسترسی عمومی؛
• امکان Multisig و Timelock؛
• قابلیت Audit مستقل؛
• مشاهده رویدادهای مدیریتی روی زنجیره.

محدودیت‌ها و ریسک‌ها

• کد معیوب نیز خودکار اجرا می‌شود؛
• تراکنش اشتباه معمولاً برگشت‌ناپذیر است؛
• اصلاح قرارداد غیرقابل‌ارتقا دشوار است؛
• Proxy قدرت مدیریتی ایجاد می‌کند؛
• داده Oracle می‌تواند نادرست باشد؛
• Dependencyها ریسک سرایت دارند؛
• Audit تمام خطاها را پیدا نمی‌کند؛
• Frontend می‌تواند هک شود؛
• Approval ممکن است فعال بماند؛
• Multisig همچنان به افراد وابسته است؛
• Timelock ممکن است ناکافی باشد؛
• طراحی اقتصادی ضعیف بدون باگ فنی نیز شکست می‌خورد؛
• شبکه امن، امنیت برنامه را تضمین نمی‌کند.

چک‌لیست ریسک قرارداد هوشمند

• آدرس قرارداد از منبع رسمی دریافت شده؟
• شبکه صحیح است؟
• Source Code تأیید شده؟
• قرارداد Proxy است؟
• آدرس Implementation مشخص است؟
• آخرین Upgrade چه زمانی بوده؟
• چه کسی اجازه Upgrade دارد؟
• Proxy Admin یک EOA است یا Multisig؟
• Multisig چند امضا نیاز دارد؟
• امضاکنندگان مستقل‌اند؟
• عملیات حساس Timelock دارد؟
• مدیر می‌تواند قرارداد را Pause کند؟
• امکان Mint وجود دارد؟
• سقف Mint مشخص است؟
• Blacklist قابل‌اعمال است؟
• کارمزد قابل‌تغییر است؟
• حداکثر کارمزد محدود شده؟
• تابع برداشت اضطراری وجود دارد؟
• Oracle کدام است؟
• داده Oracle چند منبع دارد؟
• Staleness بررسی می‌شود؟
• قیمت از استخر کم‌عمق گرفته می‌شود؟
• قرارداد به چه پروتکل‌هایی وابسته است؟
• Bridge یا Wrapped Asset استفاده می‌شود؟
• Audit مستقیم و قابل‌تأیید است؟
• Audit همان نسخه فعلی را پوشش می‌دهد؟
• مشکلات Critical و High رفع شده‌اند؟
• موارد Acknowledged بررسی شده‌اند؟
• Bug Bounty فعال است؟
• سابقه Incident وجود دارد؟
• TVL و نقدینگی متمرکزند؟
• نرخ سود از کجا تأمین می‌شود؟
• Approval چه مقدار است؟
• Approval نامحدود ضروری است؟
• Permit یا Signature چه اختیاری می‌دهد؟
• کیف پول عملیاتی جداست؟
• مبلغ سرمایه متناسب با ریسک است؟
• برنامه خروج اضطراری وجود دارد؟

اشتباهات رایج درباره ریسک قرارداد هوشمند

• تصور اینکه بلاکچین امن، هر قرارداد روی آن را امن می‌کند؛
• یکی‌دانستن Verified Contract با قرارداد بی‌خطر؛
• اعتماد کامل به Audit؛
• نخواندن Scope گزارش؛
• استفاده از Audit نسخه قدیمی؛
• نادیده‌گرفتن Proxy؛
• بررسی‌نکردن Implementation؛
• اعتماد به Renounce Ownership بدون بررسی کد؛
• بی‌توجهی به کلید مدیر؛
• تصور غیرمتمرکزبودن هر DAO؛
• نادیده‌گرفتن Oracle؛
• معرفی Flash Loan به‌عنوان باگ اصلی؛
• حذف ریسک Dependency؛
• نگهداری تمام سرمایه در یک پروتکل؛
• دادن Approval نامحدود؛
• امضای پیام ناخوانا؛
• اتصال کیف پول اصلی به سایت‌های ناشناس؛
• خرید توکن فقط به‌دلیل امکان خرید موفق؛
• آزمایش‌نکردن فروش؛
• اعتماد به APY بالا؛
• فرض جبران خسارت پس از هک؛
• نادیده‌گرفتن ریسک Frontend و DNS؛
• اعتماد به لوگوی شرکت امنیتی بدون گزارش؛
• تصور حذف کامل ریسک با Formal Verification.

FAQ شامل ۵ تا ۸ سؤال واقعی با پاسخ کوتاه و مناسب Featured Snippet

ریسک قرارداد هوشمند چیست؟

ریسک قرارداد هوشمند احتمال زیان ناشی از باگ، طراحی اقتصادی معیوب، دسترسی مدیریتی، Oracle دست‌کاری‌شده، Proxy، Dependency یا مجوز خطرناک کیف پول است.

آیا قرارداد تأییدشده امن است؟

خیر. Verification فقط تطابق Source Code منتشرشده با Bytecode قرارداد را نشان می‌دهد. کد تأییدشده همچنان می‌تواند باگ، Backdoor یا دسترسی مدیریتی خطرناک داشته باشد.

آیا Audit امنیت قرارداد را تضمین می‌کند؟

خیر. Audit یک بررسی مستقل روی نسخه و Scope مشخص است و ممکن است همه ضعف‌ها را پیدا نکند. تغییر کد یا Upgrade بعدی نیز می‌تواند گزارش را قدیمی کند.

قرارداد Proxy چه خطری دارد؟

در قرارداد Proxy، مدیر می‌تواند Implementation و منطق اجرا را تغییر دهد. سرقت کلید مدیر یا ارتقای مخرب می‌تواند دارایی کاربران را به خطر بیندازد.

Approval نامحدود چیست؟

Approval نامحدود اجازه می‌دهد قرارداد مقدار نامحدودی از یک توکن کیف پول را خرج کند. اگر قرارداد یا دسترسی مدیریتی آلوده شود، تمام موجودی همان توکن ممکن است در معرض خطر قرار گیرد.

حمله Reentrancy چیست؟

Reentrancy زمانی رخ می‌دهد که قرارداد خارجی پیش از تکمیل تغییرات داخلی، دوباره تابع قرارداد قربانی را فراخوانی و عملیاتی مانند برداشت را تکرار کند.

آیا Flash Loan خودش یک آسیب‌پذیری است؟

خیر. Flash Loan سرمایه موقت فراهم می‌کند. ضعف اصلی معمولاً در Oracle، منطق وثیقه، حاکمیت یا طراحی اقتصادی است که با سرمایه Flash Loan قابل‌بهره‌برداری می‌شود.

چگونه ریسک قرارداد هوشمند را کاهش دهیم؟

آدرس قرارداد، Source، Proxy، مدیر، Audit، Oracle و Dependencyها را بررسی کنید؛ Approval محدود بدهید، از کیف پول عملیاتی جدا استفاده و سرمایه را میان پروتکل‌ها تقسیم کنید.

جمع‌بندی

ریسک قرارداد هوشمند چیست؟ این ریسک فقط به باگ برنامه‌نویسی محدود نمی‌شود. Access Control، کلید مدیر، Proxy، Oracle، حاکمیت، Dependency، Bridge، طراحی اقتصادی و مجوز کیف پول نیز می‌توانند باعث زیان شوند.

Verified بودن قرارداد نشان می‌دهد کد منتشرشده با Bytecode تطبیق دارد، نه اینکه رفتار آن کاملاً امن است. Audit نیز یک لایه بررسی اضافی است و تمام خطاها یا تغییرات آینده را پوشش نمی‌دهد.

پیش از واریز سرمایه، آدرس و شبکه، Source Code، Implementation، اختیار Upgrade، Multisig، Timelock، گزارش Audit، Oracle و Approvalها را بررسی کنید. اندازه سرمایه نیز باید با احتمال شکست کامل پروتکل هماهنگ باشد.

قرارداد هوشمند واسطه انسانی را کاهش می‌دهد، اما ریسک را حذف نمی‌کند؛ بخشی از ریسک از انسان به کد، کلیدهای مدیریتی و وابستگی‌های فنی منتقل می‌شود.