من حادثة Kelp DAO إلى واجهة المستخدم القابلة للتحقق: لماذا تعتبر «الواجهة القابلة للتحقق» هي الخط الدفاعي الجديد للأمان اللامركزي؟

الكون على السلسلة في عالم التمويل اللامركزي، مرة أخرى تظهر حادثة أمان بقيمة مئات الملايين من الدولارات.

في 18 أبريل، استغل المهاجمون تكوين مسار LayerZero في Kelp DAO الذي يستخدم 1 من 1 DVN، وبدون مدققي اختيار، وقاموا بتزوير رسالة عبر السلسلة مما أدى إلى إصدار خاطئ لـ 116500 من rsETH، مما أدى إلى أن Aave تواجه نطاق ديون محتملة يتراوح بين 1.237 مليار و2.301 مليار دولار في سيناريوهات توزيع الخسائر المختلفة.

من الناحية الموضوعية، ليست هذه فقط أكبر حادثة أمان في DeFi منذ عام 2026 حتى الآن، بل والأهم أنها كشفت عن فرضية هيكلية كانت مقبولة سابقًا في الصناعة: لتحقيق الكفاءة والسيولة والعائد، يتم بشكل خفي رهن المزيد من الأمان على عدد قليل من الطبقات الوسيطة التي تعتبر موثوقة بشكل افتراضي.

أولاً، فقدان آلية اللامركزية وراء حادثة Kelp DAO

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

كـ بروتوكول إعادة الرهن السائل (Liquid Restaking) في بيئة إيثريوم، يُفترض أن المستخدمين فقط بحاجة إلى إيداع ETH ليحصلوا على rsETH كوثيقة إثبات، وهذه الوثيقة يمكن أن تتداول على الشبكة الرئيسية، وأيضًا بعد تغليفها بمعيار OFT الخاص بـ LayerZero، تُنشر على أكثر من 20 سلسلة مثل Base، Arbitrum، Linea، Blast، Mantle، Scroll وغيرها.

وبمعنى آخر، الجانب الخاص بعقد التبادل عبر السلسلة على شبكة إيثريوم يحتفظ بكامل احتياطيات ETH، بينما تعتبر rsETH على الشبكات الأخرى في جوهرها مجرد «إشعارات استلام من الاحتياطيات الرئيسية»، مما يعني أن الأساس الذي يقوم عليه هذا النظام هو أن «كمية ETH المقفلة على الشبكة الرئيسية دائمًا تساوي أو تتجاوز كمية الإصدار على L2»، وأن هذا الربط لا يمكن كسره.

وما قام المهاجمون بتجاوزه هو بالضبط هذا القيد الأساسي الظاهر والبسيط، وهو أن قاموا بتزوير رسالة عبر LayerZero تعتبر «مشروعة»، مما جعل عقد الجسر على الشبكة الرئيسية يعتقد أن الأمر صادر من شبكة أخرى بشكل قانوني، ثم سمحوا بإصدار 116500 من rsETH.

المشكلة الأساسية تكمن في تكوين التحقق الخاص بـ LayerZero، حيث أن Kelp DAO تستخدم تكوين DVN من نوع 1/1 (شبكة المدققين اللامركزية)، مما يجعل توقيع مدقق واحد كافيًا لإجازة رسالة عبر السلسلة! وفي الواقع، يوصي LayerZero باستخدام 2/2 أو أكثر من المدققين لضمان التكرار، وكان قد تم تنبيه الباحثين الأمنيين إلى مخاطر تكوين 1/1 منذ يناير 2025، لكن لم يتم تعديله خلال 15 شهرًا!

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

