هک استخر پنکیک‌سواپ؛ سرقت ۱.۱ میلیون دلار از OLPC/LABUBU با خطای توکن‌سوزی

هک استخر پنکیک‌سواپ؛ سرقت ۱.۱ میلیون دلار از OLPC/LABUBU با خطای توکن‌سوزی

این خبر و تحلیل بر اساس گزارش و بررسی سایت Cointelegraph تهیه شده است.

بازار دیفای در ماه‌های اخیر بار دیگر نشان داده که حتی آسیب‌پذیری‌های به‌ظاهر کوچک در منطق توکن‌ها و استخرهای نقدینگی می‌توانند به سرقت‌های میلیون‌دلاری ختم شوند. تازه‌ترین نمونه از این دست، حمله به استخر OLPC/LABUBU در PancakeSwap V2 روی شبکه BNB Chain است؛ حمله‌ای که به تخلیه حدود ۱.۱ میلیون دلار از دارایی‌های استخر منجر شد و دوباره نگاه‌ها را به سمت ریسک‌های فنی پروژه‌های کوچک‌تر در اکوسیستم دیفای برگرداند.

بر اساس گزارش‌های منتشرشده، مهاجم در این حمله از یک باگ ناهماهنگی ذخایر یا reserve desynchronization سوءاستفاده کرده است؛ مشکلی که از تعامل میان منطق بازارساز خودکار استخر و مکانیزم تورم‌زدا یا همان deflationary mechanism توکن OLPC ناشی می‌شد. نتیجه این اختلال آن بود که ذخایر ثبت‌شده استخر با موجودی واقعی توکن‌ها هم‌خوانی خود را از دست دادند و همین شکاف، امکان خرید LABUBU با قیمت‌هایی به‌مراتب پایین‌تر از سطح واقعی بازار را برای مهاجم فراهم کرد. اگرچه در نگاه اول این اتفاق شاید شبیه یکی دیگر از ده‌ها حمله روزمره به پروژه‌های کوچک دیفای به‌نظر برسد، اما از نظر فنی نمونه مهمی از آسیب‌پذیری‌هایی است که نه لزوماً از خود صرافی غیرمتمرکز، بلکه از طراحی داخلی توکن و نحوه تعامل آن با استخر نقدینگی سرچشمه می‌گیرند. همین مسئله باعث شده حمله OLPC/LABUBU فراتر از یک خبر کوتاه، به نمونه‌ای هشداردهنده برای توسعه‌دهندگان، سرمایه‌گذاران و کاربران دیفای تبدیل شود.

⬅️ کارگزاری و سکوی تبادل تخصصی OTC رمزدارایی اتریوم (ETH) در ایران »» مشاهده مقاله

حمله به OLPC/LABUBU چگونه انجام شد؟

طبق اطلاعات اولیه، حمله در ۲۰ ژوئن رخ داد و مهاجم توانست با دستکاری وضعیت استخر OLPC/LABUBU، حدود ۱.۱۱۵ میلیون USDT سود به‌دست آورد. قلب این حمله، یک ناهماهنگی میان ذخایر کش‌شده استخر و موجودی واقعی توکن‌ها بود. در بازارسازهای خودکار مبتنی بر مدل حاصل‌ضرب ثابت، مانند استخرهای PancakeSwap V2، قیمت توکن‌ها بر اساس نسبت ذخایر دو دارایی موجود در استخر تعیین می‌شود. اگر به هر دلیل این ذخایر با موجودی واقعی قرارداد یکسان نباشند، قیمت محاسبه‌شده می‌تواند از واقعیت فاصله بگیرد و زمینه برای سوءاستفاده فراهم شود. در این پرونده، مهاجم با یک انتقال کوچک از قرارداد خود، مکانیزم خاص توکن OLPC را فعال کرد. این انتقال باعث شد حجم بزرگی از توکن‌های OLPC و LABUBU مستقیماً از موجودی استخر سوزانده و به یک آدرس مرده ارسال شود. گزارش‌ها از سوختن حدود ۵۱.۹ میلیون OLPC و ۱۲۴ هزار LABUBU خبر می‌دهند؛ رقمی که برای یک استخر کوچک تا متوسط، بسیار قابل‌توجه است و می‌تواند ساختار قیمت را به‌طور کامل برهم بزند. مشکل اینجا بود که در همان لحظه، ذخایر ثبت‌شده در استخر به‌روز نشدند. به بیان ساده، قرارداد استخر هنوز تصور می‌کرد مقدار مشخصی توکن در استخر وجود دارد، در حالی که موجودی واقعی به‌شدت کاهش یافته بود. همین شکاف میان «آنچه استخر فکر می‌کند دارد» و «آنچه واقعاً در استخر مانده» همان ناهماهنگی ذخایر بود که مهاجم از آن استفاده کرد.

ناهماهنگی ذخایر چرا خطرناک است؟

این نوع حمله از نظر ساختار، شباهت‌هایی با برخی حملات قبلی در BNB Chain دارد؛ حملاتی که در آن‌ها منطق سوزاندن، مینت یا انتقال توکن باعث برهم‌خوردن نسبت استخر شده و مهاجم با سوءاستفاده از قیمت تحریف‌شده، دارایی ارزشمندتر را از استخر خارج کرده است. به همین دلیل، حمله اخیر فقط یک خطای تصادفی در یک پروژه ناشناس نیست؛ بلکه بخشی از یک الگوی تکرارشونده در پروژه‌هایی است که توکن‌های سفارشی با رفتارهای غیرمعمول را به استخرهای AMM متصل می‌کنند.

