فهم EigenLayer من منظور إعادة التصميم

المصدر: مجتمع Denglian

في منشور المدونة هذا، سنأخذك إلى فهم تطور بروتوكول EigenLayer، وصف كيفية ظهور بنية EigenLayer من مفهومها الأولي.

هذه المدونة مستوحاة من سلسلة "Account Abstraction" لديفيد فيليبسون ^{[5]< / سوب> إلهام. شكر خاص للمجتمع نعوم هورويتز[6]، شيفا[7]، NashQ[8]، مايك نيودر[9] وسينا[10] لتعليقاتهم وملاحظاتهم على هذه المقالة.}

في حين أن العديد من الأشخاص على دراية بمصطلحي restain وEigenLayer، إلا أن القليل منهم فقط يعرفون أن عقدنا الأساسي يحتوي على آلاف الأسطر من الكود< سوب>[11]، وبنيته هي كما يلي.

تعمل EigenLayer على تبسيط البنية

لماذا تصبح الفكرة البسيطة معقدة للغاية؟

في مشاركة المدونة هذه، سنأخذك عبر البروتوكول من خلال وصف كيفية ظهور البنية المعقدة الحالية لـ EigenLayer من مفهومها الأوليEvolution .

هذه المقالة مخصصة للأشخاص الذين لديهم فهم أساسي للعقود الذكية وسمعوا عن EigenLayer أو إعادة الإنشاء.

نظرًا لأن الغرض من مشاركة المدونة هذه هو تقديم شرح عالي المستوى لـ تطور تصميم EigenLayer، لذلك قد تختلف الواجهة والمتغيرات والمنطق عن عقد EigenLayer الأساسي الحالي ^[12].

الآن، لنبدأ.

الهدف النهائي: جعل البنية التحتية للبناء سهلة

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

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

تعد آليات الإجماع ضرورية لتسهيل التفاعل بين هذه العقد، سواء كانت L1 أو شبكة أوراكل أو جسر.

إثبات العمل^[13] يستهلك طاقة جدية، وإثبات السلطة^[14] مركزي للغاية. ولذلك أصبح إثبات الحصة^[15] (PoS) هو آلية الإجماع الرئيسية لمعظم مشاريع البنية التحتية.

ومع ذلك، فإن إطلاق شبكة PoS جديدة أمر صعب.

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

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

ثالثًا، يجب على أصحاب المصلحة التخلي عن فرص المكافآت الأخرى، مثل مكافأة 5% المقدمة من Ethereum.

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

افترض في الوقت الحالي أن أصحاب المصلحة المشاركين في مشاريع البنية التحتية مسؤولون أيضًا عن العمل دون اتصال بالإنترنت برامج لضمان سلامتهم. لكننا سنغير هذا الافتراض لاحقًا في المقالة.

تم إنشاء EigenLayer لحل هذه المشكلات:

• وهو بمثابة منصة لربط أصحاب المصلحة ومطوري البنية التحتية.

• يمكن للمتعهدين استخدام أي رمز مميز لتوفير الأمن المالي.

• يمكن للمتعهدين اختيار إعادة تنفيذ تعهداتهم الأصلية والمساهمة في أمن البنية التحتية الأخرى أثناء تلقي مكافآت Native Ether.

• من خلال إعادة التخزين، تجمع EigenLayer الأمان معًا بدلاً من تجزئته.

الورقة البيضاء لـEigenLayer^[16] تتم مناقشة هذه القضايا بعمق.

تعمم طبقة EigenLayer مفهوم توفير الأمن الاقتصادي.

الهدف 1: إنشاء منصة تربط بين أصحاب المصلحة ومطوري البنية التحتية

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

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

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

من الناحية المفاهيمية عندما يتم التعهد بمبلغ 100 مليون دولار أمريكي لمشروع ما، فهذا يعني أنه إذا انحرف عن جزء من هذه الـ 100 مليون دولار أمريكي سيتم قطعه إذا انتهك وعوده وأظهر سوء النية. وببساطة، يمكن فهم "القطع" على أنه تدمير لهذا الصندوق.

