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