الأساسيات الخاصة بإعادة التخزين

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

المثال الأساسي الذي قدمته EigenLayer هو مثال حول شخص يقوم بالاستثمار المنفرد لإعادة استثمار الـ ETH الحالي الذي يمتلكه. للقيام بذلك، يقوم الشخص المستثمر منفردًا بتحديث عنوان السحب الخاص به إلى عنوان الطبقة الخاصة. تعد EigenPods عقود ذكية تتتبع الخدمات التي قام المراهن الفردي بالتسجيل فيها لتأمينها بمساهمته. يصبح EigenPod في نهاية المطاف مالكًا لأصل soETH، بينما يُنسب للمراهن الفردي تمثيلًا مدفوعًا مرة أخرى لإيثريومهم المراهن.

ملكية الأصل soETH في إطارنا تدل على "الحق الأول" في ETH المُسحوب من بروتوكول Ethereum، أي أنها تمتلك مطالبة أكثر أهمية من أي مشارك آخر في السلسلة. عندما يقرر المشارك الفردي السحب ETH الخاص به من بروتوكول Ethereum، يتم تصفية ETH المُسحوب من خلال عقد EigenPod، حيث يتم التحقق مما إذا كان بإمكان المشارك الفردي استرداد المبلغ الكامل من soETH أم لا (سنرى لاحقًا عندما قد لا يكون هذا الحال). مع جداول الأرصدة الخاصة بنا:

نحن نجعل كل خطوة صريحة فيما يلي:

1. يودع المشارك الفردي عملاته الإيثريوم إلى بروتوكول الإيثريوم، مستلماً موقفًا افتراضيًا للـ soETH من بروتوكول الإيثريوم.
2. يقوم المراهن الفردي بإيداع soETH الخاص به تقريبًا في EigenLayer عن طريق تعيين عنوان السحب الخاص به إلى عنوان البود EigenLayer. كبديل، يتلقى المراهن الفردي موقفًا افتراضيًا [soETH] من EigenLayer، مما يتيح له في نهاية المطاف تشغيل ترتيب العمليات بشكل عكسي.

توازن الارصدة

يمكننا بالفعل إجراء بعض الملاحظات الشيقة من القوائم المالية أعلاه. الأولى هي أن بروتوكول Ethereum ليس لديه أي تصور على الإطلاق لـ [soETH]، حيث أن هذا لا يظهر في قائمته المالية بمفردها. تم مناقشة هذه المسألة في " فك تجزئة PBS: نحو التزامات المقترح المفروضة بروتوكولاً (PEPC)تظل لدى العارض الذي تم تقليصه بواسطة EigenLayer رصيد تخزين كامل على ورقة الرصيد لبروتوكول Ethereum، مما قد يؤدي إلى خطر أخلاقي وعدم توازن في المكافآت (فالعارض الذي لم يُخفض بالكامل لا يزال يحصل على مكافآت كاملة من بروتوكول Ethereum). نوضح سيناريو التقليص في الأوراق المالية التالية، مع إعطاء أرقام توضيحية لتوضيح المشكلة:

تم حل هذه المشكلة بمجرد أن يقوم EigenLayer بالإبلاغ بدقة عن تخفيض EigenLayer للمحقق إلى بروتوكول Ethereum، مع إعادة توازن الأوراق. يمكن ذلك مع EIP-7002: تنفيذ طبقة الخروج القابل للتنفيذ، على الرغم من المستوى الخشن، حيث يخرج مشغل البيانات الثنائي ببساطة المصادق، ولكن ما زال من الضروري الطبقة الخاصة EigenLayer أو EigenPod لتشغيل الإشارة إلى بروتوكول Ethereum PoS. هذا الإجراء مصلحة لطبقة EigenLayer لأن الحساب السليم يعود بالنفع على الخدمات التي تتمتع بالأمان من خلال EigenLayer ويزيد في نهاية المطاف من ثقة المشغلين وإعادة المشاركة في التنفيذ الوفي للمنصة.

