حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل التأخير بشكل ملحوظ، وألغت لأول مرة الحاجة إلى التوقف في بروتوكول حقيقي محدد. بشكل عام، تم تحسين تأخير Bullshark بنسبة 40% في حالة عدم وجود أخطاء، وبنسبة 80% في حالة وجود أخطاء.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal ( مثل DAG-Rider و Tusk و Bullshark ) من خلال خط الأنابيب وسمعة القادة. يقوم خط الأنابيب بتقليل تأخير ترتيب DAG من خلال إدخال نقطة ربط في كل جولة ، بينما تعمل سمعة القادة على تحسين التأخير بشكل أكبر من خلال ضمان ارتباط النقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك ، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات الزمنية. وهذا يسمح لـ Shoal بتقديم خاصية نسميها الاستجابة العامة ، والتي تحتوي على الاستجابة التفاؤلية المطلوبة عادة.
تقنيًا ، يقوم Shoal بتشغيل عدة مثيلات من البروتوكول الأساسي بترتيب. لذا عند استخدام مثيل Bullshark ، نحصل على مجموعة من "أسماك القرش" التي تتسابق في سباق التتابع.
عند السعي نحو أداء عالٍ لشبكة البلوك تشين، كان الناس دائمًا يهتمون بتقليل تعقيد الاتصالات. ومع ذلك، لم تؤدِّ هذه الطريقة إلى تحسين كبير في معدل النقل. على سبيل المثال، النسخة المبكرة من Diem التي تم تنفيذ Hotstuff فيها حققت فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
الاختراق الأخير جاء من إدراك أن انتشار البيانات هو العقبة الرئيسية المستندة إلى بروتوكول القادة، ويمكن الاستفادة من التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن منطق الإجماع، مقترحًا هيكلًا حيث تقوم جميع المراجعين بنشر البيانات في نفس الوقت، بينما تقوم مكونات الإجماع بترتيب كمية صغيرة من البيانات الوصفية. أبلغت ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
في السابق قدمنا Quorum Store، وهو تطبيق Narwhal، الذي يفصل بين نشر البيانات والتوافق، وكيفية استخدامه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول يعتمد على القيادة، يجمع بين المسار السريع الخطي لتندرمينت وتغيير العرض بأسلوب PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول التوافق القائم على القيادة لا يمكنه بوضوح الاستفادة الكاملة من إمكانات إنتاج Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark، بروتوكول توافق بلا تكلفة اتصالات، فوق Narwhal DAG. للأسف، بالمقارنة مع Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يأتي بتكلفة تأخير تبلغ 50%.
تتناول هذه المقالة كيفية تقليل تأخير Bullshark بشكل كبير بواسطة Shoal.
خلفية 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 يعتمد على عدد الدورات بين النقاط المعلقة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية من Bullshark لديها تأخير أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 1: متوسط تأخير الكتلة. في Bullshark، يوجد نقطة ربط في كل جولة زوجية، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى جولتين من DAG لترتيب النقاط المربوطة، ومع ذلك، تحتاج القمم في التاريخ السببي لنقاط الربط إلى المزيد من الجولات لانتظار ترتيب النقطة المربوطة. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرتبطة في الجولات الزوجية إلى أربع جولات.
السؤال 2: تأخير حالة العطل. تنطبق تحليلات التأخير المذكورة أعلاه على الحالات التي لا توجد فيها أعطال، ومن ناحية أخرى، إذا فشل قائد الجولة في بث النقطة المرجعية بسرعة كافية، فلن يكون من الممكن ترتيب النقطة المرجعية ( وبالتالي يتم تخطيها )، لذا يجب أن تنتظر جميع الرؤوس غير المرتبة في الجولات السابقة حتى يتم ترتيب النقطة المرجعية التالية. سيؤدي ذلك بشكل كبير إلى تقليل أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark يستخدم الانتظار المؤقت لقائد الجولة.
حلت Shoal هاتين المشكلتين في التأخير، من خلال تعزيز Bullshark( أو أي بروتوكول BFT آخر يعتمد على Narwhal) عبر خطوط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، وتقليل تأخير جميع الرؤوس غير المرتبطة في DAG إلى ثلاث جولات. كما أدخلت Shoal آلية سمعة القائد بدون تكلفة في DAG، مما يجعل الاختيار يتجه نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر قضايا خط الأنابيب وسمعة القائد من المشاكل الصعبة، للأسباب التالية:
حاول خط الإنتاج السابق تعديل المنطق الأساسي لبول شارك، لكن يبدو أن هذا أمر مستحيل جوهريًا.
يتم تقديم سمعة القادة في 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-859e732e16c3eee0e2c93422474debc2.webp(
سمعة القادة
أثناء تخطي نقاط التثبيت خلال ترتيب Bullshark، سيزداد التأخير. في هذه الحالة، لن تكون تقنية خط الأنابيب فعالة، لأنه لا يمكن بدء مثيل جديد قبل ترتيب نقطة التثبيت في المثيل السابق. يضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة تحقق، مما يجعل من غير المحتمل اختيار القائد المقابل لمعالجة نقاط التثبيت المفقودة في المستقبل. ستحصل الموثقون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا، ستخصص درجات منخفضة لعقدة التحقق، لأنها قد تتعطل أو تكون بطيئة أو تسيء التصرف.
فكرته هي إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع الانحياز نحو القادة ذوي النقاط الأعلى. لكي يتوصل المدققون إلى توافق في الآراء بشأن الخريطة الجديدة، يجب عليهم التوصل إلى توافق بشأن النقاط، وبالتالي الوصول إلى توافق بشأن التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن أن تتكامل خطوط الإنتاج وسمعة القيادة بشكل طبيعي، لأن كلاهما يستخدم نفس التكنولوجيا الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المدققون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقد التحقق في تنفيذ مثيل جديد من Bullshark باستخدام دالة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
تلعب مهلة الوقت دورًا حيويًا في جميع تنفيذات BFT القائمة على الزعيم. ومع ذلك، فإن التعقيد الذي يتم إدخاله يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب تقنيات مراقبة أكثر.
يؤدي انتهاء المهلة أيضًا إلى زيادة التأخير بشكل كبير، لأن تكوينها بشكل مناسب أمر مهم للغاية وغالبًا ما يتطلب تعديلًا ديناميكيًا، حيث يعتمد بشكل كبير على بيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، يقوم البروتوكول بدفع عقوبة تأخير انتهاء المهلة بالكامل للقائد الذي فشل. لذلك، لا يمكن أن تكون إعدادات انتهاء المهلة متحفظة جدًا، ولكن إذا كانت مدة انتهاء المهلة قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالي، كان القادة في Jolteon/Hotstuff مثقلين، وقد انتهت المهلة قبل أن يتمكنوا من دفع التقدم.
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.
تسجيلات الإعجاب 16
أعجبني
16
4
مشاركة
تعليق
0/400
DeFiChef
· منذ 38 د
هذه الزيادة في الأداء بنسبة 40% رائعة!
شاهد النسخة الأصليةرد0
TokenEconomist
· 07-02 09:36
في الواقع، تعتبر بنية الشول تحفة نظرية الألعاب. فكر فيها مثل توازن ناش حيث يقوم المدققون بتحسين السمعة = f(السرعة، الاعتمادية)...
شاهد النسخة الأصليةرد0
WhaleSurfer
· 07-02 09:33
ثور ثور ثور突破上限啦
شاهد النسخة الأصليةرد0
TokenSleuth
· 07-02 09:24
Aptos هذه تحسين الثور آه وقت الإستجابة انخفض كثيراً
إطار Shoal أسقط بشكل كبير تأخير Bullshark على Aptos، وقد عززت آلية التدفق والسمعة الأداء بشكل ملحوظ.
إطار Shoal: تحسين تأخير Bullshark على Aptos
حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل التأخير بشكل ملحوظ، وألغت لأول مرة الحاجة إلى التوقف في بروتوكول حقيقي محدد. بشكل عام، تم تحسين تأخير Bullshark بنسبة 40% في حالة عدم وجود أخطاء، وبنسبة 80% في حالة وجود أخطاء.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal ( مثل DAG-Rider و Tusk و Bullshark ) من خلال خط الأنابيب وسمعة القادة. يقوم خط الأنابيب بتقليل تأخير ترتيب DAG من خلال إدخال نقطة ربط في كل جولة ، بينما تعمل سمعة القادة على تحسين التأخير بشكل أكبر من خلال ضمان ارتباط النقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك ، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات الزمنية. وهذا يسمح لـ Shoal بتقديم خاصية نسميها الاستجابة العامة ، والتي تحتوي على الاستجابة التفاؤلية المطلوبة عادة.
تقنيًا ، يقوم Shoal بتشغيل عدة مثيلات من البروتوكول الأساسي بترتيب. لذا عند استخدام مثيل Bullshark ، نحصل على مجموعة من "أسماك القرش" التي تتسابق في سباق التتابع.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
الدافع
عند السعي نحو أداء عالٍ لشبكة البلوك تشين، كان الناس دائمًا يهتمون بتقليل تعقيد الاتصالات. ومع ذلك، لم تؤدِّ هذه الطريقة إلى تحسين كبير في معدل النقل. على سبيل المثال، النسخة المبكرة من Diem التي تم تنفيذ Hotstuff فيها حققت فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
الاختراق الأخير جاء من إدراك أن انتشار البيانات هو العقبة الرئيسية المستندة إلى بروتوكول القادة، ويمكن الاستفادة من التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن منطق الإجماع، مقترحًا هيكلًا حيث تقوم جميع المراجعين بنشر البيانات في نفس الوقت، بينما تقوم مكونات الإجماع بترتيب كمية صغيرة من البيانات الوصفية. أبلغت ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
في السابق قدمنا Quorum Store، وهو تطبيق Narwhal، الذي يفصل بين نشر البيانات والتوافق، وكيفية استخدامه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول يعتمد على القيادة، يجمع بين المسار السريع الخطي لتندرمينت وتغيير العرض بأسلوب PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول التوافق القائم على القيادة لا يمكنه بوضوح الاستفادة الكاملة من إمكانات إنتاج Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark، بروتوكول توافق بلا تكلفة اتصالات، فوق Narwhal DAG. للأسف، بالمقارنة مع Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يأتي بتكلفة تأخير تبلغ 50%.
تتناول هذه المقالة كيفية تقليل تأخير Bullshark بشكل كبير بواسطة Shoal.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة معينة. للدخول في الجولة r، يجب على المدقق أولاً الحصول على n-f من الرؤوس التي تنتمي إلى الجولة r-1. يمكن لكل مدقق في كل جولة بث رأس واحد، ويجب أن يشير كل رأس على الأقل إلى n-f من الرؤوس من الجولة السابقة. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي وقت.
خاصية رئيسية لـ DAG هي عدم الغموض: إذا كان لدى اثنين من عقد التحقق نفس القمة v في عرضهم المحلي لـ DAG، فإنهما يمتلكان نفس التاريخ السببي لـ v.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
المقدمة
يمكن تحقيق توافق على الترتيب الإجمالي لجميع القمم في DAG دون أي تكلفة اتصال إضافية. لهذا الغرض، يفسر المصادقون في DAG-Rider وTusk وBullshark هيكل DAG كبروتوكول إجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف الأصوات.
على الرغم من أن منطق تقاطع المجموعات في بنية DAG مختلف، إلا أن جميع بروتوكولات الإجماع الحالية القائمة على Narwhal تحتوي على الهيكل التالي:
النقطة المرجعية: كل عدة جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد مسبقًا، ويطلق على قمة القائد النقطة المرجعية؛
نقاط الربط المرتبة: يحدد المدققون بشكل مستقل ولكن حاسم أي نقاط ربط يجب ترتيبها وأيها يجب تخطيها؛
تاريخ السبب والنتيجة المرتب: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، ومن خلال قواعد حتمية، يقومون بترتيب جميع الرؤوس غير المرتبة السابقة في تاريخ السبب والنتيجة لكل نقطة ربط.
المفتاح لضمان الأمان هو التأكد من أن قائمة النقاط المرسلة المرتبة التي أنشأتها جميع العقد الموثوقة في الخطوة (2) تشترك في نفس البادئة. في Shoal، نقدم الملاحظات التالية حول جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
Bullshark تأخير
تأخير Bullshark يعتمد على عدد الدورات بين النقاط المعلقة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية من Bullshark لديها تأخير أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 1: متوسط تأخير الكتلة. في Bullshark، يوجد نقطة ربط في كل جولة زوجية، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى جولتين من DAG لترتيب النقاط المربوطة، ومع ذلك، تحتاج القمم في التاريخ السببي لنقاط الربط إلى المزيد من الجولات لانتظار ترتيب النقطة المربوطة. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرتبطة في الجولات الزوجية إلى أربع جولات.
السؤال 2: تأخير حالة العطل. تنطبق تحليلات التأخير المذكورة أعلاه على الحالات التي لا توجد فيها أعطال، ومن ناحية أخرى، إذا فشل قائد الجولة في بث النقطة المرجعية بسرعة كافية، فلن يكون من الممكن ترتيب النقطة المرجعية ( وبالتالي يتم تخطيها )، لذا يجب أن تنتظر جميع الرؤوس غير المرتبة في الجولات السابقة حتى يتم ترتيب النقطة المرجعية التالية. سيؤدي ذلك بشكل كبير إلى تقليل أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark يستخدم الانتظار المؤقت لقائد الجولة.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
إطار Shoal
حلت Shoal هاتين المشكلتين في التأخير، من خلال تعزيز Bullshark( أو أي بروتوكول BFT آخر يعتمد على Narwhal) عبر خطوط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، وتقليل تأخير جميع الرؤوس غير المرتبطة في DAG إلى ثلاث جولات. كما أدخلت Shoal آلية سمعة القائد بدون تكلفة في DAG، مما يجعل الاختيار يتجه نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر قضايا خط الأنابيب وسمعة القائد من المشاكل الصعبة، للأسباب التالية:
حاول خط الإنتاج السابق تعديل المنطق الأساسي لبول شارك، لكن يبدو أن هذا أمر مستحيل جوهريًا.
يتم تقديم سمعة القادة في DiemBFT وتوثيقها رسميًا في Carousel، وهي فكرة يتم من خلالها اختيار القادة المستقبليين ديناميكيًا بناءً على أداء المدققين في الماضي، والمرتبطة بالمرساة في Bullshark (. على الرغم من أن وجود تباين في هوية القادة لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي إلى ترتيبات مختلفة تمامًا، مما يبرز جوهر المشكلة وهو أن اختيار المراسي بشكل ديناميكي وحتمي أمر ضروري لحل الإجماع، ويتعين على المدققين التوصل إلى توافق حول التاريخ المرتب لاختيار المراسي المستقبلية.
كدليل على صعوبة المشكلة، نلاحظ أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
! [万字详解Shoal框架:如何减少Aptos上的Bullshark延迟? ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
الاتفاقية
على الرغم من التحديات المذكورة أعلاه، إلا أن الحل موجود في البساطة.
في 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-859e732e16c3eee0e2c93422474debc2.webp(
سمعة القادة
أثناء تخطي نقاط التثبيت خلال ترتيب Bullshark، سيزداد التأخير. في هذه الحالة، لن تكون تقنية خط الأنابيب فعالة، لأنه لا يمكن بدء مثيل جديد قبل ترتيب نقطة التثبيت في المثيل السابق. يضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة تحقق، مما يجعل من غير المحتمل اختيار القائد المقابل لمعالجة نقاط التثبيت المفقودة في المستقبل. ستحصل الموثقون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا، ستخصص درجات منخفضة لعقدة التحقق، لأنها قد تتعطل أو تكون بطيئة أو تسيء التصرف.
فكرته هي إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع الانحياز نحو القادة ذوي النقاط الأعلى. لكي يتوصل المدققون إلى توافق في الآراء بشأن الخريطة الجديدة، يجب عليهم التوصل إلى توافق بشأن النقاط، وبالتالي الوصول إلى توافق بشأن التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن أن تتكامل خطوط الإنتاج وسمعة القيادة بشكل طبيعي، لأن كلاهما يستخدم نفس التكنولوجيا الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المدققون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقد التحقق في تنفيذ مثيل جديد من Bullshark باستخدام دالة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
! [万字详解Shoal框架:如何减少Aptos上的Bullshark延迟? ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
لا مزيد من المهلة
تلعب مهلة الوقت دورًا حيويًا في جميع تنفيذات BFT القائمة على الزعيم. ومع ذلك، فإن التعقيد الذي يتم إدخاله يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب تقنيات مراقبة أكثر.
يؤدي انتهاء المهلة أيضًا إلى زيادة التأخير بشكل كبير، لأن تكوينها بشكل مناسب أمر مهم للغاية وغالبًا ما يتطلب تعديلًا ديناميكيًا، حيث يعتمد بشكل كبير على بيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، يقوم البروتوكول بدفع عقوبة تأخير انتهاء المهلة بالكامل للقائد الذي فشل. لذلك، لا يمكن أن تكون إعدادات انتهاء المهلة متحفظة جدًا، ولكن إذا كانت مدة انتهاء المهلة قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالي، كان القادة في Jolteon/Hotstuff مثقلين، وقد انتهت المهلة قبل أن يتمكنوا من دفع التقدم.
للأسف ، بناءً على القيادة