⁦EIP-7805⁩: قوائم التضمين المفروضة باختيار التفرع (⁦FOCIL⁩)

الحلقة 141 من PEEPanEIP المقدمة من Ethereum Cat Herders. تستضيف بوجا رانجان كلاً من توماس تيري وجوليان ما، الباحثين في مجموعة الحوافز القوية في مؤسسة إيثيريوم والمؤلفين المشاركين لمقترح EIP-7805 (يفتح في علامة تبويب جديدة)، لشرح قوائم التضمين المفروضة باختيار التفرع (FOCIL): لماذا تحتاج إيثيريوم إلى مقاومة الرقابة على مستوى البروتوكول، وكيف تعمل الآلية، وما هي حالة التنفيذ الحالية.

هذا النص هو نسخة يسهل الوصول إليها من النص الأصلي للفيديو (يفتح في علامة تبويب جديدة) الذي نشرته Ethereum Cat Herders. تم تعديله بشكل طفيف لتسهيل القراءة.

مقدمة (0:35)

بوجا رانجان: مرحباً بكم في PEEPanEIP، البرنامج الأول والوحيد الذي نتعمق فيه في مقترحات تحسين إيثيريوم ونستكشف تأثيرها على النظام البيئي. هذه هي الحلقة 141، برعاية Ethereum Cat Herders. أنا مضيفتكم، بوجا رانجان، واليوم نتحدث عن EIP-7805، قوائم التضمين المفروضة باختيار التفرع.

تم توثيق EIP-7805 في نوفمبر 2024، وهو مقترح أساسي في مسار المعايير وهو حالياً في حالة المسودة. يهدف هذا المقترح إلى السماح للجنة من المدققين بفرض تضمين مجموعة من المعاملات في كل كتلة. شارك في تأليف المقترح كل من توماس تيري، وفرانشيسكو داماتو، وجوليان ما، وبارنابي مونو، وتيرينس تساو، وجاكوب كوفمان، وجيهون سونغ، ويخضع المقترح لنقاش نشط من أجل ترقية مستقبلية.

في هذه الحلقة، سنستكشف تفاصيل EIP-7805، وآثاره، وتأثيره المحتمل على النظام البيئي لإيثيريوم. للحديث أكثر عن المقترح، ينضم إلينا توماس تيري وجوليان ما. مرحباً بكم في PEEPanEIP.

توماس تيري: شكراً لاستضافتنا.

جوليان ما: نعم، شكراً جزيلاً لاستضافتنا.

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

مقدمات الضيوف (2:14)

جوليان ما: بالتأكيد، يمكنني البدء. أنا جوليان، باحث في مجموعة الحوافز القوية، تمامًا مثل توماس، في مؤسسة إيثيريوم. تهتم مجموعة الحوافز القوية باقتصاديات البروتوكول بشكل عام. كان بعضنا يبحث في آليات رسوم المعاملة، مثل EIP-1559، وكان آخرون يبحثون في هجمات طبقة الإجماع، ومعظمها مدفوع بحوافز اقتصادية.

بالنسبة لي، بدأت بفترة تدريب تبحث في مشتقات الرسم الأساسي، وبعد ذلك انضممت للعمل بدوام كامل. لقد كنت أعمل في الغالب على فصل المقترح عن الباني (PBS) والمواضيع المتعلقة بـ MEV، والآن أركز على قوائم التضمين عبر FOCIL مع هذا الـ EIP، وأتطلع إلى فصل المصدق عن المقترح. أود أن أقول إنني متحمس جدًا لنقل الأبحاث إلى مرحلة الإنتاج عبر هذا المسار الذي يبدأ بعمل نظري أكثر ويوجهه نحو EIP نأمل أن يتم اقتراحه وتنفيذه داخل إيثيريوم.

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

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

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

العرض التقديمي: أهداف FOCIL (5:16)

جوليان ما: ممتاز، شكرًا جزيلاً لكم. أود أن أبدأ بعرض تقديمي صغير حول كيفية عمل EIP-7805، أو FOCIL، ولماذا نريد القيام بذلك بالضبط. الهدف منه هو بدء المحادثة، لذا لن يكون متعمقًا جدًا، لترك بعض المجال للمناقشة بعد ذلك.

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

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