• المستوى الأول هو نقطة التحقق الأحادية: حيث أن DVN مصمم كنموذج أمني قابل للتجميع يعتمد على نظام X من Y من N، يدعم التحقق المتعدد المستقل لتلبية متطلبات الأمان المختلفة، لكن صحة رسالة KelpDAO تم اختصارها إلى فرضية «مدقق واحد فقط لا يخطئ»؛
• المستوى الثاني هو نقطة الاحتياطيات الأحادية: فإذا تم اختراق مخزون الشبكة الرئيسية، فإن rsETH على الشبكات الأخرى لن يكون بعد ذلك أصلًا عبر السلسلة، بل سيظهر كـ IOU مبني على نقطة مرجعية واحدة على الشبكة الرئيسية.

عندما تتراكب نقطة التحقق الأحادية مع نقطة الاحتياطيات الأحادية، فإن المخاطر لا تظل داخل البروتوكول الواحد، بل تمتد عبر قابلية التجميع في DeFi.

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

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

ثانيًا، من «الملكية الذاتية للأصول» إلى «التفاعل القابل للتحقق»: أخطر نقطة ثقة يمكن تجاهلها

لطالما كانت هناك مقولة في مجتمع Web3: لا تثق، بل تحقق.

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

وينطبق هذا المبدأ أيضًا على التفاعل مع المحافظ وDeFi.

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

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

وهذا هو الخطر الأكثر إغفالًا اليوم في DeFi: هل ما يوقع عليه المستخدم هو حقًا ما يعتقد أنه يوقع عليه؟

يمكن القول إن في التفاعلات اليومية على السلسلة، ما يواجهه المستخدم هو في الغالب ليس السلسلة نفسها، بل طبقات من الواجهات المغلفة، مثل واجهة الويب الخاصة بـ DApp، نوافذ المحافظ، مسارات المزودين، وفي المستقبل قد تشمل أيضًا Agent الذي يولد الاستدعاءات ويؤكد النتائج، والتي ستخبرك: «أنت تودع 100 ETH في استراتيجية معينة»، «ستحصل على عائد سنوي معين»، «أنت تقوم بتفويض عادي فقط».

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

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

من هذا المنظور، فإن حادثة Kelp DAO لا تكشف فقط عن مشكلة التحقق الأحادي في مسار الجسر، بل تذكر أيضًا بحقيقة طويلة الأمد كانت تُقلل من شأنها، وهي أن الواجهة في العديد من التفاعلات على السلسلة هي نقطة ثقة افتراضية، نادرًا ما يتم التحقق منها، وأن «الضغط على زر التأكيد» هو في الواقع رهان على أن «الواجهة لا تكذب».

وهذا يقود إلى مفهوم «واجهة قابلة للتحقق» (Verifiable UI).

ما المقصود بـ «واجهة قابلة للتحقق»؟ هو ببساطة «واجهة يمكن التحقق منها». لا يهدف إلى جعل الواجهة أكثر جمالًا، أو جعل نوافذ التوقيع أكثر وضوحًا، بل يسعى إلى ربط المحتوى المعروض على الواجهة مع التنفيذ الحقيقي على السلسلة، بحيث يمكن للمستخدم التحقق منه، ويمكن للمحفظة التحقق منه، ويمكن تتبعه لاحقًا.

بعبارة أخرى، هو لا يحل مشكلة «هل تم عرض المعلومات»، بل يضمن أن «ما يُعرض يتطابق مع ما سيحدث على السلسلة»، وهذا يتطلب:

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

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

وفي عالم DeFi اليوم، لا تزال قابلية التحقق من الواجهة موضوعًا يُقلل من شأنه بشكل كبير؛ لكن مع مرور الوقت، ستتحول من «تحسين أمني يستحق النقاش» إلى «وظيفة أساسية لا يمكن تأجيلها». لأن مسار التفاعل على إيثريوم يشهد انتقالًا هادئًا لكنه عميق المعنى.

ثالثًا، لماذا ستصبح «الواجهة القابلة للتحقق» حدًا أمنيًا جديدًا؟

