ما المشكلة في إعادة الرهن؟

كتابة: Kydo، مسؤول السرد في EigenCloud

ترجمة: Saoirse، Foresight News

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

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

كل هذه الآراء معقولة، وكثير منها له وجاهته.

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

آمل أن تكون التجارب المذكورة في المقالة ذات طابع عام وتوفر مرجعاً لمطوري أنظمة إيكولوجية أخرى.

بعد أكثر من عامين من دمج جميع خدمات التحقق الرائدة (AVS) على EigenLayer وتصميم EigenCloud، أود أن أراجع بصدق: أين أخطأنا، وأين أصبنا، وإلى أين سنتجه بعد ذلك.

ما هي إعادة التخزين (Restaking) بالضبط؟

مجرد الحاجة لشرح “ما هي إعادة التخزين” الآن، بحد ذاته دليل على أننا لم ننجح في توضيح المفهوم عندما كانت إعادة التخزين محور الاهتمام في الصناعة. وهذا هو “الدرس رقم 0” — التركيز على سرد رئيسي واحد وتكراره باستمرار.

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

كانت AVS أول محاولة واضحة نقوم بها لتحقيق ذلك.

AVS (خدمة التحقق الذاتي) هي نوع من شبكات إثبات الحصة (PoS)، يديرها مشغلون لامركزيون ينفذون مهام خارج السلسلة. تتم مراقبة سلوك هؤلاء المشغلين، وفي حال المخالفة، يتم خصم رصيدهم المرهون كعقوبة. ولتنفيذ “آلية العقوبة” يجب أن يكون هناك “رأس مال مرهون” يدعم ذلك.

هنا تكمن قيمة إعادة التخزين: ليس على كل AVS بناء نظام أمان من الصفر، بل تتيح إعادة التخزين إعادة استخدام ETH المرهون لتوفير الأمان لعدة AVS، ما يقلل من تكلفة رأس المال ويسرّع إطلاق النظام البيئي.

لذا، يمكن تلخيص إطار مفهوم إعادة التخزين كالتالي:

AVS: هي “طبقة الخدمة”، وهي حاملة لنظام أمان تشفير اقتصادي جديد قائم على PoS؛

إعادة التخزين: هي “طبقة رأس المال”، حيث يتم إعادة استخدام الأصول المرهونة الحالية لتوفير الأمان لهذه الأنظمة.

ما زلت أعتقد أن هذا المفهوم ذكي للغاية، لكن الواقع لم يكن مثالياً كما في الرسوم التوضيحية — كثير من الأمور لم تحقق النتائج المتوقعة.

ما لم يتحقق كما هو متوقع

1. اخترنا السوق الخطأ: شريحة ضيقة جداً

لم نكن نبحث عن “أي نوع من الحوسبة القابلة للتحقق”، بل كنا مصرين على “نظام لامركزي من اليوم الأول، قائم على آلية العقوبة، وأمان اقتصادي مشفر بالكامل”.

كنا نأمل أن تصبح AVS “خدمة بنية تحتية” — تماماً كما يمكن للمطورين بناء SaaS (البرمجيات كخدمة)، يمكن لأي شخص بناء AVS.

هذا التموضع بدا مبدئياً، ولكنه قلص بشكل كبير نطاق المطورين المحتملين.

النتيجة كانت أننا واجهنا سوقاً “صغير الحجم، بطيء التقدم، عالي العتبة”: مستخدمون محتملون قليلون، تكلفة تنفيذ عالية، ودورة تطوير طويلة لكلا الفريق والمطورين. سواء بنية EigenLayer التحتية أو أدوات التطوير أو كل AVS في الأعلى، استغرق بناؤها شهوراً أو حتى سنوات.

بعد ما يقارب ثلاث سنوات: لدينا حالياً فقط AVS رئيسيين يعملان في بيئة الإنتاج — هما DIN (شبكة البنية التحتية اللامركزية) من Infura وEigenZero من LayerZero. لا يمكن اعتبار هذا “اعتماداً واسع النطاق”.

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

2. البيئة التنظيمية أجبرتنا على “الصمت”

عندما بدأنا المشروع، كنا في ذروة “عصر Gary Gensler” (ملاحظة: Gary Gensler هو رئيس SEC الأمريكي، وقد اتخذ موقفاً تنظيمياً صارماً تجاه صناعة التشفير). في ذلك الوقت، كانت عدة شركات متخصصة في التخزين قيد التحقيق والمقاضاة.

بصفتنا “مشروع إعادة تخزين”، كان كل ما نقوله في الأماكن العامة يمكن تفسيره على أنه “وعد استثماري” أو “إعلان عوائد”، وربما يجلب لنا استدعاءً قانونياً.

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

