في الجزء الأول، درسنا كيفية عمل إجماع PBFT الكلاسيكي (تحمل الخطأ البيزنطي العملي) وكيفية تشغيل الإصدارات المبكرة من HotStuff. كما تعلمنا كيف يحل MonadBFT مشكلة الانقسام النهائي في HotStuff، وهي مشكلة فقدان الكتل الفعالة أحيانًا في نظام التدفق.
تسبب مشكلة ذيل الشجرة في مشكلتين رئيسيتين: 1) إنها تعطل مكافآت بناة الكتل الأمناء، 2) قد تؤدي إلى توقف الشبكة.
أدخل MonadBFT قواعد إعادة الاقتراح وآلية التصويت بدون تأييد للتخلص من مشكلة الانقسام في النهاية، وضمان دخول أي كتلة معتمدة بشكل صحيح من مقترح أمين إلى السلسلة.
في الجزء الثاني، سنستكشف خاصيتين إضافيتين لـ MonadBFT: 1) النهائية المضاربة و 2) الاستجابة المتفائلة. سنستكشف أيضًا تأثير MonadBFT على المطورين.
النهائية للتخمين في جولة واحدة
بالإضافة إلى مقاومة الانقسام في النهاية، فإن خاصية رئيسية أخرى لـ MonadBFT هي النهائية الأحادية للدوران.
في التطبيق العملي، يعني هذا أن العميل والمستخدمين يمكنهم تلقي تأكيد المعاملة على الفور بعد أن يحصل الكتلة على أغلبية الأصوات، حتى قبل انتهاء الجولة التالية.
تذكر أنه في بروتوكول HotStuff الأساسي، يجب أن تمر الكتلة عادةً عبر مرحلتين على الأقل (مثل Fast-Hotstuff وDiem-BFT) قبل أن تعتبر نهائية (غير قابلة للعكس): المرحلة الأولى هي الحصول على شهادة عدد الأصوات القانوني (QC) (لإغلاق الكتلة بـ ≥2f+1 صوت)، والمرحلة الثانية هي أن يقوم القائد التالي ببناء وتقديم الكتلة استنادًا إلى شهادة العدد القانوني (QC).
تعد هذه العملية ذات المرحلتين ضرورية لضمان الأمان: بمجرد أن يقوم عدد كافٍ من العقد الصادقة بقفل كتلة، لن تتمكن الكتلة المتعارضة من الحصول على العدد القانوني، وستجعل الجولة التالية من التقديم ذلك دائمًا. لذلك، قد يحتاج العميل عادةً إلى الانتظار حتى يتم إنتاج الكتلة التالية أو الجولة التالية ليعرف ما إذا كانت المعاملة السابقة قد تم تأكيدها نهائيًا.
MonadBFT يسمح أساسًا بأن تُعتبر المعاملات نهائية بما يكفي بعد جولة واحدة فقط من التصويت (يمكن تشغيلها بأمان). وهذا ما يُعرف بالنهائية المضاربة.
عندما يقدم القائد كتلة، يصوت المدققون لتشكيل QC لهذه الكتلة، تكون هذه الكتلة في حالة تصويت (تم قفلها من قبل النصاب القانوني). في MonadBFT، بمجرد أن يقوم المدققون بتشكيل QC، يقومون على الفور بتنفيذ معاملات هذه الكتلة، وقد يرسلون حتى تأكيدًا أوليًا إلى العميل، مما يشير إلى أن هذه الكتلة قد تم قبولها (مضاربة). هذا يشبه القول "لدينا أغلبية كبيرة توافق على هذه الكتلة. ما لم تحدث أشياء غير متوقعة للغاية، يمكن اعتبار هذه الكتلة مؤكدة."
هذا التأكيد الفوري هو تفاؤلي. الكتلة لم تُسجل بعد في السجل. سيحدث ذلك عندما يظهر الاقتراح التالي ويؤكد ذلك (QC-on QC)، ولكن في الظروف العادية، لا شيء يمكن أن يلغي ذلك. الحالة الوحيدة التي يمكن أن تلغي بها الكتلة التنفيذية المضاربية هي حدوث هجوم مكافئ من قبل القائد (أي تقديم كتلتين مختلفتين على نفس الارتفاع لتفريق الأصوات).
يمكنك اعتبار نهائية المضاربة كمنتج ثانوي جيد لمقاومة الانقسامات الطرفية. تضمن مقاومة الانقسامات الطرفية أنه حتى لو انهار القائد التالي، فلن يتم إهمال الاقتراح الحالي (بفضل إعادة الاقتراح وقواعد NEC). الحالة الوحيدة التي يتم فيها إهمال الكتلة التنفيذية المضاربة هي حدوث هجوم مكافئ من قبل المقترح الأصلي (خطأ توقيع مزدوج موثوق بإثبات الخبث)، وفي هذه الحالة: 1) يمكن اكتشافها من خلال QC المتعارضة؛ 2) يمكن معاقبتها؛ 3) نادرة للغاية.
في البروتوكول السابق، لم يضمنوا أن القائد التالي سيعيد تقديم الكتلة السابقة، وبالتالي فإن وجود انقسام في النهاية ممكن، مما يكسر الفرضية المضاربة.
الاستجابة المتفائلة
في معظم بروتوكولات الإجمــاع، يوجد فترة انتظار مدمجة بعد كل جولة، مثل فترة التخزين المؤقت أو المهلة. هذا لضمان وصول جميع الرسائل قبل الاستمرار في التقدم. إنها آلية حماية تهدف إلى معالجة أسوأ السيناريوهات، مثل انهيار القائد أو عدم إرسال أي معلومات على الإطلاق.
هذه المهلات عادة ما تكون متحفظة للغاية. إذا كانت الشبكة تعمل بشكل طبيعي وكان سلوك جميع المدققين صحيحًا، فإن الانتظار الثابت سيصبح تكلفة غير ضرورية. كان يمكن إكمال الكتلة بشكل أسرع، لكن البروتوكول تأخر احتياطيًا.
موناد BFT قدمت استجابة متفائلة، مما يعني أن البروتوكول يمكن أن يتقدم على الفور بناءً على معلومات الشبكة، بدلاً من الاعتماد دائمًا على مؤقتات ثابتة. يمكن تلخيص مبادئ التصميم هنا بعبارة "إذا كان بالإمكان السرعة فليكن، وإذا كان يجب الانتظار فليكن الانتظار".
تصميم MonadBFT يجعله في الأوضاع الطبيعية، وحتى أثناء استعادة الأعطال، إذا لم يكن هناك ضرورة، فإنه لا يتوقف في انتظار المهلة المحددة.
على المسار السعيد (يعني أن لدينا قائدًا صادقًا): لا توجد تأخيرات مدمجة في الاقتراح أو التصويت. بمجرد أن يحين دور القائد، فإنه سيقدم كتلة. عندما يتلقى المُحقق اقتراحًا صالحًا، فإنه سيصوت على الفور. عندما يجمع القائد (أو بالأحرى، القائد التالي، لأنه في خط أنابيب HotStuff، يتم إرسال التصويت إلى المُقترح التالي) 2f + 1 صوتًا، يتم تشكيل QC ويمكن نشره. في تصميم الاستجابة المتفائلة، سيؤدي ذلك على الفور إلى بدء المرحلة التالية.
في الممارسة العملية، هذا يعني أنه إذا كان تأخير الشبكة بين العقد 100 مللي ثانية، فإن الإجماع قد يستغرق بضع مئات من المللي ثانية لإكمال جولة (بالإضافة إلى تكاليف الحساب والتجميع).
إذا لم يكن هناك حاجة، فلن ينتظر، مثل "وقت الفتحة" الذي يستمر لمدة ثانية كاملة. هذا يختلف عن نموذج الفتحة والعصر المعتمد في الشبكة الرئيسية للإيثيريوم. في الإيثيريوم، يتم تثبيت الفاصل الزمني لإنتاج الكتل عند 12 ثانية. حتى لو كان الجميع مستعدين مسبقًا، سيظل البروتوكول ينتظر.
تزيل طريقة MonadBFT التأخيرات غير الضرورية. إنها تحتفظ بهيكل HotStuff المتسلسل، ولكنها تزيل القاعدة الصارمة "يجب الانتظار لمدة Δ ثانية" في الحالات العادية. وهذا يعني أنها يمكن أن تتفوق على الأنظمة المقيدة زمنياً من حيث الاستجابة دون التضحية بالأمان.
في مسار غير سعيد (فشل القائد): في العديد من بروتوكولات الإجماع، عندما يفشل القائد في اقتراح كتلة، فإن العقد الأخرى لا تدرك ذلك إلا بعد انتهاء مهلة Δ. على سبيل المثال، إذا كانت Δ تساوي 1 ثانية، فإن هذه الفترة الزمنية تُعتبر مضيعة بشكل أساسي. طريقة MonadBFT في التعامل مع هذا الأمر مختلفة. عندما يكتشف المصدقون فقدان الاقتراح، فإنهم يقومون على الفور ببث رسالة انتهاء المهلة (TC أو شهادة انتهاء المهلة). بمجرد ظهور 2f+1 من انتهاء المهلة، سيتولى القائد التالي المسؤولية. الانتقال إلى وجهة نظر جديدة يتم تحفيزه بواسطة دليل يعتمد على عدد الأصوات بدلاً من أن يتم تحفيزه بواسطة الساعة.
مقارنة مع الإجماع في عائلة hotstuff
تأسس MonadBFT على أساس بروتوكولات الإجماع من سلسلة HotStuff، لكنه تميز من خلال تنفيذ مجموعة من الخصائص المثالية. كانت البروتوكولات المبكرة غالبًا ما تُحسَّن لأبعاد معينة، مثل سعة المعالجة المتوازية أو الاتصال الخطي، لكنها اضطرت للتضحية بجوانب أخرى. يجمع MonadBFT بشكل فريد بين تعقيد الرسائل الخطية، والتقديم المتوازن، ومقاومة قوية للانقسامات في النهاية، والاستجابة الفورية بدون تأخير ثابت، وآلية استرداد فعالة، مع الاحتفاظ أيضًا بتأكيد نهائي سريع وضمانات عالية التوافر. يلخص الجدول أدناه مقارنة بين MonadBFT وبروتوكولات BFT الأخرى التي تتناوب على القيادة في هذه الأبعاد الأساسية:
ماذا يعني هذا للمطورين والمستخدمين؟
بالنسبة للمطورين، فإن MonadBFT تعني عدة نقاط:
نموذج نهائي أبسط: باستخدام MonadBFT، يمكنك اعتبار الكتلة التي تحتوي على QC (تصويت الأغلبية الساحقة) قد تم تأكيدها نهائيًا، لأن البروتوكول سيؤكدها نهائيًا أو يفرض عقوبة. يمكن للمطورين العمل بأمان على تأكيد كتلة واحدة بثقة عالية.
تحسين تجربة المستخدم للتطبيقات: إذا كنت تبني تطبيقًا عالي الإنتاجية (مثل البورصات، الألعاب، إلخ)، فإن التأخير المنخفض لـ MonadBFT وخصائص مقاومة الفوكس ستتحول إلى تجربة مستخدم أكثر سلاسة. يمكن للمستخدمين رؤية تأكيد عملياتهم تقريبًا على الفور، ولن يواجهوا إعادة تنظيم أو تراجع مربك بشكل متكرر. بهذه الطريقة، يمكنك تصميم تطبيقات تتمتع بالثبات النهائي والتحديث السريع.
سلوك الحتمية: تقلل القواعد الأكثر صرامة لـ MonadBFT (مثل متطلبات إعادة الاقتراح) من عدم اليقين في تضمين الكتل. بسبب العوامل الزمنية الدقيقة مثل ما إذا كانت الأصوات أو انتهاء الوقت تصل إلى القائد أولاً، تكون "حالات الحافة" التي يتم فيها تضمين الكتل أو تخطيها أقل. تستبدل MonadBFT هذه الغموض الحساس للوقت بقواعد واضحة وأدلة قابلة للتحقق. وهذا يجعل من الأسهل استنتاج صحة البروتوكول واختباره. كما أنه يوفر أساسًا واضحًا لتحديد العقد المعطلة (على سبيل المثال، إذا فشل شخص ما في إعادة الاقتراح أو اقترح كتلة متعارضة، فإنك تعرف أنهم انتهكوا البروتوكول).
مساحة القابلية للتوسع: إذا كنت مطورًا يركز على القابلية للتوسع، فإن MonadBFT يوفر لك المزيد من المساحة قبل مواجهة الاختناقات. بالمقارنة مع البروتوكولات الثانوية، يمكنك بسهولة زيادة حجم الكتلة أو عدد المراجعين. بالإضافة إلى ذلك، فإن ميزات مثل نشر الكتل باستخدام الترميز القابل للحذف تعني أنك تستطيع دفع كميات كبيرة من البيانات عبر الشبكة دون استهلاك مفرط لعقدة واحدة. وهذا يجعل من الممكن استهداف معدل نقل أعلى، ويفتح مساحة تصميم لتطبيقات أكثر طموحًا على السلسلة.
بالنسبة للمستخدمين النهائيين: لن يفهم المستخدمون العاديون أي شيء مما نتحدث عنه هنا، لكنهم سيشعرون بتأثيره. مع MonadBFT كأساس لسلسلة Monad، يمكن للمستخدمين توقع جميع الميزات الجيدة التالية دون التضحية باللامركزية ومقاومة الرقابة.
تأكيد أسرع: ستتلقى المعاملات (مثل إرسال الرموز، تبادل الأصول، سك NFT، تنفيذ المعاملات) تأكيدًا سريعًا.
تقليل المفاجآت: تتسق حالة السلسلة بشكل أكبر، لأن أمورًا مثل الانقسامات النهائية، التي تنتمي في جوهرها إلى إعادة التنظيم، قد أزيلت.
العدالة والشفافية: تحسين الإجماع يعني بشكل غير مباشر أن تشغيل السلسلة أصبح أكثر عدلاً. لا يمكن لأي مُصادق فردي بسهولة مراجعة المعاملات أو التلاعب بترتيب الكتل.
استنتاج
باختصار، قدم MonadBFT أربع ابتكارات جوهرية على أساس إجماع HotStuff بأسلوب التدفق:
مقاومة هجمات تقسيم الذيل: MonadBFT هو أول بروتوكول BFT متسلسل يقضي على هجمات تقسيم الذيل. يحقق ذلك من خلال إعادة تقديم الكتلة التي تم التصويت عليها في المرة السابقة من قبل القائد التالي في حال فشل القائد السابق، أو عرض شهادة عدم التصديق (NEC) لإثبات أن هذه الكتلة تفتقر إلى الدعم. هذا يضمن عدم تجاهل أي كتلة حصلت على دعم الأغلبية الساحقة، مما يحمي مكافآت القادة الأمناء ويمنع إعادة التجميع الخبيثة واستخراج MEV عبر الكتل.
النهائية للتكهنات ذات الدورة الواحدة: يمكن للمتحققين تأكيد الكتلة بعد الاتصال ذو الدورة الواحدة (اقتراح قائد واحد وتصويت) ، مما يوفر للعملاء ضمانًا فوريًا للاحتواء. هذه التأكيدات التكهنية لن تستعاد إلا في حالة هجوم مكافئ للقائد (سلوك يمكن إثباته ومعاقبته) ، مما يجعلها في الممارسة فرضية أمان.
استجابة متفائلة: البروتوكول يعمل بسرعة الشبكة، دون تأخير متأصل. يتقدم القائد بالإجماع على الفور بعد تلقي الأصوات اللازمة، وتحدث تغييرات العرض على الفور بعد ملاحظة تجاوز العدد القانوني، بدلاً من الانتظار لفترة زمنية ثابتة. يقلل تصميم الاستجابة المتفائلة هذا من وقت الانتظار ويزيد من القدرة على المعالجة، بينما لا يزال قادرًا على المعالجة بشكل قوي في حالة حدوث عدم تزامن أو أعطال.
الاتصالات الخطية: على المسار السعيد (أي عندما يكون القائد صادقًا)، تكون تعقيد الرسائل والتحقق في علاقة خطية مع عدد المراجعين. يحتفظ MonadBFT بنمط الاتصال الفعال لـ HotStuff، باستخدام التوقيعات المجمعة وقادة بسيطين لبث إلى المراجعين، مما يسمح للبروتوكول بالتوسع إلى مئات المراجعين دون ظهور اختناق في الأداء.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
تحليل MonadBFT (الجزء الثاني): ماذا يعني ذلك للمطورين والمستخدمين
في الجزء الأول، درسنا كيفية عمل إجماع PBFT الكلاسيكي (تحمل الخطأ البيزنطي العملي) وكيفية تشغيل الإصدارات المبكرة من HotStuff. كما تعلمنا كيف يحل MonadBFT مشكلة الانقسام النهائي في HotStuff، وهي مشكلة فقدان الكتل الفعالة أحيانًا في نظام التدفق.
تسبب مشكلة ذيل الشجرة في مشكلتين رئيسيتين: 1) إنها تعطل مكافآت بناة الكتل الأمناء، 2) قد تؤدي إلى توقف الشبكة.
أدخل MonadBFT قواعد إعادة الاقتراح وآلية التصويت بدون تأييد للتخلص من مشكلة الانقسام في النهاية، وضمان دخول أي كتلة معتمدة بشكل صحيح من مقترح أمين إلى السلسلة.
في الجزء الثاني، سنستكشف خاصيتين إضافيتين لـ MonadBFT: 1) النهائية المضاربة و 2) الاستجابة المتفائلة. سنستكشف أيضًا تأثير MonadBFT على المطورين.
النهائية للتخمين في جولة واحدة
بالإضافة إلى مقاومة الانقسام في النهاية، فإن خاصية رئيسية أخرى لـ MonadBFT هي النهائية الأحادية للدوران.
في التطبيق العملي، يعني هذا أن العميل والمستخدمين يمكنهم تلقي تأكيد المعاملة على الفور بعد أن يحصل الكتلة على أغلبية الأصوات، حتى قبل انتهاء الجولة التالية.
تذكر أنه في بروتوكول HotStuff الأساسي، يجب أن تمر الكتلة عادةً عبر مرحلتين على الأقل (مثل Fast-Hotstuff وDiem-BFT) قبل أن تعتبر نهائية (غير قابلة للعكس): المرحلة الأولى هي الحصول على شهادة عدد الأصوات القانوني (QC) (لإغلاق الكتلة بـ ≥2f+1 صوت)، والمرحلة الثانية هي أن يقوم القائد التالي ببناء وتقديم الكتلة استنادًا إلى شهادة العدد القانوني (QC).
تعد هذه العملية ذات المرحلتين ضرورية لضمان الأمان: بمجرد أن يقوم عدد كافٍ من العقد الصادقة بقفل كتلة، لن تتمكن الكتلة المتعارضة من الحصول على العدد القانوني، وستجعل الجولة التالية من التقديم ذلك دائمًا. لذلك، قد يحتاج العميل عادةً إلى الانتظار حتى يتم إنتاج الكتلة التالية أو الجولة التالية ليعرف ما إذا كانت المعاملة السابقة قد تم تأكيدها نهائيًا.
MonadBFT يسمح أساسًا بأن تُعتبر المعاملات نهائية بما يكفي بعد جولة واحدة فقط من التصويت (يمكن تشغيلها بأمان). وهذا ما يُعرف بالنهائية المضاربة.
عندما يقدم القائد كتلة، يصوت المدققون لتشكيل QC لهذه الكتلة، تكون هذه الكتلة في حالة تصويت (تم قفلها من قبل النصاب القانوني). في MonadBFT، بمجرد أن يقوم المدققون بتشكيل QC، يقومون على الفور بتنفيذ معاملات هذه الكتلة، وقد يرسلون حتى تأكيدًا أوليًا إلى العميل، مما يشير إلى أن هذه الكتلة قد تم قبولها (مضاربة). هذا يشبه القول "لدينا أغلبية كبيرة توافق على هذه الكتلة. ما لم تحدث أشياء غير متوقعة للغاية، يمكن اعتبار هذه الكتلة مؤكدة."
هذا التأكيد الفوري هو تفاؤلي. الكتلة لم تُسجل بعد في السجل. سيحدث ذلك عندما يظهر الاقتراح التالي ويؤكد ذلك (QC-on QC)، ولكن في الظروف العادية، لا شيء يمكن أن يلغي ذلك. الحالة الوحيدة التي يمكن أن تلغي بها الكتلة التنفيذية المضاربية هي حدوث هجوم مكافئ من قبل القائد (أي تقديم كتلتين مختلفتين على نفس الارتفاع لتفريق الأصوات).
يمكنك اعتبار نهائية المضاربة كمنتج ثانوي جيد لمقاومة الانقسامات الطرفية. تضمن مقاومة الانقسامات الطرفية أنه حتى لو انهار القائد التالي، فلن يتم إهمال الاقتراح الحالي (بفضل إعادة الاقتراح وقواعد NEC). الحالة الوحيدة التي يتم فيها إهمال الكتلة التنفيذية المضاربة هي حدوث هجوم مكافئ من قبل المقترح الأصلي (خطأ توقيع مزدوج موثوق بإثبات الخبث)، وفي هذه الحالة: 1) يمكن اكتشافها من خلال QC المتعارضة؛ 2) يمكن معاقبتها؛ 3) نادرة للغاية.
في البروتوكول السابق، لم يضمنوا أن القائد التالي سيعيد تقديم الكتلة السابقة، وبالتالي فإن وجود انقسام في النهاية ممكن، مما يكسر الفرضية المضاربة.
الاستجابة المتفائلة
في معظم بروتوكولات الإجمــاع، يوجد فترة انتظار مدمجة بعد كل جولة، مثل فترة التخزين المؤقت أو المهلة. هذا لضمان وصول جميع الرسائل قبل الاستمرار في التقدم. إنها آلية حماية تهدف إلى معالجة أسوأ السيناريوهات، مثل انهيار القائد أو عدم إرسال أي معلومات على الإطلاق.
هذه المهلات عادة ما تكون متحفظة للغاية. إذا كانت الشبكة تعمل بشكل طبيعي وكان سلوك جميع المدققين صحيحًا، فإن الانتظار الثابت سيصبح تكلفة غير ضرورية. كان يمكن إكمال الكتلة بشكل أسرع، لكن البروتوكول تأخر احتياطيًا.
موناد BFT قدمت استجابة متفائلة، مما يعني أن البروتوكول يمكن أن يتقدم على الفور بناءً على معلومات الشبكة، بدلاً من الاعتماد دائمًا على مؤقتات ثابتة. يمكن تلخيص مبادئ التصميم هنا بعبارة "إذا كان بالإمكان السرعة فليكن، وإذا كان يجب الانتظار فليكن الانتظار".
تصميم MonadBFT يجعله في الأوضاع الطبيعية، وحتى أثناء استعادة الأعطال، إذا لم يكن هناك ضرورة، فإنه لا يتوقف في انتظار المهلة المحددة.
على المسار السعيد (يعني أن لدينا قائدًا صادقًا): لا توجد تأخيرات مدمجة في الاقتراح أو التصويت. بمجرد أن يحين دور القائد، فإنه سيقدم كتلة. عندما يتلقى المُحقق اقتراحًا صالحًا، فإنه سيصوت على الفور. عندما يجمع القائد (أو بالأحرى، القائد التالي، لأنه في خط أنابيب HotStuff، يتم إرسال التصويت إلى المُقترح التالي) 2f + 1 صوتًا، يتم تشكيل QC ويمكن نشره. في تصميم الاستجابة المتفائلة، سيؤدي ذلك على الفور إلى بدء المرحلة التالية.
في الممارسة العملية، هذا يعني أنه إذا كان تأخير الشبكة بين العقد 100 مللي ثانية، فإن الإجماع قد يستغرق بضع مئات من المللي ثانية لإكمال جولة (بالإضافة إلى تكاليف الحساب والتجميع).
إذا لم يكن هناك حاجة، فلن ينتظر، مثل "وقت الفتحة" الذي يستمر لمدة ثانية كاملة. هذا يختلف عن نموذج الفتحة والعصر المعتمد في الشبكة الرئيسية للإيثيريوم. في الإيثيريوم، يتم تثبيت الفاصل الزمني لإنتاج الكتل عند 12 ثانية. حتى لو كان الجميع مستعدين مسبقًا، سيظل البروتوكول ينتظر.
تزيل طريقة MonadBFT التأخيرات غير الضرورية. إنها تحتفظ بهيكل HotStuff المتسلسل، ولكنها تزيل القاعدة الصارمة "يجب الانتظار لمدة Δ ثانية" في الحالات العادية. وهذا يعني أنها يمكن أن تتفوق على الأنظمة المقيدة زمنياً من حيث الاستجابة دون التضحية بالأمان.
في مسار غير سعيد (فشل القائد): في العديد من بروتوكولات الإجماع، عندما يفشل القائد في اقتراح كتلة، فإن العقد الأخرى لا تدرك ذلك إلا بعد انتهاء مهلة Δ. على سبيل المثال، إذا كانت Δ تساوي 1 ثانية، فإن هذه الفترة الزمنية تُعتبر مضيعة بشكل أساسي. طريقة MonadBFT في التعامل مع هذا الأمر مختلفة. عندما يكتشف المصدقون فقدان الاقتراح، فإنهم يقومون على الفور ببث رسالة انتهاء المهلة (TC أو شهادة انتهاء المهلة). بمجرد ظهور 2f+1 من انتهاء المهلة، سيتولى القائد التالي المسؤولية. الانتقال إلى وجهة نظر جديدة يتم تحفيزه بواسطة دليل يعتمد على عدد الأصوات بدلاً من أن يتم تحفيزه بواسطة الساعة.
مقارنة مع الإجماع في عائلة hotstuff
تأسس MonadBFT على أساس بروتوكولات الإجماع من سلسلة HotStuff، لكنه تميز من خلال تنفيذ مجموعة من الخصائص المثالية. كانت البروتوكولات المبكرة غالبًا ما تُحسَّن لأبعاد معينة، مثل سعة المعالجة المتوازية أو الاتصال الخطي، لكنها اضطرت للتضحية بجوانب أخرى. يجمع MonadBFT بشكل فريد بين تعقيد الرسائل الخطية، والتقديم المتوازن، ومقاومة قوية للانقسامات في النهاية، والاستجابة الفورية بدون تأخير ثابت، وآلية استرداد فعالة، مع الاحتفاظ أيضًا بتأكيد نهائي سريع وضمانات عالية التوافر. يلخص الجدول أدناه مقارنة بين MonadBFT وبروتوكولات BFT الأخرى التي تتناوب على القيادة في هذه الأبعاد الأساسية:
ماذا يعني هذا للمطورين والمستخدمين؟
بالنسبة للمطورين، فإن MonadBFT تعني عدة نقاط:
نموذج نهائي أبسط: باستخدام MonadBFT، يمكنك اعتبار الكتلة التي تحتوي على QC (تصويت الأغلبية الساحقة) قد تم تأكيدها نهائيًا، لأن البروتوكول سيؤكدها نهائيًا أو يفرض عقوبة. يمكن للمطورين العمل بأمان على تأكيد كتلة واحدة بثقة عالية.
تحسين تجربة المستخدم للتطبيقات: إذا كنت تبني تطبيقًا عالي الإنتاجية (مثل البورصات، الألعاب، إلخ)، فإن التأخير المنخفض لـ MonadBFT وخصائص مقاومة الفوكس ستتحول إلى تجربة مستخدم أكثر سلاسة. يمكن للمستخدمين رؤية تأكيد عملياتهم تقريبًا على الفور، ولن يواجهوا إعادة تنظيم أو تراجع مربك بشكل متكرر. بهذه الطريقة، يمكنك تصميم تطبيقات تتمتع بالثبات النهائي والتحديث السريع.
سلوك الحتمية: تقلل القواعد الأكثر صرامة لـ MonadBFT (مثل متطلبات إعادة الاقتراح) من عدم اليقين في تضمين الكتل. بسبب العوامل الزمنية الدقيقة مثل ما إذا كانت الأصوات أو انتهاء الوقت تصل إلى القائد أولاً، تكون "حالات الحافة" التي يتم فيها تضمين الكتل أو تخطيها أقل. تستبدل MonadBFT هذه الغموض الحساس للوقت بقواعد واضحة وأدلة قابلة للتحقق. وهذا يجعل من الأسهل استنتاج صحة البروتوكول واختباره. كما أنه يوفر أساسًا واضحًا لتحديد العقد المعطلة (على سبيل المثال، إذا فشل شخص ما في إعادة الاقتراح أو اقترح كتلة متعارضة، فإنك تعرف أنهم انتهكوا البروتوكول).
مساحة القابلية للتوسع: إذا كنت مطورًا يركز على القابلية للتوسع، فإن MonadBFT يوفر لك المزيد من المساحة قبل مواجهة الاختناقات. بالمقارنة مع البروتوكولات الثانوية، يمكنك بسهولة زيادة حجم الكتلة أو عدد المراجعين. بالإضافة إلى ذلك، فإن ميزات مثل نشر الكتل باستخدام الترميز القابل للحذف تعني أنك تستطيع دفع كميات كبيرة من البيانات عبر الشبكة دون استهلاك مفرط لعقدة واحدة. وهذا يجعل من الممكن استهداف معدل نقل أعلى، ويفتح مساحة تصميم لتطبيقات أكثر طموحًا على السلسلة.
بالنسبة للمستخدمين النهائيين: لن يفهم المستخدمون العاديون أي شيء مما نتحدث عنه هنا، لكنهم سيشعرون بتأثيره. مع MonadBFT كأساس لسلسلة Monad، يمكن للمستخدمين توقع جميع الميزات الجيدة التالية دون التضحية باللامركزية ومقاومة الرقابة.
تأكيد أسرع: ستتلقى المعاملات (مثل إرسال الرموز، تبادل الأصول، سك NFT، تنفيذ المعاملات) تأكيدًا سريعًا.
تقليل المفاجآت: تتسق حالة السلسلة بشكل أكبر، لأن أمورًا مثل الانقسامات النهائية، التي تنتمي في جوهرها إلى إعادة التنظيم، قد أزيلت.
العدالة والشفافية: تحسين الإجماع يعني بشكل غير مباشر أن تشغيل السلسلة أصبح أكثر عدلاً. لا يمكن لأي مُصادق فردي بسهولة مراجعة المعاملات أو التلاعب بترتيب الكتل.
استنتاج
باختصار، قدم MonadBFT أربع ابتكارات جوهرية على أساس إجماع HotStuff بأسلوب التدفق:
مقاومة هجمات تقسيم الذيل: MonadBFT هو أول بروتوكول BFT متسلسل يقضي على هجمات تقسيم الذيل. يحقق ذلك من خلال إعادة تقديم الكتلة التي تم التصويت عليها في المرة السابقة من قبل القائد التالي في حال فشل القائد السابق، أو عرض شهادة عدم التصديق (NEC) لإثبات أن هذه الكتلة تفتقر إلى الدعم. هذا يضمن عدم تجاهل أي كتلة حصلت على دعم الأغلبية الساحقة، مما يحمي مكافآت القادة الأمناء ويمنع إعادة التجميع الخبيثة واستخراج MEV عبر الكتل.
النهائية للتكهنات ذات الدورة الواحدة: يمكن للمتحققين تأكيد الكتلة بعد الاتصال ذو الدورة الواحدة (اقتراح قائد واحد وتصويت) ، مما يوفر للعملاء ضمانًا فوريًا للاحتواء. هذه التأكيدات التكهنية لن تستعاد إلا في حالة هجوم مكافئ للقائد (سلوك يمكن إثباته ومعاقبته) ، مما يجعلها في الممارسة فرضية أمان.
استجابة متفائلة: البروتوكول يعمل بسرعة الشبكة، دون تأخير متأصل. يتقدم القائد بالإجماع على الفور بعد تلقي الأصوات اللازمة، وتحدث تغييرات العرض على الفور بعد ملاحظة تجاوز العدد القانوني، بدلاً من الانتظار لفترة زمنية ثابتة. يقلل تصميم الاستجابة المتفائلة هذا من وقت الانتظار ويزيد من القدرة على المعالجة، بينما لا يزال قادرًا على المعالجة بشكل قوي في حالة حدوث عدم تزامن أو أعطال.
الاتصالات الخطية: على المسار السعيد (أي عندما يكون القائد صادقًا)، تكون تعقيد الرسائل والتحقق في علاقة خطية مع عدد المراجعين. يحتفظ MonadBFT بنمط الاتصال الفعال لـ HotStuff، باستخدام التوقيعات المجمعة وقادة بسيطين لبث إلى المراجعين، مما يسمح للبروتوكول بالتوسع إلى مئات المراجعين دون ظهور اختناق في الأداء.