تأمين تقنية البلوك تشين: دور التسامح البيزنطي مع الأخطاء

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

الآلية التي تجعل هذا ممكناً هي تحمل الأخطاء البيزنطية (BFT). وهي من أهم المفاهيم وأقلها فهماً في الأنظمة الموزعة، وتشكل أساس الأمان الذي تقوم عليه. بلوكشين التكنولوجيا، والتمويل اللامركزي، وسجلات المؤسسات، وإنترنت الأشياء.

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

مشكلة الجنرالات البيزنطيين: من أين بدأ كل شيء

لفهم مفهوم تحمل الأخطاء البيزنطية، يجب فهم المشكلة التي صُممت لحلها. وُصفت مشكلة الجنرالات البيزنطيين رسميًا لأول مرة عام 1982 من قِبل علماء الحاسوب ليزلي لامبورت وروبرت شوستاك ومارشال بيس في ورقة بحثية بعنوان "مشكلة الجنرالات البيزنطيين"، نُشرت في مجلة ACM Transactions on Programming Languages ​​and Systems.

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

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

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

أثبت لامبورت وشوستاك وبيس أن الحل ممكن فقط إذا كان أكثر من ثلثي الجنرالات موالين. بعبارة أخرى: يمكن لنظام مكون من n عقدة أن يتحمل على الأكثر f عقدة معيبة أو خبيثة طالما أن n لا يقل عن 3f + 1. مع أقل من ثلثي المشاركين النزيهين، لا يمكن لأي خوارزمية ضمان الاتفاق.

أصبحت هذه النتيجة الرياضية الأساس النظري لكل خوارزمية توافق BFT التي تلتها.

اقرأ أيضا: كيف تحمي التجزئة تقنية البلوكشين

ما هو تحمل الأخطاء البيزنطية؟

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

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

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

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

التسامح مع الأخطاء غير البيزنطية مقابل البيزنطية: تمييز حاسم

ليست جميع أنواع تحمل الأعطال متساوية. إن فهم الفرق بين تحمل الأعطال غير البيزنطية وتحمل الأعطال البيزنطية يوضح سبب صعوبة النوع الأخير وأهميته البالغة في تقنية البلوك تشين.

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

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

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

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

كيفية تحقيق العلاج بالتحول البيولوجي: الآليات الأساسية

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

وفرة

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

تواقيع التشفير

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

بروتوكولات الإجماع المنظم

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

الخصائص الثلاث التي تحدد إجماع BFT

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

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

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

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

قد يتعارض الأمان مع استمرارية الخدمة. تُظهر نظرية CAP الشهيرة في الأنظمة الموزعة أنه لا يمكن لأي نظام موزع ضمان الاتساق والتوافر وتحمل التقسيم في آنٍ واحد. تُجري بروتوكولات BFT مفاضلات مدروسة. تُعطي معظمها الأولوية للأمان على استمرارية الخدمة: فهي تتوقف بدلاً من تنفيذ نتيجة خاطئة محتملة إذا كان عدد كبير جدًا من العُقد يتصرف بشكل غير صحيح.

اقرأ أيضا: ما هو الإجماع في Blockchain؟

أنواع خوارزميات تحمل الأخطاء البيزنطية

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

التسامح البيزنطي العملي للخطأ (PBFT)

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

يعمل بروتوكول PBFT من خلال ثلاث مراحل اتصال بين العقد:

مرحلة التحضير المسبق: تستقبل العقدة الرئيسية (الرئيسية) طلب العميل، وتُخصص له رقم تسلسلي، ثم تُرسل رسالة تحضيرية إلى جميع العقد الأخرى (المسماة بالنسخ المتماثلة). تحتوي هذه الرسالة على الطلب، والرقم التسلسلي، ورقم العرض الحالي.

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

مرحلة الالتزام: بمجرد أن تجمع العقدة عددًا كافيًا من رسائل التحضير المطابقة، تبث رسالة تأكيد. تقوم النسخة المتماثلة بتنفيذ الطلب والرد على العميل فقط عندما تتلقى رسائل تأكيد من 2f + 1 عقدة على الأقل. يضمن هذا النصاب النهائي أنه حتى في حالة تعطل بعض العقد التي أرسلت رسائل التأكيد لاحقًا، يوجد عدد كافٍ من العقد المؤكدة لضمان استدامة النتيجة.

