50 مليون USDT تم تبادلها مقابل 35,000 دولار أمريكي AAVE: كيف حدثت الكارثة؟ من يجب أن نلوم؟

هذه المقالة من: @Ehsan1579

تم تجميعها بواسطة: إيثان، أو دايلي بلانيت دايلي

مجرد النظر إلى عنوان الحدث، قد يعتقد المرء عن طريق الخطأ أن هذه حالة من هجوم استغلال ثغرة.

جوهر الحدث هو: شخص ما تبادل USDT بقيمة 50.4 مليون دولار مقابل AAVE بقيمة 35,900 دولار فقط.

لقد صدمت حقًا عندما سمعت عن هذا لأول مرة. لذلك، قمت بمراجعة شاملة للحدث بأكمله: تتبع المعاملات، مسارات الحل، استدعاءات العقود، الاحتياطيات التاريخية، بيانات التسوية، عمليات المحول، كود واجهة Aave، SDK قرض CoW الفوري، وكود التوجيه الذي يحدد ما إذا كانت الاقتباسات "معقولة".

هذه ليست هجمة هاكر. البروتوكول الأساسي لـ Aave لم يرتكب خطأ. تسوية CoW لم ترتكب خطأ. Uniswap لم يرتكب خطأ. SushiSwap لم يرتكب خطأ. كانت المعاملة صالحة، وكانت التوقيع صالحة، وتم تنفيذ جميع العقود بدقة وفقًا للكود. ومع ذلك، تم تدمير تقريبًا كل القيمة الاقتصادية ببساطة لأن التوجيه الذي سُمح له بأخذه كان غير معقول بشكل مثير للسخرية.

سلسلة العامة لم يكن لديها مشكلة؛ كانت المشكلة في التوجيه.

في رأيي، التقليل من أهمية هذه الحادثة باعتبارها مجرد "خطأ تشغيلي من المستخدم" ليس موقفًا موضوعيًا أو صارمًا. في الواقع، أكمل المستخدم توقيع الطلب، لكن النظام البرمجي بالكامل سمح بعملية تتعلق بحوالي 50 مليون دولار كضمان لإكمال الاقتباس، والتوقيع، وتخطيط التوجيه، والتنفيذ النهائي، وكلها تشير إلى تجمع سيولة منخفض يحتوي فقط على حوالي 331 AAVE. كان يجب أن يكون هذا مستحيلاً تمامًا، وعلى الأقل كان يجب أن يتم اعتراضه ورفضه بشكل قاطع من قبل النظام قبل بدء مرحلة التسوية.

معلومات أساسية تتبع المعاملة

هاش هذه المعاملة غير الطبيعية هو: 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f، تم تأكيده في 12 مارس 2026، عند ارتفاع كتلة الشبكة الرئيسية للإيثيريوم 24643151، مع فهرس المعاملة 1، مستهلكًا 3,780,570 وحدة غاز، وتم تنفيذ المعاملة بنجاح. عنوان المحفظة الذي ينتمي إلى الطلب يبدأ بـ 0x98b9، بينما يبدأ عنوان المحلل الفعلي (مرسل المعاملة) بـ 0x3980، والذي تم تمييزه كـ tsolver في بيانات منافسة CoW.

أولاً، من المهم أن نفهم أن هذا ليس تبادلًا بسيطًا من USDT إلى AAVE على مستوى المحفظة. الرمز المبيع هو aEthUSDT، وهو شهادة إيداع USDT ذات الفائدة على منصة Aave. الرمز المشتراة هو aEthAAVE، وهو شهادة إيداع AAVE ذات الفائدة على منصة Aave. لذلك، هذا في الواقع تبادل ضمانات Aave تم إجراؤه من خلال نظام تسوية بروتوكول CoW وعملية محول القرض الفوري.

قبل المعاملة، كانت المحفظة تحتوي على حوالي 50,432,693.075254 aEthUSDT و0 aEthAAVE. بعد المعاملة، تبقى منها فقط 4.980399 aEthUSDT وتلقت 327.241335505966487788 aEthAAVE. في الواقع، باعت المحفظة تقريبًا كل مركزها.