يمكن أن يُجبر مشغّل أدق على سحب جزئي من رصيد المحقق من توافق إيثريوم، دون الخروج من المحقق تمامًا. هذا مرغوب فيه لخدمات EigenLayer التي ترغب في تعاقب المحققين جزئيًا، دون تشغيل خروج. يُرجى ملاحظة أن كل من EIP-7002 وسحوبات السحب الجزئية المُحفزة بطبقة التنفيذ غير متوفرة على شبكة إيثريوم الرئيسية اليوم. كما تُرجى ملاحظة أن @mikeneuder/eip-7251-faq">سيجمع MaxEB (إزالة الحد البالغ 32 إيثريوم على الرهان الرئيسي الواحد للمحقق) بشكل جيد مع السحب الجزئي، مما يزيل حافزًا إضافيًا للمحققين للبقاء غير مجزأين (تشغيل العديد من 32 محقق إيثريوم بدلاً من محقق واحد 2048 إيثريوم على سبيل المثال).

بناءً على غياب هذه الميزة الجزئية للسحب، هناك حافز إضافي للحفاظ على تسجيل EigenLayer مستقل عن تسجيل بروتوكول Ethereum، مما قد يسبب، كما لاحظنا أعلاه، عدم توافق بينهما. فيما يلي، نصور مراقب يتم خصم 8 ETH منه من قبل EigenLayer، والذي لا يخرج المراقب من مهامه في التوافق (الرصيد المستبعد هو 16 ETH):

AVS تدعي

قد يتساءل الشخص عن مكان 8 [soETH] في المثال السابق. يترك هذا القرار لخدمات التحقق النشطة المدعومة بطبقة EigenLayer (AVS). AVS هو خدمة تطلب بعض الرهان كضمان. وجود الرهان يسمح للخدمة بإلتزام موثوق به بأداء معين، حيث يمكن خصم الرهان إذا لم تتم الخدمة بشكل صحيح.

يقوم محقق التخزين بالتسجيل في AVSs عبر EigenPod الخاص بهم. عندما يفعلون ذلك، يطبع EigenPod مطالب جديدة تُعرض لـ AVSs، تمثل الضمانات التي يتم حاليًا الاحتفاظ بها تحت EigenPod. يجب علينا الآن أن نقوم بتمييز بين نوعين من المطالب.

1. يدعي AVS: نحن نستخدم [soETH] للدلالة على هذه الادعاءات، مشددين على أنها مستمدة من قيمة الأصول بين القوسين [ ].
2. مطالبة المسوغ: سنستخدم الآن [soETH]* لتوضيح الجودة الخاصة لهذه المطالبة، التي يتم استردادها من قبل المسوغ فقط بعد تسوية جميع مطالب AVS. بمعنى آخر، تمتلك المطالبة للمسوغ أقل أولوية، ويتم استرداد الأصول المتبقية بمجرد تسوية جميع المطالبات الأخرى AVS.

1. المراهن الفردي يعيد الرهان.
   1. تم وضع soETH تحت سيطرة EigenPod.
   2. [soETH] يتم استلامها من قبل المعيد الفردي للتخزين، مطالبة بأصولهم المعيدة.
2. يقوم المراهن الفردي بطبع مطالبة جديدة، [soETH] من EigenPod الخاص بهم.
3. يتم منح المطالبة كضمان لشبكة AVS.
   1. [soETH] يتم نقلها إلى AVS.
   2. يتم منح المعيد إيصال الأمان الجديد.

بمجرد أن يتصرف المحقق بطريقة معاكسة لأهداف AVS (على سبيل المثال، تحريض حالة القطع لـ AVS)، قد يقرر AVS على سبيل المثال حرق مطالبة المحقق بـ ETH المراهنة، أو الاحتفاظ بالرهن كإيراد لـ AVS. نوضح هذا الخيار الثاني فيما يلي، عن طريق افتراض أن بروتوكول Ethereum يقوم ببساطة بتحويل 8 ETH إلى EigenPod كسحب جزئي بعد تقرير القطع EigenLayer، بعد ذلك يقوم EigenLayer بتحويلها إلى AVS:

