فيتاليك: مستقبل بروتوكول الإيثريوم (الجزء الأول) - الدمج

المؤلف: فيتاليك؛ المترجم: دينغ تونغ، Golden Finance

شكر خاص لجوستين دريك، وهسياو-وي وانغ، و@antonttc، وفرانشيسكو على تعليقاتهم ومراجعتهم.

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

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

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

هذه ليست قائمة شاملة بالتحسينات التي يمكن إجراؤها على إثبات الحصة، بل هي قائمة بالأفكار التي يتم النظر فيها بنشاط.

النهائية ذات الفتحة الواحدة وإرساء الديمقراطية

ما هي المشكلة التي نحلها؟

اليوم، يستغرق الأمر 2-3 حقب (~ 15 دقيقة) لإكمال الكتلة ويتطلب 32 ETH لتصبح لاعبًا. كان هذا في الأصل حلاً وسطًا لتحقيق التوازن بين ثلاثة أهداف:

• < p>تعظيم العدد من المدققين الذين يمكنهم المشاركة في التوقيع المساحي (وهذا يعني بشكل مباشر تقليل الحد الأدنى من ETH المطلوب للمشاركة)

• تقليل وقت الإكمال إلى أدنى حد

• تقليل النفقات العامة لتشغيل العقدة

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

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

من الناحية المثالية، نود الحفاظ على النهاية الاقتصادية مع تحسين الوضع الراهن في مجالين:

• إنهاء الكتل خلال فترة زمنية (من الأفضل الحفاظ على الطول الحالي وهو 12 ثانية أو حتى تقليله) بدلاً من 15 دقيقة

• السماح للمدققين بـ حصة بـ 1 إيثريوم (تم التخفيض من 32 إيثريوم إلى 1 إيثريوم)

يتم إثبات الهدف الأول من خلال هدفين، وكلاهما يمكن مشاهدته والهدف هو "محاذاة خصائص إيثريوم مع خصائص سلاسل L1 (الأكثر مركزية) التي تركز على الأداء."

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

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

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

ما هو وكيف يعمل؟

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

الاقتراح النهائي الرائد للفتحة الواحدة

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

• الخيار 1:القوة الغاشمة - العمل من أجل بروتوكول أفضل لتجميع التوقيع، ربما باستخدام ZK-SNARKs، والذي سيسمح لنا في الواقع بمعالجة أرقام التوقيعات لكل فتحة من ملايين المدققين.

البوق، أحد التصميمات المقترحة لبروتوكولات التجميع الأفضل.

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

  إحدى طرق التفكير في Orbit SSF هي أنه يفتح مساحة من خيارات التسوية التي تتراوح من x=0 (لجنة على طراز Algorand، لا يوجد نهائية اقتصادية) إلى x= 1 (الحالة الحالية لـ Ethereum)، يفتح نقطة في المنتصف حيث لا يزال لدى Ethereum ما يكفي من النهاية الاقتصادية ليكون آمنًا للغاية، ولكن في الوقت نفسه نكتسب ميزة الكفاءة المتمثلة في طلب عينة عشوائية متوسطة الحجم من المدققين فقط للمشاركة في كل عصر.

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

• الخيار 3: الستاكينغ ذو المستويين - آلية يتم فيها تقسيم المتعهدين إلى فئتين، واحدة بمتطلبات إيداع أعلى والأخرى بمتطلبات إيداع أقل. فقط المستويات ذات متطلبات الإيداع الأعلى ستشارك بشكل مباشر في توفير النهاية الاقتصادية. هناك العديد من المقترحات حول ما هي الحقوق والمسؤوليات بالضبط بالنسبة للمستويات ذات متطلبات الإيداع الأقل (انظر، على سبيل المثال، منشور Rainbow Scking). تتضمن الأفكار الشائعة ما يلي:

• تفويض المصالح إلى الحقوق من أصحاب المصلحة ذوي المستوى الأعلى

• يتم اعتماد أصحاب المصلحة من المستوى الأدنى المختارين عشوائيًا ويطلب منهم إكمال كل كتلة

• الحق في إنشاء قوائم التضمين

كيف يرتبط ذلك بالأبحاث الحالية؟

المسار لتحقيق نهائية الفتحة الواحدة (2022): https://notes.ethereum.org/@vbuterin/single_slot_finality

اقتراح محدد لبروتوكول النهاية أحادي الفتحة لـ Ethereum (2023): https://eprint.iacr.org/2023/280