يقبل العميل النتيجة عندما يتلقى f + 1 ردود مطابقة، مما يضمن أن عقدة واحدة صادقة على الأقل قد أكدت النتيجة.

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

يستطيع بروتوكول PBFT تحمل ما يصل إلى ثلث (33%) العقد التي تحتوي على أخطاء بيزنطية. وقد ثبت رياضياً أن هذا الحد هو الحد الأقصى النظري لبروتوكولات BFT التقليدية.

استخدام Hyperledger Fabric لآلية الإجماع المشتقة من PBFT يُعدّ هذا المثال الأبرز في مجال المؤسسات. تستخدم منصة Fabric خدمة طلبات (كانت تعتمد سابقًا على PBFT، وأصبحت الآن تعتمد على Raft مع مسار ترقية BFT عبر SmartBFT) توفر إنتاجية عالية وزمن استجابة منخفض لتطبيقات المؤسسات. استخدمت Walmart منصة Hyperledger Fabric لتتبع المواد الغذائية من المزرعة إلى رفوف المتاجر، مما يُظهر تطبيقًا عمليًا لتقنية BFT في بيئة سلسلة توريد حقيقية.

الاتفاقية البيزنطية الفيدرالية (FBA)

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

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

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

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

أشياء ساخنة

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

يكمن الابتكار الرئيسي لـ HotStuff في تحقيق تعقيد اتصال خطي، O(n)، بدلاً من تعقيد الاتصال التربيعي O(n²) في PBFT. ويتحقق ذلك من خلال تصميم قائم على القائد، حيث يجمع القائد الأصوات في توقيعات عتبة، ويُجمّع n صوتًا فرديًا في برهان واحد مُختصر. وهذا يعني أن عبء الاتصال لا يتزايد بشكل كبير مع نمو مجموعة المُدقّقين.

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

يُضحي بروتوكول HotStuff بزمن استجابة أعلى قليلاً (ثلاث جولات ذهاب وإياب مقابل جولتين في PBFT) مقابل قابلية توسع أفضل بكثير. بالنسبة لمجموعات التحقق الكبيرة التي تضم مئات أو آلاف العُقد، تُعد هذه المقايضة مُفضلة للغاية. يعتمد كل من بروتوكول CometBFT (المعروف سابقًا باسم Tendermint Core) في نظام Cosmos البيئي، وبروتوكول الإجماع المُستخدم في Aptos وSui، على تصميمات عائلة HotStuff.

تندرمينت وكوميت بي إف تي

Tendermint هي خوارزمية إجماع BFT مصممة خصيصًا للاستخدام في تقنية البلوك تشين، وقد قدمها جاي كوون في عام 2014. وهي تفصل طبقة الإجماع عن طبقة التطبيق من خلال واجهة تطبيق البلوك تشين (ABCI)، مما يسمح لأي تطبيق باستخدام إجماع Tendermint دون الحاجة إلى بناء البنية التحتية الخاصة به للشبكات والإجماع.

تُحقق شبكة تندرمينت الإجماع على مراحل. في كل مرحلة، يُعلن مُقترح عن كتلة. يُصوّت المُدقّقون على مرحلتين (التصويت المُسبق والتأكيد المُسبق). تُؤكد الكتلة عندما يُرسل ثلثا المُدقّقين على الأقل أصوات تأكيد مُسبق مُتطابقة. إذا فشلت المرحلة (بسبب خلل في المُقترح أو بطء الشبكة)، تبدأ مرحلة جديدة مع مُقترح جديد.

يُوفر نظام Tendermint نهائية فورية: فبمجرد إتمام عملية تسجيل كتلة، لا يمكن التراجع عنها دون انتهاك فرضية أغلبية الثلثين الصادقة. تُعد هذه ميزة هامة مقارنةً بأنظمة النهائيية الاحتمالية مثل إثبات العمل، حيث لا تُعتبر المعاملة نهائية إلا بعد إضافة عدة كتل لاحقة.