حتى لم نكن نستطيع قول “الأمر ليس كذلك” بسهولة — لأن علينا أولاً تقييم المخاطر القانونية.

والنتيجة أنه، في ظل نقص التواصل الكافي، أطلقنا عملة رمزية مقفلة. الآن، أرى أن ذلك كان مغامرة بالفعل.

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

3. AVS المبكر أضعف قيمة العلامة التجارية

قوة علامة Eigen التجارية في البداية كانت مستمدة إلى حد كبير من Sreeram (عضو أساسي في الفريق) — نشاطه وتفاؤله وإيمانه بأن “الأنظمة والبشر يمكن أن يصبحوا أفضل” جلبت للفريق الكثير من الثقة.

وزادت مليارات الدولارات من رأس المال المرهون من تعزيز هذه الثقة.

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

مع الوقت، بدأ الناس يربطون “EigenLayer” بـ “التعدين السائل الأخير أو الإسقاطات المجانية”. وقد أدى ذلك إلى الشكوك والملل وحتى النفور، ويمكن تتبع الكثير من ذلك إلى تلك المرحلة.

لو أعدنا الكَرّة، كنت أفضل أن نبدأ بـ"عدد أقل، لكن أكثر جودة من AVS"، وأن نكون أكثر انتقاءً في “الشركاء الذين يستحقون دعم العلامة التجارية”، وألا نمانع نمواً أبطأ أو ضجيجاً أقل في الترويج.

4. السعي المفرط وراء “الحد الأدنى من الثقة” أدى إلى تعقيد التصميم

حاولنا بناء “نظام عقوبة عام مثالي” — يجب أن يكون عاماً ومرناً ويغطي جميع سيناريوهات العقوبة، لتحقيق “الحد الأدنى من الثقة”.

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

فيما بعد، اتضح لنا أن المسار الأكثر منطقية كان: إطلاق نظام عقوبة بسيط أولاً، وترك كل AVS يجرب نموذجاً أكثر تركيزاً، ثم زيادة تعقيد النظام تدريجياً. لكننا قدمنا “التصميم المعقد” في البداية، ودفعنا ثمناً في “السرعة” و"الوضوح".

ما تم تحقيقه فعلاً

الناس يحبون إلصاق وصف “الفشل” مباشرة بالأشياء، لكن هذا تصرف متسرع جداً.

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

1. أثبتنا قدرتنا على الفوز في سوق تنافسي شرس

نميل إلى تفضيل “الربح للجميع”، لكننا لا نخشى المنافسة أبداً — ما دام أننا اخترنا دخول سوق، لا بد أن نكون في المقدمة.

في مجال إعادة التخزين، كان Paradigm وLido يدعمان منافسنا المباشر. في ذلك الوقت، لم تكن قيمة EigenLayer المقفلة (TVL) تتجاوز 1 مليار.

كان للمنافس ميزة السرد، وموارد القنوات، والدعم الرأسمالي، و"ثقة افتراضية" مدمجة. قال لي الكثيرون: “تحالفهم سيكون أكثر فاعلية منكم وسيسحقكم”. لكن الواقع لم يكن كذلك — اليوم لدينا 95% من حصة سوق رأس المال في إعادة التخزين، وجذبنا 100% من كبار المطورين.

في مجال “إتاحة البيانات (DA)” بدأنا لاحقاً، فريقنا أصغر وتمويلنا أقل، والمنافسون كانوا يملكون أفضلية البداية ونظام تسويق قوي. لكن اليوم، أيّاً كان المعيار، EigenDA (حل إتاحة البيانات من Eigen) يملك حصة كبيرة من سوق DA؛ ومع اكتمال إطلاق أكبر الشركاء، ستنمو هذه الحصة بشكل أسي.

هاتان السوقان كانتا في غاية الشراسة، لكننا برزنا في النهاية.

2. EigenDA أصبح منتجاً ناضجاً “يغير النظام البيئي”

إطلاق EigenDA على بنية EigenLayer التحتية كان مفاجأة رائعة.

أصبح حجر الأساس لـ EigenCloud، وجلب للإيثيريوم ما كان يحتاجه بشدة — قناة DA ضخمة جداً. وبهذا، يمكن للـ Rollup العمل بسرعة عالية دون أن يضطر للابتعاد عن نظام الإيثيريوم بحثاً عن “السرعة” عبر سلاسل جديدة.

انطلق MegaETH لأن الفريق كان يثق في قدرة Sreeram على حل عنق الزجاجة في DA؛ وعندما اقترحت Mantle على BitDAO بناء L2 في البداية كان بسبب نفس الثقة.

