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

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

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

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

• لا يمكن تأكيد كتلتين متضاربتين على حد سواء؛
• يجب أن تستمر الشبكة في المضي قدمًا ولا يمكن أن تتوقف أو تتوقف.

MonadBFT هو أحدث اختراق تكنولوجي في هذا الاتجاه.

مراجعة موجزة لتطور بروتوكولات التوافق

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

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

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

تعقيد هيكل هذه الاتصالات هو n² - وهذا يعني، إذا كان هناك 100 محقق في الشبكة، قد تتطلب كل جولة من التوافق نقل ما يقرب من 10،000 رسالة.

في شبكة صغيرة، هذه ليست مشكلة، ولكن بمجرد زيادة عدد المحققين، ستصبح عبء الاتصالات في النظام لا يُحتمل بسرعة، مما يؤثر مباشرة على الكفاءة.

مصدر المعلومات:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

هياكل الاتصال الثانوية 'يتحدث الجميع مع الجميع' في الحقيقة غير فعالة جدًا. على سبيل المثال، في شبكة تحتوي على 100 محققًا، قد تحتاج كل جولة من التوافق إلى معالجة عشرات الآلاف من الرسائل.

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

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

هذا يحسن تعقيد الرسالة من n² الأصلي إلى n، مما يقلل بشكل كبير من عبء النظام.

تم اقتراح بروتوكول HotStuff في عام 2018 لمعالجة مشكلة التوسع القدرة هذه. فلسفته التصميمية واضحة جدًا: لاستبدال عملية التصويت المعقدة لـ PBFT ببنية تواصل أكثر اختصارًا وقيادة.

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

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

على النقيض من ذلك، طريقة الاتصال في PBFT هي 'بث للجميع'، حيث يتحدث الجميع في المجموعة، مما يؤدي في بعض الأحيان إلى مشهد فوضوي. طريقة HotStuff تشبه أكثر 'يجمع واحد، يعبأ في كل مرة'، مما يمكنه الحفاظ على التشغيل الفعال بغض النظر عن عدد الأشخاص في الشبكة.

يقارن الشكل بنية التواصل الخارجية لـ HotStuff مع وضع PBFT المتصل بالكامل المصدر:

https://www.mdpi.com/1424-8220/24/16/5417

بالإضافة إلى الاتصال الخطي، يمكن ترقية HotStuff إلى إصدار مُجزأ بشكل أعمق، مما يُستخدم لتحسين الكفاءة.

في HotStuff الأصلي، سيكون نفس المحقق كزعيم لعدة جولات متتالية، حتى يتم تأكيد كتلة بالكامل. هذه العملية هي 'معالجة كتلة واحدة في كل جولة'، مع تركيز جميع الجهود على تقدم الكتلة الحالية.

في خط الأنابيب HotStuff، الآلية أكثر مرونة: يتم اختيار قائد جديد في كل جولة، ولكل قائد مهمتان:

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

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

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

باختصار، جعلت البروتوكولات مثل HotStuff تحسينات كبيرة على الصعيدين التقليدي و BFT:

• أولاً، تكون الاتصالات أخف، حيث يحتاج كل محقق فقط إلى التواصل مع القائد؛
• ثانياً، كفاءة المعالجة أعلى، ويمكن أن تعمل عمليات تأكيد الكتل المتعددة بشكل متوازي.

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

بعد ذلك، سننغمس في هذه المسألة الأساسية: التفريع الذيلي.

مشكلة فروع الذيل في النهاية

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

ما هو شوكة الذيل؟ يمكن أن يُفهم ببساطة على أنه: تواجه سلسلة كتل البلوكشين إعادة تنظيم عرضية للكتل في 'ذيل' السلسلة.

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

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

كما ذكرنا سابقا، لكل قائد في خط الأنابيب HotStuff مهمتان:

• A. اقترح كتلة جديدة (مثل Bₙ₊₁)
• B. جمع الأصوات لكتلة القائد السابق لتوليد QC (على سبيل المثال، لتأكيد Bₙ في النهاية)

هذه المهامان متوازيتان، تأخذان دورهما بالتناوب للتتابع. ولكن المشكلة تنشأ هنا.

على سبيل المثال، لنفترض أن أليس هي القائدة، وقد اقترحت كتلة Bₙ في الارتفاع n، والتي حصلت على غالبية سوبر وهي "تقريبًا مؤكدة".

