---

معماری ماشین اتریوم (EVM) و چالش‌های امنیتی قراردادهای هوشمند در دیفای

قراردادهای هوشمند (Smart Contracts) به عنوان ستون فقرات اکوسیستم غیرمتمرکز (Web3)، شاید مهم‌ترین اختراع پس از خود بیت‌کوین باشند. این برنامه‌های خوداجرا که روی بلاکچین اجرا می‌شوند، امکان انجام تراکنش‌های بدون واسطه را فراهم می‌کنند. اما پشت پرده این کدهای جادویی، معماری پیچیده‌ای به نام ماشین مجازی اتریوم (EVM) وجود دارد که درک آن برای هر توسعه‌دهنده بلاکچین واجب است. در این مقاله به بررسی دقیق معماری EVM و خطرناک‌ترین چالش امنیتی یعنی حملات بازگشتی (Reentrancy Attacks) خواهیم پرداخت.

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

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

این ویژگی تغییرناپذیری (Immutability) اگرچه امنیت را تضمین می‌کند، اما اگر کد از ابتدا دارای باگ باشد، اصلاح آن تقریباً غیرممکن است و منجر به هک‌های میلیاردی در حوزه دیفای (DeFi) شده است.

---

معماری ماشین مجازی اتریوم (EVM)

برای درک چگونگی اجرای قراردادها، باید با ماشین مجازی اتریوم (Ethereum Virtual Machine) آشنا شویم. EVM یک محیط محاسباتی نقطه به نقطه (Sandboxed) است که روی تمام نودهای (گره‌های) شبکه اتریوم اجرا می‌شود.

۱. محیط ایزوله و سندباکس (Sandbox)

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

۲. مدل حساب‌های (Account-based Model)

برخلاف بیت‌کوین که از مدل UTXO استفاده می‌کند، EVM بر پایه حساب‌ها بنا شده است. هر حساب دارای یک موجودی (Balance)، شمارش تراکنش (Nonce)، کد قرارداد (Code) و فضای ذخیره‌سازی (Storage) است. این مدل توسعه قراردادهای پیچیده را بسیار ساده‌تر می‌کند.

۳. گس (Gas) و هزینه اجرا

هر دستوری که در EVM اجرا می‌شود، انرژی مصرف می‌کند. این انرژی با واحد گس (Gas) سنجیده می‌شود. کاربران برای اجرای توابع قرارداد باید گس پرداخت کنند. این مکانیزم از حملات انکار سرویس (DoS) و حلقه‌های بی‌نهایت جلوگیری می‌کند. اگر گس کافی نباشد، اجرای قرارداد متوقف می‌شود اما تغییرات حالت (State Changes) اعمال نمی‌شوند.

۴. بایت‌کد (Bytecode) و اپ‌کدها (Opcodes)

زبان‌های برنامه‌نویسی سطح بالا مانند Solidity یا Vyper باید به زبان ماشین EVM ترجمه شوند. خروجی این ترجمه، بایت‌کد است که مجموعه‌ای از دستورالعمل‌های سطح پایین به نام اپ‌کد (Opcode) می‌باشد. EVM این اپ‌کدها را یکی‌یکی اجرا می‌کند تا وضعیت شبکه را تغییر دهد.

---

چالش‌های امنیتی در توسعه دیفای (DeFi)

پروتکل‌های مالی غیرمتمرکز (DeFi) بر پایه قراردادهای هوشمند بنا شده‌اند و با دارایی‌های ارزشمندی سر و کار دارند. همین موضوع باعث شده تا هکرها با انگیزه‌ای بالا به دنبال باگ‌های امنیتی باشند. برخی از رایج‌ترین چالش‌ها عبارتند از:

• حملات Reentrancy (بازگشتی): شاید معروف‌ترین حمله در تاریخ اتریوم.
• سرریز عددی (Integer Overflow/Underflow): اگرچه نسخه‌های جدید Solidity این مشکل را حل کرده‌اند، اما هنوز در قراردادهای قدیمی خطرناک است.
• دسترسی غیرمجاز (Access Control): خطاهایی که به هکر اجازه می‌دهد توابع مدیریتی را اجرا کند.
• Front-running: پیش‌دستی در تراکنش‌ها توسط ماینرها یا مزرعه‌های MEV.

در ادامه به بررسی تخصصی خطرناک‌ترین آن‌ها می‌پردازیم.

---

حمله Reentrancy (حمله بازگشتی) چیست؟

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

مکانیزم عملکرد حمله Reentrancy