تُعالج Tendermint آلاف المعاملات في الثانية الواحدة بزمن استجابة لا يتجاوز ثانية واحدة. وفي عام 2023، أُعيد تسميتها إلى CometBFT لتعكس نموذج حوكمة مجتمعية أوسع. يستخدم Cosmos Hub وكل سلسلة مبنية على Cosmos SDK (والتي يزيد عددها عن 100 سلسلة نشطة بحلول عام 2025) CometBFT كطبقة إجماع. ومن الأمثلة البارزة على ذلك توقف سلسلة Cosmos Hub v17.1، والذي لم يكن ناتجًا عن خلل في آلية إثبات السلامة الأساسية لـ CometBFT، بل عن خطأ برمجي في كود تحديث مجموعة المدققين حول EndBlock، مما يُوضح كيف أن ضمانات BFT موجودة ضمن بنية تنفيذية كاملة، وليست بمعزل نظري.

BFT في إثبات الحصة: كاسبر وإيثيريوم

أدى انتقال إيثيريوم إلى آلية إثبات الحصة من خلال عملية الدمج في سبتمبر 2022 إلى إدخال أداة Casper FFG (أداة التحقق النهائي الودية) بالاشتراك مع اختيار التفرع LMD-GHOST، لتشكيل بروتوكول إجماع Gasper. يوفر Casper آلية تحقق نهائية على غرار BFT فوق مجموعة مدققي إثبات الحصة.

يعمل كاسبر كآلية نهائية تُضاف إلى عملية إنتاج الكتل. يصوّت المدققون على نقاط التحقق كل 32 خانة (حوالي 6.4 دقيقة). عندما يصوّت ثلثا إجمالي الإيثيريوم المُودع لصالح نقطة تحقق، تُعتبر "مُبرّرة". وعندما تُبرّر نقطتا تحقق متتاليتان، تُعتبر الأولى "نهائية". لا يمكن التراجع عن الكتل النهائية إلا إذا قام المهاجم بحرق ثلث الإيثيريوم المُودع على الأقل، مما يُنشئ ضمانة اقتصادية قوية ضدّ هجمات الاختراق.

تُعدّ آلية التخفيض الاقتصادي هذه نسخةً مُعدّلة من إيثيريوم لنظرية BFT الكلاسيكية: فبدلاً من الضمانات الرياضية البحتة، يتم فرض الحسم من خلال التكلفة الاقتصادية لسوء السلوك. إذا وقّع مُدقّق على كتل متضاربة، فإنه يخسر كامل حصته (يُخفّض رصيده). يُحفّز التهديد بفقدان رأس مال كبير السلوك النزيه على التوافق مع المصلحة الاقتصادية الذاتية.

التسامح مع الأخطاء البيزنطية في إثبات العمل

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

في آلية إثبات العمل (PoW) الخاصة ببيتكوين، تعني خاصية تحمل الأخطاء البيزنطية أنه طالما يسيطر المعدنون النزيهون على أكثر من 50% من إجمالي قوة التجزئة للشبكة، فلن يتمكن المهاجم الذي يسيطر على أقل من 50% من إعادة كتابة سجل المعاملات المؤكدة. وتزداد تكلفة هجوم 51% مع زيادة معدل تجزئة بيتكوين وصعوبة ألغاز التعدين.

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

المقايضة مهمة: يوفر PoW تقنية BFT في بيئة غير مرخصة على حساب استهلاك هائل للطاقة، وبطء في الوصول إلى النتيجة النهائية (10-60 دقيقة)، وضعف قابلية الهجوم بنسبة 51% الذي لا تواجهه بروتوكولات BFT الكلاسيكية أبدًا تحت عتبة معينة.

مقارنة بروتوكولات BFT: نظرة عامة مباشرة

بروتوكول	عتبة الخطأ	النهائية	تعقيد الرسالة	أفضل ل
PBFT (كاسترو-ليسكوف)	ثلث بيزنطي	لحظي	O(n تربيع)	شبكات صغيرة مرخصة
أشياء ساخنة	ثلث بيزنطي	لحظي	خطي O(n)	مجموعات التحقق الكبيرة
تندرمينت / كوميت بي إف تي	ثلث بيزنطي	فوري (~1 ثانية)	O (ن)	سلاسل كوزموس، سلاسل الكتل العامة
اتفاقية بيزنطية موحدة	شرائح النصاب المتداخلة	3-5 ثواني	متغير	شبكات الدفع (ستيلر، ريبل)
كاسبر إف إف جي (إيثيريوم PoS)	ثلث الإيثيريوم المودع	كل 6.4 دقيقة	O(n) مع تجميع BLS	سلاسل الكتل العامة لإثبات الحصة
بيتكوين إثبات العمل	قوة التجزئة 50%	احتمالي (6+ كتل)	بث O(1)	شبكات بدون أذونات وبدون ثقة
ألغوراند بي إيه	ثلث بيزنطي	~ 4.5 ثانية	دون خطي مع VRF	بدون إذن وبنتيجة نهائية سريعة

