إطار Shoal: اسقاط وقت الإستجابة Bullshark على Aptos
قامت مختبرات Aptos مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل كبير، ولأول مرة في بروتوكول عملي محدد، تم القضاء على الحاجة إلى تجاوز الوقت. بشكل عام، قام إطار عمل Shoal بتحسين وقت الإستجابة ل Bullshark بنسبة 40% في حالة عدم وجود أعطال، و 80% في حالة وجود أعطال.
Shoal هو إطار يعزز أي بروتوكول إجماع قائم على Narwhal من خلال آلية خط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). يقوم خط الأنابيب بتقليل وقت الإستجابة لترتيب DAG من خلال إدخال نقاط الربط في كل جولة، بينما تعمل سمعة القادة على تحسين الوقت من خلال ضمان ارتباط نقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal استغلال بناء DAG غير المتزامن للقضاء على جميع السيناريوهات المتعلقة بوقت انتهاء الصلاحية. هذا يمكّن Shoal من تقديم خاصية تُعرف بالاستجابة العامة، والتي تتضمن الاستجابة المتفائلة المطلوبة عادة.
الفكرة الأساسية لشول بسيطة جداً، وهي تشغيل عدة نسخ من البروتوكول الأساسي بترتيب. لذلك، عندما يتم تنفيذها باستخدام Bullshark، نحصل على مجموعة من "الأسماك" التي تتنافس في سباق التتابع.
الدافع
في سعيهم لتحقيق أداء عالٍ لشبكة البلوكتشين، كان الناس دائمًا يهتمون بإسقاط تعقيد الاتصالات. ومع ذلك، لم تحقق هذه الطريقة زيادة ملحوظة في معدل نقل البيانات. على سبيل المثال، حققت Hotstuff التي تم تنفيذها في النسخة المبكرة من Diem 3500 TPS فقط، وهو ما يقل بكثير عن الهدف البالغ 100000+ TPS.
تأتي الاختراقات الأخيرة من إدراك أن انتشار البيانات هو عنق الزجاجة الرئيسي في بروتوكول القادة، ويمكن الاستفادة منه من خلال التوازي. يفصل نظام Narwhal بين نشر البيانات والمنطق الأساسي للتوافق، ويقدم بنية حيث تقوم جميع الموثقين بنشر البيانات في نفس الوقت، بينما تقوم مكونات التوافق بترتيب كمية صغيرة فقط من البيانات الوصفية. تقرير ورقة Narwhal عن قدرة 160000 TPS.
في المقالات السابقة، قدمنا Quorum Store - تنفيذ Narwhal الخاص بنا، الذي يفصل بين نشر البيانات والتوافق، وكيف نستخدمه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القائد، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، من الواضح أن بروتوكولات التوافق القائم على القائد لا تستطيع الاستفادة بشكل كامل من إمكانيات إنتاجية Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark على قمة Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark بقدرة عالية على المعالجة يأتي بتكلفة تأخير بنسبة 50٪.
تتناول هذه المقالة كيفية قيام Shoal بإسقاط وقت الإستجابة لـ Bullshark بشكل كبير.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بجولة معينة. للدخول في الجولة r، يجب على المدقق الحصول أولاً على n-f من الرؤوس التابعة للجولة r-1. يمكن لكل مدقق بث رأس واحد في كل جولة، ويجب أن يشير كل رأس إلى n-f من الرؤوس السابقة على الأقل. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي لحظة.
من الخصائص الرئيسية لـ DAG هي عدم الغموض: إذا كانت لدى عقدتي التحقق وجهات نظر محلية لـ DAG تحتوي على نفس الرأس v، فإنهما لهما نفس التاريخ السببي لـ v.
المقدمة
يمكن تحقيق توافق على الترتيب الإجمالي لجميع القمم في DAG دون أي تكاليف إضافية للتواصل. لتحقيق ذلك، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG كبروتوكول توافق، حيث تمثل القمم الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تقاطع المجتمعات في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع القائمة على Narwhal الحالية تتمتع بالهيكل التالي:
النقطة المحددة: كل عدة جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد، ويطلق على قمة القائد النقطة المحددة.
نقاط الترتيب: يحدد المدققون بشكل مستقل ولكن حاسم نقاط الترتيب التي سيتم ترتيبها وتلك التي سيتم تخطيها.
ترتيب تاريخ السبب والنتيجة: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، بالنسبة لكل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخ السبب والنتيجة الخاص بها وفقًا لقواعد حتمية.
المفتاح لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تنشئ قائمة نقاط ربط مرتبة في الخطوة (2)، بحيث تشترك جميع القوائم في نفس البادئة. في شوال، نقوم بالاستنتاجات التالية بشأن جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
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. ثم، تبدأ عقد التحقق في تنفيذ مثيل جديد لـ Bullshark باستخدام دالة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
تؤدي مهلة الوقت دورًا حاسمًا في جميع تطبيقات BFT المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب تقنيات أكثر للمراقبة.
سيؤدي تجاوز الوقت أيضًا إلى زيادة وقت الإستجابة بشكل كبير، لأنه من المهم تكوينها بشكل مناسب، وغالبًا ما يتطلب ذلك تعديلات ديناميكية لأنه يعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع عقوبة تأخير تجاوز الوقت الكامل للقائد المعطل. لذلك، يجب ألا تكون إعدادات تجاوز الوقت متحفظة للغاية، ولكن إذا كان وقت التجاوز قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات التحميل العالي، كان القادة في Jolteon/Hotstuff تحت ضغط كبير، وانتهى وقت التجاوز قبل أن يتمكنوا من دفع التقدم.
لسوء الحظ، بناءً على بروتوكول القادة ( مثل هوتستاف
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 16
أعجبني
16
10
مشاركة
تعليق
0/400
TokenomicsTrapper
· 07-16 23:24
دخان ومرآة الكلاسيكية... 40% لا تعني شيئًا إذا كانت وقت الإستجابة الأساسي سيئًا بصراحة
شاهد النسخة الأصليةرد0
rekt_but_resilient
· 07-16 17:01
وقت الإستجابة降八成? 要للقمر咯
شاهد النسخة الأصليةرد0
NestedFox
· 07-16 09:09
تحسين ثمانين درجة رائع
شاهد النسخة الأصليةرد0
Blockwatcher9000
· 07-15 13:37
لا يزال يتغلب على وقت الإستجابة يا قوي
شاهد النسخة الأصليةرد0
GasFeePhobia
· 07-14 02:57
40 لا 80 شديد جدًا؟ التأثير جيد جدًا.
شاهد النسخة الأصليةرد0
MEVHunterBearish
· 07-14 02:55
ما فائدة هذا، نحن فقط صاعدون ولا نهتم بالهبوط
شاهد النسخة الأصليةرد0
WalletsWatcher
· 07-14 02:55
آه، لقد تمكنت أخيرًا من حل وقت الإستجابة
شاهد النسخة الأصليةرد0
CryptoFortuneTeller
· 07-14 02:45
اشترِ aptos اشترِ aptos ستنفد قريبًا
شاهد النسخة الأصليةرد0
MetamaskMechanic
· 07-14 02:43
أدخل الحساب، وقد قام شخص آخر بتحسين وقت الإستجابة.
إطار Shoal اسقط وقت الإستجابة لBullshark على Aptos لتحقيق الإجماع بدون مهلة.
إطار Shoal: اسقاط وقت الإستجابة Bullshark على Aptos
قامت مختبرات Aptos مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل كبير، ولأول مرة في بروتوكول عملي محدد، تم القضاء على الحاجة إلى تجاوز الوقت. بشكل عام، قام إطار عمل Shoal بتحسين وقت الإستجابة ل Bullshark بنسبة 40% في حالة عدم وجود أعطال، و 80% في حالة وجود أعطال.
Shoal هو إطار يعزز أي بروتوكول إجماع قائم على Narwhal من خلال آلية خط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). يقوم خط الأنابيب بتقليل وقت الإستجابة لترتيب DAG من خلال إدخال نقاط الربط في كل جولة، بينما تعمل سمعة القادة على تحسين الوقت من خلال ضمان ارتباط نقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal استغلال بناء DAG غير المتزامن للقضاء على جميع السيناريوهات المتعلقة بوقت انتهاء الصلاحية. هذا يمكّن Shoal من تقديم خاصية تُعرف بالاستجابة العامة، والتي تتضمن الاستجابة المتفائلة المطلوبة عادة.
الفكرة الأساسية لشول بسيطة جداً، وهي تشغيل عدة نسخ من البروتوكول الأساسي بترتيب. لذلك، عندما يتم تنفيذها باستخدام Bullshark، نحصل على مجموعة من "الأسماك" التي تتنافس في سباق التتابع.
الدافع
في سعيهم لتحقيق أداء عالٍ لشبكة البلوكتشين، كان الناس دائمًا يهتمون بإسقاط تعقيد الاتصالات. ومع ذلك، لم تحقق هذه الطريقة زيادة ملحوظة في معدل نقل البيانات. على سبيل المثال، حققت Hotstuff التي تم تنفيذها في النسخة المبكرة من Diem 3500 TPS فقط، وهو ما يقل بكثير عن الهدف البالغ 100000+ TPS.
تأتي الاختراقات الأخيرة من إدراك أن انتشار البيانات هو عنق الزجاجة الرئيسي في بروتوكول القادة، ويمكن الاستفادة منه من خلال التوازي. يفصل نظام Narwhal بين نشر البيانات والمنطق الأساسي للتوافق، ويقدم بنية حيث تقوم جميع الموثقين بنشر البيانات في نفس الوقت، بينما تقوم مكونات التوافق بترتيب كمية صغيرة فقط من البيانات الوصفية. تقرير ورقة Narwhal عن قدرة 160000 TPS.
في المقالات السابقة، قدمنا Quorum Store - تنفيذ Narwhal الخاص بنا، الذي يفصل بين نشر البيانات والتوافق، وكيف نستخدمه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القائد، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، من الواضح أن بروتوكولات التوافق القائم على القائد لا تستطيع الاستفادة بشكل كامل من إمكانيات إنتاجية Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark على قمة Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark بقدرة عالية على المعالجة يأتي بتكلفة تأخير بنسبة 50٪.
تتناول هذه المقالة كيفية قيام Shoal بإسقاط وقت الإستجابة لـ Bullshark بشكل كبير.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بجولة معينة. للدخول في الجولة r، يجب على المدقق الحصول أولاً على n-f من الرؤوس التابعة للجولة r-1. يمكن لكل مدقق بث رأس واحد في كل جولة، ويجب أن يشير كل رأس إلى n-f من الرؤوس السابقة على الأقل. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي لحظة.
من الخصائص الرئيسية لـ DAG هي عدم الغموض: إذا كانت لدى عقدتي التحقق وجهات نظر محلية لـ DAG تحتوي على نفس الرأس v، فإنهما لهما نفس التاريخ السببي لـ v.
المقدمة
يمكن تحقيق توافق على الترتيب الإجمالي لجميع القمم في DAG دون أي تكاليف إضافية للتواصل. لتحقيق ذلك، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG كبروتوكول توافق، حيث تمثل القمم الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تقاطع المجتمعات في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع القائمة على Narwhal الحالية تتمتع بالهيكل التالي:
النقطة المحددة: كل عدة جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد، ويطلق على قمة القائد النقطة المحددة.
نقاط الترتيب: يحدد المدققون بشكل مستقل ولكن حاسم نقاط الترتيب التي سيتم ترتيبها وتلك التي سيتم تخطيها.
ترتيب تاريخ السبب والنتيجة: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، بالنسبة لكل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخ السبب والنتيجة الخاص بها وفقًا لقواعد حتمية.
المفتاح لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تنشئ قائمة نقاط ربط مرتبة في الخطوة (2)، بحيث تشترك جميع القوائم في نفس البادئة. في شوال، نقوم بالاستنتاجات التالية بشأن جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
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. ثم، تبدأ عقد التحقق في تنفيذ مثيل جديد لـ Bullshark باستخدام دالة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
تؤدي مهلة الوقت دورًا حاسمًا في جميع تطبيقات BFT المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب تقنيات أكثر للمراقبة.
سيؤدي تجاوز الوقت أيضًا إلى زيادة وقت الإستجابة بشكل كبير، لأنه من المهم تكوينها بشكل مناسب، وغالبًا ما يتطلب ذلك تعديلات ديناميكية لأنه يعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع عقوبة تأخير تجاوز الوقت الكامل للقائد المعطل. لذلك، يجب ألا تكون إعدادات تجاوز الوقت متحفظة للغاية، ولكن إذا كان وقت التجاوز قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات التحميل العالي، كان القادة في Jolteon/Hotstuff تحت ضغط كبير، وانتهى وقت التجاوز قبل أن يتمكنوا من دفع التقدم.
لسوء الحظ، بناءً على بروتوكول القادة ( مثل هوتستاف