Orbit SSF: https://ethresear.ch/t/orbit-ssf-solo-slooking-Friendly-validator-set-management-for-ssf/19928

مزيد من التحليل لآلية نمط Orbit: https://notes.ethereum.org/@anderselowsson/Vorbit_SSF

القرن، بروتوكول تجميع التوقيع (2022) ): https://ethresear.ch/t/horn-collecting-signatures-for-faster-finality/14219

دمج التوقيع للتوافق على نطاق واسع ( 2023): https://ethresear.ch/t/signature-merging-for-large-scale-consensus/17386?u=asn

خوفراتوفيتش وآخرون بروتوكول تجميع التوقيع: https://hackmd.io/@7dpNYqjKQGeYC7wMlPxHtQ/BykM3ggu0#/

تجميع التوقيع المستند إلى STARK (2022): https://hackmd. .io/@vbuterin/stark_aggregation

حصاد قوس قزح: https://ethresear.ch/t/unbundling-stake-towards-rainbow-stake/18683

ما الذي بقي للقيام به؟ ما هي المقايضات؟

هناك أربعة مسارات رئيسية محتملة (يمكننا أيضًا استخدام المسارات المختلطة):

• الحفاظ على الوضع الراهن

• Orbit SSF

• SSF قوي

< li>

SSF بمستويين من الستاكينغ

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

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

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

(3) تجنب إعادة التفكير الذكي وبدلاً من ذلك حل المشكلات بالقوة باستخدام التكنولوجيا المتقدمة. ويتطلب القيام بذلك جمع عدد كبير من التوقيعات (أكثر من مليون) في وقت قصير جدًا (5-10 ثوانٍ).

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

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

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

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

يمكن دمج استراتيجيات متعددة، على سبيل المثال:

• (1 + 2): إضافة Orbit دون إجراء عملية نهائية في فتحة واحدة.

• (1 + 3): استخدم تقنيات القوة الغاشمة لتقليل الحد الأدنى لحجم الإيداع دون فرض نهائية الفتحة الواحدة. كمية البلمرة المطلوبة أقل بـ 64 مرة مما كانت عليه في الحالة النقية (3)، وبالتالي تصبح المشكلة أسهل.

• (2 + 3): تنفيذ Orbit SSF بمعلمات متحفظة (على سبيل المثال، لجنة التحقق من الصحة 128k بدلاً من 8k أو 32k) واستخدام تقنيات القوة الغاشمة لجعلها فائقة الكفاءة.

• (1 + 4): إضافة حصة قوس قزح دون فرض نهائية في فتحة واحدة.

كيف تتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

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

انتخاب قائد سري واحد

ما هي المشكلة التي نريد حلها؟

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

ما هذا؟ كيف يعمل؟

إن أفضل طريقة لحل مشكلة DoS هي إخفاء المعلومات الخاصة بالمدقق الذي سيقوم بإنشاء الكتلة التالية، على الأقل حتى يتم إنشاء الكتلة فعليًا. لاحظ أن هذا سيكون سهلاً إذا قمنا بإزالة الشرط "الفردي": أحد الحلول هو السماح لأي شخص بإنشاء الكتلة التالية، ولكن مطالبة Randao بالكشف عن أقل من 2256/N. في المتوسط، يلبي مدقق واحد فقط هذا المطلب - ولكن في بعض الأحيان يكون هناك مدققان أو أكثر، وأحيانًا يكون هناك صفر. إن الجمع بين شرط "السرية" وشرط "الوحدة" كان دائما مشكلة صعبة.

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

بروتوكول Whisk SSLE

ما هي بعض الروابط للأبحاث الحالية؟

مقالة دان بونيه (2020): https://eprint.iacr.org/2020/025.pdf

Whisk (اقتراح محدد لـ Ethereum، 2022): https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763< /p>< p style="text-align: left;">علامة انتخاب زعيم سري واحدة على ethresear.ch: https://ethresear.ch/tag/single-secret-leader-election

ما الذي بقي للقيام به؟ ما هي المقايضات؟

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

في النهاية قد يكون هناك موقف حيث يتم تحقيق "القيمة الهامشية" لـ SSLE فقط عندما نقدم آلية عامة لإثبات المعرفة الصفرية على L1 من بروتوكول Ethereum لأسباب أخرى (على سبيل المثال، شجرة الحالة، ZK-EVM) سيتم تخفيض "التعقيد الإضافي" إلى مستوى منخفض بما فيه الكفاية.

