المشكلة التي يريد حلها مباشرة جدًا:
عندما يتم تنفيذ مهمة أو بيانات أو رسالة أو عملية على السلسلة بواسطة نظامٍ ما، فمن الذي يثبت أن هذا الأمر صحيحٌ فعلًا، وصحيحٌ من حيث الصحة، وأنه لم يتم العبث به عبر أي عقدة مركزية؟
تُعرّف DeepSafe عن نفسها على أنها:
Universal Verification Layer، طبقة التحقق العامة.
📍في جوهرها، تريد بناء شبكة تحقق مستقلة.
مهما كانت الطبقة العلوية تتعامل مع AI Agent أو بروتوكولات عبر السلاسل أو التطبيقات، أو أي أنظمة أخرى تحتاج إلى تنفيذٍ موثوق، فإن DeepSafe تأمل أن توفر طبقة تحقق خارجية.
بعبارات بسيطة:
عندما يقول نظام ما “لقد انتهيت”، يتولى DeepSafe مهمة الفحص—
كيف يمكنك إثبات ذلك؟
🗝️ أولاً، ما المشكلة التي يحلها DeepSafe حقًا؟
اليوم تعتمد العديد من التطبيقات فعليًا على نموذج ثقة بسيط جدًا:
يخبرك الخادم بما هي النتيجة، وأنت تفترض أنها صحيحة.
تخبرك عقدة ما بأن الرسالة تم تنفيذها بالفعل، وأنت تفترض أنها صحيحة.
يرجع نظام ما نتيجة ما، وأنت تفترض أنه لم يتصرف بسوء نية.
هذا لا يسبب مشكلة كبيرة في السيناريوهات منخفضة القيمة.
لكن بمجرد أن يتعلق الأمر بالتمويل أو الأصول أو نقل السلاسل أو التنفيذ الآلي، تبدأ مخاطر الثقة في نقطة واحدة بالاتساع.
لذلك فإن ما يريد DeepSafe القيام به ليس هو إنجاز هذه المهام بنفسه.
لكن ذلك يضيف طبقة مهام:
قابلية التحقق.
مثل:
قام وكيل بتنفيذ صفقة.
لا يتولى DeepSafe مسؤولية تنفيذ المعاملات نيابةً عنه، بل يتحقق من نتيجة التنفيذ.
يُرسل نظام ما رسالة عبر السلاسل المتقاطعة.
لا يتولى DeepSafe مسؤولية تحديد محتوى الرسالة، بل يتحقق مما إذا كانت هذه الرسالة قد تم توليدها بشكل صحيح ونقلها بشكل صحيح.
تحتاج نتيجة حساب ما إلى أن تتبناها أنظمة أخرى.
يأمل DeepSafe أن لا يضطر المستخدمون إلى مجرد تصديق مقدم النتائج.
وهذه هي منطقها الأساسي لما يسمى طبقة Verification.
📍 ثانيًا، ما هي CRVA؟
جوهر DeepSafe هو شبكة تحقق CRVA.
داخلها توجد تقنيات مختلفة مثل Ring VRF وMPC وTEE وZKP وغيرها.
هذه الأسماء الإنجليزية تبدو معقدة، لكن في الحقيقة لا داعي للنظر إليها على أنها غامضة للغاية.
يمكن تبسيط الأمر إلى عدة خطوات:
🔻 اختيار المدققين عشوائيًا، لتقليل مخاطر سيطرة طويلة الأمد للعقد الثابتة؛
🔻 عدة أطراف تشارك في إتمام عملية التحقق معًا، لتجنب أن تُقرر النتيجة بالكامل بواسطة جهة واحدة؛
🔻 باستخدام بيئات تنفيذ موثوقة مثل TEE، لتقليل احتمال أن يتدخل طرف خارجي في عملية التنفيذ؛
🔻 ثم عبر أدوات تشفير مثل ZKP وغيرها، تقديم إثبات قابل للتحقق حول النتيجة.
عند جمع هذه الأشياء معًا، فإن ما يهدف حلّه في النهاية هو سؤال واحد فقط:
كيفية تقليل مخاطر “أن الأمر يتحكم به عقدة واحدة” قدر الإمكان.
أعتقد أن هذا هو أهم نقطة لفهم DeepSafe.
هناك الكثير من المصطلحات التقنية، لكن جوهر المشروع ليس معقدًا.
إنه يعمل على:
التحقق اللامركزي.
🗝️ ثالثًا، لماذا سُمّي “طبقة التحقق العامة”؟
لأن DeepSafe لا يريد أن يَرتبط بمشهد واحد فقط.
إذا كان الهدف مجرد تزويد وكيل AI معين بالتحقق، فهو في الحقيقة يشبه إضافة (Plugin) لوكيل.
إذا كان يخدم نقل السلاسل فقط، فهو يشبه أكثر “شبكة تحقق الجسور” (Bridge Verification Network).
لكن ما يريد DeepSafe القيام به هو طبقة أعمق من ذلك:
طالما يوجد لدى نظام ما احتياج بأن “تحتاج النتيجة إلى التحقق من طرف ثالث”، فيمكنه من الناحية النظرية الاتصال.
لذلك فهو يؤكد Universal.
وهذا أيضًا تفكير البنية التحتية النموذجي لهذا المشروع:
لا ينتج المنتج النهائي مباشرة، بل يزوّد الأنظمة في الأعلى بقدرات موثوقة.
إذا استطاعت هذه الرؤية أن تنجح في النهاية، فلن تعتمد قيمتها فقط على نجاح تطبيق واحد بعينه، بل ستعتمد على قدرتها على أن تصبح شبكة تحقق يمكن للأنظمة المختلفة استدعاؤها معًا.
بالطبع، هذه أيضًا هي الصعوبة.
“العامة” تعني أن سقفها مرتفع.
لكن هذا يعني أيضًا ضرورة التوافق مع المزيد من السيناريوهات، واحتياجات المطورين والأعمال.
📍 رابعًا، DeepSafe ليس مشروع AI تحول فجائي
这一点我觉得值得单独说。
إن سلف DeepSafe هو Bool Network.
منذ عام 2024، كانت الفرقة تعمل على دفع اتجاهات مثل شبكة التحقق وBTC عبر السلاسل وTEE وCRVA وغيرها.
أي أن الأمر يتعلق بالتحقق، وليس أنه بعد أن يشتعل حماس الناس لوكلاء AI فجأة تم تغليف المشروع السابق بمفهوم AI.
كان يدرس أصلًا التنفيذ والتحقق الموثوقين.
حاليًا، تم تشغيل شبكة اختبار DeepSafe Beta Mainnet بالفعل.
الرمز الأصلي الخاص به هو DEF، والإجمالي 1 مليار قطعة.
يمكن أيضًا رؤية سجل التطوير المستمر على GitHub.
سبق للمشروع أيضًا أن كشف عن تمويل Seed بقيمة 3 ملايين دولار، وتضم المؤسسات المشاركة Antalpha Ventures وViaBTC Capital وGate Ventures وSpark Digital Capital وCKB Eco Fund وغيرها.
على الأقل من حيث الخط الزمني، فإن مساره التقني متصل.
هذه النقطة أقوى بكثير من مجرد “تغيير الاسم والاقتراب من AI”.
🗝️ خامسًا، أعتقد أن ما يريد DeepSafe إثباته الحقيقي ليس التقنية، بل الاحتياج
غالبًا ما تواجه مشاريع مثل شبكة التحقق مشكلة:
يبدو أن الجانب التقني كامل.
التشفير، وTEE، وMPC، وZK—كلها موجودة.
مخطط البنية المعمارية أيضًا جميل جدًا.
لكن في النهاية، لا توجد تطبيقات كافية مستعدة لاستدعائه.
وهذا هو أكبر خطر.
لأن البنية التحتية في النهاية يجب أن تجيب عن سؤال واحد:
من سيتحمل تكاليف الدفع مقابل هذه البنية التحتية؟
بالنسبة إلى DeepSafe، أعتقد أن الشيء الأكثر جدارة بالملاحظة لاحقًا ليس كم عدد الوحدات التقنية التي تم ضمها مجددًا.
وليست مجرد بعض المؤشرات الأكثر واقعية:
هل توجد تطبيقات حقيقية تستمر في استدعاء شبكة التحقق؛
هل يمكن لعدد طلبات التحقق أن ينمو؟
هل ظهرت بالفعل حاجة ملحّة حقيقية في سيناريوهات AI أو نقل السلاسل أو الأتمتة داخل السلسلة؟
هل يرغب المطورون في تحمل تكاليف تحقق إضافية وزيادة في زمن التأخير؛
وما إذا كان بإمكان DEF في النهاية الارتباط فعليًا باستهلاك الشبكة.
هذه الأشياء أهم من مجرد الإعلان عن بعض الشراكات.
📍 لذلك، إذا طلبت مني الآن أن أحدد موقع DeepSafe:
سأنظر إليها على أنها مشروع بنية تحتية يستهدف نمو متطلبات “الحوسبة/التنفيذ القابل للتحقق”.
الميزة تكمن في أن المسار مترابط نسبيًا، كما أن لديهم بالفعل تراكمًا تقنيًا من فترة Bool Network، وليسوا على الصفر.
لكن مشكلته أيضًا نموذجية جدًا:
هل يمكن لطبقة التحقق أن تصبح سوقًا مستقلًا وكبيرًا بما يكفي؟
لا يمكننا أن نضع الإجابة مسبقًا بعد.
ما يريد DeepSafe إثباته ليس أن “التحقق مهم”.
هذا الطرح نفسه لا يثير الكثير من الجدل.
إن الشيء الحقيقي الصعب هو:
هل يرغب السوق في دفع ثمن Verification وحده؟
إذا استطاع مستقبلًا أن ينتقل فعلًا من “شبكة التحقق التقنية” إلى “بنية تحتية يتم استدعاؤها من قبل عدد كبير من التطبيقات”، عندها فقط يُعد المشروع قد قطع أهم خطوة.
قبل ذلك، سأكون أكثر ميلاً لوضعه ضمن قائمة المراقبة.
المسار التقني موجود بالفعل، والآن ما يجب مراقبته هو حجم الاستخدام.