إطار Shoal: تحسين وقت الإستجابة للإجماع Bullshark على Aptos

قامت Aptos Labs مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما قلل بشكل كبير من وقت الإستجابة، وألغى لأول مرة الحاجة إلى المهلة في بروتوكولات الحقيقية المحددة. بشكل عام، تم تحسين وقت إستجابة Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة حدوث أعطال.

Shoal هو إطار عمل يعزز بروتوكول الإجماع القائم على Narwhal من خلال معالجة خطوط الأنابيب وآلية سمعة القائد ( مثل DAG-Rider و Tusk و Bullshark ). تعمل خطوط الأنابيب على تقليل وقت الإستجابة من خلال إدخال نقطة ربط في كل جولة، بينما تعمل سمعة القائد على تحسين مشكلة التأخير من خلال ضمان ارتباط النقاط المرتبطة بأسرع عقد التحقق. بالإضافة إلى ذلك، تسمح سمعة القائد لـ Shoal بالاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي تتضمن المهلات. وهذا يمكّن Shoal من تقديم خصائص الاستجابة العامة، بما في ذلك الاستجابة المتفائلة المطلوبة عادة.

تقنية Shoal بسيطة نسبيًا، حيث يتم تشغيل عدة مثيلات من البروتوكول الأساسي واحدًا تلو الآخر حسب الترتيب. عند استخدام Bullshark للتجسيد، تتشكل مجموعة من "الأسماك" في سباق التتابع.

الخلفية والدوافع

في سعيها لتحقيق أداء عالٍ لشبكة البلوكشين، كانت تقليل تعقيد الاتصالات دائمًا محور التركيز. ومع ذلك، لم تؤدِ هذه الطريقة إلى تحسين كبير في معدل النقل. على سبيل المثال، حققت Hotstuff التي تم تنفيذها في الإصدارات المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.

لقد نشأت الاختراقات الأخيرة من إدراك أن انتشار البيانات هو العنصر الرئيسي في قيود الاتفاق بين القادة، ويمكن أن يستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات والمنطق الأساسي للإجماع، مقترحًا هيكلًا حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما تقوم مكونات الإجماع بترتيب كمية صغيرة من البيانات الوصفية فقط. وقد أفادت ورقة Narwhal بمعدل نقل قدره 160,000 TPS.

قدمت Aptos سابقًا Quorum Store، وهو تطبيق لـ Narwhal، حيث يتم فصل نشر البيانات عن الإجماع، بالإضافة إلى كيفية استخدامه لتوسيع بروتوكول الإجماع الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، من الواضح أن بروتوكولات الإجماع القائمة على القيادة لا يمكنها الاستفادة الكاملة من إمكانيات قدرة Narwhal. على الرغم من فصل نشر البيانات عن الإجماع، فإنه مع زيادة القدرة، لا يزال زعيم Hotstuff/Jolteon مقيدًا.

لذلك، قررت Aptos نشر Bullshark، وهو بروتوكول إجماع بدون تكلفة اتصالات، على Narwhal DAG. للأسف، فإن هيكل DAG الذي يدعم Bullshark بسعة عالية يأتي بتكلفة تأخير تبلغ 50% مقارنة بـ Jolteon.

خلفية DAG-BFT

كل رأس في Narwhal DAG مرتبط بدورة معينة. لدخول الجولة r، يجب على المصدقين أولاً الحصول على n-f من الرؤوس المنتمية للجولة r-1. يمكن لكل مصدق في كل جولة بث رأس واحد، ويجب أن يشير كل رأس على الأقل إلى n-f من الرؤوس في الجولة السابقة. بسبب عدم التزامن في الشبكة، قد يلاحظ المصدقون المختلفون في أي نقطة زمنية رؤى محلية مختلفة لـ DAG.

تتمثل إحدى الخصائص الرئيسية لـ DAG في عدم الغموض: إذا كان لدى عقدتي تحقق اثنتين نفس القمة v في رؤيتهما المحلية لـ DAG، فإنهما تمتلكان تاريخًا سببيًا متطابقًا تمامًا لـ v.

المقدمة

يمكن تحقيق توافق على الترتيب الكلي لجميع القمم في DAG دون أي تكلفة إضافية للتواصل. لتحقيق ذلك، يُفسر المصدقون في DAG-Rider وTusk وBullshark هيكل DAG كنوع من بروتوكول الإجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف الأصوات.

