MEV-Boost، بروتوكول السيارة الجانبية الحالي لاستخراج MEV في Ethereum، يعتمد بشكل كبير على الجهات المركزية المسماة مناوبات.
نقترح بنية بديلة تسمح بالاتصال المباشر والخاص بشكل تشفيري بين المنشئين والمقترحين. يعتمد ذلك على شكل جديد وغير تفاعلي من التشفير بالحد الأدنى "الصامت" الذي يمكن استخدام أزواج مفاتيح BLS الحالية للمدققين.
أساسًا ، نستخدم منصة مناوبة الشهادة للخصوصية وتوافر البيانات عن طريق تشفير اقتراحات الكتل بحيث تصل إلى جزء من المناوبين للفتحة. تُشكل شهاداتهم مفتاح فك التشفير. بمجرد تحقيق عتبة الرغبة ، يمكن فك تشفير الكتلة.
يعالج البناء الخاص بنا الخصوصية بين البناة ومقدمي العروض ولكنه لا يضمن وحده صلاحية الكتلة. يمكن دمجه مع آليات أخرى لتكرار الوظائف التي توفرها المرحلات بشكل كامل - كل من الخصوصية وصلاحية الكتلة. على سبيل المثال ، مخططات الإثبات مثل براهين بيئة التنفيذ الموثوقة (TEE) أو براهين المعرفة الصفرية (ZK) ، أو آليات الاقتصاد المشفر لضمان البناة.
عن طريق إزالة الحاجة إلى المناوبات لتوفير خصوصية المباني وضمان صحة الكتلة ، نهدف إلى تقليل التأخير وتحسين اللامركزية ومقاومة الرقابة في إثيريوم.
MEV-Boost هو بروتوكول جانبي يتوسط بين بناة الكتل والمقترحين. الدور الرئيسيلم يتم تحديد مصطلح الترجمة
الاعتماد على المناوبات، ومع ذلك، يُدخِل تمركزًا مركزيًا كبيرًا. تُسلَم ما يقرب من 90% من الكتل على إيثيريوم من خلال مجرد عدد قليل من المناوبات. وهذا يشكل بعض المخاطر:
أحد المقترحات الرائدة لاستبدال المرحلات هو "TEE-Boostالذي يعتمد على TEEs (Trusted Execution Environments). لاحظ أن TEEs ليست ضرورية لمخططنا؛ إنها مجرد مساعدة في استخدام TEE-Boost كمثال تعليمي على المشاكل التي نهدف إلى حلها.
بشكل ملموس، يجعل TEE-Boost البناة استخدام TEEs لإنشاء دلائل تثبت للمقترحين نزاهة عروضهم وصحة كتلهم دون الكشف عن محتويات الكتل الفعلية للمقترحين. يمكن للمقترحين التحقق من هذه الدلائل دون تشغيل TEEs بأنفسهم على أجهزة الأجهزة الطبيعية.
ومع ذلك، يواجه TEE-Boost مشكلة في توفر البيانات: حيث يقوم المُنشئون بمشاركة الإثباتات TEE ورؤوس الكتل مع المُقترحين فقط، وليس محتويات الكتل الفعلية.[1]وقد يختار عدم الإفصاح عن محتويات الكتلة حتى بعد توقيع المقترح على العنوان (على سبيل المثال، إذا تغيرت ظروف السوق بشكل غير مواتية). النهج المقترح لحل هذه المشكلة DA هو:
كلتا النهجين لهما عيوب. تقوم حلاقة TEE-escrow بتكرار ديناميكيات التأخير المركزية المشابهة لتلك المتعلقة بالمناوبات الحالية.[2]استخدام طبقة DA الخارجية يُدخِل افتراضًا خارج البروتوكول و يتحمل ديناميات التأخير لذلك البروتوكول الخارجي (والتي من المرجح أن تكون غير مواتية أيضًا).
نظريًا، إذا كان لدى المقترحين أيضًا الوصول إلى TEEs، يمكن للمُنشئين تشفير كتلهم إلى TEE يتم تشغيله بواسطة المقترح. سيقوم TEE للمقترح بإلغاء تشفير الكتلة فقط بعد توقيعها. ومع ذلك، نحن نعتقد أن TEE-Boost لا ينظر إلى هذا التصميم لأنه سيتطلب من المقترحين (الموثقين) تشغيل TEEs. نريد أن يكون بإمكان الموثقين تشغيلهم على عتاد قابل للتداول.↩
يمكن تجنب ديناميكية التأخير إذا قام المقترحون بتشغيل TEE-Escrow بأنفسهم كجزء جانبي متزامن مع عقدة المصادقة الخاصة بهم. ومع ذلك، مرة أخرى، لا نريد جعل المصادقين يشغلون TEEs.↩
نقترح حلاً أنيقًا لمشكلة DA في TEE-Boost: التشفير العتبي للجنة الشهود. على وجه الخصوص، يقوم مشفر الحد بتشفير الكتلة لجزء محدد من لجنة الشهود لتلك الفتحة. بمجرد جمع عدد كافٍ من الشهادات، تصبح الكتلة قابلة للفك والتحميل.
تكنولوجيا التمكين الأساسية هيتشفير عتبة الصمت. تسمح تقنية التشفير هذه بتشفير العتبة دون الحاجة إلى مرحلة إعداد تفاعلية لإنشاء المفاتيح الموزعة (DKG) ، والتي تتطلبها الإنشاءات السابقة. بدلا من ذلك ، يتم حساب المفتاح العام المشترك بشكل حتمي من مفاتيح BLS العامة الموجودة بالفعل بالإضافة إلى بعض "التلميحات" (تمت مناقشتها لاحقا).
يتحقق هذا من التواصل المباشر لمرة واحدة بين الباني والموثق مع الخصوصية التشفيرية. لا يُطلب من الموثقين تشغيل TEEs أنفسهم أو إدارة أي مواد مفتاحية جديدة.
الميكانيكا:
يقوم المُنشئ ببناء كتلة ويُشفرها لجنة الشهود.
يقوم المُبني بإنشاء دليل TEE يُظهر ثلاثة أشياء للجنة المعترف بها: أن العرض صادق، وأن الكتلة صالحة، وأنها مشفرة بشكل صحيح.
يتواصل البناء مع كتلة التشفير الحدية وبرهان TEE (الذي يتضمن قيمة العرض) إلى المقترح.[3]
يوقع المقترح على كتلة المشيد الفائز المشفرة ويتسرب هذا المقترح إلى مجموعة المحققين.
بمجرد أن تقوم لجنة المصادقين n-attester المحددة (على سبيل المثال ، n/2 أو 2n/3) بمصادقة الفتحة على الكتلة ، يتم فك تشفيرها.
يتابع الكتلة المفككة الى الاستكمال بشكل طبيعي.
تتميز خصائص الأداء لتشفير الحد الصامت بشكل جيد.
n هو الحد الأقصى لحجم اللجنة التي نرغب في دعمها و t هو الحد الأدنى لفك التشفير.
كل من التشفير وفك التشفير الجزئي هما من الوقت الثابت. مع تنفيذ ساذج ، يستغرق التشفير أقل من 7 مللي ثانية - ويمكن توازيها. يستغرق فك التشفير الجزئي أقل من 1 مللي ثانية.
حجم النص المشفر عامل إضافي ثابت بحجم 768 بايت ، أكبر من النص الأصلي (بغض النظر عن قيم n و t)
تعتمد تجميع فك التشفير الجزئي على حجم اللجنة. مع n=1024، يستغرق التنفيذ الساذج أقل من 200 مللي ثانية. نتوقع أن ينخفض ذلك بمقدار 10 مع n=128 (حجم لجنة التصديق لكل فتحة)، ويمكن تحسين التنفيذ بشكل إضافي.
من الأهمية بشكل كبير أن يكون وقت التشفير هو الرقم الأساسي للأداء الذي يتم مقارنته بتأخر المناوبة. هذا ما يجب على البناء حسابه في "المسار الحرج" لإنتاج الكتلة. إنه أقل من تأخر معالجة الكتلة في المناوبة الحالية ويتجنب التواصل متعدد القفزات.
تشفير عتبة الصمت ليس مجانيًا تمامًا. فهو يتطلب سلسلة مرجعية مشتركة من النوع: (g، gτ,gτ2,…,gτn−t), مماثل لما يستخدم في نظام التزام الجدول الدالة الكثيرية KZG.
بالإضافة إلى ذلك، يقوم كل محقق بمفتاح عام BLS من النوع gsk بنشر مجموعة من العناصر الجماعية التي نسميها "تلميحات": (جsk⋅τ,…,gsk⋅τn−t). هذه التلميحات مطلوبة فقط لتجميع المفاتيح العامة وفك تشفير النصوص المشفرة. يستخدم التشفير فقط مفتاحًا عامًا مجمعًا بحجم ثابت.
حتى كتابة هذا المنشور، هناك حوالي 1 مليون منقب. إذا قمنا بتعيين n=128 و t=n/2، فإن كل منقب يحتاج إلى نشر حوالي 3 كيلوبايت من التلميحات. وبالتالي، يتطلب تخزين تلميحات جميع المنقبين 3 جيجابايت.
سيقل هذا المتطلب على الأرجح بشكل كبير مع تفعيل MaxEB، والتي تسمح للمدققين الذين يتحكمون في أكثر من 32 ETH بحمل أرصدة أكبر تحت نفس مفتاح الزوج (بدلاً من تجزيءها على عدة إيداعات 32 ETH). يتم مناقشة الحد من مجموعة المدققين التي سيتم تحقيقها. يبدو أنه من الممكن أن نصل إلى حوالي 1 جيجابايت.
أخيرًا، واعتمادًا على التغييرات المستقبلية في بنية consensu Ethereum (على سبيل المثال، تقليلات إضافية في حجم مجموعة المدققين، أو أنابيب النهاية البديلة) فإن حجم التلميحات التي يجب تخزينها قد يقل بشكل أكبر.
يرغب إيثريوم في البقاء على قيد الحياة حتى في ظل ظروف الشبكة السلبية. إحدى المشكلات في هذا النظام هي احتمالية وجود كتل لا يمكن فك تشفيرها لأن الكسر المحدد من اللجنة غير متصل بالإنترنت.
إحدى الحلول هي السماح للبنّاء بتحديد الكسر المقبول (𝑡) من المجلس للفك شفرته. هناك توازن بين الخصوصية (إمكانية فك تجزئة وسرقة MEV) واحتمالية استمرار عتبة المجلس على الإنترنت. إنه من المربح للبنّاءين الحصول على تضمين كتلهم بدلاً من الشوكات، لذلك يجب أن يحددوا إعدادًا محسّنًا للعتبة.[4]
بالإضافة إلى ذلك، يجب أن يكون استخدام هذه النظام التشفير اختياريًا. في ظروف الشبكة السيئة، حيث لا يتوفر لجنة بحجم ملائم بشكل دائم، يمكن للمقترحين والبنائين اللجوء إلى استخدام مناوبات أو بناء الذاتي أو أي آلية أخرى تفضلها بناءً على طبيعة البيئة السيئة.
وبشكل بديل، قد تكون اللجنة عبر الإنترنت، ولكن قد يتمكن الباني من خلق حالة يتعذر فيها فك تشفير الكتلة أو تكون غير صالحة عند فك التشفير (على سبيل المثال، باستخدام دلائل مزيفة).
من وجهة نظر البروتوكول ، فمن المقبول أن يفصل هذه الكتل. ببساطة ، فإن مجموعة المحقق الأوسع لا يمكنها التصديق عليها أو على أي كتلة تشير إليها. أفضل طريقة للتعامل مع هذا النوع من الأخطاء هي جعل عميل التوافق على علم بالاحتمالية وقادرًا على الفشل بشكل لائق. يتطلب ذلك دراسة مستفيضة حول كيفية التعامل مع المسألة تحديدًا.
يعرف المنشئ الفائز محتويات الكتلة قبل الآخرين حتى يتم الوصول إلى الحد الأدنى ، مما قد يخلق ميزة غير عادلة في الفتحات اللاحقة. ومع ذلك ، من المفترض أن تعمل لجنة التصديق قبل نهاية الفتحة التالية ، وتكون غالبية قيمة الكتلة في نهاية الفتحة ، لذلك يجب أن تكون تأثيرات هذه الميزة ضئيلة قدر الإمكان.
في المدى الطويل، قد يكون من الممكن استبدال دلائل TEE بدلائل الأمان الصفري (ZK). حالياً، تعتبر دلائل ZK بطيئة للغاية، ولكن التطورات في علم التشفير والبرمجيات والأجهزة المتخصصة (ASICs) قد تجعل توليد دليل ZK ممكناً في نهاية المطاف ضمن القيود اللازمة للتأخير. يجدر بالذكر أن دلائل ZK المصاحبة للكتل موجودة بالفعلالجزء الأساسي من خارطة طريق إثريوم على المدى الطويل.
مع حجم مجموعة المحقق الحالي ومعدل النمو الحالي، قد لا يكون هذا النظام يستحق الكمية من البيانات المطلوبة للنشر على L1. ومع ذلك، يخطط Ethereum بالفعل لتقليل عدد مجموعة المحقق بشكل كبير مع MaxEB.
من المحتمل أن يكون النهج الأفضل ترقية إلى جانب أو بعد MaxEB حيث يتم إعلام عملاء الاتفاقية بإمكانية دلالات الكتل المشفرة ويتم تشجيع المحققين على نشر التلميحات. على سبيل المثال ، بعد MaxEB ، يمكن أن يتطلب من المحققين الجدد نشر التلميحات ، ويمكن إعطاء المحققين الأقدم حافزًا للترقية.
سيبدأ المُنشئون في استخدام الآلية بمجرد أن يتبنى نسبة كافية من مجموعة المُعتمدين لديهم أحجام لجان كافية (أي خصوصية مقبولة واحتمال فك التشفير).
إذا كان لدينا نهج يتمتع فعلاً بتأخير ملائم مقارنة بالتوجيه متعدد القفزات، يجب أن يعتمده السوق بدون الحاجة لفرض استخدام البروتوكول أو توثيق تحديد معلمة معينة.
المناوبات هي واحدة من أهم مصادر تمركز إثيريوم، مما يخلق فرصًا للاستئجار ويشوه تمركز البروتوكول جغرافيًا.
نحن بحاجة إلى إزالة المناوبات ونعتقد أن هذه هي الطريقة الأنيقة نسبيا للقيام بذلك. يتطلب تغييرات في طبقة الاتفاق، ولكن لا يتطلب استخدام مواد جديدة أو مواد رئيسية من جانب المحققين.
السلبية هي أنها تعدل معقدة لطبقة التوافق من أجل آلية قد تتم اعتمادها أو لا من قبل السوق (كما يقترح). ومع ذلك، تطرح العديد من التغييرات المحتملة على خط أنابيب MEV أسئلة مماثلة بالنسبة للتبني وتحسين الإيرادات (على سبيل المثال، قوائم الاحتواء). وقد تكون هناك حالات استخدام مستقبلية أخرى تعتمد على مجموعة المدقق التي تحتوي على بنية تحتية لتشفير العتبة المتاحة.
MEV-Boost، بروتوكول السيارة الجانبية الحالي لاستخراج MEV في Ethereum، يعتمد بشكل كبير على الجهات المركزية المسماة مناوبات.
نقترح بنية بديلة تسمح بالاتصال المباشر والخاص بشكل تشفيري بين المنشئين والمقترحين. يعتمد ذلك على شكل جديد وغير تفاعلي من التشفير بالحد الأدنى "الصامت" الذي يمكن استخدام أزواج مفاتيح BLS الحالية للمدققين.
أساسًا ، نستخدم منصة مناوبة الشهادة للخصوصية وتوافر البيانات عن طريق تشفير اقتراحات الكتل بحيث تصل إلى جزء من المناوبين للفتحة. تُشكل شهاداتهم مفتاح فك التشفير. بمجرد تحقيق عتبة الرغبة ، يمكن فك تشفير الكتلة.
يعالج البناء الخاص بنا الخصوصية بين البناة ومقدمي العروض ولكنه لا يضمن وحده صلاحية الكتلة. يمكن دمجه مع آليات أخرى لتكرار الوظائف التي توفرها المرحلات بشكل كامل - كل من الخصوصية وصلاحية الكتلة. على سبيل المثال ، مخططات الإثبات مثل براهين بيئة التنفيذ الموثوقة (TEE) أو براهين المعرفة الصفرية (ZK) ، أو آليات الاقتصاد المشفر لضمان البناة.
عن طريق إزالة الحاجة إلى المناوبات لتوفير خصوصية المباني وضمان صحة الكتلة ، نهدف إلى تقليل التأخير وتحسين اللامركزية ومقاومة الرقابة في إثيريوم.
MEV-Boost هو بروتوكول جانبي يتوسط بين بناة الكتل والمقترحين. الدور الرئيسيلم يتم تحديد مصطلح الترجمة
الاعتماد على المناوبات، ومع ذلك، يُدخِل تمركزًا مركزيًا كبيرًا. تُسلَم ما يقرب من 90% من الكتل على إيثيريوم من خلال مجرد عدد قليل من المناوبات. وهذا يشكل بعض المخاطر:
أحد المقترحات الرائدة لاستبدال المرحلات هو "TEE-Boostالذي يعتمد على TEEs (Trusted Execution Environments). لاحظ أن TEEs ليست ضرورية لمخططنا؛ إنها مجرد مساعدة في استخدام TEE-Boost كمثال تعليمي على المشاكل التي نهدف إلى حلها.
بشكل ملموس، يجعل TEE-Boost البناة استخدام TEEs لإنشاء دلائل تثبت للمقترحين نزاهة عروضهم وصحة كتلهم دون الكشف عن محتويات الكتل الفعلية للمقترحين. يمكن للمقترحين التحقق من هذه الدلائل دون تشغيل TEEs بأنفسهم على أجهزة الأجهزة الطبيعية.
ومع ذلك، يواجه TEE-Boost مشكلة في توفر البيانات: حيث يقوم المُنشئون بمشاركة الإثباتات TEE ورؤوس الكتل مع المُقترحين فقط، وليس محتويات الكتل الفعلية.[1]وقد يختار عدم الإفصاح عن محتويات الكتلة حتى بعد توقيع المقترح على العنوان (على سبيل المثال، إذا تغيرت ظروف السوق بشكل غير مواتية). النهج المقترح لحل هذه المشكلة DA هو:
كلتا النهجين لهما عيوب. تقوم حلاقة TEE-escrow بتكرار ديناميكيات التأخير المركزية المشابهة لتلك المتعلقة بالمناوبات الحالية.[2]استخدام طبقة DA الخارجية يُدخِل افتراضًا خارج البروتوكول و يتحمل ديناميات التأخير لذلك البروتوكول الخارجي (والتي من المرجح أن تكون غير مواتية أيضًا).
نظريًا، إذا كان لدى المقترحين أيضًا الوصول إلى TEEs، يمكن للمُنشئين تشفير كتلهم إلى TEE يتم تشغيله بواسطة المقترح. سيقوم TEE للمقترح بإلغاء تشفير الكتلة فقط بعد توقيعها. ومع ذلك، نحن نعتقد أن TEE-Boost لا ينظر إلى هذا التصميم لأنه سيتطلب من المقترحين (الموثقين) تشغيل TEEs. نريد أن يكون بإمكان الموثقين تشغيلهم على عتاد قابل للتداول.↩
يمكن تجنب ديناميكية التأخير إذا قام المقترحون بتشغيل TEE-Escrow بأنفسهم كجزء جانبي متزامن مع عقدة المصادقة الخاصة بهم. ومع ذلك، مرة أخرى، لا نريد جعل المصادقين يشغلون TEEs.↩
نقترح حلاً أنيقًا لمشكلة DA في TEE-Boost: التشفير العتبي للجنة الشهود. على وجه الخصوص، يقوم مشفر الحد بتشفير الكتلة لجزء محدد من لجنة الشهود لتلك الفتحة. بمجرد جمع عدد كافٍ من الشهادات، تصبح الكتلة قابلة للفك والتحميل.
تكنولوجيا التمكين الأساسية هيتشفير عتبة الصمت. تسمح تقنية التشفير هذه بتشفير العتبة دون الحاجة إلى مرحلة إعداد تفاعلية لإنشاء المفاتيح الموزعة (DKG) ، والتي تتطلبها الإنشاءات السابقة. بدلا من ذلك ، يتم حساب المفتاح العام المشترك بشكل حتمي من مفاتيح BLS العامة الموجودة بالفعل بالإضافة إلى بعض "التلميحات" (تمت مناقشتها لاحقا).
يتحقق هذا من التواصل المباشر لمرة واحدة بين الباني والموثق مع الخصوصية التشفيرية. لا يُطلب من الموثقين تشغيل TEEs أنفسهم أو إدارة أي مواد مفتاحية جديدة.
الميكانيكا:
يقوم المُنشئ ببناء كتلة ويُشفرها لجنة الشهود.
يقوم المُبني بإنشاء دليل TEE يُظهر ثلاثة أشياء للجنة المعترف بها: أن العرض صادق، وأن الكتلة صالحة، وأنها مشفرة بشكل صحيح.
يتواصل البناء مع كتلة التشفير الحدية وبرهان TEE (الذي يتضمن قيمة العرض) إلى المقترح.[3]
يوقع المقترح على كتلة المشيد الفائز المشفرة ويتسرب هذا المقترح إلى مجموعة المحققين.
بمجرد أن تقوم لجنة المصادقين n-attester المحددة (على سبيل المثال ، n/2 أو 2n/3) بمصادقة الفتحة على الكتلة ، يتم فك تشفيرها.
يتابع الكتلة المفككة الى الاستكمال بشكل طبيعي.
تتميز خصائص الأداء لتشفير الحد الصامت بشكل جيد.
n هو الحد الأقصى لحجم اللجنة التي نرغب في دعمها و t هو الحد الأدنى لفك التشفير.
كل من التشفير وفك التشفير الجزئي هما من الوقت الثابت. مع تنفيذ ساذج ، يستغرق التشفير أقل من 7 مللي ثانية - ويمكن توازيها. يستغرق فك التشفير الجزئي أقل من 1 مللي ثانية.
حجم النص المشفر عامل إضافي ثابت بحجم 768 بايت ، أكبر من النص الأصلي (بغض النظر عن قيم n و t)
تعتمد تجميع فك التشفير الجزئي على حجم اللجنة. مع n=1024، يستغرق التنفيذ الساذج أقل من 200 مللي ثانية. نتوقع أن ينخفض ذلك بمقدار 10 مع n=128 (حجم لجنة التصديق لكل فتحة)، ويمكن تحسين التنفيذ بشكل إضافي.
من الأهمية بشكل كبير أن يكون وقت التشفير هو الرقم الأساسي للأداء الذي يتم مقارنته بتأخر المناوبة. هذا ما يجب على البناء حسابه في "المسار الحرج" لإنتاج الكتلة. إنه أقل من تأخر معالجة الكتلة في المناوبة الحالية ويتجنب التواصل متعدد القفزات.
تشفير عتبة الصمت ليس مجانيًا تمامًا. فهو يتطلب سلسلة مرجعية مشتركة من النوع: (g، gτ,gτ2,…,gτn−t), مماثل لما يستخدم في نظام التزام الجدول الدالة الكثيرية KZG.
بالإضافة إلى ذلك، يقوم كل محقق بمفتاح عام BLS من النوع gsk بنشر مجموعة من العناصر الجماعية التي نسميها "تلميحات": (جsk⋅τ,…,gsk⋅τn−t). هذه التلميحات مطلوبة فقط لتجميع المفاتيح العامة وفك تشفير النصوص المشفرة. يستخدم التشفير فقط مفتاحًا عامًا مجمعًا بحجم ثابت.
حتى كتابة هذا المنشور، هناك حوالي 1 مليون منقب. إذا قمنا بتعيين n=128 و t=n/2، فإن كل منقب يحتاج إلى نشر حوالي 3 كيلوبايت من التلميحات. وبالتالي، يتطلب تخزين تلميحات جميع المنقبين 3 جيجابايت.
سيقل هذا المتطلب على الأرجح بشكل كبير مع تفعيل MaxEB، والتي تسمح للمدققين الذين يتحكمون في أكثر من 32 ETH بحمل أرصدة أكبر تحت نفس مفتاح الزوج (بدلاً من تجزيءها على عدة إيداعات 32 ETH). يتم مناقشة الحد من مجموعة المدققين التي سيتم تحقيقها. يبدو أنه من الممكن أن نصل إلى حوالي 1 جيجابايت.
أخيرًا، واعتمادًا على التغييرات المستقبلية في بنية consensu Ethereum (على سبيل المثال، تقليلات إضافية في حجم مجموعة المدققين، أو أنابيب النهاية البديلة) فإن حجم التلميحات التي يجب تخزينها قد يقل بشكل أكبر.
يرغب إيثريوم في البقاء على قيد الحياة حتى في ظل ظروف الشبكة السلبية. إحدى المشكلات في هذا النظام هي احتمالية وجود كتل لا يمكن فك تشفيرها لأن الكسر المحدد من اللجنة غير متصل بالإنترنت.
إحدى الحلول هي السماح للبنّاء بتحديد الكسر المقبول (𝑡) من المجلس للفك شفرته. هناك توازن بين الخصوصية (إمكانية فك تجزئة وسرقة MEV) واحتمالية استمرار عتبة المجلس على الإنترنت. إنه من المربح للبنّاءين الحصول على تضمين كتلهم بدلاً من الشوكات، لذلك يجب أن يحددوا إعدادًا محسّنًا للعتبة.[4]
بالإضافة إلى ذلك، يجب أن يكون استخدام هذه النظام التشفير اختياريًا. في ظروف الشبكة السيئة، حيث لا يتوفر لجنة بحجم ملائم بشكل دائم، يمكن للمقترحين والبنائين اللجوء إلى استخدام مناوبات أو بناء الذاتي أو أي آلية أخرى تفضلها بناءً على طبيعة البيئة السيئة.
وبشكل بديل، قد تكون اللجنة عبر الإنترنت، ولكن قد يتمكن الباني من خلق حالة يتعذر فيها فك تشفير الكتلة أو تكون غير صالحة عند فك التشفير (على سبيل المثال، باستخدام دلائل مزيفة).
من وجهة نظر البروتوكول ، فمن المقبول أن يفصل هذه الكتل. ببساطة ، فإن مجموعة المحقق الأوسع لا يمكنها التصديق عليها أو على أي كتلة تشير إليها. أفضل طريقة للتعامل مع هذا النوع من الأخطاء هي جعل عميل التوافق على علم بالاحتمالية وقادرًا على الفشل بشكل لائق. يتطلب ذلك دراسة مستفيضة حول كيفية التعامل مع المسألة تحديدًا.
يعرف المنشئ الفائز محتويات الكتلة قبل الآخرين حتى يتم الوصول إلى الحد الأدنى ، مما قد يخلق ميزة غير عادلة في الفتحات اللاحقة. ومع ذلك ، من المفترض أن تعمل لجنة التصديق قبل نهاية الفتحة التالية ، وتكون غالبية قيمة الكتلة في نهاية الفتحة ، لذلك يجب أن تكون تأثيرات هذه الميزة ضئيلة قدر الإمكان.
في المدى الطويل، قد يكون من الممكن استبدال دلائل TEE بدلائل الأمان الصفري (ZK). حالياً، تعتبر دلائل ZK بطيئة للغاية، ولكن التطورات في علم التشفير والبرمجيات والأجهزة المتخصصة (ASICs) قد تجعل توليد دليل ZK ممكناً في نهاية المطاف ضمن القيود اللازمة للتأخير. يجدر بالذكر أن دلائل ZK المصاحبة للكتل موجودة بالفعلالجزء الأساسي من خارطة طريق إثريوم على المدى الطويل.
مع حجم مجموعة المحقق الحالي ومعدل النمو الحالي، قد لا يكون هذا النظام يستحق الكمية من البيانات المطلوبة للنشر على L1. ومع ذلك، يخطط Ethereum بالفعل لتقليل عدد مجموعة المحقق بشكل كبير مع MaxEB.
من المحتمل أن يكون النهج الأفضل ترقية إلى جانب أو بعد MaxEB حيث يتم إعلام عملاء الاتفاقية بإمكانية دلالات الكتل المشفرة ويتم تشجيع المحققين على نشر التلميحات. على سبيل المثال ، بعد MaxEB ، يمكن أن يتطلب من المحققين الجدد نشر التلميحات ، ويمكن إعطاء المحققين الأقدم حافزًا للترقية.
سيبدأ المُنشئون في استخدام الآلية بمجرد أن يتبنى نسبة كافية من مجموعة المُعتمدين لديهم أحجام لجان كافية (أي خصوصية مقبولة واحتمال فك التشفير).
إذا كان لدينا نهج يتمتع فعلاً بتأخير ملائم مقارنة بالتوجيه متعدد القفزات، يجب أن يعتمده السوق بدون الحاجة لفرض استخدام البروتوكول أو توثيق تحديد معلمة معينة.
المناوبات هي واحدة من أهم مصادر تمركز إثيريوم، مما يخلق فرصًا للاستئجار ويشوه تمركز البروتوكول جغرافيًا.
نحن بحاجة إلى إزالة المناوبات ونعتقد أن هذه هي الطريقة الأنيقة نسبيا للقيام بذلك. يتطلب تغييرات في طبقة الاتفاق، ولكن لا يتطلب استخدام مواد جديدة أو مواد رئيسية من جانب المحققين.
السلبية هي أنها تعدل معقدة لطبقة التوافق من أجل آلية قد تتم اعتمادها أو لا من قبل السوق (كما يقترح). ومع ذلك، تطرح العديد من التغييرات المحتملة على خط أنابيب MEV أسئلة مماثلة بالنسبة للتبني وتحسين الإيرادات (على سبيل المثال، قوائم الاحتواء). وقد تكون هناك حالات استخدام مستقبلية أخرى تعتمد على مجموعة المدقق التي تحتوي على بنية تحتية لتشفير العتبة المتاحة.