بعد ذلك، يجب أن يكون دور بوب الآن لتولي دور القائد، ومواصلة التقدم إلى الكتلة التالية Bₙ₊₁ من السلسلة، وكذلك تضمين QC (الالتزام المؤهل) لـ Bₙ في اقتراحه لاستكمال التأكيد النهائي لـ Bₙ.

ولكن إذا كان بوب غير متصل في هذا الوقت، أو لا يقدم بوضوح نوعية التحكم القياسي لـ Bₙ، فإن هناك مشكلة.

لأنه لم يقم أحد بتغليف كتلة أليس ب QC، فإن سجل التصويت لـ Bₙ لم ينتشر. تم معالجة هذه الكتلة، التي يجب أن تكون مؤكدة، 'عملية باردة' وتم تجاهلها في نهاية المطاف من قبل الشبكة بأكملها.

هذه هي جوهر شوكة الذيل: يتم تخطي كتلة من القائد السابق بسبب الإهمال أو الخبث من القائد التالي.

لماذا الشوكة الخلفية شديدة؟

مشكلة الشوكة الذيلية تركز أساسًا على جانبين: 1) تعطيل آلية الحوافز، 2) تهديد نشاط النظام.

أولاً، يتم بلع المكافآت:

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

الثاني، توسع سطح هجوم MEV:

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

الثالث، تقويض ضمان النهوض الأخير، مما يؤثر على تجربة المستخدم:

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

رابعا، قد يسبب فشل رد الفعل المتسلسل:

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

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

ما هو MonadBFT؟

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

1) الزعيم الدوار: اختيار زعيم جديد لكل جولة لدفع السلسلة للأمام؛
2) التعهدات المجزأة: يمكن أن تتداخل عمليات تأكيد الكتل المتعددة؛
3) التواصل الخطي (الرسائل الخطية): كل مدقق يحتاج فقط للتواصل مع القائد، مما يوفر الكثير من السمعة على الشبكة.

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

آلية إعادة الاقتراح الإلزامية (إعادة اقتراح)
2) شهادة عدم التأييد (NEC)

آلية إعادة الاقتراح

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

أضاف MonadBFT آلية لضمان أن أي كتل مقترحة بصدق خلال عملية تبديل العرض لن تفقد السلسلة بسبب دورة الزعيم.

عند فشل القائد الحالي، سيقوم المحققون بإرسال رسالة موقعة لتبديل الجولة (تغيير الرأي)، مشيرين إلى أن الجولة الحالية قد انتهت.

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

سيقوم الزعماء الجدد بجمع رسائل انتهاء الوقت هذه من الجوالة الفائقة الأكثرية (2f+1) ودمجها في شهادة انتهاء الوقت (TC). تمثل هذه الـ TC اللقطة الإدراكية الموحدة لـ 'رأس السلسلة الكتلية' للشبكة بأكملها عند فشل الجولة السابقة. سيختار الزعيم الجديد الكتلة ذات الارتفاع الأعلى (أو أحدث رقم رأي)، المعروفة باسم الـ high_tip، منها.

يتطلب MonadBFT: يجب أن يتضمن اقتراح قائد جديد TC صالحًا ويجب إعادة اقتراح أعلى كتلة معلقة في TC لإعطاء هذه الكتلة فرصة أخرى لتأكيد.

لماذا؟ كما ذكر سابقا: نحن لا نريد أن يختفي كتلة قريبة من التأكيد.

على سبيل المثال، لنفترض أن أليس هي قائد العرض 5، اقترحت كتلة صالحة، وتلقت أغلبية الأصوات. بعد ذلك، عندما يكون قائد العرض 6، بوب، غير متصل بالإنترنت ويفشل في تقدم عملية السلسلة، بحلول وقت تولي كارول كقائد للعرض 7، وفقًا لقواعد MonadBFT، يجب عليها أن تضمن TC وتعيد اقتراح كتلة أليس. بهذه الطريقة، لن يذهب عمل أليس الشريف سدى.

إذا لم تكن لدى كارول كتلة أليس، يمكنها طلبها من العقد الأخرى. يمكن للعقد أن:

• تقديم الكتلة، أو
• إرجاع رسالة 'لا تأييد (NE)' موقعة، تشير إلى أن المرسل ليس لديه هذا الكتلة (يتم شرح آليته في وقت لاحق). (يمكن لما يصل إلى f من العقد البيزنطية تجاهل الطلب وعدم الرد.)

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