كلما زاد العدد، زاد الأمان والأمان الذي يوفره لمستخدميه.

إذا سمحنا لأصحاب المصلحة بتعيين حصص لالتزامات مختلفة، فيمكننا إنشاء منصة سهلة الاستخدام فوقها.

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

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

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

يشكل هذا أساس EigenLayer - يمكن لأي صاحب مصلحة تقديم التزام موثوق بأي بروتوكول للبنية التحتية.

التصميم الأولي لـ EigenLayer

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

يمكن للمتعهدين الآخرين أيضًا مشاركة الرموز المميزة في هذا العقد، مما يزيد من أمان البنية التحتية. سوف نسمي هذا العقد TokenPool.

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

< li >

أصحاب المصلحة: أي شخص يقدم الرموز المميزة لـ EigenLayer.

• الرمز المميز: أي نوع من الرموز المميزة؛ في الوقت الحالي، فكر في الأمر ببساطة باعتباره رمزًا مميزًا لـ ERC20 .

• TokenPool: عقد ذكي يحفظ الرموز المميزة للمستثمرين.

• قص: يزيل وصول أصحاب المصلحة إلى الرموز المميزة الخاصة بهم.

< span style="text-align: center;">يمكن التعبير عن واجهة TokenPool هذه على النحو التالي:

