تفسير معمق لهجوم Balancer V2: آلية الثغرة، خطوات الهجوم والدروس المستفادة

سلسلة Chainfeeds دليل القراءة:

قام المهاجمون بتعيين المعلمات عمدًا، بما في ذلك عدد التكرارات ومبلغ الإدخال، لتعظيم تأثير فقدان الدقة.

مصدر المقال:

كاتب المقال:

BlockSec

وجهة نظر:

BlockSec: في 3 نوفمبر 2025، تعرضت Composable Stable Pool في Balancer V2، بالإضافة إلى عدة مشاريع أخرى على السلسلة مبنية على Fork منها، لهجوم منسق عبر السلاسل، مما أدى إلى خسائر إجمالية تجاوزت 125 ملايين دولار. أصدرت BlockSec تحذيرًا في الوقت المناسب، وتبعت ذلك بتحليل أولي. كان هذا هجومًا عالي التعقيد. أظهرت تحقيقاتنا أن السبب الجذري يكمن في فقدان الدقة في حساب الثوابت، حيث تم استغلال فقدان الدقة لتحفيز التلاعب بالأسعار، مما أثر على سعر BPT (Balancer Pool Token). استغل المهاجمون عملية batchSwap واحدة لتحقيق أرباح من مجمعات مستقرة محددة. المكون المتأثر هو Composable Stable Pool في Balancer V2. تم تصميم هذا النوع من المجمعات خصيصًا للأصول المتوقع أن تحافظ على نسبة تبادل قريبة من 1:1، مما يسمح بتنفيذ صفقات كبيرة بأقل انزلاق، ويزيد بشكل كبير من كفاءة رأس المال للأصول المماثلة أو المرتبطة. كل مجمع لديه BPT خاص به، ويمكن التعبير عن سعره تقريبا بالمعادلة: سعر BPT = D / totalSupply، حيث D هو الثابت في الرياضيات المستقرة، ويمثل القيمة الإجمالية الافتراضية للمجمع. من المعادلة يمكن ملاحظة أنه إذا تم تقليل D رياضيًا (حتى لو لم تُفقد الأموال الحقيقية)، سيظهر سعر BPT أقل. يوفر Balancer V2 دالة batchSwap () التي تتيح تنفيذ Swap متعدد القفزات داخل Vault، ويوجد في SwapRequest نمطان: GIVEN_IN و GIVEN_OUT. في وضع GIVEN_OUT، يحدد المتصل مبلغ الخرج المتوقع، ويتولى المجمع حساب مبلغ الإدخال المطلوب. في المجمعات المستقرة، عند حساب مبلغ الإدخال المطلوب amountIn، يجب حل معادلة متعددة الحدود بناءً على معادلة الثابت، وتتم هذه الحسابات بشكل موحد من خلال Upscaling و Downscaling. نظريًا، هما عمليتان متعاكستان، لكن التنفيذ الفعلي به اتجاهات تقريب مختلفة: الرفع (Upscaling) يستخدم فقط التقريب للأسفل (mulDown)، بينما الخفض (Downscaling) قد يستخدم التقريب للأعلى أو للأسفل (divUp / divDown). هذا التناقض هو ما أتاح فرصة للهجوم. يكمن أصل الثغرة في استخدام التقريب للأسفل عند Upscaling لقيمة swapRequest.amount في BaseGeneralPool._swapGivenOut (). القيمة التي تم تقريبها للأسفل تُستخدم كـ amountOut في إدخال _onSwapGivenOut ()، مما يؤدي إلى أن المبلغ النهائي المحسوب لـ amountIn يكون أقل من المطلوب فعليًا، مخالفًا لمبدأ التقريب الذي يجب أن يكون لصالح البروتوكول. بالنسبة لمجمعات مثل (wstETH / rETH / cbETH)، يمكن للمهاجمين استخدام كمية أقل من أصل معين للحصول على كمية أكبر من أصل آخر، مما يقلل من الثابت D، وبالتالي يخفض سعر BPT. نفذ المهاجمون الهجوم على مرحلتين. المرحلة الأولى تنفذ المنطق الأساسي للهجوم في معاملة واحدة دون تحقيق ربح فوري؛ المرحلة الثانية يتم فيها سحب الأرباح من خلال معاملة منفصلة. تنقسم المرحلة الأولى إلى خطوتين: حساب المعلمات وتنفيذ batch swap. على سبيل المثال، في معاملة الهجوم على سلسلة Arbitrum (TX: 0x7da32e…55773)، حصل المهاجم أولاً على معلمات المجمع، بما في ذلك عوامل التحجيم، A (عامل التضخيم)، سعر صرف BPT، رسوم swap، إلخ، ثم حسب trickAmt، ونفذ محاكاة من خلال نشر عقد مساعد. استخدم المهاجم مزيجًا من الحسابات خارج السلسلة والمحاكاة على السلسلة لضبط معلمات swap التالية بدقة، بما في ذلك عدد التكرارات وقيم الإدخال والإخراج لكل مرة. في كل تكرار، تم تنفيذ ثلاث خطوات swap: في الخطوة الأولى، تم دفع كمية التوكن الهدف إلى trickAmt + 1؛ في الخطوة الثانية، استمر في swap لإخراج التوكن الهدف، مما أدى إلى تفعيل التقريب للأسفل في _upscale ()؛ في الخطوة الثالثة، تم تنفيذ swap عكسي، حيث تم تقليص رصيد المجمع "بإزالة أعلى منزلتين عشريتين" ثم إعادة التبادل. على سبيل المثال: 324,816 → 320,000. في بعض الحالات، بسبب استخدام طريقة Newton–Raphson في حل الرياضيات المستقرة، قد تفشل العملية، وكان لدى المهاجم خطتي احتياط، حيث أعاد المحاولة باستخدام 9/10 من القيمة الأصلية. بعد وقوع الهجوم، وبسبب عدم إمكانية إيقاف بعض آليات Balancer، تفاقمت آثار الهجوم، وتبعت ذلك هجمات مقلدة على عدة سلاسل، ليصل إجمالي الخسائر إلى أكثر من 125 ملايين دولار. كشفت هذه الحادثة عن أربع مشكلات رئيسية في البروتوكولات اللامركزية: آليات التقريب غير المتسقة، تطور أساليب المهاجمين المستمر، عدم القدرة على الإيقاف مما يؤدي إلى تضخيم الخسائر، ونقص المراقبة اللحظية لحالة التهيئة والتشغيل والصيانة. يسمح الرفع بالتقريب للأسفل فقط، بينما يسمح الخفض بالتقريب في كلا الاتجاهين، وهذا التفاوت يمكن أن يتراكم إلى فقدان دقة قابل للاستغلال في ظل معلمات مصطنعة متطرفة. كان من المفترض أن يكون اتجاه التقريب دائمًا لصالح البروتوكول، لكنه في هذه الحالة أضر بمصالح البروتوكول. استخدم المهاجمون أسلوب المرحلتين، حيث يتم تنفيذ الهجوم في المرحلة الأولى دون تحقيق ربح على الورق، ثم يتم السحب في المرحلة الثانية، لتجنب نماذج المراقبة على السلسلة. كل خطوة من الهجوم جمعت بين المحاكاة خارج السلسلة وعلى السلسلة، حتى أن العقد المساعد أعاد استخدام تنفيذ StableMath الخاص بـ Balancer، مع الحفاظ على رسائل الخطأ نفسها. بعد الهجوم، تبعت عدة سلاسل أخرى، وتأثرت العديد من مشاريع Fork، مما يوضح أنه طالما أن الرياضيات المستقرة ومنطق التقريب متطابقان، يمكن أن تنتشر الثغرة عبر النظام البيئي. توضح الحادثة أن بروتوكولات DeFi بحاجة إلى عمليات رياضية أكثر دقة، والتحقق الصارم من التقريب، وآليات محاكاة المسارات المشبوهة، بالإضافة إلى القدرة على الإيقاف الطارئ في الحالات الشاذة. [النص الأصلي بالإنجليزية]