• کاربران وب 3 باید مراقب ریسک‌های قراردادهای هوشمند در اکوسیستم EVM باشند.
• به عنوان کاربر قراردادهای هوشمند، با قراردادهای پروکسی (نماینده) و تأثیر آنها بر پروژه‌ها آشنا باشید.
• همچنین باید با نحوه بررسی گزارش بازرسی قراردادهای هوشمند آشنایی داشته باشید.

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

اما حتی با توجه به عدم وجود واسطه، قراردادهای هوشمند هم یکسری چالش خاص دارند – که ممکن است موجودی و دارایی شما را تحت تأثیر قرار دهند.

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

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

می‌توانید اتریوم را مثل یک کامپیوتر توزیع شده بزرگ در نظر بگیرید. اتریوم مثل کامپیوترهای معمولی کار می‌کند اما در اصل، یک شبیه سازی نرم‌افزاری از کامپیوتر فیزیکی است که به آن ماشین مجازی گفته می‌شود. در ماشین مجازی اتریوم (EVM) قرارداد هوشمند یک نرم‌افزار کامپیوتری است که به صورت خودکار و تنها در صورت برقراری یکسری شرایط از پیش تعیین شده اجرا می‌شود. معمولاً از این قراردادها برای اجرای توافقنامه بین افراد مختلف، بدون نیاز به دخالت واسطه‌ها استفاده می‌شود.

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

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

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

حملات ورود مجدد (Reentrancy attack)

ورود مجدد، به حالتی گفته می‌شود که در آن، مهاجم بتواند فراخوانی قرارداد را پیش از تکمیل اجرای آن، دوباره وارد کند. به این ترتیب مهاجمان می‌توانند از آپدیت‌هایی که هنوز انجام نشده (مثل کاهش موجودی) سوء استفاده کنند. مهم‌ترین نمونه از این حمله در هک DAO رخ داد که باعث انشعاب اتریوم به دو نسخه اتریوم و اتریوم کلاسیک شد.

سرریز و ته ریز اعداد صحیح

احتمال وقوع سرریز (Overflow) و ته ریز (Underflow) حین اجرای عملیات محاسباتی وجود دارد. اگر سرریز و ته ریز اعداد صحیح کنترل نشود، می‌توانند باعث رسیدن به اعداد بسیار بزرگ یا برگشتن به صفر شوند. در چنین شرایطی محاسبات به درستی انجام نمی‌شوند و ممکن است مهاجمان از آن برای سرقت موجودی کاربران یا دسترسی به حساب‌هایی که متعلق به خودشان نیست، استفاده کنند.

شکل پذیری امضاء (Signature malleability)

معمولاً برای تأیید تراکنش در قراردادهای هوشمند نیاز به امضاء وجود دارد. اما خیلی از مواقع، حداقل دو نسخه از یک امضاء، می‌توانند نشان دهنده داده‌های یکسانی باشند. اگر قرارداد هوشمند، امضاهای مورد استفاده در آن را ثبت کند (برای پیشگیری از استفاده دوباره)، ممکن است امکان استفاده از نسخه متفاوت یک امضاء برای دور زدن این بررسی‌ها وجود داشته باشد. برای حل این مشکل باید از علایم و نشانه‌های دیگری مثل نانس هم استفاده کرد.

مشکلات کنترل دسترسی

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

از دست رفتن دقت ممیز شناور

EVM قابلیت تشخیص اعداد اعشاری را ندارد و همین موضوع باعث ایجاد مشکلاتی حین تقسیم می‌شود. مثلاً حاصل 3 تقسیم بر 2، عدد 1.5 است اما در دنیای EVM حاصل این عملیات 1 است. برای حل این مشکل، بیشتر مقادیر در قالب wei بیان می‌شوند (1 اتر معادل با 1,000,000,000,000,000,000 wei است). اما اگر قرارداد هوشمند شما تدابیر لازم را پیاده سازی نکرده باشد، چنین محاسباتی می‌توانند باعث از دست رفتن موجودی شوند.

مشکلات ارتقای قرارداد پروکسی

یکی از ویژگی‌های قراردادهای اتریوم، غیرقابل تغییر بودن آنهاست. با توجه به داده‌هایی که این قراردادها مورد استفاده قرار می‌دهند، منطق آنها باید ایستا باشد تا همیشه به صورت مورد انتظار عمل کنند. اما توسعه دهندگان، با استفاده از قابلیتی به نام ‘delegatecall’ این ویژگی را دور می‌زنند تا منطق اجرا را از یک آدرس قرارداد دیگر استخراج کنند.

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

چگونه قراردادهای هوشمند را تحلیل کنیم؟

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

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

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

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

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

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

البته، هر چقدر ارزش قفل شده (TVL) در یک قرارداد هوشمند بیشتر باشد، انگیزه مهاجمان برای حمله به آن بیشتر می‌شود. قراردادی که مبلغ زیادی در آن قفل نشده باشد، جذابیت زیادی برای مهاجمان ندارد. در نتیجه جذابیت یک قرارداد با 1 میلیون دلار TVL نسبت به قراردادی 100 دلاری بیشتر است.

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

نتیجه گیری

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