إطار Shoal: كيف نقلل وقت الإستجابة لـ Bullshark على Aptos؟
حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل كبير، ولأول مرة ألغت الحاجة إلى المهلة في البروتوكولات العملية الحتمية. بشكل عام، تم تحسين وقت استجابة Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز بروتوكول الإجماع المستند إلى Narwhal من خلال معالجة خطوط الأنابيب وآلية سمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). تقلل معالجة خطوط الأنابيب من وقت استجابة ترتيب DAG عن طريق إدخال نقطة ربط في كل جولة، بينما تحسن آلية سمعة القادة مشكلة الوقت المستجابة من خلال ضمان ارتباط النقاط المرساة بأسرع عقد التحقق. علاوة على ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على وقت الاستجابة في جميع السيناريوهات. وهذا يمكّن Shoal من تقديم خاصية الاستجابة العالمية، بما في ذلك الاستجابة المتفائلة التي تحتاج إليها عادة.
هذه التقنية بسيطة للغاية، حيث تتضمن تشغيل عدة مثيلات من البروتوكول الأساسي بالتتابع. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
الخلفية
في سعيها لتحقيق أداء عالٍ لشبكة البلوكتشين، كانت هناك دائمًا اهتمام بتقليل تعقيد الاتصال. ومع ذلك، لم تؤدي هذه الطريقة إلى تحسين كبير في معدل نقل البيانات. على سبيل المثال، لم تصل Hotstuff التي تم تنفيذها في النسخة المبكرة من Diem إلا إلى 3500 TPS، وهو أقل بكثير من الهدف البالغ 100,000+ TPS.
إن الاختراق الأخير ناتج عن إدراك أن انتشار البيانات هو نقطة الاختناق الرئيسية بناءً على بروتوكولات القادة، ويمكن أن يستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات ومنطق الإجماع الأساسي، ويقدم بنية حيث يقوم جميع المراجعين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة فقط من البيانات الوصفية. أبلغت ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ لـ Narwhal، والذي يفصل بين نشر البيانات والإجماع، وكذلك كيفية استخدامه لتوسيع بروتوكول الإجماع الحالي Jolteon. Jolteon هو بروتوكول قائم على القائد، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكولات الإجماع القائمة على القائد لا يمكنها بوضوح الاستفادة الكاملة من إمكانات سعة Narwhal. على الرغم من فصل نشر البيانات عن الإجماع، إلا أن قائد Hotstuff/Jolteon لا يزال مقيدًا مع زيادة السعة.
لذلك، قررت Aptos نشر Bullshark على Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark عالي الإنتاجية يأتي بتكلفة تأخير قدرها 50%.
تتناول هذه المقالة كيف يمكن لـ Shoal تقليل وقت الإستجابة بشكل كبير لـ Bullshark.
خلفية DAG-BFT
كل قمة في Narwhal DAG مرتبطة بدورة معينة. للدخول في الجولة r، يجب على المدقق أولاً الحصول على n-f من القمم التي تنتمي إلى الجولة r-1. يمكن لكل مدقق أن يبث قمة واحدة في كل جولة، ويجب أن تشير كل قمة على الأقل إلى n-f من القمم في الجولة السابقة. نظرًا للاختلاف في توقيت الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
تتمثل إحدى الخصائص الرئيسية لـ DAG في عدم الغموض: إذا كان لدى عقدتي التحقق نفس الرأس v في عرض DAG المحلي الخاص بهما، فإنهما تمتلكان تاريخًا سببيًا متطابقًا تمامًا لـ v.
المقدمة
يمكن التوصل إلى توافق على الترتيب الإجمالي لجميع القمم في DAG دون تكاليف إضافية للاتصال. لتحقيق ذلك، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG على أنها بروتوكول إجماع، حيث تمثل القمم المقترحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تقاطع المجموعات في هيكل DAG يختلف، إلا أن جميع بروتوكولات الإجماع القائمة على Narwhal لها الهيكل التالي:
نقطة الربط المحددة: بعد عدة جولات ( على سبيل المثال، في Bullshark، سيكون هناك قائد محدد مسبقاً في كل جولتين )، وذروة القائد تُسمى نقطة الربط.
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يتم ترتيبها وأي النقاط يتم تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة الخاصة بهم واحدًا تلو الآخر، ولكل نقطة ربط، يتم ترتيب جميع القمم غير المرتبة السابقة في تاريخها السببي وفقًا لبعض القواعد الحتمية.
المفتاح لضمان الأمان هو التأكد من أنه في الخطوة (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، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول مخبأة في البساطة.
في 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 مثقلين، وانتهى وقت الاستجابة قبل أن يدفعوا التقدم.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 9
أعجبني
9
5
مشاركة
تعليق
0/400
ChainSpy
· منذ 7 س
绿灯啦 APT要للقمر
شاهد النسخة الأصليةرد0
AirdropHunter007
· منذ 18 س
وقت الإستجابة降40%؟ هذه الموجة للقمر！
شاهد النسخة الأصليةرد0
BTCBeliefStation
· منذ 18 س
رائع هذه الزيادة في التحسين جعلتني مذهولاً
شاهد النسخة الأصليةرد0
CounterIndicator
· منذ 18 س
ثور啊 وقت الإستجابة降了一半多
شاهد النسخة الأصليةرد0
MoonRocketTeam
· منذ 18 س
哎哟وقت الإستجابة مباشرة 50% تراجع هذه نافذة الإطلاق要 للقمر
تحسين إطار Shoal لبروتوكول إجماع Aptos انخفض وقت الإستجابة ل Bullshark بشكل كبير
إطار Shoal: كيف نقلل وقت الإستجابة لـ Bullshark على Aptos؟
حلت Aptos Labs مؤخرًا مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل كبير، ولأول مرة ألغت الحاجة إلى المهلة في البروتوكولات العملية الحتمية. بشكل عام، تم تحسين وقت استجابة Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز بروتوكول الإجماع المستند إلى Narwhal من خلال معالجة خطوط الأنابيب وآلية سمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). تقلل معالجة خطوط الأنابيب من وقت استجابة ترتيب DAG عن طريق إدخال نقطة ربط في كل جولة، بينما تحسن آلية سمعة القادة مشكلة الوقت المستجابة من خلال ضمان ارتباط النقاط المرساة بأسرع عقد التحقق. علاوة على ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على وقت الاستجابة في جميع السيناريوهات. وهذا يمكّن Shoal من تقديم خاصية الاستجابة العالمية، بما في ذلك الاستجابة المتفائلة التي تحتاج إليها عادة.
هذه التقنية بسيطة للغاية، حيث تتضمن تشغيل عدة مثيلات من البروتوكول الأساسي بالتتابع. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
الخلفية
في سعيها لتحقيق أداء عالٍ لشبكة البلوكتشين، كانت هناك دائمًا اهتمام بتقليل تعقيد الاتصال. ومع ذلك، لم تؤدي هذه الطريقة إلى تحسين كبير في معدل نقل البيانات. على سبيل المثال، لم تصل Hotstuff التي تم تنفيذها في النسخة المبكرة من Diem إلا إلى 3500 TPS، وهو أقل بكثير من الهدف البالغ 100,000+ TPS.
إن الاختراق الأخير ناتج عن إدراك أن انتشار البيانات هو نقطة الاختناق الرئيسية بناءً على بروتوكولات القادة، ويمكن أن يستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات ومنطق الإجماع الأساسي، ويقدم بنية حيث يقوم جميع المراجعين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة فقط من البيانات الوصفية. أبلغت ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ لـ Narwhal، والذي يفصل بين نشر البيانات والإجماع، وكذلك كيفية استخدامه لتوسيع بروتوكول الإجماع الحالي Jolteon. Jolteon هو بروتوكول قائم على القائد، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكولات الإجماع القائمة على القائد لا يمكنها بوضوح الاستفادة الكاملة من إمكانات سعة Narwhal. على الرغم من فصل نشر البيانات عن الإجماع، إلا أن قائد Hotstuff/Jolteon لا يزال مقيدًا مع زيادة السعة.
لذلك، قررت Aptos نشر Bullshark على Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark عالي الإنتاجية يأتي بتكلفة تأخير قدرها 50%.
تتناول هذه المقالة كيف يمكن لـ Shoal تقليل وقت الإستجابة بشكل كبير لـ Bullshark.
خلفية DAG-BFT
كل قمة في Narwhal DAG مرتبطة بدورة معينة. للدخول في الجولة r، يجب على المدقق أولاً الحصول على n-f من القمم التي تنتمي إلى الجولة r-1. يمكن لكل مدقق أن يبث قمة واحدة في كل جولة، ويجب أن تشير كل قمة على الأقل إلى n-f من القمم في الجولة السابقة. نظرًا للاختلاف في توقيت الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
تتمثل إحدى الخصائص الرئيسية لـ DAG في عدم الغموض: إذا كان لدى عقدتي التحقق نفس الرأس v في عرض DAG المحلي الخاص بهما، فإنهما تمتلكان تاريخًا سببيًا متطابقًا تمامًا لـ v.
المقدمة
يمكن التوصل إلى توافق على الترتيب الإجمالي لجميع القمم في DAG دون تكاليف إضافية للاتصال. لتحقيق ذلك، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG على أنها بروتوكول إجماع، حيث تمثل القمم المقترحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تقاطع المجموعات في هيكل DAG يختلف، إلا أن جميع بروتوكولات الإجماع القائمة على Narwhal لها الهيكل التالي:
نقطة الربط المحددة: بعد عدة جولات ( على سبيل المثال، في Bullshark، سيكون هناك قائد محدد مسبقاً في كل جولتين )، وذروة القائد تُسمى نقطة الربط.
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يتم ترتيبها وأي النقاط يتم تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة الخاصة بهم واحدًا تلو الآخر، ولكل نقطة ربط، يتم ترتيب جميع القمم غير المرتبة السابقة في تاريخها السببي وفقًا لبعض القواعد الحتمية.
المفتاح لضمان الأمان هو التأكد من أنه في الخطوة (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، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول مخبأة في البساطة.
في 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 مثقلين، وانتهى وقت الاستجابة قبل أن يدفعوا التقدم.
للأسف، بناءً على بروتوكول القائد ( مثل