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