1. يقوم AVS بتقليص الضمان الخاص بالمعيد الوحيد للتخزين مرة أخرى.
   1. الضمان الخاص ب AVS يتكون من 32 [soETH]. بمجرد الإبلاغ عن التخفيض، يقوم AVS بإزالة 8 [soETH] من الضمان، ويقوم بالإبلاغ عن التخفيض إلى EigenPod، الذي يقلل أيضًا من مسؤولياته بمقدار 8 [soETH].
   2. لم يعد AVS يُمنح 32 avs.[soETH] للمعيد الفردي، مما يقلل هذا المطالبة بـ 8 avs.[soETH].
   3. بعد أن تم تخفيضها بواسطة AVS، يقلل EigenPod من مطالبة المعين الفردي بالتخزين بمقدار 8 [soETH]*.
2. يقوم EigenPod بالإبلاغ عن القصاص في بروتوكول Ethereum، مما يؤدي إلى سحب 8 ETH.
   1. ينخفض مطالبة الأصول المعروضة في بروتوكول Ethereum إلى 24 soETH.
   2. تم معالجة سحب جزئي لمقدار 8 ETH، ويتلقى EigenPod الـ 8 ETH المغلقة مسبقًا في بروتوكول Ethereum.
3. يوجه EigenPod العقوبة ETH 8 إلى AVS، الذي يمكنه التخلص منه كما يشاء مجاناً.

إعادة-التخزين-التخزين-التخزين-التخزين-...

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

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

نحن نعبر عن [X]p الأصل X المعاد تخزينه مرة أخرى. في الوقت الحالي ، هذا تعريف بسيط ، ولكننا سنلمح إلى بعض الخصائص الخاصة بهذه الأصول بعد تفصيل خطوات هذه القوائم المالية. يمكن لـ EigenPod طباعة هذه الالتزامات حسب الرغبة، مزورة لتكوين أصول جديدة كلما التزم المعاد بنفسه ب AVSs جديدة.

1. يضع المعيد الأصول X تحت سيطرة EigenPod. هذا الفعل هو التزام من المعيد بأنه إذا فشل في تقديم الخدمات التي يسجل لها، فقد يتم أخذ جزء أو كل من الأصول X منه. يتم استلام المطالبة [X]* لتمثيل هذا التزام.
2. نحن نوضح هنا الملتزم بإعادة الوضع الآمن لسلسلة Y.
   1. يحصل المعيد على أصل معاد تعيينه الأول [X]¹ عن طريق دخول سلسلة AVS 'تأمين سلسلة Y'.
   2. المعالج يعيد الرهان [X]¹ تحت سلسلة Y، مستلمًا soY.[X]¹ (مطالبة برهانهم + مكافآت - عقوبات). يجب على سلسلة Y أن تكون 'مدركة' أن الأصل الذي تم إعادة الرهان عليه يؤمن حاليًا بروتوكولها، أي يجب أن تكون واثقة من أن هناك شيئًا ما يُراهن عليه لشخص ما.
3. نوضح هنا الشخص الملتزم بإعادة الرهان لتأمين سلسلة Z.
   1. يحصل المخزن مرة أخرى على أصل مخزن [X]² عن طريق الدخول إلى سلسلة AVS "تأمين سلسلة Z".
   2. حصص إعادة التخزين [X]² تحت السلسلة Z ، تتلقى soZ. [X]² (مطالبة بحصتهم + مكافآتهم - عقوبات). يجب أن "تفهم" السلسلة Z أن الأصل المعاد تخزينه يؤمن حاليا بروتوكوله ، أي يجب أن يكون واثقا من وجود شيء على المحك لشخص ما.

بناءً على القوائم المالية أعلاه، نتناول الآن بعض الأسئلة. نلاحظ أن السلسلة Y تتلقى [X]¹، بينما تتلقى السلسلة Z [X]². هل هذه الأصول من نفس النوع، وهل يمكننا أن نقول فقط أن كلتاهما تتلقى أصول نوع [X]؟

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

