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

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

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

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

دافع

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

لكن الاختراق الأخير ناتج عن إدراك أن انتشار البيانات هو عنق الزجاجة الرئيسي المعتمد على بروتوكول القادة، ويمكن أن يستفيد من التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن المنطق الأساسي للتوافق، ويقدم بنية تقوم فيها جميع الجهات الفاعلة بنشر البيانات في نفس الوقت، بينما تقوم مكونات التوافق بترتيب كمية صغيرة من البيانات الوصفية. أبلغت ورقة Narwhal عن معدل إنتاجية يبلغ 160000 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 و Bullshark، يرجى الرجوع إلى مقال DAG meets BFT.

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

خاصية رئيسية من DAG هي أنها غير غامضة: إذا كان لدى عقدتي التحقق اثنين في وجهة نظرهما المحلية لـ DAG نفس القمة v، فإن لهما نفس التاريخ السببي لـ 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، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يبرز لب المشكلة، وهو أن اختيار الربط الديناميكي والحتمي ضروري لحل الإجماع، ويحتاج المدققون إلى الاتفاق على التاريخ المرتب لاختيار الربط المستقبلي.

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

بروتوكول

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

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

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

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

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

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

![شرح شامل لإطار Shoal: كيف تقلل من وقت الإستجابة لBullshark على 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 المتزامنة المحددة على أساس القائد. ومع ذلك، فإن التعقيد الذي يتم إدخاله يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب المزيد من تقنيات المراقبة.

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