يتمثل جوهر blockchain في تحقيق نوع من الإجماع العالمي الصارم: أي أنه بغض النظر عن مكان توزيع عقد الشبكة، في أي بلد أو منطقة زمنية، يجب على جميع المشاركين في النهاية التوصل إلى توافق حول مجموعة من النتائج الموضوعية.
ومع ذلك ، فإن الشبكة الموزعة في الواقع ليست مثالية: يتم فصل بعض العقد ، وبعض العقد تكمن ، وبعضها يخرب عمدا. في هذه الحالة ، كيف "يتحدث النظام" ويحافظ على الاتساق؟
هذه هي المشكلة التي تهدف بروتوكولات الإجماع إلى حلها. إنها في جوهرها مجموعة من القواعد التي توجه مجموعة من العقد المستقلة تمامًا، وحتى غير الموثوق بها تمامًا، حول كيفية التوصل إلى قرار موحد بشأن ترتيب ومحتوى كل عملية.
بمجرد إنشاء هذا "الإجماع الصارم" ، تفتح blockchain عددا من الميزات الرئيسية ، مثل حماية الملكية الرقمية ، والنماذج النقدية المقاومة للتضخم ، وهياكل التعاون الاجتماعي القابلة للتطوير. لكن الفرضية هي أن بروتوكول الإجماع نفسه يجب أن يضمن أساسيين في نفس الوقت:
لا يمكن أن يتم تأكيد كتلتين تتعارضان مع بعضهما.
يجب أن يستمر الشبكة في التقدم، ولا يمكن أن تتعطل أو تتوقف.
مونادBFT هو أحدث تقدم تقني تم إحرازه في هذا الاتجاه.
نظرة عامة موجزة على تطور بروتوكولات الإجماع
لقد تم البحث في مجال آليات الإجماع منذ عقود. كانت أول مجموعة من البروتوكولات مثل PBFT (تحمل الأخطاء البيزنطية العملية) قادرة بالفعل على معالجة حالة واقعية للغاية: حتى لو كان هناك عدد من العقد في الشبكة تفقد الاتصال أو تتصرف بشكل ضار أو تتحدث هراء، طالما أنها لا تتجاوز ثلث العدد الإجمالي، يمكن للنظام أن يتوصل إلى توافق.
تم تصميم هذه البروتوكولات المبكرة بطريقة "تقليدية": في كل جولة يتم اختيار قائد واحد، الذي يقوم بإطلاق الاقتراح، ومن ثم يقوم باقي المدققين بالتصويت على هذا الاقتراح في جولات متعددة، لتأكيد تسلسل المعاملات خطوة بخطوة.
تمر عملية التصويت عادة بعدة مراحل ، مثل الإعداد المسبق والإعداد والالتزام والرد. في كل مرحلة ، يتواصل جميع المدققين مع بعضهم البعض. بمعنى آخر ، يجب على الجميع إخبار الجميع ، وحجم الرسائل ينمو بشكل متفجر في "شبكة".
تعقيد هيكل الاتصال هذا هو n² - بمعنى أنه إذا كان هناك 100 مدقق في الشبكة، فقد يتعين إرسال ما يقرب من 10,000 رسالة في كل جولة من التوافق.
هذه ليست مشكلة كبيرة في الشبكات الصغيرة، ولكن بمجرد أن يزيد عدد المدققين، فإن عبء التواصل في النظام سيصبح سريعًا غير قابل للتحمل، وستتدهور الكفاءة بشكل مباشر.
مصدر المعلومات:
هيكل الاتصال الثانوي "يجب على كل شخص أن يتواصل مع كل شخص" غير فعال للغاية. على سبيل المثال، في شبكة بها 100 مدقق، قد تحتاج كل دورة توافق إلى معالجة آلاف الرسائل.
هذا يمكن التعامل معه في دائرة صغيرة، ولكن إذا وضع في شبكة مفتوحة على نطاق عالمي، فإن عبء الاتصالات يصبح غير مقبول على الفور. لذا فإن بروتوكولات BFT المبكرة مثل PBFT و Tendermint تُستخدم عادةً فقط في السيناريوهات المصرح بها (شبكة مسموح بها) أو في الأنظمة التي تحتوي على عدد قليل جدًا من المدققين، حيث يمكن أن تعمل بصعوبة.
من أجل تكييف بروتوكول BFT مع بيئة سلسلة عامة بدون إذن ، بدأت بعض تصميمات الجيل التالي في التحرك نحو طريقة اتصال أخف: يتواصل كل مدقق فقط مع القائد ، بدلا من جميع أعضاء الفريق.
هذا يقلل من تعقيد الرسالة من n² الأصلية إلى n - مما خفف بشكل كبير من عبء النظام.
تم اقتراح بروتوكول HotStuff في عام 2018، وكان ذلك لحل مشكلة القابلية للتوسع. إن فلسفة تصميمه واضحة جدًا: استبدال عملية التصويت المعقدة لـ PBFT بهيكل اتصال أبسط يقوده القائد.
الخاصية الرئيسية لـ HotStuff هي ما يسمى بالتواصل الخطي (linear communication). في آليته، يحتاج كل مدقق فقط لإرسال صوته إلى القائد الحالي، ثم يقوم القائد بتجميع هذه الأصوات وإصدار شهادة الكواروم (QC، شهادة الأغلبية القانونية).
هذا QC في جوهره هو توقيع جماعي، يثبت للشبكة بأكملها: "توافق غالبية العقد على هذا الاقتراح."
بالمقارنة ، فإن نمط الاتصال في PBFT هو "بث جماعي" حيث يتحدث الجميع في المجموعة ، وكان المشهد فوضويًا للغاية. بينما نمط HotStuff يشبه "شخص واحد يجمع ، حزمة واحدة في كل مرة" ، بغض النظر عن عدد الأشخاص في الشبكة ، لا يزال بإمكانه الحفاظ على التشغيل الفعال.
تظهر الصورة أعلاه مقارنة بين هيكل الاتصال الموزع لـ HotStuff ونموذج الربط الشبكي الكامل لـ PBFT.
المصدر:
بصرف النظر عن الاتصالات الخطية، يمكن أيضًا ترقية HotStuff إلى إصدار متسلسل (pipelined HotStuff) لتحسين الكفاءة.
في HotStuff الأصلي، يقوم نفس المدقق بدور القائد لعدة جولات متتالية حتى يتم تأكيد كتلة كاملة. هذه العملية هي "جولة واحدة لمعالجة كتلة واحدة"، حيث يتم التركيز بالكامل على دفع الحالية.
وفي خط الأنابيب HotStuff، أصبحت الآلية أكثر مرونة: في كل جولة يتم اختيار قائد جديد، ومهمة كل قائد لها اثنان:
في نفس الوقت، يتم تجميع تصويت الجولة السابقة في شهادة إجماع (QC) وإرسالها إلى الشبكة بأكملها؛
تقديم كتلة جديدة وبدء الجولة التالية.
بمعنى آخر، لم يعد الأمر "تأكيد واحد ثم معالجة التالي"، بل يشبه خط الإنتاج، حيث يتولى قادة مختلفون مسؤولية كل مرحلة بالتناوب. الشخص السابق يقترح كتلة، والشخص التالي يؤكدها ويستمر في اقتراح كتل جديدة، ويستمر التوافق على السلسلة كما لو كان سباق تتابع.
هذا هو مصدر تشبيهه "خط التجميع": الكتلة الحالية لا تزال تمر بعملية التأكيد، والكتلة التالية قيد التحضير، مما يزيد من الكفاءة من خلال إجراء عدة خطوات بشكل متوازي.
لتلخيص الأمر، فإن بروتوكولات مثل HotStuff قد حققت تحسينات كبيرة مقارنة بـ BFT التقليدي في بعدين.
أولاً، الاتصال أخف وزناً، حيث يحتاج كل مدقق فقط للتواصل مع القائد؛
ثانياً، كفاءة المعالجة أعلى، حيث يمكن أن تتم عمليات تأكيد الكتل المتعددة بشكل متزامن.
هذا جعل HotStuff نموذج تصميم للعديد من آليات إجماع blockchain الحديثة القائمة على إثبات الحصة (PoS). ولكن كما هو الحال في كل شيء، هناك إيجابيات وسلبيات - على الرغم من أن الهيكل المتسلسل قوي من حيث الأداء، إلا أنه أدخل بهدوء مخاطر هيكلية يصعب اكتشافها.
الآن دعونا نتحدث بعمق عن هذه المسألة الأساسية: التفريع الذيل (Tail Forking).
مشكلة تفرع الذيل (Tail-Forking)
على الرغم من أن HotStuff - وخاصة إصدارها المتسلسل - قد حل مشكلة قابلية توسيع بروتوكول الإجماع، إلا أنها قدمت أيضًا بعض التحديات الجديدة. وأهمها، والتي يسهل تجاهلها، هي مشكلة "تفرع الذيل" (Tail Forking).
ما هو انقسام الذيل؟ يمكن فهمه ببساطة على أنه: يحتوي blockchain على (reorg) غير متوقع لإعادة تنظيم الكتلة في "نهاية السلسلة".
بشكل أكثر تحديدًا، هناك كتلة تعتبر صالحة، وقد تم نشرها بنجاح إلى معظم المدققين، وقد حصلت على ما يكفي من دعم التصويت، ومن المفترض أن يتم تأكيدها وكتابتها في السلسلة الرئيسية. ولكن في النهاية، تم "تجاوزها"، وتم التخلي عنها (يتيمًا)، وحل محلها كتلة جديدة في نفس الارتفاع.
هذه ليست خطأ، وليست هجومًا، بل بسبب تصميم البروتوكول نفسه، توجد إمكانية "سقوط السلسلة". هل يبدو هذا غير عادل قليلاً؟ إذن، كيف يحدث هذا بالضبط؟
لقد قلنا سابقًا أن كل قائد في خط الإنتاج HotStuff لديه مهمتان:
A. اقتراح كتلة جديدة (مثل Bₙ₊₁)
B. لجمع الأصوات لكتلة القائد السابق، توليد QC (مثل إكمال التأكيد النهائي لـ Bₙ)
هذان المهمتان متوازيتان، يتبادلان التتابع. لكن المشكلة تكمن هنا.
على سبيل المثال: لنفترض أن أليس هي القائدة، وقد قدمت كتلة Bₙ عند الارتفاع n، وقد حصلت هذه الكتلة على تصويت أغلبية ساحقة، وقد "كادت أن تُؤكَّد".
بعد ذلك، يجب أن يتولى بوب القيادة، ويواصل دفع الكتلة التالية من السلسلة Bₙ₊₁، كما ينبغي عليه تضمين QC (إثبات الأغلبية القانونية) لـ Bₙ في اقتراحه، لإتمام التأكيد النهائي لـ Bₙ.
لكن إذا كان بوب غير متصل في ذلك الوقت، أو تعمد عدم تقديم QC لـ Bₙ، فستكون هناك مشكلة.
لأنه لم يكن هناك من يقوم بإكمال QC وتغليف كتلة Alice، لم تتمكن سجلات تصويت Bₙ من الانتشار، وبالتالي تم "معالجة" هذه الكتلة التي كان من المفترض أن يتم تأكيدها، وتم تجاهلها في النهاية من قبل الشبكة بأكملها.
هذه هي جوهر الانقسام النهائي: يتم تخطي كتلة القائد السابق بسبب إهمال أو سوء نية القائد التالي.
لماذا يكون الانقسام في النهاية شديدًا؟
تتركز مشكلة تشعب الذيل بشكل رئيسي على جانبين: 1) تم تدمير آلية الحوافز، 2) تم تهديد نشاط النظام.
أولاً، تم ابتلاع المكافأة:
إذا تم التخلي عن كتلة معينة، فلن يحصل قائدها على أي مكافأة. سواء كانت مكافأة الكتلة أو رسوم المعاملات. على سبيل المثال، إذا قدمت أليس كتلة شرعية وحصلت على دعم تصويت الأغلبية الساحقة، ولكن بسبب خطأ بوب أو تصرف خبيث، لم يتم تأكيد هذه الكتلة، فلن تحصل أليس في النهاية على أي شيء. سيؤدي هذا إلى هيكل حوافز خاطئ: يمكن للعقدة الخبيثة مثل بوب أن تقطع مصدر مكافآتهم عن طريق تخطي كتل خصومهم. لا تتطلب هذه السلوكيات هجمات تقنية، بل تحتاج فقط إلى عدم التعاون عن عمد، مما يضعف عائدات المنافسين. إذا حدثت هذه الأمور بشكل متكرر، بمرور الوقت، ستؤدي إلى انخفاض مشاركة النظام بالكامل وموضوعيته، بل وقد تحفز التآمر بين العقد.
ثانياً، اتساع مساحة هجمات MEV:
تسبب الانقسام في النهاية في مشكلة أكثر خفاءً ولكنها خطيرة: زادت مساحة التلاعب الخبيث بـ MEV (القيمة القابلة للاستخراج القصوى). على سبيل المثال: لنفترض أن كتلة أليس تحتوي على صفقة تحكيم ذات قيمة عالية. إذا أراد بوب إحداث مشكلة، يمكنه التواطؤ مع القائد التالي كارول، عمداً بعدم نشر كتلة أليس. ثم يقوم كارول بإعادة بناء كتلة جديدة بنفس الارتفاع، و"يأخذ" صفقة التحكيم الأصلية لأليس - مما يحول أرباح MEV إلى أرباحه الخاصة. هذه الممارسة "إعادة ترتيب السلسلة + التواطؤ"، تبدو ظاهرياً مثل إنتاج الكتل وفقاً للقواعد، لكنها في الواقع عملية نهب مصممة بعناية. والأسوأ من ذلك، أنها ستغري القادة بإنشاء "علاقات تآمرية"، مما يجعل تأكيد الكتل لعبة توزيع مصالح بدلاً من خدمة عامة.
ثالثًا، تدمير ضمانات الحسم النهائي، مما يؤثر على تجربة المستخدم:
بالمقارنة مع بروتوكولات مثل ناكاموتو، فإن إحدى المزايا الكبيرة لـ BFT هي النهاية الحتمية: بمجرد أن يتم تقديم الكتلة، لا يمكن التراجع عنها. لكن الانقسام النهائي يضر بهذه الضمانة، خاصةً في تلك الكتل التي "تم الحصول على التصويت ولكن لم يتم تأكيدها رسمياً بعد". بعض التطبيقات ذات معدل النقل العالي غالبًا ما تأمل في القدرة على قراءة البيانات فور مرور تصويت الكتلة لتقليل التأخير، وإذا تم إهمال تلك الكتلة فجأة، فقد يؤدي ذلك إلى تراجع حالة المستخدم - على سبيل المثال، عدم تطابق رصيد الحساب، واختفاء تداولات الرافعة المالية التي تم الانتهاء منها للتو، وإعادة تعيين حالة اللعبة بشكل مفاجئ.
رابعًا، قد يؤدي إلى حدوث فشل متسلسل:
بشكل عام، قد يؤدي الانقسام في نهاية السلسلة إلى تأخير تأكيد كتلة واحدة فقط، ولا يعتبر التأثير كبيراً. ولكن في بعض السيناريوهات الحدية، إذا اختار عدد من القادة المتتاليين تخطي الكتلة السابقة، فقد يتعطل النظام، حيث لا يرغب أحد في "تحمل" الكتلة السابقة. وعندها تتوقف سلسلة الكتل حتى يظهر أخيراً "قائد مستعد لتحمل المسؤولية"، وعندها فقط ستستمر الشبكة في التقدم.
على الرغم من أن هناك بعض الحلول السابقة، مثل آلية تجنب الفروع النهائية التي اقترحها بروتوكول BeeGees، إلا أنها غالبًا ما تتطلب التضحية بالأداء، مثل إعادة إدخال تعقيد الاتصال الثانوي، مما يجعل الأمر غير مجدٍ.
ما هو موناد بفت؟
MonadBFT هو بروتوكول إجماع من الجيل الجديد مصمم خصيصًا لحل مشكلة الفروع النهائية. تكمن قوته في أنه أثناء معالجة المخاطر الهيكلية، لم يضحِ بمزايا الأداء التي توفرها تقنية HotStuff المتدفقة. بعبارة أخرى، فإن MonadBFT ليس إعادة بناء كاملة، بل هو تحسين مستمر مبني على الإطار الأساسي لـ HotStuff. يحتفظ بثلاث ميزات رئيسية:
تبادل القادة (rotating leader): يتم اختيار قائد جديد في كل جولة لدفع السلسلة للأمام؛
الالتزامات المتسلسلة (pipelined commits): يمكن أن تتداخل عمليات تأكيد الكتل المتعددة.
3）الاتصالات الخطية (linear messaging): يحتاج كل مدقق فقط إلى التواصل مع القائد، مما يوفر الكثير من النفقات الشبكية.
لكن الاعتماد فقط على هذه النقاط الثلاث ليس آمناً بما فيه الكفاية. لسد الثغرة الهيكلية التي تنشأ من انقسام النهاية، أضاف MonadBFT مجموعتين من الآليات الرئيسية:
آلية إعادة الاقتراح الإلزامية (Re-Proposal)
2）شهادة عدم التأييد (NEC, No-Endorsement Certificate)
آلية إعادة الاقتراح (Re-Proposal)
في بروتوكول BFT، يتم تقسيم الوقت إلى جولات (تسمى view)، حيث يتولى قائد واحد في كل جولة مسؤولية اقتراح كتل جديدة. إذا فشل القائد (على سبيل المثال، لم يقم باقتراح الكتلة في الوقت المحدد، أو كانت الاقتراحات غير صالحة)، فسيتحول النظام إلى الجولة التالية ويختار قائدًا جديدًا.
أضاف MonadBFT آلية لضمان أنه خلال عملية تبديل العرض، لن تفقد أي كتلة تم تقديمها بأمان بسبب تبديل القائد.
عندما يتعطل القائد الحالي للدورة، يقوم المدقق بإرسال رسالة تغيير عرض موقعة (view change) تشير إلى أن الدورة الحالية قد تجاوزت الوقت المحدد.
خصوصاً، لا تشير هذه الرسالة إلى "انتهت المهلة" فحسب، بل يجب أن تحتوي أيضاً على معلومات عن الكتلة التي صوت عليها المدقق في المرة الأخيرة، مما يعني: "لم أستلم اقتراحاً قانونياً، وهذه هي آخر كتلة أراها حالياً."
ستجمع مجموعة من القادة الجدد هذه الرسائل المتجاوزة من عدد كبير من المدققين (2f+1) وستقوم بدمجها في شهادة تجاوز (Timeout Certificate, TC). تمثل هذه الشهادة: عندما يفشل الدور السابق، يكون هناك صورة موحدة من الشبكة عن "كتلة رأس السلسلة". سيختار القائد الجديد الكتلة ذات أعلى ارتفاع (أو أحدث رقم عرض) والمعروفة باسم high_tip.
متطلبات MonadBFT: يجب أن تتضمن اقتراح الزعيم الجديد TC قانونيًا، ويجب إعادة اقتراح أعلى كتلة معلقة في TC، مما يمنح هذه الكتلة فرصة أخرى للتأكيد.
لماذا؟ كما ذكرنا سابقًا: لا نريد أن يختفي كتلة قريبة من التأكيد.
على سبيل المثال: افترض أن أليس هي القائدة في العرض 5، وقد اقترحت كتلة صالحة وحصلت على تصويت الأغلبية. بعد ذلك، كان القائد في العرض 6، بوب، غير متصل بالإنترنت، ولم يستطع دفع عملية السلسلة. عندما تولت كارول القيادة في العرض 7، وفقًا لقواعد MonadBFT، يجب عليها تضمين TC وإعادة اقتراح كتلة أليس. وبهذه الطريقة، لن تذهب جهود أليس الصادقة سدى.
إذا لم يكن لدى كارول كتلة أليس، يمكنها الطلب من عقد أخرى. يمكن للعقد أن:
توفير هذه القطعة من الكتلة، أو
إرجاع رسالة "بدون تأييد" (No-Endorsement, NE) موقعة، تشير إلى أنني لا أملك هذه الكتلة (سيتم شرح آليتها لاحقًا). (يمكن أن تختار ما يصل إلى f من العقد البيزنطية تجاهل الطلب وعدم الرد.)
بمجرد أن تعيد كارول اقتراح كتلة أليس، ستحصل على فرصة اقتراح إضافية، مما يضمن ألا تتعرض "للتبعات" بسبب فشل القائد السابق.
الغرض من آلية إعادة الاقتراح هذه واضح: ضمان أن تقدم السلسلة يكون عادلاً، وأن أي عمل فعال لن يتم التخلي عنه بهدوء بسبب سوء الحظ أو تدخل شخص ما.
شهادة عدم التأييد (NEC)
استمرارًا على المثال السابق: بعد انتهاء جولة بوب، طلبت كارول من باقي المدققين تقديم كتلة high_tip (أي كتلة أليس). في هذه الحالة، سيستجيب على الأقل 2f+1 من المدققين:
إما تقديم كتلة أليس
إما إرسال رسالة NE موقعة، تعبر عن عدم استلامي لكتلة Alice
بمجرد أن تتلقى كارول كتلة أليس، يجب عليها إعادة اقتراحها وفقًا للقواعد. يمكن لكارول فقط تخطي تلك الكتلة واقتراح واحدة جديدة إذا قام ما لا يقل عن f+1 من المدققين بالتوقيع على رسالة NE.
لماذا f+1؟ في نظام BFT يتكون من 3f+1 من المدققين، هناك فقط f واحد محتمل للغش. إذا كانت كتلة أليس قد حصلت بالفعل على تصويت الأغلبية الساحقة، فهذا يعني أن هناك على الأقل 2f+1 من العقد الصادقة قد تلقتها.
لذلك، إذا ادعت كارول "لا أستطيع الحصول على كتلة أليس"، فيجب عليها تقديم f+1 توقيع من المدققين لإثبات أن هؤلاء الأشخاص لم يتلقوا أي شيء. وهذا يشكل شهادة عدم التأييد (No-Endorsement Certificate, NEC).
NEC هو القائد "الإعفاء": إنه دليل يمكن التحقق منه، يشير إلى أن الكتلة السابقة لم تكن جاهزة بعد للتأكيد، وأنه لم يتم تخطيها عن عمد، بل تم "التخلي" عنها بطريقة منطقية.
إعادة الاقتراح + شهادة عدم التأييد = حل انقسام الذيل
يؤسس MonadBFT مجموعة صارمة وواضحة من قواعد معالجة رأس السلسلة من خلال إدخال آلية إعادة الاقتراح (Re-Proposal) وشهادة عدم التأييد (NEC, No-Endorsement Certificate).
إما أن يتم الانتهاء من تقديم الكتلة "المؤكدة تقريبًا".
يجب تقديم أدلة كافية لإثبات أن الكتلة لا تستوفي شروط التأكيد.
إلا أنه لا يُسمح بتخطي أو استبدال الكتلة السابقة.
تضمن هذه الآلية: أنه لن يتم التخلي عن أي كتلة حصلت على أغلبية قانونية بسبب خطأ من القائد أو التهرب المتعمد.
تم معالجة المخاطر الهيكلية الناتجة عن التقسيم في النهاية بشكل منهجي، حيث يمكن للبروتوكول أن يفرض قيودًا واضحة على سلوك التخطي غير السليم.
إذا حاول أحد القادة تخطي الكتلة السابقة دون سبب، ولكنه فشل في تقديم دليل NEC، فسيتعرف البروتوكول على هذا التصرف ويرفضه على الفور. سُيعتبر التصرف المتعلق بالقفز دون دليل تشفيري غير قانوني، ولن يحصل على دعم إجماع الشبكة.
من الناحية الاقتصادية، يوفر هذا التصميم حماية واضحة للمتحققين:
طالما أن الكتلة قد تم تقديمها بصدق وحصلت على دعم التصويت، فلن يتم حرمان مكافأتها بسبب فشل في المراحل التالية؛
حتى في الحالات القصوى، مثلما إذا قام أحد العقد عمداً بتخطي دورة اقتراحه، في محاولة لمساعدة الآخرين على الاستيلاء على MEV للكتلة السابقة، فإن البروتوكول سيجبر القادة اللاحقين على إعادة اقتراح الكتلة الأصلية كأولوية، مما يمنع المهاجمين من تحقيق مكاسب اقتصادية من خلال تخطي العملية.
الأهم من ذلك، أن MonadBFT لم تضحِ بأداء البروتوكول من أجل تعزيز الأمان.
بعض التصاميم السابقة للتعامل مع تفرع النهاية (مثل بروتوكول BeeGees) على الرغم من أنها تمتلك بعض القدرات الوقائية، إلا أنها غالبًا ما تعتمد على تعقيد الاتصال العالي (n²) أو تفعيل عمليات الاتصال المتكررة في كل جولة، مما يزيد بشكل ملحوظ من عبء النظام في الممارسة العملية.
استراتيجية تصميم MonadBFT أكثر دقة:
لا يتم بدء اتصالات إضافية (مثل رسائل المهلة، إعادة اقتراح الكتل) إلا عند فشل العرض أو وجود استثناء. يظل البروتوكول يعمل بحالة خفيفة وفعالة على المسار العادي للأمناء الصادقين الذين يواصلون إنشاء الكتل.
هذا التوازن الديناميكي بين الأداء والأمان هو أحد المزايا الأساسية لـ MonadBFT مقارنةً بالبروتوكولات السابقة.
ملخص
تستعرض هذه المقالة الآلية الأساسية لتوافق PBFT التقليدي، وتستعرض مسار تطوير بروتوكول HotStuff، وتشرح بشكل خاص كيف أن MonadBFT يحل مشكلة تفرع الجزء الأخير المتأصل في HotStuff من حيث هيكل طبقة البروتوكول.
سوف يؤدي التشعب في النهاية إلى تشويه الحوافز الاقتصادية لمقترحي الكتل، مما يشكل تهديدًا محتملاً لنشاط الشبكة. يضمن MonadBFT من خلال تقديم آلية إعادة الاقتراح وشهادات بدون تأييد (NEC) أن أي كتلة يقترحها قادة أمناء وتحصل على تصويت أغلبية قانونية لن يتم التخلي عنها أو تخطيها.
في المقالة التالية، سنواصل استكشاف خاصيتين رئيسيتين أخريين من MonadBFT:
النهائية التخمينية (Speculative Finality)
2）استجابة متفائلة (Optimistic Responsiveness)
ويتم تحليل هذه الآليات بشكل أكبر لمعرفة معناها الفعلي بالنسبة للمتحققين والمطورين.
يتبع.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
MonadBFT: إعادة تعريف أمان إجماع البلوكتشين، وداعاً لمخاطر الفرك في النهاية
المؤلف: michaellwy
يتمثل جوهر blockchain في تحقيق نوع من الإجماع العالمي الصارم: أي أنه بغض النظر عن مكان توزيع عقد الشبكة، في أي بلد أو منطقة زمنية، يجب على جميع المشاركين في النهاية التوصل إلى توافق حول مجموعة من النتائج الموضوعية.
ومع ذلك ، فإن الشبكة الموزعة في الواقع ليست مثالية: يتم فصل بعض العقد ، وبعض العقد تكمن ، وبعضها يخرب عمدا. في هذه الحالة ، كيف "يتحدث النظام" ويحافظ على الاتساق؟
هذه هي المشكلة التي تهدف بروتوكولات الإجماع إلى حلها. إنها في جوهرها مجموعة من القواعد التي توجه مجموعة من العقد المستقلة تمامًا، وحتى غير الموثوق بها تمامًا، حول كيفية التوصل إلى قرار موحد بشأن ترتيب ومحتوى كل عملية.
بمجرد إنشاء هذا "الإجماع الصارم" ، تفتح blockchain عددا من الميزات الرئيسية ، مثل حماية الملكية الرقمية ، والنماذج النقدية المقاومة للتضخم ، وهياكل التعاون الاجتماعي القابلة للتطوير. لكن الفرضية هي أن بروتوكول الإجماع نفسه يجب أن يضمن أساسيين في نفس الوقت:
لا يمكن أن يتم تأكيد كتلتين تتعارضان مع بعضهما.
يجب أن يستمر الشبكة في التقدم، ولا يمكن أن تتعطل أو تتوقف.
مونادBFT هو أحدث تقدم تقني تم إحرازه في هذا الاتجاه.
نظرة عامة موجزة على تطور بروتوكولات الإجماع
لقد تم البحث في مجال آليات الإجماع منذ عقود. كانت أول مجموعة من البروتوكولات مثل PBFT (تحمل الأخطاء البيزنطية العملية) قادرة بالفعل على معالجة حالة واقعية للغاية: حتى لو كان هناك عدد من العقد في الشبكة تفقد الاتصال أو تتصرف بشكل ضار أو تتحدث هراء، طالما أنها لا تتجاوز ثلث العدد الإجمالي، يمكن للنظام أن يتوصل إلى توافق.
تم تصميم هذه البروتوكولات المبكرة بطريقة "تقليدية": في كل جولة يتم اختيار قائد واحد، الذي يقوم بإطلاق الاقتراح، ومن ثم يقوم باقي المدققين بالتصويت على هذا الاقتراح في جولات متعددة، لتأكيد تسلسل المعاملات خطوة بخطوة.
تمر عملية التصويت عادة بعدة مراحل ، مثل الإعداد المسبق والإعداد والالتزام والرد. في كل مرحلة ، يتواصل جميع المدققين مع بعضهم البعض. بمعنى آخر ، يجب على الجميع إخبار الجميع ، وحجم الرسائل ينمو بشكل متفجر في "شبكة".
تعقيد هيكل الاتصال هذا هو n² - بمعنى أنه إذا كان هناك 100 مدقق في الشبكة، فقد يتعين إرسال ما يقرب من 10,000 رسالة في كل جولة من التوافق.
هذه ليست مشكلة كبيرة في الشبكات الصغيرة، ولكن بمجرد أن يزيد عدد المدققين، فإن عبء التواصل في النظام سيصبح سريعًا غير قابل للتحمل، وستتدهور الكفاءة بشكل مباشر.
مصدر المعلومات:
هيكل الاتصال الثانوي "يجب على كل شخص أن يتواصل مع كل شخص" غير فعال للغاية. على سبيل المثال، في شبكة بها 100 مدقق، قد تحتاج كل دورة توافق إلى معالجة آلاف الرسائل.
هذا يمكن التعامل معه في دائرة صغيرة، ولكن إذا وضع في شبكة مفتوحة على نطاق عالمي، فإن عبء الاتصالات يصبح غير مقبول على الفور. لذا فإن بروتوكولات BFT المبكرة مثل PBFT و Tendermint تُستخدم عادةً فقط في السيناريوهات المصرح بها (شبكة مسموح بها) أو في الأنظمة التي تحتوي على عدد قليل جدًا من المدققين، حيث يمكن أن تعمل بصعوبة.
من أجل تكييف بروتوكول BFT مع بيئة سلسلة عامة بدون إذن ، بدأت بعض تصميمات الجيل التالي في التحرك نحو طريقة اتصال أخف: يتواصل كل مدقق فقط مع القائد ، بدلا من جميع أعضاء الفريق.
هذا يقلل من تعقيد الرسالة من n² الأصلية إلى n - مما خفف بشكل كبير من عبء النظام.
تم اقتراح بروتوكول HotStuff في عام 2018، وكان ذلك لحل مشكلة القابلية للتوسع. إن فلسفة تصميمه واضحة جدًا: استبدال عملية التصويت المعقدة لـ PBFT بهيكل اتصال أبسط يقوده القائد.
الخاصية الرئيسية لـ HotStuff هي ما يسمى بالتواصل الخطي (linear communication). في آليته، يحتاج كل مدقق فقط لإرسال صوته إلى القائد الحالي، ثم يقوم القائد بتجميع هذه الأصوات وإصدار شهادة الكواروم (QC، شهادة الأغلبية القانونية).
هذا QC في جوهره هو توقيع جماعي، يثبت للشبكة بأكملها: "توافق غالبية العقد على هذا الاقتراح."
بالمقارنة ، فإن نمط الاتصال في PBFT هو "بث جماعي" حيث يتحدث الجميع في المجموعة ، وكان المشهد فوضويًا للغاية. بينما نمط HotStuff يشبه "شخص واحد يجمع ، حزمة واحدة في كل مرة" ، بغض النظر عن عدد الأشخاص في الشبكة ، لا يزال بإمكانه الحفاظ على التشغيل الفعال.
تظهر الصورة أعلاه مقارنة بين هيكل الاتصال الموزع لـ HotStuff ونموذج الربط الشبكي الكامل لـ PBFT.
المصدر:
بصرف النظر عن الاتصالات الخطية، يمكن أيضًا ترقية HotStuff إلى إصدار متسلسل (pipelined HotStuff) لتحسين الكفاءة.
في HotStuff الأصلي، يقوم نفس المدقق بدور القائد لعدة جولات متتالية حتى يتم تأكيد كتلة كاملة. هذه العملية هي "جولة واحدة لمعالجة كتلة واحدة"، حيث يتم التركيز بالكامل على دفع الحالية.
وفي خط الأنابيب HotStuff، أصبحت الآلية أكثر مرونة: في كل جولة يتم اختيار قائد جديد، ومهمة كل قائد لها اثنان:
في نفس الوقت، يتم تجميع تصويت الجولة السابقة في شهادة إجماع (QC) وإرسالها إلى الشبكة بأكملها؛
تقديم كتلة جديدة وبدء الجولة التالية.
بمعنى آخر، لم يعد الأمر "تأكيد واحد ثم معالجة التالي"، بل يشبه خط الإنتاج، حيث يتولى قادة مختلفون مسؤولية كل مرحلة بالتناوب. الشخص السابق يقترح كتلة، والشخص التالي يؤكدها ويستمر في اقتراح كتل جديدة، ويستمر التوافق على السلسلة كما لو كان سباق تتابع.
هذا هو مصدر تشبيهه "خط التجميع": الكتلة الحالية لا تزال تمر بعملية التأكيد، والكتلة التالية قيد التحضير، مما يزيد من الكفاءة من خلال إجراء عدة خطوات بشكل متوازي.
لتلخيص الأمر، فإن بروتوكولات مثل HotStuff قد حققت تحسينات كبيرة مقارنة بـ BFT التقليدي في بعدين.
أولاً، الاتصال أخف وزناً، حيث يحتاج كل مدقق فقط للتواصل مع القائد؛
ثانياً، كفاءة المعالجة أعلى، حيث يمكن أن تتم عمليات تأكيد الكتل المتعددة بشكل متزامن.
هذا جعل HotStuff نموذج تصميم للعديد من آليات إجماع blockchain الحديثة القائمة على إثبات الحصة (PoS). ولكن كما هو الحال في كل شيء، هناك إيجابيات وسلبيات - على الرغم من أن الهيكل المتسلسل قوي من حيث الأداء، إلا أنه أدخل بهدوء مخاطر هيكلية يصعب اكتشافها.
الآن دعونا نتحدث بعمق عن هذه المسألة الأساسية: التفريع الذيل (Tail Forking).
مشكلة تفرع الذيل (Tail-Forking)
على الرغم من أن HotStuff - وخاصة إصدارها المتسلسل - قد حل مشكلة قابلية توسيع بروتوكول الإجماع، إلا أنها قدمت أيضًا بعض التحديات الجديدة. وأهمها، والتي يسهل تجاهلها، هي مشكلة "تفرع الذيل" (Tail Forking).
ما هو انقسام الذيل؟ يمكن فهمه ببساطة على أنه: يحتوي blockchain على (reorg) غير متوقع لإعادة تنظيم الكتلة في "نهاية السلسلة".
بشكل أكثر تحديدًا، هناك كتلة تعتبر صالحة، وقد تم نشرها بنجاح إلى معظم المدققين، وقد حصلت على ما يكفي من دعم التصويت، ومن المفترض أن يتم تأكيدها وكتابتها في السلسلة الرئيسية. ولكن في النهاية، تم "تجاوزها"، وتم التخلي عنها (يتيمًا)، وحل محلها كتلة جديدة في نفس الارتفاع.
هذه ليست خطأ، وليست هجومًا، بل بسبب تصميم البروتوكول نفسه، توجد إمكانية "سقوط السلسلة". هل يبدو هذا غير عادل قليلاً؟ إذن، كيف يحدث هذا بالضبط؟
لقد قلنا سابقًا أن كل قائد في خط الإنتاج HotStuff لديه مهمتان:
A. اقتراح كتلة جديدة (مثل Bₙ₊₁)
B. لجمع الأصوات لكتلة القائد السابق، توليد QC (مثل إكمال التأكيد النهائي لـ Bₙ)
هذان المهمتان متوازيتان، يتبادلان التتابع. لكن المشكلة تكمن هنا.
على سبيل المثال: لنفترض أن أليس هي القائدة، وقد قدمت كتلة Bₙ عند الارتفاع n، وقد حصلت هذه الكتلة على تصويت أغلبية ساحقة، وقد "كادت أن تُؤكَّد".
بعد ذلك، يجب أن يتولى بوب القيادة، ويواصل دفع الكتلة التالية من السلسلة Bₙ₊₁، كما ينبغي عليه تضمين QC (إثبات الأغلبية القانونية) لـ Bₙ في اقتراحه، لإتمام التأكيد النهائي لـ Bₙ.
لكن إذا كان بوب غير متصل في ذلك الوقت، أو تعمد عدم تقديم QC لـ Bₙ، فستكون هناك مشكلة.
لأنه لم يكن هناك من يقوم بإكمال QC وتغليف كتلة Alice، لم تتمكن سجلات تصويت Bₙ من الانتشار، وبالتالي تم "معالجة" هذه الكتلة التي كان من المفترض أن يتم تأكيدها، وتم تجاهلها في النهاية من قبل الشبكة بأكملها.
هذه هي جوهر الانقسام النهائي: يتم تخطي كتلة القائد السابق بسبب إهمال أو سوء نية القائد التالي.
لماذا يكون الانقسام في النهاية شديدًا؟
تتركز مشكلة تشعب الذيل بشكل رئيسي على جانبين: 1) تم تدمير آلية الحوافز، 2) تم تهديد نشاط النظام.
أولاً، تم ابتلاع المكافأة:
إذا تم التخلي عن كتلة معينة، فلن يحصل قائدها على أي مكافأة. سواء كانت مكافأة الكتلة أو رسوم المعاملات. على سبيل المثال، إذا قدمت أليس كتلة شرعية وحصلت على دعم تصويت الأغلبية الساحقة، ولكن بسبب خطأ بوب أو تصرف خبيث، لم يتم تأكيد هذه الكتلة، فلن تحصل أليس في النهاية على أي شيء. سيؤدي هذا إلى هيكل حوافز خاطئ: يمكن للعقدة الخبيثة مثل بوب أن تقطع مصدر مكافآتهم عن طريق تخطي كتل خصومهم. لا تتطلب هذه السلوكيات هجمات تقنية، بل تحتاج فقط إلى عدم التعاون عن عمد، مما يضعف عائدات المنافسين. إذا حدثت هذه الأمور بشكل متكرر، بمرور الوقت، ستؤدي إلى انخفاض مشاركة النظام بالكامل وموضوعيته، بل وقد تحفز التآمر بين العقد.
ثانياً، اتساع مساحة هجمات MEV:
تسبب الانقسام في النهاية في مشكلة أكثر خفاءً ولكنها خطيرة: زادت مساحة التلاعب الخبيث بـ MEV (القيمة القابلة للاستخراج القصوى). على سبيل المثال: لنفترض أن كتلة أليس تحتوي على صفقة تحكيم ذات قيمة عالية. إذا أراد بوب إحداث مشكلة، يمكنه التواطؤ مع القائد التالي كارول، عمداً بعدم نشر كتلة أليس. ثم يقوم كارول بإعادة بناء كتلة جديدة بنفس الارتفاع، و"يأخذ" صفقة التحكيم الأصلية لأليس - مما يحول أرباح MEV إلى أرباحه الخاصة. هذه الممارسة "إعادة ترتيب السلسلة + التواطؤ"، تبدو ظاهرياً مثل إنتاج الكتل وفقاً للقواعد، لكنها في الواقع عملية نهب مصممة بعناية. والأسوأ من ذلك، أنها ستغري القادة بإنشاء "علاقات تآمرية"، مما يجعل تأكيد الكتل لعبة توزيع مصالح بدلاً من خدمة عامة.
ثالثًا، تدمير ضمانات الحسم النهائي، مما يؤثر على تجربة المستخدم:
بالمقارنة مع بروتوكولات مثل ناكاموتو، فإن إحدى المزايا الكبيرة لـ BFT هي النهاية الحتمية: بمجرد أن يتم تقديم الكتلة، لا يمكن التراجع عنها. لكن الانقسام النهائي يضر بهذه الضمانة، خاصةً في تلك الكتل التي "تم الحصول على التصويت ولكن لم يتم تأكيدها رسمياً بعد". بعض التطبيقات ذات معدل النقل العالي غالبًا ما تأمل في القدرة على قراءة البيانات فور مرور تصويت الكتلة لتقليل التأخير، وإذا تم إهمال تلك الكتلة فجأة، فقد يؤدي ذلك إلى تراجع حالة المستخدم - على سبيل المثال، عدم تطابق رصيد الحساب، واختفاء تداولات الرافعة المالية التي تم الانتهاء منها للتو، وإعادة تعيين حالة اللعبة بشكل مفاجئ.
رابعًا، قد يؤدي إلى حدوث فشل متسلسل:
بشكل عام، قد يؤدي الانقسام في نهاية السلسلة إلى تأخير تأكيد كتلة واحدة فقط، ولا يعتبر التأثير كبيراً. ولكن في بعض السيناريوهات الحدية، إذا اختار عدد من القادة المتتاليين تخطي الكتلة السابقة، فقد يتعطل النظام، حيث لا يرغب أحد في "تحمل" الكتلة السابقة. وعندها تتوقف سلسلة الكتل حتى يظهر أخيراً "قائد مستعد لتحمل المسؤولية"، وعندها فقط ستستمر الشبكة في التقدم.
على الرغم من أن هناك بعض الحلول السابقة، مثل آلية تجنب الفروع النهائية التي اقترحها بروتوكول BeeGees، إلا أنها غالبًا ما تتطلب التضحية بالأداء، مثل إعادة إدخال تعقيد الاتصال الثانوي، مما يجعل الأمر غير مجدٍ.
ما هو موناد بفت؟
MonadBFT هو بروتوكول إجماع من الجيل الجديد مصمم خصيصًا لحل مشكلة الفروع النهائية. تكمن قوته في أنه أثناء معالجة المخاطر الهيكلية، لم يضحِ بمزايا الأداء التي توفرها تقنية HotStuff المتدفقة. بعبارة أخرى، فإن MonadBFT ليس إعادة بناء كاملة، بل هو تحسين مستمر مبني على الإطار الأساسي لـ HotStuff. يحتفظ بثلاث ميزات رئيسية:
تبادل القادة (rotating leader): يتم اختيار قائد جديد في كل جولة لدفع السلسلة للأمام؛
الالتزامات المتسلسلة (pipelined commits): يمكن أن تتداخل عمليات تأكيد الكتل المتعددة.
3）الاتصالات الخطية (linear messaging): يحتاج كل مدقق فقط إلى التواصل مع القائد، مما يوفر الكثير من النفقات الشبكية.
لكن الاعتماد فقط على هذه النقاط الثلاث ليس آمناً بما فيه الكفاية. لسد الثغرة الهيكلية التي تنشأ من انقسام النهاية، أضاف MonadBFT مجموعتين من الآليات الرئيسية:
2）شهادة عدم التأييد (NEC, No-Endorsement Certificate)
آلية إعادة الاقتراح (Re-Proposal)
في بروتوكول BFT، يتم تقسيم الوقت إلى جولات (تسمى view)، حيث يتولى قائد واحد في كل جولة مسؤولية اقتراح كتل جديدة. إذا فشل القائد (على سبيل المثال، لم يقم باقتراح الكتلة في الوقت المحدد، أو كانت الاقتراحات غير صالحة)، فسيتحول النظام إلى الجولة التالية ويختار قائدًا جديدًا.
أضاف MonadBFT آلية لضمان أنه خلال عملية تبديل العرض، لن تفقد أي كتلة تم تقديمها بأمان بسبب تبديل القائد.
عندما يتعطل القائد الحالي للدورة، يقوم المدقق بإرسال رسالة تغيير عرض موقعة (view change) تشير إلى أن الدورة الحالية قد تجاوزت الوقت المحدد.
خصوصاً، لا تشير هذه الرسالة إلى "انتهت المهلة" فحسب، بل يجب أن تحتوي أيضاً على معلومات عن الكتلة التي صوت عليها المدقق في المرة الأخيرة، مما يعني: "لم أستلم اقتراحاً قانونياً، وهذه هي آخر كتلة أراها حالياً."
ستجمع مجموعة من القادة الجدد هذه الرسائل المتجاوزة من عدد كبير من المدققين (2f+1) وستقوم بدمجها في شهادة تجاوز (Timeout Certificate, TC). تمثل هذه الشهادة: عندما يفشل الدور السابق، يكون هناك صورة موحدة من الشبكة عن "كتلة رأس السلسلة". سيختار القائد الجديد الكتلة ذات أعلى ارتفاع (أو أحدث رقم عرض) والمعروفة باسم high_tip.
متطلبات MonadBFT: يجب أن تتضمن اقتراح الزعيم الجديد TC قانونيًا، ويجب إعادة اقتراح أعلى كتلة معلقة في TC، مما يمنح هذه الكتلة فرصة أخرى للتأكيد.
لماذا؟ كما ذكرنا سابقًا: لا نريد أن يختفي كتلة قريبة من التأكيد.
على سبيل المثال: افترض أن أليس هي القائدة في العرض 5، وقد اقترحت كتلة صالحة وحصلت على تصويت الأغلبية. بعد ذلك، كان القائد في العرض 6، بوب، غير متصل بالإنترنت، ولم يستطع دفع عملية السلسلة. عندما تولت كارول القيادة في العرض 7، وفقًا لقواعد MonadBFT، يجب عليها تضمين TC وإعادة اقتراح كتلة أليس. وبهذه الطريقة، لن تذهب جهود أليس الصادقة سدى.
إذا لم يكن لدى كارول كتلة أليس، يمكنها الطلب من عقد أخرى. يمكن للعقد أن:
توفير هذه القطعة من الكتلة، أو
إرجاع رسالة "بدون تأييد" (No-Endorsement, NE) موقعة، تشير إلى أنني لا أملك هذه الكتلة (سيتم شرح آليتها لاحقًا). (يمكن أن تختار ما يصل إلى f من العقد البيزنطية تجاهل الطلب وعدم الرد.)
بمجرد أن تعيد كارول اقتراح كتلة أليس، ستحصل على فرصة اقتراح إضافية، مما يضمن ألا تتعرض "للتبعات" بسبب فشل القائد السابق.
الغرض من آلية إعادة الاقتراح هذه واضح: ضمان أن تقدم السلسلة يكون عادلاً، وأن أي عمل فعال لن يتم التخلي عنه بهدوء بسبب سوء الحظ أو تدخل شخص ما.
شهادة عدم التأييد (NEC)
استمرارًا على المثال السابق: بعد انتهاء جولة بوب، طلبت كارول من باقي المدققين تقديم كتلة high_tip (أي كتلة أليس). في هذه الحالة، سيستجيب على الأقل 2f+1 من المدققين:
إما تقديم كتلة أليس
إما إرسال رسالة NE موقعة، تعبر عن عدم استلامي لكتلة Alice
بمجرد أن تتلقى كارول كتلة أليس، يجب عليها إعادة اقتراحها وفقًا للقواعد. يمكن لكارول فقط تخطي تلك الكتلة واقتراح واحدة جديدة إذا قام ما لا يقل عن f+1 من المدققين بالتوقيع على رسالة NE.
لماذا f+1؟ في نظام BFT يتكون من 3f+1 من المدققين، هناك فقط f واحد محتمل للغش. إذا كانت كتلة أليس قد حصلت بالفعل على تصويت الأغلبية الساحقة، فهذا يعني أن هناك على الأقل 2f+1 من العقد الصادقة قد تلقتها.
لذلك، إذا ادعت كارول "لا أستطيع الحصول على كتلة أليس"، فيجب عليها تقديم f+1 توقيع من المدققين لإثبات أن هؤلاء الأشخاص لم يتلقوا أي شيء. وهذا يشكل شهادة عدم التأييد (No-Endorsement Certificate, NEC).
NEC هو القائد "الإعفاء": إنه دليل يمكن التحقق منه، يشير إلى أن الكتلة السابقة لم تكن جاهزة بعد للتأكيد، وأنه لم يتم تخطيها عن عمد، بل تم "التخلي" عنها بطريقة منطقية.
إعادة الاقتراح + شهادة عدم التأييد = حل انقسام الذيل
يؤسس MonadBFT مجموعة صارمة وواضحة من قواعد معالجة رأس السلسلة من خلال إدخال آلية إعادة الاقتراح (Re-Proposal) وشهادة عدم التأييد (NEC, No-Endorsement Certificate).
إما أن يتم الانتهاء من تقديم الكتلة "المؤكدة تقريبًا".
يجب تقديم أدلة كافية لإثبات أن الكتلة لا تستوفي شروط التأكيد.
إلا أنه لا يُسمح بتخطي أو استبدال الكتلة السابقة.
تضمن هذه الآلية: أنه لن يتم التخلي عن أي كتلة حصلت على أغلبية قانونية بسبب خطأ من القائد أو التهرب المتعمد.
تم معالجة المخاطر الهيكلية الناتجة عن التقسيم في النهاية بشكل منهجي، حيث يمكن للبروتوكول أن يفرض قيودًا واضحة على سلوك التخطي غير السليم.
إذا حاول أحد القادة تخطي الكتلة السابقة دون سبب، ولكنه فشل في تقديم دليل NEC، فسيتعرف البروتوكول على هذا التصرف ويرفضه على الفور. سُيعتبر التصرف المتعلق بالقفز دون دليل تشفيري غير قانوني، ولن يحصل على دعم إجماع الشبكة.
من الناحية الاقتصادية، يوفر هذا التصميم حماية واضحة للمتحققين:
طالما أن الكتلة قد تم تقديمها بصدق وحصلت على دعم التصويت، فلن يتم حرمان مكافأتها بسبب فشل في المراحل التالية؛
حتى في الحالات القصوى، مثلما إذا قام أحد العقد عمداً بتخطي دورة اقتراحه، في محاولة لمساعدة الآخرين على الاستيلاء على MEV للكتلة السابقة، فإن البروتوكول سيجبر القادة اللاحقين على إعادة اقتراح الكتلة الأصلية كأولوية، مما يمنع المهاجمين من تحقيق مكاسب اقتصادية من خلال تخطي العملية.
الأهم من ذلك، أن MonadBFT لم تضحِ بأداء البروتوكول من أجل تعزيز الأمان.
بعض التصاميم السابقة للتعامل مع تفرع النهاية (مثل بروتوكول BeeGees) على الرغم من أنها تمتلك بعض القدرات الوقائية، إلا أنها غالبًا ما تعتمد على تعقيد الاتصال العالي (n²) أو تفعيل عمليات الاتصال المتكررة في كل جولة، مما يزيد بشكل ملحوظ من عبء النظام في الممارسة العملية.
استراتيجية تصميم MonadBFT أكثر دقة:
لا يتم بدء اتصالات إضافية (مثل رسائل المهلة، إعادة اقتراح الكتل) إلا عند فشل العرض أو وجود استثناء. يظل البروتوكول يعمل بحالة خفيفة وفعالة على المسار العادي للأمناء الصادقين الذين يواصلون إنشاء الكتل.
هذا التوازن الديناميكي بين الأداء والأمان هو أحد المزايا الأساسية لـ MonadBFT مقارنةً بالبروتوكولات السابقة.
ملخص
تستعرض هذه المقالة الآلية الأساسية لتوافق PBFT التقليدي، وتستعرض مسار تطوير بروتوكول HotStuff، وتشرح بشكل خاص كيف أن MonadBFT يحل مشكلة تفرع الجزء الأخير المتأصل في HotStuff من حيث هيكل طبقة البروتوكول.
سوف يؤدي التشعب في النهاية إلى تشويه الحوافز الاقتصادية لمقترحي الكتل، مما يشكل تهديدًا محتملاً لنشاط الشبكة. يضمن MonadBFT من خلال تقديم آلية إعادة الاقتراح وشهادات بدون تأييد (NEC) أن أي كتلة يقترحها قادة أمناء وتحصل على تصويت أغلبية قانونية لن يتم التخلي عنها أو تخطيها.
في المقالة التالية، سنواصل استكشاف خاصيتين رئيسيتين أخريين من MonadBFT:
2）استجابة متفائلة (Optimistic Responsiveness)
ويتم تحليل هذه الآليات بشكل أكبر لمعرفة معناها الفعلي بالنسبة للمتحققين والمطورين.
يتبع.