إطار Shoal: اسقاط وقت الإستجابة Bullshark على Aptos
حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى اسقاط وقت الإستجابة بشكل ملحوظ، وألغت لأول مرة الحاجة إلى انتهاء الوقت في بروتوكول موثوق محدد. بشكل عام، تم تحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار يعزز بروتوكول الإجماع القائم على Narwhal من خلال معالجة خطوط الأنابيب وآلية سمعة القادة ( مثل DAG-Rider وTusk وBullshark ). تقلل معالجة خطوط الأنابيب من تأخير ترتيب DAG من خلال إدخال نقاط ربط في كل جولة، بينما تعمل آلية سمعة القادة على تحسين مشكلة التأخير بشكل أكبر من خلال ضمان ارتباط نقاط الربط بأسرع عقد التحقق. بالإضافة إلى ذلك، تمكن سمعة القادة Shoal من الاستفادة من بناء DAG غير المتزامن للقضاء على جميع سيناريوهات المهلة. وهذا يسمح لـ Shoal بتوفير خاصية تُعرف باسم "الاستجابة العامة"، التي تحتوي على الاستجابة المتفائلة المطلوبة عادة.
تقنية Shoal بسيطة للغاية، حيث تتعلق بتشغيل عدة مثيلات من البروتوكول الأساسي بالتتابع واحدًا تلو الآخر. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تجري سباق التتابع.
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة البلوكشين، كان الناس دائمًا يهتمون باسقاط تعقيد الاتصال. ومع ذلك، لم تؤدِ هذه الطريقة إلى زيادة ملحوظة في معدل النقل. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem 3500 TPS فقط، وهو أقل بكثير من هدفنا البالغ 100k+ TPS.
التقدم الأخير نبع من إدراك أن انتشار البيانات هو العقبة الرئيسية القائمة على بروتوكولات القادة، ويمكن أن يستفيد من التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن منطق الإجماع الأساسي، ويقترح هيكلاً حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما تقوم مكونات الإجماع بترتيب كمية صغيرة فقط من البيانات الوصفية. أفادت ورقة Narwhal بقدرة معالجة تبلغ 160,000 TPS.
تقوم Narwhal الخاصة بنا بتنفيذ Quorum Store بفصل نشر البيانات عن الإجماع، لاستخدامها في توسيع بروتوكول الإجماع الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض على طريقة PBFT، مما يقلل وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه الاستفادة بالكامل من إمكانيات الإنتاجية لـ Narwhal. على الرغم من فصل نشر البيانات عن الإجماع، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark، بروتوكول إجماع بدون تكلفة تواصل، فوق Narwhal DAG. للأسف، فإن هيكل DAG الذي يدعم Bullshark ذو الإنتاجية العالية جاء بتكلفة تأخير بنسبة 50% مقارنة بـ Jolteon.
تقدم هذه المقالة كيفية تقليل وقت الإستجابة لـ Bullshark بشكل كبير بواسطة Shoal.
خلفية DAG-BFT
يرتبط كل رأس في Narwhal DAG بدورة معينة. لدخول الجولة r، يجب على المدقق أولاً الحصول على n-f رؤوس تنتمي إلى الجولة r-1. يمكن لكل مدقق بث رأس واحد في كل جولة، ويجب أن يشير كل رأس على الأقل إلى n-f رؤوس من الجولة السابقة. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي لحظة.
خاصية رئيسية في DAG ليست غامضة: إذا كان لدى عقدتي تحقق مختلفتين نفس القمة v في وجهاتهما المحلية لـ DAG، فإن لديهما نفس التاريخ السببي لـ v.
المقدمة
يمكن تحقيق التوافق على الترتيب الكلي لجميع القمم في DAG دون أي تكلفة اتصالات إضافية. لهذا الغرض، يفسر المدققون في DAG-Rider وTusk وBullshark هيكل DAG كبروتوكول إجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف الأصوات.
على الرغم من أن منطق التقاطع الجماعي في هيكل DAG يختلف، إلا أن جميع بروتوكولات الإجماع القائمة على Narwhal الحالية تتمتع بالهيكل التالي:
نقطة الربط: كل عدة جولات سيكون هناك قائد محدد مسبقًا، وتسمى ذروة القائد نقطة الربط.
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يجب ترتيبها وأي النقاط يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسخة المرتبة واحدة تلو الأخرى، وبالنسبة لكل نقطة مرساة، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخها السببي وفقًا لقواعد حتمية.
الشرط الرئيسي لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تخلق قائمة نقاط ربط مرتبة في الخطوة (2)، بحيث تشترك جميع القوائم في نفس البادئة. في Shoal، لدينا الملاحظات التالية حول جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
تتوقف وقت الإستجابة لـ Bullshark على عدد الدورات بين النقاط المرجعية المرتبة في DAG. على الرغم من أن الجزء الأكثر عملية من الإصدارات المتزامنة لـ Bullshark أفضل في وقت الإستجابة من الإصدارات غير المتزامنة، إلا أنه لا يزال بعيدًا عن المثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، كل جولة زوجية لديها نقطة ربط، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى دورتين من DAG لترتيب نقاط الربط، ومع ذلك، تحتاج القمم في التاريخ السببي لنقاط الربط إلى مزيد من الدورات لانتظار ترتيب نقاط الربط. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث دورات، بينما تحتاج القمم غير المرتبطة في الجولات الزوجية إلى أربع دورات.
السؤال 2: وقت الإستجابة لحالات الفشل، تحليل الوقت الإستجابة المذكور أعلاه ينطبق على الحالات بدون فشل، من ناحية أخرى، إذا لم يتمكن القائد في جولة من جولات من بث النقاط المرجعية بسرعة كافية، فلن يكون بالإمكان ترتيب النقاط المرجعية ( وبالتالي سيتم تخطيها )، لذا يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. هذا سيؤدي إلى اسقاط كبير في أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم أوقات الانتظار للانتظار على القائد.
إطار Shoal
عزز Shoal معالجة خط الأنابيب Bullshark( أو أي بروتوكول BFT آخر قائم على Narwhal)، مما يسمح بوجود نقطة ربط في كل جولة، ويقلل وقت الإستجابة لجميع رؤوس DAG غير المرتبطة إلى ثلاث جولات. كما قدم Shoal آلية سمعة القادة بدون تكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
تحدي
في سياق بروتوكول DAG، تعتبر معالجة الأنابيب وسمعة القائد من القضايا الصعبة، والأسباب كما يلي:
كانت المعالجة السابقة على خطوط الإنتاج تحاول تعديل منطق Bullshark الأساسي، ولكن يبدو أن ذلك من حيث الجوهر غير ممكن.
تم إدخال سمعة القادة في DiemBFT وتم توثيقها رسميًا في Carousel، ويتم اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المصدقين في الماضي، وهو فكرة الربط في Bullshark. على الرغم من أن وجود اختلافات في هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار الربط بشكل ديناميكي وحتمي ضروري لحل الإجماع، ويحتاج المصدقون إلى التوصل إلى توافق بشأن التاريخ المرتب لاختيار الربط المستقبلي.
كدليل على صعوبة المشكلة، نلاحظ أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول تكمن في البساطة.
في Shoal ، نعتمد على قدرة تنفيذ الحسابات المحلية على DAG ، وحققنا القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على النقطة المرصودة الأولى ، يقوم Shoal بترتيب تجميع عدة مثيلات من Bullshark ومعالجتها بشكل متسلسل ، مما يجعل ( النقطة الأولى المرصودة نقطة التحول للمثيلات ، و) التاريخ السببي للنقاط المرصودة يُستخدم لحساب سمعة القائد.
معالجة خط الأنابيب
V تربط الدور بالزعيم. تقوم Shoal بتشغيل مثيلات Bullshark واحدة تلو الأخرى، بحيث يتم تحديد الربط مسبقًا لكل مثيل بواسطة الخريطة F. يقوم كل مثيل بترتيب الربط، مما يؤدي إلى الانتقال إلى المثيل التالي.
في البداية، أطلق Shoal أول مثال لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى يتم تحديد أول نقطة ربط مرتبة، مثل الجولة r. اتفق جميع المدققين على هذه النقطة. وبالتالي، يمكن لجميع المدققين أن يتفقوا بشكل قاطع على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal فقط مثالًا جديدًا من Bullshark في الجولة r+1.
في أفضل الحالات، يسمح ذلك لـ Shoal بترتيب ركيزة في كل جولة. يتم فرز نقاط الركيزة في الجولة الأولى حسب أول مثيل. ثم، يبدأ Shoal مثيلًا جديدًا في الجولة الثانية، والذي يحتوي بنفسه على نقطة ركيزة، ويتم فرز هذه الركيزة بواسطة هذا المثيل، ثم يتم فرز مثيل جديد آخر في الجولة الثالثة، ثم تستمر العملية.
سمعة القادة
سيزداد وقت الإستجابة عند تخطي النقاط الثابتة خلال ترتيب Bullshark. في هذه الحالة، فإن تقنية معالجة خطوط الأنابيب غير فعالة، لأنه لا يمكن بدء مثيل جديد قبل ترتيب النقطة الثابتة للمثيل السابق. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة تحقق، مما يجعل من غير المرجح اختيار القادة المعنيين لمعالجة النقاط الثابتة المفقودة في المستقبل. سيحصل المصدقون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا سيتم تخصيص درجات منخفضة لعقدة التحقق، لأنها قد تنهار أو تكون بطيئة أو تتصرف بشكل خبيث.
مفهومها هو إعادة حساب الخرائط المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث الدرجات، مع التوجه نحو القادة ذوي الدرجات الأعلى. لكي يتفق المدققون على الخريطة الجديدة، يجب عليهم التوصل إلى توافق في الدرجات، وبالتالي التوصل إلى توافق في التاريخ المستخدم لاستنتاج الدرجات.
في Shoal، يمكن دمج معالجة خطوط الأنابيب وسمعة القادة بشكل طبيعي، لأنهما يستخدمان نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الفرق الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المُصادق فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقدة التحقق باستخدام دالة اختيار النقاط المرجعية المحدثة F' لتنفيذ مثال جديد لـ Bullshark بدءًا من الجولة r+1.
لا مزيد من الوقت المستغرق
يؤدي الوقت المستغرق دورًا حاسمًا في جميع تنفيذات BFT المعتمدة على القائد. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب مزيدًا من تقنيات المراقبة.
سيؤدي انتهاء المهلة أيضًا إلى زيادة وقت الإستجابة بشكل ملحوظ، لأن تكوينها بشكل صحيح أمر مهم للغاية، وغالبًا ما يتطلب تعديلات ديناميكية، لأنه يعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستدفع البروتوكول عقوبة كاملة على وقت الإستجابة للقائد الذي به خلل. لذلك، لا يمكن أن تكون إعدادات المهلة متحفظة للغاية، لكن إذا كانت مدة المهلة قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالية، كان القادة في Jolteon/Hotstuff مثقلين، وقد انتهى وقت الإستجابة قبل أن يدفعوا التقدم.
للأسف، فإن بروتوكول القائد ( مثل Hotstuff و Jolteon ) يتطلب في جوهره وقت الإستجابة لضمان أن كل مرة يفشل فيها القائد.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
9
مشاركة
تعليق
0/400
ChainComedian
· منذ 13 س
وقت الإستجابة انخفض كثيرًا أشعر أنه يمكن القيام بصفقة كبيرة
شاهد النسخة الأصليةرد0
YouMustMakeBigMoneyEvery
· 07-19 04:14
تجاوز so l
شاهد النسخة الأصليةرد0
YouMustMakeBigMoneyEvery
· 07-19 04:14
شركة HODL💎
شاهد النسخة الأصليةرد0
VirtualRichDream
· 07-19 03:33
وقت الإستجابة اسقاط这么多 aptos走起来了
شاهد النسخة الأصليةرد0
FOMOSapien
· 07-19 03:33
تقليل وقت الإستجابة ليس أفضل من محاولة A مباشرة مع الرئيس
شاهد النسخة الأصليةرد0
BearEatsAll
· 07-19 03:30
هل يمكن أن يكون aptos أسرع؟ ثور
شاهد النسخة الأصليةرد0
PaperHandsCriminal
· 07-19 03:26
لا أحد يعرف ما هي فائدة وقت الإستجابة المنخفض، ولم يمنعني ذلك من أن أكون ضحية لخداع الناس لتحقيق الربح.
شاهد النسخة الأصليةرد0
ApeShotFirst
· 07-19 03:23
ارتفع وقت الإستجابة إلغاء الإدراج
شاهد النسخة الأصليةرد0
BlockchainFries
· 07-19 03:15
نظرًا لانخفاض وقت الإستجابة بهذا القدر، سأشتري مركز صغير أولاً.
إطار Shoal اسقط بشكل كبير وقت الإستجابة للإجماع Bullshark على Aptos
إطار Shoal: اسقاط وقت الإستجابة Bullshark على Aptos
حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى اسقاط وقت الإستجابة بشكل ملحوظ، وألغت لأول مرة الحاجة إلى انتهاء الوقت في بروتوكول موثوق محدد. بشكل عام، تم تحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار يعزز بروتوكول الإجماع القائم على Narwhal من خلال معالجة خطوط الأنابيب وآلية سمعة القادة ( مثل DAG-Rider وTusk وBullshark ). تقلل معالجة خطوط الأنابيب من تأخير ترتيب DAG من خلال إدخال نقاط ربط في كل جولة، بينما تعمل آلية سمعة القادة على تحسين مشكلة التأخير بشكل أكبر من خلال ضمان ارتباط نقاط الربط بأسرع عقد التحقق. بالإضافة إلى ذلك، تمكن سمعة القادة Shoal من الاستفادة من بناء DAG غير المتزامن للقضاء على جميع سيناريوهات المهلة. وهذا يسمح لـ Shoal بتوفير خاصية تُعرف باسم "الاستجابة العامة"، التي تحتوي على الاستجابة المتفائلة المطلوبة عادة.
تقنية Shoal بسيطة للغاية، حيث تتعلق بتشغيل عدة مثيلات من البروتوكول الأساسي بالتتابع واحدًا تلو الآخر. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تجري سباق التتابع.
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة البلوكشين، كان الناس دائمًا يهتمون باسقاط تعقيد الاتصال. ومع ذلك، لم تؤدِ هذه الطريقة إلى زيادة ملحوظة في معدل النقل. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem 3500 TPS فقط، وهو أقل بكثير من هدفنا البالغ 100k+ TPS.
التقدم الأخير نبع من إدراك أن انتشار البيانات هو العقبة الرئيسية القائمة على بروتوكولات القادة، ويمكن أن يستفيد من التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن منطق الإجماع الأساسي، ويقترح هيكلاً حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما تقوم مكونات الإجماع بترتيب كمية صغيرة فقط من البيانات الوصفية. أفادت ورقة Narwhal بقدرة معالجة تبلغ 160,000 TPS.
تقوم Narwhal الخاصة بنا بتنفيذ Quorum Store بفصل نشر البيانات عن الإجماع، لاستخدامها في توسيع بروتوكول الإجماع الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض على طريقة PBFT، مما يقلل وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه الاستفادة بالكامل من إمكانيات الإنتاجية لـ Narwhal. على الرغم من فصل نشر البيانات عن الإجماع، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark، بروتوكول إجماع بدون تكلفة تواصل، فوق Narwhal DAG. للأسف، فإن هيكل DAG الذي يدعم Bullshark ذو الإنتاجية العالية جاء بتكلفة تأخير بنسبة 50% مقارنة بـ Jolteon.
تقدم هذه المقالة كيفية تقليل وقت الإستجابة لـ Bullshark بشكل كبير بواسطة Shoal.
خلفية DAG-BFT
يرتبط كل رأس في Narwhal DAG بدورة معينة. لدخول الجولة r، يجب على المدقق أولاً الحصول على n-f رؤوس تنتمي إلى الجولة r-1. يمكن لكل مدقق بث رأس واحد في كل جولة، ويجب أن يشير كل رأس على الأقل إلى n-f رؤوس من الجولة السابقة. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي لحظة.
خاصية رئيسية في DAG ليست غامضة: إذا كان لدى عقدتي تحقق مختلفتين نفس القمة v في وجهاتهما المحلية لـ DAG، فإن لديهما نفس التاريخ السببي لـ v.
المقدمة
يمكن تحقيق التوافق على الترتيب الكلي لجميع القمم في DAG دون أي تكلفة اتصالات إضافية. لهذا الغرض، يفسر المدققون في DAG-Rider وTusk وBullshark هيكل DAG كبروتوكول إجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف الأصوات.
على الرغم من أن منطق التقاطع الجماعي في هيكل DAG يختلف، إلا أن جميع بروتوكولات الإجماع القائمة على Narwhal الحالية تتمتع بالهيكل التالي:
نقطة الربط: كل عدة جولات سيكون هناك قائد محدد مسبقًا، وتسمى ذروة القائد نقطة الربط.
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يجب ترتيبها وأي النقاط يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسخة المرتبة واحدة تلو الأخرى، وبالنسبة لكل نقطة مرساة، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخها السببي وفقًا لقواعد حتمية.
الشرط الرئيسي لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تخلق قائمة نقاط ربط مرتبة في الخطوة (2)، بحيث تشترك جميع القوائم في نفس البادئة. في Shoal، لدينا الملاحظات التالية حول جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
تتوقف وقت الإستجابة لـ Bullshark على عدد الدورات بين النقاط المرجعية المرتبة في DAG. على الرغم من أن الجزء الأكثر عملية من الإصدارات المتزامنة لـ Bullshark أفضل في وقت الإستجابة من الإصدارات غير المتزامنة، إلا أنه لا يزال بعيدًا عن المثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، كل جولة زوجية لديها نقطة ربط، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى دورتين من DAG لترتيب نقاط الربط، ومع ذلك، تحتاج القمم في التاريخ السببي لنقاط الربط إلى مزيد من الدورات لانتظار ترتيب نقاط الربط. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث دورات، بينما تحتاج القمم غير المرتبطة في الجولات الزوجية إلى أربع دورات.
السؤال 2: وقت الإستجابة لحالات الفشل، تحليل الوقت الإستجابة المذكور أعلاه ينطبق على الحالات بدون فشل، من ناحية أخرى، إذا لم يتمكن القائد في جولة من جولات من بث النقاط المرجعية بسرعة كافية، فلن يكون بالإمكان ترتيب النقاط المرجعية ( وبالتالي سيتم تخطيها )، لذا يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. هذا سيؤدي إلى اسقاط كبير في أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم أوقات الانتظار للانتظار على القائد.
إطار Shoal
عزز Shoal معالجة خط الأنابيب Bullshark( أو أي بروتوكول BFT آخر قائم على Narwhal)، مما يسمح بوجود نقطة ربط في كل جولة، ويقلل وقت الإستجابة لجميع رؤوس DAG غير المرتبطة إلى ثلاث جولات. كما قدم Shoal آلية سمعة القادة بدون تكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
تحدي
في سياق بروتوكول DAG، تعتبر معالجة الأنابيب وسمعة القائد من القضايا الصعبة، والأسباب كما يلي:
كانت المعالجة السابقة على خطوط الإنتاج تحاول تعديل منطق Bullshark الأساسي، ولكن يبدو أن ذلك من حيث الجوهر غير ممكن.
تم إدخال سمعة القادة في DiemBFT وتم توثيقها رسميًا في Carousel، ويتم اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المصدقين في الماضي، وهو فكرة الربط في Bullshark. على الرغم من أن وجود اختلافات في هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار الربط بشكل ديناميكي وحتمي ضروري لحل الإجماع، ويحتاج المصدقون إلى التوصل إلى توافق بشأن التاريخ المرتب لاختيار الربط المستقبلي.
كدليل على صعوبة المشكلة، نلاحظ أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول تكمن في البساطة.
في Shoal ، نعتمد على قدرة تنفيذ الحسابات المحلية على DAG ، وحققنا القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على النقطة المرصودة الأولى ، يقوم Shoal بترتيب تجميع عدة مثيلات من Bullshark ومعالجتها بشكل متسلسل ، مما يجعل ( النقطة الأولى المرصودة نقطة التحول للمثيلات ، و) التاريخ السببي للنقاط المرصودة يُستخدم لحساب سمعة القائد.
معالجة خط الأنابيب
V تربط الدور بالزعيم. تقوم Shoal بتشغيل مثيلات Bullshark واحدة تلو الأخرى، بحيث يتم تحديد الربط مسبقًا لكل مثيل بواسطة الخريطة F. يقوم كل مثيل بترتيب الربط، مما يؤدي إلى الانتقال إلى المثيل التالي.
في البداية، أطلق Shoal أول مثال لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى يتم تحديد أول نقطة ربط مرتبة، مثل الجولة r. اتفق جميع المدققين على هذه النقطة. وبالتالي، يمكن لجميع المدققين أن يتفقوا بشكل قاطع على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal فقط مثالًا جديدًا من Bullshark في الجولة r+1.
في أفضل الحالات، يسمح ذلك لـ Shoal بترتيب ركيزة في كل جولة. يتم فرز نقاط الركيزة في الجولة الأولى حسب أول مثيل. ثم، يبدأ Shoal مثيلًا جديدًا في الجولة الثانية، والذي يحتوي بنفسه على نقطة ركيزة، ويتم فرز هذه الركيزة بواسطة هذا المثيل، ثم يتم فرز مثيل جديد آخر في الجولة الثالثة، ثم تستمر العملية.
سمعة القادة
سيزداد وقت الإستجابة عند تخطي النقاط الثابتة خلال ترتيب Bullshark. في هذه الحالة، فإن تقنية معالجة خطوط الأنابيب غير فعالة، لأنه لا يمكن بدء مثيل جديد قبل ترتيب النقطة الثابتة للمثيل السابق. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة تحقق، مما يجعل من غير المرجح اختيار القادة المعنيين لمعالجة النقاط الثابتة المفقودة في المستقبل. سيحصل المصدقون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا سيتم تخصيص درجات منخفضة لعقدة التحقق، لأنها قد تنهار أو تكون بطيئة أو تتصرف بشكل خبيث.
مفهومها هو إعادة حساب الخرائط المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث الدرجات، مع التوجه نحو القادة ذوي الدرجات الأعلى. لكي يتفق المدققون على الخريطة الجديدة، يجب عليهم التوصل إلى توافق في الدرجات، وبالتالي التوصل إلى توافق في التاريخ المستخدم لاستنتاج الدرجات.
في Shoal، يمكن دمج معالجة خطوط الأنابيب وسمعة القادة بشكل طبيعي، لأنهما يستخدمان نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الفرق الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المُصادق فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقدة التحقق باستخدام دالة اختيار النقاط المرجعية المحدثة F' لتنفيذ مثال جديد لـ Bullshark بدءًا من الجولة r+1.
لا مزيد من الوقت المستغرق
يؤدي الوقت المستغرق دورًا حاسمًا في جميع تنفيذات BFT المعتمدة على القائد. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب مزيدًا من تقنيات المراقبة.
سيؤدي انتهاء المهلة أيضًا إلى زيادة وقت الإستجابة بشكل ملحوظ، لأن تكوينها بشكل صحيح أمر مهم للغاية، وغالبًا ما يتطلب تعديلات ديناميكية، لأنه يعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستدفع البروتوكول عقوبة كاملة على وقت الإستجابة للقائد الذي به خلل. لذلك، لا يمكن أن تكون إعدادات المهلة متحفظة للغاية، لكن إذا كانت مدة المهلة قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالية، كان القادة في Jolteon/Hotstuff مثقلين، وقد انتهى وقت الإستجابة قبل أن يدفعوا التقدم.
للأسف، فإن بروتوكول القائد ( مثل Hotstuff و Jolteon ) يتطلب في جوهره وقت الإستجابة لضمان أن كل مرة يفشل فيها القائد.