أصبح EigenDA أيضاً “درع حماية” للإيثيريوم: عندما يتوفر حل DA محلي عالي الإنتاجية داخل نظام الإيثيريوم، يصبح من الصعب على سلاسل خارجية أن “تجذب الانتباه بسرد الإيثيريوم وتمتص قيمة النظام البيئي”.

3. دفع سوق التأكيد المسبق للأمام

إحدى القضايا الأساسية التي ناقشناها في EigenLayer في البداية، هي كيفية تفعيل ميزة التأكيد المسبق للإيثيريوم عبر EigenLayer.

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

لدفع النظام البيئي للأمام، أطلقنا برنامج Commit-Boost — هدفه حل “تأثير القفل” لعملاء التأكيد المسبق، وبناء منصة محايدة تمكن أي شخص من الابتكار عبر التزامات المدققين.

اليوم، يتدفق مليارات الدولارات عبر Commit-Boost، وأكثر من 35% من المدققين انضموا للبرنامج. ومع إطلاق خدمات التأكيد المسبق الرئيسية خلال الأشهر القادمة، ستزداد هذه النسبة أكثر.

هذا ضروري لـ “مناعة” نظام الإيثيريوم، ويؤسس لاستمرارية الابتكار في سوق التأكيد المسبق.

4. ضمان سلامة الأصول دائماً

على مدار سنوات، حافظنا على أمان أصول بمئات المليارات من الدولارات.

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

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

5. منع Lido من الاستحواذ الدائم على أكثر من 33% من الحصة

هناك أثر غير مقدر لإعادة التخزين: تدفق كميات ضخمة من ETH إلى مزودي LRT، ما منع Lido من السيطرة الدائمة على أكثر من 33% من الحصة.

هذا مهم جداً لـ “التوازن الاجتماعي” للإيثيريوم. لو سيطر Lido على أكثر من 33% من الحصة لفترة طويلة دون بدائل موثوقة، لكان ذلك أثار جدلاً كبيراً وخلافات داخلية.

لم تحقق إعادة التخزين وLRT “اللامركزية الكاملة بشكل سحري”، لكنها غيّرت بالفعل اتجاه تركّز الحصة — وهذا ليس إنجازاً بسيطاً.

6. تحديد “الحدود الحقيقية” بدقة

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

المسار الصحيح ليس “البدء بالأمان الاقتصادي المشفر العام، وفرض بناء مشغلين لامركزيين من اليوم الأول، ثم انتظار انضمام جميع الأعمال لهذا المستوى”.

الطريقة الفعالة لدفع “الحدود” هي: تزويد المطورين بأدوات مباشرة لتحقيق القابلية للتحقق لتطبيقاتهم الخاصة، وتوفير البدائل المناسبة. علينا أن “نقترب من احتياجات المطورين”، لا أن نطلب منهم أن يصبحوا “مصممي بروتوكولات” من اليوم الأول.

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

الخطوة التالية

إذن، في مواجهة كل هذه التجارب — من توقيت التنفيذ، إلى النجاحات، إلى الدروس المستفادة، إلى “ندوب” العلامة التجارية — كيف سنواجه المرحلة القادمة؟

هنا لمحة عن خطتنا القادمة والمنطق وراءها:

1. جعل رمز EIGEN محور النظام

مستقبلاً، ستكون كل منظومة EigenCloud وجميع المنتجات المحيطة بها مبنية حول رمز EIGEN.

دور رمز EIGEN هو:

محرك الأمان الاقتصادي الأساسي لـ EigenCloud؛

الأصل الذي يدعم مختلف المخاطر التي يتحملها المنصة؛

أداة التقاط القيمة الأساسية لتدفقات الرسوم والأنشطة الاقتصادية للمنصة.

في البداية، كان هناك فجوة بين توقعات الكثيرين حول “ما القيمة التي يمكن أن يلتقطها رمز EIGEN” وبين “الآلية الفعلية” — مما سبب ارتباكاً. في المرحلة القادمة، سنسد هذه الفجوة من خلال التصميمات والتطبيقات الفعلية. المزيد من التفاصيل سنعلنها لاحقاً.

2. تمكين المطورين من بناء “تطبيقات قابلة للتحقق” وليس فقط AVS

ما زالت حجتنا الأساسية كما هي: زيادة إمكانية التحقق من الحوسبة خارج السلسلة لتمكين تطبيقات أكثر أماناً على السلسلة. لكن أدوات تحقيق “القابلية للتحقق” لن تقتصر على نوع واحد.

أحياناً، قد تكون الأمان الاقتصادي المشفر؛ وأحياناً، قد يكون إثبات ZK أو TEE (بيئة تنفيذ موثوقة)، أو حلول هجينة. ليس المهم “تمجيد تقنية معينة”، بل جعل “القابلية للتحقق” معياراً يمكن للمطورين دمجه في تقنيتهم بسهولة.