لماذا نحتاج إلى FOCIL، ولماذا الآن؟ (6:09)

جوليان ما: لماذا نحتاج إلى شيء كهذا؟ حاليًا، يقوم جميع المُدَقِّقين تقريبًا بالاستعانة بمصادر خارجية لبناء الكتل عبر MEV-Boost، وهو سوق خارج البروتوكول حيث يزايد البناة للحصول على حقوق بناء الكتل. في هذا السوق، لا يوجد سوى كيانين يهيمنان حقًا، وهذا يعني أن 90% من الكتل يتم بناؤها بواسطة كيانين فقط.

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

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

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

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

كيف يعمل FOCIL (8:10)

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

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

إذًا، من ينشئ هذه القائمة؟ هذه هي الخطوة الأولى لكيفية عمل بروتوكول FOCIL. في كل خانة، يتم اختيار 16 مُدَقِّقًا كأعضاء في لجنة قائمة التضمين. يراقب كل عضو من أعضاء هذه اللجنة مجمع الذاكرة وينشئ قائمة التضمين الخاصة به. يجب أن يكون حجم قائمة التضمين حوالي 8 كيلوبايت، أو حوالي 20 معاملة في المتوسط، مما يعني حوالي 320 معاملة في المتوسط إجمالاً.

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

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

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

IL Boost وعدم القابلية للازدحام (11:07)

جوليان ما: أحد المخاوف الكبيرة بشأن قوائم التضمين، والذي تم التعبير عنه في EIP السابق من مايك وأثناء التطوير بعد ذلك، هو "IL Boost"، أو عدم القابلية للازدحام. يشير هذا إلى حقيقة أن مُقترِحي قائمة التضمين قد يرغبون في بيع حقوقهم لبناء قائمة تضمين. إنه قلق منطقي للغاية، لأننا نرى هذا يحدث مع بناء الكتل: بيع هذا الحق يؤدي إلى سوق مركزية من البناة المتطورين.

نحن نجادل بأن FOCIL قوي ضد هذه الأسواق الشبيهة بـ MEV-Boost، أو IL Boost كما تُعرف بالعامية، بسبب الخصائص التالية. لا يضمن FOCIL أي ترتيب للمعاملات. بغض النظر عن المكان الذي تضع فيه معاملتك في قائمة التضمين الخاصة بك، سيتم ترتيبها بأي طريقة يراها منشئ الكتل مناسبة. إذا قمت، على سبيل المثال، بتضمين معاملة مراجحة في القائمة، فمن غير المرجح أن يضع الباني معاملة المراجحة الخاصة بك في أعلى الكتلة بحيث تنفذ المراجحة بالفعل. بدلاً من ذلك، من المحتمل أن يقوم الباني بذلك بنفسه.

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

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

وأخيرًا، يتم إنشاء قوائم التضمين هذه قبل 3 ثوانٍ من تصرف منتج الكتلة. هناك 3 ثوانٍ من المعلومات الإضافية، والتي عادة ما تكون ذات صلة وثيقة بأنواع معاملات MEV، والتي تصل بعد الالتزام بقائمة التضمين وقبل أن يتصرف منتج الكتلة، مما يعني أن هناك ميزة معلوماتية قليلة جدًا. في الواقع، هناك عيب معلوماتي لأولئك الذين يحاولون استخدام قوائم التضمين كوسيلة لـ MEV.

لهذه الأسباب، نعتقد أنه لا يوجد مُقترِح قائمة تضمين فردي لديه سلطة التضمين أو الترتيب أو الاستبعاد، وهو التعريف الأساسي لـ MEV. لذلك لا ينبغي أن تخضع قوائم التضمين لـ MEV.

ملخص العرض التقديمي (13:09)

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

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

بوجا رانجان: شكرًا جزيلاً لك على هذا العرض التقديمي السريع والنظرة العامة على المقترح.

أسئلة وأجوبة: كيف يختلف EIP-7805 عن EIP-7547؟ (14:17)

بوجا رانجان: أود أن أبدأ قسم الأسئلة والأجوبة بالسؤال الأول، حول المقترح السابق الذي تم ذكره أيضًا في عرضك التقديمي: المقترح 7547، قوائم التضمين، بواسطة مايك نيودر. أريد أن أفهم الفرق الأساسي بين ذلك المقترح و FOCIL الذي لدينا مع 7805. لقد تطرقت جزئيًا في عرضك التقديمي إلى IL Boost وعدم القابلية للازدحام. هل ترغب ربما في شرح المزيد عن ذلك؟