ریشه آسیب‌پذیری از کجا آمده بود؟

یکی از مهم‌ترین بخش‌های این ماجرا، منشأ آسیب‌پذیری است. تحلیل‌های اولیه نشان می‌دهد مشکل ممکن است از مدت‌ها قبل در قرارداد OLPC وجود داشته و به‌نوعی در طراحی توکن یا تنظیمات مدیریتی آن تعبیه شده باشد. بر اساس گزارش‌ها، حدود ۴۶ روز پیش از حمله، مالک توکن پارامتری با نام decimalsValue را از مقدار ۱ به عددی بسیار بزرگ تغییر داده بود؛ تغییری که ظاهراً به تابع _update() اجازه می‌داد در شرایط خاص، سوزاندن بسیار بزرگ‌تری را فعال کند. همین نکته باعث شده برخی ناظران نسبت به ماهیت این باگ تردید داشته باشند. از یک سو، ممکن است ماجرا صرفاً یک ضعف فنی ناشی از تنظیم نادرست پارامترها بوده باشد؛ از سوی دیگر، زمان‌بندی تغییرات و باقی‌ماندن این شرایط تا زمان حمله، این پرسش را ایجاد کرده که آیا آسیب‌پذیری از مدت‌ها قبل در قرارداد تعبیه شده بود یا نه. این موضوع زمانی حساس‌تر می‌شود که بدانیم پیش از انصراف از مالکیت قرارداد نیز سطح این پارامتر به‌شکل غیرعادی بالا تنظیم شده بود. در اکوسیستم دیفای، چنین سناریوهایی بی‌سابقه نیست. گاهی پروژه‌ها با ادعای غیرمتمرکز بودن، قراردادهایی را منتشر می‌کنند که در ظاهر مالکیت آن‌ها رها شده، اما در عمل برخی تنظیمات خطرناک یا پارامترهای دست‌کاری‌شده از قبل در آن‌ها باقی مانده است. در این حالت، تشخیص اینکه حمله حاصل یک خطای قدیمی، طراحی ضعیف یا حتی یک آسیب‌پذیری تعبیه‌شده بوده، به بررسی‌های دقیق‌تر نیاز دارد.

مهاجم چگونه سود را نقد کرد؟

پس از ایجاد ناهماهنگی در ذخایر و خرید LABUBU با نرخ‌های غیرواقعی، مهاجم توانست موقعیت خود را به سود تبدیل کند. گزارش‌ها می‌گویند خروجی نهایی حمله حدود ۱.۱۱۵ میلیون USDT بوده است. در برخی گزارش‌های اولیه همچنین اشاره شده که بخشی از وجوه سرقت‌شده بعداً به مسیرهای دیگری منتقل شده و حتی احتمال واریز بخشی از آن به Tornado Cash نیز مطرح شده است؛ هرچند در زمان انتشار گزارش‌های اولیه، هنوز جزئیات کامل مسیر جابه‌جایی وجوه به‌طور رسمی تأیید نشده بود.

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

واکنش PancakeSwap و وضعیت مسئولیت صرافی

پس از انتشار خبر حمله، PancakeSwap اعلام کرد که در بررسی اولیه خود، مشکلی در قراردادهای هوشمند اصلی صرافی مشاهده نکرده است. این نکته از نظر فنی مهم است، زیرا نشان می‌دهد آسیب‌پذیری به‌احتمال زیاد در سطح توکن OLPC یا نحوه تعامل آن با استخر بوده، نه در منطق پایه PancakeSwap V2. در واقع، صرافی غیرمتمرکز در اینجا بیشتر نقش بستر اجرای معاملات را داشته و مشکل از دارایی‌ای آمده که وارد استخر شده است. این مسئله یکی از چالش‌های همیشگی دیفای را دوباره برجسته می‌کند: کاربران معمولاً وقتی نام یک صرافی بزرگ مانند PancakeSwap را کنار خبر هک می‌بینند، ممکن است تصور کنند خود صرافی هک شده است؛ در حالی که در بسیاری از موارد، ریشه بحران در توکن‌های شخص ثالث، قراردادهای سفارشی یا طراحی ضعیف استخرهای فرعی قرار دارد. به همین دلیل، بررسی منشأ واقعی آسیب‌پذیری برای ارزیابی ریسک اهمیت زیادی دارد.

حمله OLPC/LABUBU در بستر موج جدید هک‌های BNB Chain

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

در این فضا، هر مکانیزم غیرمعمول مانند توکن‌سوزی پویا، تغییرات عرضه، کارمزدهای انتقال پیچیده، مینت وابسته به رویداد یا پارامترهای مدیریتی قابل‌تغییر می‌تواند به نقطه شکست تبدیل شود؛ به‌ویژه اگر با استخرهای AMM استاندارد ترکیب شود. حمله OLPC/LABUBU دقیقاً یادآور همین خطر است: گاهی مشکل نه در AMM، بلکه در این فرض اشتباه نهفته است که هر نوع توکن سفارشی را می‌توان بدون ریسک جدی به یک استخر نقدینگی استاندارد متصل کرد.

سوال متداول