ریسک قرارداد هوشمند؛ چرا هک می‌شوند
چرا قراردادهای هوشمند هک می‌شوند؟ باگ منطق، حملهٔ اجرای مجدد و ریسک پل‌ها؛ چرا ممیزی تضمین نیست و قاعدهٔ سقف سرمایه چگونه از تو محافظت می‌کند؟
قرارداد هوشمند قولِ جذابی دارد: قانونی که خودش اجرا می‌شود؛ نه واسطه‌ای می‌خواهد، نه اجازه‌نامه‌ای. اما همین ویژگی، روی دیگرش را هم ساخته — قانونی که خودش اجرا می‌شود، خودش را تصحیح هم نمی‌کند. یک باگ کوچک در کد، پنجره‌ای می‌شود که مهاجم از آن بیرون می‌رود و در بیشتر قصه‌های دیفای، پول کاربران پیش از آنکه کسی بتواند جلویش را بگیرد تخلیه شده است. در این نوشته سرچشمه‌های اصلی هک را می‌شناسیم، یک قصهٔ تاریخی را مرور می‌کنیم و مهم‌تر از همه، خط دفاعی را می‌چینیم که به کد هیچ پروژه‌ای ربطی ندارد.
سرچشمه‌های اصلی؛ از باگ تا پل
- باگ منطق: کد دقیقاً همان‌طور که نوشته شده کار می‌کند، اما نویسنده‌اش منطق را اشتباه چیده — مثل درِ خروجی که از بیرون هم باز می‌شود.
- حملهٔ اجرای مجدد (Reentrancy): قراردادِ قربانی، پیش از به‌روزرسانی موجودی‌اش، به مهاجم اجازه می‌دهد دوباره و دوباره برداشت کند؛ حفرهٔ کلاسیکی که در کدهای کپی‌شده نسل‌به‌نسل تکرار می‌شود.
- پل‌های بین‌شبکه‌ای: خزانه‌ای متمرکز از دارایی صدها هزار کاربر، به‌علاوهٔ لایهٔ پیچیدهٔ اعتبارسنجیِ میان دو زنجیره — ترکیبی که بزرگ‌ترین غارت‌های تاریخ کریپتو را رقم زده است.
- خطای خودِ کاربر: قراردادِ کاملاً سالم هم اگر تو دسترسیِ برداشت را با یک امضای نابخشوده داده باشی، کیف پولت را خالی می‌کند.
قصهٔ ۲۰۱۶؛ حفره‌ای که زنجیره را دو نیم کرد
پروژهٔ «The DAO» — صندوق سرمایه‌گذاری جمعی روی اتریوم — با حفرهٔ اجرای مجدد غارت شد: مهاجم در زنجیره‌ای از فراخوانی‌های تو در تو، حدود ۳٫۶ میلیون اتریوم را از قرارداد بیرون کشید و جامعه را در برابر انتخابی سخت گذاشت — بازگرداندن پول با دخالت در تاریخ زنجیره، یا پای‌بندی به اصلِ «کد، قانون است». آن انتخاب، اتریوم را دو نیم کرد و نام «اتریوم کلاسیک» از همان شکاف بیرون آمد. آموزنده‌ترین بخش ماجرا اما برای امروزِ توست: آن حفره از همان سال مستند و شناخته شده، اما الگوی حمله‌اش سال‌ها بعد هم در پروژه‌های دیگر تکرار شده — کدِ کپی‌شده، حفره‌اش را هم با خودش کپی می‌کند.
ممیزی؛ شرط لازم، نه تضمین
ممیزی یعنی تیمی مستقل کد را در یک پنجرهٔ زمانی مشخص بررسی کرده و گزارشی از یافته‌ها منتشر کرده است. سه محدودیتِ این سند را هم همین‌جا ببین: ممیزی تمامِ کد را پوشش نمی‌دهد؛ با هر ارتقا و تغییرِ بعدی، اعتبارش کهنه می‌شود؛ و هیچ ممیزی‌ای «ضمانت» نیست — پروژه‌های ممیزی‌شدهٔ بزرگ هم غارت شده‌اند. پس به‌جای لوگوی «ممیزی‌شده»، خودِ گزارش را ببین: تاریخ انتشار، دامنهٔ بررسی و فهرست یافته‌های بازمانده. آن را شرطِ لازم بدان، نه کافی؛ چیزی که جای خالی‌اش را پر می‌کند لایهٔ بعدی است — قاعدهٔ سقف.
قاعدهٔ سقف؛ خط دفاعی که به کد ربطی ندارد
هیچ کاربری موظف نیست باگِ پنهان را در کد پیدا کند؛ اما هر کاربری می‌تواند انتخاب کند چقدر از سرمایه‌اش در معرضِ آن است. قاعدهٔ سقف یعنی برای هر پروتکل، سهمی مشخص و کوچک از کل سرمایه. مثال عددی: با سرمایهٔ ۲٬۰۰۰ دلاری و سقف ۵٪ برای هر قرارداد، حداکثر زیانِ یک هکِ کامل ۱۰۰ دلار است؛ حتی اگر دو پروتکل هم‌زمان غارت شوند، ضربهٔ ۲۰۰ دلاری (۱۰٪ کل) حساب را زخمی می‌کند اما نمی‌کُشد. دو مکملِ ساده: واریز اول همیشه اندک باشد و برداشتِ آزمایشی را پیش از واریز اصلی ببین؛ و به سنِ پروتکل احترام بگذار — کدِ تازه، سال‌های عملیاتیِ بلند و بی‌حادثه را هنوز پشت سر نگذاشته است.
مهاجم به متنِ قانون نگاه نمی‌کند؛ به حفره‌های کد نگاه می‌کند. سهم تو در این معادله فقط یک عدد است: اندازهٔ پولی که آن‌جا خوابیده.
این نوشته تکهٔ پایانیِ پازل ریسکِ دیفای چیست؟ بانکداری بدون بانکدار است؛ دو تکهٔ مکملش را هم بخوان: حملات بریج؛ ریسک‌های جابه‌جایی بین شبکه‌ها برای عمیق‌ترین سرچشمهٔ غارت، و ریسک‌های approve؛ دسترسی‌هایی که می‌دهی برای لبه‌ای که خودت با یک امضا باز می‌کنی. بعد، قاعدهٔ سقف را برای پرتفوی واقعی‌ات بنویس — روی کاغذ، نه در ذهن.
مطالب مرتبط
ساختار کامل تحلیل و مدیریت ریسک را در مسیر آموزشی یاد بگیر — از سطح یک، رایگان.