دور آلية إعادة الاقتراح هذه واضح: ضمان تقدم السلسلة بشكل عادل، وعدم رمي أي عمل صالح بصمت بسبب الحظ السيئ أو تخريب شخص ما.

شهادة غير قابلة للتوقيع (NEC)

مواصلة مع المثال السابق: بعد انتهاء دور بوب، تطلب كارول من المحققين الآخرين تقديم كتلة الحد الأعلى (أي كتلة أليس). في هذه النقطة، سيستجيب على الأقل 2f+1 محققًا:

• إما توفير كتل أليس
• سواء قمت بإرسال رسالة NE موقعة تشير إلى أنك لم تستلم كتلة أليس.

طالما تتلقى كارول كتلة أليس، يجب أن تقترحها مرة أخرى وفقًا للقواعد. يمكن لكارول تخطي الكتلة فقط واقتراح واحدة جديدة عندما يقوم الحد الأدنى من f+1 المحققين بتوقيع رسالة NE.

لماذا f+1؟ في نظام BFT المكون من 3f+1 مدققًا، يمكن أن يكون الحد الأقصى للمتسللين f فقط. إذا كان من المؤكد أن كتلة أليس حصلت فعلًا على أغلبية سوبر، فإن على الأقل 2f+1 عقد صادقة تلقتها.

لذلك، إذا ادعت كارول: 'لا أستطيع الحصول على كتلة أليس'، يجب عليها إنتاج علامات تأييد من المحققين بمقدار f+1 لإثبات عدم تلقي أي منهم لها. وهذا يشكل شهادة عدم تأييد (NEC).

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

إعادة الاقتراح + شهادة غير موقعة = حل الشوكة الذيلية

يقدم MonadBFT مجموعة من قواعد معالجة رؤوس السلسلة صارمة وواضحة من خلال إدخال آلية إعادة الاقتراح وشهادة عدم الإقرار (NEC).

إما أن تلتزم في النهاية بالكتلة 'القريبة من التأكيد'؛

إما تقديم أدلة كافية لإثبات أن الكتلة لم تكتمل بعد لتأكيدها،

وإلا، لا يُسمح بتخطي أو استبدال الكتلة السابقة.

هذا الآلية تضمن أن أي كتلة حصلت على أغلبية قانونية من الأصوات لن يتم التخلي عنها بسبب أخطاء القائد أو التفادي العمد.

تم حل مخاطر الهضبة الذيل بشكل منهجي، ويمكن للبروتوكول أن يقيد بوضوح السلوك الغير مناسب للتخطي.

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

من وجهة نظر الحوافز الاقتصادية، يوفر هذا التصميم حماية واضحة للمحققين:

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

الأهم من ذلك، لم تضحِ MonadBFT الأداء البروتوكولي من أجل تعزيز الأمان.

بعض التصاميم التي تتعامل مع شواخص الذيل (مثل بروتوكول BeeGees) في الماضي لديها قدرات وقائية معينة، ولكن غالبًا ما تعتمد على تعقيد الاتصال العالي (n²) أو تمكين عمليات اتصال ثقيلة في كل دورة، مما يزيد بشكل كبير من عبء النظام في الممارسة.

استراتيجية تصميم MonadBFT أكثر تطوراً:

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

التوازن الديناميكي بين الأداء والأمان هو بالضبط أحد المزايا الأساسية لـ MonadBFT على البروتوكولات السابقة.

ملخص

يستعرض هذا المقال الآلية الأساسية لموافقة PBFT التقليدية، ويفرز مسار التطوير لبروتوكول HotStuff، ويركز على كيفية حل MonadBFT لمشكلة الشوكة الذيلية الكامنة في تركيبة الطبقة البروتوكولية HotStuff.

يمكن أن تشوه الشوك الخلفي الحوافز الاقتصادية لمقترحي الكتلة وتشكل تهديدًا محتملًا لنشاط الشبكة. يضمن MonadBFT أن أي كتلة مقترحة من قادة صادقين وموافقة عليها بالتصويت بغالبية قانونية لن تتم التخلي عنها أو تخطيها من خلال إدخال آلية إعادة المقترح وشهادة غير معتمدة (NEC).

في المقالة التالية، سنستمر في استكشاف الميزتين الأساسيتين الأخريين لـ MonadBFT:

1) النهوض الاحتمالي
2）الاستجابة المتفائلة

تحليل أعمق لهذه الآليات وأهميتها العملية للمحققين والمطورين.

بيان:

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