TL;DR

• تم تصميم ePBS مع التركيز على أمان المنشئ، مما يمنح المنشئين السيطرة الكاملة على معاملات الكتل.
• يدمج فصل مقترح-بناة (PBS) مباشرة في طبقة التوافق في إيثريوم ، والمشار إليه باسم In-Protocol PBS ، لمعالجة فشل إعادة الإرسال المحتملة والقضاء على نقاط الفشل الفردية في النظام.
• تواصل ePBS مؤسسة PBS من خلال تقليل سيطرة كيان واحد على محتوى الكتلة، وتعزيز مقاومة الشبكة للرقابة واللامركزية.
• لجنة توقيت الحمولة (PTC) تضمن الوقتية وصحة المعاملات في الكتل الجديدة.

مقدمة

في شهر فبراير، أعرب مطور Prysm Potuz عن قلقه بشأن قضايا الثقة في شبكة Ethereum الرئيسية، مشيرًا إلى تأجيل إصدار Electra حتى عام 2025، باستخدام حدث التوافق لتحسين تصميم ePBS. ومع ذلك، كانت هناك آراء مختلطة داخل مجتمع Ethereum، حيث أبدى بعض المطورين والباحثين قلقهم بشأن المخاطر المحتملة. تختلف الآراء بشأن ePBS، لذلك سنستكشف اليوم ما هو ePBS وكيف يختلف عن PBS.

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

في PBS، يجب أن يكون هناك دور وسيط ليعمل كمعالج ثقة طرف ثالث:

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

تصميم ثوري لـ ePBS

فصل باني المقترح المدمج

المقترح المنصوص عليه - بناء (ePBS) هو نوع من PBS المتكامل مباشرة في طبقة الاتفاق الخاصة ب Ethereum، المعروف أيضًا باسم In-Protocol PBS. تم تصميمه لمعالجة فشل الريلي المحتمل والقضاء على نقاط الفشل الفردية في النظام. كآلية توافق ناشئة، سننغمس الآن في ePBS، مشرحين مبادئه الأساسية ومزاياه، وكيف يختلف عن الفصل التقليدي بين المقترح والبناء (PBS).

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

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

• المقترح: مسؤول عن اقتراح الكتلة، بما في ذلك معلومات رأس الكتلة.
• الباني: المسؤول عن بناء محتوى الكتلة.

فوائد رئيسيتان

العقوبة المباشرة للأفعال الخبيثة وعدم حاجة إلى ثقة من طرف ثالث بروتوكول غيت

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

1. القدرة المدمجة على الكشف والتنفيذ

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

2. تقليل الاعتماد على الأطراف الثالثة، معززة اللامركزية

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

*مقارنة بين PBS التقليدي و ePBS👇

تصميم ePBS

رقصة التنفيذ والتحقق

في نظام إثريوم للمحمل الأصلي (PoS)، يتم تقسيم الوقت لكل فتحة إلى فترات بمدة 12 ثانية. في كل فتحة، يتم اختيار مقترح بشكل عشوائي ليقترح كتلة، ويتم تعيين لجنة للتحقق من صحة الكتلة. إذا لم يتم اقتراح كتلة خلال الفتحة المعطاة، سيقوم المقترح المسؤول بالتحقق من صحة الكتلة السابقة بعد 4 ثوانٍ.

المصدر: إثريسيرش، سيتم معالجة فتحة ePBS واحدة بواسطة طبقة الاتفاق (CL) وطبقة التنفيذ (EL). يتم بث معلومات الكتلة في طبقة الاتفاق، ثم يتم تقديم الكتلة إلى طبقة التنفيذ للتحقق.

1. مرحلة المزايدة على الكتلة: يبدأ البناء في المزايدة ويُرسل العرض إلى المقترح.
2. بث المقترح: يختار المقترح العرض الفائز ويقرر ما إذا كان سيستخدم قائمة الاستدراج لبناء محتوى الكتلة، ثم يبث الكتلة.
3. تصويت العارض: عند رؤية الكتلة، يصوت العارضون استنادًا إلى نتائج التحقق الخاصة بهم.
4. الشهادة المجتمعة: تتم إنشاء الشهادات المجتمعة بواسطة المجمعين الذين يجمعون بين دلائل عدة محققين لنفس الكتلة. يستخدم المحققون بعد ذلك الشهادة المجتمعة للتحقق من الكتلة.
5. بث الحمولة: يجب أن يقوم المُنشئ بنشر حمولة التنفيذ الكاملة في الوقت المحدد.
6. تصويت PTC: تشرف لجنة توقيت الحمولة الصافية (PTC) وتتحقق مما إذا كانت حمولة المنشئ صالحة وفي الوقت المناسب.
7. ينشر مقترح الخانة التالية كتلته ، ويبنيها إما على كتلة كاملة أو فارغة بناء على نتائج تصويت PTC والشهادات المجمعة. تعتبر الكتلة التي تحتوي على نسبة أعلى من أصوات PT في الوقت المناسب كتلة كاملة.