جوليان ما: ربما يكون توماس هو الأنسب للإجابة على كيفية اختلاف 7805 عن 7547، ولكن يمكنني أن أقول القليل عن ذلك. أولاً وقبل كل شيء، FOCIL مخصص لنفس الخانة، بينما كان 7547 مخصصًا للخانة التالية. خاصية نفس الخانة تجعل بعض الأمور أسهل، لأنها تعني أن قائمة التضمين لا يجب تخزينها على السلسلة.

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

توماس تيري: هناك فرق كبير أيضًا وهو عدد مُقترِحي قائمة التضمين لدينا. في المقترح السابق، كانت هناك آلية يقوم من خلالها مُقترِح الخانة n بإنشاء قائمة التضمين التي يحتاج مُقترِح الخانة n+1 إلى فرضها. الشيئان الكبيران هنا: أولاً، هناك تأخير بمقدار خانة واحدة، لذلك يجب تضمين المعاملات الموجودة في قائمة التضمين فقط في الخانة التالية بواسطة المُقترِح التالي. وهناك مُقترِح واحد فقط يقوم فعليًا بإنشاء قائمة التضمين. مع FOCIL لدينا 16. إنه يحدث فرقًا كبيرًا، لأننا الآن نحتاج فقط إلى أن يكون واحد من أصل 16 عضوًا في لجنة قائمة التضمين (IL) صادقًا حتى تعمل الآلية بأكملها كما هو مقصود. إنه يضاعف فرصك في الحصول فعليًا على آلية جيدة مقاومة للرقابة، بينما كنت تعتمد في السابق على طرف واحد.

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

بوجا رانجان: شكرًا جزيلاً لك. للأشخاص الذين يرغبون في معرفة المزيد عن المقترح 7547، لدينا حلقة مسجلة مع مايك نيودر، الحلقة 130 من PEEPanEIP، والتي تقدم نظرة عامة شاملة. أحب دائمًا رؤية المقترحات المتنافسة، لأنني أعلم أن ذلك من أجل تحسين النظام البيئي والسلسلة. أرى في الدردشة أن هناك بعض الأسئلة. ربما أود دعوة كاتايا لمشاركة سؤالها.

هل يجب على المُقترِح تضمين جميع القوائم الـ 16؟ (19:05)

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

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

بوجا رانجان: السؤال التالي في الدردشة من جاستن. جاستن، هل تود قراءة سؤالك للضيوف؟

معاملات مجمع الذاكرة الخاص في قوائم التضمين (19:55)

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

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

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

بوجا رانجان: شكرًا لك على المشاركة. أرى أن السؤال التالي من لاديسلاوس.

FOCIL والتوسع (21:41)

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

جوليان ما: شكراً على السؤال. أولاً وقبل كل شيء، حجة التوسع عبر FOCIL. حالياً، يقوم 90% من المُدَقِّقين بالاستعانة بمصادر خارجية لبناء الكتل عبر MEV-Boost، ومن الواضح أن هذه الكيانات المتطورة تمتلك نطاقاً ترددياً أكبر من الحد الأدنى لمتطلبات الأجهزة. يمكنهم، على سبيل المثال، تضمين المزيد من كتل البيانات في كتلهم دون أن يؤدي ذلك إلى أي مشاكل. ومع ذلك، فإن الأمر المثير للاهتمام هو أن إيثيريوم تعتمد على البناء المحلي للكتل من أجل الحياد الموثوق، أو مقاومة الرقابة، لأن هذين الكيانين المتطورين ليسا من الكيانات التي يمكن بناء مقاومة الرقابة في إيثيريوم عليها.

