إطار Shoal: كيف يمكن تقليل تأخير Bullshark على Aptos؟
نظرة عامة
حل مختبرات Aptos مشكلتين مفتوحتين مهمتين في DAG BFT، مما قلل بشكل كبير من التأخير، وأزال لأول مرة الحاجة إلى التوقف في البروتوكولات العملية المحددة. بشكل عام، تم تحسين تأخير Bullshark بنسبة 40٪ في حالة عدم وجود أعطال، و 80٪ في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal ( مثل DAG-Rider و Tusk و Bullshark ) من خلال معالجة خط الأنابيب وآلية سمعة القائد. يقلل خط الأنابيب من تأخير ترتيب DAG من خلال تقديم نقطة مرجعية في كل جولة ، بينما تعمل سمعة القائد على تحسين مشكلة التأخير من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد التحقق. بالإضافة إلى ذلك، تتيح سمعة القائد لـ Shoal الاستفادة من بناء DAG غير المتزامن للتخلص من مهلات في جميع السيناريوهات. وهذا يسمح لـ Shoal بتقديم خاصية نسميها الاستجابة العالمية، التي تحتوي على الاستجابة المتفائلة اللازمة عادة.
تكون هذه التقنية بسيطة للغاية، حيث تتضمن تشغيل عدة حالات من البروتوكول الأساسي واحداً تلو الآخر. لذلك، عندما يتم تجسيدها باستخدام Bullshark، نحصل على مجموعة من "القرش" التي تشارك في سباق التتابع.
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا يهتمون بتقليل تعقيد الاتصالات. ومع ذلك، لم تؤد هذه الطريقة إلى تحسين كبير في معدل النقل. على سبيل المثال، وصلت النسخة المبكرة من 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٪.
تستعرض هذه المقالة كيفية تقليل Shoal لتأخير Bullshark بشكل كبير.
كل رأس في Narwhal DAG مرتبط بدورة معينة. لدخول الدورة r، يجب على المدقق أولاً الحصول على n-f من الرؤوس التي تنتمي إلى الدورة r-1. يمكن لكل مدقق في كل دورة بث رأس واحد، ويجب أن يشير كل رأس إلى n-f من الرؤوس في الدورة السابقة على الأقل. بسبب عدم التزامن في الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي لحظة.
خاصية رئيسية من DAG هي عدم الغموض: إذا كان لدى عقدتي التحقق اثنين من نفس القمة v في رؤيتهما المحلية لـ DAG، فإنهما تمتلكان نفس تاريخ v السببي تمامًا.
يمكن تحقيق توافق على الترتيب الكلي لجميع القمم في DAG دون تكاليف اتصالات إضافية. لهذا، يقوم المدققون في DAG-Rider وTusk وBullshark بتفسير هيكل DAG كبروتوكول إجماع، حيث تمثل القمم المقترحات، وتمثل الحواف التصويت.
على الرغم من أن منطق التقاطع الجماعي في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع الحالية المعتمدة على Narwhal تتمتع بالهيكل التالي:
نقطة الإرساء المحددة: كل بضع جولات سيكون هناك قائد محدد مسبقًا، ويطلق على قمة القائد اسم نقطة الإرساء؛
نقاط الربط: يقرر المدققون بشكل مستقل ولكن حاسم أي نقاط ربط يجب ترتيبها وأيها يجب تخطيها؛
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسخة المرتبة واحدة تلو الأخرى، وترتيب جميع الرؤوس غير المرتبة السابقة في التاريخ السببي لكل نقطة مرسخة.
المفتاح لضمان الأمان هو التأكد من أن قائمة النقاط الثابتة المرتبة التي أنشأها جميع عقد التحقق النزيهة تشترك في نفس البادئة في الخطوة (2). في Shoal ، نقدم الملاحظات التالية حول جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
تأخير Bullshark
تعتمد تأخيرات 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 مثيلًا جديدًا في الجولة الثانية، وله نقطة مرساة خاصة به، يتم ترتيبها بواسطة هذا المثيل، ثم يتم طلب نقطة مرساة أخرى في الجولة الثالثة، وتستمر العملية.
أثناء تخطي النقاط المرجعية خلال فرز Bullshark، ستزداد التأخيرات. في هذه الحالة، لا يمكن لتقنية المعالجة المتزامنة أن تفعل شيئًا، لأنه لا يمكن بدء مثيل جديد قبل طلب النقطة المرجعية السابقة. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة، مما يجعل من غير المحتمل أن يتم اختيار القادة المعنيين في المستقبل لمعالجة النقاط المرجعية المفقودة. ستحصل العقد التي تستجيب وتشارك في البروتوكول على درجات عالية، وإلا، فسيتم تخصيص درجات منخفضة لعقد التحقق، لأنها قد تتعطل، أو تكون بطيئة، أو تقوم بأعمال ضارة.
مفهومه هو إعادة حساب خريطة محددة مسبقًا F من الجولات إلى القادة بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع التركيز على القادة ذوي النقاط الأعلى. لكي يتوصل الموثقون إلى توافق بشأن الخريطة الجديدة، يجب عليهم التوصل إلى توافق حول النقاط، وبالتالي التوصل إلى توافق بشأن التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن دمج معالجة خطوط الأنابيب وسمعة القادة بشكل طبيعي، لأن كلاهما يستخدم نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق في الآراء حول أول نقطة ربط مرتبة.
في الحقيقة، الفرق الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المدققون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، تبدأ عقد التحقق في تنفيذ مثيل جديد من Bullshark باستخدام دالة اختيار النقاط المرجعية المحدثة F' ابتداءً من الجولة r+1.
تلعب مهلة الوقت دورًا حاسمًا في جميع تطبيقات BFT المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي يقدمونه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح ويحتاج إلى مزيد من تقنيات المراقبة.
سيؤدي تجاوز الوقت أيضًا إلى زيادة التأخير بشكل ملحوظ، لأن تكوينها بشكل مناسب أمر مهم للغاية، وغالبًا ما يتطلب تعديلات ديناميكية، لأنه يعتمد بشكل كبير على بيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستدفع البروتوكول عقوبة التأخير الكامل للقائد المعطل. لذلك، يجب ألا تكون إعدادات المهلة متحفظة للغاية، ولكن إذا كانت مدة المهلة قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالي، كان القادة في Jolteon/Hotstuff مثقلون، وكانوا يتجاوزون الوقت قبل دفعهم للتقدم.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 21
أعجبني
21
9
مشاركة
تعليق
0/400
RektCoaster
· 08-03 07:00
وقت الإستجابة انخفضت بهذا القدر؟ ثور啊
شاهد النسخة الأصليةرد0
Degen4Breakfast
· 08-02 20:25
لا بأس، هل يحتاج المرساة إلى كل هذه المتاعب؟
شاهد النسخة الأصليةرد0
SatoshiLegend
· 08-02 17:14
على الرغم من أن تحسين DAG جيد، إلا أنه يجب ألا نغير نوايانا الأساسية لنحقق النجاح. تحت الكود المصدر، لا توجد أسرار.
إطار Shoal يعزز بشكل ملحوظ أداء Bullshark على سلسلة Aptos مع تقليل التأخير بنسبة تصل إلى 80%
إطار Shoal: كيف يمكن تقليل تأخير Bullshark على Aptos؟
نظرة عامة
حل مختبرات Aptos مشكلتين مفتوحتين مهمتين في DAG BFT، مما قلل بشكل كبير من التأخير، وأزال لأول مرة الحاجة إلى التوقف في البروتوكولات العملية المحددة. بشكل عام، تم تحسين تأخير Bullshark بنسبة 40٪ في حالة عدم وجود أعطال، و 80٪ في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal ( مثل DAG-Rider و Tusk و Bullshark ) من خلال معالجة خط الأنابيب وآلية سمعة القائد. يقلل خط الأنابيب من تأخير ترتيب DAG من خلال تقديم نقطة مرجعية في كل جولة ، بينما تعمل سمعة القائد على تحسين مشكلة التأخير من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد التحقق. بالإضافة إلى ذلك، تتيح سمعة القائد لـ Shoal الاستفادة من بناء DAG غير المتزامن للتخلص من مهلات في جميع السيناريوهات. وهذا يسمح لـ Shoal بتقديم خاصية نسميها الاستجابة العالمية، التي تحتوي على الاستجابة المتفائلة اللازمة عادة.
تكون هذه التقنية بسيطة للغاية، حيث تتضمن تشغيل عدة حالات من البروتوكول الأساسي واحداً تلو الآخر. لذلك، عندما يتم تجسيدها باستخدام Bullshark، نحصل على مجموعة من "القرش" التي تشارك في سباق التتابع.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
الدافع
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا يهتمون بتقليل تعقيد الاتصالات. ومع ذلك، لم تؤد هذه الطريقة إلى تحسين كبير في معدل النقل. على سبيل المثال، وصلت النسخة المبكرة من 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٪.
تستعرض هذه المقالة كيفية تقليل Shoal لتأخير Bullshark بشكل كبير.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
خلفية 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 تتمتع بالهيكل التالي:
نقطة الإرساء المحددة: كل بضع جولات سيكون هناك قائد محدد مسبقًا، ويطلق على قمة القائد اسم نقطة الإرساء؛
نقاط الربط: يقرر المدققون بشكل مستقل ولكن حاسم أي نقاط ربط يجب ترتيبها وأيها يجب تخطيها؛
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسخة المرتبة واحدة تلو الأخرى، وترتيب جميع الرؤوس غير المرتبة السابقة في التاريخ السببي لكل نقطة مرسخة.
المفتاح لضمان الأمان هو التأكد من أن قائمة النقاط الثابتة المرتبة التي أنشأها جميع عقد التحقق النزيهة تشترك في نفس البادئة في الخطوة (2). في Shoal ، نقدم الملاحظات التالية حول جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
تأخير Bullshark
تعتمد تأخيرات Bullshark على عدد الدورات بين نقاط الربط المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية من Bullshark تتمتع بتأخير أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن كونها مثالية.
السؤال 1: تأخير الكتلة المتوسط. في Bullshark، يحتوي كل جولة زوجية على نقطة ربط، بينما يتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، يلزم دورتان من DAG لترتيب نقاط الربط، ومع ذلك، تحتاج القمم في التاريخ السببي لنقاط الربط إلى المزيد من الجولات في انتظار ترتيب نقاط الربط. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرتبطة في الجولات الزوجية إلى أربع جولات.
السؤال 2: تأخير حالات الفشل. ينطبق تحليل التأخير أعلاه على الحالة الخالية من الأعطال، ومن ناحية أخرى، إذا فشل قائد الجولة في بث النقاط المرجعية بسرعة كافية، فلا يمكن ترتيب النقاط المرجعية ( وبالتالي يتم تخطيها )، لذا يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. سيؤدي ذلك إلى تقليل أداء شبكة النسخ الجغرافي بشكل كبير، خاصة لأن Bullshark تستخدم المهلة للانتظار حتى قائد الجولة.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
إطار Shoal
عززت Shoal من خلال معالجة خط الأنابيب بروتوكول Bullshark( أو أي بروتوكول BFT آخر يعتمد على Narwhal)، مما يسمح بوجود نقطة ربط في كل جولة، ويقلل من تأخير جميع الرؤوس غير المرتبطة في DAG إلى ثلاث جولات. كما أدخلت Shoal آلية سمعة القادة بدون تكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
تحدي
في سياق بروتوكول DAG، تعتبر معالجة التدفقات والتقدير القيادي من القضايا الصعبة، للأسباب التالية:
كانت المحاولات السابقة لمعالجة خط التجميع لتعديل منطق Bullshark الأساسي، لكن يبدو أن ذلك من الناحية الجوهرية غير ممكن.
تم تقديم سمعة القائد في DiemBFT وتوثيقها رسميًا في Carousel، بناءً على الأداء السابق للمدققين لاختيار القادة المستقبليين بشكل ديناميكي. فكرة عن مرساة في Bullshark. على الرغم من أن وجود خلافات في هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار المرساة الديناميكية والمحددة هو أمر ضروري لحل الإجماع، ويجب على المدققين التوصل إلى توافق بشأن التاريخ المرتب لاختيار المرساة المستقبلية.
كتقرير حول صعوبة المشكلة، نلاحظ أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
الاتفاقية
على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول مخبأة في البساطة.
في Shoal، نعتمد على القدرة على إجراء حسابات محلية على DAG، ونحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على الرؤية الأساسية للنقطة المرصودة الأولى، يقوم Shoal بترتيب ومعالجة عدة أمثلة من Bullshark بشكل متسلسل، مما يجعل ( النقطة المرصودة الأولى نقطة التحويل للأمثلة، وكذلك ) التاريخ السببي للنقاط المستخدمة في حساب سمعة القائد.
معالجة خط التجميع
V يربط الجولات بالقائد. تقوم Shoal بتشغيل مثيل Bullshark واحدًا تلو الآخر، بحيث يتم تحديد الربط مسبقًا من خلال التحويل F لكل مثيل. كل مثيل يطلب ربطًا، مما يؤدي إلى الانتقال إلى المثيل التالي.
في البداية، أطلق Shoal أول مثال لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى تم تحديد أول نقطة ربط مرتبة، مثل في الجولة r. وافق جميع المدققين على هذه النقطة الربط. لذلك، يمكن لجميع المدققين أن يتفقوا بشكل مؤكد على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal فقط مثالًا جديدًا لـ Bullshark في الجولة r+1.
في أفضل الحالات، يتيح ذلك لـ Shoal طلب مرساة في كل جولة. يتم ترتيب نقاط المراساة في الجولة الأولى حسب أول مثيل. بعد ذلك، يبدأ Shoal مثيلًا جديدًا في الجولة الثانية، وله نقطة مرساة خاصة به، يتم ترتيبها بواسطة هذا المثيل، ثم يتم طلب نقطة مرساة أخرى في الجولة الثالثة، وتستمر العملية.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
سمعة القادة
أثناء تخطي النقاط المرجعية خلال فرز Bullshark، ستزداد التأخيرات. في هذه الحالة، لا يمكن لتقنية المعالجة المتزامنة أن تفعل شيئًا، لأنه لا يمكن بدء مثيل جديد قبل طلب النقطة المرجعية السابقة. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة، مما يجعل من غير المحتمل أن يتم اختيار القادة المعنيين في المستقبل لمعالجة النقاط المرجعية المفقودة. ستحصل العقد التي تستجيب وتشارك في البروتوكول على درجات عالية، وإلا، فسيتم تخصيص درجات منخفضة لعقد التحقق، لأنها قد تتعطل، أو تكون بطيئة، أو تقوم بأعمال ضارة.
مفهومه هو إعادة حساب خريطة محددة مسبقًا F من الجولات إلى القادة بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع التركيز على القادة ذوي النقاط الأعلى. لكي يتوصل الموثقون إلى توافق بشأن الخريطة الجديدة، يجب عليهم التوصل إلى توافق حول النقاط، وبالتالي التوصل إلى توافق بشأن التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن دمج معالجة خطوط الأنابيب وسمعة القادة بشكل طبيعي، لأن كلاهما يستخدم نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق في الآراء حول أول نقطة ربط مرتبة.
في الحقيقة، الفرق الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المدققون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، تبدأ عقد التحقق في تنفيذ مثيل جديد من Bullshark باستخدام دالة اختيار النقاط المرجعية المحدثة F' ابتداءً من الجولة r+1.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
لا مزيد من المهلات
تلعب مهلة الوقت دورًا حاسمًا في جميع تطبيقات BFT المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي يقدمونه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح ويحتاج إلى مزيد من تقنيات المراقبة.
سيؤدي تجاوز الوقت أيضًا إلى زيادة التأخير بشكل ملحوظ، لأن تكوينها بشكل مناسب أمر مهم للغاية، وغالبًا ما يتطلب تعديلات ديناميكية، لأنه يعتمد بشكل كبير على بيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستدفع البروتوكول عقوبة التأخير الكامل للقائد المعطل. لذلك، يجب ألا تكون إعدادات المهلة متحفظة للغاية، ولكن إذا كانت مدة المهلة قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالي، كان القادة في Jolteon/Hotstuff مثقلون، وكانوا يتجاوزون الوقت قبل دفعهم للتقدم.