إطار Shoal: كيفية تقليل وقت الإستجابة في Bullshark على Aptos
نظرة عامة
Aptos Labs حلت مشكلتين مفتوحتين مهمتين في 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 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 تتمتع بالهيكل التالي:
نقطة الربط المحددة مسبقاً: سيكون هناك قائد محدد مسبقاً بعد عدة جولات، وذروة القائد تُسمى نقطة الربط؛
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يجب ترتيبها وأي النقاط يجب تخطيها;
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة الخاصة بهم واحدًا تلو الآخر، وترتيب جميع الرؤوس غير المرتبة السابقة في تاريخ كل نقطة ربط.
الشرط الأساسي لضمان الأمان هو التأكد من أنه في الخطوة (2)، يقوم جميع عقد التحقق الأمينة بإنشاء قائمة نقاط ربط مرتبة، بحيث تشترك جميع القوائم في نفس البادئة. في شوال، تم إجراء الملاحظات التالية على جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
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: كيف تقلل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
بروتوكول
في 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
سمعة القادة
عند تخطي النقاط المرجعية خلال فرز Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، تكون تقنية خط الأنابيب عديمة الجدوى، لأنه لا يمكن بدء مثيل جديد قبل أن يتم طلب النقاط المرجعية في المثيل السابق. تضمن Shoal من خلال استخدام آلية السمعة أن يتم تخصيص درجة لكل عقدة تحقيف بناءً على التاريخ النشط الأخير لكل عقدة تحقيف، مما يجعل من غير المحتمل اختيار القادة المعنيين في المستقبل لمعالجة النقاط المرجعية المفقودة. سيحصل المحققون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا، سيتم تخصيص درجات منخفضة لعقد التحقيقت، لأنها قد تتعطل أو تكون بطيئة أو تتصرف بشكل سيء.
فكرته هي إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النتيجة، مع تفضيل القائد الذي لديه درجة أعلى. لكي يتوصل المدققون إلى توافق بشأن الخريطة الجديدة، يجب عليهم التوصل إلى توافق بشأن النتيجة، وبالتالي تحقيق توافق حول التاريخ المستخدم لتوليد النتيجة.
في Shoal، يمكن دمج خط الأنابيب وسمعة القيادة بشكل طبيعي، لأنهما يستخدمان نفس التكنولوجيا الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد فرز النقاط المرجعية في الجولة r، يحتاج المُصادقون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، تبدأ عقد المُصادقين في تنفيذ مثال جديد لـ Bullshark باستخدام دالة اختيار النقاط المرجعية المُحدثة F' بدءًا من الجولة r+1.
![شرح مفصل حول إطار Shoal: كيف نقلل من وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
لا مزيد من وقت الإستجابة
تلعب المهلة دورًا حيويًا في جميع تطبيقات BFT المتزامنة القابلة للتحديد المعتمدة على الزعيم. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب تقنيات مراقبة إضافية.
سيؤدي الوقت المستغرق أيضًا إلى زيادة وقت الإستجابة بشكل ملحوظ، لأنه من المهم تكوينها بشكل مناسب وغالبًا ما تحتاج إلى ضبط ديناميكي، حيث تعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، يدفع البروتوكول عقوبة الوقت المستغرق الكامل للقائد المعطل. لذلك، لا يمكن أن تكون إعدادات الوقت المستغرق متحفظة للغاية، ولكن إذا كان وقت الاستجابة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، نلاحظ
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
إطار Shoal أسقط وقت الإستجابة للإجماع Bullshark على Aptos بنسبة 40%-80%
إطار Shoal: كيفية تقليل وقت الإستجابة في Bullshark على Aptos
نظرة عامة
Aptos Labs حلت مشكلتين مفتوحتين مهمتين في 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 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 تتمتع بالهيكل التالي:
نقطة الربط المحددة مسبقاً: سيكون هناك قائد محدد مسبقاً بعد عدة جولات، وذروة القائد تُسمى نقطة الربط؛
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يجب ترتيبها وأي النقاط يجب تخطيها;
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة الخاصة بهم واحدًا تلو الآخر، وترتيب جميع الرؤوس غير المرتبة السابقة في تاريخ كل نقطة ربط.
الشرط الأساسي لضمان الأمان هو التأكد من أنه في الخطوة (2)، يقوم جميع عقد التحقق الأمينة بإنشاء قائمة نقاط ربط مرتبة، بحيث تشترك جميع القوائم في نفس البادئة. في شوال، تم إجراء الملاحظات التالية على جميع البروتوكولات المذكورة أعلاه:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
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: كيف تقلل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
بروتوكول
في 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
سمعة القادة
عند تخطي النقاط المرجعية خلال فرز Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، تكون تقنية خط الأنابيب عديمة الجدوى، لأنه لا يمكن بدء مثيل جديد قبل أن يتم طلب النقاط المرجعية في المثيل السابق. تضمن Shoal من خلال استخدام آلية السمعة أن يتم تخصيص درجة لكل عقدة تحقيف بناءً على التاريخ النشط الأخير لكل عقدة تحقيف، مما يجعل من غير المحتمل اختيار القادة المعنيين في المستقبل لمعالجة النقاط المرجعية المفقودة. سيحصل المحققون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا، سيتم تخصيص درجات منخفضة لعقد التحقيقت، لأنها قد تتعطل أو تكون بطيئة أو تتصرف بشكل سيء.
فكرته هي إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النتيجة، مع تفضيل القائد الذي لديه درجة أعلى. لكي يتوصل المدققون إلى توافق بشأن الخريطة الجديدة، يجب عليهم التوصل إلى توافق بشأن النتيجة، وبالتالي تحقيق توافق حول التاريخ المستخدم لتوليد النتيجة.
في Shoal، يمكن دمج خط الأنابيب وسمعة القيادة بشكل طبيعي، لأنهما يستخدمان نفس التكنولوجيا الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد فرز النقاط المرجعية في الجولة r، يحتاج المُصادقون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 بناءً على التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، تبدأ عقد المُصادقين في تنفيذ مثال جديد لـ Bullshark باستخدام دالة اختيار النقاط المرجعية المُحدثة F' بدءًا من الجولة r+1.
![شرح مفصل حول إطار Shoal: كيف نقلل من وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
لا مزيد من وقت الإستجابة
تلعب المهلة دورًا حيويًا في جميع تطبيقات BFT المتزامنة القابلة للتحديد المعتمدة على الزعيم. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب تقنيات مراقبة إضافية.
سيؤدي الوقت المستغرق أيضًا إلى زيادة وقت الإستجابة بشكل ملحوظ، لأنه من المهم تكوينها بشكل مناسب وغالبًا ما تحتاج إلى ضبط ديناميكي، حيث تعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، يدفع البروتوكول عقوبة الوقت المستغرق الكامل للقائد المعطل. لذلك، لا يمكن أن تكون إعدادات الوقت المستغرق متحفظة للغاية، ولكن إذا كان وقت الاستجابة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، نلاحظ