على الرغم من أن منطق تقاطع المجموعات في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع القائمة على Narwhal الحالية تمتلك الهيكل التالي:

1. نقاط التثبيت: بعد كل عدة جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد مسبقًا، وقمة القائد تُسمى نقطة التثبيت.

2. نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يجب ترتيبها وأي النقاط يجب تخطيها.

3. ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، وبالنسبة لكل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخها السببي وفقًا لقواعد حتمية.

المفتاح لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة في الخطوة 2 تقوم بإنشاء قائمة نقاط ربط مرتبة، بحيث تشارك جميع القوائم نفس البادئة. في Shoal، يمكن إجراء الملاحظات التالية بشأن جميع البروتوكولات المذكورة أعلاه: يتفق جميع المدققين على أول نقطة ربط مرتبة.

Bullshark وقت الإستجابة

يعتمد وقت الإستجابة لـ Bullshark على عدد الدورات بين النقاط المرسومة في DAG. على الرغم من أن النسخة المتزامنة الأكثر فائدة من Bullshark لديها وقت إستجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.

توجد مشكلتان رئيسيتان:

1. متوسط وقت الإستجابة للكتل: في Bullshark، يوجد نقطة مرجعية في كل جولة زوجية، ويتم تفسير قمم الجولات الفردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى جولتين من DAG لفرز النقاط المرجعية، ومع ذلك، تحتاج القمم في التاريخ السببي للنقاط المرجعية إلى المزيد من الجولات للانتظار حتى يتم فرز النقاط المرجعية. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج قمم الجولات الزوجية غير المرجعية إلى أربع جولات.

2. حالات الفشل وقت الإستجابة: إذا فشل القائد في جولة ما في بث النقطة المرجعية بشكل سريع بما فيه الكفاية، فلن يمكن ترتيب النقطة المرجعية ( وبالتالي يتم تخطيها )، يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. سيؤدي هذا إلى تقليل أداء شبكة النسخ الجغرافي بشكل كبير، خاصة لأن Bullshark يستخدم المهلة للانتظار على القائد.

إطار Shoal

عزز Shoal معالجة سلسلة الإنتاج Bullshark( أو أي بروتوكول BFT آخر قائم على Narwhal)، مما يسمح بوجود نقطة ربط في كل جولة، ويقلل من وقت الإستجابة لجميع القمم غير المرتبطة في DAG إلى ثلاث جولات. كما قدم Shoal آلية سمعة قادة دون تكلفة في DAG، مما يساهم في تفضيل القادة السريعين.

التحدي

في سياق بروتوكول DAG، تعتبر معالجة الخطوط والسمعة القيادية من القضايا الصعبة، والأسباب كالتالي:

1. كانت محاولات معالجة خط الأنابيب السابقة لتعديل منطق Bullshark الأساسي، ولكن يبدو أن هذا من الناحية الجوهرية مستحيل.

2. تم إدخال سمعة القادة في DiemBFT وتثبيتها رسميًا في Carousel، وهي فكرة اختيار القادة المستقبليين ديناميكيًا بناءً على أداء المراجعين في الماضي في (Bullshark. على الرغم من أن وجود خلافات في هوية القادة لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا. هذا يثير جوهر المشكلة، وهو أن اختيار العجلات بشكل ديناميكي وحتمي ضروري لحل الإجماع، ويحتاج المراجعون إلى التوصل إلى إجماع بشأن التاريخ المنظم لاختيار العجلات المستقبلية.

البروتوكول

على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول مخبأة في البساطة. في Shoal، تم استخدام القدرة على تنفيذ الحسابات المحلية على DAG، مما يوفر القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل التوافق بين جميع المدققين على الرؤية الأساسية للنقطة المرصودة الأولى، يقوم Shoal بدمج عدة حالات Bullshark بالتسلسل لمعالجة التدفق، مما يتيح:

1. النقطة المرسومة الأولى هي نقطة التحويل الخاصة بالنموذج
2. التاريخ السببي للنقطة المرجعية يُستخدم في حساب سمعة القادة

) معالجة خط الأنابيب

V يربط الجولات بالقادة. تعمل Shoal على تشغيل مثيل من Bullshark واحدًا تلو الآخر، بحيث يتم تحديد النقطة المرجعية مسبقًا بواسطة الرسم F لكل مثيل. يتم ترتيب نقطة مرجعية واحدة لكل مثيل، مما يؤدي إلى الانتقال إلى المثيل التالي.