تشير البيانات الوصفية بشكل أوضح إلى أن التوجيه كان "سامًا" بالفعل قبل التنفيذ. جاء الطلب من عملية aave-v3-interface-collateral-swap. عرضت واجهة برمجة تطبيقات CoW ذلك كأمر بيع موقع، بينما أشارت البيانات الوصفية للتطبيق إلى أنه تبادل ضمانات بأسلوب السوق باستخدام 121 نقطة أساس من الانزلاق الذكي. كان مقدار البيع الموقع 50,432,688.41618 aEthUSDT. كان الحد الأدنى لمقدار الشراء الموقع 324.949260918413591035 aEthAAVE. المبلغ الفعلي للتسوية المدفوعة كان 327.241335505966487788 aEthAAVE.

هذه تفاصيل مهمة للغاية. لم يتوقع الطلب الحصول على آلاف من AAVE، فقط ليتم تدميره بطريقة ما في منتصف الطريق. منذ البداية، تم بناؤه حول نتيجة تزيد عن ثلاثمائة AAVE.

رابط كامل لانهيار التوجيه

بمجرد أن تتبع تتبع المعاملة، تكون العملية بأكملها مباشرة بشكل صارخ.

يعتمد تدفق رأس المال من المستوى الأعلى على عقد تسوية GPv2Settlement لبروتوكول CoW الذي يبدأ بـ 0x9008. أولاً، يكمل عقد HooksTrampoline الذي يبدأ بـ 0x60bf عملية تفويض aEthUSDT، مما يسمح لموزع خزينة CoW باستخراج أصول المستخدمين دون تفويض معاملة منفصل؛ ثم، يستخرج عقد GPv2VaultRelayer الذي يبدأ بـ 0xc92e 50,432,688.41618 aEthUSDT من محفظة المستخدم إلى عملية التسوية. حتى هذه النقطة، تتوافق جميع العمليات مع المنطق العادي.

ثم يمنح عقد التسوية سلطة تشغيل aEthUSDT لعقد مساعد غير موثق يبدأ بـ 0xd524 ويبدأ مكالمة عبر محدد الوظيفة 0x494b3137؛ ثم ينقل هذا العقد المساعد سلطة التنفيذ إلى عقد منفذ غير موثق يبدأ بـ 0x699c، في هذه المرحلة يتم الكشف عن الصورة الكاملة لتوجيه المعاملة غير العادية.

تشير أول مكالمة فعالة إلى عقد تجمع السيولة Aave الذي يبدأ بـ 0x87870، والذي يدمر aEthUSDT من خلال وظيفة السحب (المحدد 0x69328dec) لاسترداد USDT الأصلي؛ ثم ينتقل التوجيه إلى تجمع تداول Uniswap V3 العميق USDT/WETH الذي يبدأ بـ 0x4e68، مبادلاً جميع 50,432,688.41618 USDT مقابل 17,957.810805702142342238 WETH.

المعاملة في هذه المرحلة طبيعية تمامًا: سعر الصرف حوالي 2808.4 USDT مقابل 1 WETH، متسق مع السوق في ذلك الوقت، دون مشاكل نقص السيولة، ودون انحرافات حسابية؛ لا توجد شذوذات في رابط المعاملة الأولى.

تظهر المشكلة في القفزة الثانية؛ بمجرد أن ترى احتياطيات السيولة، فإن بقية القصة حتمية.

بعد أن يحصل المنفذ على 17,957.810805702142342238 WETH، ينقل جميع الأموال إلى تجمع تداول SushiSwap V2 AAVE/WETH على العنوان 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.

تحققت من بيانات احتياطي السيولة التاريخية لهذا التجمع قبل حدوث المعاملة غير العادية (ارتفاع الكتلة 24643150)، وكان التجمع يحتفظ فقط بـ:

331.631982538108027323 AAVE، 17.653276196397688066 WETH

هذه ليست خطأ في إدخال البيانات، بل حقيقة لا يمكن إنكارها.

هذا التوجيه للمعاملة حقن ما يقرب من 17,958 WETH بالكامل في تجمع تداول صغير يحتفظ فقط بـ 17.65 WETH، مما يتوافق مع إجمالي مخزون AAVE يبلغ فقط 331.63 AAVE، مع حجم WETH المدخلات حوالي 1017 مرة من احتياطيات WETH في التجمع.

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

