بروتوكولات BFT: PBFT وTendermint

تطرح مسألة الجنرالات البيزنطيين، التي صاغها Lamport وShostak وPease عام 1982، السؤال الآتي: هل يستطيع نظام موزّع الوصول إلى إجماع عندما يرسل بعض المشاركين رسائل متناقضة؟ سُمّيت المسألة نسبةً إلى جنرالات بيزنطيين يجب أن ينسّقوا هجومًا، لكن قد يكون بينهم خونة يرسلون أوامر متعارضة. ويكون النظام متحمّلًا للأعطال البيزنطية (BFT) إذا توصّل إلى إجماع صحيح رغم وجود ما يصل إلى f من العقد الخبيثة بين 3f+1 عقدة إجمالًا. ويُعدّ BFT المعيار الذهبي لإجماع سلاسل الكتل التي تتطلب الأمان في ظل ظروف عدائية.

كان PBFT (من Castro وLiskov عام 1999) أول بروتوكول BFT عملي، إذ أثبت إمكانية تشغيل BFT بكفاءة في الأنظمة الحقيقية. يعمل PBFT ضمن جولات (terms)، لكل منها أساسي (قائد) معيّن. وتتكون العملية العادية من ثلاث مراحل: pre-prepare (يبث الأساسي طلب العميل ورقم التسلسل)، وprepare (تبث النسخ اتفاقها مع رقم التسلسل)، وcommit (تبث النسخ تأكيد الالتزام). يُنفَّذ الطلب بمجرد أن تجمع إحدى النسخ 2f+1 من رسائل commit المتطابقة. ويوفّر PBFT الأمان والحيوية بافتراض أن عدد النسخ البيزنطية أقل من ثلث النسخ.

يتمثل القيد الأساسي في PBFT في تعقيد الرسائل O(n^2) لكل طلب: إذ ترسل كل واحدة من النسخ n رسائل إلى جميع النسخ الأخرى في مرحلتي prepare وcommit. وعند وجود n=100 نسخة، يولّد كل طلب نحو 10,000 رسالة. وهذا يجعل PBFT غير عملي لمجموعات المدقّقين الكبيرة. وقد أمضى مجتمع أبحاث BFT عقدين في تحسين ذلك؛ فخفّض BFT-SMART الثوابت، وحقق HotStuff تعقيدًا خطيًا للرسائل من خلال نموذج تمرير يعتمد على القائد، وكيّف Tendermint أفكار PBFT لاستخدامها في سلاسل الكتل العامة.

عندما يُشتبه في أن أساسي PBFT معيب (بسبب انتهاء المهلة)، تبدأ النسخ تغيير العرض. تبث كل نسخة رسالة view-change تتضمن حالتها (القيم التي أُعدّت في العرض القديم). ويجمع الأساسي الجديد 2f+1 من رسائل view-change، ثم ينشئ رسالة new-view تثبت اتساق انتقال الحالة مع القيم التي سبق الالتزام بها، ويبثها. وتغييرات العرض مكلفة، إذ تتطلب O(n^3) من الرسائل، وكانت تمثل عنق زجاجة عمليًا. وتعالج تحسينات مثل شهادة view-change في PBFT وتصميم HotStuff ذي المعالجة المتسلسلة هذه المشكلة.

يكيّف Tendermint (عام 2014، بواسطة Kwon؛ وبدأ استخدامه الإنتاجي في Cosmos عام 2019) بروتوكول PBFT لبيئات سلاسل الكتل العامة. ويضم Tendermint ثلاث مراحل لكل كتلة: propose (يبث القائد الكتلة المقترحة)، وprevote (يصوّت المدقّقون على المقترح)، وprecommit (يصوّت المدقّقون للالتزام بعد رؤية 2/3 من أصوات prevote). وتُلتزم الكتلة عندما يجمع أحد المدقّقين 2/3 من أصوات precommit، وهو ما يسمى شهادة النصاب. ويتناوب المدقّقون على دور المقترح بترتيب round-robin موزون حسب الحصة. وإذا انتهت الجولة دون التزام، ينتقل المدقّقون إلى الجولة التالية مع تصويت nil.

يوفّر Tendermint أمانًا قويًا: فالكتلة الملتزم بها نهائية ولا يمكن التراجع عنها ما دام أقل من ثلث الحصة بيزنطيًا. وهذه نهائية متزامنة، إذ لا توجد تشعبات بعد الالتزام. وتتطلب الحيوية شبكة متزامنة جزئيًا؛ فالبروتوكول يحرز تقدمًا بمجرد أن تصبح تأخيرات الرسائل محدودة، لكنه لا يتطلب التزامن باستمرار. والمقايضة بين الحيوية والأمان أساسية: يضحّي Tendermint بالحيوية (وقد يتوقف إذا انقسمت الشبكة) لضمان الأمان، بخلاف سلاسل مثل Bitcoin التي تضحّي بالأمان (وتسمح بتشعبات مؤقتة) لصالح الحيوية.