هناك خيار آخر وهو تجاهل SSLE على الإطلاق واستخدام وسائل التخفيف خارج البروتوكول (مثل طبقة p2p) لمعالجة مشكلات DoS بدلاً من ذلك.

كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

تأكيد أسرع للمعاملة

ما هي المشكلة التي نحلها؟

هناك قيمة في إجراء مزيد من التخفيضات في وقت تأكيد معاملة Ethereum، من 12 ثانية إلى 4 ثوانٍ. سيؤدي القيام بذلك إلى تحسين تجربة المستخدم المستندة إلى L1 والتجميع بشكل كبير مع جعل بروتوكول defi أكثر كفاءة. كما أنه سيسهل على اللغة الثانية تحقيق اللامركزية، حيث سيسمح لعدد كبير من تطبيقات اللغة الثانية بالعمل على الطلب القائم على التجميع، وبالتالي تقليل حاجة اللغة الثانية لبناء ترتيب لامركزي قائم على اللجان.

ما هذا؟ كيف يعمل؟

يوجد هنا طريقتان تقريبًا:

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

• يسمح لمقدمي العروض بإصدار تأكيدات مسبقة أثناء الفترة. في الحالات القصوى، يمكن لمقدمي العروض دمج المعاملات التي يرونها في الكتل الخاصة بهم في الوقت الفعلي ونشر رسالة تأكيد مسبقة على الفور لكل معاملة ("معاملتي الأولى كانت 0×1234..."، "معاملتي الثانية هي 0×5678..."). يمكن التعامل مع الموقف الذي يُصدر فيه المُقترح تأكيدين متعارضين بطريقتين: (1) عن طريق قطع المُقترح، أو (2) باستخدام الأمثال للتصويت على أيهما أسبق.

ما هي بعض الروابط للأبحاث الموجودة؟

بناءً على التأكيدات المسبقة: https://ethresear.ch/t/based-preconfirmations/17353

التزامات مقدمي العروض المفروضة بموجب البروتوكول (PEPC): https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879

فترات متداخلة على السلاسل المتوازية (أفكار لتحقيق زمن وصول منخفض في 2018): https://ethresear.ch/t/staggered-periods/1793

ما الذي تبقى للقيام به، ما هي المقايضات؟

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

تتمثل نقطة الضعف في طريقة التأكيد المسبق لمقدم الطلب في أنها تعمل على تحسين متوسط ​​وقت إدراج الحالة بشكل كبير، ولكن ليس وقت تضمين الحالة الأسوأ: إذا كان مقدم العرض الحالي يعمل بشكل جيد، فستتم معاملتك في 0.5 Get تم تأكيده مسبقًا في ثوانٍ بدلاً من 6 ثوانٍ (في المتوسط) ليتم تضمينه، ولكن إذا كان مقدم الاقتراح الحالي غير متصل بالإنترنت أو لا يعمل بشكل جيد، فلا يزال يتعين عليك الانتظار لمدة 12 ثانية كاملة قبل أن تتمكن من بدء الفترة التالية وتقديم مقترح جديد.

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

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

كيف يتفاعل مع الأجزاء الأخرى من خريطة الطريق؟

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

مجالات البحث الأخرى

التعافي من الهجمات بنسبة 51%

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

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

زيادة حد النصاب القانوني

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

يجيب هذا أيضًا على السؤال "ما الفائدة من المتعهدين المنفصلين؟" اليوم، غالبية أصحاب المصلحة يقومون بالفعل بالتخزين من خلال المجمعات، ويبدو من غير المرجح أن يحصل أحد أصحاب المصلحة على ما يصل إلى 51٪ من ETH. ومع ذلك، فإن الحصول على حصة منفردة للوصول إلى الأقلية التي تمنع الأغلبية يبدو ممكنًا إذا حاولنا جاهدين، خاصة إذا وصلت الأغلبية إلى 80% (لذلك هناك حاجة إلى 21% فقط لمنع الأغلبية). طالما أن أصحاب المصلحة الوحيدين لا يشاركون في هجوم بنسبة 51% (سواء كان عكس النهاية أو المراجعة)، فلن يكون هناك "نصر واضح" لهذا الهجوم، وسيساعد أصحاب المصلحة الوحيدون بنشاط في تنظيم شوكات الأقليات الناعمة.

المقاومة الكمية

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

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