تطبيقات عملية لنظرية التعلم القائم على السلوك في عام 2025

هايبرليدجر فابريك وبلوك تشين المؤسسات

يُعدّ Hyperledger Fabric إطار عمل بلوك تشين الأكثر استخدامًا في بيئات الإنتاج المؤسسية. فهو يدعم نظام تتبع الأغذية لدى Walmart، وحلول سلسلة التوريد لدى IBM، ومئات التطبيقات المالية واللوجستية. شهدت خدمة الطلبات في Fabric تطورًا ملحوظًا: فبعد الانتقال من PBFT إلى Raft (وهو بروتوكول توافق آراء يتحمل الأعطال لتسهيل عمليات النشر)، قدّم Fabric خدمة SmartBFT كخدمة طلبات تتحمل الأخطاء البيزنطية للبيئات التي تتطلب ضمانات كاملة لتحمل الأخطاء البيزنطية. تتبع SmartBFT نمط البث ثلاثي المراحل المألوف الموروث من PBFT، وتوفر إنتاجية عالية مع زمن استجابة منخفض، مما يجعلها مناسبة لتطبيقات المؤسسات.

اتفاقية ستيلر البيزنطية الموحدة في المدفوعات العالمية

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

بروتوكول اتفاقية ألغوراند البيزنطية

تستخدم Algorand نهجًا فريدًا لخوارزمية BFT يُسمى إثبات الحصة الخالص، مُدمجًا مع فرز تشفيري. في كل جولة إجماع، يتم اختيار لجنة عشوائية من المدققين باستخدام دالة عشوائية قابلة للتحقق (VRF). أعضاء اللجنة المُختارون فقط هم من يعلمون باختيارهم (ويمكنهم إثبات ذلك للآخرين)، مما يجعل الهجمات المُستهدفة ضد أعضاء اللجنة شبه مستحيلة، لأن المُهاجم لا يعرف من يستهدف مُسبقًا.

يحقق بروتوكول BA الخاص بـ Algorand إتمام المعاملات في غضون 4.5 ثانية تقريبًا، مع معدل نقل بيانات يتجاوز 1,000 معاملة في الثانية في بيئة الإنتاج. يوفر تصميمه تقنية BFT في بيئة مفتوحة المصدر دون تكلفة الطاقة اللازمة لإثبات العمل، وهو ما يميزه عن كل من Bitcoin وأنظمة BFT التقليدية ذات الأذونات.

نظام كوزموس البيئي ومذنب بي إف تي

يضم نظام Cosmos البيئي في عام 2025 أكثر من 100 سلسلة كتل سيادية، تستخدم جميعها بروتوكول CometBFT كطبقة إجماع. يعتمد بروتوكول الاتصال بين سلاسل الكتل (IBC) على ضمانة الإتمام الفوري التي يوفرها CometBFT: لا تكون إثباتات IBC صالحة إلا لأن مركز Cosmos وسلاسل الطرف المقابل قادرة على إثبات أن المعاملة قد أُنجزت بالفعل، وليس مجرد احتمال إتمامها. بدون ضمانات الإتمام القوية التي يوفرها إجماع BFT، سيكون تأمين هذا النوع من الاتصالات بين السلاسل أكثر صعوبة. يعالج النظام البيئي مليارات الدولارات من التحويلات القيمة اليومية بين السلاسل، وكلها مؤمنة بواسطة إجماع CometBFT المقاوم للأخطاء البيزنطية.

مطعم كلايتن إسطنبول بي إف تي

تستخدم منصة Klaytn، التي طورتها شركة Kakao الكورية الجنوبية، بروتوكول IBFT (Istanbul BFT) الذي يعمل بسرعة تتجاوز 4,000 معاملة في الثانية، مع زمن إنشاء كتلة يبلغ ثانية واحدة. يُعد IBFT نسخة متوافقة مع آلة إيثيريوم الافتراضية (EVM)، مما يُمكّن Klaytn من الحفاظ على توافقها مع أدوات إيثيريوم، مع تحقيق أداء أعلى بكثير من الطبقة الأساسية لإيثيريوم. يتيح تصميمها الهجين، العام والخاص، للمؤسسات تشغيل سلاسل جانبية مُرخصة، بينما تحافظ السلسلة الرئيسية العامة على ضمانات BFT اللامركزية.

