إطار Shoal: كيفية تقليل وقت الإستجابة لـ Bullshark على Aptos

نظرة عامة

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

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

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

! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)

الدوافع

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

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

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

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

تقدم هذه المقالة كيفية تقليل وقت الإستجابة لـ Bullshark بشكل كبير بواسطة Shoal.

خلفية DAG-BFT

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

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

! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)

الترتيب الكامل

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

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

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

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

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

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

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

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

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

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

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

إطار شوال

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

التحدي

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

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

2. تم تقديم سمعة القائد في 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. بعد ذلك، تستخدم العقد المصدقة وظيفة اختيار النقاط المرجعية المُحدثة F' لتنفيذ مثيل جديد لبولشارك بدءًا من الجولة r+1.

لا مزيد من وقت الإستجابة

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

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