سحر سعر التلاعب: تحليل ثغرة حساب الثوابت في Balancer V2

ترجمة: البلوكتشين العامي

!

في 3 نوفمبر 2025، تعرضت بركة الاستقرار القابلة للتكوين (Composable Stable Pools) في Balancer V2 والعديد من المشاريع المتفرعة على عدة سلاسل لهجوم متزامن، مما أدى إلى خسائر إجمالية تزيد عن 125 مليون دولار. أصدرت BlockSec إنذارًا في الوقت المناسب، ثم نشرت تحليلًا أوليًا.

هذه هجمة معقدة للغاية. تظهر تحقيقاتنا أن السبب الجذري هو فقدان الدقة في حساب المتغير الثابت (invariant) مما أدى إلى تلاعب في الأسعار، وبالتالي تشويه حساب أسعار BPT (رمز مجموعة Balancer). يسمح هذا التلاعب بالمتغير الثابت للمهاجمين بالربح من خلال عملية تبادل جماعي (batch swap) واحدة من تجمع مستقر معين. على الرغم من أن بعض الباحثين قدموا تحليلات غنية بالأفكار، إلا أن بعض التفسيرات قد تكون مضللة، ولم يتم توضيح السبب الجذري وعملية الهجوم بشكل كامل. يهدف هذا المدونة إلى تقديم تحليل تقني شامل ودقيق لهذا الحدث.

النقاط الرئيسية (TL;DR)

• السبب الجذري: عدم اتساق التقريب وفقدان الدقة

  • عملية التكبير (upscaling) تستخدم التقريب الأحادي (التقريب للأسفل)، بينما عملية التصغير (downscaling) تستخدم التقريب الثنائي (التقريب للأعلى والأسفل).
  • هذا التناقض يسبب فقدان الدقة، وعند استغلاله من خلال مسارات تبادل مصممة بعناية، ينتهك المبدأ القياسي “يجب أن يكون التقريب دائمًا لصالح البروتوكول”.

• تنفيذ الهجوم

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

• يستخدم المهاجمون طريقة من مرحلتين لتجنب الكشف: أولاً ينفذون الهجوم الأساسي في معاملة واحدة دون تحقيق أرباح على الفور، ثم في معاملة أخرى يحققون الأرباح من خلال سحب الأصول.

• أثر التشغيل والتضخيم

  • بسبب بعض القيود، لا يمكن إيقاف البروتوكول. وقد أدت هذه الحالة التي لا يمكن إيقاف تشغيلها إلى تفاقم تأثير الهجمات، مما أدى إلى حدوث العديد من الهجمات اللاحقة أو المقلدة.

في الأقسام التالية، سنقدم أولاً معلومات أساسية رئيسية حول Balancer V2، ثم نقوم بتحليل متعمق للمشكلات التي تم اكتشافها والهجمات ذات الصلة.

0x1 الخلفية

1. مجمع بركة V2 من نوع حمام الاستقرار

المكون المتأثر في هذا الهجوم هو مجموعة بركة بروتوكول Balancer V2. تم تصميم هذه البرك خصيصًا للحفاظ على ارتباط قريب من 1:1 (أو التداول بسعر معروف) للأصول ، وتسمح بإجراء تبادلات كبيرة بأقل تأثير على السعر ، مما يزيد بشكل كبير من كفاءة رأس المال بين الأصول المماثلة أو ذات الصلة. تحتوي كل بركة على رمز بركة Balancer الخاص بها (BPT) ، والذي يمثل حصة مقدمي السيولة في البركة والأصول الأساسية المقابلة.

تستخدم هذه المسبح الرياضيات المستقرة (نموذج StableSwap القائم على Curve) ، حيث تمثل الثابت D القيمة الإجمالية الافتراضية للمسبح.

يمكن تقريب سعر BPT إلى:

من المعادلة أعلاه، يمكننا أن نرى أنه إذا كان من الممكن تقليل D على الورق (حتى بدون أي خسارة فعلية في الأموال)، فإن سعر BPT سيبدو أرخص.

2. batchSwap() و onSwap()

يوفر Balancer V2 وظيفة batchSwap() ، التي تدعم عمليات التبادل المتعددة القفزات (multi-hop swaps) داخل Vault. بناءً على المعلمات الممررة إلى هذه الوظيفة ، هناك نوعان من عمليات التبادل:

