النقطة الأساسية في الهجوم على Kelp كانت: استخدم المهاجمون رسائل عبر سلاسل مزيفة لجعل جسر LayerZero OFT يطلق مباشرةً على الشبكة الرئيسية 116,500 وحدة من rsETH حقيقية (بدون حرق مكافئ على السلسلة المصدر)، ثم أودعوا هذه rsETH "الفارغة" في بروتوكولات مثل Aave كضمانات، واقترضوا حوالي 236 مليون دولار أمريكي من WETH/ETH حقيقية. الثغرة الأساسية ليست في Aave، بل في تكوين جسر LayerZero الخاص بـ Kelp DAO. تستخدم Kelp rsETH عبر سلاسل عبر معيار OFT (Omnichain Fungible Token) من LayerZero V2: على الشبكة الرئيسية لإيثريوم، يُجمّد عقد OFTAdapter rsETH كاحتياطي نهائي لـ rsETH المربوطة على عدة L2 (مثل خزنة بنكية). على L2، يعمل عقد OFT القياسي وفق آلية 1:1 تتمثل في: "خصم (حرق/طرح) → رسالة → ائتمان (صك/إطلاق)". في حالة نقل عادي، ستكون العملية كالتالي: يحرق مستخدم L2 rsETH → ترسل LayerZero رسالة → يحصل OFTAdapter على الشبكة الرئيسية على الرسالة ثم يطلق rsETH. أما المهاجمون، ففعلوا شيئًا واحدًا فقط: استدعوا مباشرةً على الشبكة الرئيسية لإيثريوم دالة lzReceive في عقد EndpointV2 الخاص بـ LayerZero (رقم المعاملة معلنة: 0x1ae232da…). في الوقت نفسه، أدخلوا حزمة رسالة عبر سلاسل مزيفة (origin packet) تدّعي أن الرسالة قادمة من سلسلة مصدر شرعية. بعد التحقق الناجح من قبل EndpointV2، تم تمرير الرسالة إلى OFTAdapter الخاص بـ Kelp rsETH. وبمجرد استلام OFTAdapter للرسالة، أطلق مباشرةً 116,500 وحدة من rsETH من خزينة الشبكة الرئيسية إلى عنوان المهاجم. بهذه الطريقة، لم يكن هناك أي سجل حرق/خصم على السلسلة المصدر، لكن تم إتمام الائتمان/الإطلاق على الشبكة الرئيسية. تم كسر مبدأ الحفاظ على كمية Omnichain، وتم تفريغ الخزينة الرئيسية، وأصبحت جميع rsETH على L2 في نفس الوقت "ورقًا بلا قيمة". اكتمل الهجوم بأكمله في معاملة واحدة. لم تنجح الهجمات الإضافيتان اللتان تلاتا (كل منهما 40,000 وحدة) لأن Kelp أوقفت الخدمة فجأة. إذًا، السؤال هو: لماذا "صدق" جسر LayerZero هذه الرسالة المزيفة؟ ليس لأن بروتوكول LayerZero به عيب، بل لأن التكوين الأمني لتطبيق Kelp (OApp) كان ضعيفًا جدًا. يدعم LayerZero V2 مطورين لتحديد مستوى التحقق المخصص باستخدام DVN (شبكة المدققين الموزعة) للتحقق من الرسائل. كانت Kelp قد عيّنت فقط DVN 1-of-1 (يحتاج فقط توقيع مدقق واحد للقبول)، وهو أضعف مستوى أمان ممكن. منذ يناير 2025، حذّر منتدى حوكمة Aave من ضرورة توسيع Kelp DVN إلى نظام متعدد التوقيعات (على الأقل 2-of-2 أو أكثر)، لكن بعد 15 شهرًا، لم يتم إجراء أي تغيير، وما زالوا يفضلون التكوين الأضعف "الأولوية للسرعة". وهذا النقطة الواحدة أصبحت نقطة الهجوم الأساسية: تم اختراق مدقق DVN واحد، أو تم تزوير التوقيع، أو تم بناء حزمة تمرر التحقق بشكل مباشر. وبمجرد استلام EndpointV2 لرسالة "تم التحقق منها"، فإنه يستدعي مباشرةً دالة lzReceive في العقد المستهدف، ويثق OFTAdapter تمامًا في الحزمة المرسلة من Endpoint دون أي تحقق ثانوي إضافي. لو لم تكن Kelp قد اتخذت قرار "الأولوية للسرعة" واعتبرت الأمان بنفس القدر من الأهمية، ربما لم يكن هذا الهجوم ناجحًا. بمعنى آخر، وضعت Kelp "شرعية الرسائل عبر السلاسل" بالكامل على عاتق مدقق DVN واحد فقط. وكان السبب في قدرة rsETH على الاقتراض بسرعة مقابل ETH حقيقي هو أن rsETH كانت مدرجة في قائمة البيضاء كضمان في بروتوكولات مثل Aave. أودع المهاجمون rsETH المزيفة داخل Aave قبل 46 دقيقة من إيقاف Kelp، واقترضوا WETH حقيقيًا. عندما قامت Kelp بتجميد الجسر والعملة، كانت الديون السيئة قد تكونت بالفعل داخل Aave (وقد قام Aave بتجميد سوق rsETH وتفعيل وحدة الأمان Umbrella للتعامل معها). باختصار، فإن جوهر التزوير هنا هو: "تكوين DVN واحد فقط + استدعاء مباشر لـ lzReceive لإدخال حزمة مزيفة". إن خطر التحقق النقطي، مجتمعًا مع قابلية التوافق في DeFi، أدى إلى هذا الهجوم الضخم. التحقق النقطي هش. السرعة مهمة، لكن الأمان أهم.