لذا يجب أن يظل بروتوكول إيثيريوم مصمماً بحيث يكون من الممكن القيام بالبناء المحلي للكتل، وفي الواقع نحن نصممه بحيث لا يكون غير مربح مقارنة بـ MEV-Boost. هذا موجود في تصميم إيثيريوم، ولكن من الناحية العملية، بالطبع، يعد MEV-Boost أكثر ربحية بكثير: أولاً لأن منشئي الكتل المتطورين هؤلاء لديهم خوارزميات أكثر تعقيداً، وثانياً لأن لديهم تدفق أوامر خاصاً أكبر بكثير. كان هناك بعض الأبحاث التي أجرتها Data Always مؤخراً والتي تظهر أن كتل MEV-Boost تحتوي على عدد أكبر بكثير من المعاملات. هذا وحده يؤدي إلى المزيد من الأرباح.

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

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

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

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

بوجا رانجان: شكراً جزيلاً لكم. أعتقد أن السؤال التالي من لويس.

معايير اختيار المعاملات (26:46)

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

توماس تيري: هذا سؤال رائع. وهو ذو شقين. الشق الأول مهم جدًا، ويتعلق بمحاولة فصل المُصادقين عن الأشخاص الذين يبنون أو يقترحون الكتلة. هذا هو مسار البحث الكامل حول فصل المُصادق عن المُقترِح (APS)؛ وقد عمل جوليان كثيرًا على هذا الأمر. نحن نطلق عليه اسم تفكيك الأدوار، بحيث تتطابق بشكل أوثق مع واجبات البروتوكول. لقد كتبت منشورًا، شاركته للتو، حول فصل محتمل، وهو مفتوح للنقاش إلى حد كبير، وأود الحصول على المزيد من الآراء من الناس. في هذا المنشور، أقوم بالفصل بين المُصادقين، والمُضمِّنين، وهم أعضاء لجنة قائمة التضمين (IL) الآن، ومُقترحي التنفيذ، أو البناة. أعتقد أن هذه واجبات مختلفة بشكل أساسي، وربما ينبغي أن يكون لدينا أدوار مختلفة لهم.

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

لويس بينتو: حسنًا، إذن أنتم تقومون أيضًا بتوزيع هذه المعايير، مما يسمح لمن يبنون قوائم التضمين بامتلاك معاييرهم الخاصة. أم أن هذا سيكون جزءًا من البروتوكول؟

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

لويس بينتو: حسنًا، شكرًا لك.

التوافق مع EIP-7702 وePBS وPeerDAS (30:43)

بوجا رانجان: شكرًا جزيلاً لك. على حد فهمي، تم اقتراح هذا المقترح بالفعل للترقية التي تلي بيكترا، وهي فوساكا. ونظرًا لأن فوساكا قد تتضمن أو لا تتضمن بعض مقترحات تحسين إيثيريوم (EIPs) الأخرى قيد التقدم، أتساءل عن حالة توافق FOCIL فيما يتعلق بمقترحات مثل 7702، الخاص بتجريد الحساب، وePBS، وPeerDAS.

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

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

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

FOCIL وMEV متعدد الخانات (33:04)

بوجا رانجان: كنت أراجع المستندات والتفاصيل المضافة إلى موقع FOCIL الإلكتروني، meetfocil.eth.limo، وتعرفت على مصطلح يسمى MEV متعدد الخانات. ذكر جوليان أيضًا أن MEV-Boost بشكل عام مربح، على الرغم من رغبة المطورين والجهود التي يبذلونها لإبقائه على قدم المساواة. أتساءل كيف سيمنع FOCIL ذلك.

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

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

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

السبب في أنه لا يحل جميع المشاكل هو الاختيار السلبي، وهي خاصية اقتصادية حيث يمتلك شخص معلومات أكثر من الآخر. أحد الأمثلة على MEV متعدد الخانات هو استخراج المراجحة عبر كتلتين، حيث لا يقوم منشئ الكتل باستخراج المراجحة في الكتلة الأولى ويفعل ذلك في الكتلة الثانية. هناك بعض النتائج النظرية التي تظهر أن هذا يمكن أن يكون أكثر ربحية لمنشئ الكتل من استخراج المراجحة في كلتا الخانتين. قد تعتقد أن FOCIL يساعد هنا، لأن المتداولين بالمراجحة يمكنهم من حيث المبدأ تضمين معاملتهم في قائمة التضمين وبالتالي فرض حدوث نوع من المراجحة. على الرغم من أن هذا هو الحال، إلا أنه لا يتوافق مع الحوافز للمتداولين بالمراجحة لتقديم معاملتهم إلى FOCIL، لأنه لا يزال هناك 3 ثوانٍ بين تقديم معاملتهم وقدرة منشئ الكتل على التصرف. إذا كنت تحاول القيام بالمراجحة وكان السعر يتحرك باستمرار في بعض الأسواق الخارجية، فلن ترغب في الالتزام مسبقًا بـ 3 ثوانٍ، لأن لديك معلومات أقل بكثير من منشئ الكتل، الذي يتصرف بعدك. يلعب الاختيار السلبي دورًا لأن الباني لديه معلومات أكثر: سيسمح لك بالفوز إذا كان ذلك سيئًا بالنسبة لك، وإذا تحرك السعر في السوق الخارجي ضدك في تلك الثواني الثلاث الإضافية، وسيسمح لنفسه بالفوز إذا كان من الأفضل له أن يفوز.

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

