هک قرارداد هوشمند یا پل بلاکچینی ممکن است با وجود امنیت خود شبکه رخ دهد. در این مقاله امنیت پل‌ها، اوراکل، حمله بازگشتی، وام فوری، اختیارات مدیر و روش ارزیابی قرارداد را بررسی می‌کنیم.
امنیت دیفای و خطر قراردادهای متصل به یکدیگر
در بلاکچین‌های قابل برنامه‌ریزی، قرارداد هوشمند می‌تواند دارایی را نگهداری یا قواعد وام و مبادله را اجرا کند. این امکان خدمات مالی تازه‌ای ساخته است، اما اشکال کوچک در کد یا طراحی اقتصادی ممکن است به خسارت بزرگ منجر شود. امنیت شبکه پایه با امنیت تمام برنامه‌های ساخته‌شده روی آن یکسان نیست. حتی اگر اجماع اتریوم درست کار کند، قرارداد استخر نقدینگی یا پل میان دو شبکه می‌تواند آسیب‌پذیر باشد. برای ارزیابی باید لایه‌های خطر را تفکیک کرد: امنیت اجماع، کد قرارداد، اختیارات مدیر، اوراکل قیمت و سازوکار نگهداری دارایی. تبلیغ «مبتنی بر بلاکچین امن» به‌تنهایی هیچ‌یک از این خطرهای مستقل را برطرف نمی‌کند.
پل بلاکچینی چیست و چگونه کار می‌کند؟
پل یا Bridge راهکاری برای انتقال پیام یا نمایش دارایی میان دو بلاکچین است. در برخی مدل‌ها، توکن در شبکه مبدأ قفل و نماینده آن در مقصد صادر می‌شود. در هنگام بازگشت، نماینده سوزانده و دارایی اصلی آزاد می‌شود. مدل‌های دیگر از تأمین نقدینگی واسط یا مکانیزم‌های اثبات پیام استفاده می‌کنند. بنابراین واژه پل به یک معماری امنیتی واحد اشاره ندارد. کاربر باید بداند دارایی مقصد دقیقاً چه حق بازخریدی دارد و چه نهادی یا چه قراردادی اجازه آزادسازی دارایی مبدأ را صادر می‌کند. شباهت نماد و لوگوی توکن در دو شبکه لزوماً به معنی یکسان بودن پشتوانه و سطح ریسک آن‌ها نیست.
ریسک اعتبارسنج‌ها و امضاکنندگان پل
در بعضی پل‌ها، مجموعه محدودی از امضاکنندگان تأیید می‌کنند که دارایی در شبکه مبدأ قفل شده و پیام مجاز به اجرا در مقصد است. اگر کلید تعداد کافی از این امضاکنندگان به سرقت رود یا آنان تبانی کنند، ممکن است پیام انتقال جعلی پذیرفته شود. در معماری دیگر، پیام با اثبات رمزنگاری‌شده یا تأیید در زنجیره اصلی بررسی می‌شود، اما این روش‌ها نیز به پیاده‌سازی درست وابسته‌اند. هنگام ارزیابی باید پرسید چند امضا لازم است، کلیدها چگونه نگهداری می‌شوند و آیا امکان تغییر فوری مجموعه اعتبارسنج وجود دارد. تعداد زیاد گره تبلیغ‌شده بدون شناخت کنترل واقعی کلیدها، معیار کاملی برای امنیت پل نیست.
تفاوت پل رسمی، شخص ثالث و لایه دوم
پل رسمی یک رول‌آپ ممکن است به قراردادهای تسویه آن لایه دوم متصل باشد، در حالی که پل شخص ثالث برای انتقال سریع‌تر از ذخایر نقدینگی و متولی مستقل استفاده کند. امنیت و زمان خروج این دو مدل یکسان نیست. در رول‌آپ خوش‌بینانه، برداشت مستقیم از لایه پایه ممکن است دوره انتظار برای بررسی اعتراض داشته باشد؛ بعضی پل‌های سریع در برابر کارمزد بیشتر امکان دریافت زودتر دارایی فراهم می‌کنند. این راحتی می‌تواند ریسک طرف مقابل و نقدینگی ایجاد کند. کاربر باید میان خروج مستقیم با تضمین‌های شبکه و فروش یا تبدیل ادعای برداشت نزد واسطه تفاوت بگذارد. نام شبکه مقصد به‌تنهایی کیفیت مسیر انتقال را مشخص نمی‌کند.
حمله بازگشتی به قرارداد هوشمند
حمله بازگشتی یا Reentrancy از الگوی اجرای نادرست عملیات حساس سوءاستفاده می‌کند. اگر قرارداد پیش از ثبت تغییر موجودی با برنامه دیگری تعامل کند، ممکن است فراخوانی خارجی مسیر اجرای دوباره تابع را باز کند و حالت حسابداری را مختل سازد. دفاع‌های رایج شامل ترتیب درست بررسی، تغییر وضعیت و تعامل خارجی و محافظت در برابر بازگشتی است. اما هیچ الگوی برنامه‌نویسی به‌تنهایی همه حملات را حذف نمی‌کند. کد باید براساس طراحی واقعی، دارایی‌های پشتیبانی‌شده و تعامل با سایر قراردادها بازبینی شود. برای سرمایه‌گذار مهم است بداند قرارداد حسابرسی شده مربوط به کدام نسخه است و چه تغییراتی پس از آن اجرا شده‌اند. هر نقص فنی می‌تواند به خطر اقتصادی تبدیل شود.
اوراکل قیمت و حملات دست‌کاری بازار
بسیاری از پروتکل‌های وام‌دهی برای ارزش‌گذاری وثیقه از اوراکل استفاده می‌کنند. اگر قرارداد به قیمت لحظه‌ای یک استخر کم‌عمق وابسته باشد، مهاجم ممکن است با معامله بزرگ موقت قیمت را تغییر دهد و از تسویه یا وام‌گیری نادرست بهره ببرد. طراحی مقاوم‌تر می‌تواند از منابع متعدد، میانگین‌گیری زمانی، محدودیت نوسان و کنترل کیفیت داده استفاده کند. بااین‌حال قیمت درست در بازار پرتنش نیز همیشه آسان تعیین نمی‌شود. برای شناخت خطر باید پرسید مرجع قیمت کجاست، چقدر نقدشوندگی دارد و در زمان توقف اوراکل چه اتفاقی رخ می‌دهد. امنیت مالی قرارداد تنها به نبود خطای برنامه‌نویسی محدود نمی‌شود؛ فرض‌های اقتصادی آن نیز باید پایدار باشند.
وام فوری Flash Loan و نقش آن در حملات
وام فوری در بعضی پروتکل‌ها اجازه می‌دهد دارایی در یک تراکنش قرض گرفته و پیش از پایان همان تراکنش بازپرداخت شود؛ در غیر این صورت کل عملیات مطابق قواعد قرارداد برگشت می‌خورد. این ابزار کاربردهای مشروع مانند آربیتراژ و مدیریت وثیقه دارد. بااین‌حال مهاجم می‌تواند با سرمایه موقت بزرگ، ضعف اوراکل یا طراحی مالی پروتکل را آشکار و بهره‌برداری کند. خود وام فوری علت بنیادی آسیب‌پذیری نیست؛ مشکل اصلی قرارداد هدف است که قیمت یا وثیقه را با فرض‌های نامناسب محاسبه می‌کند. ممنوع کردن ابزار به‌تنهایی لزوماً ضعف اقتصادی را برطرف نمی‌کند. تحلیل‌گر باید مسیر داده، محدودیت نقدینگی و امکان سوءاستفاده در یک تراکنش را بررسی کند.
اختیار ارتقای قرارداد و خطر مدیر
برخی قراردادهای دیفای از ساختار Proxy یا الگوی مشابه برای ارتقای منطق اجرایی استفاده می‌کنند. این قابلیت اجازه اصلاح خطا و افزودن امکانات تازه می‌دهد، اما دارندگان دارایی باید بدانند چه کسی می‌تواند منطق قرارداد را تغییر دهد. اگر یک کلید یا گروه کوچک بتواند بدون تأخیر قرارداد را جایگزین کند، اختیار قابل توجهی بر وجوه کاربران دارد. ابزارهایی مانند چندامضایی، تأخیر زمانی، محدودیت دسترسی و گزارش عمومی تغییرات می‌توانند بخشی از خطر را کاهش دهند. وجود عنوان DAO یا رأی‌گیری روی وب‌سایت کافی نیست؛ باید بررسی شود آیا رأی عملاً اجرا را کنترل می‌کند یا اختیار نهایی نزد تیم است. سطح تمرکز باید در تصمیم سرمایه‌گذاری لحاظ شود.
حسابرسی امنیتی و محدودیت اثبات ایمنی
حسابرسی فنی می‌تواند اشکالات مشخصی در نسخه‌ای از کد را شناسایی کند، اما گواهی مصونیت قطعی نیست. باید تاریخ گزارش، شناسه نسخه بررسی‌شده، شدت یافته‌ها و وضعیت رفع مشکلات مطالعه شود. گاهی پروژه پس از حسابرسی تغییراتی ایجاد می‌کند که خارج از دامنه بررسی بوده‌اند. برخی گزارش‌ها نیز فقط قرارداد اصلی را پوشش می‌دهند و پل یا اوراکل مرتبط را بررسی نمی‌کنند. استفاده از چند گروه حسابرسی مستقل می‌تواند مفید باشد، ولی همچنان احتمال نقص ناشناخته وجود دارد. برنامه پاداش کشف باگ و رویه پاسخ به رخداد نشانه‌های تکمیلی‌اند. برای دارایی قابل توجه بهتر است ریسک از دست رفتن کل وجه در قرارداد نیز به‌عنوان سناریوی واقعی سنجیده شود.
ریسک ترکیب‌پذیری پروتکل‌های دیفای
کاربر ممکن است توکن سپرده یک پروتکل را به‌عنوان وثیقه در پروتکل دوم قرار دهد و با وام حاصل وارد استخر دیگری شود. این ساختار می‌تواند بازده بالقوه را افزایش دهد اما خطرها را نیز به یکدیگر متصل می‌کند. نقص قرارداد اول، افت قیمت وثیقه یا توقف پل میان شبکه‌ای می‌تواند چند موقعیت را هم‌زمان درگیر کند. حتی اگر هر قرارداد جداگانه حسابرسی شده باشد، تعامل تازه میان آن‌ها ممکن است مسیر حمله یا تسویه پیش‌بینی‌نشده ایجاد کند. برای ارزیابی باید زنجیره دارایی، بدهی و اوراکل‌های مشترک را ترسیم کرد. تعداد زیاد پروتکل‌ها در یک استراتژی، لزوماً به معنای تنوع‌بخشی ریسک نیست.
دسترس‌پذیری داده و ترتیب‌دهنده لایه دوم
در بسیاری از شبکه‌های لایه دوم، ترتیب‌دهنده تراکنش نقش مهمی در تجربه سریع کاربر دارد. اگر ترتیب‌دهنده متمرکز متوقف شود، ممکن است ارسال یا تأیید عملیات با تأخیر مواجه شود. از سوی دیگر، دسترس‌پذیری داده تعیین می‌کند کاربران در صورت مشکل اپراتور آیا می‌توانند وضعیت خود را بازسازی کنند. امنیت محاسبه و توان برداشت دو موضوع متفاوت‌اند؛ اثبات معتبر بدون داده کافی ممکن است برای کاربر عادی سود عملی محدودی داشته باشد. برخی طراحی‌ها مسیر اضطراری برای ارسال تراکنش از لایه اصلی دارند، اما کارکرد و محدودیت آن‌ها باید بررسی شود. وعده کارمزد پایین یا سرعت بالا بدون شناخت این وابستگی‌ها معیار کافی برای انتخاب شبکه نیست.
هک پل چه اثری بر توکن‌های نماینده دارد؟
اگر ذخایر پشتوانه پل سرقت شود، توکن‌های نماینده منتشرشده در شبکه مقصد ممکن است دیگر پشتوانه کافی برای بازخرید نداشته باشند. در چنین وضعیتی قیمت آن‌ها می‌تواند از دارایی اصلی فاصله بگیرد و کاربران حتی بدون فعالیت مستقیم در پل زیان ببینند. این وضعیت با افت معمول قیمت رمزارز تفاوت دارد؛ مسئله به کیفیت حق بازخرید و ریسک واسطه مربوط است. هنگام نگهداری توکن پل‌خورده باید دانست چه نوع دارایی‌ای در پشتوانه قرار گرفته و چه سازوکاری برای جبران کسری وجود دارد. نماد یکسان BTC یا USDC در چند شبکه به معنای حمایت اقتصادی یکسان نیست. بررسی قرارداد و ناشر نسخه توکن ضروری است.
مجوز خرج توکن و امضای کیف پول
برای تعامل با استخر یا پل، کیف پول ممکن است از کاربر درخواست Approval یا امضای دستوری کند که به قرارداد اجازه انتقال مقدار مشخصی دارایی را می‌دهد. مجوز نامحدود، در صورت آلوده شدن قرارداد یا رابط برنامه، خطر بزرگ‌تری ایجاد می‌کند. حتی اگر مقصد تراکنش ظاهراً یک وب‌سایت آشنا باشد، باید نشانی قرارداد و محتوای عملیات بررسی شود. بهتر است برای فعالیت روزانه کیف پول جدا و موجودی محدود استفاده شود و مجوزهای غیرضروری به‌طور دوره‌ای بازبینی گردند. لغو مجوز قبلی نمی‌تواند انتقال انجام‌شده را معکوس کند. عبارت بازیابی نیز هرگز نباید برای تأیید پل یا رفع خطای تراکنش در یک سایت وارد شود.
نکات عملی انتقال ایمن بین شبکه‌ها
پیش از استفاده از پل باید شبکه مبدأ و مقصد، آدرس قرارداد رسمی، کارمزد، زمان تقریبی تسویه، حداقل برداشت و دارایی دریافتی مشخص باشد. در صورت وجود چند نسخه از توکن مقصد، باید امکان پذیرش آن توسط صرافی یا کیف پول گیرنده بررسی شود. انتقال آزمایشی با مبلغ کوچک می‌تواند برخی خطاهای آدرس و شبکه را آشکار کند، اما ریسک کل قرارداد را از بین نمی‌برد. کاربر نباید صرفاً براساس ارزان‌ترین کارمزد، پلی با ساختار نامعلوم انتخاب کند. شرایط برداشت اضطراری و سازوکار جبران خسارت، اگر وجود دارد، باید از اسناد رسمی مطالعه شود. ریسک نقدشوندگی توکن نماینده نیز مستقل از کارمزد پل است.
برنامه پاسخ به رخداد امنیتی
در صورت اعلام نقص جدی یک قرارداد یا پل، بهتر است ابتدا منابع رسمی و شناسه قرارداد تحت تأثیر بررسی شوند. شتاب برای تعامل با لینک‌های ناشناس «بازیابی» می‌تواند به امضای تراکنش مخرب تازه منجر شود. اگر کلید خصوصی افشا شده، تغییر گذرواژه برنامه به‌تنهایی کافی نیست و انتقال دارایی به کیف پول تازه با کلید مستقل ممکن است ضروری باشد. در صورتی که فقط مجوز قرارداد مخرب صادر شده باشد، باید وضعیت آن از ابزار معتبر بررسی شود. هیچ اقدام واحدی برای همه رخدادها مناسب نیست و مسیر واکنش به نوع خطر وابسته است. نگهداری شناسه تراکنش‌ها و اسناد مربوط می‌تواند به پیگیری رسمی کمک کند.
جمع‌بندی
امنیت بلاکچین اصلی، امنیت قرارداد هوشمند و امنیت پل بین شبکه‌ها سه موضوع مستقل‌اند. قرارداد می‌تواند بدون نقض اجماع شبکه هک شود و پل ممکن است به دلیل ضعف امضاکنندگان یا مدیریت پشتوانه دارایی از دست بدهد. تحلیل ریسک نیازمند بررسی کد، اختیار ارتقا، اوراکل، نقدینگی و امکان خروج در شرایط اختلال است. گزارش حسابرسی مفید است اما تضمین کامل نیست. سرمایه‌گذار باید هر لایه اضافی قرارداد و توکن نماینده را به‌عنوان منبع خطر تازه در نظر بگیرد. مطالعه قراردادهای هوشمند و لایه دوم بلاکچین مبانی فنی این تصمیم را تکمیل می‌کند.
منابع و مراجع
این آموزش جای حسابرسی حرفه‌ای امنیت یا ارزیابی حقوقی پروتکل را نمی‌گیرد.