نفذ تجمع AMM العملية وفقًا للخوارزمية المحددة، مما استنفد تقريبًا جميع احتياطيات AAVE في التجمع.

أدى زوج تداول SushiSwap إلى تفعيل حدث تبادل Swap الأساسي: نقل المنفذ 17,957.810805702142342238 WETH، واسترد فقط 331.305315608938235428 AAVE. بعد المعاملة، كانت السيولة المتبقية في التجمع تقريبًا:

0.326666929169791895 AAVE، 17,975.464081898540030304 WETH

بعبارات بسيطة، تم استنزاف حوالي 99.9% من احتياطيات AAVE في المسبح في خطوة واحدة.

استنادًا إلى الاحتياطيات قبل المعاملة، كان سعر AAVE الضمني في المسبح حوالي 149.50 دولارًا. كان سعر التنفيذ الفعلي للمستخدم حوالي 154,114.66 USDT مقابل 1 AAVE. هذا يختلف بأكثر من 1000 مرة عن سعر السوق قبل المعاملة.

بعد ذلك، تم إعادة توفير هذه AAVE إلى مسبح السيولة Aave، باستخدام المحدد 0x617ba037، أي، supply(address,uint256,address,uint16). كانت النتيجة أن aEthAAVE الذي تم سكّه حديثًا تم إرساله مرة أخرى إلى عقد التسوية. في النهاية، نقل عقد التسوية 327.241335505966487788 aEthAAVE إلى المستخدم. ظل حوالي 4.06398010297174764 aEthAAVE في عقد التسوية كفائض بالنسبة لما دفعه المستخدم.

لذا، لم يقم التسوية بتحريف نتيجة تنفيذ جيدة إلى سيئة فجأة. لقد أنهت فقط النتيجة التي أنتجها التوجيه بالفعل.

هذه نقطة رئيسية تستحق أن تُذكر بوضوح: كانت النتيجة الكارثية "مُعدة مسبقًا" في التوجيه قبل التنفيذ.

في بيانات استدعاء العقد المساعدة المدمجة في التوجيه، كان مقدار الشراء المستهدف على جانب الشراء حوالي 331.272185078031026739، وكان الحد الأدنى لمقدار الشراء المتفق عليه من قبل المستخدم هو 324.949260918413591035، وكان مقدار التسوية الفعلي هو 327.241335505966487788، مع قفل جميع القيم الأساسية عند مستوى يزيد عن ثلاثمائة AAVE قبل التسوية.

هذا التوجيه وُلِد سيئًا.

أين الخلل؟

الإجابة هي: كل طبقة من آلية التحقق في النظام تتحقق من البعد الخاطئ.

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

عيب برمجي في واجهة Aave محول مسار الاقتباس

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

المصدر: rates.helpers.ts:93 و adapters.helpers.ts:194

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

تحديد ضعف المعقولية في منطق منافسة اقتباسات CoW (عيب أساسي)

تكمن المشكلة الثانية والأكثر خطورة في منطق منافسة الاقتباسات في بروتوكول CoW: في كود الخدمة العامة الخاص به، طالما كانت رسوم غاز الاقتباس إيجابية ومقدار الناتج غير صفري، سيتم اعتباره "اقتباسًا معقولًا."

المصدر: quote.rs:31

لنظام توجيه يتعامل مع طلبات من ثمانية أرقام، هذا تعريف ضعيف بشكل صادم لـ "المعقولية."

لم يدمج النظام الأوراق المالية للتحقق من صحة الأسعار، ولم يكن لديه آلية اعتراض لـ "الاقتباسات التي تنحرف عن سعر السوق بأكثر من 500 مرة"، ولم يكن هناك تقييم للمخاطر لـ "توجيه يستنزف تمامًا برك السيولة"، ولم يكن هناك تحذير لـ "تطابق السيولة في آخر قفزة بشكل كبير مع حجم الطلب؛" كان يتطلب فقط من المحلّل إرجاع خطة توجيه قابلة للتنفيذ وغير صفرية، والتي سيتم قبولها من قبل النظام، هذا هو العيب الأساسي في هذه الحادثة.

عيوب في منطق نمذجة السيولة على طراز Uniswap V2