إذا كانت حادثة Kelp DAO كشفت عن مشكلة الثقة الأحادية الموجودة منذ سنوات في بنية DeFi القديمة، فإن «الواجهة القابلة للتحقق» تمثل مرحلة جديدة بدأت تلوح في الأفق.

وقد رسمت خريطة تجربة المستخدم (UX) الخاصة بإيثريوم، والتي تُعرف بـ ETHUX، بوضوح جوهر التحديات الحالية: وضوح المعاملات، تدفق عبر السلسلة، السلامة والأمان، كلها من أصعب النقاط، ومشاكل التوقيع الأعمى، والإرهاق من التوقيع، وألم الجسور، وتجزئة الأصول، كلها مألوفة للمستخدمين القدامى.

وهذا لا يعكس نقصًا في «توعية المستخدمين»، بل يعكس حقيقة أعمق، وهي أن في عالم السلسلة، UX والأمان ليسا شيئًا منفصلًا.

بعبارة أخرى، عدم الفهم هو في حد ذاته أكبر خطر أمني.

ومع تحول نمط التفاعل من «المستخدم ينقر خطوة خطوة على واجهة DApp» إلى «المستخدم يعبر عن نية، والنظام ينفذ تلقائيًا»، فإن المشكلة ستتفاقم، لا تتراجع.

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

لكن مع دخول عصر Agent، ستُضغط هذه العملية بشكل كبير. لن يفتح المستخدم كل من Router، Bridge، Vault، سوق الإقراض للتحقق من كل استدعاء، بل قد يقول ببساطة لـ AI Wallet: «حوّل ETH الخاص بي إلى استراتيجية عوائد أكثر استقرارًا»، «انتقل إلى Base، مع التحكم في أكبر قدر من الانزلاق»، «اسمح لهذا الـ Agent فقط باستخدام 100 USDT خلال 24 ساعة»، ثم ينتظر نتيجة «تم الإنجاز».

وهذا يعني زيادة كبيرة في الكفاءة، لكنه أيضًا يجعل المسارات، والمعلمات، والتفويضات، وترتيب التنفيذ، أكثر عرضة للاختزال خارج مرئية المستخدم. وفي هذا السياق، اقترحت محفظة imToken مسارين متوازيين: أحدهما استكشاف تفاعلات تعتمد على النية، بحيث يعبّر المستخدم فقط عن «ما أريد»، ويقوم النظام بالبحث عن المسار وتنفيذه؛ والآخر هو تعزيز «واجهة موحدة وقابلة للتحقق»، بحيث يتم تصعيد «أن الواجهة يمكن أن تكون نقطة هجوم» إلى مستوى المنتج كهدف استراتيجي طويل الأمد.

وهذا يعكس بشكل أساسي التغيير المطلوب في مسؤولية المحافظ في الجيل القادم.

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

من هذا المنظور، فإن «واجهة قابلة للتحقق» ليست مجرد مفهوم تصميم واجهة متقدم، بل هي نموذج أمني تفاعلي جديد، ويمكن القول إنها قطعة أساسية من الصورة المجمعة التي يجب أن تكتمل في المحافظ ذاتية الحوكمة مع تطورها.

لقد كان التركيز في الصناعة سابقًا على «ليس مفاتيحك، ليست عملاتك»، لكن مع تصاعد نية التوجيه وتنفيذ Agent، يجب أن نضيف: «واجهتك أيضًا يجب أن تكون قابلة للتحقق».

ختامًا

بعد حادثة Kelp DAO، ظهرت بسرعة مناقشات كثيرة حول تكوين DVN، وإدارة مخاطر LRT، ومسارات الجسور، والمخاطر الأحادية.

كل هذه المناقشات ذات قيمة.

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

وهذا هو السبب في أن اللامركزية ليست عدوة الكفاءة، بل هي الحد الأدنى للأمان.

لقد حان الوقت لإنهاء عصر الاعتماد على فرضية نقطة واحدة للأمان.