إطار Shoal: تحسين وقت الإستجابة ل Consensus 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، وهو أقل بكثير من الهدف البالغ 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.
ستتناول هذه المقالة كيفية تقليل وقت الإستجابة ل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 تتمتع بالهيكل التالي:
نقطة الربط المحددة مسبقاً: بعد عدد من الجولات، سيكون هناك قائد محدد مسبقاً، ويطلق على قمة القائد اسم نقطة الربط.
ترتيب النقاط المرجعية: يقرر المدققون بشكل مستقل ولكن حازم ترتيب النقاط المرجعية التي يجب تضمينها وتلك التي يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدقق بمعالجة قائمة النقاط الثابتة المرتبة واحدة تلو الأخرى، ويقوم بترتيب جميع الرؤوس غير المرتبة السابقة في التاريخ السببي لكل نقطة ثابتة.
الشرط الأساسي للأمان هو التأكد من أن جميع عقد التحقق الصادقة تنشئ قائمة نقاط تثبيت مرتبة في الخطوة (2)، بحيث تشارك جميع القوائم نفس البادئة. في Shoal، نقدم الملاحظات التالية على جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
يعتمد وقت الإستجابة لبول شارك على عدد الدورات بين نقاط الربط المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية لبول شارك توفر وقت إستجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن أن تكون مثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة مرجعية في كل جولة زوجية، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى جولتين من DAG لترتيب النقاط المرجعية، ومع ذلك، تحتاج القمم في التاريخ السببي لنقاط المرجعية إلى المزيد من الجولات في انتظار ترتيب النقاط المرجعية. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرجعية في الجولات الزوجية إلى أربع جولات.
السؤال 2: وقت الإستجابة لحالات الفشل. ينطبق تحليل التأخير أعلاه على الحالات الخالية من الأعطال، ومن ناحية أخرى، إذا فشل الزعيم في الجولة في بث النقاط المرجعية بسرعة كافية، فلا يمكن فرز النقاط المرجعية ( وبالتالي يتم تخطيها )، وبالتالي يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم فرز النقطة المرجعية التالية. سيؤدي ذلك إلى تقليل أداء شبكة النسخ الجغرافي بشكل ملحوظ، خاصة لأن Bullshark يستخدم أوقات الانتظار للانتظار للزعيم.
إطار Shoal
حل 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 مثقلين، وانتهى وقت الإستجابة قبل أن يحققوا تقدمًا.
للأسف، بروتوكول الإجماع القائم على القادة ### مثل Hotstuff
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 9
أعجبني
9
6
إعادة النشر
مشاركة
تعليق
0/400
SchrodingerProfit
· منذ 10 س
هذا يعني أن aptos سيذهب للقمر مرة أخرى
شاهد النسخة الأصليةرد0
CodeAuditQueen
· منذ 16 س
هناك أيضًا مخاطر إعادة الدخول في قوة الحوسبة بسبب تحسين الخوارزمية المعقدة. نأمل ألا يحدث انفجار في المجاري.
إطار Shoal يعزز كفاءة إجماع Aptos: Bullshark وقت الإستجابة انخفض بشكل كبير بنسبة 40-80%
إطار Shoal: تحسين وقت الإستجابة ل Consensus 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، وهو أقل بكثير من الهدف البالغ 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.
ستتناول هذه المقالة كيفية تقليل وقت الإستجابة ل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 تتمتع بالهيكل التالي:
نقطة الربط المحددة مسبقاً: بعد عدد من الجولات، سيكون هناك قائد محدد مسبقاً، ويطلق على قمة القائد اسم نقطة الربط.
ترتيب النقاط المرجعية: يقرر المدققون بشكل مستقل ولكن حازم ترتيب النقاط المرجعية التي يجب تضمينها وتلك التي يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدقق بمعالجة قائمة النقاط الثابتة المرتبة واحدة تلو الأخرى، ويقوم بترتيب جميع الرؤوس غير المرتبة السابقة في التاريخ السببي لكل نقطة ثابتة.
الشرط الأساسي للأمان هو التأكد من أن جميع عقد التحقق الصادقة تنشئ قائمة نقاط تثبيت مرتبة في الخطوة (2)، بحيث تشارك جميع القوائم نفس البادئة. في Shoal، نقدم الملاحظات التالية على جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
يعتمد وقت الإستجابة لبول شارك على عدد الدورات بين نقاط الربط المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية لبول شارك توفر وقت إستجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن أن تكون مثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة مرجعية في كل جولة زوجية، ويتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى جولتين من DAG لترتيب النقاط المرجعية، ومع ذلك، تحتاج القمم في التاريخ السببي لنقاط المرجعية إلى المزيد من الجولات في انتظار ترتيب النقاط المرجعية. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرجعية في الجولات الزوجية إلى أربع جولات.
السؤال 2: وقت الإستجابة لحالات الفشل. ينطبق تحليل التأخير أعلاه على الحالات الخالية من الأعطال، ومن ناحية أخرى، إذا فشل الزعيم في الجولة في بث النقاط المرجعية بسرعة كافية، فلا يمكن فرز النقاط المرجعية ( وبالتالي يتم تخطيها )، وبالتالي يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم فرز النقطة المرجعية التالية. سيؤدي ذلك إلى تقليل أداء شبكة النسخ الجغرافي بشكل ملحوظ، خاصة لأن Bullshark يستخدم أوقات الانتظار للانتظار للزعيم.
إطار Shoal
حل 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 مثقلين، وانتهى وقت الإستجابة قبل أن يحققوا تقدمًا.
للأسف، بروتوكول الإجماع القائم على القادة ### مثل Hotstuff