تحليل تقني: كيف تم اختراق Balancer بمبلغ 120 مليون دولار وأين تكمن الثغرة؟

عنوان المقال الأصلي: "تحليل تقني لثغرة اختراق Balancer بقيمة 120 مليون دولار"
المصدر الأصلي: ExVul Security

مقدمة

في 3 نوفمبر 2025، تعرض بروتوكول Balancer للهجوم على سلاسل متعددة بما في ذلك Arbitrum و Ethereum، مما أدى إلى خسارة أصول بقيمة 120 مليون دولار. كان الهجوم يرجع في المقام الأول إلى ثغرة مزدوجة تتعلق بفقدان الدقة (precision loss) والتلاعب بالقيمة الثابتة (Invariant).

حافظت البنية التحتية لـ Chainlink منذ فترة طويلة على أعلى المعايير في مجال Web3، مما يجعلها خيارًا طبيعيًا لـ X Layer، المكرسة لتوفير أدوات على مستوى مؤسسي للمطورين.

تكمن المشكلة الرئيسية في هذا الهجوم في منطق البروتوكول للتعامل مع المعاملات الصغيرة. عندما يقوم المستخدمون بإجراء تبادلات بمبالغ صغيرة، يستدعي البروتوكول دالة _upscaleArray، التي تستخدم mulDown لتقريب القيم للأسفل. عندما يصل الرصيد في المعاملة ومبلغ الإدخال كلاهما إلى حد تقريب معين (على سبيل المثال، نطاق 8-9 wei)، يحدث خطأ في الدقة النسبية ملحوظ.

ينتشر خطأ الدقة هذا إلى حساب القيمة الثابتة D للبروتوكول، مما يتسبب في انخفاض غير طبيعي في قيمة D. تؤدي تقلبات قيمة D مباشرة إلى خفض سعر Balancer Pool Token (BPT) في بروتوكول Balancer. استغل المخترق سعر BPT المكبوت هذا من خلال مسار تداول مخطط له مسبقًا لإجراء مراجحة، مما أدى في النهاية إلى خسارة فادحة في الأصول.

المعاملة المستغلة:

https://etherscan.io/tx/0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742

معاملة تحويل الأصول:

https://etherscan.io/tx/0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569

تحليل تقني

ناقل الهجوم

كانت نقطة دخول الهجوم هي عقد Balancer: Vault، مع دالة الإدخال المقابلة وهي batchSwap، والتي تستدعي داخليًا onSwap لتبادل التوكن.

من منظور معلمات الدالة والقيود، يمكن الحصول على عدة معلومات:

1. يحتاج المهاجم إلى استدعاء هذه الدالة من خلال Vault ولا يمكنه استدعاؤها مباشرة.

2. ستستدعي الدالة داخليًا _scalingFactors() للحصول على عامل القياس لعمليات القياس.

3. تتركز عملية القياس إما في _swapGivenIn أو _swapGivenOut.

تحليل نمط الهجوم

آلية حساب سعر BPT

في نموذج المجمع المستقر لـ Balancer، يعد سعر BPT نقطة مرجعية حاسمة تحدد مقدار BPT الذي يحصل عليه المستخدم ومقدار الأصول التي يحصل عليها كل BPT.

في حساب تبادل المجمع:

حيث الجزء الذي يعمل كـ مرساة سعر BPT هو قيمة ثابتة D، مما يعني أن التحكم في سعر BPT يتطلب التحكم في D. دعونا نحلل عملية حساب D بشكل أكبر:

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

السبب الجذري لفقدان الدقة

عملية القياس:

كما هو موضح أعلاه، عند المرور عبر _upscaleArray، إذا كان الرصيد صغيرًا جدًا (على سبيل المثال، 8-9 wei)، فإن التقريب للأسفل في mulDown سيؤدي إلى فقدان كبير في الدقة.

تفاصيل عملية الهجوم

المرحلة 1: التعديل إلى حد التقريب

المرحلة 2: إثارة فقدان الدقة (الثغرة الأساسية)

المرحلة 3: استغلال سعر BPT المكبوت للربح

أعلاه، يستخدم المهاجم Batch Swap لإجراء تبادلات متعددة في معاملة واحدة:

1. التبادل الأول: BPT → cbETH (تعديل الرصيد)

2. التبادل الثاني: wstETH (8) → cbETH (إثارة فقدان الدقة)

3. التبادل الثالث: الأصول الأساسية → BPT (جني الأرباح)

تحدث كل هذه التبادلات في نفس معاملة batch swap، وتتشارك نفس حالة الرصيد، لكن كل تبادل يستدعي _upscaleArray لتعديل مصفوفة الأرصدة.

نقص آلية الاستدعاء

يتم بدء العملية الرئيسية بواسطة Vault. كيف يؤدي هذا إلى تراكم فقدان الدقة؟ الإجابة تكمن في آلية تمرير مصفوفة الأرصدة.

بالنظر إلى الكود أعلاه، على الرغم من أن Vault ينشئ مصفوفة currentBalances جديدة في كل مرة يتم فيها استدعاء onSwap، في Batch Swap:

1. بعد التبادل الأول، يتم تحديث الرصيد (ولكن بسبب فقدان الدقة، قد تكون القيمة المحدثة غير دقيقة)

2. يستمر التبادل الثاني في الحساب بناءً على نتيجة التبادل الأول

3. يتراكم فقدان الدقة، مما يتسبب في النهاية في انخفاض القيمة الثابتة D بشكل كبير

المشكلة الرئيسية:

ملخص

يمكن تلخيص هجوم Balancer للأسباب التالية:

1. دالة القياس تستخدم التقريب للأسفل: تستخدم _upscaleArray دالة mulDown للقياس، مما يؤدي إلى فقدان كبير في الدقة النسبية عندما يكون الرصيد صغيرًا جدًا (على سبيل المثال، 8-9 wei).

2. حساب القيمة الثابتة حساس للدقة: يعتمد حساب القيمة الثابتة D على مصفوفة الأرصدة المقاسة، ويؤثر فقدان الدقة بشكل مباشر على حساب D، مما يتسبب في انخفاض D.

3. نقص التحقق من تغيير القيمة الثابتة: أثناء عملية التبادل، لم يكن هناك تحقق لضمان أن التغيير في القيمة الثابتة D كان ضمن نطاق معقول، مما سمح للمهاجمين باستغلال فقدان الدقة بشكل متكرر لقمع سعر BPT.

4. تراكم فقدان الدقة في Batch Swaps: ضمن نفس batch swap، يتراكم فقدان الدقة من تبادلات متعددة ويؤدي في النهاية إلى خسائر مالية كبيرة.

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

هذا المقال عبارة عن مساهمة ولا يمثل وجهات نظر BlockBeats.