بوجا رانجان: حسنًا جدًا، شكرًا جزيلاً لك على مشاركة ذلك. أفهم أن هناك الكثير من الأبحاث الجارية لمعالجة مسألة MEV، لذلك من الجيد معرفة أنه على الأقل من حيث المبدأ سيساعد أكثر من السيناريو الحالي.

المقايضات والتحديات (36:44)

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

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

بالنسبة للمقايضات: إذا أخذت نظرة ضيقة جدًا، فمن الصحيح أن FOCIL يضيف بعض المهام إلى المُدَقِّقين، سواء عندما يتعين عليهم اقتراح قائمة تضمين، أو بالنسبة للمصادقين، عندما يتعين عليهم التحقق من شرط إضافي واحد للتأكد من أن الكتلة صالحة وفقًا لقوائم التضمين. كما أنه يضيف مهمة صغيرة لـ المُقترِح، لأنه يحتاج الآن إلى التأكد من أن حمولته تتضمن بالفعل المعاملات الموجودة في ILs. بالنسبة لي، هذه هي المقايضة الوحيدة، وهذه المهام ليست ثقيلة أو معقدة. يقوم عضو لجنة IL ببساطة بمراقبة مجمع الذاكرة العام وتضمين المعاملات في قائمة يرسلونها. لا يتطلب الأمر أي نوع من المهارة أو التعقيد، وهو أمر رائع في رأيي. من ناحية أخرى، كما قلنا، قد يفتح الباب أمام بعض التحسينات الكبيرة في التوسع وفصل أفضل بين المشاركين والواجبات داخل البروتوكول.

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

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

آليات رسوم المعاملة لقوائم التضمين (39:50)

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

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

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

أحد الآراء التي كونتها مؤخرًا هو: ماذا لو أضفنا بعض الميزات الرائعة إلى FOCIL، مثل الخصوصية، بحيث لا يمكنك حقًا معرفة من اقترح قائمة معينة من المعاملات؟ أنت تعلم أنه كان شخصًا تم اختياره بالفعل كعضو في لجنة IL، لكنك لا تعرف بالضبط من اقترح أي قائمة، لذلك لا يمكنك ربط أعضاء لجنة IL بمجموعة المعاملات في قوائم التضمين (ILs) الخاصة بهم. إذا تمكنا من الحصول على ذلك، وجعلنا دور لجنة IL اختياريًا نوعًا ما، فمن المحتمل أن يكون لدينا مشاركون صادقون في البروتوكول، يعتمدون على السلوك الإيثري، وربما لن نحتاج إلى إعداد آلية رسوم على الإطلاق. هذا رأي حديث جدًا ومبني على وجهة نظر شخصية، ويتم استكشافه بشكل كبير في الوقت الحالي. كل هذه مناقشات حول "مستقبل FOCIL"؛ ولا يُفترض تضمينها في مقترح EIP الحالي.