1. الحالة 1: تقوم AVSs ، هنا بسلاسل آليات إجماع Y و Z ، ببساطة بحرق الرموز المميزة التي تم قطعها ، وهو ما تفعله معظم بروتوكولات PoS. عندما يتم حرق الرموز المميزة ، فإن التسلسل الهرمي للمطالبات لا يهم حقا: إذا أرادت كلتا السلسلتين Y و Z خفض إعادة التخزين ل 32 ETH ، فكل ما يحققونه هو حرق نفس الضمان مرتين.
   1. ملاحظة: يطلق أندرز على هذا "التخزين المتجول", إعادة التخزين عدة مرات دون تسلسل المطالبة 😊
2. الحالة 2: يرغب الAVSs في استلام الرموز التي تعرضت للمخاطر، على سبيل المثال، لتعويض طرف ما تعرض للظلم. مثال هنا MEV-Boost+، يعد مشغل AVS هو من يقترح كتلة، والذي يلتزم بعدم التلاعب بمحتويات الكتل التي تم استلامها بوضوح، وإذا فعلوا ذلك، فإنهم يلتزمون بتعويض الباني والريلي عن الفوضى. في هذه الحالة، نفترض أن عدة AVSs يستردون مطالباتهم في نفس الوقت بعد انحرافات متوازية من قبل نفس المعيد، ولا يكون هناك ما يكفي لتغطية جميع المطالبات. ثم يصبح سؤال أولوية المطالبة أو توزيع المدفوعات ذات الصلة.

فصل AVSs

في القسم السابق، قد قدمنا AVSs، وهي الخدمات التي يلتزم بها العارض المعاد رهانه بتقديمها. يتم تأمين الالتزام عبر EigenLayer، الذي يمتلك رهان العارض المعاد الموثق ويُسوّي المطالبات التي قدمتها AVSs.

ولكن ما هو AVS بالضبط؟ تمامًا مثلما فصلنا أعلاه بين بروتوكولات LST ومشغلي LST، من المنطق هنا مناقشة هذين الدورين الوظيفيين بشكل منفصل، وتخصيص أصول ومطالبات مختلفة لهما.

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

1. إعادة المراهنين كمشغلي AVS: يجسد AVS بروتوكول يبحث عن مشغلين للعمل، ومشغلو العقد الذين يعيدون المراهنة على soETH يصبحون مشغلين لبروتوكول AVS بأنفسهم.
2. إعادة المتعاملين كمزودي رأس المال لمشغل AVS: في هذه الحالة، يقبل مشغل AVS الأصول المعادة المرهونة لأداء وظيفته كمشغل نيابة عن المندوبين الذين يوفرون رأس المال. ينقل المتعامل ثم أصوله المرهونة مرة أخرى إلى مشغل AVS، الذي يؤدي بعض الوظائف نيابة عن المتعامل.

في الأقسام أعلاه، قمنا بتحديد إعادة التحقق كمزود رأس المال (تعاد رهاناتهم الخاصة) ومشغل AVS (من المتوقع أن يقدموا بعض الخدمات بأنفسهم). ومع ذلك، يمكننا النظر في بنية مختلفة، حيث لا يقوم إعادة التحقق بتشغيل AVS بأنفسهم، بدلاً من ذلك يفوضون هذه الوظيفة إلى بعض المشغل. يمكن أن يمكن هذا المشغلين الفرديين من المنافسة على العائد مع مزودي خدمات التخزين المتكاملين (SSP) / المشغلين. يقدم المثال التالي موقفًا حيث يقوم مشغل AVS واحد بالتحقق على بعض السلاسل Y و Z، نيابة عن معاد رهان. نفترض أن جميع مطالبات AVS هي من نفس النوع [X] (لا توجد هيكلية مطالبات).