تُعدّ آلية قفل التصويت من الآليات المهمة في Tendermint. فعندما يرسل مدقّق تصويت precommit لكتلة في الجولة r، يُقفل على تلك الكتلة. وفي الجولات اللاحقة، لا يجوز للمدقّق المقفَل أن يرسل prevote إلا للكتلة المقفَل عليها (أو تصويت nil إذا تلقى دليلًا على أن الكتلة لم تُلتزم). ويمنع ذلك الالتزامات المتناقضة بين الجولات. ولا يمكن للمدقّق إلغاء القفل إلا إذا تلقى polka (2/3 من أصوات prevote) لكتلة مختلفة في جولة لاحقة، مما يثبت أن الكتلة الأصلية لم تُلتزم.

يعتمد Cosmos Inter-Blockchain Communication (IBC) على النهائية الفورية في Tendermint لإجراء التحويلات بين السلاسل. ويتتبع عميل Tendermint الخفيف مجموعة المدقّقين وآخر التزام (رأس كتلة مرفقًا بتوقيعات precommit من 2/3). وللتحقق من حزمة واردة من السلسلة A، تتحقق وحدة IBC في السلسلة B من شهادة النصاب، أي أن 2/3 من مدقّقي السلسلة A وقّعوا رأس الكتلة المعني. وبذلك يعتمد أمان IBC على ضمان BFT الذي يقدمه Tendermint: يصبح التحويل بين السلاسل نهائيًا فور الالتزام بكتلة المصدر.

يحقق HotStuff (Yin وآخرون، 2018؛ وهو الأساس لـ Facebook's LibraBFT/DiemBFT، ويُستخدم الآن في Aptos وSui) تعقيدًا خطيًا للرسائل O(n) في كل جولة إجماع باستخدام طوبولوجيا نجمية: يرسل جميع المدقّقين أصواتهم إلى القائد، ويجمع القائد الأصوات في توقيع ذي عتبة (QC، شهادة النصاب)، ثم يبث QC. ويستخدم HotStuff تصميمًا متسلسلًا من ثلاث مراحل، بحيث تمتد براهين الأمان عبر ثلاث شهادات QC متتالية، مما يتيح المعالجة المتسلسلة. ويجعل التعقيد الخطي HotStuff عمليًا لما بين 100 و300 مدقّق، كما هو مطبّق في Aptos وSui.

تستخدم سلاسل الكتل المؤسسية (Hyperledger Fabric وBesu وQuorum) إجماع BFT في الشبكات المصرّح بها، حيث تكون هوية المدقّق معروفة. وتوفّر خدمة الترتيب المعتمدة على Raft في Hyperledger Fabric تحمّل أعطال التوقف (وليس الأعطال البيزنطية) للاتحادات الموثوقة. وتستهدف المرحلة المخطط لها في BFT لدى Fabric مكتبة SmartBFT، وهي تطبيق قائم على مكتبة. وتستخدم R3 Corda مجموعة notary مع BFT-SMART لمنع الإنفاق المزدوج. ويعكس الاختيار بين CFT وBFT افتراضات الثقة: إذ يلزم BFT عندما قد يكون المدقّقون عدائيين، بينما يكفي CFT عندما يكونون غير موثوقين فحسب.

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

ما الحد الأقصى لنسبة المدقّقين الذين يمكن أن يكونوا بيزنطيين في بروتوكول BFT قياسي مع الحفاظ على الأمان؟

تضمن بروتوكولات BFT الإجماع رغم وجود ما يصل إلى ثلث المدقّقين الخبيثين. وقد أثبت PBFT (عام 1999) إمكانية تطبيق BFT عمليًا، لكنه يملك تعقيدًا للرسائل O(n^2). ويكيّف Tendermint بروتوكول PBFT لسلاسل الكتل مع نهائية فورية وقفل للتصويت. ويحقق HotStuff تعقيدًا O(n) من خلال شهادات نصاب بتوقيعات ذات عتبة، ويُستخدم في Aptos وSui. ويستفيد Cosmos IBC من النهائية الفورية في Tendermint لإجراء تحويلات موثَّقة بين السلاسل. وتستخدم سلاسل الكتل المؤسسية BFT-SMART أو Raft بحسب ما إذا كانت الأعطال المتوقعة بيزنطية أم أعطال توقف فحسب.