PTC - ضمان الوقت وصحة المعاملات في الكتل الجديدة \تضمن لجنة الوقتية للحمولة (PTC) أن المعاملات في الكتل الجديدة تتم بشكل متزامن ومضافة بدقة. تتكون هذه اللجنة من المدققين (521 عضوًا مستعارين من لجنة سلسلة البيانات) الذين يتحققون مما إذا كان المنشئ قد أكمل ملء المعاملات في الكتلة ومما إذا تم تنفيذ هذه المعاملات بشكل صحيح وفقًا للقواعد قبل نهاية دورة إنشاء الكتلة.

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

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

• كتلة كاملة: تحتوي الكتلة على مجموعة كاملة من الحمولة الصالحة ، ومن المحتمل أن تتضمن معاملات متعددة ، ويتم تحديث حالة تنفيذ المعاملة في الوقت المناسب.
• الكتلة الفارغة: تحتوي الكتلة على عدد قليل جدًا أو لا تحتوي على أي معاملات على الإطلاق. قد تكون كتلة CL ، ولكنها لا تحدث حالة EL.
• كتلة ناقصة: فتحة فارغة. يشير هذا إلى كتلة كان من المتوقع أن تكون موجودة ولكنها لم تتم إنشاؤها أو إضافتها بنجاح إلى السلسلة. يمكن تصنيف الكتل المفقودة ككتل ممتلئة أو فارغة بناءً على تصويت الاختيار الشوكي (الكتلة، الفتحة).

مقاومة الرقابة في ePBS، مع تصميم قائمة الاستثناءات المدمجة

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

في مقالاتنا السابقة، تحدثنا عن الCL العملية (لمزيد من التفاصيل ، يرجى زيارة: https://mp.weixin.qq.com/s/EBzr0ttBLosYnRBNVKF6rg). باختصار ، يزود مقدم العرض المنشئ بقائمة بالمعاملات التي يجب تحديد أولوياتها. يجب أن تتضمن هذه القائمة جميع المعاملات النشطة حاليا، بغض النظر عما إذا كانت موجودة في تجمع المعاملات أم لا. طالما أن هناك مساحة متبقية في الكتلة ، يجب تضمين المعاملات من القائمة في كتلة المنشئ. إذا كانت الكتلة ممتلئة ، فيجب على المنشئ أن يشير بوضوح ويؤكد أنه قد اعترف بالقائمة.

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

ملخص

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

من المهم ملاحظة أن ePBS يوفر خيارا لفصل Proposer-Builder على مستوى البروتوكول ، بدلا من أن يكون إلزاميا. الفرق الرئيسي بين ePBS والنماذج الأخرى هو في آليات الدفع ونماذج الثقة. عند النظر في قضايا الثقة في البروتوكول بأكمله ، فإن التكلفة التي يتعين دفعها هي الحاجة إلى الالتزام بدفع الرسوم مقدما. في المقابل ، يسمح MEV-Boost بالدفع إلى Beacon Proposer بناء على الأرباح المستمدة من تسلسل حمولة التنفيذ ، مما يوفر مساحة أكبر للربحية. ربما في يوم من الأيام ، يمكن أن يتطور ePBS إلى نقطة لم تعد فيها التزامات الرسوم المسبقة ضرورية - وهذا أمل صغير للمستقبل!

المرجع

@ttsao/epbs-faq0"">https://hackmd.io/@ttsao/epbs-faq0

@potuz/rJ9GCnT1C"">https://hackmd.io/@potuz/rJ9GCnT1C

https://mirror.xyz/ohotties.eth/kw_7qbkOl4NV1pmpRgVwtsS-7TZff_zTmmNEOm2BbmU

https://mirror.xyz/barnabe.eth/LJUb_TpANS0VWi3TOwGx_fgomBvqPaQ39anVj3mnCOg

https://ethresear.ch/t/epbs-design-constraints/18728?u=barnabe

@potuz/ry9NirU2p"">https://hackmd.io/@potuz/ry9NirU2p

https://vitalik.eth.limo/general/2023/09/30/enshrinement.html

https://ethresear.ch/t/three-dichotomies-in-epbs/16267

https://ethresear.ch/t/the-contention-between-preconfs-and-epbs/19770?utm_source=substack&utm_medium=email

تنويه:

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