SafeStake ، وهو عبارة عن طبقة وسطى مُصغَّرة من الثقة تعزز لامركزية ETH 2.0 Staking ، تستخدم بروتوكول الإجماع الأساسي HotStuff – وهو متغير أكثر قوة من بروتوكول التسامح البيزنطي للخطأ (BFT) الذي يساعد على تحسين الأمان وتقليل احتمالات خفض المدققين أثناء ETH 2.0 Staking.
ولكن ما هو بروتوكول HotStuff؟ هل هو نفس البروتوكول الذي اعتبره Facebook لتحقيق توافق مع عملة LIBRA؟
في هذا المنشور ، نريد التعمق في آلية إجماع HotStuff ، بحيث يمكن لمستخدمي ParaState الذين يستخدمون منتج SafeStake الخاص بنا خلال ETH 2.0 Staking معرفة المزيد حول الآلية التي تساعدهم على تحسين دخلهم السلبي ، ولماذا هو جزء من جهودنا في ParaState لتقديم أفضل ما في تقنية blockchain إلى نظامنا البيئي.
التسامح البيزنطي للخطأ (BFT): أصل HotStuff
يتم تنفيذ آليات إجماع التسامح البيزنطي للخطأ (BFT) على سلاسل الكتل كبديل لآليات إثبات العمل (PoW) ، بهدف تحقيق نفس الأمان الذي توفره PoW دون الحاجة إلى استهلاك عالي للطاقة لبروتوكول PoW.
تحل عمليتها العامة واحدة من أكبر مشاكل البلوكتشين: المشكلة المعروفة للجنرالات البيزنطيين. إذا كنت تريد معرفة المزيد عن هذا الموضوع ، يمكنك الرجوع إلى أعمال ليزلي لامبورت وروبرت شوستاك ومارشال بيز “ACM Transactions on Programming Languages and Systems” ، يوليو 1982.
من حيث الجوهر ، يعتبر الفاعل غير العادل في شبكة لامركزية “بيزنطيًا”. أحد الإنجازات العظيمة لساتوشي ناكاموتو هو تطوير بروتوكول إجماعي ، أي آلية إثبات العمل ، لحل المشكلة العامة البيزنطية.
في تطبيق blockchain ، يتم تحقيق حل مشكلة الجنرالات البيزنطيين من خلال القادة المخلصين الذين يلتزمون بنمط السلوك المحدد مسبقًا ، والمعروف باسم خوارزميات الإجماع.
تحل خوارزمية BFT النموذجية هذه المشكلة على النحو التالي:
يحصي كل ملازم مخلص جميع الرسائل التي تلقاها من رفاقه. سيقول البعض للهجوم ، بينما ينتظر البعض الآخر.
لا يعرف أيهم مخلص أم لا ، يختار الرسالة للهجوم (ما الإجراء الذي يجب اتخاذه) بناءً على الرسالة التي حصلت على أكبر عدد من الأصوات.
إذا تصرف جميع الملازمين المخلصين بهذه الطريقة ، فهناك ضمان رياضي بأنهم سيتخذون القرار الصحيح طالما أن أقل من من الأعضاء هم من البيزنطيين.
يستخدم BFT بشكل أساسي الصيغة البسيطة “3f + 1 = x” لتحديد النسبة التي يمكن للنظام أن يتحملها من الجهات الفاعلة المخلصين / غير الموالين الذين يشكلون الشبكة.
وبالتالي ، إذا كانت f تساوي 1 ، فستكون هناك حاجة إلى 4 عقد على الأقل (ملازم) لكي تعمل آلية توافق الآراء BFT.
عندما تم تصميم هذا البروتوكول في الأصل ، كان حجم النظام النموذجي n = 4 أو n = 7 ، تم نشره على شبكة المنطقة المحلية. ومع ذلك ، فإن الاهتمام المتجدد باستخدامه في شبكات البلوكتشين يستدعي حلولًا يمكن توسيع نطاقها ليشمل ns أكبر بكثير.
منذ إدخال التسامح البيزنطي العملي للخطأ (PBFT) ، وهو الحل العملي الأول لتكرار BFT في نموذج التزامن الجزئي ، تم بناء العديد من الاشتقاقات حول BFT بناءً على مرحلتيها ، بهدف عملي وهو أن القائد المستقر يمكن أن يعزز الإجماع. القرار في جولتين فقط من الرسائل:
مرحلة أولى تضمن تفرد الاقتراح من خلال تشكيل شهادة النصاب (QC) المكونة من أصوات (n-f).
تضمن المرحلة الثانية أن القائد التالي يمكنه إقناع النسخ المتماثلة بالتصويت على اقتراح آمن.في هذا النظام ، كما أشرنا من قبل ، تعتبر خوارزمية القائد الجديد لجمع المعلومات واقتراحها على النسخ المتماثلة – التي تسمى تغيير العرض * – هي مركز النسخ المتماثل.
لكن تبديل العرض القائم على النموذج للمرحلتين السابقتين بعيد كل البعد عن الوضوح ، وعرضة للخطأ ، ويتعرض لعقوبة اتصال كبيرة حتى بالنسبة للأنظمة متوسطة الحجم.
حتى مع المصادقات فقط (التوقيعات الرقمية أو أكواد مصادقة الرسائل) ، فإن إرسال اقتراح جديد له بصمة اتصال من الدرجة الثانية [O (n ^ 2)] في PBFT مما يؤدي إلى تحدي القياس في جميع الاشتقاقات القائمة على PBFT.
على الرغم من وجود العديد من الاختلافات في PBFT التي تنفذها العديد من منصات البلوكتشين، فإننا نريد في هذا المنشور تسليط الضوء على الخصائص الرئيسية لـ qBFT و iBFT ، والتي تعتبر من بين أكثر بروتوكولات BFT قوة داخل عائلة بروتوكولات BFT والتي كانت بمثابة نقطة مرجعية لـ SafeStake في اختيار HotStuff كآلية إجماع.
الغرض الفوري: تم اقتراح كتلة واحدة فقط عند ارتفاع سلسلة معين.
مجموعة المدقق الديناميكي
المرونة البيزنطية المثلى عند العمل في شبكة متزامنة جزئيًا
تعقيد رسالة O (N ^ 2)
يعتمد QBFT على بروتوكول اتفاقية BFT المقدم في IBFT-Moniz.
تتطلب هذه الشبكات تشغيل ⅔ من المدققين لإنشاء كتل وشبكات باستخدام هذه البروتوكولات ، حيث يمكن لثلاثة أو أقل من المدققين إنتاج كتل ولكنهم لا يضمنون نهائية عند التشغيل في بيئات قاسية.
في حين أنها تحقق عوائد ممتازة مقارنة بـ PoW ، فإن الوقت لإضافة كتل جديدة يزداد مع زيادة عدد المدققين.
يتمثل الاختلاف الرئيسي بين qBFT و iBFT في أن المدققين يتناوبون على إنشاء الكتلة التالية ضمن مجموعة مدقق ديناميكي غير عشوائي.
يزيل iBFT تفرع السلسلة وبالتالي يدعم إنهاء المعاملة.
كلا البروتوكولين أكثر ملاءمة للاستخدام في شبكات blockchain الخاصة أو شبكات الكونسورتيوم.
في حالة iBFT ، تكون الخوارزمية حتمية وقائمة على القائد ومرنة على النحو الأمثل وتتسامح مع العمليات المعيبة من n حيث n≥3f + 1.
HotStuff: أول بروتوكول تكرار BFT متزامن جزئيًا
أصبح التسامح مع الخطأ البيزنطي غير المتزامن أحد أكثر الطرق شيوعًا لتحقيق الإجماع في مساحة تقنية دفتر الأستاذ الموزع. ومع ذلك ، يجادل بعض النقاد بأنهم بروتوكولات بطيئة ومكلفة للتشغيل ، فضلاً عن كونها مقيدة ذاتيًا نظرًا لوجود حد أعلى لتأخير الشبكة.
تم تطوير HotStuff بواسطة الباحثين Maofan Yin و Dahlia Malkhi و Michael K. Reiter و Ittai Abraham و Guy Gueta وتم اقتراحه بواسطة VMware Research في مارس 2018 ، حيث يقدم HotStuff عددًا من التحسينات الجوهرية على PBFT ومشتقاته:
1.- يزيل HotStuff بعض التعقيدات من بروتوكولات BFT غير المتزامنة لجعلها أكثر قابلية للتوسع ، مع تقديم وظيفة بسيطة لعدد العقد في الشبكة بدلاً من وظيفة عدد العقد التربيعية
بالإضافة إلى ذلك ، تسمح بساطة رمزها بالتكيف بسهولة مع متطلبات الحلول الحديثة لنشرها على البلوكتشين، وحل مشكلة تكرار آلة الحالة (SMR) في بضعة أسطر من التعليمات البرمجية.
2.- تقدم HotStuff تغييرًا جذريًا في شبكة الاتصال الشبكي PBFT باستخدام شبكة اتصالات نجمية ، مما يؤدي إلى تحويل عبء الاتصال إلى القائد الذي يحسن أوقات استجابة البروتوكول.
3.- يدمج البروتوكول عملية تغيير العرض * مع العملية العادية ، مما يقلل من تعقيدها.
4.- يبدأ البروتوكول الخاص بالقائد الجديد بجمع رسائل العرض الجديدة من النسخ المتماثلة. تتضمن عملية بدء عرض جديد بعد تلقي رسالة معدة ثلاث مراحل في HotStuff بدلاً من المرحلتين اللتين تم توفيرهما في الأصل في PBFT: مرحلة ما قبل الالتزام ومرحلة الالتزام ومرحلة القرار.
5.- ضمن المكون التكنولوجي لـ HotStuff توجد توقيعات العتبة لتقليل عدد التوقيعات في بروتوكول الإجماع.
6.- يشير التغيير الأخير المطبق على PBFT بواسطة HotStuff إلى خط أنابيب مراحل الإجماع. نظرًا لأن جميع المراحل لها بنية متطابقة ، يمكن تحقيق خط أنابيب HotStuff.
يمكنك أن ترى أن مراحل التأكيد الثلاث لـ Basic HotStuff لها نفس البنية: تصوت العقد الأخرى على رسالة ، ويجمع القائد الأصوات ويبثها إلى العقد الأخرى. يمكن تمثيل هذه المراحل بطريقة موحدة ومجزأة.
تتميز HotStuff بكونها بسيطة بشكل ملحوظ ، ويرجع ذلك جزئيًا إلى اقتصادها الميكانيكي: لا يوجد سوى نوعين من الرسائل وقواعد بسيطة لتحديد كيفية معالجة كل نسخة متماثلة. يتم تحديد الأمان من خلال قواعد التصويت والتأكيد على الرسوم البيانية للعقدة.
يستفيد SafeStake من HotStuff لتحسين اللامركزية في Ethereum 2.0
مع “الدمج” الذي يلوح في الأفق لتنفيذ إثبات الحصة في Ethereum ، فإن SafeStake تسير على الطريق الصحيح لتجنب تركيز مزود خدمة Staking في أيدي عدد قليل من عقد المشغل.
لتحقيق ذلك ، تشبه بنيتها بنية شبكة SSV ، باستخدام تشفير العتبة لتقسيم مفتاح التحقق الخاص بالمصدق / المدقق إلى عدة مشاركات ، سيتم إرسال كل منها إلى أحد المشغلين.
يؤدي العامل الذي يعمل معًا مهمة التخزين والتحقق ذات الصلة للمدققين من خلال تشغيل مخطط توقيع العتبة. يجب على الخصم التنازل عن عدد محدد مسبقًا من المشغلين لشن هجوم ناجح ضد خدمة Staking ETH التي توفرها الشبكة.
تحدث هذه العملية بأكملها بموجب بروتوكول توافق HotStuff ، والذي يلعب دورًا رئيسيًا في التحقق من صحة المعاملات وإبقاء المشغلين داخل النظام ملتزمين بتقديم الخدمة لأطول فترة ممكنة لتجنب العقوبات أو التخفيضات بسبب عدم النشاط.
في الالتزام المكون من ثلاث مراحل لـ HotStuff ، يشير ما يسمى بالتصويت إلى توقيع الحد الأدنى على رسالة من النسخ المتماثلة ، والتي يتم إرسالها بعد ذلك إلى القائد. يتم إنشاء التوقيع الكامل عندما يتلقى القائد عددًا كافيًا من الأصوات. سيقوم القائد بإرفاق هذا التوقيع برسالة المرحلة التالية التي يرسلها إلى النسخ المتماثلة ، وسيتم التحقق من التوقيع بواسطتهم.
باستخدام HotStuff ، يتحكم SafeStake في شبكات المشغل لتحديد محتوى رسالة مخطط توقيع العتبة بين عقد المشغل.
من خلال تطبيق HotStuff على SafeStake ، لا تحتاج العقدة في النظام الموزع إلى تأكيد الرسالة ؛ إذا كانت “العقد الكافية تريد إجراء تبديل العرض” قبل إخطار القائد الجديد ، فيمكن بدلاً من ذلك التبديل مباشرةً إلى العرض الجديد وإخطار القائد الجديد.
هذا لا يجعل الشبكة أكثر قوة فحسب ، بل يولد أيضًا أداءً أعلى من اشتقاقات البروتوكولات الأخرى القائمة على BFT مثل PBFT أو Tendermint أو Casper ، حيث تقوم HotStuff بدفع عمليات متعددة على كل عقدة ، وبالتالي تخفيف تكلفة التوقيعات الرقمية عن طريق القرار.
HotStuff هو بروتوكول إجماع بيزنطي يتسامح مع الأخطاء وقد اكتسب الاحترام بين مجتمع مطوري blockchain لقوته وأمانه وسهولة تنفيذه ، وهي من بين أسباب إستناد الورقة البيضاء الخاصة بـ Libra على Facebook في تأسيس بروتوكول LibraBFT الخاص به على HotStuff.
على عكس Libra ، فإن SafeStake لديها الهدف والنية ، على عكس تصميم Facebook ، لتنفيذ HotStuff المفتوح والذي لا يحتاج لتصريح ، مما يضمن قدرًا أكبر من اللامركزية لخدمة ETH 2.0 Staking.
هذا لا يدعم فقط التطوير الشامل لنظام SafeStake البيئي بأكمله ، ولكنه يتجنب أيضًا تركيز الكثير من الموارد والاهتمام على الأداء والأمان العام للشبكة.
قامت SafeStake بتطبيق HotStuff مع آلية لا تحتاج لتصريح بها لوضع إجماع ثنائي السلسلة يعتمد على Ethereum 2.0 PoS ، لضمان هيكل أكثر انفتاحًا وديمقراطية ، مما يوفر المزيد من الترابط اللامركزي.
وبالتالي ، في SafeStake ، يتم فصل أدوار عامل التشغيل والمدقق. لا يتعين على مشغل العقدة إيداع Eth. يحتاج المدققون فقط إلى إيداع Eth على سلسلة Beacon (32Eth) أو مجموعة Staking الخاصة بك (المرحلة الثانية لشبكة الاختبار لخفض عتبة Staking) ليكونوا مدققين.
افكار اخيرة
على الرغم من إضافة مرحلة ثالثة إلى البروتوكول ، فقد ثبت أن HotStuff يحقق أداءً عاليًا. بفضل مخطط المصادقة الخطي O (n) لاتخاذ قرار إجماعي ، فإن تكاليف الاتصال للوصول إلى توافق في الآراء منخفضة جدًا مقارنة بمخططات BFT الأخرى.
لهذه الأسباب والقدرة المتفائلة على الاستجابة جنبًا إلى جنب مع بروتوكول القائد الخطي دون تأخير ، تقوم SafeStake بتنفيذ HotStuff لتأكيد السلسلة لمحتوى الرسالة الخاص بنظام توقيع العتبة الذي يتم تنفيذه أثناء خدمة Staking ETH 2.0.
تدرك ParaState أهمية النظام البيئي Ethereum ومدى أهمية المشاركة في تأمين الشبكة الرئيسية للتطبيقات اللامركزية في السوق ؛ لذلك ، جنبًا إلى جنب مع SafeStake ، نبتكر باستخدام أفضل تقنيات البلوكتشين المتاحة لبناء عالم لامركزي جديد معًا.
المقالة الرئيسية : https://hackernoon.com/hotstuff-the-consensus-protocol-behind-safestake-and-facebooks-librabft