! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-a5fdeca023-dd1a6f-62a40f)
ملخص
لقد حلت مختبرات Aptos مشكلتين مهمتين مفتوحتين في DAG BFT ، مما قلل بشكل كبير من زمن الوصول ، ولأول مرة ألغيت الحاجة إلى التوقف المؤقت في البروتوكولات العملية الحتمية. بشكل عام ، يعمل هذا على تحسين زمن انتقال Bullshark بنسبة 40٪ في حالة عدم الفشل و 80٪ في حالة الخطأ.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal (على سبيل المثال ، DAG-Rider و Tusk و Bullshark) من خلال خطوط الأنابيب وسمعة القائد. يقلل Pipelining من زمن انتقال طلب DAG من خلال تقديم مرساة في كل جولة ، كما تعمل سمعة القائد على تحسين زمن الوصول من خلال ضمان ارتباط المراسي بأسرع المدققين. بالإضافة إلى ذلك ، تمكّن سمعة القائد Shoal من الاستفادة من بنية DAG غير المتزامنة للقضاء على المهلات في جميع السيناريوهات. يسمح هذا لـ Shoal بتوفير خاصية أطلقنا عليها اسم Universal Response ، والتي تحتوي على الاستجابة المثلى المطلوبة عادةً.
أسلوبنا بسيط للغاية ، فهو يتضمن تشغيل مثيلات متعددة من البروتوكول الأساسي بالتتابع واحدة تلو الأخرى. لذلك ، عند إنشاء مثيل مع 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. لسوء الحظ ، يأتي هيكل DAG الذي يدعم الإنتاجية العالية لشركة Bullshark مع عقوبة زمن انتقال بنسبة 50 ٪ مقارنةً بـ Jolteon.
في هذا المنشور ، نصف كيف حقق Shoal انخفاضًا كبيرًا في زمن انتقال Bullshark.
خلفية DAG-BFT
لنبدأ بفهم الخلفية ذات الصلة لهذه المقالة. للحصول على وصف مفصل لـ Narwhal و Bullshark ، يرجى الرجوع إلى DAG يلتقي بوظيفة BFT.
يرتبط كل رأس في Narwhal DAG برقم دائري. للدخول إلى الجولة r ، يجب على المدقق أولاً الحصول على رؤوس nf التي تنتمي إلى الجولة r-1. يمكن لكل مدقق بث رأس واحد لكل جولة ، ويشير كل رأس إلى رؤوس nf على الأقل في الجولة السابقة. نظرًا لعدم تزامن الشبكة ، قد يلاحظ المدققون المختلفون طرق عرض محلية مختلفة لـ DAG في أي وقت. فيما يلي توضيح لعرض جزئي محتمل:
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-931319a954-dd1a6f-62a40f)
الشكل 1: يتم تمييز التاريخ السببي للرؤوس التي تم تحديدها بواسطة عقدة التحقق من صحة الجولة 2 باللون الأخضر
الخاصية الرئيسية لـ DAGs ليست الغموض: اثنان من المدققين لهما نفس التاريخ السببي تمامًا لـ v إذا كان لديهم نفس الرأس v في وجهة نظرهم المحلية لـ DAG.
من أجل الكاملة
من الممكن الاتفاق على الترتيب الإجمالي لجميع الرؤوس في DAG دون الحاجة إلى اتصال إضافي. تحقيقا لهذه الغاية ، يفسر المدققون في DAG-Rider و Tusk و Bullshark هيكل DAG على أنه بروتوكول إجماع ، حيث تمثل الرؤوس المقترحات وتمثل الحواف الأصوات.
على الرغم من اختلاف منطق تقاطع المجموعة في بنية DAG ، إلا أن جميع بروتوكولات الإجماع الحالية القائمة على Narwhal لها الهيكل التالي:
المراسي المحددة مسبقًا ، سيكون هناك قائد محدد مسبقًا كل عدة جولات (على سبيل المثال ، جولتان في Bullshark) ، وتسمى رؤوس الزعيم المراسي ؛
طلب المراسي ، يقرر المدقق بشكل مستقل ولكن بشكل حاسم المراسي التي يجب طلبها وأي المراسي يجب تخطيها ؛
ترتيب التواريخ السببية ، حيث يقوم المدققون بمعالجة قائمة المراسي المرتبة واحدة تلو الأخرى ، ولكل نقطة ارتساء ، قم بفرز جميع الرؤوس غير المرتبة سابقًا في تاريخها السببي من خلال بعض القواعد الحتمية.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-51897602ab-dd1a6f-62a40f)
الشكل 2: رسم توضيحي لعرض جزئي محتمل لـ DAG في بروتوكول Bullshark. في هذا المثال ، يتم فرز المراسي الحمراء والصفراء ، بينما يتم تخطي الأخضر (ليس في DAG). لذلك ، لطلب DAG ، يقوم المدققون بترتيب التواريخ السببية للمراسي الحمراء أولاً بشكل قاطع ، تليها المراسي الصفراء.
المفتاح لتحقيق الأمان هو التأكد من أنه في الخطوة (2) أعلاه ، يقوم جميع المدققين الصادقين بإنشاء قائمة مرتبة من نقاط الارتساء بحيث تشترك جميع القوائم في نفس البادئة. في Shoal ، نقدم الملاحظات التالية لجميع البروتوكولات المذكورة أعلاه:
** يتفق جميع المدققين على المرساة الأولى المطلوبة. **
بولشارك الكمون
يعتمد وقت استجابة Bullshark على عدد الجولات بين المراسي المطلوبة في DAG. في حين أن الإصدار المتزامن جزئياً الأكثر فائدة من Bullshark لديه زمن انتقال أفضل من الإصدار غير المتزامن ، إلا أنه بعيد عن المستوى الأمثل.
المشكلة 1: متوسط زمن انتقال الكتلة. في Bullshark ، كل جولة زوجية لها مرساة ، ويتم تفسير رؤوس كل جولة فردية على أنها أصوات. عادةً ما يستغرق الأمر جولتين من DAG لطلب المراسي ، ومع ذلك ، فإن الرؤوس في التاريخ السببي للمرساة تستغرق عدة جولات أخرى لانتظار طلب المرساة. في الحالة الشائعة ، تتطلب الرؤوس في الجولات الفردية ثلاث جولات ، بينما تتطلب الرؤوس غير المرساة في الجولات الزوجية أربع جولات (انظر الشكل 3).
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-94f64a51cc-dd1a6f-62a40f)
الشكل 3: في الحالة الشائعة ، يجب فرز المراسي في الجولة i + 1 لجولتين. يتم فرز القمم في الجولة الأولى في وقت واحد ، لذلك يكون وقت الاستجابة ثلاث جولات. ومع ذلك ، يجب أن تنتظر الرؤوس في الجولة i + 1 حتى يتم فرز المرساة التالية (التي في الجولة i + 3) ، وبالتالي فإن تأخير الفرز هو أربع جولات.
المشكلة 2: زمن انتقال حالة الفشل ، ينطبق تحليل زمن الوصول أعلاه على حالة عدم الفشل ، من ناحية أخرى ، إذا فشل قائد الجولة في بث المراسي بسرعة كافية ، فلا يمكن طلب المراسي (وبالتالي يتم تخطيها) ، لذلك الكل يجب أن تنتظر القمم التي لم يتم فرزها في الجولات السابقة حتى يتم فرز المرساة التالية. يمكن أن يقلل هذا بشكل كبير من أداء شبكة مكررة جغرافيًا ، خاصة وأن Bullshark يستخدم المهلات في انتظار القائد.
إطار Shoal Framework
يحل Shoal كل من مشكلات زمن الوصول هذه عن طريق تعزيز Bullshark (أو أي بروتوكول BFT آخر قائم على Narwhal) عن طريق الأنابيب ، مما يسمح بمرساة في كل جولة ، وتقليل زمن انتقال جميع الرؤوس غير المرساة في DAG إلى ثلاث جولات. يقدم Shoal أيضًا آلية سمعة القائد الصفري في DAG ، والتي تحيز الاختيار لصالح القادة السريعين.
تحدي
في سياق بروتوكولات DAG ، يعتبر خط الأنابيب وسمعة القائد مشاكل صعبة للأسباب التالية:
محاولات خطوط الأنابيب السابقة لتعديل منطق Bullshark الأساسي ، لكن هذا يبدو مستحيلاً بطبيعته
سمعة القائد ، التي تم تقديمها في DiemBFT وتم إضفاء الطابع الرسمي عليها في Carousel ، هي فكرة الاختيار الديناميكي لقادة المستقبل (المراسي في Bullshark) بناءً على الأداء السابق للمدققين. في حين أن الخلاف حول هوية القائد لا ينتهك الأمان في هذه البروتوكولات ، إلا أنه في Bullshark يمكن أن يؤدي إلى ترتيب مختلف تمامًا ، والذي يصل إلى قلب السؤال ، وهو أن الاختيار الديناميكي والحتمي لمثبتات العجلات هو المفتاح لحل الإجماع المطلوب ، بينما يحتاج المدققون إلى الاتفاق على سجل مرتب لاختيار نقاط ارتساء مستقبلية.
كدليل على صعوبة المشكلة ، نلاحظ أن تنفيذ Bullshark ، بما في ذلك التنفيذ الحالي في الإنتاج ، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه ، اتضح أن الحلول ، كما يقال ، تكمن وراء البساطة.
في Shoal ، نعتمد على القدرة على إجراء الحسابات المحلية على DAG وتنفيذ القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. مع البصيرة الأساسية التي يتفق عليها جميع المدققين على المرساة الأولى المطلوبة ، تقوم أنابيب Shoal بتكوينها من خلال إنشاء عدة مثيلات Bullshark في تسلسل بحيث (1) المرساة الأولى المطلوبة هي نقطة التبديل للحالات ، و (2) التاريخ السببي لـ تستخدم المراسي لحساب سمعة القائد.
خطوط الأنابيب
على غرار Bullshark ، يوافق المدققون مسبقًا على المراسي المحتملة ، أي أن هناك تعيينًا معروفًا F: R -> V جولات رسم الخرائط للقادة. يدير Shoal مثيلات Bullshark واحدة تلو الأخرى بحيث يتم تحديد المرساة مسبقًا بواسطة الخريطة F. يطلب كل مثيل مرساة ، والتي تؤدي إلى التبديل إلى المثيل التالي.
في البداية ، أطلق Shoal أول مثيل لـ Bullshark في الجولة الأولى من DAG وتشغيله حتى يتم تحديد المرساة الأولى المطلوبة ، على سبيل المثال في الجولة r. يتفق جميع المدققين على هذا المرساة. لذلك ، يمكن لجميع المدققين الموافقة بشكل حاسم على إعادة تفسير DAG بدءًا من الجولة r + 1. يبدأ Shoal في إصدار نسخة جديدة من Bullshark في الجولة r + 1.
في أفضل سيناريو ، يسمح هذا لـ Shoal بطلب مرساة في كل جولة. يتم فرز المراسي للجولة الأولى حسب الحالة الأولى. بعد ذلك ، يبدأ Shoal مثيلًا جديدًا في الجولة الثانية ، والذي يحتوي في حد ذاته على مرساة مرتبة حسب المثال ، ثم يقوم مثيل جديد آخر بطلب المراسي في الجولة الثالثة ، وتستمر العملية. يرجى الاطلاع على الرسم التوضيحي أدناه:
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-815c54edb-dd1a6f-62a40f)
الشكل 4: الرؤوس المقابلة للقادة التي يحددها F مميزة بتاج. يفسر المثال الأول لـ Bullshark أولاً DAG مع المراسي في الجولات 1 و 3 و 5. يحدد Bullshark المراسي في الجولة 1 (في علامة اختيار خضراء mark) هو أول ما يتم فرزه في المقام الأول. (لاحظ أنه في الحالة العامة ، يمكن تخطي هذا المرساة ، في حين يتم فرز بعض المراسي الأخرى أولاً.) ثم يتم تجاهل بقية المثيل الأول ، ويبدأ مثيل جديد لـ Bullshark من الجولة 2 ، ويتم تمييز نقاط الربط في الجولتين 2 و 4.
سمعة القائد
زيادة زمن الوصول عند تخطي المراسي أثناء فرز Bullshark. في هذه الحالة ، تكون تقنية Pipelining عاجزة لأنه لا يمكن بدء مثيل جديد حتى يطلب المثيل السابق مرساة. يضمن Shoal أنه من غير المرجح أن يتم انتخاب القائد المناسب في المستقبل للتعامل مع مرساة مفقودة باستخدام آلية سمعة لتعيين درجة لكل مدقق بناءً على تاريخ نشاطه الأخير. سيتم منح المدقق الذي يستجيب ويشارك في البروتوكول درجة عالية ، وإلا فسيتم تعيين درجة منخفضة للمدقق لأنه قد يتعطل أو يكون بطيئًا أو ضارًا.
الفكرة هي إعادة حساب التعيين المحدد مسبقًا F بشكل حاسم من الجولات إلى القادة في كل تحديث للنتيجة ، مع تفضيل القادة ذوي الدرجات الأعلى. لكي يتفق المدققون على التعيين الجديد ، يجب أن يتفقوا على الدرجة وبالتالي التاريخ المستخدم لاشتقاق النتيجة.
في Shoal ، يمكن الجمع بين سمعة خطوط الأنابيب والقيادة بشكل طبيعي لأن كلاهما يستخدم نفس الأسلوب الأساسي لإعادة تفسير DAG بعد الاتفاق على المرساة الأولى المطلوبة.
في الواقع ، الاختلاف الوحيد هو أنه بعد فرز المراسي في الجولة r ، يحتاج المدقق فقط إلى حساب تعيين جديد F 'من الجولة r + 1 استنادًا إلى التاريخ السببي للمراسي المرتبة في الجولة r. بعد ذلك ، يقوم المدقق بتنفيذ مثيل جديد من Bullshark بدءًا من الجولة r + 1 باستخدام وظيفة تحديد المرساة المحدثة F '. انظر الصورة أدناه:
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-c1d8088bd3-dd1a6f-62a40f)
الشكل 5. القمم المقابلة للقادة المحددة بواسطة F مميزة بتيجان شفافة. يطلب المثيل الأول من Bullshark مرساة في الجولة 1 ، مميزة بعلامة اختيار خضراء ، ثم يحسب تعيينًا جديدًا F 'استنادًا إلى المعلومات الموجودة في التاريخ السببي للمرساة. يتم تمييز القادة الذين تحددهم F 'بتيجان ملونة.
لا مزيد من المهلات
تلعب المهلات دورًا حاسمًا في جميع عمليات تنفيذ BFT الحتمية المتزامنة جزئيًا والقائمة على القائد. ومع ذلك ، فإن التعقيد الذي يقدمونه يزيد من مقدار الحالة الداخلية التي يجب إدارتها ومراقبتها ، مما يعقد عملية التصحيح ويتطلب المزيد من تقنيات الملاحظة.
يمكن أن تضيف المهلات أيضًا بشكل كبير إلى زمن الانتقال ، نظرًا لأنه من المهم تهيئتها بشكل مناسب ، وعادة ما تحتاج إلى تعديل ديناميكي ، لأنها تعتمد بشكل كبير على البيئة (الشبكة). يدفع البروتوكول للقائد الخاطئ عقوبة تأخير المهلة الكاملة قبل الانتقال إلى القائد التالي. لذلك ، لا يمكن أن يكون إعداد المهلة متحفظًا للغاية ، ولكن إذا كانت المهلة قصيرة جدًا ، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال ، لاحظنا أنه في ظل العبء الكبير ، كان القادة في Jolteon / Hotstuff مرهقين وانتهت المهلات قبل أن يتمكنوا من دفع التقدم.
لسوء الحظ ، تتطلب البروتوكولات القائمة على القائد مثل Hotstuff و Jolteon بطبيعتها مهلات للتأكد من أن البروتوكول يمكن أن يحرز تقدمًا في كل مرة يفشل فيها القائد. بدون مهلة ، حتى القائد المحطم يمكنه إيقاف البروتوكول إلى الأبد. نظرًا لعدم القدرة على التمييز بين القائد الخاطئ والقائد البطيء أثناء عدم التزامن ، يمكن أن تتسبب المهلات في أن يرى المدققون التغييرات لجميع القادة دون التوافق في الآراء.
في Bullshark ، تُستخدم المهلات في إنشاء DAG للتأكد من أن القائد الصادق أثناء المزامنة يضيف المراسي إلى DAG بسرعة كافية ليتم طلبها.
نلاحظ أن بناء DAG يوفر "ساعة" لتقدير سرعة الشبكة. في حالة عدم وجود توقف مؤقت ، تستمر الجولات في التقدم طالما استمر المدققون الصادقون في إضافة رؤوس إلى DAG. في حين أن Bullshark قد لا يكون قادرًا على الفرز بسرعة الشبكة (بسبب القادة المشكلون) ، لا يزال DAG ينمو بسرعة الشبكة على الرغم من بعض مشاكل القائد أو أن الشبكة غير متزامنة. في النهاية ، عندما يبث القائد الخالي من العيوب المراسي بسرعة كافية ، فسيتم ترتيب التاريخ السببي الكامل للمراسي.
في تقييمنا ، قارنا Bullshark مع وبدون مهلة في الحالات التالية:
القائد السريع ، وهذا يعني على الأقل أسرع من المدققين الآخرين. في هذه الحالة ، توفر كلتا الطريقتين نفس وقت الاستجابة لأنه يتم ترتيب نقاط الارتساء وعدم استخدام المهلات.
القائد الخاطئ ، في هذه الحالة ، يوفر Bullshark بدون توقف زمن انتقال أفضل حيث سيتخطى المدققون على الفور نقاط ارتكازه ، بينما ينتظر المدققون مع التوقفات وصولهم قبل استمرار توقع.
القائد البطيء ، هذه هي الحالة الوحيدة التي يتمتع فيها Bullshark بأداء مهلة أفضل. هذا لأنه ، بدون توقف مؤقت ، قد يتم تخطي المرساة لأن القائد لا يمكنه بثها بالسرعة الكافية ، بينما مع التوقف ، سينتظر المدققون المرساة.
في Shoal ، يسير تجنب المهلات وسمعة القيادة جنبًا إلى جنب. يؤدي الانتظار المتكرر لقائد بطيء إلى زيادة وقت الاستجابة ، كما أن آلية سمعة القائد تمنع المدققين البطيئين من انتخابهم كقادة. بهذه الطريقة ، يستخدم النظام عقد التحقق السريع للتشغيل بسرعة الشبكة في جميع سيناريوهات العالم الحقيقي.
لاحظ أن نتيجة استحالة FLP تُظهر أنه لا يوجد بروتوكول إجماع حتمي يمكنه تجنب المهلات. لا يمكن لـ Shoal التحايل على هذه النتيجة لأن هناك جدولًا نظريًا للأحداث العدائية التي من شأنها أن تمنع جميع المراسلين من الأوامر. بدلاً من ذلك ، يعود Shoal إلى المهلة بعد عدد قابل للتكوين من عمليات تخطي الارتساء المتتالية. من الناحية العملية ، من غير المرجح أن يحدث هذا.
الاستجابة العامة
روجت ورقة Hotstuff لمفهوم الاستجابة المتفائلة ، والتي ، على الرغم من عدم تعريفها رسميًا ، تعني بشكل حدسي أن البروتوكول يمكن أن يعمل بسرعة الشبكة في ظل ظروف جيدة بما في ذلك القائد السريع والشبكة المتزامنة.
يوفر Shoal خاصية أفضل ، والتي نسميها الاستجابة العالمية. على وجه التحديد ، على عكس Hotstuff ، يستمر Shoal في العمل بسرعة الشبكة حتى إذا فشل القائد في عدد قابل للتكوين من الجولات المتتالية أو الدورات غير المتزامنة التي تمر من خلالها الشبكة. شاهد مقارنة أكثر تفصيلاً في الجدول أدناه.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-b87c1b94cb-dd1a6f-62a40f)
لاحظ أن الاستجابة العامة توفر ضمانات تقدم أفضل بشكل صارم خلال الفترات غير المتزامنة وعندما يفشل القائد. أثناء المزامنة مع قائد بطيء ، لا يمكن مقارنة هذه الخصائص لأنها تعتمد على مدى بطء القائد. ومع ذلك ، نظرًا لسمعة القائد ، نادرًا ما يظهر القادة بطيئون الحركة في Shoal.
يقيم
قمنا بتنفيذ Bullshark و Shoal على رأس متجر Quorum لتطبيق Narwhal. يمكن العثور على مقارنة مفصلة بين Shoal و Bullshark و Jolteon في قسم التقييم في ورقة Shoal ، حيث نقدم بعض النقاط البارزة.
أولاً ، لإثبات قوة بناء DAG غير المتزامن ، نقارن Bullshark مع وبدون توقفات. تفترض ورقة Bullshark الكاملة وجود شبكة غير متزامنة ، ولكنها توفر وضع مسار سريع ، مما يتطلب توقفًا مؤقتًا أثناء جميع الجولات. نسمي هذا الإصدار Vanilla Bullshark. نلاحظ أنه بالنسبة للإصدارات الافتراضية للشبكة المستقلة المتزامنة جزئيًا ، لا يلزم التوقف مؤقتًا في جولات التصويت. نسمي هذا الإصدار Vanilla Bullshark بدون مهلة التصويت بدون مهلة التصويت ، Baseline Bullshark هو الإصدار بدون أي مهلة.
يقارن الرسم البياني أدناه تأثير المهلات على زمن انتقال Bullshark مع الإخفاقات وبدونها. على ما يبدو ، فإن Baseline Bullshark (بدون مهلة) تؤدي بشكل أفضل في حالة الفشل. مع عدم وجود إخفاقات ، فإن Baseline Bullshark قابلة للمقارنة مع Vanilla Bullshark بدون تعليق التصويت. هذا لأنه ، كما ذكرنا سابقًا ، بدون آلية سمعة القائد ، قد يكون للمهلة ميزة في المواقف التي يكون فيها القائد جيدًا ولكن بطيئًا.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-d49abda989-dd1a6f-62a40f)
الشكل 6: تأثير المهلات على زمن انتقال Bullshark بدون إخفاقات (يسار) ومع حالات فشل (يمين) ، مع وجود 50 مدققًا في حالة الفشل
بعد ذلك ، نقوم بإنشاء مثيل Shoal باستخدام Baseline Bullshark (بدون مهلة) ونوضح تحسينات زمن الوصول لخط الأنابيب وآلية سمعة القائد مع وبدون فشل ، ولتحقيق الاكتمال ، نقارنها أيضًا بـ Jolteon مع وبدون فشل مقارنة.
يوضح الشكل 7 أدناه حالة عدم الفشل ، وبينما يمكن أن يقلل كل من خطوط الأنابيب وسمعة القائد من زمن الانتقال بشكل فردي ، فإن الجمع بينهما يؤدي إلى أفضل زمن انتقال.
بالنسبة إلى Jolteon ، لا يمكن توسيع نطاقه إلى أكثر من 20 مدققًا ، وحتى إذا تم تشغيله على Quorum Store ، فإنه يمكن فقط تحقيق نصف إنتاجية Bullshark / Shoal ، مما يزيل عنق زجاجة نشر البيانات.
تظهر النتائج أن Shoal يحسن بشكل كبير زمن انتقال Bullshark. بالنسبة إلى Jolteon ، من المهم ملاحظة أنه على الرغم من أننا قمنا بقياس زمن الوصول الإجماعي فقط. نظرًا لأن Jolteon لا يمكن تشغيله محليًا أعلى DAG ، فإنه يتطلب زمن انتقال إضافي لفصل انتشار البيانات ، وهو ما لم نقيسه. لذلك ، في ظل الحمل العالي ، يجب أن يتطابق Shoal مع زمن انتقال Jolteon من طرف إلى طرف.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-2ccc6874f4-dd1a6f-62a40f)
الشكل 7: الإنتاجية والكمون دون فشل ، يدعم Shoal PL و Shaol LR خطوط الأنابيب وسمعة القائد فقط ، على التوالي.
يوضح الشكل 8 أدناه حالة فشل مع 50 مدققًا ، حيث تعمل آلية سمعة القائد بشكل كبير على تحسين زمن الانتقال عن طريق تقليل احتمال فشل مدقق مصدق يتم انتخابه كقائد. لاحظ أنه مع وجود 16 إخفاقًا من أصل 50 ، كان زمن انتقال Shoal أقل بنسبة 65٪ من Baseline Bullshark.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-729e379b05-dd1a6f-62a40f)
شاهد النسخة الأصلية
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
شرح إطار 4D Shoal: كيفية تقليل زمن انتقال Bullshark على Aptos؟
الأصل: Aptos Labs
تجميع: Aptos Global
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-a5fdeca023-dd1a6f-62a40f)
ملخص
لقد حلت مختبرات Aptos مشكلتين مهمتين مفتوحتين في DAG BFT ، مما قلل بشكل كبير من زمن الوصول ، ولأول مرة ألغيت الحاجة إلى التوقف المؤقت في البروتوكولات العملية الحتمية. بشكل عام ، يعمل هذا على تحسين زمن انتقال Bullshark بنسبة 40٪ في حالة عدم الفشل و 80٪ في حالة الخطأ.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal (على سبيل المثال ، DAG-Rider و Tusk و Bullshark) من خلال خطوط الأنابيب وسمعة القائد. يقلل Pipelining من زمن انتقال طلب DAG من خلال تقديم مرساة في كل جولة ، كما تعمل سمعة القائد على تحسين زمن الوصول من خلال ضمان ارتباط المراسي بأسرع المدققين. بالإضافة إلى ذلك ، تمكّن سمعة القائد Shoal من الاستفادة من بنية DAG غير المتزامنة للقضاء على المهلات في جميع السيناريوهات. يسمح هذا لـ Shoal بتوفير خاصية أطلقنا عليها اسم Universal Response ، والتي تحتوي على الاستجابة المثلى المطلوبة عادةً.
أسلوبنا بسيط للغاية ، فهو يتضمن تشغيل مثيلات متعددة من البروتوكول الأساسي بالتتابع واحدة تلو الأخرى. لذلك ، عند إنشاء مثيل مع 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. لسوء الحظ ، يأتي هيكل DAG الذي يدعم الإنتاجية العالية لشركة Bullshark مع عقوبة زمن انتقال بنسبة 50 ٪ مقارنةً بـ Jolteon.
في هذا المنشور ، نصف كيف حقق Shoal انخفاضًا كبيرًا في زمن انتقال Bullshark.
خلفية DAG-BFT
لنبدأ بفهم الخلفية ذات الصلة لهذه المقالة. للحصول على وصف مفصل لـ Narwhal و Bullshark ، يرجى الرجوع إلى DAG يلتقي بوظيفة BFT.
يرتبط كل رأس في Narwhal DAG برقم دائري. للدخول إلى الجولة r ، يجب على المدقق أولاً الحصول على رؤوس nf التي تنتمي إلى الجولة r-1. يمكن لكل مدقق بث رأس واحد لكل جولة ، ويشير كل رأس إلى رؤوس nf على الأقل في الجولة السابقة. نظرًا لعدم تزامن الشبكة ، قد يلاحظ المدققون المختلفون طرق عرض محلية مختلفة لـ DAG في أي وقت. فيما يلي توضيح لعرض جزئي محتمل:
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-931319a954-dd1a6f-62a40f)
الشكل 1: يتم تمييز التاريخ السببي للرؤوس التي تم تحديدها بواسطة عقدة التحقق من صحة الجولة 2 باللون الأخضر
الخاصية الرئيسية لـ DAGs ليست الغموض: اثنان من المدققين لهما نفس التاريخ السببي تمامًا لـ v إذا كان لديهم نفس الرأس v في وجهة نظرهم المحلية لـ DAG.
من أجل الكاملة
من الممكن الاتفاق على الترتيب الإجمالي لجميع الرؤوس في DAG دون الحاجة إلى اتصال إضافي. تحقيقا لهذه الغاية ، يفسر المدققون في DAG-Rider و Tusk و Bullshark هيكل DAG على أنه بروتوكول إجماع ، حيث تمثل الرؤوس المقترحات وتمثل الحواف الأصوات.
على الرغم من اختلاف منطق تقاطع المجموعة في بنية DAG ، إلا أن جميع بروتوكولات الإجماع الحالية القائمة على Narwhal لها الهيكل التالي:
المراسي المحددة مسبقًا ، سيكون هناك قائد محدد مسبقًا كل عدة جولات (على سبيل المثال ، جولتان في Bullshark) ، وتسمى رؤوس الزعيم المراسي ؛
طلب المراسي ، يقرر المدقق بشكل مستقل ولكن بشكل حاسم المراسي التي يجب طلبها وأي المراسي يجب تخطيها ؛
ترتيب التواريخ السببية ، حيث يقوم المدققون بمعالجة قائمة المراسي المرتبة واحدة تلو الأخرى ، ولكل نقطة ارتساء ، قم بفرز جميع الرؤوس غير المرتبة سابقًا في تاريخها السببي من خلال بعض القواعد الحتمية.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-51897602ab-dd1a6f-62a40f)
الشكل 2: رسم توضيحي لعرض جزئي محتمل لـ DAG في بروتوكول Bullshark. في هذا المثال ، يتم فرز المراسي الحمراء والصفراء ، بينما يتم تخطي الأخضر (ليس في DAG). لذلك ، لطلب DAG ، يقوم المدققون بترتيب التواريخ السببية للمراسي الحمراء أولاً بشكل قاطع ، تليها المراسي الصفراء.
المفتاح لتحقيق الأمان هو التأكد من أنه في الخطوة (2) أعلاه ، يقوم جميع المدققين الصادقين بإنشاء قائمة مرتبة من نقاط الارتساء بحيث تشترك جميع القوائم في نفس البادئة. في Shoal ، نقدم الملاحظات التالية لجميع البروتوكولات المذكورة أعلاه:
** يتفق جميع المدققين على المرساة الأولى المطلوبة. **
بولشارك الكمون
يعتمد وقت استجابة Bullshark على عدد الجولات بين المراسي المطلوبة في DAG. في حين أن الإصدار المتزامن جزئياً الأكثر فائدة من Bullshark لديه زمن انتقال أفضل من الإصدار غير المتزامن ، إلا أنه بعيد عن المستوى الأمثل.
المشكلة 1: متوسط زمن انتقال الكتلة. في Bullshark ، كل جولة زوجية لها مرساة ، ويتم تفسير رؤوس كل جولة فردية على أنها أصوات. عادةً ما يستغرق الأمر جولتين من DAG لطلب المراسي ، ومع ذلك ، فإن الرؤوس في التاريخ السببي للمرساة تستغرق عدة جولات أخرى لانتظار طلب المرساة. في الحالة الشائعة ، تتطلب الرؤوس في الجولات الفردية ثلاث جولات ، بينما تتطلب الرؤوس غير المرساة في الجولات الزوجية أربع جولات (انظر الشكل 3).
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-94f64a51cc-dd1a6f-62a40f)
الشكل 3: في الحالة الشائعة ، يجب فرز المراسي في الجولة i + 1 لجولتين. يتم فرز القمم في الجولة الأولى في وقت واحد ، لذلك يكون وقت الاستجابة ثلاث جولات. ومع ذلك ، يجب أن تنتظر الرؤوس في الجولة i + 1 حتى يتم فرز المرساة التالية (التي في الجولة i + 3) ، وبالتالي فإن تأخير الفرز هو أربع جولات.
المشكلة 2: زمن انتقال حالة الفشل ، ينطبق تحليل زمن الوصول أعلاه على حالة عدم الفشل ، من ناحية أخرى ، إذا فشل قائد الجولة في بث المراسي بسرعة كافية ، فلا يمكن طلب المراسي (وبالتالي يتم تخطيها) ، لذلك الكل يجب أن تنتظر القمم التي لم يتم فرزها في الجولات السابقة حتى يتم فرز المرساة التالية. يمكن أن يقلل هذا بشكل كبير من أداء شبكة مكررة جغرافيًا ، خاصة وأن Bullshark يستخدم المهلات في انتظار القائد.
إطار Shoal Framework
يحل Shoal كل من مشكلات زمن الوصول هذه عن طريق تعزيز Bullshark (أو أي بروتوكول BFT آخر قائم على Narwhal) عن طريق الأنابيب ، مما يسمح بمرساة في كل جولة ، وتقليل زمن انتقال جميع الرؤوس غير المرساة في DAG إلى ثلاث جولات. يقدم Shoal أيضًا آلية سمعة القائد الصفري في DAG ، والتي تحيز الاختيار لصالح القادة السريعين.
تحدي
في سياق بروتوكولات DAG ، يعتبر خط الأنابيب وسمعة القائد مشاكل صعبة للأسباب التالية:
محاولات خطوط الأنابيب السابقة لتعديل منطق Bullshark الأساسي ، لكن هذا يبدو مستحيلاً بطبيعته
سمعة القائد ، التي تم تقديمها في DiemBFT وتم إضفاء الطابع الرسمي عليها في Carousel ، هي فكرة الاختيار الديناميكي لقادة المستقبل (المراسي في Bullshark) بناءً على الأداء السابق للمدققين. في حين أن الخلاف حول هوية القائد لا ينتهك الأمان في هذه البروتوكولات ، إلا أنه في Bullshark يمكن أن يؤدي إلى ترتيب مختلف تمامًا ، والذي يصل إلى قلب السؤال ، وهو أن الاختيار الديناميكي والحتمي لمثبتات العجلات هو المفتاح لحل الإجماع المطلوب ، بينما يحتاج المدققون إلى الاتفاق على سجل مرتب لاختيار نقاط ارتساء مستقبلية.
كدليل على صعوبة المشكلة ، نلاحظ أن تنفيذ Bullshark ، بما في ذلك التنفيذ الحالي في الإنتاج ، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه ، اتضح أن الحلول ، كما يقال ، تكمن وراء البساطة.
في Shoal ، نعتمد على القدرة على إجراء الحسابات المحلية على DAG وتنفيذ القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. مع البصيرة الأساسية التي يتفق عليها جميع المدققين على المرساة الأولى المطلوبة ، تقوم أنابيب Shoal بتكوينها من خلال إنشاء عدة مثيلات Bullshark في تسلسل بحيث (1) المرساة الأولى المطلوبة هي نقطة التبديل للحالات ، و (2) التاريخ السببي لـ تستخدم المراسي لحساب سمعة القائد.
خطوط الأنابيب
على غرار Bullshark ، يوافق المدققون مسبقًا على المراسي المحتملة ، أي أن هناك تعيينًا معروفًا F: R -> V جولات رسم الخرائط للقادة. يدير Shoal مثيلات Bullshark واحدة تلو الأخرى بحيث يتم تحديد المرساة مسبقًا بواسطة الخريطة F. يطلب كل مثيل مرساة ، والتي تؤدي إلى التبديل إلى المثيل التالي.
في البداية ، أطلق Shoal أول مثيل لـ Bullshark في الجولة الأولى من DAG وتشغيله حتى يتم تحديد المرساة الأولى المطلوبة ، على سبيل المثال في الجولة r. يتفق جميع المدققين على هذا المرساة. لذلك ، يمكن لجميع المدققين الموافقة بشكل حاسم على إعادة تفسير DAG بدءًا من الجولة r + 1. يبدأ Shoal في إصدار نسخة جديدة من Bullshark في الجولة r + 1.
في أفضل سيناريو ، يسمح هذا لـ Shoal بطلب مرساة في كل جولة. يتم فرز المراسي للجولة الأولى حسب الحالة الأولى. بعد ذلك ، يبدأ Shoal مثيلًا جديدًا في الجولة الثانية ، والذي يحتوي في حد ذاته على مرساة مرتبة حسب المثال ، ثم يقوم مثيل جديد آخر بطلب المراسي في الجولة الثالثة ، وتستمر العملية. يرجى الاطلاع على الرسم التوضيحي أدناه:
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-815c54edb-dd1a6f-62a40f)
الشكل 4: الرؤوس المقابلة للقادة التي يحددها F مميزة بتاج. يفسر المثال الأول لـ Bullshark أولاً DAG مع المراسي في الجولات 1 و 3 و 5. يحدد Bullshark المراسي في الجولة 1 (في علامة اختيار خضراء mark) هو أول ما يتم فرزه في المقام الأول. (لاحظ أنه في الحالة العامة ، يمكن تخطي هذا المرساة ، في حين يتم فرز بعض المراسي الأخرى أولاً.) ثم يتم تجاهل بقية المثيل الأول ، ويبدأ مثيل جديد لـ Bullshark من الجولة 2 ، ويتم تمييز نقاط الربط في الجولتين 2 و 4.
سمعة القائد
زيادة زمن الوصول عند تخطي المراسي أثناء فرز Bullshark. في هذه الحالة ، تكون تقنية Pipelining عاجزة لأنه لا يمكن بدء مثيل جديد حتى يطلب المثيل السابق مرساة. يضمن Shoal أنه من غير المرجح أن يتم انتخاب القائد المناسب في المستقبل للتعامل مع مرساة مفقودة باستخدام آلية سمعة لتعيين درجة لكل مدقق بناءً على تاريخ نشاطه الأخير. سيتم منح المدقق الذي يستجيب ويشارك في البروتوكول درجة عالية ، وإلا فسيتم تعيين درجة منخفضة للمدقق لأنه قد يتعطل أو يكون بطيئًا أو ضارًا.
الفكرة هي إعادة حساب التعيين المحدد مسبقًا F بشكل حاسم من الجولات إلى القادة في كل تحديث للنتيجة ، مع تفضيل القادة ذوي الدرجات الأعلى. لكي يتفق المدققون على التعيين الجديد ، يجب أن يتفقوا على الدرجة وبالتالي التاريخ المستخدم لاشتقاق النتيجة.
في Shoal ، يمكن الجمع بين سمعة خطوط الأنابيب والقيادة بشكل طبيعي لأن كلاهما يستخدم نفس الأسلوب الأساسي لإعادة تفسير DAG بعد الاتفاق على المرساة الأولى المطلوبة.
في الواقع ، الاختلاف الوحيد هو أنه بعد فرز المراسي في الجولة r ، يحتاج المدقق فقط إلى حساب تعيين جديد F 'من الجولة r + 1 استنادًا إلى التاريخ السببي للمراسي المرتبة في الجولة r. بعد ذلك ، يقوم المدقق بتنفيذ مثيل جديد من Bullshark بدءًا من الجولة r + 1 باستخدام وظيفة تحديد المرساة المحدثة F '. انظر الصورة أدناه:
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-c1d8088bd3-dd1a6f-62a40f)
الشكل 5. القمم المقابلة للقادة المحددة بواسطة F مميزة بتيجان شفافة. يطلب المثيل الأول من Bullshark مرساة في الجولة 1 ، مميزة بعلامة اختيار خضراء ، ثم يحسب تعيينًا جديدًا F 'استنادًا إلى المعلومات الموجودة في التاريخ السببي للمرساة. يتم تمييز القادة الذين تحددهم F 'بتيجان ملونة.
لا مزيد من المهلات
تلعب المهلات دورًا حاسمًا في جميع عمليات تنفيذ BFT الحتمية المتزامنة جزئيًا والقائمة على القائد. ومع ذلك ، فإن التعقيد الذي يقدمونه يزيد من مقدار الحالة الداخلية التي يجب إدارتها ومراقبتها ، مما يعقد عملية التصحيح ويتطلب المزيد من تقنيات الملاحظة.
يمكن أن تضيف المهلات أيضًا بشكل كبير إلى زمن الانتقال ، نظرًا لأنه من المهم تهيئتها بشكل مناسب ، وعادة ما تحتاج إلى تعديل ديناميكي ، لأنها تعتمد بشكل كبير على البيئة (الشبكة). يدفع البروتوكول للقائد الخاطئ عقوبة تأخير المهلة الكاملة قبل الانتقال إلى القائد التالي. لذلك ، لا يمكن أن يكون إعداد المهلة متحفظًا للغاية ، ولكن إذا كانت المهلة قصيرة جدًا ، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال ، لاحظنا أنه في ظل العبء الكبير ، كان القادة في Jolteon / Hotstuff مرهقين وانتهت المهلات قبل أن يتمكنوا من دفع التقدم.
لسوء الحظ ، تتطلب البروتوكولات القائمة على القائد مثل Hotstuff و Jolteon بطبيعتها مهلات للتأكد من أن البروتوكول يمكن أن يحرز تقدمًا في كل مرة يفشل فيها القائد. بدون مهلة ، حتى القائد المحطم يمكنه إيقاف البروتوكول إلى الأبد. نظرًا لعدم القدرة على التمييز بين القائد الخاطئ والقائد البطيء أثناء عدم التزامن ، يمكن أن تتسبب المهلات في أن يرى المدققون التغييرات لجميع القادة دون التوافق في الآراء.
في Bullshark ، تُستخدم المهلات في إنشاء DAG للتأكد من أن القائد الصادق أثناء المزامنة يضيف المراسي إلى DAG بسرعة كافية ليتم طلبها.
نلاحظ أن بناء DAG يوفر "ساعة" لتقدير سرعة الشبكة. في حالة عدم وجود توقف مؤقت ، تستمر الجولات في التقدم طالما استمر المدققون الصادقون في إضافة رؤوس إلى DAG. في حين أن Bullshark قد لا يكون قادرًا على الفرز بسرعة الشبكة (بسبب القادة المشكلون) ، لا يزال DAG ينمو بسرعة الشبكة على الرغم من بعض مشاكل القائد أو أن الشبكة غير متزامنة. في النهاية ، عندما يبث القائد الخالي من العيوب المراسي بسرعة كافية ، فسيتم ترتيب التاريخ السببي الكامل للمراسي.
في تقييمنا ، قارنا Bullshark مع وبدون مهلة في الحالات التالية:
القائد السريع ، وهذا يعني على الأقل أسرع من المدققين الآخرين. في هذه الحالة ، توفر كلتا الطريقتين نفس وقت الاستجابة لأنه يتم ترتيب نقاط الارتساء وعدم استخدام المهلات.
القائد الخاطئ ، في هذه الحالة ، يوفر Bullshark بدون توقف زمن انتقال أفضل حيث سيتخطى المدققون على الفور نقاط ارتكازه ، بينما ينتظر المدققون مع التوقفات وصولهم قبل استمرار توقع.
القائد البطيء ، هذه هي الحالة الوحيدة التي يتمتع فيها Bullshark بأداء مهلة أفضل. هذا لأنه ، بدون توقف مؤقت ، قد يتم تخطي المرساة لأن القائد لا يمكنه بثها بالسرعة الكافية ، بينما مع التوقف ، سينتظر المدققون المرساة.
في Shoal ، يسير تجنب المهلات وسمعة القيادة جنبًا إلى جنب. يؤدي الانتظار المتكرر لقائد بطيء إلى زيادة وقت الاستجابة ، كما أن آلية سمعة القائد تمنع المدققين البطيئين من انتخابهم كقادة. بهذه الطريقة ، يستخدم النظام عقد التحقق السريع للتشغيل بسرعة الشبكة في جميع سيناريوهات العالم الحقيقي.
لاحظ أن نتيجة استحالة FLP تُظهر أنه لا يوجد بروتوكول إجماع حتمي يمكنه تجنب المهلات. لا يمكن لـ Shoal التحايل على هذه النتيجة لأن هناك جدولًا نظريًا للأحداث العدائية التي من شأنها أن تمنع جميع المراسلين من الأوامر. بدلاً من ذلك ، يعود Shoal إلى المهلة بعد عدد قابل للتكوين من عمليات تخطي الارتساء المتتالية. من الناحية العملية ، من غير المرجح أن يحدث هذا.
الاستجابة العامة
روجت ورقة Hotstuff لمفهوم الاستجابة المتفائلة ، والتي ، على الرغم من عدم تعريفها رسميًا ، تعني بشكل حدسي أن البروتوكول يمكن أن يعمل بسرعة الشبكة في ظل ظروف جيدة بما في ذلك القائد السريع والشبكة المتزامنة.
يوفر Shoal خاصية أفضل ، والتي نسميها الاستجابة العالمية. على وجه التحديد ، على عكس Hotstuff ، يستمر Shoal في العمل بسرعة الشبكة حتى إذا فشل القائد في عدد قابل للتكوين من الجولات المتتالية أو الدورات غير المتزامنة التي تمر من خلالها الشبكة. شاهد مقارنة أكثر تفصيلاً في الجدول أدناه.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-b87c1b94cb-dd1a6f-62a40f)
لاحظ أن الاستجابة العامة توفر ضمانات تقدم أفضل بشكل صارم خلال الفترات غير المتزامنة وعندما يفشل القائد. أثناء المزامنة مع قائد بطيء ، لا يمكن مقارنة هذه الخصائص لأنها تعتمد على مدى بطء القائد. ومع ذلك ، نظرًا لسمعة القائد ، نادرًا ما يظهر القادة بطيئون الحركة في Shoal.
يقيم
قمنا بتنفيذ Bullshark و Shoal على رأس متجر Quorum لتطبيق Narwhal. يمكن العثور على مقارنة مفصلة بين Shoal و Bullshark و Jolteon في قسم التقييم في ورقة Shoal ، حيث نقدم بعض النقاط البارزة.
أولاً ، لإثبات قوة بناء DAG غير المتزامن ، نقارن Bullshark مع وبدون توقفات. تفترض ورقة Bullshark الكاملة وجود شبكة غير متزامنة ، ولكنها توفر وضع مسار سريع ، مما يتطلب توقفًا مؤقتًا أثناء جميع الجولات. نسمي هذا الإصدار Vanilla Bullshark. نلاحظ أنه بالنسبة للإصدارات الافتراضية للشبكة المستقلة المتزامنة جزئيًا ، لا يلزم التوقف مؤقتًا في جولات التصويت. نسمي هذا الإصدار Vanilla Bullshark بدون مهلة التصويت بدون مهلة التصويت ، Baseline Bullshark هو الإصدار بدون أي مهلة.
يقارن الرسم البياني أدناه تأثير المهلات على زمن انتقال Bullshark مع الإخفاقات وبدونها. على ما يبدو ، فإن Baseline Bullshark (بدون مهلة) تؤدي بشكل أفضل في حالة الفشل. مع عدم وجود إخفاقات ، فإن Baseline Bullshark قابلة للمقارنة مع Vanilla Bullshark بدون تعليق التصويت. هذا لأنه ، كما ذكرنا سابقًا ، بدون آلية سمعة القائد ، قد يكون للمهلة ميزة في المواقف التي يكون فيها القائد جيدًا ولكن بطيئًا.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-d49abda989-dd1a6f-62a40f)
الشكل 6: تأثير المهلات على زمن انتقال Bullshark بدون إخفاقات (يسار) ومع حالات فشل (يمين) ، مع وجود 50 مدققًا في حالة الفشل
بعد ذلك ، نقوم بإنشاء مثيل Shoal باستخدام Baseline Bullshark (بدون مهلة) ونوضح تحسينات زمن الوصول لخط الأنابيب وآلية سمعة القائد مع وبدون فشل ، ولتحقيق الاكتمال ، نقارنها أيضًا بـ Jolteon مع وبدون فشل مقارنة.
يوضح الشكل 7 أدناه حالة عدم الفشل ، وبينما يمكن أن يقلل كل من خطوط الأنابيب وسمعة القائد من زمن الانتقال بشكل فردي ، فإن الجمع بينهما يؤدي إلى أفضل زمن انتقال.
بالنسبة إلى Jolteon ، لا يمكن توسيع نطاقه إلى أكثر من 20 مدققًا ، وحتى إذا تم تشغيله على Quorum Store ، فإنه يمكن فقط تحقيق نصف إنتاجية Bullshark / Shoal ، مما يزيل عنق زجاجة نشر البيانات.
تظهر النتائج أن Shoal يحسن بشكل كبير زمن انتقال Bullshark. بالنسبة إلى Jolteon ، من المهم ملاحظة أنه على الرغم من أننا قمنا بقياس زمن الوصول الإجماعي فقط. نظرًا لأن Jolteon لا يمكن تشغيله محليًا أعلى DAG ، فإنه يتطلب زمن انتقال إضافي لفصل انتشار البيانات ، وهو ما لم نقيسه. لذلك ، في ظل الحمل العالي ، يجب أن يتطابق Shoal مع زمن انتقال Jolteon من طرف إلى طرف.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-2ccc6874f4-dd1a6f-62a40f)
الشكل 7: الإنتاجية والكمون دون فشل ، يدعم Shoal PL و Shaol LR خطوط الأنابيب وسمعة القائد فقط ، على التوالي.
يوضح الشكل 8 أدناه حالة فشل مع 50 مدققًا ، حيث تعمل آلية سمعة القائد بشكل كبير على تحسين زمن الانتقال عن طريق تقليل احتمال فشل مدقق مصدق يتم انتخابه كقائد. لاحظ أنه مع وجود 16 إخفاقًا من أصل 50 ، كان زمن انتقال Shoal أقل بنسبة 65٪ من Baseline Bullshark.
! [شرح إطار عمل Shoal بالتفصيل: كيفية تقليل زمن انتقال Bullshark على Aptos؟ ] (https://img.gateio.im/social/moments-69a80767fe-729e379b05-dd1a6f-62a40f)