1. يضع المعيد مرة أخرى الأصول X تحت سيطرة EigenPod. هذا الفعل هو التزام من المعيد مرة أخرى بأنه إذا فشل في تقديم الخدمات التي يشترك فيها، فقد يتم أخذ جزء أو كل من الأصول X منه. يتم استلام المطالبة [X]* لتمثيل هذا التزام.
2. نحن هنا نوضح هنا الملتزمون بإعادة الوضع الآمن لسلسلة Y، مفوضين واجبات التحقق إلى مشغل AVS.
   1. يحصل المعيد على الأصل المعيد [X] عن طريق دخول سلسلة AVS "تأمين سلسلة Y".
   2. المعيد يعطي الأصل المعاد لمشغل AVS، مقابل الحصول على "الإيصال" noY.[X].
   3. يقوم مشغل AVS برهن [X] تحت chain Y، مما يتلقى soY.[X] (مطالبة برهانهم + مكافآت - عقوبات). يجب على chain Y 'أن يفهم' أن الأصل الذي تم إعادة رهنه حاليًا يؤمن بروتوكوله، أي يجب أن يكون واثقًا من أن هناك شيئًا مرهونًا لشخص ما.
3. نحن نوضح هنا المشارك الذي يعيد التصويت لضمان سلسلة Z، ويكلف واجبات التحقق لمشغل AVS.
   1. يحصل المعيد على أصل تم إعادة نقده [X] عن طريق دخول سلسلة AVS "تأمين السلسلة Y".
   2. يعطي المعيد التخزين الأصل المعاد تخزينه [X] إلى مشغل AVS ، ويحصل على "إيصال" noZ. [X].
   3. مشغل AVS يراهن [X] تحت سلسلة Z، مما يؤدي إلى الحصول على soZ.[X] (مطالبة لرهانهم + المكافآت - العقوبات). يجب على سلسلة Z أن "تفهم" أن الأصل المراهن حاليًا يؤمن بروتوكولها، أي، يجب أن تكون واثقة من أن هناك شيء مراهن عليه لشخص ما.

في هذا النموذج، نستعيد البنيات المألوفة. ولا يتلقى العائد أي أصول من قبل الذي يعيد زرعها، مما يلمح بالفعل إلى إمكانية تسييل مثل هذه المواقع. سنناقش هذه البنى المتقدمة في المنشور التالي، ولكن قبل ذلك، دعونا نذكر البحث الجاري حول "PBS لـ AVS" كنهج لتقليل تمركز المشغل.

تحتإطار التفويض التفاؤلي (ODF)المقترح من Drew Van der Werff (انظر أيضامحادثة ورشة عمل كريبتوإيكونومكس الأخيرة لـ 0xKydo في كولومبيا)، يكون جهاز إعادة التخزين قادرا على التعاقد على تشغيل المركبات المضادة للمركبات التي يشترك فيها في سوق مفتوحة من "المعالجات المشتركة". يمكن تحديد المعالجات المشتركة مع دور "المنشئ" ل PBS ، وهو كيان متخصص قادر على تشغيل عمليات مكثفة محتملة ، والتي لا يمكن الوصول إليها من قبل الكيانات غير المتطورة أو محدودة الحوسبة مثل المخزنين الفرديين. ويقدم المجهزون المشاركون عطاءات إلى القائمين على إعادة التخزين، في آلية على غرار مزاد الاشتراء، مما يسمح للقائم بإعادة التخزين بتحديد المشغل الأكثر ربحية. ولزيادة ضمان الأداء، يكون المجهزون المشاركون مشاركين مستعبدين، ويعرضون أنفسهم لفقدان رباطهم إذا قدموا عملا غير صالح يمكن إثباته أثناء عملياتهم.

تنصل:

1. هذا المقال مأخوذ من [مرآة], جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [سعر الوكالة]. إذا كانت هناك اعتراضات على هذا النشر مرجعًا، يرجى التواصل مع البوابة تعلمالفريق، وسوف يتعاملون معه بسرعة.
2. إخلاء المسؤولية عن المسؤولية: وجهات النظر والآراء المعبر عنها في هذه المقالة هي فقط تلك التي تعود إلى الكاتب ولا تشكل أي نصيحة استثمارية.
3. تُجرَى ترجمة المقالة إلى لغات أخرى من قِبَل فريق Gate Learn. ما لم يُذكَر، يُحظَر نسخ أو توزيع أو نسخ المقالات المترجمة.