جوليان ما: للإضافة إلى ذلك فقط، هذا الجزء الأخير مهم جدًا أيضًا: لا يتضمن EIP-7805 أي آلية لرسوم المعاملة، لجعله أسهل في التنفيذ. إنها في الأساس أصغر طريقة ممكنة يمكننا من خلالها توفير خصائص مقاومة الرقابة، لكنها قابلة للتوسيع بشكل كبير. نحن نبحث في ذلك. لقد قام توماس بالكثير من العمل في البحث في رسوم المعاملة المنفصلة للمُضمِّنين والمُقترِحين. ثم، كما ذكر توماس، لدينا منحة جارية مع باحث رائع في نيذرميند يبحث في إنشاء آلية رسوم المعاملة لـ FOCIL، وهذا واعد جدًا. وأخيرًا، كان هناك عمل على آلية رسوم المعاملة لمتغير من FOCIL يسمى AUCIL، وهو تصميم قائمة تضمين قائم على المزاد اقترحه ساريشت وادوا، وفان تشانغ، وكارتيك ناياك جنبًا إلى جنب مع العديد من مؤلفي FOCIL، والذي يبحث في طرق لتحفيز أعضاء لجنة قائمة التضمين.

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

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

حجم قائمة التضمين (44:16)

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

توماس تيري: لدينا حجم ثابت الآن في المواصفات، وهو موجود منذ فترة: 8 كيلوبايت. لقد وضعناه بالكيلوبايت لأن ما تستهلكه FOCIL و ILs حقًا هو النطاق الترددي، وهذا كل شيء تقريبًا. إذا أخذت متوسط حجم المعاملة، فسنصل إلى حوالي 40 معاملة لكل IL، وإذا كانت جميع المعاملات فريدة، فهذا يعني حوالي 640 معاملة يمكن دمجها معًا عبر جميع أعضاء اللجنة البالغ عددهم 16.

لا أعرف ما إذا كان هناك الكثير من الأبحاث التي يتعين القيام بها حول الحجم الأمثل الدقيق. ما اخترناه هو: 16 مضروبًا في 8 كيلوبايت وهو في الأساس حجم كتلة بيانات (بلوب)، لذا فهو ليس مقدارًا هائلاً من النطاق الترددي مجتمعًا. وبما أن مجموعة المعاملات عبر ILs أكبر من كتلة، فلا أعتقد أننا سنواجه مشكلات هناك.

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

مقاييس لتتبع الاعتماد (46:39)

بوجا رانجان: مجرد متابعة هنا: هل لديك أي مقاييس في الاعتبار يمكننا تتبعها لفهم مدى اعتماد أو نجاح هذا المقترح؟

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

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

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

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

حالة تنفيذ العميل (49:11)

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

توماس تيري: نحن نبلي بلاءً حسناً. أولاً وقبل كل شيء، كان من الرائع جداً رؤية كيف تولى الأشخاص جزء التنفيذ الخاص بـ FOCIL، لأنني لست مطوراً، بل أنا باحث. لقد كنت أعمل مع المطورين منذ البداية، لكنني لست من ينفذ الأشياء في العملاء.

أما من قادوا هذه الجهود، وهم ثلاثة: لدينا تيرينس من برايزم (Prysm)، وجيهون، الذي كان يساعد تيرينس كثيراً في برايزم (Prysm) ولكنه عمل أيضاً على جو إيثريوم (Geth). لذا لدينا الآن شبكة تطوير تعمل لكل من برايزم (Prysm) وجو إيثريوم (Geth)، وهو أمر رائع، وهناك الكثير من الاختبارات الجارية. نحاول الآن أيضاً جعل FOCIL معروضاً ومرئياً على مستكشف Dora. ثم لديك جاكوب، الذي عمل على لايتهاوس (Lighthouse) وريث (Reth)، وأعلم أن بعض الجهود لا تزال مستمرة هناك. كان لودستار (Lodestar) نشطاً جداً مؤخراً؛ أعتقد أنهم قريبون جداً من تشغيل شبكة تطوير. تلقينا بعض الأخبار من نيذرميند (Nethermind) اليوم بأن لديهم نموذجاً أولياً، وهو أمر رائع جداً. أشعر وكأنني أنسى بعضهم... نيمبوس (Nimbus) ينضم أيضاً، كما يقول جيهون. هذا رائع حقاً.

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

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

FOCIL في فوساكا أم غلامستردام؟ (52:07)

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

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

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

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

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

أسئلة سريعة (55:18)

بوجا رانجان: قبل أن نختتم، لدينا جولة أسئلة سريعة. الشرط الوحيد هو أن تكون الإجابة كلمة واحدة أو جملة واحدة، وسنحاول القيام بذلك باستخدام مؤقت، ربما 30 ثانية لكل سؤال. إذا كنتم مستعدين، فلنبدأ مع جوليان. ما هي أصعب مشكلة في أبحاث سلسلة الكتل في الوقت الحالي؟

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