برای درک بهتر، سناریوی یک بانک دیفای را در نظر بگیرید:

1. کاربر (قرارداد مخرب) درخواست برداشت ۱۰۰ اتر را می‌دهد.
2. قرارداد بانک موجودی کاربر را چک می‌کند (مثلاً ۱۰۰ اتر دارد).
3. قرارداد بانک ۱۰۰ اتر را به آدرس کاربر ارسال می‌کند.
4. نکته کلیدی: در اتریوم، هنگام ارسال اتر به یک قرارداد، اگر آن قرارداد تابعی به نام fallback داشته باشد، به صورت خودکار اجرا می‌شود.
5. قرارداد مخرب در تابع fallback خود، دوباره تابع برداشت را فراخوانی می‌کند.
6. قرارداد بانک چون هنوز موجودی کاربر را در دیتابیس خود کم نکرده است (این مرحله معمولاً بعد از ارسال انجام می‌شود)، دوباره اجازه برداشت می‌دهد.
7. این حلقه تا زمانی که گس تمام شود یا موجودی بانک خالی شود، تکرار می‌شود.

نمونه کد آسیب‌پذیر (Solidity)

// این کد صرفاً برای آموزش است و دارای آسیب‌پذیری است
function withdraw(uint amount) public {
    require(balances[msg.sender] >= amount);

    // ارسال اتر قبل از به‌روزرسانی موجودی (خطرناک!)
    (bool sent, ) = msg.sender.call{value: amount}("");
    require(sent, "Failed to send Ether");

    // به‌روزرسانی موجودی بعد از ارسال (باعث حمله Reentrancy می‌شود)
    balances[msg.sender] -= amount;
}

راهکارهای مقابله با Reentrancy

برای جلوگیری از این حملات، توسعه‌دهندگان باید از الگوی Checks-Effects-Interactions پیروی کنند:

1. Checks: ابتدا شرایط را چک کنید.
2. Effects: وضعیت داخلی قرارداد را به‌روزرسانی کنید (موجودی را کم کنید).
3. Interactions: در آخر با دنیای خارج تعامل کنید (پول ارسال کنید).

همچنین استفاده از اصلاحگر nonReentrant در کتابخانه OpenZeppelin استاندارد طلایی برای جلوگیری از این حملات است.

---

نتیجه‌گیری: امنیت، اولویت اول در توسعه بلاکچین

توسعه قراردادهای هوشمند بر روی ماشین مجازی اتریوم (EVM) فرصت‌های بی‌نظیری برای خلق برنامه‌های غیرمتمرکز فراهم کرده است. اما معماری پیچیده EVM و ماهیت تغییرناپذیر بلاکچین، حاشیه خطا را به صفر می‌رساند.

حملاتی مانند Reentrancy نشان دادند که حتی یک خط کد اشتباه می‌تواند منجر به از دست رفتن میلیون‌ها دلار دارایی شود. برای موفقیت در اکوسیستم دیفای، توسعه‌دهندگان باید اصول امنیتی را در اولویت قرار دهند، از کتابخانه‌های استاندارد مانند OpenZeppelin استفاده کنند و قراردادهای خود را تحت ممیزی دقیق (Audit) قرار دهند.

سوالات متداول ( قراردادهای هوشمند (Smart Contracts) و ماشین اتریوم (EVM) )

آیا ماشین مجازی اتریوم (EVM) فقط برای اتریوم است؟
خیر. بسیاری از بلاکچین‌های دیگر مانند بایننس اسمارت چین (BSC)، پولکادات (Moonbeam) و آوالانچ (Avalanche C-Chain) از ماشین مجازی سازگار با اتریوم استفاده می‌کنند تا توسعه‌دهندگان بتوانند به راحتی dAppهای خود را منتقل کنند.

حمله Reentrancy چگونه کشف شد؟
معروف‌ترین نمونه این حمله مربوط به هک DAO در سال ۲۰۱۶ بود که منجر به تقسیم اتریوم به ETH و ETC شد. اخیراً نیز صرافی غیرمتمرکز Uniswap نسخه ۲ هدف این نوع حملات قرار گرفت.

چگونه می‌توانم مطمئن شوم یک قرارداد هوشمند امن است؟
قبل از تعامل با هر قرارداد، بهتر است کد منبع آن را در سایت‌هایی مانند Etherscan بررسی کنید. همچنین به دنبال نشان‌های ممیزی (Audit Badges) از شرکت‌های معتبر امنیتی بلاکچین باشید.

---