• GIVEN_IN（“المدخلات المحددة”）：يتعين على المتصل تحديد العدد الدقيق لرموز الإدخال، ويحسب المسبح العدد المقابل من رموز الإخراج.
• GIVEN_OUT（“مخرجات محددة”）：المستدعي يحدد الكمية المتوقعة من المخرجات، ويقوم المسبح بحساب الكمية المطلوبة من المدخلات.

عادةً ما يتكون batchSwap() من تبادلات بين عدة Tokens يتم تنفيذها من خلال دالة onSwap(). يوضح ما يلي مسار التنفيذ عندما يتم تخصيص طلب التبادل SwapRequest كنوع تبادل GIVEN_OUT (يرجى ملاحظة أن ComposableStablePool ترث من BaseGeneralPool):

! [صورة] ()

يوضح ما يلي حساب amount_in في نوع التبادل GIVEN_OUT، والذي ينطوي على الثابت D.

// inGivenOut توكن x لـ y - معادلة متعددة الحدود للحل // ax = المبلغ الذي سيتم حسابه // bx = رصيد الرمز في x = bx + ax (finalBalanceIn)
// D = ثابت // A = معامل التضخيم // n = عدد الرموز // S = مجموع الأرصدة النهائية ولكن x // P = ناتج الأرصدة النهائية ولكن x

               د د ^ (n + 1)  

x ^ 2 + ( S - ---------- - D) * x - ------------- = 0
(A * n ^ n) A * n ^ 2n * P

3. التكبير والتقريب

لتحقيق حساب موحد بين أرصدة التوكنات المختلفة، يقوم Balancer بتنفيذ العمليتين التاليتين:

• زيادة الحجم (Upscaling)：قبل تنفيذ الحساب，将 الرصيد والمبلغ إلى دقة داخلية موحدة.

• الخفض (Downscaling) : تحويل النتائج إلى دقتها الأصلية، وتطبيق التقريب الموجه (على سبيل المثال، يتم عادةً تقريب مبلغ الإدخال لأعلى لضمان عدم تقاضي الرسوم بشكل غير كاف، بينما يتم غالبًا تقريب مبلغ الإخراج لأسفل).

! [صورة] ()

من الواضح أن التكبير والتصغير هما عمليتان متقابلتان من الناحية النظرية - وهما الضرب والقسمة على التوالي. ومع ذلك، هناك عدم توافق في تنفيذ هاتين العمليتين. بشكل محدد، هناك اتجاهين أو متغيرين لعملية التصغير: divUp و divDown. بالمقابل، توجد اتجاه واحد فقط لعملية التكبير، وهو mulDown.

سبب هذا التناقض غير واضح. وفقًا للتعليقات في دالة _upscale()، يعتقد المطورون أن تأثير التقريب أحادي الاتجاه ضئيل.

// قد لا يكون التكبير (Upscale) دائماً نحو نفس الاتجاه: على سبيل المثال، في عملية تبادل واحدة،

// يجب تقريبي رصيد توكن المدخلات للأعلى، بينما يجب تقريبي رصيد توكن المخرجات للأسفل. هذه هي الحالة الوحيدة التي نقوم فيها بالتقريب بنفس الاتجاه لجميع المبالغ,

// لأن تأثير هذه التقريب المتوقع هو الأدنى

// (وما لم يتم覆盖 _scalingFactor()، فلا توجد أخطاء تقريبيه).

0x2 تحليل الثغرات

المشكلة الأساسية تنبع من عملية التقريب للأسفل التي تتم أثناء تنفيذ عملية التكبير (upscaling) في دالة BaseGeneralPool._swapGivenOut(). على وجه الخصوص، تقوم دالة _swapGivenOut() بشكل خاطئ بتقريب swapRequest.amount للأسفل عبر دالة _upscale(). يتم استخدام هذه القيمة المقربة بعد ذلك كـ amountOut، وتستخدم عند حساب amountIn عبر دالة _onSwapGivenOut(). هذا السلوك يتعارض مع الممارسة القياسية التي تنص على “يجب تطبيق التقريب بطريقة تفيد البروتوكول.”

