إطار Shoal: كيف يمكن اسقاط وقت الإستجابة Bullshark على Aptos
قامت Aptos Labs مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أسقط وقت الإستجابة بشكل كبير، وألغت للمرة الأولى الحاجة إلى المهلة في البروتوكولات الفعلية المحددة. بشكل عام، تم تحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal ( مثل DAG-Rider و Tusk و Bullshark ) من خلال خط الأنابيب وسمعة القائد. يقلل خط الأنابيب من وقت الإستجابة من خلال إدخال نقطة مرجعية في كل جولة، بينما تحسن سمعة القائد من مشكلة وقت الإستجابة من خلال ضمان ارتباط النقاط المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، تتيح سمعة القائد لـ Shoal استخدام بنية DAG غير المتزامنة للقضاء على جميع السيناريوهات المتجاوزة للوقت. هذا يسمح لـ Shoal بتوفير خاصية تُعرف بالاستجابة العامة، والتي تحتوي على الاستجابة المتفائلة المطلوبة عادة.
هذه التقنية بسيطة جدًا، حيث تتضمن تشغيل عدة نسخ من البروتوكول الأساسي بالتتابع واحدًا تلو الآخر. وبالتالي، عندما يتم تهيئة باستخدام Bullshark، يتم الحصول على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا مهتمين باسقاط تعقيد الاتصالات. ومع ذلك، لم تؤد هذه الطريقة إلى زيادة كبيرة في معدل الإنتاج. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ 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٪.
تتناول هذه المقالة كيفية تحقيق Shoal انخفاضًا كبيرًا في وقت الإستجابة Bullshark.
خلفية 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 وقت الإستجابة
يعتمد وقت الإستجابة لبول شارك على عدد الدورات بين النقاط المرسلة المرتبة في DAG. على الرغم من أن الإصدار المتزامن الأكثر فائدة من بول شارك لديه وقت إستجابة أفضل من الإصدار غير المتزامن، إلا أنه بعيد عن كونه الأمثل.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة ربط في كل جولة زوجية، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى جولتين من DAG لطلب النقاط المربوطة، ومع ذلك، تحتاج القمم في التاريخ السببي للنقطة المربوطة إلى المزيد من الجولات في انتظار ترتيب النقطة المربوطة. في الحالات الشائعة، تحتاج القمم في الجولة الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرتبطة في الجولة الزوجية إلى أربع جولات.
السؤال 2: وقت الإستجابة لحالات الفشل، ينطبق التحليل المتأخر أعلاه على الحالات الخالية من الأخطاء، من ناحية أخرى، إذا فشل القائد في جولة ما في بث النقاط المرجعية بسرعة كافية، فلن يكون من الممكن ترتيب النقاط المرجعية ( وبالتالي سيتم تخطيها )، لذلك يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. سيؤدي ذلك إلى اسقاط كبير في أداء شبكة النسخ الجغرافية، خاصةً لأن Bullshark يستخدم وقت الإستجابة للانتظار على القائد.
إطار Shoal
حل Shoal مشكلتين من وقت الإستجابة هاتين، عن طريق تحسين Bullshark( أو أي بروتوكول BFT آخر يعتمد على Narwhal) من خلال استخدام خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة وتقليل وقت الإستجابة لجميع رؤوس DAG غير المرتبطة إلى ثلاث جولات. كما قدم Shoal آلية سمعة قائد بدون تكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر قضايا خط الأنابيب وسمعة القائد من المشاكل الصعبة، والأسباب كما يلي:
كانت خطوط الإنتاج السابقة تحاول تعديل منطق Bullshark الأساسي، لكن يبدو أن هذا أمر مستحيل من حيث الجوهر.
تم إدخال سمعة القادة في DiemBFT وتم تأكيدها في Carousel، وذلك من خلال اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المصدقين في الماضي في ( Bullshark. على الرغم من أن وجود تباين في هوية القادة لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار العوامة الديناميكية والحتمية هو أمر ضروري لحل الإجماع، ويحتاج المصدقون إلى التوصل إلى توافق بشأن التاريخ المرتب لاختيار العوامة المستقبلية.
كإثبات لصعوبة المسألة، فإن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، فإن الحل يكمن في البساطة.
في Shoal، تعتمد على القدرة على تنفيذ الحسابات المحلية على DAG، وتحقيق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل الفهم الأساسي الذي يتفق عليه جميع المدققين حول أول نقطة ربط مرتبة، تجمع Shoal بشكل متسلسل بين عدة حالات Bullshark وتقوم بمعالجتها بشكل متسلسل، مما يجعل ) أول نقطة ربط مرتبة هي نقطة التحول للحالات، و( التاريخ السببي للنقاط المستخدمة في حساب سمعة القائد.
![شرح شامل لإطار Shoal: كيف تقلل من وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
خط الأنابيب
V يربط الجولات بالقادة. تقوم Shoal بتشغيل مثيلات Bullshark واحدة تلو الأخرى، بحيث يتم تحديد النقطة المرجعية مسبقًا بواسطة التعيين F لكل مثيل. يطلب كل مثيل نقطة مرجعية، مما يؤدي إلى الانتقال إلى المثيل التالي.
في البداية، أطلق Shoal أول مثيل لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى تحديد أول نقطة ربط مرتبة، مثل الجولة r. اتفق جميع المدققين على هذه النقطة. لذلك، يمكن لجميع المدققين بالتأكيد الاتفاق على إعادة تفسير DAG بدءًا من الجولة r+1. بدأ Shoal فقط مثيلًا جديدًا لـ Bullshark في الجولة r+1.
في أفضل الظروف، يسمح هذا لـ Shoal بطلب رصيف في كل جولة. يتم ترتيب نقاط الرصيف في الجولة الأولى حسب المثال الأول. ثم، يبدأ Shoal مثلاً جديداً في الجولة الثانية، والذي يحتوي على نقطة رصيف، ويتم ترتيب هذه الرصيف بواسطة هذا المثال، ثم يتم طلب نقطة رصيف جديدة في الجولة الثالثة، وتستمر هذه العملية.
![شرح شامل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
سمعة القادة
عند تخطي النقاط الثابتة خلال ترتيب Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، فإن تقنية خط الأنابيب ليست فعالة، لأنه لا يمكن بدء مثيل جديد قبل طلب النقاط الثابتة في المثيل السابق. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ نشاطها الأخير، مما يجعل من غير المرجح اختيار القائد المناسب في المستقبل لمعالجة النقاط الثابتة المفقودة. سيحصل المدققون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، بينما ستُخصص درجات منخفضة لعقد التحقق الأخرى، لأنها قد تكون معطلة أو بطيئة أو تقوم بسلوك غير جيد.
مفاهيمها هي إعادة حساب التعيين المحدد F من الجولات إلى القادة بشكل حتمي في كل مرة يتم فيها تحديث الدرجات، مع الميل نحو القادة ذوي الدرجات الأعلى. لكي يتفق المتحققون على التعيين الجديد، يجب عليهم التوصل إلى توافق في الدرجات، وبالتالي تحقيق التوافق في التاريخ المستخدم لاشتقاق الدرجات.
في Shoal، يمكن أن تتكامل خطوط الإنتاج والسمعة القيادية بشكل طبيعي، لأنها تستخدم نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد ترتيب النقاط المرسى في الجولة r، يحتاج المدققون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي للنقاط المرسى المرتبة في الجولة r. ثم يبدأ عقد التحقق في تنفيذ نسخة جديدة من Bullshark باستخدام دالة اختيار النقاط المرسى المحدثة F' بدءًا من الجولة r+1.
![شرح مفصل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
لا مزيد من وقت الإستجابة
تلعب المهلة دورًا حاسمًا في جميع تنفيذات BFT المتزامنة القابلة للتحديد المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب تقنيات مراقبة أكثر.
سوف يزيد انتهاء المهلة بشكل كبير من وقت الإستجابة، لأنه من المهم تكوينها بشكل صحيح، وغالبًا ما تحتاج إلى تعديل ديناميكي، لأنها تعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع عقوبة انتهاء المهلة الكاملة للقائد الذي يعاني من عطل. لذلك، لا يمكن أن تكون إعدادات انتهاء المهلة متحفظة للغاية، ولكن إذا كان وقت انتهاء المهلة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات التحميل العالي، كان القادة في Jolteon/Hotstuff مثقلين، وانتهت المهلة قبل أن يتمكنوا من دفع التقدم.
لسوء الحظ، فإن بروتوكول القادة ) مثل Hotstuff و Jolteon ( يتطلب أساسًا وقت الإستجابة، لضمان أن كل قائد
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
إطار Shoal اسقط وقت الإستجابة Bullshark على Aptos بنسبة 40%-80%
إطار Shoal: كيف يمكن اسقاط وقت الإستجابة Bullshark على Aptos
قامت Aptos Labs مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أسقط وقت الإستجابة بشكل كبير، وألغت للمرة الأولى الحاجة إلى المهلة في البروتوكولات الفعلية المحددة. بشكل عام، تم تحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal ( مثل DAG-Rider و Tusk و Bullshark ) من خلال خط الأنابيب وسمعة القائد. يقلل خط الأنابيب من وقت الإستجابة من خلال إدخال نقطة مرجعية في كل جولة، بينما تحسن سمعة القائد من مشكلة وقت الإستجابة من خلال ضمان ارتباط النقاط المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، تتيح سمعة القائد لـ Shoal استخدام بنية DAG غير المتزامنة للقضاء على جميع السيناريوهات المتجاوزة للوقت. هذا يسمح لـ Shoal بتوفير خاصية تُعرف بالاستجابة العامة، والتي تحتوي على الاستجابة المتفائلة المطلوبة عادة.
هذه التقنية بسيطة جدًا، حيث تتضمن تشغيل عدة نسخ من البروتوكول الأساسي بالتتابع واحدًا تلو الآخر. وبالتالي، عندما يتم تهيئة باستخدام Bullshark، يتم الحصول على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا مهتمين باسقاط تعقيد الاتصالات. ومع ذلك، لم تؤد هذه الطريقة إلى زيادة كبيرة في معدل الإنتاج. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ 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٪.
تتناول هذه المقالة كيفية تحقيق Shoal انخفاضًا كبيرًا في وقت الإستجابة Bullshark.
خلفية 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 وقت الإستجابة
يعتمد وقت الإستجابة لبول شارك على عدد الدورات بين النقاط المرسلة المرتبة في DAG. على الرغم من أن الإصدار المتزامن الأكثر فائدة من بول شارك لديه وقت إستجابة أفضل من الإصدار غير المتزامن، إلا أنه بعيد عن كونه الأمثل.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة ربط في كل جولة زوجية، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى جولتين من DAG لطلب النقاط المربوطة، ومع ذلك، تحتاج القمم في التاريخ السببي للنقطة المربوطة إلى المزيد من الجولات في انتظار ترتيب النقطة المربوطة. في الحالات الشائعة، تحتاج القمم في الجولة الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرتبطة في الجولة الزوجية إلى أربع جولات.
السؤال 2: وقت الإستجابة لحالات الفشل، ينطبق التحليل المتأخر أعلاه على الحالات الخالية من الأخطاء، من ناحية أخرى، إذا فشل القائد في جولة ما في بث النقاط المرجعية بسرعة كافية، فلن يكون من الممكن ترتيب النقاط المرجعية ( وبالتالي سيتم تخطيها )، لذلك يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. سيؤدي ذلك إلى اسقاط كبير في أداء شبكة النسخ الجغرافية، خاصةً لأن Bullshark يستخدم وقت الإستجابة للانتظار على القائد.
إطار Shoal
حل Shoal مشكلتين من وقت الإستجابة هاتين، عن طريق تحسين Bullshark( أو أي بروتوكول BFT آخر يعتمد على Narwhal) من خلال استخدام خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة وتقليل وقت الإستجابة لجميع رؤوس DAG غير المرتبطة إلى ثلاث جولات. كما قدم Shoal آلية سمعة قائد بدون تكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر قضايا خط الأنابيب وسمعة القائد من المشاكل الصعبة، والأسباب كما يلي:
كانت خطوط الإنتاج السابقة تحاول تعديل منطق Bullshark الأساسي، لكن يبدو أن هذا أمر مستحيل من حيث الجوهر.
تم إدخال سمعة القادة في DiemBFT وتم تأكيدها في Carousel، وذلك من خلال اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المصدقين في الماضي في ( Bullshark. على الرغم من أن وجود تباين في هوية القادة لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار العوامة الديناميكية والحتمية هو أمر ضروري لحل الإجماع، ويحتاج المصدقون إلى التوصل إلى توافق بشأن التاريخ المرتب لاختيار العوامة المستقبلية.
كإثبات لصعوبة المسألة، فإن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، فإن الحل يكمن في البساطة.
في Shoal، تعتمد على القدرة على تنفيذ الحسابات المحلية على DAG، وتحقيق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل الفهم الأساسي الذي يتفق عليه جميع المدققين حول أول نقطة ربط مرتبة، تجمع Shoal بشكل متسلسل بين عدة حالات Bullshark وتقوم بمعالجتها بشكل متسلسل، مما يجعل ) أول نقطة ربط مرتبة هي نقطة التحول للحالات، و( التاريخ السببي للنقاط المستخدمة في حساب سمعة القائد.
![شرح شامل لإطار Shoal: كيف تقلل من وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
خط الأنابيب
V يربط الجولات بالقادة. تقوم Shoal بتشغيل مثيلات Bullshark واحدة تلو الأخرى، بحيث يتم تحديد النقطة المرجعية مسبقًا بواسطة التعيين F لكل مثيل. يطلب كل مثيل نقطة مرجعية، مما يؤدي إلى الانتقال إلى المثيل التالي.
في البداية، أطلق Shoal أول مثيل لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى تحديد أول نقطة ربط مرتبة، مثل الجولة r. اتفق جميع المدققين على هذه النقطة. لذلك، يمكن لجميع المدققين بالتأكيد الاتفاق على إعادة تفسير DAG بدءًا من الجولة r+1. بدأ Shoal فقط مثيلًا جديدًا لـ Bullshark في الجولة r+1.
في أفضل الظروف، يسمح هذا لـ Shoal بطلب رصيف في كل جولة. يتم ترتيب نقاط الرصيف في الجولة الأولى حسب المثال الأول. ثم، يبدأ Shoal مثلاً جديداً في الجولة الثانية، والذي يحتوي على نقطة رصيف، ويتم ترتيب هذه الرصيف بواسطة هذا المثال، ثم يتم طلب نقطة رصيف جديدة في الجولة الثالثة، وتستمر هذه العملية.
![شرح شامل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
سمعة القادة
عند تخطي النقاط الثابتة خلال ترتيب Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، فإن تقنية خط الأنابيب ليست فعالة، لأنه لا يمكن بدء مثيل جديد قبل طلب النقاط الثابتة في المثيل السابق. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ نشاطها الأخير، مما يجعل من غير المرجح اختيار القائد المناسب في المستقبل لمعالجة النقاط الثابتة المفقودة. سيحصل المدققون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، بينما ستُخصص درجات منخفضة لعقد التحقق الأخرى، لأنها قد تكون معطلة أو بطيئة أو تقوم بسلوك غير جيد.
مفاهيمها هي إعادة حساب التعيين المحدد F من الجولات إلى القادة بشكل حتمي في كل مرة يتم فيها تحديث الدرجات، مع الميل نحو القادة ذوي الدرجات الأعلى. لكي يتفق المتحققون على التعيين الجديد، يجب عليهم التوصل إلى توافق في الدرجات، وبالتالي تحقيق التوافق في التاريخ المستخدم لاشتقاق الدرجات.
في Shoal، يمكن أن تتكامل خطوط الإنتاج والسمعة القيادية بشكل طبيعي، لأنها تستخدم نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد ترتيب النقاط المرسى في الجولة r، يحتاج المدققون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي للنقاط المرسى المرتبة في الجولة r. ثم يبدأ عقد التحقق في تنفيذ نسخة جديدة من Bullshark باستخدام دالة اختيار النقاط المرسى المحدثة F' بدءًا من الجولة r+1.
![شرح مفصل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
لا مزيد من وقت الإستجابة
تلعب المهلة دورًا حاسمًا في جميع تنفيذات BFT المتزامنة القابلة للتحديد المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب تقنيات مراقبة أكثر.
سوف يزيد انتهاء المهلة بشكل كبير من وقت الإستجابة، لأنه من المهم تكوينها بشكل صحيح، وغالبًا ما تحتاج إلى تعديل ديناميكي، لأنها تعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع عقوبة انتهاء المهلة الكاملة للقائد الذي يعاني من عطل. لذلك، لا يمكن أن تكون إعدادات انتهاء المهلة متحفظة للغاية، ولكن إذا كان وقت انتهاء المهلة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات التحميل العالي، كان القادة في Jolteon/Hotstuff مثقلين، وانتهت المهلة قبل أن يتمكنوا من دفع التقدم.
لسوء الحظ، فإن بروتوكول القادة ) مثل Hotstuff و Jolteon ( يتطلب أساسًا وقت الإستجابة، لضمان أن كل قائد