إطار Shoal: كيف يمكن اسقاط وقت الإستجابة لBullshark على Aptos؟
نظرة عامة
قامت مختبرات Aptos بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل كبير، ولأول مرة القضاء على الحاجة إلى انتهاء الوقت في البروتوكولات الحقيقية الحتمية. بشكل عام، تم تحسين وقت الإستجابة لبولشارك بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal من خلال خطوط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). تقوم خطوط الأنابيب بتقليل وقت الإستجابة من خلال إدخال نقطة ربط في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت من خلال ضمان ارتباط النقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي قد تتعرض لوقت الإستجابة. وهذا يمكّن Shoal من تقديم خاصية الاستجابة العالمية، والتي تتضمن الاستجابة المتفائلة المطلوبة عادة.
هذه التقنية بسيطة للغاية، حيث تتضمن تشغيل عدة أمثلة من البروتوكولات الأساسية بالتتابع. لذلك، عندما يتم تجسيدها باستخدام Bullshark، نحصل على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
الدافع
عند السعي نحو أداء عالٍ لشبكة البلوكشين، كان التركيز دائمًا على اسقاط تعقيد الاتصالات. ومع ذلك، لم تؤدِ هذه الطريقة إلى تحسين كبير في معدل النقل. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في النسخة المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
الاختراق الأخير ناتج عن إدراك أن انتشار البيانات هو العقبة الرئيسية التي تعتمد على بروتوكول القادة، ويمكن الاستفادة من التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن المنطق الأساسي للتوافق، ويقترح بنية يتم فيها نشر البيانات بواسطة جميع المدققين في نفس الوقت، بينما يقوم مكون التوافق بترتيب كمية صغيرة من البيانات الوصفية. تقرير ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
تمت الإشارة سابقًا إلى Quorum Store، الذي يفصل بين نشر البيانات والتوافق، وكيفية استخدامه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير الرؤية على طراز PBFT، مما يقلل وقت الاستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، لا تستطيع بروتوكولات التوافق القائمة على القيادة الاستفادة الكاملة من إمكانيات إنتاجية Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن قادة Hotstuff/Jolteon لا يزالون مقيدين مع زيادة الإنتاجية.
لذلك، تم اتخاذ القرار بنشر Bullshark فوق Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو throughput عالي يأتي بتكلفة تأخير بنسبة 50٪.
تقدم هذه المقالة كيفية تقليل وقت الإستجابة 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 إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار الربط الديناميكي والحتمي هو أمر ضروري لحل الإجماع، ويجب على المصادقين التوصل إلى توافق بشأن التاريخ المنظم لاختيار الربط المستقبلي.
كأدلة على صعوبة المشكلة، فإن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
الاتفاقية
على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول مخبأة وراء البساطة.
في Shoal، نعتمد على القدرة على تنفيذ الحسابات المحلية على DAG، ونحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على الرؤية الأساسية للنقطة المرسومة الأولى، يقوم Shoal بترتيب وتجميع عدة حالات من Bullshark لمعالجتها بشكل متسلسل، مما يجعل ( النقطة المرسومة الأولى نقطة التحول للحالات، و ) التاريخ السببي للنقطة المرسومة يُستخدم لحساب سمعة القائد.
خط الإنتاج
V تربط الجولات بالقادة. يتم تشغيل Shoal مثيلًا بعد مثيل لـ Bullshark، بحيث يتم تحديد النقطة المرجعية مسبقًا لكل مثيل بواسطة الخريطة F. يطلب كل مثيل نقطة مرجعية، مما يؤدي إلى التبديل إلى المثيل التالي.
في البداية، أطلقت Shoal أول حالة من Bullshark في الجولة الأولى من DAG واستمرت في تشغيلها حتى تم تحديد أول نقطة ربط مرتبة، مثل الجولة r. اتفق جميع المدققين على هذه النقطة الربط. لذلك، يمكن لجميع المدققين أن يتفقوا بشكل مؤكد على إعادة تفسير DAG اعتباراً من الجولة r+1. فقط في الجولة r+1، أطلقت Shoal حالة جديدة من Bullshark.
في أفضل الأحوال، يسمح ذلك لشوول بطلب رصيف في كل جولة. يتم ترتيب نقاط الرصيف في الجولة الأولى حسب الحالة الأولى. ثم، يبدأ شوول حالة جديدة في الجولة الثانية، والتي تحتوي على نقطة رصيف، ويتم ترتيب هذه النقطة بواسطة تلك الحالة، ثم يتم طلب نقطة رصيف جديدة في الجولة الثالثة، ثم تستمر العملية.
سمعة القادة
عند تخطي نقاط الربط أثناء ترتيب Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، تكون تقنية خط الأنابيب عديمة الفائدة، لأنه لا يمكن بدء مثيل جديد قبل طلب نقطة الربط السابقة. يضمن Shoal من خلال استخدام آلية السمعة تخصيص نقاط لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة، مما يجعل من غير المحتمل اختيار القادة المقابلين في المستقبل لمعالجة نقاط الربط المفقودة. ستتلقى العقد التي تستجيب وتشارك في البروتوكول درجات عالية، بينما سيتم تخصيص درجات منخفضة لعقد التحقق الأخرى، لأنها قد تفشل أو تكون بطيئة أو تقوم بأفعال خبيثة.
فكرته هي إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع الميل نحو القادة ذوي النقاط الأعلى. لكي يتوصل المدققون إلى توافق في الخريطة الجديدة، ينبغي عليهم التوصل إلى توافق في النقاط، وبالتالي الوصول إلى توافق في التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن دمج خطوط الأنابيب وسمعة القيادة بشكل طبيعي، لأن كلاهما يستخدم نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الفرق الوحيد هو أنه بعد تصنيف النقاط المرجعية في الجولة r، يحتاج المُحققون فقط إلى حساب الخريطة الجديدة F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقد التحقق في تنفيذ مثيل جديد من Bullshark باستخدام وظيفة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
تلعب فترة الانتظار دورًا حاسمًا في جميع تطبيقات BFT المحددة في أجزاء التزامن المستندة إلى القائد. ومع ذلك، فإن التعقيد الناتج يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
سوف يزيد انتهاء الوقت بشكل ملحوظ وقت الإستجابة، لأنه من المهم تكوينها بشكل مناسب، وغالبًا ما تحتاج إلى تعديل ديناميكي، لأنها تعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع العقوبة الكاملة لتأخير انتهاء الوقت للقادة الذين يعانون من عطل. لذلك، لا ينبغي أن تكون إعدادات انتهاء الوقت متحفظة للغاية، ولكن إذا كان وقت انتهاء الوقت قصيرًا جدًا، فقد يتجاوز البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالي، كان القادة في Jolteon/Hotstuff مثقلين، وسبق أن انتهى الوقت قبل أن يحققوا تقدمًا.
للأسف، بناءً على بروتوكول الزعيم ( مثل Hotstuff و Jolteon) يتطلب أساسًا وقت الإستجابة، لضمان تقدم البروتوكول في كل مرة يفشل فيها الزعيم. إذا لم يكن هناك وقت الإستجابة، حتى الزعيم المتعطل قد يتوقف عن البروتوكول إلى الأبد. بسبب عدم القدرة على التمييز خلال الفترة غير المتزامنة.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 23
أعجبني
23
6
مشاركة
تعليق
0/400
VirtualRichDream
· 07-25 11:15
وقت الإستجابة降这么多 aptos要 للقمر了
شاهد النسخة الأصليةرد0
CoffeeNFTs
· 07-22 19:02
هذا الوقت الإستجابة اسقاط له طعم جيد.
شاهد النسخة الأصليةرد0
RugDocDetective
· 07-22 19:01
ما شاء الله، انتظرت طويلاً وأخيراً خرجت خطة Aptos
شاهد النسخة الأصليةرد0
RuntimeError
· 07-22 19:00
هل هذه الحيلة الجديدة لـ aptos تنجح أم لا؟
شاهد النسخة الأصليةرد0
UnluckyValidator
· 07-22 18:58
وقت الإستجابة العالية قد انتهت أخيراً بعد نصف عام من المعاناة
إطار Shoal اسقط وقت الإستجابة Bullshark داخل السلسلة Aptos بنسبة 40-80%
إطار Shoal: كيف يمكن اسقاط وقت الإستجابة لBullshark على Aptos؟
نظرة عامة
قامت مختبرات Aptos بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل كبير، ولأول مرة القضاء على الحاجة إلى انتهاء الوقت في البروتوكولات الحقيقية الحتمية. بشكل عام، تم تحسين وقت الإستجابة لبولشارك بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal من خلال خطوط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). تقوم خطوط الأنابيب بتقليل وقت الإستجابة من خلال إدخال نقطة ربط في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت من خلال ضمان ارتباط النقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي قد تتعرض لوقت الإستجابة. وهذا يمكّن Shoal من تقديم خاصية الاستجابة العالمية، والتي تتضمن الاستجابة المتفائلة المطلوبة عادة.
هذه التقنية بسيطة للغاية، حيث تتضمن تشغيل عدة أمثلة من البروتوكولات الأساسية بالتتابع. لذلك، عندما يتم تجسيدها باستخدام Bullshark، نحصل على مجموعة من "الأسماك" التي تتسابق في سباق التتابع.
الدافع
عند السعي نحو أداء عالٍ لشبكة البلوكشين، كان التركيز دائمًا على اسقاط تعقيد الاتصالات. ومع ذلك، لم تؤدِ هذه الطريقة إلى تحسين كبير في معدل النقل. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في النسخة المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
الاختراق الأخير ناتج عن إدراك أن انتشار البيانات هو العقبة الرئيسية التي تعتمد على بروتوكول القادة، ويمكن الاستفادة من التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن المنطق الأساسي للتوافق، ويقترح بنية يتم فيها نشر البيانات بواسطة جميع المدققين في نفس الوقت، بينما يقوم مكون التوافق بترتيب كمية صغيرة من البيانات الوصفية. تقرير ورقة Narwhal عن قدرة معالجة تصل إلى 160,000 TPS.
تمت الإشارة سابقًا إلى Quorum Store، الذي يفصل بين نشر البيانات والتوافق، وكيفية استخدامه لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير الرؤية على طراز PBFT، مما يقلل وقت الاستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، لا تستطيع بروتوكولات التوافق القائمة على القيادة الاستفادة الكاملة من إمكانيات إنتاجية Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن قادة Hotstuff/Jolteon لا يزالون مقيدين مع زيادة الإنتاجية.
لذلك، تم اتخاذ القرار بنشر Bullshark فوق Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو throughput عالي يأتي بتكلفة تأخير بنسبة 50٪.
تقدم هذه المقالة كيفية تقليل وقت الإستجابة 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 إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار الربط الديناميكي والحتمي هو أمر ضروري لحل الإجماع، ويجب على المصادقين التوصل إلى توافق بشأن التاريخ المنظم لاختيار الربط المستقبلي.
كأدلة على صعوبة المشكلة، فإن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
الاتفاقية
على الرغم من التحديات المذكورة أعلاه، إلا أن الحلول مخبأة وراء البساطة.
في Shoal، نعتمد على القدرة على تنفيذ الحسابات المحلية على DAG، ونحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على الرؤية الأساسية للنقطة المرسومة الأولى، يقوم Shoal بترتيب وتجميع عدة حالات من Bullshark لمعالجتها بشكل متسلسل، مما يجعل ( النقطة المرسومة الأولى نقطة التحول للحالات، و ) التاريخ السببي للنقطة المرسومة يُستخدم لحساب سمعة القائد.
خط الإنتاج
V تربط الجولات بالقادة. يتم تشغيل Shoal مثيلًا بعد مثيل لـ Bullshark، بحيث يتم تحديد النقطة المرجعية مسبقًا لكل مثيل بواسطة الخريطة F. يطلب كل مثيل نقطة مرجعية، مما يؤدي إلى التبديل إلى المثيل التالي.
في البداية، أطلقت Shoal أول حالة من Bullshark في الجولة الأولى من DAG واستمرت في تشغيلها حتى تم تحديد أول نقطة ربط مرتبة، مثل الجولة r. اتفق جميع المدققين على هذه النقطة الربط. لذلك، يمكن لجميع المدققين أن يتفقوا بشكل مؤكد على إعادة تفسير DAG اعتباراً من الجولة r+1. فقط في الجولة r+1، أطلقت Shoal حالة جديدة من Bullshark.
في أفضل الأحوال، يسمح ذلك لشوول بطلب رصيف في كل جولة. يتم ترتيب نقاط الرصيف في الجولة الأولى حسب الحالة الأولى. ثم، يبدأ شوول حالة جديدة في الجولة الثانية، والتي تحتوي على نقطة رصيف، ويتم ترتيب هذه النقطة بواسطة تلك الحالة، ثم يتم طلب نقطة رصيف جديدة في الجولة الثالثة، ثم تستمر العملية.
سمعة القادة
عند تخطي نقاط الربط أثناء ترتيب Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، تكون تقنية خط الأنابيب عديمة الفائدة، لأنه لا يمكن بدء مثيل جديد قبل طلب نقطة الربط السابقة. يضمن Shoal من خلال استخدام آلية السمعة تخصيص نقاط لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة، مما يجعل من غير المحتمل اختيار القادة المقابلين في المستقبل لمعالجة نقاط الربط المفقودة. ستتلقى العقد التي تستجيب وتشارك في البروتوكول درجات عالية، بينما سيتم تخصيص درجات منخفضة لعقد التحقق الأخرى، لأنها قد تفشل أو تكون بطيئة أو تقوم بأفعال خبيثة.
فكرته هي إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع الميل نحو القادة ذوي النقاط الأعلى. لكي يتوصل المدققون إلى توافق في الخريطة الجديدة، ينبغي عليهم التوصل إلى توافق في النقاط، وبالتالي الوصول إلى توافق في التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن دمج خطوط الأنابيب وسمعة القيادة بشكل طبيعي، لأن كلاهما يستخدم نفس التقنية الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الفرق الوحيد هو أنه بعد تصنيف النقاط المرجعية في الجولة r، يحتاج المُحققون فقط إلى حساب الخريطة الجديدة F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقد التحقق في تنفيذ مثيل جديد من Bullshark باستخدام وظيفة اختيار النقاط المرجعية المحدثة F' بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
تلعب فترة الانتظار دورًا حاسمًا في جميع تطبيقات BFT المحددة في أجزاء التزامن المستندة إلى القائد. ومع ذلك، فإن التعقيد الناتج يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
سوف يزيد انتهاء الوقت بشكل ملحوظ وقت الإستجابة، لأنه من المهم تكوينها بشكل مناسب، وغالبًا ما تحتاج إلى تعديل ديناميكي، لأنها تعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع العقوبة الكاملة لتأخير انتهاء الوقت للقادة الذين يعانون من عطل. لذلك، لا ينبغي أن تكون إعدادات انتهاء الوقت متحفظة للغاية، ولكن إذا كان وقت انتهاء الوقت قصيرًا جدًا، فقد يتجاوز البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل العالي، كان القادة في Jolteon/Hotstuff مثقلين، وسبق أن انتهى الوقت قبل أن يحققوا تقدمًا.
للأسف، بناءً على بروتوكول الزعيم ( مثل Hotstuff و Jolteon) يتطلب أساسًا وقت الإستجابة، لضمان تقدم البروتوكول في كل مرة يفشل فيها الزعيم. إذا لم يكن هناك وقت الإستجابة، حتى الزعيم المتعطل قد يتوقف عن البروتوكول إلى الأبد. بسبب عدم القدرة على التمييز خلال الفترة غير المتزامنة.