حلت مختبرات Aptos مشكلتين مفتوحتين هامتين في DAG BFT، مما قلل بشكل كبير من التأخير، وألغت لأول مرة الحاجة إلى التوقف في البروتوكول العملي الحتمي. بشكل عام، تم تحسين تأخير Bullshark بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
تعزز إطار عمل Shoal بروتوكول الإجماع القائم على Narwhal ( من خلال آلية خط الأنابيب وسمعة القادة مثل DAG-Rider وTusk وBullshark ). يقدم خط الأنابيب نقطة ربط جديدة في كل جولة لتقليل تأخير ترتيب DAG، وتضمن سمعة القادة ربط النقاط الأسرع مع أسرع عقد التحقق، مما يحسن التأخير بشكل أكبر. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي تتضمن الوقت المستغرق، مما يحقق خاصية الاستجابة العامة.
تقنية Shoal بسيطة للغاية، حيث يتم تشغيل عدة نسخ من البروتوكول الأساسي بالترتيب. عند تجسيد Bullshark، يبدو الأمر كما لو كانت مجموعة من "الأسماك" التي تجري سباق تتابع.
عند السعي لتحقيق أداء عالٍ لشبكات البلوكشين، كان الناس دائمًا مهتمين بتقليل تعقيد الاتصالات، لكن ذلك لم يؤد إلى تحسين كبير في معدل النقل. على سبيل المثال، فإن Hotstuff الذي تم تنفيذه في Diem في مراحله المبكرة حقق فقط 3500 TPS، وهو ما يقل بكثير عن الهدف البالغ 100k+ TPS.
في الآونة الأخيرة، جاءت الاختراقات نتيجة للإدراك بأن انتشار البيانات هو العقبة الرئيسية التي تعتمد على بروتوكولات القيادة، ويمكن أن تستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات ومنطق الإجماع الأساسي، حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة من البيانات الوصفية. أبلغت ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ Narwhal، الذي يفصل بين نشر البيانات والتوافق، ويستخدم لتوسيع بروتوكول التوافق الحالي Jolteon. يجمع Jolteon بين المسار السريع الخطي لـ Tendermint وتغيير الرؤية على طراز PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول التوافق القائم على القيادة لا يمكنه الاستفادة بشكل كامل من إمكانيات الإنتاجية لـ Narwhal.
لذلك، قررت Aptos نشر Bullshark، وهو بروتوكول توافق بدون تكلفة اتصال على قمة Narwhal DAG. للأسف، فإن بنية 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 لها الهيكل التالي:
نقطة الربط المحددة مسبقًا: كل عدة جولات يوجد قائد محدد مسبقًا، وتسمى قمته نقطة الربط.
نقاط الترتيب: يقوم المدققون بشكل مستقل ولكن حاسم بتحديد أي النقاط لترتيبها وأيها لتجاوزها.
تاريخ السببية المرتب: يقوم المُحققون بمعالجة قائمة النقاط المرسومة المرتبة واحدة تلو الأخرى، لترتيب الرؤوس غير المرتبة السابقة في تاريخ السببية لكل نقطة مرسومة.
الشرط الأساسي لتحقيق الأمان هو التأكد من أن قائمة نقاط الربط المرتبة التي أنشأتها جميع العقد الصحيحة تشترك في نفس البادئة في الخطوة (2). في Shoal، لاحظنا:
اتفق جميع المدققين على أول نقطة ربط مرتبة.
Bullshark التأخير
يعتمد تأخير Bullshark على عدد الدورات بين النقاط المرجعية المرتبة في DAG. تأخير بعض إصدارات المزامنة أفضل من الإصدارات غير المتزامنة، ولكنه لا يزال ليس الأمثل.
السؤال 1: متوسط تأخير الكتلة. في Bullshark، يوجد نقطة مرجعية في كل جولة زوجية، وتُعتبر قمة الجولة الفردية بمثابة تصويت. في الحالات الشائعة، يحتاج الأمر إلى جولتين من DAG لترتيب النقاط المرجعية، ولكن القمم في التاريخ السببي للنقاط المرجعية تحتاج إلى المزيد من الجولات في انتظار ترتيب النقاط المرجعية. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، وتحتاج القمم غير المرجعية في الجولات الزوجية إلى أربع جولات.
السؤال 2: تأخير حالة العطل. إذا فشل قائد الجولة في بث النقطة المرجعية في الوقت المناسب، فلن يتم ترتيبها. يتم تخطي (، ويجب أن تنتظر جميع النقاط غير المرتبة من الجولات السابقة حتى يتم ترتيب النقطة المرجعية التالية. هذا يقلل بشكل كبير من أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark يستخدم انتظار المهلة للقائد.
يعزز Shoal Bullshark) أو أي بروتوكول BFT قائم على Narwhal( من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، مما يقلل من تأخيرات جميع النقاط غير المرتبطة في DAG إلى ثلاث جولات. كما يقدم Shoal آلية سمعة القائد بدون تكلفة في DAG، مما يفضل اختيار القادة السريعين.
) تحدي
تعتبر خط الأنابيب وسمعة القائد في بروتوكول DAG من القضايا الصعبة، وذلك للأسباب التالية:
كانت المحاولات السابقة لتعديل منطق Bullshark الأساسي من خلال خط التجميع، لكن يبدو أنه من المستحيل جوهريًا.
تم إدخال سمعة القادة في DiemBFT وتثبيتها رسميًا في Carousel، حيث يتم اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المدققين السابق. ### مرساة في Bullshark (. على الرغم من أن انقسام هوية القادة لا ينتهك أمان هذه البروتوكولات، إلا أنه قد يؤدي إلى ترتيب مختلف تمامًا في Bullshark، مما يبرز جوهر المشكلة: الاختيار الديناميكي والحتمي للمرساة الدوارة ضروري لحل الإجماع، ويحتاج المدققون إلى التوصل إلى توافق حول التاريخ المرتب لاختيار المرساة المستقبلية.
كدليل على صعوبة المشكلة، يتضمن تنفيذ Bullshark ) أن البيئة الإنتاجية الحالية ( لا تدعم هذه الميزات.
) اتفاقية
على الرغم من التحديات المذكورة أعلاه، إلا أن الحل يكمن في البساطة.
تعتمد Shoal على القدرة على تنفيذ الحسابات المحلية على DAG، مما يتيح حفظ وإعادة تفسير المعلومات من الجولات السابقة. استنادًا إلى توافق جميع المدققين على أول نقطة ربط مرتبة، تقوم Shoal بترتيب دمج عدة حالات من Bullshark لمعالجة خطية، مما يجعل ### أول نقطة ربط مرتبة هي نقطة التحول للحالات، و( التاريخ السببي لنقطة الربط تُستخدم لحساب سمعة القائد.
) خط الإنتاج
يشبه Bullshark، يتفق المدققون مسبقًا على نقاط الربط المحتملة، وهناك خريطة معروفة F:R→V تقوم بربط الدور بالقائد. تعمل Shoal بترتيب تنفيذ حالات Bullshark، حيث يتم تحديد نقطة الربط لكل حالة مسبقًا بواسطة الخريطة F. يقوم كل حالة بترتيب نقطة ربط، مما يؤدي إلى التحويل إلى الحالة التالية.
في البداية، بدأ Shoal أول مثال لـ Bullshark في الجولة الأولى من DAG، واستمر حتى تم تحديد أول نقطة ربط مرتبة ( كما في الجولة r ). اتفق جميع المدققين على هذه النقطة الثابتة، وبالتالي يمكن الاتفاق بشكل مؤكد على إعادة تفسير DAG من الجولة r + 1. أطلق Shoal مثالاً جديداً لـ Bullshark في الجولة r + 1.
في أفضل الحالات، يتيح ذلك لشول ترتيب مرساة واحدة في كل جولة. يتم ترتيب نقطة المرساة الأولى بواسطة أول مثيل. ثم، يبدأ شول مثيلًا جديدًا في الجولة الثانية، ولديه نقطة مرساة خاصة به ويتم ترتيبها بواسطة هذا المثيل، ثم مثيل جديد آخر يرتب نقطة المرساة في الجولة الثالثة، وهكذا تستمر العملية.
عندما يتجاوز ترتيب Bullshark النقطة المرجعية، تزداد التأخيرات. في هذه الحالة، لا تستطيع خطوط الأنابيب المساعدة، لأنه لا يمكن بدء مثيل جديد قبل نقطة المرجعية لترتيب المثيل السابق. يقوم Shoal بتخصيص نقاط لكل عقدة تحقق من خلال آلية سمعة، مما يضمن أنه بناءً على تاريخ أنشطتها الأخيرة، من غير المرجح اختيار القادة المناسبين في المستقبل لمعالجة النقاط المرجعية المفقودة. يحصل المصدقون الذين يستجيبون ويشاركون في البروتوكول على نقاط عالية، أما الباقون فيتم تخصيص نقاط منخفضة ( قد تنهار أو تكون بطيئة أو خبيثة ).
المفهوم هو إعادة حساب الخريطة المحددة مسبقًا F من الجولات إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، حيث يميل ذلك نحو القادة ذوي النقاط العالية. لكي يتفق المدققون على الخريطة الجديدة، يجب عليهم التوصل إلى توافق بشأن النقاط، وبالتالي التوصل إلى توافق بشأن التاريخ المستخدم لاشتقاق النقاط.
في Shoal، تتكامل خطوط الإنتاج وسمعة القادة بشكل طبيعي، لأنها تستخدم نفس التقنية الأساسية: إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
الفرق الوحيد هو أنه بعد نقطة الربط في الجولة r، يقوم المدققون بناءً على التاريخ السببي لنقاط الربط المرتبة في الجولة r، بحساب التعيين الجديد F' بدءًا من الجولة r+1. ثم تبدأ عقد التحقق في تنفيذ مثال جديد لبولشارك باستخدام وظيفة اختيار النقاط المحدثة F' بدءًا من الجولة r+1.
إن تجاوز الوقت أمر بالغ الأهمية في جميع تطبيقات BFT القابلة للتحديد المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي تم إدخاله يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
تزيد المهلات بشكل ملحوظ من التأخير، لأنه من المهم تكوينها بشكل صحيح، وغالبًا ما تحتاج إلى تعديل ديناميكي، وتعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى الزعيم التالي، يعاقب البروتوكول الزعيم المتعطل بمدة التأخير الكاملة للمهلة. لذلك، لا ينبغي أن تكون إعدادات المهلة متحفظة جدًا، ولكن إذا كانت قصيرة جدًا، قد يتخطى البروتوكول الزعماء الجيدين. على سبيل المثال، لاحظنا أنه في ظل الحمل العالي، كان الزعماء في Jolteon/Hotstuff مثقلين، وقد انتهت المهلة قبل دفع التقدم.
للأسف، تتطلب بروتوكولات القادة مثل Hotstuff و Jolteon###، المستندة إلى (، بشكل أساسي وجود مهلة لضمان تقدم البروتوكول في كل مرة يحدث فيها فشل للقائد. بدون مهلة، حتى القادة المعطلين قد يتوقفون عن البروتوكول إلى الأبد. نظرًا لعدم إمكانية التمييز بين القادة المعطلين والبطيئين خلال الفترات غير المتزامنة، قد تؤدي المهلة إلى قيام عقد التحقق بمراجعة جميع القادة دون وجود نشاط توافق.
في Bullshark، يتم استخدام المهلة لبناء DAG، لضمان أن القادة الصادقين أثناء التزامن يضيفون النقاط المرجعية إلى DAG بسرعة كافية لترتيبها.
لقد لاحظنا أن بناء DAG يقدم "ساعة" لتقدير سرعة الشبكة. دون توقف، طالما أن n-f من المدققين الشرفاء يستمرون في إضافة القمم إلى DAG، ستستمر الجولات في التقدم. على الرغم من أن Bullshark قد لا يكون قادرًا على ترتيب ) بسرعة الشبكة بسبب مشاكل القيادة (، إلا أن DAG لا يزال ينمو بسرعة الشبكة، على الرغم من وجود بعض القادة الذين لديهم مشاكل أو الشبكة غير متزامنة. في النهاية، عندما يقوم القادة الخاليين من الأخطاء ببث النقاط المرجعية بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل للنقاط المرجعية.
جاري التقييم، قمنا بمقارنة Bullshark في الحالات التالية لمعرفة ما إذا كان هناك أي وقت مستقطع:
القادة السريعين، على الأقل أسرع من غيرهم من المدققين. في هذه الحالة، توفر الطريقتان نفس التأخير، لأن الرابطة مرتبة ولا تستخدم الوقت المستغرق.
القادة الخاطئون، في هذه الحالة، يوفر Bullshark بدون توقف تأخيرًا أفضل، حيث سيتخطى عقد التحقق على الفور نقاط الربط الخاصة به، بينما ستنتظر عقد التحقق مع التوقف حتى انتهاء صلاحيتها قبل المتابعة.
القادة البطيئون، هذه هي الحالة الوحيدة التي يكون فيها أداء Bullshark المتفوق أفضل. لأنه في حالة عدم وجود توقيف، قد يتم تخطي النقاط المرجعية لأن القائد لا يستطيع بثها بسرعة كافية، وعندما يكون هناك توقيف، سينتظر المدققون النقاط المرجعية.
في Shoal، تجنب تجاوز الوقت مرتبط ارتباطًا وثيقًا بسمعة القائد. الانتظار المتكرر
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
أدخلت Aptos إطار Shoal مما أسقط بشكل كبير تأخير Bullshark وإزالة الحاجة إلى المهلة
تقليل تأخير Bullshark على Aptos: شرح إطار Shoal
حلت مختبرات Aptos مشكلتين مفتوحتين هامتين في DAG BFT، مما قلل بشكل كبير من التأخير، وألغت لأول مرة الحاجة إلى التوقف في البروتوكول العملي الحتمي. بشكل عام، تم تحسين تأخير Bullshark بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
تعزز إطار عمل Shoal بروتوكول الإجماع القائم على Narwhal ( من خلال آلية خط الأنابيب وسمعة القادة مثل DAG-Rider وTusk وBullshark ). يقدم خط الأنابيب نقطة ربط جديدة في كل جولة لتقليل تأخير ترتيب DAG، وتضمن سمعة القادة ربط النقاط الأسرع مع أسرع عقد التحقق، مما يحسن التأخير بشكل أكبر. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي تتضمن الوقت المستغرق، مما يحقق خاصية الاستجابة العامة.
تقنية Shoal بسيطة للغاية، حيث يتم تشغيل عدة نسخ من البروتوكول الأساسي بالترتيب. عند تجسيد Bullshark، يبدو الأمر كما لو كانت مجموعة من "الأسماك" التي تجري سباق تتابع.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكات البلوكشين، كان الناس دائمًا مهتمين بتقليل تعقيد الاتصالات، لكن ذلك لم يؤد إلى تحسين كبير في معدل النقل. على سبيل المثال، فإن Hotstuff الذي تم تنفيذه في Diem في مراحله المبكرة حقق فقط 3500 TPS، وهو ما يقل بكثير عن الهدف البالغ 100k+ TPS.
في الآونة الأخيرة، جاءت الاختراقات نتيجة للإدراك بأن انتشار البيانات هو العقبة الرئيسية التي تعتمد على بروتوكولات القيادة، ويمكن أن تستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات ومنطق الإجماع الأساسي، حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة من البيانات الوصفية. أبلغت ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ Narwhal، الذي يفصل بين نشر البيانات والتوافق، ويستخدم لتوسيع بروتوكول التوافق الحالي Jolteon. يجمع Jolteon بين المسار السريع الخطي لـ Tendermint وتغيير الرؤية على طراز PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول التوافق القائم على القيادة لا يمكنه الاستفادة بشكل كامل من إمكانيات الإنتاجية لـ Narwhal.
لذلك، قررت Aptos نشر Bullshark، وهو بروتوكول توافق بدون تكلفة اتصال على قمة Narwhal DAG. للأسف، فإن بنية 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 لها الهيكل التالي:
نقطة الربط المحددة مسبقًا: كل عدة جولات يوجد قائد محدد مسبقًا، وتسمى قمته نقطة الربط.
نقاط الترتيب: يقوم المدققون بشكل مستقل ولكن حاسم بتحديد أي النقاط لترتيبها وأيها لتجاوزها.
تاريخ السببية المرتب: يقوم المُحققون بمعالجة قائمة النقاط المرسومة المرتبة واحدة تلو الأخرى، لترتيب الرؤوس غير المرتبة السابقة في تاريخ السببية لكل نقطة مرسومة.
الشرط الأساسي لتحقيق الأمان هو التأكد من أن قائمة نقاط الربط المرتبة التي أنشأتها جميع العقد الصحيحة تشترك في نفس البادئة في الخطوة (2). في Shoal، لاحظنا:
اتفق جميع المدققين على أول نقطة ربط مرتبة.
Bullshark التأخير
يعتمد تأخير Bullshark على عدد الدورات بين النقاط المرجعية المرتبة في DAG. تأخير بعض إصدارات المزامنة أفضل من الإصدارات غير المتزامنة، ولكنه لا يزال ليس الأمثل.
السؤال 1: متوسط تأخير الكتلة. في Bullshark، يوجد نقطة مرجعية في كل جولة زوجية، وتُعتبر قمة الجولة الفردية بمثابة تصويت. في الحالات الشائعة، يحتاج الأمر إلى جولتين من DAG لترتيب النقاط المرجعية، ولكن القمم في التاريخ السببي للنقاط المرجعية تحتاج إلى المزيد من الجولات في انتظار ترتيب النقاط المرجعية. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، وتحتاج القمم غير المرجعية في الجولات الزوجية إلى أربع جولات.
السؤال 2: تأخير حالة العطل. إذا فشل قائد الجولة في بث النقطة المرجعية في الوقت المناسب، فلن يتم ترتيبها. يتم تخطي (، ويجب أن تنتظر جميع النقاط غير المرتبة من الجولات السابقة حتى يتم ترتيب النقطة المرجعية التالية. هذا يقلل بشكل كبير من أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark يستخدم انتظار المهلة للقائد.
! [万字详解Shoal框架:如何减少Aptos上的Bullshark延迟? ])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
إطار Shoal
يعزز Shoal Bullshark) أو أي بروتوكول BFT قائم على Narwhal( من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، مما يقلل من تأخيرات جميع النقاط غير المرتبطة في DAG إلى ثلاث جولات. كما يقدم Shoal آلية سمعة القائد بدون تكلفة في DAG، مما يفضل اختيار القادة السريعين.
) تحدي
تعتبر خط الأنابيب وسمعة القائد في بروتوكول DAG من القضايا الصعبة، وذلك للأسباب التالية:
كانت المحاولات السابقة لتعديل منطق Bullshark الأساسي من خلال خط التجميع، لكن يبدو أنه من المستحيل جوهريًا.
تم إدخال سمعة القادة في DiemBFT وتثبيتها رسميًا في Carousel، حيث يتم اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المدققين السابق. ### مرساة في Bullshark (. على الرغم من أن انقسام هوية القادة لا ينتهك أمان هذه البروتوكولات، إلا أنه قد يؤدي إلى ترتيب مختلف تمامًا في Bullshark، مما يبرز جوهر المشكلة: الاختيار الديناميكي والحتمي للمرساة الدوارة ضروري لحل الإجماع، ويحتاج المدققون إلى التوصل إلى توافق حول التاريخ المرتب لاختيار المرساة المستقبلية.
كدليل على صعوبة المشكلة، يتضمن تنفيذ Bullshark ) أن البيئة الإنتاجية الحالية ( لا تدعم هذه الميزات.
) اتفاقية
على الرغم من التحديات المذكورة أعلاه، إلا أن الحل يكمن في البساطة.
تعتمد Shoal على القدرة على تنفيذ الحسابات المحلية على DAG، مما يتيح حفظ وإعادة تفسير المعلومات من الجولات السابقة. استنادًا إلى توافق جميع المدققين على أول نقطة ربط مرتبة، تقوم Shoal بترتيب دمج عدة حالات من Bullshark لمعالجة خطية، مما يجعل ### أول نقطة ربط مرتبة هي نقطة التحول للحالات، و( التاريخ السببي لنقطة الربط تُستخدم لحساب سمعة القائد.
) خط الإنتاج
يشبه Bullshark، يتفق المدققون مسبقًا على نقاط الربط المحتملة، وهناك خريطة معروفة F:R→V تقوم بربط الدور بالقائد. تعمل Shoal بترتيب تنفيذ حالات Bullshark، حيث يتم تحديد نقطة الربط لكل حالة مسبقًا بواسطة الخريطة F. يقوم كل حالة بترتيب نقطة ربط، مما يؤدي إلى التحويل إلى الحالة التالية.
في البداية، بدأ Shoal أول مثال لـ Bullshark في الجولة الأولى من DAG، واستمر حتى تم تحديد أول نقطة ربط مرتبة ( كما في الجولة r ). اتفق جميع المدققين على هذه النقطة الثابتة، وبالتالي يمكن الاتفاق بشكل مؤكد على إعادة تفسير DAG من الجولة r + 1. أطلق Shoal مثالاً جديداً لـ Bullshark في الجولة r + 1.
في أفضل الحالات، يتيح ذلك لشول ترتيب مرساة واحدة في كل جولة. يتم ترتيب نقطة المرساة الأولى بواسطة أول مثيل. ثم، يبدأ شول مثيلًا جديدًا في الجولة الثانية، ولديه نقطة مرساة خاصة به ويتم ترتيبها بواسطة هذا المثيل، ثم مثيل جديد آخر يرتب نقطة المرساة في الجولة الثالثة، وهكذا تستمر العملية.
! [万字详解Shoal框架:如何减少Aptos上的Bullshark延迟? ]###https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
) سمعة القادة
عندما يتجاوز ترتيب Bullshark النقطة المرجعية، تزداد التأخيرات. في هذه الحالة، لا تستطيع خطوط الأنابيب المساعدة، لأنه لا يمكن بدء مثيل جديد قبل نقطة المرجعية لترتيب المثيل السابق. يقوم Shoal بتخصيص نقاط لكل عقدة تحقق من خلال آلية سمعة، مما يضمن أنه بناءً على تاريخ أنشطتها الأخيرة، من غير المرجح اختيار القادة المناسبين في المستقبل لمعالجة النقاط المرجعية المفقودة. يحصل المصدقون الذين يستجيبون ويشاركون في البروتوكول على نقاط عالية، أما الباقون فيتم تخصيص نقاط منخفضة ( قد تنهار أو تكون بطيئة أو خبيثة ).
المفهوم هو إعادة حساب الخريطة المحددة مسبقًا F من الجولات إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، حيث يميل ذلك نحو القادة ذوي النقاط العالية. لكي يتفق المدققون على الخريطة الجديدة، يجب عليهم التوصل إلى توافق بشأن النقاط، وبالتالي التوصل إلى توافق بشأن التاريخ المستخدم لاشتقاق النقاط.
في Shoal، تتكامل خطوط الإنتاج وسمعة القادة بشكل طبيعي، لأنها تستخدم نفس التقنية الأساسية: إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
الفرق الوحيد هو أنه بعد نقطة الربط في الجولة r، يقوم المدققون بناءً على التاريخ السببي لنقاط الربط المرتبة في الجولة r، بحساب التعيين الجديد F' بدءًا من الجولة r+1. ثم تبدأ عقد التحقق في تنفيذ مثال جديد لبولشارك باستخدام وظيفة اختيار النقاط المحدثة F' بدءًا من الجولة r+1.
! [万字详解Shoal框架:如何减少Aptos上的Bullshark延迟? ]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) لا حاجة لمزيد من الوقت
إن تجاوز الوقت أمر بالغ الأهمية في جميع تطبيقات BFT القابلة للتحديد المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي تم إدخاله يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
تزيد المهلات بشكل ملحوظ من التأخير، لأنه من المهم تكوينها بشكل صحيح، وغالبًا ما تحتاج إلى تعديل ديناميكي، وتعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى الزعيم التالي، يعاقب البروتوكول الزعيم المتعطل بمدة التأخير الكاملة للمهلة. لذلك، لا ينبغي أن تكون إعدادات المهلة متحفظة جدًا، ولكن إذا كانت قصيرة جدًا، قد يتخطى البروتوكول الزعماء الجيدين. على سبيل المثال، لاحظنا أنه في ظل الحمل العالي، كان الزعماء في Jolteon/Hotstuff مثقلين، وقد انتهت المهلة قبل دفع التقدم.
للأسف، تتطلب بروتوكولات القادة مثل Hotstuff و Jolteon###، المستندة إلى (، بشكل أساسي وجود مهلة لضمان تقدم البروتوكول في كل مرة يحدث فيها فشل للقائد. بدون مهلة، حتى القادة المعطلين قد يتوقفون عن البروتوكول إلى الأبد. نظرًا لعدم إمكانية التمييز بين القادة المعطلين والبطيئين خلال الفترات غير المتزامنة، قد تؤدي المهلة إلى قيام عقد التحقق بمراجعة جميع القادة دون وجود نشاط توافق.
في Bullshark، يتم استخدام المهلة لبناء DAG، لضمان أن القادة الصادقين أثناء التزامن يضيفون النقاط المرجعية إلى DAG بسرعة كافية لترتيبها.
لقد لاحظنا أن بناء DAG يقدم "ساعة" لتقدير سرعة الشبكة. دون توقف، طالما أن n-f من المدققين الشرفاء يستمرون في إضافة القمم إلى DAG، ستستمر الجولات في التقدم. على الرغم من أن Bullshark قد لا يكون قادرًا على ترتيب ) بسرعة الشبكة بسبب مشاكل القيادة (، إلا أن DAG لا يزال ينمو بسرعة الشبكة، على الرغم من وجود بعض القادة الذين لديهم مشاكل أو الشبكة غير متزامنة. في النهاية، عندما يقوم القادة الخاليين من الأخطاء ببث النقاط المرجعية بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل للنقاط المرجعية.
جاري التقييم، قمنا بمقارنة Bullshark في الحالات التالية لمعرفة ما إذا كان هناك أي وقت مستقطع:
القادة السريعين، على الأقل أسرع من غيرهم من المدققين. في هذه الحالة، توفر الطريقتان نفس التأخير، لأن الرابطة مرتبة ولا تستخدم الوقت المستغرق.
القادة الخاطئون، في هذه الحالة، يوفر Bullshark بدون توقف تأخيرًا أفضل، حيث سيتخطى عقد التحقق على الفور نقاط الربط الخاصة به، بينما ستنتظر عقد التحقق مع التوقف حتى انتهاء صلاحيتها قبل المتابعة.
القادة البطيئون، هذه هي الحالة الوحيدة التي يكون فيها أداء Bullshark المتفوق أفضل. لأنه في حالة عدم وجود توقيف، قد يتم تخطي النقاط المرجعية لأن القائد لا يستطيع بثها بسرعة كافية، وعندما يكون هناك توقيف، سينتظر المدققون النقاط المرجعية.
في Shoal، تجنب تجاوز الوقت مرتبط ارتباطًا وثيقًا بسمعة القائد. الانتظار المتكرر