شرح إطار العمل Shoal: كيفية تقليل وقت الإستجابة في Bullshark على Aptos
نظرة عامة
قامت مختبرات Aptos بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما قلل بشكل كبير وقت الإستجابة، وأزال لأول مرة الحاجة إلى التوقف في البروتوكول العملي الحتمي. بشكل عام، تم تحسين تأخير Bullshark بنسبة 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، حيث تفصل تنفيذنا Narwhal بين نشر البيانات والإجماع، وكيفية استخدامه لتوسيع بروتوكول الإجماع الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه بوضوح الاستفادة الكاملة من إمكانيات إنتاجية Narwhal. على الرغم من فصل نشر البيانات عن الإجماع، لا يزال قائد Hotstuff/Jolteon مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark على Narwhal DAG، وهي بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن الهيكل DAG الذي يدعم Bullshark عالي الإنتاجية يأتي بتكلفة تأخير قدرها 50%.
تقدم هذه المقالة كيف يمكن لشوول تقليل وقت الإستجابة لبول شارك بشكل كبير.
خلفية 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 مشكلتين من مشكلات وقت الإستجابة، حيث عزز Bullshark( أو أي بروتوكول BFT قائم على Narwhal) من خلال خطوط الإنتاج، مما يسمح بوجود نقطة مرجعية في كل جولة، ويقلل من وقت الإستجابة لجميع الرؤوس غير المرجعية في DAG إلى ثلاث جولات. كما قدم Shoal آلية سمعة قادة بلا تكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر قضايا خط الأنابيب وسمعة القادة من المشاكل الصعبة، والأسباب كالتالي:
كانت خطوط الإنتاج السابقة تحاول تعديل منطق Bullshark الأساسي، ولكن يبدو أن هذا من المستحيل جوهريًا.
سمعة القائد تم تقديمها في DiemBFT وتوثيقها في Carousel، وهي فكرة اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المصادقين السابق. على الرغم من أن وجود خلافات في هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار العجلة بشكل ديناميكي وقطعي ضروري لحل الإجماع، ويحتاج المصادقون إلى التوصل إلى توافق بشأن التاريخ المنظم لاختيار العجلات المستقبلية.
كدليل على صعوبة المشكلة، لاحظنا أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحل مخفي في البساطة.
في Shoal، نعتمد على قدرة تنفيذ الحسابات المحلية على DAG، وحققنا القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المصدّقين على الرؤية الأساسية للنقطة المرسومة الأولى، يقوم Shoal بترتيب وتجميع عدة مثيلات من Bullshark لمعالجتها بشكل متسلسل، مما يجعل ( النقطة المرسومة الأولى هي نقطة التحول للمثيلات، وكذلك ) التاريخ السببي للنقاط المرسومة يُستخدم لحساب سمعة القائد.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
خط الأنابيب
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 مثقلين، وانتهى الوقت المستغرق قبل أن يدفعوا التقدم.
للأسف، فإن البروتوكولات المعتمدة على القادة ( مثل Hotstuff و Jolteon ) تتطلب بشكل أساسي وقت الإستجابة، لضمان تقدم البروتوكول في كل مرة يفشل فيها القائد. إذا لم يكن هناك وقت الإستجابة، حتى القائد المعطل أيضًا
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تحسين إطار Shoal وقت الإستجابة Bullshark داخل السلسلة Aptos بنسبة 40% دون أعطال
شرح إطار العمل Shoal: كيفية تقليل وقت الإستجابة في Bullshark على Aptos
نظرة عامة
قامت مختبرات Aptos بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما قلل بشكل كبير وقت الإستجابة، وأزال لأول مرة الحاجة إلى التوقف في البروتوكول العملي الحتمي. بشكل عام، تم تحسين تأخير Bullshark بنسبة 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، حيث تفصل تنفيذنا Narwhal بين نشر البيانات والإجماع، وكيفية استخدامه لتوسيع بروتوكول الإجماع الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه بوضوح الاستفادة الكاملة من إمكانيات إنتاجية Narwhal. على الرغم من فصل نشر البيانات عن الإجماع، لا يزال قائد Hotstuff/Jolteon مقيدًا مع زيادة الإنتاجية.
لذلك، قررنا نشر Bullshark على Narwhal DAG، وهي بروتوكول إجماع بدون تكلفة اتصالات. للأسف، مقارنةً بـ Jolteon، فإن الهيكل DAG الذي يدعم Bullshark عالي الإنتاجية يأتي بتكلفة تأخير قدرها 50%.
تقدم هذه المقالة كيف يمكن لشوول تقليل وقت الإستجابة لبول شارك بشكل كبير.
خلفية 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 مشكلتين من مشكلات وقت الإستجابة، حيث عزز Bullshark( أو أي بروتوكول BFT قائم على Narwhal) من خلال خطوط الإنتاج، مما يسمح بوجود نقطة مرجعية في كل جولة، ويقلل من وقت الإستجابة لجميع الرؤوس غير المرجعية في DAG إلى ثلاث جولات. كما قدم Shoal آلية سمعة قادة بلا تكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر قضايا خط الأنابيب وسمعة القادة من المشاكل الصعبة، والأسباب كالتالي:
كانت خطوط الإنتاج السابقة تحاول تعديل منطق Bullshark الأساسي، ولكن يبدو أن هذا من المستحيل جوهريًا.
سمعة القائد تم تقديمها في DiemBFT وتوثيقها في Carousel، وهي فكرة اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المصادقين السابق. على الرغم من أن وجود خلافات في هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي ذلك إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار العجلة بشكل ديناميكي وقطعي ضروري لحل الإجماع، ويحتاج المصادقون إلى التوصل إلى توافق بشأن التاريخ المنظم لاختيار العجلات المستقبلية.
كدليل على صعوبة المشكلة، لاحظنا أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
بروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحل مخفي في البساطة.
في Shoal، نعتمد على قدرة تنفيذ الحسابات المحلية على DAG، وحققنا القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المصدّقين على الرؤية الأساسية للنقطة المرسومة الأولى، يقوم Shoal بترتيب وتجميع عدة مثيلات من Bullshark لمعالجتها بشكل متسلسل، مما يجعل ( النقطة المرسومة الأولى هي نقطة التحول للمثيلات، وكذلك ) التاريخ السببي للنقاط المرسومة يُستخدم لحساب سمعة القائد.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
خط الأنابيب
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 مثقلين، وانتهى الوقت المستغرق قبل أن يدفعوا التقدم.
للأسف، فإن البروتوكولات المعتمدة على القادة ( مثل Hotstuff و Jolteon ) تتطلب بشكل أساسي وقت الإستجابة، لضمان تقدم البروتوكول في كل مرة يفشل فيها القائد. إذا لم يكن هناك وقت الإستجابة، حتى القائد المعطل أيضًا