إطار Shoal: تقليل وقت الإستجابة لBullshark على Aptos بشكل كبير
قامت Aptos Labs مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل ملحوظ، ولأول مرة ألغت الحاجة إلى مهلة في بروتوكولات العملية الحاسمة. بشكل عام، تحسن وقت الإستجابة لبولشارك بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز بروتوكول الإجماع القائم على Narwhal من خلال آلية خط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). يقلل خط الأنابيب من وقت الإستجابة عن طريق إدخال نقطة مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت عن طريق ضمان ارتباط النقاط المرجعية بأسرع عقد التحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على مهلة في جميع السيناريوهات. وهذا يمكّن Shoal من تقديم خاصية الاستجابة العامة، والتي تتضمن الاستجابة المتفائلة التي تُطلب عادةً.
هذه التقنية بسيطة جدًا، حيث تتضمن تشغيل عدة مثيلات من البروتوكولات الأساسية واحدة تلو الأخرى. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
الخلفية
في سعيهم لتحقيق أداء عالٍ لشبكة البلوكشين، كان الناس دائمًا مهتمين بتقليل تعقيد الاتصالات. ومع ذلك، لم تؤدِ هذه الطريقة إلى زيادة كبيرة في الإنتاجية. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem 3500 TPS فقط، وهو أقل بكثير من الهدف البالغ 100000+ TPS.
إن الانفراجة الأخيرة جاءت من فهم أن نقل البيانات هو العقبة الرئيسية التي تستند إلى بروتوكول القادة، ويمكن أن تستفيد من التوازي. يقوم نظام Narwhal بفصل نقل البيانات عن المنطق الأساسي للإجماع، حيث يقدم بنية يتم فيها نقل البيانات من قبل جميع المدققين في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة من البيانات الوصفية فقط. أفادت ورقة Narwhal بقدرة معالجة تصل إلى 160,000 TPS.
لقد قدمنا سابقًا Quorum Store، وهو تنفيذ Narwhal الخاص بنا الذي يفصل بين نشر البيانات والتوافق، وكيفية استخدامه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة يجمع بين المسار السريع الخطي لـ Tendermint وتغيير الرؤية بأسلوب PBFT، مما يقلل من وقت الاستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، من الواضح أن بروتوكولات التوافق القائمة على القيادة لا يمكن أن تستفيد بشكل كامل من إمكانات الإنتاجية لـ Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القيادة في Hotstuff/Jolteon لا تزال مقيدة مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark فوق Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يأتي بتكلفة تأخير تبلغ 50٪.
تتناول هذه المقالة كيفية تقليل وقت الإستجابة لـ Bullshark بشكل كبير بواسطة Shoal.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
خلفية DAG-BFT
كل رأس في DAG لناروال مرتبط بدورة معينة. للدخول إلى الدورة r، يجب على المدقق أولاً الحصول على n-f من الرؤوس التي تنتمي إلى الدورة r-1. يمكن لكل مدقق بث رأس واحد في كل دورة، ويجب أن يشير كل رأس إلى n-f من الرؤوس في الدورة السابقة على الأقل. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
خاصية رئيسية لـ DAG هي أنها غير غامضة: إذا كان لدى عقدتي التحقق نفس القمة v في عرض DAG المحلي الخاص بهما، فإنهما يمتلكان تاريخ سبب v نفسه تمامًا.
المقدمة
يمكن تحقيق التوافق على الترتيب الكلي لجميع القمم في DAG دون أي تكلفة اتصال إضافية. لتحقيق ذلك، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG كنوع من بروتوكول الإجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تقاطع المجموعات في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع الحالية المستندة إلى Narwhal تتمتع بالبنية التالية:
نقاط الربط المحجوزة: كل عدة جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد مسبقًا، وذروة القائد تُعرف بنقطة الربط.
نقاط الربط الترتيبية: يحدد المدققون بشكل مستقل ولكن حاسم أي نقاط ربط يجب ترتيبها وأيها يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، بالنسبة لكل نقطة ربط، يتم ترتيب جميع القمم غير المرتبة السابقة في تاريخها السببي وفقًا لبعض القواعد الحتمية.
الشرط الأساسي لتحقيق الأمان هو ضمان أن جميع قوائم نقاط الربط المرتبة التي أنشأتها عقد التحقق النزيهة تشترك في نفس البادئة في الخطوة (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. ثم، تبدأ عقد المُصادقين في تنفيذ نموذج Bullshark الجديد باستخدام دالة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
يلعب الوقت المستجيب دورًا حاسمًا في جميع تطبيقات BFT القائمة على الزعيم. ومع ذلك، فإن التعقيد الذي تطرحه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب المزيد من تقنيات المراقبة.
سوف يؤدي الوقت المستغرق أيضاً إلى زيادة وقت الإستجابة بشكل ملحوظ، لأن تكوينها بشكل مناسب مهم جداً، وغالباً ما يتطلب تعديلات ديناميكية، لأنه يعتمد بشكل كبير على بيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستقوم البروتوكول بدفع عقوبة وقت الإستجابة الكاملة للقائد المعطل.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
إطار Shoal أسقط وقت الإستجابة Bullshark على بلوكتشين Aptos
إطار Shoal: تقليل وقت الإستجابة لBullshark على Aptos بشكل كبير
قامت Aptos Labs مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل ملحوظ، ولأول مرة ألغت الحاجة إلى مهلة في بروتوكولات العملية الحاسمة. بشكل عام، تحسن وقت الإستجابة لبولشارك بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز بروتوكول الإجماع القائم على Narwhal من خلال آلية خط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). يقلل خط الأنابيب من وقت الإستجابة عن طريق إدخال نقطة مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت عن طريق ضمان ارتباط النقاط المرجعية بأسرع عقد التحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على مهلة في جميع السيناريوهات. وهذا يمكّن Shoal من تقديم خاصية الاستجابة العامة، والتي تتضمن الاستجابة المتفائلة التي تُطلب عادةً.
هذه التقنية بسيطة جدًا، حيث تتضمن تشغيل عدة مثيلات من البروتوكولات الأساسية واحدة تلو الأخرى. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
الخلفية
في سعيهم لتحقيق أداء عالٍ لشبكة البلوكشين، كان الناس دائمًا مهتمين بتقليل تعقيد الاتصالات. ومع ذلك، لم تؤدِ هذه الطريقة إلى زيادة كبيرة في الإنتاجية. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem 3500 TPS فقط، وهو أقل بكثير من الهدف البالغ 100000+ TPS.
إن الانفراجة الأخيرة جاءت من فهم أن نقل البيانات هو العقبة الرئيسية التي تستند إلى بروتوكول القادة، ويمكن أن تستفيد من التوازي. يقوم نظام Narwhal بفصل نقل البيانات عن المنطق الأساسي للإجماع، حيث يقدم بنية يتم فيها نقل البيانات من قبل جميع المدققين في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة من البيانات الوصفية فقط. أفادت ورقة Narwhal بقدرة معالجة تصل إلى 160,000 TPS.
لقد قدمنا سابقًا Quorum Store، وهو تنفيذ Narwhal الخاص بنا الذي يفصل بين نشر البيانات والتوافق، وكيفية استخدامه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة يجمع بين المسار السريع الخطي لـ Tendermint وتغيير الرؤية بأسلوب PBFT، مما يقلل من وقت الاستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، من الواضح أن بروتوكولات التوافق القائمة على القيادة لا يمكن أن تستفيد بشكل كامل من إمكانات الإنتاجية لـ Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القيادة في Hotstuff/Jolteon لا تزال مقيدة مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark فوق Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يأتي بتكلفة تأخير تبلغ 50٪.
تتناول هذه المقالة كيفية تقليل وقت الإستجابة لـ Bullshark بشكل كبير بواسطة Shoal.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
خلفية DAG-BFT
كل رأس في DAG لناروال مرتبط بدورة معينة. للدخول إلى الدورة r، يجب على المدقق أولاً الحصول على n-f من الرؤوس التي تنتمي إلى الدورة r-1. يمكن لكل مدقق بث رأس واحد في كل دورة، ويجب أن يشير كل رأس إلى n-f من الرؤوس في الدورة السابقة على الأقل. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
خاصية رئيسية لـ DAG هي أنها غير غامضة: إذا كان لدى عقدتي التحقق نفس القمة v في عرض DAG المحلي الخاص بهما، فإنهما يمتلكان تاريخ سبب v نفسه تمامًا.
المقدمة
يمكن تحقيق التوافق على الترتيب الكلي لجميع القمم في DAG دون أي تكلفة اتصال إضافية. لتحقيق ذلك، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG كنوع من بروتوكول الإجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تقاطع المجموعات في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع الحالية المستندة إلى Narwhal تتمتع بالبنية التالية:
نقاط الربط المحجوزة: كل عدة جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد مسبقًا، وذروة القائد تُعرف بنقطة الربط.
نقاط الربط الترتيبية: يحدد المدققون بشكل مستقل ولكن حاسم أي نقاط ربط يجب ترتيبها وأيها يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، بالنسبة لكل نقطة ربط، يتم ترتيب جميع القمم غير المرتبة السابقة في تاريخها السببي وفقًا لبعض القواعد الحتمية.
الشرط الأساسي لتحقيق الأمان هو ضمان أن جميع قوائم نقاط الربط المرتبة التي أنشأتها عقد التحقق النزيهة تشترك في نفس البادئة في الخطوة (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. ثم، تبدأ عقد المُصادقين في تنفيذ نموذج Bullshark الجديد باستخدام دالة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
يلعب الوقت المستجيب دورًا حاسمًا في جميع تطبيقات BFT القائمة على الزعيم. ومع ذلك، فإن التعقيد الذي تطرحه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب المزيد من تقنيات المراقبة.
سوف يؤدي الوقت المستغرق أيضاً إلى زيادة وقت الإستجابة بشكل ملحوظ، لأن تكوينها بشكل مناسب مهم جداً، وغالباً ما يتطلب تعديلات ديناميكية، لأنه يعتمد بشكل كبير على بيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستقوم البروتوكول بدفع عقوبة وقت الإستجابة الكاملة للقائد المعطل.