بوجا رانجان: ما هي حالة استخدام واحدة لتقنية سلسلة الكتل لم يتم استكشافها بشكل كافٍ؟

جوليان ما: أود أن أقول FOCIL.

بوجا رانجان: ما هو أكبر خطر أمني يواجه إيثيريوم اليوم؟

جوليان ما: بصراحة، أود أن أقول إن مقاومة الرقابة أمر بالغ الأهمية هنا، بسبب أشياء مثل MEV متعدد الكتل الذي يمكن أن يشكل مخاطر أمنية ضخمة، على سبيل المثال لشبكات طبقات 2 (L2s).

بوجا رانجان: هل ينبغي تقليل MEV، أم تبنيه، أم شيء بينهما؟

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

بوجا رانجان: هل اللامركزية تستحق دائمًا التنازلات؟

جوليان ما: إنها تستحق التنازلات في العادة.

بوجا رانجان: ما هو أكبر ابتكار قدمته إيثيريوم للعالم؟

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

بوجا رانجان: شكرًا جزيلاً لك، إجابة رائعة. مجموعتي التالية من الأسئلة موجهة إلى توماس. إذن، إذا لم تكن إيثيريوم موجودة، فما هي سلسلة الكتل التي كنت ستعمل عليها؟

توماس تيري: أعتقد أنني سأكون مازحًا جدًا، وقد سبقني جوليان قليلاً لأنني اعتقدت أنه سيفعل الشيء نفسه. سلسلة الكتل ستكون FOCIL.

بوجا رانجان: ما هي حالة الاستخدام المبالغ فيها لتقنية سلسلة الكتل؟

توماس تيري: لا توجد حالة استخدام تستحق المبالغة بدون FOCIL.

بوجا رانجان: ما هو الشيء الوحيد الذي تحتاج إيثيريوم إلى تحسينه في أسرع وقت ممكن؟

توماس تيري: مقاومة الرقابة، باستخدام FOCIL.

بوجا رانجان: كلمة واحدة لوصف اللامركزية؟

توماس تيري: FOCIL.

بوجا رانجان: هل تعتقد أن إيثيريوم ستحل مشكلة قابلية التوسع بالكامل؟

توماس تيري: إيثيريوم مع FOCIL، نعم.

بوجا رانجان: توسيع طبقة 1 (L1) أم توسيع طبقة 2 (L2)، أيهما يفوز؟

توماس تيري: طبقات لا نهائية، جميعها باستخدام FOCIL.

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

رسائل إلى المجتمع (58:08)

توماس تيري: في الواقع، هذه نقطة مهمة للغاية، لأن لدينا نقاشات نشطة طوال الوقت، وكلها عامة على ديسكورد. كان هناك توجه في البداية لجعل كل شيء عامًا، والناس يفعلون ذلك بالفعل، لذا أنا سعيد جدًا. يمكنك متابعة النقاشات والتقدم على ديسكورد Eth R&D العام، في قناة inclusion-list. هذا هو المكان الذي يحدث فيه كل شيء تقريبًا في الوقت الحالي. ثم يمكنك التواصل معنا على تويتر، أو تيليغرام، أو في أي مكان. لا تتردد.

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

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

الكلمات الختامية (59:52)

بوجا رانجان: شكراً لكم. هكذا نختتم حلقتنا. شكر كبير لتوماس وجوليان لانضمامهما إلينا اليوم ومشاركة رؤاهما حول EIP-7805. شكراً لجميع المشاركين؛ أسئلتكم مشجعة وغنية بالمعلومات. شكراً على متابعتكم. إذا استمتعتم بهذه المحادثة، فتأكدوا من الإعجاب والاشتراك ومشاركة هذه الحلقة مع زملائكم من المتحمسين لشبكة إيثيريوم. سنقدم لكم المزيد من EIPs وتطورات الأبحاث في PEEPanEIP. حتى نلتقي في المرة القادمة، استمروا في التزود بالمعرفة واستكشاف إيثيريوم مع Ethereum Cat Herders. أتمنى لكم بقية يوم رائعة.