في البداية، أطلق Shoal أول نموذج لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى تم تحديد أول نقطة ربط مرتبة، مثل الجولة r. اتفق جميع المدققين على هذه النقطة. لذلك، يمكن لجميع المدققين بشكل مؤكد الاتفاق على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal فقط نموذج Bullshark جديد في الجولة r+1.

في أفضل الحالات، يسمح ذلك لـ Shoal بترتيب ركيزة في كل جولة. يتم ترتيب نقاط الركيزة في الجولة الأولى حسب أول مثيل. ثم، يبدأ Shoal مثيلًا جديدًا في الجولة الثانية، والذي يحتوي على نقطة ركيزة، ويتم ترتيب هذه الركيزة بواسطة هذا المثيل، ثم يتم ترتيب نقطة ركيزة جديدة في الجولة الثالثة، وتستمر هذه العملية.

![شرح مفصل لإطار عمل Shoal: كيف تقلل من وقت الإستجابة لبول شارك على Aptos؟]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(

) سمعة القادة

عند تخطي نقاط الربط خلال فترة فرز Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، فإن تقنية المعالجة المتسلسلة غير فعالة، لأن بدء مثيل جديد لا يمكن أن يحدث قبل فرز نقطة الربط السابقة. يضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة، مما يجعل من غير المحتمل اختيار القادة المعنيين للتعامل مع نقاط الربط المفقودة في المستقبل. سيحصل المتحققون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، بينما ستتلقى عقد التحقق درجات منخفضة، لأنها قد تكون غير مستقرة أو بطيئة أو ضارة.

مفاهيمها هي إعادة حساب خريطة محددة مسبقًا F من الجولات إلى القائد بشكل حتمي عند تحديث الدرجات، مع التوجه نحو القائد الذي حصل على درجات أعلى. لكي يتفق المدققون على الخريطة الجديدة، يجب عليهم التوصل إلى توافق في الدرجات، وبالتالي الوصول إلى توافق في التاريخ المستخدم لاشتقاق الدرجات.

في Shoal، يمكن دمج معالجة الخطوط القيادة والسمعة بشكل طبيعي، لأنها تستخدم نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى الإجماع على أول نقطة ربط مرتبة.

في الواقع، الفرق الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المصادقون فقط إلى حساب التمثيل الجديد F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، تستخدم عقدة التحقق وظيفة اختيار النقاط المرجعية المحدّثة F' لتنفيذ مثيل جديد لـ Bullshark بدءًا من الجولة r+1.

![شرح شامل لإطار عمل Shoal: كيف نخفض وقت الإستجابة لـ Bullshark على Aptos؟]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(

) لا حاجة للتأخير

تلعب المهلة دورًا حيويًا في جميع تطبيقات BFT القابلة للتحديد المعتمدة على القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي يجب إدارتها ومراقبتها، مما يزيد من تعقيد عملية التصحيح ويحتاج إلى المزيد من تقنيات المراقبة.

سوف يزيد وقت الإستجابة بشكل ملحوظ عند تجاوز الوقت المحدد، لأنه من المهم تكوينها بشكل صحيح، وعادة ما تحتاج إلى ضبط ديناميكي، لأنها تعتمد بشكل كبير على البيئة ### الشبكة (. قبل الانتقال إلى قائد جديد، يدفع البروتوكول عقوبة وقت الإستجابة الكاملة للقائد الذي حدث به عطل. لذلك، لا ينبغي أن تكون إعدادات الوقت المحدد متحفظة للغاية، ولكن إذا كان وقت التوقيت قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين.

لسوء الحظ، تتطلب بروتوكولات القائد مثل Hotstuff و Jolteon) بشكل أساسي وقت الإستجابة لضمان تقدم البروتوكول في كل مرة يتعطل فيها القائد. بدون وقت الإستجابة، قد يتوقف البروتوكول إلى الأبد حتى مع وجود قائد معطل. نظرًا لأنه لا يمكن تمييز القائد المعطل عن القائد البطيء خلال فترة غير متزامنة، قد يؤدي وقت الإستجابة إلى قيام العقد المصدقة بمشاهدة تغيير جميع القادة دون وجود نشاط للإجماع.

في Bullshark، يُستخدم وقت الإستجابة لبناء DAG، لضمان أن القادة المخلصين سيضيفون النقاط المرجعية إلى DA أثناء المزامنة.