لذلك، بالنسبة للمسبح المعطى (wstETH/rETH/cbETH)، فإن المبلغ المحسوب amountIn يقلل من المدخلات المطلوبة فعليًا. وهذا يسمح للمستخدمين بتبادل كمية أقل من أحد الأصول الأساسية (مثل wstETH) إلى أصل آخر (مثل cbETH)، مما يؤدي إلى تقليل المتغير الثابت D بسبب انخفاض السيولة الفعالة. وبالتالي، فإن سعر BPT المقابل (wstETH/rETH/cbETH) يصبح مُضغَطًا بشكل مصطنع (deflated)، لأن $\text{BPT price} = \frac{D}{\text{totalSupply｝｝$.

0x3 تحليل الهجوم

نفذ المهاجمون

هجوم ذو مرحلتين، قد يكون من أجل تقليل مخاطر الكشف:

• في المرحلة الأولى، يتم استخدام النواة في تنفيذ صفقة واحدة دون تحقيق ربح فوري.
• في المرحلة الثانية، يحقق المهاجم الأرباح من خلال استخراج الأصول في معاملة أخرى.

المرحلة الأولى يمكن تقسيمها进一步 إلى مرحلتين: حساب المعلمات وتبادل الكتل. أدناه، سنستخدم مثالاً لهجوم على معاملة (TX) على Arbitrum لتوضيح هذه المراحل.

مرحلة حساب المعلمات

في هذه المرحلة، يجمع المهاجم بين الحسابات خارج السلسلة والمحاكاة على السلسلة، ويقوم بتعديل معلمات كل خطوة في المرحلة التالية (التبادل بالجملة) بدقة بناءً على الحالة الحالية لمجمع الاستقرار المركب (بما في ذلك عامل التوسع، معامل التضخيم، سعر BPT، رسوم التبادل ومعلمات أخرى). ومن المثير للاهتمام أن المهاجم قد نشر أيضًا عقدًا مساعدًا للمساعدة في هذه الحسابات، ربما لتقليل خطر “السرقة”.

أولاً، يجمع المهاجمون المعلومات الأساسية عن مجموعة الأهداف، بما في ذلك عامل التحجيم لكل توكن، ومعامل التكبير، وسعر BPT، ونسبة رسوم التبادل. ثم يحسبون قيمة رئيسية trickAmt، وهي عدد التوكنات المستهدفة التي تم التلاعب بها لإحداث فقدان في الدقة.

اعتبر عامل التحجيم للرمز الهدف (scaling factor) هو sF، احسب كما يلي:

لتحديد المعلمات المستخدمة في الخطوة 2 من المرحلة التالية (التبادل بالجملة)، استخدم المهاجم البيانات التالية لاستدعاء تابع العقد المساعد 0x524c9e20 بشكل محاكاة لاحقة:

uint256[] balances; // رصيد الـ Token في المسبح (لا يشمل BPT) uint256[] scalingFactors; // عامل التوسع لكل رمز من رموز التجمع uint tokenIn; // فهرس Token الإدخال لمحاكاة هذه القفزة uint tokenOut; // فهرس توكن الإخراج لمحاكاة هذه القفزة uint256 amountOut; // عدد توكنات الإخراج المتوقعة uint256 amp; // معامل التوسع في الكتلة uint256 fee; // نسبة رسوم التبادل في الكتلة

البيانات المرجعة هي:

uint256[] balances; // رصيد توكنات المسبح بعد التبادل (لا يشمل BPT)

بشكل محدد، يتم حساب الرصيد الأولي وعدد دورات التكرار خارج السلسلة، ويتم تمريرها كمعلمات إلى عقد المهاجم (التقارير هي على التوالي 100,000,000,000 و 25). يتم تنفيذ ثلاث تبادلات في كل عملية تكرار:

1. التبادل 1: دفع كمية الرمز المستهدف إلى trickAmt + 1، بافتراض أن اتجاه التبادل هو 0 → 1.
2. التبادل 2: الاستمرار في استخدام trickAmt لتبادل الهدفToken، سيؤدي ذلك إلى تفعيل التقريب لأسفل في استدعاء _upscale(). 320,000.

يرجى ملاحظة أنه نظرًا لاستخدام طريقة نيوتن-رافسون في حساب StableMath، قد تفشل هذه الخطوة أحيانًا. لتخفيف هذه الحالة، قام المهاجم بتنفيذ محاولتين لإعادة المحاولة، حيث يستخدم في كل مرة 9/10 من القيمة الأصلية كقيمة احتياطية.

تشتق عقود المساعدة للمهاجم من مكتبة StableMath الخاصة بـ Balancer V2، ويمكن إثبات ذلك من خلال احتوائها على رسالة خطأ مخصصة على طراز “BAL”.

$d$ مرحلة التبادل الجماعي

ثم يمكن تقسيم عملية batchSwap###( إلى ثلاث خطوات:

1. الخطوة 1: يقوم المهاجم بتبديل BPT )wstETH/rETH/cbETH( إلى الأصول الأساسية، بدقة لضبط رصيد توكن واحد (cbETH) إلى حافة حدود التقريب (amount = 9). هذا يهيئ الظروف لفقدان الدقة في الخطوة التالية.
2. الخطوة 2: بعد ذلك، يستخدم المهاجم كمية مصممة بعناية (= 8) للتبادل بين أصل أساسي آخر (wstETH) و cbETH. نظرًا لتقريب عدد الرموز لأسفل عند توسيعها، تصبح Δx المحسوبة أقل قليلاً (من 8.918 إلى 8)، مما يؤدي إلى تقدير منخفض لـ Δy، وبالتالي يجعل الثابت (D، من نموذج StableSwap الخاص بـ Curve) أصغر. نظرًا لأن $\text{سعر BPT} = \frac{D}{\text{totalSupply｝｝$، يتم ضغط سعر BPT بشكل مصطنع.

! [صورة] )( 3. الخطوة 3: يقوم المهاجم بعكس تحويل الأصول الأساسية إلى BPT، لاستعادة التوازن، بينما يحقق ربحًا من سعر BPT المنخفض.

0x4: الهجمات والخسائر

لقد قمنا بتلخيص هذه الهجمات والخسائر المقابلة لها في الجدول أدناه، حيث تجاوزت الخسائر الإجمالية 1.25 مليار دولار.

! [صورة] )(

0x5 استنتاج

تتعلق هذه الحادثة بسلسلة من المعاملات الهجومية على بروتوكول Balancer V2 ومشاريعها المتفرعة، مما أدى إلى خسائر مالية كبيرة. بعد الهجوم الأولي، تم ملاحظة عدد كبير من المعاملات اللاحقة والمقلدة عبر عدة شبكات. تبرز هذه الحادثة عدة دروس رئيسية حول تصميم البروتوكولات الأمنية في DeFi:

• سلوك التقريب وفقدان الدقة: يختلف التقريب أحادي الاتجاه (التقريب لأسفل) المستخدم في عمليات التكبير (upscaling) عن التقريب ثنائي الاتجاه (التقريب لأعلى ولأسفل) المستخدم في عمليات التصغير (downscaling). لمنع ثغرات مماثلة، يجب أن يتبنى البروتوكول حسابات بدقة أعلى، ويجب تنفيذ فحوصات تحقق قوية. يجب الالتزام بمبدأ “يجب أن يكون التقريب دائمًا لصالح البروتوكول”.
• تطور استغلال الثغرات: نفذ المهاجمون استغلال ثغرة معقدة من مرحلتين تهدف إلى تجنب الكشف. في المرحلة الأولى، قام المهاجم بتنفيذ الاستغلال الأساسي في صفقة واحدة دون تحقيق ربح فوري. في المرحلة الثانية، حقق المهاجم ربحًا من خلال استخراج الأصول في صفقة أخرى. وهذا يبرز مرة أخرى السباق المستمر بين الباحثين في الأمن والمهاجمين.
• وعي العمليات والاستجابة للتهديدات: تؤكد هذه الحادثة على أهمية التنبيهات الفورية بشأن حالة التهيئة والتشغيل، بالإضافة إلى آليات الكشف عن التهديدات والوقاية النشطة، لتخفيف الأضرار المحتملة الناتجة عن الهجمات المستمرة أو المقلدة.

بينما تحافظ على التشغيل واستمرارية الأعمال، يمكن لمشاركة الصناعة الاستفادة من BlockSec Phalcon كخط دفاع أخير لحماية أصولهم. فريق خبراء BlockSec جاهز دائمًا لإجراء تقييم أمان شامل لمشروعك.

رابط المقال:

المصدر: