إطار Shoal: كيف يمكن تقليل تأخير Bullshark على Aptos؟

نظرة عامة

عملت مختبرات 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.

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

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

تتناول هذه المقالة كيفية تحقيق شوال تقليل كبير في تأخير بول شارك.

! 万字详解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 تتمتع بالهيكل التالي:

1. نقطة التثبيت: يوجد قائد محدد مسبقًا كل عدة جولات، ويطلق على قمة القائد نقطة التثبيت؛

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

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

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

توافق جميع الجهات الفاعلة على أول نقطة ربط مرتبة.

! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?

Bullshark تأخير

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

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

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

! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?

إطار Shoal

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

التحدي

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

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

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

كأدلة على صعوبة المشكلة، فإن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.

![شرح مفصل عن إطار العمل Shoal: كيف نقلل من تأخير Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(

الاتفاقية

على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول مخفية وراء البساطة.

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

خط التجميع

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-9f789cb669f6fcc244ea7ff7648e48b4.webp(

سمعة القادة

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

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

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

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

! [万字详解Shoal框架:如何减少Aptos上的Bullshark延迟? ])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(

لا مزيد من المهلات

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

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