تكمن المشكلة الثالثة في نهج نمذجة بركة السيولة على طراز Uniswap V2: تستخدم الشيفرة فقط خوارزمية المنتج الثابت القياسية، وترفض فقط الحالات الرياضية المستحيلة مثل الاحتياطيات الصفرية، والانخفاض، والزيادة، دون إجراء فحوصات الجدوى الاقتصادية.

المصدر: pool_fetching.rs:118 و pool_fetching.rs:153

هذا الجزء من الشيفرة لا يحدد ما إذا كانت حجم بركة السيولة كافية لاستيعاب المعاملة التوجيهية المقابلة؛ بل يتحقق فقط مما إذا كانت عملية التبادل صحيحة رياضيًا. لذلك، حتى بركة صغيرة تحتوي على 331 احتياطي AAVE فقط ستعتبر مكانًا صالحًا لاستيعاب طلب شراء لـ 17,957 WETH، ببساطة لأن خوارزمية المنتج الثابت يمكن أن تعطي نتيجة غير صفرية، متجاهلة تمامًا الخسارة الكارثية للأصول التي ستسببها هذه النتيجة.

فشل ثانوي في SDK قرض الفلاش وآلية التحقق من الطلب

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

ثم:

المصدر: index.js:484 و index.js:591

لهذا السبب قلت دائمًا إن هذا التوجيه "مولود سيئ." لم يكتشف طبقة المحول مقدارًا سيئًا جديدًا أثناء التنفيذ. لقد سجلت المقدار السيئ الذي تم اقتباسه بالفعل في بيانات الخطاف وحددت عنوان الحالة. بمجرد وجود اقتباس سيء، ستقوم الآليات المتبقية بنقله بأمان.

حتى منطق التحقق من الطلب في CoW هنا لم يحمي المستخدم حقًا، حيث أنه يتحقق فقط مما إذا كان الطلب يتجاوز سعر السوق في وقت الاقتباس، دون التحقق مما إذا كان الاقتباس نفسه غير منطقي بالنسبة للسيولة الفعلية.

المصدر: order_validation.rs:694

هذه فحص للتناسق. إذا كان الاقتباس نفسه غير منطقي بالفعل، يمكن أن يمر الطلب.

آلية تحذير واجهة المستخدم الأمامية غير فعالة

واجهة Aave تحتوي على تحذيرات عالية التأثير على السعر، لكن ليست قاطع دائرة صارم. عندما يتجاوز فقدان القيمة 20%، يصبح مربع تأكيد.

بمجرد أن يتحقق المستخدم من مربع التأكيد، تتم إزالة الحاجز:

المصدر: helpers.ts:24 و HighPriceImpactWarning.tsx:35

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

استنادًا إلى جميع فشل الآليات المذكورة أعلاه، لا أوافق تمامًا على الاستنتاج المتساهل بأن "هذا مجرد غباء من المستخدم." أكمل المستخدم التوقيع، لكن النظام البرمجي بالكامل كان لديه عدد لا يحصى من الفرص لاعتراض هذه الكارثة، ومع ذلك، كل طبقة قامت فقط بإجراء فحوصات أساسية، محددة "غير صفرية، قابلة للتنفيذ، موقعة"، وأطلقتها مباشرة، مما أدى في النهاية إلى عواقب كارثية.

لم يتم العبث بالتوجيه

هذا القسم حاسم، يستبعد مباشرة عددًا كبيرًا من التكهنات الخاطئة: ستقوم عملية واجهة Aave الرسمية المقابلة لـ aave-v3-interface-collateral-swap بحساب مبلغ الشراء المعدل وفقًا للانزلاق في السطر 139 من ملف useSwapOrderAmounts.ts، مجمعة الاقتباس، ورسوم الشبكة، ورسوم الشركاء، ورسوم القرض الفوري؛ السطر 331 يحوله إلى قيمة buyAmountBigInt؛ ثم في السطر 191 من ملف CollateralSwapActionsViaCoWAdapters.tsx، يتم توقيع هذا المبلغ بدقة.