هدفنا هو تقليص الفجوة بين حالتين:

من “لدي تطبيق” إلى “لدي تطبيق يمكن للمستخدم والشريك والجهة التنظيمية التحقق منه”.

حالياً، “التشفير الاقتصادي + TEE” هو الخيار الأفضل — فهو يحقق توازناً مثالياً بين “قابلية برمجة المطورين” (ما يمكنهم بناؤه) و"الأمان" (أمان تطبيقي حقيقي، لا نظري).

عندما تنضج إثباتات ZK وآليات التحقق الأخرى بما يكفي لتلبية احتياجات المطورين، سنقوم بدمجها في EigenCloud أيضاً.

3. التوسع العميق في مجال الذكاء الاصطناعي

التحول الأكبر في الحوسبة عالمياً حالياً هو الذكاء الاصطناعي — خصوصاً العوامل الذكية (AI Agents). وصناعة التشفير ليست استثناءً.

العامل الذكي في الأساس هو “نموذج لغوي مغلف بأدوات، ينفذ عمليات في بيئة معينة”.

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

لكن إذا أصبحت العوامل الذكية “قابلة للتحقق”، فلن يحتاج الناس للاعتماد على الثقة في المطور.

لتحقيق قابلية التحقق لعوامل الذكاء الاصطناعي، يجب تلبية ثلاثة شروط: أن يكون استدلال LLM (النموذج اللغوي الكبير) قابلاً للتحقق، أن تكون بيئة التنفيذ قابلة للتحقق، وأن تكون طبقة البيانات المستخدمة للحفظ والاسترجاع وفهم السياق قابلة للتحقق.

وهذا بالضبط ما صُممت من أجله EigenCloud:

EigenAI: يوفر خدمة استدلال LLM قابلة للتحقق وحتمية؛

EigenCompute: يوفر بيئة تنفيذ عمليات قابلة للتحقق؛

EigenDA: يوفر تخزين واسترجاع بيانات قابلة للتحقق.

نحن نؤمن بأن “عوامل الذكاء الاصطناعي القابلة للتحقق” ستكون من أكثر سيناريوهات “الخدمات السحابية القابلة للتحقق” تنافسية لدينا — ولهذا أنشأنا فريقاً متخصصاً للعمل في هذا المجال.

4. إعادة صياغة سرد “الرهن والعوائد”

للحصول على عوائد حقيقية، يجب تحمل مخاطر حقيقية.

نحن نستكشف سيناريوهات أوسع لاستخدام الرهن، بحيث يمكن لرأس المال المرهون دعم المخاطر التالية:

مخاطر العقود الذكية؛

مخاطر أنواع مختلفة من الحوسبة؛

مخاطر يمكن وصفها بوضوح وتسعيرها كمياً.

العوائد المستقبلية ستعكس المخاطر “الشفافة والمفهومة” التي يتحملها المستخدم، وليس فقط “مطاردة أحدث صيحات التعدين السائل”.

هذا المنطق سيتم دمجه طبيعياً في استخدامات رمز EIGEN، ونطاق دعمه، وآلية تدفق القيمة فيه.

كلمة أخيرة

لم تصبح إعادة التخزين “الطبقة الشاملة” التي كنت (وغيري) أتمناها، لكنها لم تختف أيضاً. على مدار التطوير الطويل، أصبحت مثل معظم “المنتجات الأولى من نوعها”:

فصل مهم، دروس غالية، وبنية تحتية تدعم أعمالاً أوسع اليوم.

ما زلنا ندير أعمال إعادة التخزين ونهتم بها — لكننا لم نعد نسمح للسرد الأولي بأن يقيدنا.

إذا كنت عضواً في المجتمع، أو مطور AVS، أو مستثمراً ما زال يربط Eigen بـ “مشروع إعادة التخزين”، آمل أن تساعدك هذه المقالة في فهم “ما حدث في الماضي” و"وجهتنا الحالية".

ندخل اليوم مجالاً ذا “سوق إجمالي قابل للاستهداف (TAM) أكبر”: من جهة خدمات سحابية، ومن جهة أخرى احتياجات تطبيقية مباشرة للمطورين. نواصل استكشاف “مسار الذكاء الاصطناعي غير المستغل بالكامل”، وسنواصل الدفع في هذه المجالات بقوة تنفيذ عالية كما اعتدنا.

الفريق ما زال مليئاً بالحماس، وأتوق لإثبات قدرتنا لكل المشككين — نحن قادرون.

لم أكن يوماً متفائلاً تجاه Eigen كما أنا اليوم، وما زلت أزيد من حيازتي لرمز EIGEN وسأواصل ذلك مستقبلاً.

ما زلنا في بدايتنا.