أساليب الهجوم التي يتصدى لها نظام BFT

إن فهم ما يحمي منه نظام BFT يوضح قيمته وحدوده.

هجمات الإنفاق المزدوج

في هجوم الإنفاق المزدوج، يحاول المهاجم إنفاق نفس الأموال مرتين عن طريق بث معاملتين متعارضتين في آن واحد. يمنع نظام إجماع BFT هذا الهجوم باشتراط موافقة ثلثي المدققين على أمر معاملة واحد قبل إتمام أي معاملة. بمجرد إتمام معاملة في نظام BFT، لا يمكن إتمام أي معاملة منافسة لنفس الأموال دون تجاوز عتبة الثلثين.

هجمات الكسوف

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

هجمات سيبيل

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

عتبة الهجوم بنسبة 33%

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

لهذا السبب، يُعدّ حدّ الـ 33% عاملاً حاسماً في أي نموذج أمني لنظام قائم على تقنية BFT. تُضيف بروتوكولات مثل Casper الخاصة بشبكة Ethereum آلية خفض اقتصادي إضافية إلى جانب حدّ BFT: فحتى لو وصل المهاجم إلى ثلث كمية ETH المُودعة، فإنّ نجاحه في اختراق آلية الإنهاء سيُجبره على خسارة كامل حصته، ما يجعل الهجوم مُدمّراً اقتصادياً بالنسبة له.

هجمات التلاعب بالرسائل وإعادة تشغيلها

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

مزايا تحمل الأخطاء البيزنطية في تقنية البلوك تشين

حتمية، نهائية المعاملات الفورية

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

يُعدّ هذا الأمر بالغ الأهمية للتطبيقات المالية. لا يُمكن لشبكات الدفع أن تعمل بكفاءة إذا كان بالإمكان إلغاء كل معاملة بعد ساعات. تتطلب تطبيقات التمويل اللامركزي ضمانًا نهائيًا موثوقًا به لعمليات التصفية والقروض وتسوية المشتقات. يتطلب التواصل بين السلاسل عبر بروتوكولات مثل IBC أن تُثبت إحدى السلاسل للأخرى أن معاملة مُحددة نهائية بالفعل.

كفاءة إستهلاك الطاقة

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

القدرة على الصمود في وجه أعطال الشبكة والعُقد الخبيثة

يستمر بروتوكول BFT المُطبَّق جيدًا في العمل بشكل صحيح طالما بقي ثلثا العُقد سليمين ومتصلين. وهو يتعامل مع حالات التعطل المفاجئ، وانقطاعات الشبكة (مؤقتًا)، والعُقد البيزنطية، ومجموعات هذه الحالات في آنٍ واحد. هذه المرونة هي ما تحتاجه شبكات البلوك تشين العامة تحديدًا: فهي لا تستطيع معرفة العُقد التي ستتعطل أو تتصرف بشكل ضار مسبقًا، لذا يجب على بروتوكول الإجماع التعامل مع حالات التعطل العشوائية بسلاسة.

إنتاجية عالية للأنظمة المرخصة

تُحقق بروتوكولات BFT في بيئات مُرخصة مثل Hyperledger Fabric إنتاجية عالية جدًا للمعاملات. ولأن مجموعة المُدقّقين ثابتة ومعروفة، فإن عبء الاتصال قابل للتنبؤ والتحسين. تُحقق عمليات النشر المؤسسية بشكل روتيني آلاف المعاملات في الثانية مع توقيت نهائي أقل من ثانية، وهو أداء مستحيل مع إثبات العمل، ويُمثل تحديًا حتى للعديد من أنظمة إثبات الحصة.

الحماية من الأخطاء البيزنطية والهجمات المنسقة

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

تحديات وقيود تحمل الأخطاء البيزنطية

قيود قابلية التوسع