عقد TokenPool {
    mapping(address => uint256) الرصيد العام;
   ;   تعيين (عنوان => عنوان[]) مشرح عام;

    حصة الوظيفة (مبلغ uint256) عام;
    سحب الوظيفة () عام;
     ;تسجيل الوظيفة(مشرح العنوان) فقطالمالك;

باستثناء الحصة< /code> والسحب والتوازن والوظائف والمتغيرات، كما قدمنا ​​دالة جديدة ومتغيرًا جديدًا. يقوم المتغير slasher بمراقبة AVS المسجل حاليًا لكل مسؤول. تسمح وظيفة التسجيل لأصحاب المصلحة بالمشاركة في AVS

لذلك، فإن التسجيل في AVS يمنح "القاتل" القدرة على خفض حصتك. .

مع هذا التعديل، بعد التخزين في TokenPool، يمكن لأصحاب المصلحة الانضمام عن طريق استدعاء وظيفة التسجيل الخاصة بـ AVS . تحتوي هذه الوظيفة على عقد القطع المائل الخاص بـ AVS في تعيين slasher.

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

أثناء عملية الاستخراج، يمكن لعقد TokenPool أن يطلب كل slasher تحديد ما إذا كان صاحب المصلحة مؤهلاً للانسحاب. يتم التحقق من ذلك عبر وظيفة isSlashed في عقد slasher. إذا كانت قيمة isSlashedTRUE بالنسبة إلى صاحب الحصة هذا، فلن يتمكن صاحب الحصة من سحب حصته لأنه تم قطعها.

عقد TokenPool {< br>    mapping(address => uint256) public sessionrBalance;
    mapping(address => uint256) publicoperatorBalance;
    mapping(address => عنوان) 
    mapping(address => عنوان[]) المشرح العام;

    حصة الوظيفة (مبلغ uint256) عامة;
    سحب الوظيفة () عام;
    وظيفة مندوب إلى (مشغل العنوان) عامة;
    وظيفة التسجيل (مقطع العنوان) عامل التشغيل فقط;
    خروج الوظيفة (مقطع العنوان) عامل التشغيل فقط;< br>}

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

لقد أجرينا أيضًا تغييرات طفيفة على تعيين slasher. وهو يمنح الآن slasher سلطة قطع العقد للمشغل، بدلاً من المسؤول.

contract TokenPool {
    mapping(address => uint256) public StakerBalance;
 
    حصة الوظيفة (مبلغ uint256) عامة;
    وظيفة سحب () عامة;

TokenPool سيتتبع العقد فقط رصيد كل صاحب مصلحة. سيتم التعامل مع تتبع AVS والانضمام إليه بواسطة DelegationManager.

شرطة مائلة للعقد {
    تعيين (address => bool) مقطوعة;

 شرطة مائلة للوظيفة (عامل العنوان، ؟؟؟ إثبات)؛

}

بعد تنظيف العقد وبعد تقسيم كل مكون إلى وحدات، تبدو البنية الآن كما يلي:

تصميم الطبقة المتوسطة EigenLayer: بعد فصل دور المشغل ودور المسؤول.

الهدف: دعم المزيد من الرموز المميزة

حتى الآن، تم تطوير التصميم يدعم فقط التوقيعالرمز المميز لأننا نحتفظ فقطبالتعيين لأصحاب المصلحة.

يمكننا حل هذه المشكلة من خلال اعتماد نموذج قائم على مشاركة LP وإنشاء TokenPool< /code خاص بالرمز المميز >.

للقيام بذلك، سنقوم بإنشاء عقد جديد يسمى TokenManager. سيكون TokenManager هو المكان الذي يذهب إليه أصحاب المصلحة لمشاركة وسحب رموزهم المميزة.

ضمن TokenManager، كل رمز مميز سيكون له TokenPool . سيكون TokenManager بمثابة مركز المحاسبة لجميع الرموز المميزة، ولن يقوم بتخزين أي رموز مميزة بنفسه. سيحتفظ كل TokenPool بالرمز المميز الخاص به.

مكون جديد مصمم الآن لتتبع الرموز المميزة لأصحاب المصلحة.

عندما يقوم المستخدم بتجميع رمز مميز، تتم معالجته بواسطة TokenManager. يقوم TokenManager بعد ذلك باستدعاء وظيفة stake الخاصة بـ TokenPool المطابق المرتبط بهذا الرمز المميز. سيتم نقل الرموز المميزة للمستخدم إلى TokenPool. في نهاية الوظيفة، سيتم تحديث totalShares وstakerPoolShares لتعكس الحصة الجديدة. يتتبع totalShares العدد الإجمالي للأسهم الصادرة عن TokenPool، بينما يسجل stakerPoolShares ممتلكات كل مشارك فردي في كل TokenPool الكود> عدد المشاركات.

ستبدو واجهة كل عقد كما يلي:

contract DelegationManager {
    // .. .
    mapping(address => mapping(address => uint256)) عاملPoolShares;
    // ...

الآن، وفي ظل نفس البنية الأساسية، يمكن لأصحاب المصلحة مشاركة أي رمز مميز في EigenLayer لحماية AVS الأخرى. 
الهدف: توسيع تصميم AVS
ضع في اعتبارك المواقف التالية : يسحب صاحب المصلحة تعهدهعلى الفور بعد الانخراط في سلوك قابل للتخفيض، وينسحبقبل أن يقوم أي شخص آخر بتخفيض أصوله. 
_على سبيل المثال_، لنفترض أن هناك عاملًا هو مشغل ومسؤول في نفس الوقت، ويعمل بشكل ضار في AVS. قبل أن يتمكن أي شخص آخر من المشاركة على السلسلة، يسحب المشغل حصته من عقد EigenLayer. هذا ممكن لأنه في وقت السحب، لم يتم تحديث slasher بعد لخفض أصولهم. لذلك، لم تعد AVS قادرة على خفض المشغلين/المتعهدين الضارين لأنه لم يعد هناك المزيد من الرموز المميزة المتاحة للقطع. 
 الجدول الزمني المحتمل لأحداث المشغلين/الشركاء الضارين. 
وبالتالي، يتطلب AVS "الآمن" واحدًا يمكنه تجميد المحتوى الضار داخل نفس الكتلة التي يقع فيها الحدث. تخفيض عقد المشغل . يحد هذا القيد بشكل كبير من تصميم AVS، مما يجعل معظم AVS غير آمنة. 
أحد الحلول هو تقديم فترة التفكيك. بدلاً من السماح لأصحاب المصلحة بسحب حصتهم على الفور، فإننا نقدم تأخيرًا في عملية السحب يسمى فترة عدم الالتزام. بعد ذلك، يمكن لأصحاب المصلحة سحب الأموال كما كان من قبل. 
عندما يقرر أحد أصحاب المصلحة الانسحاب من النظام، يتم وضع طلبه في قائمة الانتظار. لن تتم معالجة هذا السحب في قائمة الانتظار إلا بعد انتهاء أطول فترة إلغاء ربط للمشغل. وذلك لأن مشغلًا واحدًا قد يدير عدة AVS، ولكن لا يمكن مواءمة عمليات سحب أصحاب المصلحة إلا مع فترة إلغاء ربط واحدة. لأسباب أمنية، يقوم النظام بتعيين فترة فك الارتباط على أطول فترة. 
على سبيل المثال، إذا عهد صاحب المصلحة بتعهده إلى مشغلين مشاركين في ثلاثة AVS، فإن فترات فك الارتباط لهذه AVS الثلاثة هي ستة وخمسة على التوالي. وسبعة أيام، ثم بعد طلب السحب من EigenLayer، يجب عليهم الانتظار سبعة أيام للوصول إلى حصتهم. وذلك لأن سبعة أيام هي أطول الفترات الثلاث. 
في نهاية فترة السبعة أيام، يمكن لأصحاب المصلحة سحب حصتهم. ومع ذلك، إذا تم تقليص المشغل الذي تم تكليفه به خلال هذه الفترة، فسيتم أيضًا إيقاف عمليات السحب المعلقة. 
من أجل تقديم هذا التغيير، يحتاج DelegationManager إلى تتبع فترة إلغاء الربط لكل عامل وتحديثها عند المشغل ينضم قم بتحديثه عند توفر AVS الجديد. 
contract TokenManager {
 mapping(address => Address) public tokenPoolRegistry;
 mapping(address => mapping(address => uint256)) public StakerPoolShares;
 رسم الخرائط (العنوان => uint256) السحب العامCompleteTime;

 الدالة حصةToPool(تجمع العناوين, مبلغ uint256) عام;
 قائمة الانتظار الوظيفية(تجمع العناوين) عام;
 الدالة CompleteWithdrawal(تجمع العناوين) العام ;


عندما يصطف أصحاب المصلحة في قائمة الانتظار للانسحاب، سيعمل TokenManager مع DelegationManager يتحقق مما إذا كان المشغل المفوض من قبل المتعهد قد تم قطعه. إذا كان عامل التشغيل بدون شرطة مائلة، فسيقوم TokenManager بتحديث withdrawalCompleteTime الخاص بصاحب المصلحة بناءً على DelegationManager وunbondingPeriod الخاص بـ DelegationManager. الوقت الحالي. 
بعد فترة فك الارتباط، يمكن لأصحاب المصلحة إكمال انسحابهم من خلال CompleteWithdrawal. ستتحقق هذه الوظيفة من انقضاء وقت الانسحاب. إذا تم تمريرها، فسيتم نقل الرموز المميزة لصاحب الحصص وفقًا للعملية السابقة. 
كان تصميم هذه العملية معقدًا وخضع لعدة تكرارات في عمليتنا. يمكننا حتى كتابة مقال منفصل حول هذا الموضوع! حاليًا، نستخدم نظام تتبع الوقت لتنفيذ تتبع التفكيك هذا. هذا الجزء لا يزال قيد التقدم! 
وحدات مائلة
بما أننا نقوم بعمل خطوط مائلة الآلية أكثر أمانًا، فلنحاول أيضًا أن نجعلها أكثر معيارية وكفاءة. 
حاليًا، أثناء عملية الاستخراج، يحتاج TokenManager إلى التحقق من كل slasher فرديًا للتحقق مما إذا كان تم قطع المشغل. يؤدي هذا إلى زيادة النفقات العامة على أصحاب المصلحة وقد يقلل بشكل كبير من مكافآت أصحاب المصلحة الأصغر حجمًا. 
أيضًا، نظرًا لأن مطوري AVS عادةً ما يصممون وحدات مائلة، فإن تقسيم هذا المكون المحدد يمكن أن يبسط عملية التطوير لـ AVS الفردية. 
على غرار TokenManager، سنعتمد تصميمًا من جزأين لآلية الشرطة المائلة. يحافظ SlasherManager على حالة كل مشغل. ستتعامل slasher المنفصلة مع منطق الشرطة المائلة لكل AVS. 
 مزيد من وحدات العقد المائل لتقليل تكاليف الغاز لأصحاب المصلحة. 
مقطع العقد {
    وظيفة شرطة مائلة(عامل العنوان, ؟؟؟ إثبات) public;

slasher سيكون خاصًا بـ AVS، وعلى الأرجح تم تطويره بواسطة مطوري AVS. وسوف يتفاعل مع SlasherManager لتحديث حالة المشغلين المختلفين. 
تم تصميم EigenLayer! 
للمراجعة:هدف EigenLayer هو تبسيط إنشاء البنية التحتية.  لقد بدأنا بأربعة أهداف رئيسية: 
بناء منصة لربط أصحاب المصلحة و مطوري البنية التحتية. 
يسمح لأصحاب المصلحة باستخدام أي رمز مميز لتوفير الأمن الاقتصادي. 
تمكين أصحاب المصلحة من إعادة حصة حصصهم وكسب مكافآت ETH الأصلية مع توفير الأمان للبنية التحتية الأخرى. 
تجميع الأمن من خلال إعادة التخزين بدلاً من اللامركزية. 
بعد عدة التكرارات، قمنا بتطوير ثلاثة مكونات أساسية: TokenManager< /code> و DelegationManager وSlasherManager. كل مكون له وظائف محددة: 
بنية مبسطة لـ EigenLayer
< code>TokenManager : يتعامل مع تعهد وسحب المتعهدين. 
DelegationManager: يسمح بتسجيل المشغل وتتبع مشاركات المشغل. 
SlasherManager: يوفر واجهة لمطوري AVS لتحديد منطق الشرطة المائلة. 
تتواصل هذه المكونات الأساسية أيضًا مع بعضها البعض لضمان أمان النظام بأكمله. 
بالإضافة إلى هذه العقود الأساسية، هناك العديد من الميزات والعقود الأخرى التي تعمل على تحسين المجموعة بأكملها. تدعم هذه الميزات الإضافية مجموعة متنوعة من تصميمات AVS، وتبسيط التعقيدات التقنية دون الاتصال بالإنترنت، وتقليل تكاليف الغاز للمستخدمين والمشغلين. 
لمعرفة المزيد حول هذه الميزات الإضافية، يمكنك زيارة مستودع التعليمات البرمجية مفتوح المصدر الخاص بنا: https://github.com/Layr-Labs/eigenlayer -contracts< /p>
إضافة 1: من يثق بمن؟ 
عندما يكون النظام معياريًا، قد يكون من الصعب تتبع افتراضات الثقة بين المشاركين في البروتوكول. لذلك، من المهم جدًا تحديد افتراضات الثقة بين المشاركين في الاتفاقية بوضوح. 
في EigenLayer، يوجد ثلاثة وكلاء رئيسيين: أصحاب المصلحة، والمشغلون، ومطورو AVS. 
يعتمد المشغلون على مطوري AVS لكتابة برامج العميل وشروط الشرطة المائلة على السلسلة بدقة. إذا كان هناك خطأ في برنامج AVS، في أفضل الأحوال، فقد يفوت المشغل دفعات الرسوم المحتملة. في أسوأ الحالات، قد يتم استبعاد المشغل من حصته بالكامل. 
نظرًا لأهمية القيم المعنية، من المهم التأكد من أن النظام بأكمله يحتوي على عجلات تدريب مساعدة قبل وضعه حيز الاستخدام. 
تعمل لجان الفيتو بمثابة عجلات التدريب هذه. لديه القدرة على التراجع عن الخطوط المائلة الناتجة عن السلوك غير الضار. تمثل لجنة الفيتو ثقة متبادلة بين أصحاب المصلحة والمشغلين ومطوري AVS. 
وبهذه الطريقة، يمكن إزالة افتراض الثقة في مطوري AVS. حتى لو كان هناك خطأ برمجي في AVS، فلن يتم معاقبة أصحاب المصلحة والمشغلين. 
يثق المسؤولون في المشغلين الذين يثقون بهم. إذا أساء المشغل التصرف، فقد يفوت أصحاب المصلحة مدفوعات الرسوم المحتملة أو حتى يفقدوا حصتهم بالكامل. افتراض الثقة هذا هو نفس خدمات التحقق الحالية مثل Binance Scking وخدمات التخزين الأخرى. 
يعتمد مطورو AVS على المشغلين الذين يعملون بأمانة. إذا كان المشغلون غير صادقين، فسوف تنخفض خدمة AVS بشكل كبير، مما يؤدي إلى رحيل العملاء وعواقب أخرى. 
يتم افتراض الثقة بين المشاركين من خلال لجنة الفيتو على النحو التالي:
 
يثق المتعهدون بالمشغلين للتصرف بأمانة، وقد يؤدي سوء السلوك إلى شرطة مائلة. 
يثق مطورو AVS في المشغلينلتشغيل برامج AVS بأمانة. 
أصحاب المصلحة والمشغلون ومطورو AVS يثقون في لجنة النقض للتراجع عن الخطوط المائلة. 
الجزء الثاني الإضافي: إعادة الاستعادة الأصلية
حتى الآن ، لقد ناقشنا استخدام LST لإعادة التوقيع المساحي. ومع ذلك، إذا كنت لا ترغب في مشاركة EigenLayer عبر بروتوكول Liquid Scking، فيمكنك البدء في المشاركة في EigenLayer عبر إعادة الستاكينغ الأصلية. 
دعونا نحدد إعادة التخزين الأصلية: هذه هي عملية تقديم التزامات إضافية باستخدام ETH داخل أداة التحقق. إذا انحرف المدقق عن الالتزام، فسوف يفقد ETH الموجود داخل أداة التحقق الخاصة به. 
التحدي هنا هو أن ETH داخل أدوات التحقق هذه غير ممثلة في شكل رموز ERC20. بدلاً من ذلك، توجد ETH في Beacon Chain. إذا لم تكن على دراية بطبقة التنفيذ أو طبقة الإجماع (سلسلة المنارات)، فإن هذا الشرح [17] يعد مصدرًا جيدًا لإطلاعك على آخر المستجدات. 
لحل هذه المشكلة، يمكننا استخدام EigenPod لتتبع أرصدة مدقق Ethereum وخفضها عند الضرورة. 
EigenPod يعمل كنظام محاسبة افتراضي. باستخدام EigenPod يمكننا مراقبة رصيد ETH لكل مدقق إعادة تخزين. 
على مستوى عالٍ، EigenPods يتعامل مع عملية الاستخراج الخاصة بأدوات التحقق من الصحة. عندما يسحب المدقق حصته من EigenLayer، يمر ETH أولاً عبر EigenPod للتحقق مما إذا كان المدقق قد تم تخفيضه. إذا تم قطع أداة التحقق من الصحة، فسيتم تجميد الرموز المميزة ضمن عقد EigenPod، مما يؤدي إلى قطعها بشكل فعال. 
يعد تنفيذ EigenPod
يعد تنفيذ EigenPod أمرًا صعبًا نظرًا لأن مدقق Ethereum يتم تخزين الأرصدة في سلسلة الإشارات ولا يمكننا الوصول إلى بيانات سلسلة الإشارات في طبقة التنفيذ. 
لحل هذه المشكلة، نستخدم أوراكل لتمرير جذر حالة سلسلة المنارة إلى طبقة التنفيذ. من خلال الحصول على جذر حالة المنارة، يمكننا الوصول إلى رصيد أداة التحقق من خلال توفير دليل Merkle المقابل. 
باستخدام EIP-4788[18]، يمكننا إزالة أوراكل والاستعلام عن المعلومات مباشرة من علامة طبقة التنفيذ جذر. 
لتغليف النظام المحاسبي، سنستخدم نماذج مشابهة لنموذجي TokenPool وTokenManager إلى<قوي>معيارينظام إعادة التعهد المحلي. سيتولى كل EigenPod عملية السحب لـ مدقق واحد. سوف يقوم EigenPodManager بالتنسيق مع العقود الأساسية الأخرى لتتبع كمية الأثير التي يراهن عليها كل مشغل وصاحب مصلحة. 
<span ) 10px 10px / 40px بدون تكرار ;الارتفاع: 30px;العرض: 100% ;الهامش السفلي: -7px;border-radius: 5px;'>عقد EigenPodManager{
    mapping(address) => uint256) مشاركات عامة;

  وظيفة createEigenPod(مالك العنوان) عامة;
    وظيفة حصةToPod(جراب العنوان, مبلغ uint256) عامة;
   ;وظيفة pullFromPod(address pod) public;

contract EigenPod{
   address BEACON_CHAIN_ORACLE;
    address podOwner;
   br>
    حصة الوظيفة (مبلغ uint256) عامة;
    وظيفة التحققRestakedBalance(uint256 المبلغ, دليل MerkleProof) عام;
    وظيفة سحب () عامة;

EigenPodManagerيتتبع عدد الأسهم التي يمتلكها كل صاحب مصلحة. يسمح للمشاركين بإنشاء EigenPod الذي يتم إنشاءه له التعهد والانسحاب منه. 
EigenPodتم النجاحالتوازن المستعادمتغير يتتبع توازن أجهزة التحقق المختلفة في سلسلة المنارة. عندما يتغير رصيد أي أداة التحقق من الصحة، يمكن لأي شخص التحقق منه عن طريق الاتصال بـ verifyRestakedBalance()وظيفة لتحديث رصيد أداة التحقق المحددة تلك. ستمرر هذه الوظيفة BEACON_CHAIN_ORACLE الذي حصلنا عليه من جذر حالة المنارة للتحقق مما إذا كان الرصيد المحدث صحيحًا. 
هذه هي الطريقة التي تنفذ بها EigenLayer عملية إعادة التخزين المحلية. 
المواد المرجعية
[1] رابط خطة الترجمة: https://github.com/lbc-team/Pioneer
[2] فريق الترجمة: https://learnblockchain.cn/people/412
[3] الدب الصغير: https://learnblockchain.cn/people/15
 < تمتد نمط = "font-size: 14px؛">[4]learnblockchain.cn/article…: https://learnblockchain.cn/article/7657
[5] سلسلة تجريد الحسابات: https://learnblockchain.cn/article/5426
[6]نعوم هورويتز: https://twitter.com/ProballyNoam
[7]شيفا: https://twitter.com/ShivanshuMadan
[8]NashQ: https://twitter.com/NashQueue
[9]مايك نيودر: https://twitter.com/mikeneuder
 [10]سينا: https://twitter.com/sina_eth_
[11]الكود: https://github.com/Layr-Labs/eigenlayer-contracts/tree/master/src/contracts
[12]العقد: https://github.com/Layr-Labs/eigenlayer-contracts/tree/master/src / العقود
[13]إثبات العمل: https://en.wikipedia . org/wiki/Proof_of_work
[14] الدليل الرسمي: https:// en .wikipedia.org/wiki/Proof_of_authority
[15]إثبات الحصة: https ://en.wikipedia.org/wiki/Proof_of_stake
[16]أبيض الورق : https://docs.eigenlayer.xyz/overview/whitepaper
[ 17] هذا الشرح: https://docs.prylabs.network/docs/concepts/nodes-networks
[18]EIP-4788: https://eips.ethereum.org/EIPS/eip-4788
< تمتد نمط = "font-size: 14px؛">[19]DeCert.me: https://decert.me/