حمله DoS با محدودیت گس بلاک (Block Gas Limit) در قراردادهای هوشمند
در بلاک‌چین اتریوم، هر بار که یک قرارداد هوشمند مستقر می‌شود یا یکی از توابع آن فراخوانی می‌گردد، برای اجرا به مقدار مشخصی گَس (Gas) نیاز دارد. این گس، در واقع سوختی است که اجرای عملیات را ممکن می‌سازد. با این حال، شبکه اتریوم برای هر بلاک، سقف مشخصی از مصرف گس تعیین کرده که به آن Block Gas Limit گفته می‌شود. این یعنی مجموع گسی که تمام تراکنش‌های یک بلاک مصرف می‌کنند، نباید از این حد بالاتر برود.
در ظاهر شاید این محدودیت چیز مهمی به نظر نرسد، اما در عمل می‌تواند در صورت عدم مدیریت صحیح، منجر به حملات انکار سرویس (DoS) در قراردادهای هوشمند شود.
چگونه حلقه‌های بی‌پایان باعث بروز حمله DoS می‌شوند؟
در قراردادهای هوشمند، استفاده از حلقه‌ها امری رایج است. اما هر بار اجرای یک حلقه، مقداری گس مصرف می‌کند. حالا تصور کنید تابعی داریم که روی یک آرایه اجرا می‌شود — اگر این آرایه با گذر زمان بزرگ‌تر شود، تعداد تکرارهای حلقه هم افزایش پیدا می‌کند و در نتیجه، اجرای آن تابع نیاز به گس بیشتری خواهد داشت.
اگر مقدار گس موردنیاز از حد مجاز گس بلاک بیشتر شود، چه اتفاقی می‌افتد؟ پاسخ ساده است: تراکنش اصلاً اجرا نخواهد شد. نکته مهم اینجاست که چنین تراکنشی حتی به مرحله پردازش نمی‌رسد، چرا که به دلیل هزینه بالا، در هیچ بلاکی گنجانده نمی‌شود.
در چنین شرایطی، تابع عملاً از کار می‌افتد و هرگونه تلاشی برای اجرای آن با شکست مواجه می‌شود — صرفاً به این دلیل که هزینه‌اش بیشتر از توان بلاک است. در نهایت، اگر عملکردهای حیاتی دیگری نیز به این تابع وابسته باشند، آن‌ها هم غیرقابل استفاده خواهند شد.
تاثیر آسیب‌پذیری DoS With Block Gas Limit
در سناریوهای خاص، این نوع از آسیب‌پذیری می‌تواند پروژه را به بن‌بست بکشاند. برای مثال، اگر یک قرارداد هوشمند وظیفه آزادسازی دارایی‌ها را بر عهده داشته باشد و تابع مربوطه دچار این مشکل شود، دارایی‌ها برای همیشه در قرارداد قفل می‌شوند. این تهدید زمانی جدی‌تر می‌شود که کاربران بتوانند به‌صورت مستقیم بر داده‌هایی مثل اندازه آرایه یا تعداد اجرای حلقه‌ها اثر بگذارند. مهاجم می‌تواند با ورودی‌های خاص، اجرای تابع را آن‌قدر سنگین کند که هیچ‌گاه موفق به اجرا نشود.
چگونه از این آسیب‌پذیری جلوگیری کنیم؟
برای پیشگیری از وقوع چنین مشکلاتی، رعایت چند نکته ضروری است:
1. از عملیات پرهزینه روی آرایه‌های بزرگ بپرهیزید
اگر داده‌هایی در قرارداد شما هستند که با گذر زمان رشد می‌کنند (مثل آرایه‌هایی که کاربران اطلاعات جدید به آن اضافه می‌کنند)، تلاش برای پیمایش کامل آن‌ها در یک تراکنش می‌تواند خطرناک باشد.
2. طراحی تابع به‌گونه‌ای باشد که در چند مرحله قابل اجرا باشد
در صورتی که ناچار به کار با آرایه‌های بزرگ هستید، میتوانید ساختار توابع را طوری طراحی کنید که عملیات سنگین در چند تراکنش و طی چند بلاک انجام شوند. برای مثال، با استفاده از الگوی batch processing یا طراحی تابعی که هر بار فقط بخشی از داده را پردازش کند، می‌توان از رسیدن به محدودیت گس جلوگیری کرد.
با استفاده از codeauditplus ، در کمترین زمان و با هزینه بسیار معقول، میتوانید آسیب پذیری ها را شناسایی و در نتیجه برای بهبود کد قرارداد اقدام متناسب انجام دهید.
نتیجه‌گیری
استفاده بی‌احتیاط از حلقه‌های پردازشی در قراردادهای هوشمند، به‌ویژه زمانی که حجم داده‌ها به‌مرور افزایش می‌یابد، می‌تواند راه را برای بروز حملات انکار سرویس باز کند. حمله DoS با سوءاستفاده از محدودیت گس بلاک، اجرای توابع حیاتی را مختل می‌کند و در برخی موارد ممکن است دسترسی به دارایی‌ها را برای همیشه از بین ببرد.
بهترین راه مقابله، پیش‌بینی این موارد در طراحی اولیه قرارداد است — طراحی‌ای که مقیاس‌پذیر، گس-بهینه و مقاوم در برابر رفتارهای مخرب باشد.
راهکار ما:
- ثبت درخواست ممیزی
- مشاهده راهنمای چگونگی ثبت درخواست ممیزی در آپارات
- مشاهده راهنمای چگونگی ثبت درخواست ممیزی در یوتیوب
منابع
https://owasp.org/www-project-smart-contract-top-10/2025/en/src/SC10-denial-of-service.html
https://swcregistry.io/docs/SWC-128/
