قراردادهای هوشمند (Smart Contracts): بررسی معماری ماشین اتریوم (EVM) و چالش های امنیتی مانند Reentrancy Attacks در توسعه دیفای (DeFi)

معماری ماشین اتریوم (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) از شرکت های معتبر امنیتی بلاکچین باشید.

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

https://mohammadnasser.com/smart-contracts-evm-architecture-and-reentrancy-attacks-in-defi