تخطي إلى المحتوى الرئيسي

ما وراء بروتوكول إيثيريوم: فصل المقترح عن الباني

عرض تقديمي حول فصل المقترح عن الباني (PBS)، وهو نمط تصميم يفصل بين أدوار بناء الكتلة واقتراح الكتلة في إيثيريوم.

Date published: 5 فبراير 2024

يشرح هذا العرض التقديمي كيف تطور إنتاج الكتلة في إيثيريوم من نموذج بسيط إلى سلسلة توريد معقدة تشمل المُدَقِّقين، والبناة، والباحثين، والمُرحِّلات. يستعرض بارنابي مونو (Barnabé Monnot) من مؤسسة إيثيريوم أسباب وجود فصل المقترح عن الباني (PBS)، وكيف تتوسط مُرحِّلات MEV-Boost العلاقة بين المُقترِحين والبناة، وما هي الحلول داخل البروتوكول التي يتم استكشافها لتقليل الاعتماد على الثقة وتحسين مقاومة الرقابة، وتوزيع القيمة القصوى القابلة للاستخراج (MEV)، ولامركزية المُدَقِّقين.

هذا النص هو نسخة يسهل الوصول إليها من النص الأصلي للفيديو (opens in a new tab) الذي نشره سي بي إي آر فوروم (CBER Forum). تم تعديله قليلاً لتسهيل القراءة.

مقدمة (0:00)

اسمي بارنابي مونو. سأتحدث قليلاً عما يحدث خارج البروتوكول، وتحديداً عن مفهوم فصل المقترح عن الباني وكيف يتم تشغيله باستخدام المُرحِّلات والكثير من البنية التحتية خارج السلسلة.

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

لماذا يستخدم المُدَقِّقون البناة (0:46)

المثير للاهتمام هو أنه على الرغم من أن البروتوكول هو الذي يُنشئ هذه الحقوق ويمنحها للمُدَقِّقين، إلا أن ما نلاحظه في الممارسة العملية هو أن العديد من المُدَقِّقين يختارون عدم ممارسة هذا الحق بأنفسهم. بل يختارون منح الحق لشخص آخر لأدائه نيابة عنهم. وهذا "الشخص الآخر" نعرفه في إيثيريوم باسم الباني.

لذا ما نلاحظه هو أنه على الرغم من أن المُدَقِّقين يستمرون في أداء مهام الإجماع هذه بأنفسهم، إلا أنهم يقررون تمرير مهام التنفيذ إلى البناة. إنه في الواقع سوق كبير جداً. اليوم، يتم بناء حوالي 90% من الكتل بواسطة بناة خارجيين، وكان هذا هو الحال منذ حوالي ديسمبر 2022 — أي بعد ثلاثة أشهر من الدمج. يبلغ متوسط الدفع من الباني إلى المُدَقِّق حوالي $120 لكل كتلة. يتم دفع مليون دولار يومياً، وكل 12 ثانية هناك إمكانية لهذا السوق للتوصل إلى نوع من الاتفاق بين مُقترِح واحد وباني واحد.

اليوم أريد أن أناقش لماذا يستخدم المُدَقِّقون البناة، ومن أين تأتي هذه العلاقة — سأقدم نبذة عن القيمة القصوى القابلة للاستخراج (MEV) والباحثين على طول الطريق — ثم سأخبركم كيف يتم التوسط في هذه العلاقة، وسأتحدث عن المُرحِّلات الموجودة اليوم والحلول داخل البروتوكول التي نفكر فيها. أريد أيضاً أن ألقي نظرة على الصورة الكبيرة، لأنه من السهل رؤية هذه الصور والتفكير "أوه هذا مخيف جداً، ماذا عن اللامركزية؟" أريد أن أعطيكم انطباعاً بأن هذه مقايضات يتم إجراؤها، ولكن في رأيي يتم إجراؤها في الاتجاه الصحيح.

النموذج البسيط والقيمة القصوى القابلة للاستخراج (MEV) (3:04)

يمكنك التفكير في نموذج بسيط لإنتاج الكتلة حيث يتم اختيار المُدَقِّق وفقاً لعملية اختيار القائد، وعليهم إنشاء كتلة تحتوي على قائمة من المعاملات من مجمع الذاكرة. في النموذج الأكثر بساطة، لديك حقاً طرفان فقط — مُدَقِّق يستمع إلى مجمع الذاكرة، وعندما يحين دوره لإنشاء كتلة، فإنه يستخرج المعاملات التي تدفع أكبر قدر من الرسوم ويضيفها، وعادة ما يستخدم خوارزميات تعبئة غير معقدة للغاية.

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

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

هذا يعطي حقاً الكثير من القوة للمُنتِج ويجعل منصب مُنتِج الكتلة قيماً للغاية. امتياز المُنتِج هذا هو ما نطلق عليه الآن القيمة القصوى القابلة للاستخراج (MEV).

دور الباحثين (5:43)

في الممارسة العملية، قد لا يعرف المُنتِجون أين تكمن القيمة. يمكن أن يكون لديك مُنتِجو كتل غير متمرسين إلى حد ما — كما ذكرنا، يمكن لأي شخص أن يصبح مُدَقِّقاً طالما أن لديه رأس مال كافٍ وقادر على تشغيل عقدة. عملياً، قد لا أعرف كيفية القيام بالمراجحة أو أي شيء عن الأسواق المالية. ما أريده هو أن يخبرني شخص ما أين توجد هذه الفرص — سوق من الأشخاص يتنافسون لإخباري بأفضل ما يمكنني فعله بصفتي مُنتِج الكتلة.

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

