البلوكتشين الذي يركز على تحقيق نوع من الإجماع العالمي الصارم: بمعنى أنه، بغض النظر عن مكان توزيع عقد الشبكة، أو أي منطقة زمنية، يجب على جميع المشاركين في النهاية التوصل إلى توافق بشأن مجموعة من النتائج الموضوعية.
لكن الشبكات الموزعة في الواقع ليست مثالية: هناك عقدة تتعطل، وهناك عقدة تكذب، بل وحتى بعض الأشخاص يقومون بتخريب متعمد. في هذه الحالة، كيف يمكن للنظام أن "يتحدث بصوت واحد" ويحافظ على التوافق؟
هذه هي المشكلة التي يجب أن تحلها بروتوكولات الإجماع. إنها في جوهرها مجموعة من القواعد التي توجه مجموعة من العقد المستقلة عن بعضها البعض، وحتى غير الموثوقة تمامًا، حول كيفية التوصل إلى قرار موحد بشأن ترتيب ومحتوى كل صفقة.
وعندما يتم إنشاء هذا "الإجماع الصارم"، يمكن للبلوكتشين فتح العديد من الميزات الأساسية، مثل ضمان الملكية الرقمية، ونموذج العملة المقاوم للتضخم، وهياكل التعاون الاجتماعي القابلة للتوسع. ولكن الشرط هو أن بروتوكول الإجماع نفسه يجب أن يضمن في الوقت نفسه جانبين أساسيين:
لا يمكن أن يتم تأكيد كتلتين متعارضتين.
يجب أن يستمر الشبكة في التقدم، ولا يمكن أن تتوقف أو تتعطل.
MonadBFT هو أحدث تقدم تكنولوجي تم إحرازه في هذا الاتجاه.
لمحة عن تطور بروتوكول الإجماع
لقد تم البحث في مجال آلية الإجماع هذا لعشرات السنين. وكانت أول مجموعة من البروتوكولات، مثل PBFT (تحمل أخطاء بيزنطية العملية)، قادرة على معالجة حالة واقعية: حتى لو كانت هناك بعض العقد في الشبكة تفشل أو تتصرف بشكل خاطئ أو تتحدث بشكل غير منطقي، طالما أنها لا تتجاوز ثلث العدد الكلي، يمكن للنظام أن يصل إلى توافق.
تم تصميم هذه البروتوكولات المبكرة بطريقة "تقليدية" نسبياً: يتم اختيار قائد واحد في كل جولة، يقوم بدعوة الاقتراح، ثم يقوم باقي المدققين بالتصويت على هذا الاقتراح عبر عدة جولات، لتأكيد ترتيب المعاملات خطوة بخطوة.
عادةً ما تمر عملية التصويت بأكثر من مرحلة، مثل pre-prepare وprepare وcommit وreply. في كل مرحلة، يجب على جميع المدققين التواصل مع بعضهم البعض. بعبارة أخرى، يجب على كل شخص التحدث مع الجميع مرة واحدة، مما يؤدي إلى زيادة هائلة في حجم الرسائل بشكل "شبكي".
تعقيد هيكل الاتصال هذا هو n² - بمعنى أنه إذا كان هناك 100 من المدققين في الشبكة، فقد يحتاج كل جولة من الإجماع إلى نقل حوالي 10,000 رسالة.
هذا ليس بمشكلة كبيرة في الشبكات الصغيرة، ولكن حالما يرتفع عدد المدققين، ستصبح عبء الاتصالات في النظام سريعًا لا يُطاق، وكفاءة النظام ستتدهور مباشرة.
هذا الهيكل الثانوي من "يجب على كل شخص التواصل مع كل شخص" في الواقع غير فعال للغاية. على سبيل المثال، في شبكة بها 100 موثق، قد يحتاج كل جولة من الإجماع إلى معالجة آلاف الرسائل.
هذا يمكن التعامل معه في دائرة صغيرة، ولكن إذا تم وضعه في شبكة بلوكتشين مفتوحة على مستوى عالمي، فإن حمل الاتصالات سيصبح غير مقبول على الفور. لذلك، فإن بروتوكولات BFT المبكرة مثل PBFT وTendermint، عادة ما تُستخدم فقط في السيناريوهات المرخصة (شبكة مرخصة) أو في الأنظمة التي تحتوي على عدد قليل جداً من المدققين، لتتمكن من العمل بالكاد.
لجعل بروتوكول BFT يتكيف أيضًا مع بيئات السلاسل العامة غير المصرح بها، بدأت بعض التصميمات من الجيل الجديد تتجه نحو طرق اتصال أخف: حيث يتواصل كل مدقق فقط مع القائد، بدلاً من تبادل المعلومات بين الجميع.
هذا يقلل من تعقيد الرسالة من n² الأصلي إلى n - مما خفف بشكل كبير من عبء النظام.
بروتوكول HotStuff تم تقديمه في عام 2018، وكان ذلك لحل مشكلة القابلية للتوسع هذه. فكرة تصميمه واضحة جدًا: استبدال هيكل الاتصال المعقد لعملية التصويت في PBFT بهيكل اتصال أكثر بساطة مدفوع بمشغل.
الخاصية الرئيسية لـ HotStuff هي ما يسمى بالتواصل الخطي (linear communication). في آليته، يحتاج كل مُصادق فقط إلى إرسال صوته إلى القائد الحالي، ثم يقوم القائد بتجميع هذه الأصوات، وإنتاج شهادة الكواروم (QC، شهادة الأغلبية القانونية).
هذا QC في جوهره هو توقيع جماعي، يثبت للشبكة بأكملها: "معظم العقدة وافقت على هذا الاقتراح."
في المقابل ، فإن وضع الاتصال في PBFT هو "البث الشامل" ، حيث يتحدث الجميع في المجموعة ، والمشهد فوضوي للغاية لفترة من الوقت. يشبه نموذج HotStuff إلى حد كبير "شخص واحد يجمع ، وتعبئة واحدة" ، بغض النظر عن عدد الأشخاص الموجودين في الشبكة ، فإنه لا يزال يعمل بكفاءة.
بالإضافة إلى الاتصال الخطي، يمكن لـ HotStuff أيضًا الترقية إلى إصدار أنبوبي (pipelined HotStuff) لتحسين الكفاءة.
في HotStuff الأصلية، سيظل نفس المدقق يتولى قيادة عدة جولات متتالية حتى يتم التأكد من كتلة واحدة بالكامل. هذه العملية هي "جولة واحدة لمعالجة كتلة واحدة"، حيث تتركز كل الجهود على دفع تلك الكتلة الحالية.
وفي خط الإنتاج HotStuff، أصبحت الآلية أكثر مرونة: في كل جولة يتم اختيار قائد جديد، ومهمة كل قائد هي اثنتان:
على جانب واحد، قم بتجميع تصويت الجولة السابقة في شهادة الإجماع (QC) ، وبثها إلى الشبكة بالكامل؛
يقدم كتلة جديدة، مستعدًا لبدء الجولة التالية.
أي أنه لم يعد "تأكيد واحدة ثم معالجة أخرى"، بل كما هو الحال في خط الإنتاج، يتولى قادة مختلفون المسؤولية بالتناوب عن كل مرحلة. يقدم الشخص السابق كتلة، ويؤكدها الشخص التالي ويواصل تقديم كتل جديدة، والإجماع على البلوكتشين ينتقل كما هو الحال في سباق التتابع.
هذا هو أصل تشبيه "خط التجميع": الكتلة الحالية لا تزال تمر بعملية التأكيد، بينما الكتلة التالية بالفعل في الإعداد، مما يزيد من الكفاءة من خلال تنفيذ خطوات متعددة بشكل متوازي.
لتلخيص الأمر، فإن بروتوكولات مثل HotStuff حققت تحسينات كبيرة مقارنة بـ BFT التقليدي في بعدين.
الأول هو أن الاتصال أكثر خفة، حيث يحتاج كل مُحقق إلى التواصل فقط مع القائد؛
الثاني هو أن كفاءة المعالجة أعلى، حيث يمكن أن تسير عمليات تأكيد الكتل المتعددة بالتوازي.
هذا جعل HotStuff نموذج تصميم للعديد من آليات إجماع البلوكتشين الحديثة المعتمدة على PoS. لكن كل شيء له مزاياه وعيوبه - على الرغم من أن الهيكل المتسلسل قوي الأداء، إلا أنه أدخل بهدوء خطر هيكلي ليس من السهل اكتشافه.
بعد ذلك، سنبدأ في مناقشة هذه القضية الجوهرية: تفرع الذيل (Tail Forking).
مشكلة الانقسام في النهاية (Tail-Forking)
على الرغم من أن HotStuff - وخاصة نسخته المتسلسلة - تحل مشكلة قابلية التوسع في بروتوكولات الإجماع، إلا أنها تقدم أيضًا بعض التحديات الجديدة. ومن أبرز هذه التحديات، والتي يسهل تجاهلها، هي مشكلة "تفرع الذيل" (Tail Forking).
ما هو الانقسام في النهاية؟ يمكن فهمه ببساطة على أنه: حدوث إعادة تنظيم غير متوقعة لكتلة في "ذيل السلسلة" للبلوكتشين (reorg).
بشكل محدد، هناك كتلة، وهي صالحة، وقد تم نشرها بنجاح إلى معظم المصدقين، وحصلت على دعم تصويت كافٍ، وبالتالي، من المفترض أن يتم تأكيدها، وكتابتها في السلسلة الرئيسية. ولكن في النهاية، تم "تجاوزها"، وتم التخلي عنها (يتيمة)، ليحل محلها كتلة جديدة في نفس الارتفاع.
هذه ليست مشكلة، وليست هجومًا، بل هي نتيجة لهيكل التصميم الخاص بالبروتوكول نفسه، والذي يوجد فيه إمكانية "سقوط نهاية الكتلة". هل يبدو هذا غير عادل قليلاً؟ إذن، كيف يحدث هذا بالضبط؟
لقد ذكرنا سابقاً أن كل قائد في خط الإنتاج HotStuff لديه مهمتان:
أ. اقتراح كتلة جديدة (مثل Bₙ₊₁)
B. لجمع الأصوات على الكتلة للقائد السابق، وتوليد QC (مثل إكمال التأكيد النهائي لـ Bₙ)
تتمثل هذان المهمتان في العمل بالتوازي، بالتناوب. لكن المشكلة تكمن هنا.
خذ مثالاً: لنفترض أن أليس هي القائدة، وقد قدمت الكتلة Bₙ في الارتفاع n، وقد حصلت هذه الكتلة على تصويت الأغلبية الساحقة، وقد "تأكدت تقريبًا". بعد ذلك، يجب أن يتولى بوب القيادة، ويواصل دفع الكتلة التالية Bₙ₊₁ في السلسلة، ويجب أيضًا تضمين QC (إثبات الأغلبية القانونية) الخاص بـ Bₙ في اقتراحه، لإكمال تأكيد Bₙ النهائي.
لكن إذا كان Bob غير متصل في ذلك الوقت، أو تعمد عدم تقديم QC لـ Bₙ، فستحدث مشكلة.
لأنه لم يكن هناك من يقوم بإنهاء QC وتعبئة كتلة أليس، لم تتمكن سجلات تصويت Bₙ من الانتشار، وهكذا تم "معالجة" هذه الكتلة التي كان ينبغي التأكد منها، وتم تجاهلها في النهاية من قبل الشبكة بأكملها.
هذه هي جوهر الانقسام في النهاية: الكتلة السابقة للزعيم تم تخطيها بسبب تقصير أو سوء نية الزعيم التالي.
لماذا يكون الانقسام في النهاية شديدًا؟
تتركز مشكلة تفرع النهاية في جانبين رئيسيين: 1) تم تدمير آلية التحفيز، 2) تعرضت نشاط النظام للتهديد.
أولاً، تم ابتلاع المكافآت: إذا تم التخلي عن كتلة، فلن يحصل قائدها على أي مكافآت. سواء كانت مكافأة كتلة أو رسوم معاملات. على سبيل المثال، قدمت أليس كتلة قانونية، وحصلت على دعم تصويت الأغلبية الساحقة، لكن بسبب خطأ بوب أو عمل خبيث، لم يتم تأكيد هذه الكتلة، ولم تحصل أليس على أي شيء في النهاية. سيؤدي ذلك إلى هيكل حوافز خاطئ: يمكن للعقدة الخبيثة مثل بوب أن تقفز على كتل خصومهم، "لتقطع" مصدر مكافآتهم. لا تتطلب هذه الأفعال هجمات تقنية، بل تحتاج فقط إلى "عدم التعاون" عمدًا، مما يضعف عوائد المنافسين. إذا حدث هذا الأمر بشكل متكرر، بمرور الوقت، سيؤدي ذلك إلى انخفاض المشاركة والعدالة في النظام بأكمله، وقد يؤدي حتى إلى تآمر بين العقد.
ثانياً، توسيع مساحة هجمات MEV: ستؤدي التفرع في النهاية إلى مشكلة أكثر خفاءً ولكنها خطيرة: ازدادت مساحة التلاعب الخبيث بـ MEV (القيمة القابلة للاستخراج القصوى). على سبيل المثال: لنفترض أن كتلة أليس تحتوي على صفقة تحكيم ذات قيمة عالية. إذا كان بوب لديه نية للعبث، يمكنه التواطؤ مع القائد التالي كارول، وعمداً عدم نشر كتلة أليس. ثم يمكن لكارول في نفس الارتفاع إعادة بناء كتلة جديدة، وسرقة صفقة التحكيم الخاصة بأليس - مما يحول عائدات MEV إلى عائداته الخاصة. إن هذه الممارسة المتمثلة في "إعادة ترتيب رؤوس السلاسل + التواطؤ لسرقة"، تبدو ظاهرياً وكأنها تلتزم بقواعد إنشاء الكتل، لكنها في الواقع عملية نهب مصممة بعناية. والأسوأ من ذلك، أنها ست诱د القادة إلى إقامة "علاقات تآمر"، مما يجعل تأكيد الكتل لعبة توزيع مصالح، بدلاً من خدمة عامة.
ثالثًا، تدمير ضمانات النهائيّة يؤثر على تجربة المستخدم: مقارنةً ببروتوكولات نكاموتو، فإن إحدى المزايا الكبيرة لبروتوكول BFT هي النهائيّة الحتمية: بمجرد تقديم الكتلة، لا يمكن التراجع عنها. ولكن التفرع الأخير يدمر هذه الضمانة، خاصةً في تلك الكتل التي "حصلت على تصويت ولكن لم يتم تأكيدها رسميًا بعد". بعض تطبيقات dapp ذات السعة العالية عادةً ما تأمل في قراءة البيانات على الفور بعد أن يمر التصويت على الكتلة لتقليل التأخير، وإذا تم التخلص من تلك الكتلة فجأة، فقد يؤدي ذلك إلى تراجع حالة المستخدم - مثل عدم تطابق رصيد الحساب، أو اختفاء صفقة ذات رافعة مالية عالية تم إتمامها للتو، أو إعادة تعيين حالة اللعبة فجأة.
رابعًا، قد يؤدي إلى حدوث أعطال متسلسلة: بشكل عام، قد تؤدي الفروع الخلفية إلى تأخير تأكيد كتلة معينة بدورة واحدة، مما يؤثر بشكل غير كبير. ولكن في بعض السيناريوهات الهامشية، إذا اختار عدد من القادة المتتاليين تخطي الكتلة السابقة، قد يتوقف النظام عن العمل، حيث لا يرغب أحد في "استلام" الكتلة السابقة. ستتوقف تقدم السلسلة بأكملها حتى يظهر أخيرًا قائد "مستعد لتحمل المسؤولية"، وعندها فقط سيستمر الشبكة في التقدم.
على الرغم من أن هناك بعض الحلول السابقة، مثل آلية تجنب الانقسام في نهاية البروتوكول المقدم من BeeGees، إلا أنها غالبًا ما تحتاج إلى التضحية بالأداء، مثل إعادة إدخال تعقيد الاتصال الثانوي، مما يجعلها غير مجدية.
ما هو MonadBFT؟
MonadBFT هو بروتوكول إجماع من الجيل الجديد تم تصميمه خصيصًا لحل مشكلة التفريع في النهاية. تكمن قوته في: أنه يعالج المخاطر الهيكلية دون التضحية بمزايا الأداء التي توفرها HotStuff. بعبارة أخرى، MonadBFT ليس إعادة بناء كاملة، بل هو تحسين مستمر يعتمد على الإطار الأساسي لـ HotStuff. يحتفظ بثلاث ميزات رئيسية:
القيادة الدوارة (rotating leader): يتم اختيار قائد جديد في كل جولة لدفع السلسلة للأمام؛
التقديم في خطوط الأنابيب (pipelined commits): يمكن أن تتداخل عمليات تأكيد الكتل المتعددة.
الاتصال الخطي (linear messaging): يحتاج كل مُحقق فقط إلى التواصل مع القائد، مما يوفر الكثير من تكاليف الشبكة.
ولكن الاعتماد فقط على هذه النقاط الثلاث ليس كافيًا من حيث الأمان. لسد الثغرة الهيكلية الناتجة عن التقسيم في النهاية، أضاف MonadBFT آليتين رئيستين:
آلية إعادة الاقتراح (Re-Proposal)
شهادة عدم التأييد (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)
استمر في المثال السابق: بعد انتهاء جولة Bob، طلبت Carol من المصدقين الآخرين تقديم كتلة high_tip (أي كتلة Alice). في هذه المرحلة، سيستجيب ما لا يقل عن 2f+1 من المصدقين:
يجب تقديم كتلة Alice
إما إرسال رسالة NE موقعة، تعبر عن أنه لم يتلقَ كتلة أليس
بمجرد أن تتلقى كارول كتلة أليس، يجب عليها إعادة اقتراحها وفقًا للقواعد. لا يمكن لكارول تخطي هذه الكتلة وطرح واحدة جديدة إلا إذا وقع عليها على الأقل 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)
الاستجابة المتفائلة (Optimistic Responsiveness)
وتحليل المعاني العملية لهذه الآليات بالنسبة للمحققين والمطورين.
يتبع.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
MonadBFT تحليل (الجزء الأول): كيف نحل مشكلة الفرك في النهاية
البلوكتشين الذي يركز على تحقيق نوع من الإجماع العالمي الصارم: بمعنى أنه، بغض النظر عن مكان توزيع عقد الشبكة، أو أي منطقة زمنية، يجب على جميع المشاركين في النهاية التوصل إلى توافق بشأن مجموعة من النتائج الموضوعية.
لكن الشبكات الموزعة في الواقع ليست مثالية: هناك عقدة تتعطل، وهناك عقدة تكذب، بل وحتى بعض الأشخاص يقومون بتخريب متعمد. في هذه الحالة، كيف يمكن للنظام أن "يتحدث بصوت واحد" ويحافظ على التوافق؟
هذه هي المشكلة التي يجب أن تحلها بروتوكولات الإجماع. إنها في جوهرها مجموعة من القواعد التي توجه مجموعة من العقد المستقلة عن بعضها البعض، وحتى غير الموثوقة تمامًا، حول كيفية التوصل إلى قرار موحد بشأن ترتيب ومحتوى كل صفقة.
وعندما يتم إنشاء هذا "الإجماع الصارم"، يمكن للبلوكتشين فتح العديد من الميزات الأساسية، مثل ضمان الملكية الرقمية، ونموذج العملة المقاوم للتضخم، وهياكل التعاون الاجتماعي القابلة للتوسع. ولكن الشرط هو أن بروتوكول الإجماع نفسه يجب أن يضمن في الوقت نفسه جانبين أساسيين:
لا يمكن أن يتم تأكيد كتلتين متعارضتين.
يجب أن يستمر الشبكة في التقدم، ولا يمكن أن تتوقف أو تتعطل.
MonadBFT هو أحدث تقدم تكنولوجي تم إحرازه في هذا الاتجاه.
لمحة عن تطور بروتوكول الإجماع
لقد تم البحث في مجال آلية الإجماع هذا لعشرات السنين. وكانت أول مجموعة من البروتوكولات، مثل PBFT (تحمل أخطاء بيزنطية العملية)، قادرة على معالجة حالة واقعية: حتى لو كانت هناك بعض العقد في الشبكة تفشل أو تتصرف بشكل خاطئ أو تتحدث بشكل غير منطقي، طالما أنها لا تتجاوز ثلث العدد الكلي، يمكن للنظام أن يصل إلى توافق.
تم تصميم هذه البروتوكولات المبكرة بطريقة "تقليدية" نسبياً: يتم اختيار قائد واحد في كل جولة، يقوم بدعوة الاقتراح، ثم يقوم باقي المدققين بالتصويت على هذا الاقتراح عبر عدة جولات، لتأكيد ترتيب المعاملات خطوة بخطوة.
عادةً ما تمر عملية التصويت بأكثر من مرحلة، مثل pre-prepare وprepare وcommit وreply. في كل مرحلة، يجب على جميع المدققين التواصل مع بعضهم البعض. بعبارة أخرى، يجب على كل شخص التحدث مع الجميع مرة واحدة، مما يؤدي إلى زيادة هائلة في حجم الرسائل بشكل "شبكي".
تعقيد هيكل الاتصال هذا هو n² - بمعنى أنه إذا كان هناك 100 من المدققين في الشبكة، فقد يحتاج كل جولة من الإجماع إلى نقل حوالي 10,000 رسالة.
هذا ليس بمشكلة كبيرة في الشبكات الصغيرة، ولكن حالما يرتفع عدد المدققين، ستصبح عبء الاتصالات في النظام سريعًا لا يُطاق، وكفاءة النظام ستتدهور مباشرة.
هذا الهيكل الثانوي من "يجب على كل شخص التواصل مع كل شخص" في الواقع غير فعال للغاية. على سبيل المثال، في شبكة بها 100 موثق، قد يحتاج كل جولة من الإجماع إلى معالجة آلاف الرسائل.
هذا يمكن التعامل معه في دائرة صغيرة، ولكن إذا تم وضعه في شبكة بلوكتشين مفتوحة على مستوى عالمي، فإن حمل الاتصالات سيصبح غير مقبول على الفور. لذلك، فإن بروتوكولات BFT المبكرة مثل PBFT وTendermint، عادة ما تُستخدم فقط في السيناريوهات المرخصة (شبكة مرخصة) أو في الأنظمة التي تحتوي على عدد قليل جداً من المدققين، لتتمكن من العمل بالكاد.
لجعل بروتوكول BFT يتكيف أيضًا مع بيئات السلاسل العامة غير المصرح بها، بدأت بعض التصميمات من الجيل الجديد تتجه نحو طرق اتصال أخف: حيث يتواصل كل مدقق فقط مع القائد، بدلاً من تبادل المعلومات بين الجميع.
هذا يقلل من تعقيد الرسالة من n² الأصلي إلى n - مما خفف بشكل كبير من عبء النظام.
بروتوكول HotStuff تم تقديمه في عام 2018، وكان ذلك لحل مشكلة القابلية للتوسع هذه. فكرة تصميمه واضحة جدًا: استبدال هيكل الاتصال المعقد لعملية التصويت في PBFT بهيكل اتصال أكثر بساطة مدفوع بمشغل.
الخاصية الرئيسية لـ HotStuff هي ما يسمى بالتواصل الخطي (linear communication). في آليته، يحتاج كل مُصادق فقط إلى إرسال صوته إلى القائد الحالي، ثم يقوم القائد بتجميع هذه الأصوات، وإنتاج شهادة الكواروم (QC، شهادة الأغلبية القانونية).
هذا QC في جوهره هو توقيع جماعي، يثبت للشبكة بأكملها: "معظم العقدة وافقت على هذا الاقتراح."
في المقابل ، فإن وضع الاتصال في PBFT هو "البث الشامل" ، حيث يتحدث الجميع في المجموعة ، والمشهد فوضوي للغاية لفترة من الوقت. يشبه نموذج HotStuff إلى حد كبير "شخص واحد يجمع ، وتعبئة واحدة" ، بغض النظر عن عدد الأشخاص الموجودين في الشبكة ، فإنه لا يزال يعمل بكفاءة.
بالإضافة إلى الاتصال الخطي، يمكن لـ HotStuff أيضًا الترقية إلى إصدار أنبوبي (pipelined HotStuff) لتحسين الكفاءة.
في HotStuff الأصلية، سيظل نفس المدقق يتولى قيادة عدة جولات متتالية حتى يتم التأكد من كتلة واحدة بالكامل. هذه العملية هي "جولة واحدة لمعالجة كتلة واحدة"، حيث تتركز كل الجهود على دفع تلك الكتلة الحالية.
وفي خط الإنتاج HotStuff، أصبحت الآلية أكثر مرونة: في كل جولة يتم اختيار قائد جديد، ومهمة كل قائد هي اثنتان:
على جانب واحد، قم بتجميع تصويت الجولة السابقة في شهادة الإجماع (QC) ، وبثها إلى الشبكة بالكامل؛
يقدم كتلة جديدة، مستعدًا لبدء الجولة التالية.
أي أنه لم يعد "تأكيد واحدة ثم معالجة أخرى"، بل كما هو الحال في خط الإنتاج، يتولى قادة مختلفون المسؤولية بالتناوب عن كل مرحلة. يقدم الشخص السابق كتلة، ويؤكدها الشخص التالي ويواصل تقديم كتل جديدة، والإجماع على البلوكتشين ينتقل كما هو الحال في سباق التتابع.
هذا هو أصل تشبيه "خط التجميع": الكتلة الحالية لا تزال تمر بعملية التأكيد، بينما الكتلة التالية بالفعل في الإعداد، مما يزيد من الكفاءة من خلال تنفيذ خطوات متعددة بشكل متوازي.
لتلخيص الأمر، فإن بروتوكولات مثل HotStuff حققت تحسينات كبيرة مقارنة بـ BFT التقليدي في بعدين.
الأول هو أن الاتصال أكثر خفة، حيث يحتاج كل مُحقق إلى التواصل فقط مع القائد؛
الثاني هو أن كفاءة المعالجة أعلى، حيث يمكن أن تسير عمليات تأكيد الكتل المتعددة بالتوازي.
هذا جعل HotStuff نموذج تصميم للعديد من آليات إجماع البلوكتشين الحديثة المعتمدة على PoS. لكن كل شيء له مزاياه وعيوبه - على الرغم من أن الهيكل المتسلسل قوي الأداء، إلا أنه أدخل بهدوء خطر هيكلي ليس من السهل اكتشافه.
بعد ذلك، سنبدأ في مناقشة هذه القضية الجوهرية: تفرع الذيل (Tail Forking).
مشكلة الانقسام في النهاية (Tail-Forking)
على الرغم من أن HotStuff - وخاصة نسخته المتسلسلة - تحل مشكلة قابلية التوسع في بروتوكولات الإجماع، إلا أنها تقدم أيضًا بعض التحديات الجديدة. ومن أبرز هذه التحديات، والتي يسهل تجاهلها، هي مشكلة "تفرع الذيل" (Tail Forking).
ما هو الانقسام في النهاية؟ يمكن فهمه ببساطة على أنه: حدوث إعادة تنظيم غير متوقعة لكتلة في "ذيل السلسلة" للبلوكتشين (reorg).
بشكل محدد، هناك كتلة، وهي صالحة، وقد تم نشرها بنجاح إلى معظم المصدقين، وحصلت على دعم تصويت كافٍ، وبالتالي، من المفترض أن يتم تأكيدها، وكتابتها في السلسلة الرئيسية. ولكن في النهاية، تم "تجاوزها"، وتم التخلي عنها (يتيمة)، ليحل محلها كتلة جديدة في نفس الارتفاع.
هذه ليست مشكلة، وليست هجومًا، بل هي نتيجة لهيكل التصميم الخاص بالبروتوكول نفسه، والذي يوجد فيه إمكانية "سقوط نهاية الكتلة". هل يبدو هذا غير عادل قليلاً؟ إذن، كيف يحدث هذا بالضبط؟
لقد ذكرنا سابقاً أن كل قائد في خط الإنتاج HotStuff لديه مهمتان:
أ. اقتراح كتلة جديدة (مثل Bₙ₊₁)
B. لجمع الأصوات على الكتلة للقائد السابق، وتوليد QC (مثل إكمال التأكيد النهائي لـ Bₙ)
تتمثل هذان المهمتان في العمل بالتوازي، بالتناوب. لكن المشكلة تكمن هنا.
خذ مثالاً: لنفترض أن أليس هي القائدة، وقد قدمت الكتلة Bₙ في الارتفاع n، وقد حصلت هذه الكتلة على تصويت الأغلبية الساحقة، وقد "تأكدت تقريبًا". بعد ذلك، يجب أن يتولى بوب القيادة، ويواصل دفع الكتلة التالية Bₙ₊₁ في السلسلة، ويجب أيضًا تضمين QC (إثبات الأغلبية القانونية) الخاص بـ Bₙ في اقتراحه، لإكمال تأكيد Bₙ النهائي.
لكن إذا كان Bob غير متصل في ذلك الوقت، أو تعمد عدم تقديم QC لـ Bₙ، فستحدث مشكلة.
لأنه لم يكن هناك من يقوم بإنهاء QC وتعبئة كتلة أليس، لم تتمكن سجلات تصويت Bₙ من الانتشار، وهكذا تم "معالجة" هذه الكتلة التي كان ينبغي التأكد منها، وتم تجاهلها في النهاية من قبل الشبكة بأكملها.
هذه هي جوهر الانقسام في النهاية: الكتلة السابقة للزعيم تم تخطيها بسبب تقصير أو سوء نية الزعيم التالي.
لماذا يكون الانقسام في النهاية شديدًا؟
تتركز مشكلة تفرع النهاية في جانبين رئيسيين: 1) تم تدمير آلية التحفيز، 2) تعرضت نشاط النظام للتهديد.
أولاً، تم ابتلاع المكافآت: إذا تم التخلي عن كتلة، فلن يحصل قائدها على أي مكافآت. سواء كانت مكافأة كتلة أو رسوم معاملات. على سبيل المثال، قدمت أليس كتلة قانونية، وحصلت على دعم تصويت الأغلبية الساحقة، لكن بسبب خطأ بوب أو عمل خبيث، لم يتم تأكيد هذه الكتلة، ولم تحصل أليس على أي شيء في النهاية. سيؤدي ذلك إلى هيكل حوافز خاطئ: يمكن للعقدة الخبيثة مثل بوب أن تقفز على كتل خصومهم، "لتقطع" مصدر مكافآتهم. لا تتطلب هذه الأفعال هجمات تقنية، بل تحتاج فقط إلى "عدم التعاون" عمدًا، مما يضعف عوائد المنافسين. إذا حدث هذا الأمر بشكل متكرر، بمرور الوقت، سيؤدي ذلك إلى انخفاض المشاركة والعدالة في النظام بأكمله، وقد يؤدي حتى إلى تآمر بين العقد.
ثانياً، توسيع مساحة هجمات MEV: ستؤدي التفرع في النهاية إلى مشكلة أكثر خفاءً ولكنها خطيرة: ازدادت مساحة التلاعب الخبيث بـ MEV (القيمة القابلة للاستخراج القصوى). على سبيل المثال: لنفترض أن كتلة أليس تحتوي على صفقة تحكيم ذات قيمة عالية. إذا كان بوب لديه نية للعبث، يمكنه التواطؤ مع القائد التالي كارول، وعمداً عدم نشر كتلة أليس. ثم يمكن لكارول في نفس الارتفاع إعادة بناء كتلة جديدة، وسرقة صفقة التحكيم الخاصة بأليس - مما يحول عائدات MEV إلى عائداته الخاصة. إن هذه الممارسة المتمثلة في "إعادة ترتيب رؤوس السلاسل + التواطؤ لسرقة"، تبدو ظاهرياً وكأنها تلتزم بقواعد إنشاء الكتل، لكنها في الواقع عملية نهب مصممة بعناية. والأسوأ من ذلك، أنها ست诱د القادة إلى إقامة "علاقات تآمر"، مما يجعل تأكيد الكتل لعبة توزيع مصالح، بدلاً من خدمة عامة.
ثالثًا، تدمير ضمانات النهائيّة يؤثر على تجربة المستخدم: مقارنةً ببروتوكولات نكاموتو، فإن إحدى المزايا الكبيرة لبروتوكول BFT هي النهائيّة الحتمية: بمجرد تقديم الكتلة، لا يمكن التراجع عنها. ولكن التفرع الأخير يدمر هذه الضمانة، خاصةً في تلك الكتل التي "حصلت على تصويت ولكن لم يتم تأكيدها رسميًا بعد". بعض تطبيقات dapp ذات السعة العالية عادةً ما تأمل في قراءة البيانات على الفور بعد أن يمر التصويت على الكتلة لتقليل التأخير، وإذا تم التخلص من تلك الكتلة فجأة، فقد يؤدي ذلك إلى تراجع حالة المستخدم - مثل عدم تطابق رصيد الحساب، أو اختفاء صفقة ذات رافعة مالية عالية تم إتمامها للتو، أو إعادة تعيين حالة اللعبة فجأة.
رابعًا، قد يؤدي إلى حدوث أعطال متسلسلة: بشكل عام، قد تؤدي الفروع الخلفية إلى تأخير تأكيد كتلة معينة بدورة واحدة، مما يؤثر بشكل غير كبير. ولكن في بعض السيناريوهات الهامشية، إذا اختار عدد من القادة المتتاليين تخطي الكتلة السابقة، قد يتوقف النظام عن العمل، حيث لا يرغب أحد في "استلام" الكتلة السابقة. ستتوقف تقدم السلسلة بأكملها حتى يظهر أخيرًا قائد "مستعد لتحمل المسؤولية"، وعندها فقط سيستمر الشبكة في التقدم.
على الرغم من أن هناك بعض الحلول السابقة، مثل آلية تجنب الانقسام في نهاية البروتوكول المقدم من BeeGees، إلا أنها غالبًا ما تحتاج إلى التضحية بالأداء، مثل إعادة إدخال تعقيد الاتصال الثانوي، مما يجعلها غير مجدية.
ما هو MonadBFT؟
MonadBFT هو بروتوكول إجماع من الجيل الجديد تم تصميمه خصيصًا لحل مشكلة التفريع في النهاية. تكمن قوته في: أنه يعالج المخاطر الهيكلية دون التضحية بمزايا الأداء التي توفرها HotStuff. بعبارة أخرى، MonadBFT ليس إعادة بناء كاملة، بل هو تحسين مستمر يعتمد على الإطار الأساسي لـ HotStuff. يحتفظ بثلاث ميزات رئيسية:
القيادة الدوارة (rotating leader): يتم اختيار قائد جديد في كل جولة لدفع السلسلة للأمام؛
التقديم في خطوط الأنابيب (pipelined commits): يمكن أن تتداخل عمليات تأكيد الكتل المتعددة.
الاتصال الخطي (linear messaging): يحتاج كل مُحقق فقط إلى التواصل مع القائد، مما يوفر الكثير من تكاليف الشبكة.
ولكن الاعتماد فقط على هذه النقاط الثلاث ليس كافيًا من حيث الأمان. لسد الثغرة الهيكلية الناتجة عن التقسيم في النهاية، أضاف MonadBFT آليتين رئيستين:
آلية إعادة الاقتراح (Re-Proposal)
شهادة عدم التأييد (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)
استمر في المثال السابق: بعد انتهاء جولة Bob، طلبت Carol من المصدقين الآخرين تقديم كتلة high_tip (أي كتلة Alice). في هذه المرحلة، سيستجيب ما لا يقل عن 2f+1 من المصدقين:
يجب تقديم كتلة Alice
إما إرسال رسالة NE موقعة، تعبر عن أنه لم يتلقَ كتلة أليس
بمجرد أن تتلقى كارول كتلة أليس، يجب عليها إعادة اقتراحها وفقًا للقواعد. لا يمكن لكارول تخطي هذه الكتلة وطرح واحدة جديدة إلا إذا وقع عليها على الأقل 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)
الاستجابة المتفائلة (Optimistic Responsiveness)
وتحليل المعاني العملية لهذه الآليات بالنسبة للمحققين والمطورين.
يتبع.