ستتحقق عقود المحولات اللاحقة من أن حقول الطلب الموقعة تتطابق تمامًا مع القيم المخزنة في السطر 141 من ملف AaveV3BaseAdapter.sol؛ ستفرض عقد تسوية CoW قواعد الحد المتفق عليه الموقعة في السطر 337 من ملف GPv2Settlement.sol. لذلك، لم يتجاوز نتيجة التنفيذ على السلسلة الحدود المسموح بها من قبل الطلب الموقّع، وكانت الأصول التي تلقاها المستخدم فعليًا أعلى حتى من الحد الأدنى المتفق عليه في التوقيع.

هذا كافٍ لإثبات: الكارثة حدثت قبل مرحلة التسوية، وليس أثناء عملية التسوية؛ العيب القاتل في التوجيه قد حدد بالفعل النتيجة.

أين ذهبت القيمة المفقودة؟

المعاملة التالية في نفس الكتلة (الهاش يبدأ بـ 0x45388b0f) أكملت عملية تحكيم عكسية ضد بركة SushiSwap AAVE/WETH التالفة. بعد أن ملأت المعاملة غير الطبيعية المسبح بكمية هائلة من WETH واستنزفت معظم AAVE، قام المضارب ببيع AAVE مرة أخرى إلى المسبح، محصلاً القيمة الزائدة الناتجة عن عدم توازن السيولة.

استخرجت هذه المعاملة العكسية حوالي 17,929.770158685933 WETH، ثم دفعت حوالي 13,087.73 ETH لباني الكتلة وحوالي 4,824.31 ETH لعنوان تنفيذ المضاربة.

تم تحويل جميع القيمة الاقتصادية المفقودة من قبل المستخدم في النهاية تقريبًا على الفور إلى أرباح مضاربة MEV وأرباح باني الكتلة ضمن نفس الكتلة.

بالإضافة إلى ذلك، فإن التحقق من تسلسل الوقت على مستوى الكتلة يؤكد: لم يقم أحد بالتلاعب الخبيث بمسبح تداول SushiSwap لوضع فخ للمستخدمين؛ تم لمس زوج تداول AAVE/WETH أولاً بواسطة هذه المعاملة غير الطبيعية (فهرس المعاملة 1)؛ أكملت المعاملة التالية مباشرة (فهرس المعاملة 2) أول عملية عكسية ضد تشويه السعر الناتج عن هذه المعاملة؛ كما لمس فهرس المعاملة 3 هذا الزوج من التداول خلال عملية تصحيح السوق. الجدول الزمني يؤكد بوضوح: هذه المعاملة غير الطبيعية أنشأت تشويهًا شديدًا في السعر، والمعاملات اللاحقة حصّلت مباشرة هذه الأرباح المشوهة.

إذًا، من المسؤول؟

إذا سألت عما إذا كان بروتوكول Aave V3 الأساسي قد انهار، فإن الجواب هو لا. نفذ مسبح سيولة Aave العمليات تمامًا وفقًا للتعليمات، وأكمل بنجاح عملية استرداد USDT وإيداع AAVE.

إذا سألت عما إذا كان عقد GPv2Settlement الخاص بـ CoW قد انهار، فإن الجواب هو لا. فرض التسوية أمرًا موقعًا صالحًا ودفع مبلغًا فوق الحد الأدنى المتفق عليه في التوقيع.

إذا سألت عما إذا كانت عقود أزواج التداول في Uniswap V3 أو SushiSwap قد انهارت، فإن الجواب هو أيضًا لا. أكملت كلا نوعي مسبح التداول تسعير المعاملات وفقًا لقواعد خوارزمياتها الخاصة.

حدث الفشل النظامي الحقيقي في طبقات التوجيه والتحكم في المخاطر على مستوى أعلى:

الطرف المسؤول الرئيسي هو وحدات التوجيه، والتسعير، والحل لبروتوكول CoW: معايير النظام بالكامل لتحديد "التوجيه المعقول" ضعيفة جدًا، مما يسمح للأوامر التي تصل قيمتها إلى ملايين الدولارات بالتدفق في النهاية إلى مسابح ذات سيولة منخفضة جدًا، طالما أن التوجيه قابل للتنفيذ وغير صفري، يتم قبوله، متجاهلاً تمامًا عدم المنطق الشديد على المستوى الاقتصادي.

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

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