يعمل هذا النموذج بشكل جيد في الممارسة العملية إذا كان الباحث يثق في المُنتِج للحفاظ على ذرية الحزمة. ربما سمعت مؤخراً عن هجوم على إيثيريوم كلف مجموعة من منفذي هجمات الساندويتش $25 million — كان السبب الجذري هو أن المهاجم تمكن من كسر ذرية الحزم، وتلقي المحتويات ومحاولة إعادة تنظيمها وتعديلها. هذه خاصية مهمة جداً لا تصمد حقاً إلا طالما يمكن الوثوق بالمُنتِج لعدم كسر هذه الذرية.

لماذا نحتاج إلى البناة (8:16)

ماذا تفعل إذا كان المُنتِج غير موثوق به؟ بعد الدمج في إيثيريوم، لدينا مُخزِّنون فرديون — حوالي 6% من الشبكة — لا نعرفهم. لن يرغب الباحثون حقاً في إرسال حزم إلى مُقترِحي الكتل هؤلاء لأن الأمر خطير بعض الشيء.

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

الآن لديك هذه السلسلة الأعمق: المُدَقِّق في أحد الطرفين، والمستخدم في الطرف الآخر، وفي الوسط هذه السلسلة الكاملة من الوسطاء التي تستمر في أن تصبح أكثر كثافة بمرور الوقت. يقوم الباني بجزء التنفيذ بينما يقوم المُدَقِّق بالإجماع.

كيف تعمل مُرحِّلات MEV-Boost (13:01)

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

ما نستخدمه اليوم كطرف ثالث موثوق به هو ما نطلق عليه المُرحِّل — مُرحِّل MEV-Boost. MEV-Boost هو اسم البروتوكول الذي يتوسط التفاعلات بين البناة والمُدَقِّقين. يجلس المُرحِّل في المنتصف لضمان التوصل إلى الاتفاق من كلا الجانبين.

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

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

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

الثقة والمُرحِّل (17:01)

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

لذا فهو يعتمد على الثقة، ولكن مع افتراض أنه يمكن استبداله بسرعة إلى حد ما. المُرحِّلات ليست مُدَقِّقين — ليس لديهم بالضرورة حصة التخزين ولا يجب أن يكون لهم أي علاقة بإيثيريوم. قد يكونون أشخاصاً نعرفهم ونحبهم اليوم، ولكن غداً يمكن أن يكونوا أي شخص.

تكريس فصل المقترح عن الباني (PBS) في البروتوكول (20:01)

نحن نحاول القضاء على وضع الطرف الثالث الموثوق به للمُرحِّل. لدينا طرف ثالث موثوق به نحبه في إيثيريوم — وهو إيثيريوم نفسه. يمكنك تصميم حلول داخل البروتوكول تحاول بشكل أساسي تكريس دور المُرحِّل وجعل الاعتماد عليه اختيارياً.

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

تقييد البناة، وتعزيز اللامركزية (22:05)

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

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

اليوم هناك بوضوح ثلاثة بناة مهيمنين: Beaver Build، وTitan، وrsync Builder. هل هذه حالة جيدة للأمور؟ ليس حقاً — يمكننا القيام بعمل أفضل. ولكن هل من الواقعي أن نتخيل أنه سيكون لدينا عدد من البناة يعادل عدد المُدَقِّقين؟ ربما لا.

ما نريده حقاً هو هذه الطبقة الرقيقة من المُدَقِّقين التي تقيد وتستفيد من حقيقة وجود أطراف عالية القدرة في المنتصف يمكنها أداء مهام لا تتطلب افتراضات الأغلبية الصادقة.

بعض الأفكار لتقييد البناة:

  • قوائم التضمين — حيث يخبر المُدَقِّق الباني "يجب عليك تضمين هذه المعاملات في كتلتك"
  • بناء الكتلة الجزئي — تقسيم الكتلة الكاملة بحيث لا يحتكر الباني كل المساحة
  • تقليل الاعتماد على الأطراف الثالثة — تكريس دور المُرحِّل في البروتوكول

لتعزيز لامركزية المُدَقِّقين:

  • فصل المُصادِق عن المُقترِح — بدلاً من جعل المُدَقِّق هو مُنتِج الكتلة افتراضياً، يتم اختيار مجموعة مختلفة من الأشخاص ليصبحوا مُنتِجي كتل وفصل الأدوار
  • آليات التخزين المحسنة — التخزين في إيثيريوم بدائي بعض الشيء اليوم ويمكن تحسينه

أسئلة وختام (27:03)

سؤال من الجمهور: في عالم التمويل التقليدي، يتم تقليل وقت التسوية من يومين إلى يوم واحد. هل سيؤدي تقليل وقت التسوية من 12 ثانية إلى فترة أقصر إلى التعامل مع بعض مشاكل الاستباق؟

يتحدث الناس عن هذا — يطلقون عليه التأكيدات المسبقة. الفكرة هي أنك ترسل معاملتك ويخبرك شخص ما "أنت في الداخل، بهذا السعر، على تلك الحالة." الأمر هو أنه لا يمكنك التسوية بشكل أسرع من تشغيل البروتوكول. لا يمكنك الحصول على تسوية نهائية أسرع من 12 دقيقة. لا يمكنك التحرك بشكل أسرع من وقت الكتلة.

يعد تقصير وقت الكتلة أمراً صعباً لأننا نريد الحفاظ على طبقة المُدَقِّق لامركزية قدر الإمكان، وتقصيره يؤدي فقط إلى زيادة متطلبات الأجهزة.

هل كانت هذه الصفحة مفيدة؟