تحسين DAG الإجمــاع: كيف يمكن لإطار Shoal اسقاط وقت الإستجابة لـ Bullshark على Aptos
حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى إسقاط وقت الإستجابة بشكل ملحوظ، وأزالت الحاجة إلى تجاوز الوقت لأول مرة في بروتوكول غير متزامن محدد. بشكل عام، قام إطار العمل Shoal بتحسين وقت الإستجابة لـ 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، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنة بـ Jolteon، فإن بنية DAG التي تدعم Bullshark ذات السعة العالية تأتي بتكلفة تأخير بنسبة 50٪.
تستعرض هذه المقالة كيف يمكن لـ Shoal أن يسقط وقت الإستجابة لـ Bullshark بشكل كبير.
خلفية 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 وقت الإستجابة
يعتمد وقت الاستجابة لـ Bullshark على عدد الدورات بين النقاط المرسومة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر فائدة من Bullshark تتمتع بوقت استجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 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 و Jolteon ) يتطلب أساسًا مهلة لضمان تقدم البروتوكول في كل مرة يتعطل فيها القائد. إذا لم يكن هناك مهلة، حتى القائد المعطل قد يتوقف عن البروتوكول إلى الأبد. نظرًا لأنه لا يمكن التمييز بين القائد المعطل والقائد البطيء خلال الفترة غير المتزامنة، قد تؤدي المهلة إلى رؤية العقدة المصدقّة لتغييرات جميع القادة دون نشاط إجماع.
في Bullshark، يُستخدم وقت الإستجابة لبناء DAG، لضمان أن القادة الأمناء سيضيفون نقاط الربط خلال فترة المزامنة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 11
أعجبني
11
6
إعادة النشر
مشاركة
تعليق
0/400
GateUser-c799715c
· منذ 12 س
تحسين الأداء جيد جداً~
شاهد النسخة الأصليةرد0
AllInAlice
· منذ 15 س
هو شخص قاسي 40% خفض وقت الإستجابة
شاهد النسخة الأصليةرد0
0xSherlock
· منذ 15 س
وقت الإستجابة هذه الموجة يمكن معالجتها بطريقة رائعة
شاهد النسخة الأصليةرد0
BrokenYield
· منذ 15 س
مه، "تحسين" آخر ربما سيخلق مخاطر نظامية أكثر مما يحل... المال الذكي بالفعل يتخذ احتياطات ضد هذا
تحسين إطار عمل Shoal للإجماع DAG خفض وقت الإستجابة بشكل كبير في Bullshark على Aptos
تحسين DAG الإجمــاع: كيف يمكن لإطار Shoal اسقاط وقت الإستجابة لـ Bullshark على Aptos
حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى إسقاط وقت الإستجابة بشكل ملحوظ، وأزالت الحاجة إلى تجاوز الوقت لأول مرة في بروتوكول غير متزامن محدد. بشكل عام، قام إطار العمل Shoal بتحسين وقت الإستجابة لـ 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، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنة بـ Jolteon، فإن بنية DAG التي تدعم Bullshark ذات السعة العالية تأتي بتكلفة تأخير بنسبة 50٪.
تستعرض هذه المقالة كيف يمكن لـ Shoal أن يسقط وقت الإستجابة لـ Bullshark بشكل كبير.
خلفية 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 وقت الإستجابة
يعتمد وقت الاستجابة لـ Bullshark على عدد الدورات بين النقاط المرسومة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر فائدة من Bullshark تتمتع بوقت استجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 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 و Jolteon ) يتطلب أساسًا مهلة لضمان تقدم البروتوكول في كل مرة يتعطل فيها القائد. إذا لم يكن هناك مهلة، حتى القائد المعطل قد يتوقف عن البروتوكول إلى الأبد. نظرًا لأنه لا يمكن التمييز بين القائد المعطل والقائد البطيء خلال الفترة غير المتزامنة، قد تؤدي المهلة إلى رؤية العقدة المصدقّة لتغييرات جميع القادة دون نشاط إجماع.
في Bullshark، يُستخدم وقت الإستجابة لبناء DAG، لضمان أن القادة الأمناء سيضيفون نقاط الربط خلال فترة المزامنة.