إطار Shoal: كيف يمكن اسقاط وقت الإستجابة لـ Bullshark على Aptos؟
ملخص
حلت مختبرات Aptos مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى اسقاط وقت الإستجابة بشكل كبير، وألغت للمرة الأولى الحاجة إلى المهلة في بروتوكول فعلي حتمي. بشكل عام، تم تحسين وقت الاستجابة لبولشارك بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار يعزز بروتوكول الإجماع القائم على Narwhal باستخدام خط أنابيب وسمعة القادة ( مثل DAG-Rider وTusk وBullshark ). يعمل خط الأنابيب على تقليل وقت استجابة ترتيب DAG من خلال إدخال نقطة مرجعية في كل جولة، بينما تعزز سمعة القادة المشكلة من خلال ضمان ارتباط النقطة المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، يسمح سمعة القادة لـ 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٪.
تتناول هذه المقالة كيفية تحقيق Shoal انخفاض كبير في وقت الإستجابة Bullshark.
خلفية DAG-BFT
يرتبط كل رأس في Narwhal DAG بعدد من الدورات. لدخول الجولة r، يجب على المدقق أولاً الحصول على n-f رأسًا ينتمون إلى الجولة r-1. يمكن لكل مدقق في كل جولة بث رأس واحد، ويجب أن يشير كل رأس على الأقل إلى n-f رأسًا من الجولة السابقة. نظرًا للاختلاف في توقيت الشبكة، قد يلاحظ المدققون المختلفون في أي نقطة زمنية مشاهدات محلية مختلفة لـ DAG.
خاصية رئيسية لـ DAG هي عدم الغموض: إذا كانت لدى عقدتي التحقق اثنين وجهة نظر محلية في DAG تحتويان على نفس الرأس v، فإنهما تمتلكان تاريخ السبب 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: كيف يمكن تقليل وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
بروتوكول
على الرغم من التحديات المذكورة أعلاه، كما تقول الحكمة، فإن الحلول مخفية في البساطة.
في Shoal، نعتمد على القدرة على تنفيذ حسابات محلية على DAG، ونحقق قدرة حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على الرؤية الأساسية للنقطة المرسومة الأولى، يقوم Shoal بترتيب وتجميع عدة أمثلة من Bullshark ومعالجتها بشكل متسلسل، بحيث تكون ) النقطة المرسومة الأولى هي نقطة التحول للأمثلة، وكذلك ( التاريخ السببي للنقاط المرسومة المستخدمة في حساب سمعة القائد.
خط التجميع
مثل Bullshark، يتفق المدققون مسبقًا على النقاط المرجعية المحتملة، أي أن هناك تطابقًا معروفًا F: R -\u003e 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-859e732e16c3eee0e2c93422474debc2.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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
لا مزيد من وقت الإستجابة
تلعب المهلة دورًا حيويًا في جميع تطبيقات BFT القابلة للتحديد القائمة على القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب المزيد من تقنيات المراقبة.
سوف يزيد وقت الإستجابة بشكل ملحوظ أيضًا، لأن تكوينها بشكل صحيح أمر بالغ الأهمية، وغالبًا ما يحتاج إلى تعديل ديناميكي، لأنه يعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع عقوبة وقت الإستجابة الكامل للقائد المعطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة متحفظة جدًا، ولكن إذا
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
6
إعادة النشر
مشاركة
تعليق
0/400
SlowLearnerWang
· منذ 16 س
وقت الإستجابة انخفض 40%... هذا الخطأ تم إصلاحه بشكل ثور جداً؟
شاهد النسخة الأصليةرد0
NFTArchaeologis
· منذ 16 س
كما أن النقوش على عظام الحيوانات محفورة في علامات السلسلة الرقمية، فإن إطار شوال يبتكر عند التلوث.
شاهد النسخة الأصليةرد0
PumpDetector
· منذ 16 س
همم، ثور القرش يزداد سرعة ولكن لا يزال يقرأ بين السطور... هناك شيء يبدو غير طبيعي بصراحة
تحسين إطار Shoal للإجماع Aptos مما يؤدي إلى اسقاط كبير في وقت الإستجابة Bullshark
إطار Shoal: كيف يمكن اسقاط وقت الإستجابة لـ Bullshark على Aptos؟
ملخص
حلت مختبرات Aptos مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى اسقاط وقت الإستجابة بشكل كبير، وألغت للمرة الأولى الحاجة إلى المهلة في بروتوكول فعلي حتمي. بشكل عام، تم تحسين وقت الاستجابة لبولشارك بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار يعزز بروتوكول الإجماع القائم على Narwhal باستخدام خط أنابيب وسمعة القادة ( مثل DAG-Rider وTusk وBullshark ). يعمل خط الأنابيب على تقليل وقت استجابة ترتيب DAG من خلال إدخال نقطة مرجعية في كل جولة، بينما تعزز سمعة القادة المشكلة من خلال ضمان ارتباط النقطة المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، يسمح سمعة القادة لـ 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٪.
تتناول هذه المقالة كيفية تحقيق Shoal انخفاض كبير في وقت الإستجابة Bullshark.
خلفية DAG-BFT
يرتبط كل رأس في Narwhal DAG بعدد من الدورات. لدخول الجولة r، يجب على المدقق أولاً الحصول على n-f رأسًا ينتمون إلى الجولة r-1. يمكن لكل مدقق في كل جولة بث رأس واحد، ويجب أن يشير كل رأس على الأقل إلى n-f رأسًا من الجولة السابقة. نظرًا للاختلاف في توقيت الشبكة، قد يلاحظ المدققون المختلفون في أي نقطة زمنية مشاهدات محلية مختلفة لـ DAG.
خاصية رئيسية لـ DAG هي عدم الغموض: إذا كانت لدى عقدتي التحقق اثنين وجهة نظر محلية في DAG تحتويان على نفس الرأس v، فإنهما تمتلكان تاريخ السبب 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: كيف يمكن تقليل وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
بروتوكول
على الرغم من التحديات المذكورة أعلاه، كما تقول الحكمة، فإن الحلول مخفية في البساطة.
في Shoal، نعتمد على القدرة على تنفيذ حسابات محلية على DAG، ونحقق قدرة حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على الرؤية الأساسية للنقطة المرسومة الأولى، يقوم Shoal بترتيب وتجميع عدة أمثلة من Bullshark ومعالجتها بشكل متسلسل، بحيث تكون ) النقطة المرسومة الأولى هي نقطة التحول للأمثلة، وكذلك ( التاريخ السببي للنقاط المرسومة المستخدمة في حساب سمعة القائد.
خط التجميع
مثل Bullshark، يتفق المدققون مسبقًا على النقاط المرجعية المحتملة، أي أن هناك تطابقًا معروفًا F: R -\u003e 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-859e732e16c3eee0e2c93422474debc2.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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
لا مزيد من وقت الإستجابة
تلعب المهلة دورًا حيويًا في جميع تطبيقات BFT القابلة للتحديد القائمة على القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب المزيد من تقنيات المراقبة.
سوف يزيد وقت الإستجابة بشكل ملحوظ أيضًا، لأن تكوينها بشكل صحيح أمر بالغ الأهمية، وغالبًا ما يحتاج إلى تعديل ديناميكي، لأنه يعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، سيقوم البروتوكول بدفع عقوبة وقت الإستجابة الكامل للقائد المعطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة متحفظة جدًا، ولكن إذا