يكمن التحدي الأساسي في خوارزميات BFT التقليدية في أن تعقيد الاتصال يزداد مع ازدياد عدد المدققين. ونظرًا لتعقيد الرسائل في خوارزمية PBFT، والذي يبلغ O(n²)، فإن إضافة المزيد من المدققين يصبح أمرًا غير عملي بسرعة. فعلى سبيل المثال، تتطلب شبكة تضم 100 مدقق PBFT ما يصل إلى 10,000 رسالة لكل جولة إجماع. وعند 1,000 مدقق، يصل هذا العدد إلى مليون رسالة.

لقد عالجت تقنية HotStuff ومشتقاتها هذه المشكلة بشكل جذري من خلال تقليل التعقيد إلى O(n) الخطي عبر تجميع التوقيعات عند العتبة. ولكن حتى التعقيد الخطي له حدود عملية. فمعظم سلاسل الكتل العامة الحالية القائمة على BFT تحتفظ بمجموعات من المدققين تتراوح بين المئات إلى بضعة آلاف، بدلاً من عشرات الآلاف التي تتضمنها شبكة تعدين بيتكوين.

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

الاعتماد على مجموعة مدققين معروفة

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

النفقات العامة للأداء

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

مدى تعقيد التنفيذ الصحيح

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

مستوى الضعف عند عتبة 33%

يُعدّ شرط الأغلبية الصادقة بنسبة 33% نقطة قوة في خوارزمية BFT، ولكنه في الوقت نفسه يُمثّل حدّها الأقصى. فما دام هذا الشرط قائمًا، يبقى النظام آمنًا. ولكن إذا تمكّن مهاجم من السيطرة على ثلث أو أكثر من مجموعة المُدقّقين (أو ثلث القيمة المُودعة في أنظمة PoS-BFT)، فإن ضمانات الأمان تنهار. عمليًا، يتطلّب هذا موارد هائلة للشبكات القائمة، بينما تكون الشبكات الأصغر ذات القيمة الإجمالية المُودعة الأقل أكثر عرضةً لهذا الهجوم.

مستقبل تحمل الأخطاء البيزنطية في تقنية البلوك تشين

نظرية BFT ما بعد الكم

تعتمد بروتوكولات BFT الحالية على أنظمة توقيع تشفيرية عرضة للاختراق بواسطة الحواسيب الكمومية. فبإمكان حاسوب كمومي قوي بما يكفي اختراق تشفير المفتاح العام الذي تستخدمه بروتوكولات BFT للتحقق من صحة أصوات المدققين. وتجري أبحاث BFT ما بعد الكمومية حاليًا استكشاف أنظمة توقيع مقاومة للهجمات الكمومية، بما في ذلك التشفير القائم على الشبكات والتشفير القائم على التجزئة. وتُطبّق محفظة Trezor Safe 7، وهي محفظة أجهزة، بالفعل تشفيرًا ما بعد الكمومي مُعتمدًا من قِبل المعهد الوطني للمعايير والتكنولوجيا (NIST) للتحقق من البرامج الثابتة، مما يُشير إلى أن النظام البيئي للتشفير الأوسع يتجه نحو مقاومة الكموم. وسيتعين على بروتوكولات BFT أن تحذو حذوها مع تقدم الحوسبة الكمومية.

بروتوكولات BFT غير المتزامنة

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

قابلية التوسع من خلال التجزئة والطبقة 2

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

BFT في إنترنت الأشياء

تُقدّم شبكات إنترنت الأشياء حالة استخدام مُقنعة لآلية توافق BFT. إذ يجب على مليارات أجهزة إنترنت الأشياء تنسيق البيانات ومشاركتها بشكل آمن عبر شبكات موزعة، حيث قد تتعرض الأجهزة الفردية للاختراق المادي، أو نفاد الطاقة، أو التلاعب المتعمد. تُشير الأبحاث التي أُجريت عام 2025 إلى أن الخوارزميات القائمة على BFT تُوفّر زمن الاستجابة المنخفض الذي تتطلبه تطبيقات إنترنت الأشياء، على الرغم من أن تكلفتها الحسابية العالية ونسبة تعرضها للهجمات (33%) تستلزم استخدام بنى شبكية مُرخصة لنشر تطبيقات إنترنت الأشياء. الإنترنت الأشياء يمثل هذا أحد أسرع المجالات نمواً في أبحاث وتطبيقات تقنية BFT.

BFT في التمويل اللامركزي

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

قابلية التشغيل البيني بين أنظمة BFT

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

الأسئلة الشائعة