تحليل إطار Shoal: اسقاط كبير لوقت الإستجابة Bullshark على Aptos
قامت Aptos Labs مؤخرًا بحل مشكلتين رئيسيتين في DAG BFT، مما أدى إلى إسقاط وقت الإستجابة بشكل ملحوظ، وألغت لأول مرة الحاجة إلى الوقت المستغرق في البروتوكولات الزمنية الحتمية. بشكل عام، تحسن وقت الإستجابة لبولشارك بنسبة 40٪ في حالة عدم وجود أعطال، و80٪ في حالة وجود أعطال.
Shoal هو إطار عمل يعزز بروتوكول الإجماع القائم على Narwhal من خلال آلية خط الأنابيب وسمعة القائد ( مثل DAG-Rider و Tusk و Bullshark ). يعمل خط الأنابيب على تقليل وقت الإستجابة لترتيب DAG من خلال إدخال نقاط مرجعية في كل جولة، بينما تعمل سمعة القائد على تحسين الوقت من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد تحقق. بالإضافة إلى ذلك، تسمح سمعة القائد لشوول باستغلال البناء غير المتزامن لـ DAG للقضاء على الوقت المستغرق في جميع السيناريوهات. هذا يمنح Shoal استجابة عامة، بما في ذلك الاستجابة المتفائلة التي عادة ما تكون مطلوبة.
هذه التقنية بسيطة جدًا، وتتعلق بتشغيل عدة نسخ من البروتوكولات الأساسية بالترتيب. استخدام Bullshark للتجسيد يعادل مجموعة من "الأسماك القرش" في سباق التتابع.
الخلفية والدافع
في السعي لتحقيق أداء عالي لشبكة blockchain، كانت تقليل تعقيد الاتصالات دائمًا محور التركيز. ومع ذلك، لم تؤدي هذه الطريقة إلى تحسين كبير في معدل نقل البيانات. على سبيل المثال، لم تحقق Hotstuff التي تم تنفيذها في Diem المبكر سوى 3500 TPS، وهو أقل بكثير من الهدف البالغ 100000+ TPS.
الاختراق الأخير ناتج عن إدراك أن انتشار البيانات هو العائق الرئيسي القائم على بروتوكول القادة، ويمكن الاستفادة من التوازي. يفصل نظام Narwhal بين انتشار البيانات والمنطق الأساسي للتوافق، ويقترح هيكلًا حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما تقوم مكونات التوافق بترتيب كمية صغيرة من البيانات الوصفية فقط. تقرير ورقة Narwhal يشير إلى قدرة معالجة تصل إلى 160,000 TPS.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ Narwhal، الذي يفصل بين انتشار البيانات والإجماع، لغرض توسيع بروتوكول الإجماع الحالي Jolteon. يجمع Jolteon بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه الاستفادة الكاملة من إمكانات الإنتاجية لـ Narwhal.
لذلك، قررت Aptos نشر Bullshark، بروتوكول إجماع بدون تكلفة اتصالات على Narwhal DAG. ومع ذلك، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو القدرة العالية على الإنتاجية يأتي مع تكلفة تأخير بنسبة 50٪.
تم تصميم إطار Shoal لتقليل وقت الإستجابة لـ Bullshark بشكل كبير.
خلفية DAG-BFT
في DAG الخاص بـ Narwhal، يرتبط كل رأس بعدد من الدورات. عند الدخول إلى الدورة رقم r، يجب على المدققين أولاً الحصول على n-f من الرؤوس في الدورة رقم r-1. يمكن لكل مدقق بث رأس واحد في كل دورة، ويجب أن يشير كل رأس على الأقل إلى n-f من الرؤوس في الدورة السابقة. بسبب عدم التزامن في الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي وقت.
خاصية رئيسية لشجرة DAG هي عدم الغموض: إذا كان لدى عقدتي التحقق المحليتين عرض DAG نفسه بنفس الرأس v، فإنهما تمتلكان نفس التاريخ السببي الكامل لـ v.
ترتيب الفهرس
يمكن تحقيق التوافق على الترتيب الكلي لجميع الرؤوس في DAG دون أي تكلفة اتصال إضافية. لهذا، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG كنوع من بروتوكول الإجماع، حيث تمثل الرؤوس الاقتراحات، وتمثل الحواف الأصوات.
جميع بروتوكولات التوافق المستندة إلى Narwhal لها الهيكل التالي:
نقطة الربط المحددة مسبقًا: يتم تعيين قائد محدد مسبقًا كل عدة جولات، وتسمى قمته نقطة الربط.
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يجب ترتيبها وأي النقاط يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسومة بالترتيب، ويقومون بترتيب الرؤوس غير المرتبة السابقة في التاريخ السببي لكل نقطة مرسومة.
المفتاح إلى الأمان هو التأكد من أن جميع قوائم نقاط التثبيت المرتبة التي أنشأتها عقد التحقق الأمينة تشترك في نفس البادئة في الخطوة (2). لوحظ في Shoal: جميع المدققين اتفقوا على أول نقطة تثبيت مرتبة.
Bullshark وقت الإستجابة
يعتمد وقت الإستجابة لBullshark على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن بعض إصدارات Bullshark المتزامنة لديها وقت إستجابة أفضل من الإصدارات غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
هناك مشكلتان رئيسيتان:
متوسط وقت الإستجابة للكتل: في الحالات الشائعة، تحتاج قمة الدورة الفردية إلى ثلاث دورات، وتحتاج قمة الدورة الزوجية غير المربوطة إلى أربع دورات لترتيبها.
حالات الخلل وقت الإستجابة: إذا فشل أحد القادة في بث النقاط المرجعية في الوقت المناسب، مما أدى إلى عدم إمكانية ترتيب النقاط المرجعية وتخطيها، يجب على القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. هذا يخفض بشكل كبير من أداء شبكة النسخ الجغرافية.
إطار Shoal
يعمل Shoal على تعزيز Bullshark( أو أي بروتوكول BFT قائم على Narwhal) من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، لتقليل وقت الاستجابة لجميع الرؤوس غير المرتبطة في DAG إلى ثلاث جولات. كما يقدم Shoal آلية سمعة قادة بدون تكلفة في DAG، تميل لاختيار القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر خطوط الأنابيب وسمعة القائد من القضايا الصعبة:
كانت المحاولة السابقة لتعديل منطق Bullshark الأساسي في خط التجميع، لكن يبدو أن هذا غير ممكن في جوهره.
تم إدخال سمعة القائد في DiemBFT، وتم توثيقها في Carousel، ويتم اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المُصادقين في الماضي (. على الرغم من أن اختلاف هوية القائد لا ينتهك الأمان، إلا أنه قد يؤدي إلى ترتيب مختلف تمامًا في Bullshark.
تسببت هذه التحديات في عدم دعم تنفيذ Bullshark الحالي في بيئة الإنتاج لهذه الميزات.
) بروتوكول
تعتمد Shoal على القدرة على تنفيذ الحسابات المحلية على DAG، مما يتيح حفظ وإعادة تفسير المعلومات من الجولات السابقة. بناءً على توافق جميع المدققين على رؤية النقطة المرسومة الأولى، تقوم Shoal بترتيب مجموعة من مثيلات Bullshark المتعددة للمعالجة المتسلسلة، مما يجعل:
النقطة المرسومة الأولى هي نقطة تبديل المثيل
تاريخ السبب والنتيجة للنقطة المرجعية يُستخدم في حساب سمعة القادة
خط الإنتاج
V تربط الدور بالزعيم. تعمل Shoal على تشغيل مثيلات Bullshark بشكل متتابع، حيث يتم تحديد نقطة ربط كل مثيل مسبقًا بواسطة الخريطة F. يقوم كل مثيل بترتيب نقطة ربط، مما يؤدي إلى الانتقال إلى المثيل التالي.
بدأ Shoal في الجولة الأولى من DAG بإطلاق أول نموذج Bullshark، وتم تشغيله حتى تم تحديد أول نقطة ربط مرتبة ###، على افتراض أنها في الجولة r (. وافق جميع المدققين على هذه النقطة، وبالتالي يمكنهم بشكل قاطع الاتفاق على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal نموذج Bullshark جديد في الجولة r+1.
في الحالة المثالية، يسمح هذا لـ Shoal بترتيب نقطة مرجعية واحدة في كل جولة. يتم ترتيب نقطة المرجعية الأولى بواسطة المثال الأول، ثم يبدأ Shoal في الجولة الثانية بمثال جديد، ويرتب نقطة المرجعية لتلك الجولة، وهكذا.
![شرح شامل لإطار Shoal: كيف تقلل من وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
)# سمعة القادة
عندما تتخطى عملية ترتيب Bullshark النقاط المرجعية، فإن وقت الإستجابة سيزداد. في هذه الحالة، فإن تقنية خط الأنابيب غير فعالة، لأنه لا يمكن بدء مثيل جديد قبل ترتيب النقطة المرجعية للمثيل السابق. تقوم Shoal بتخصيص درجات لكل عقدة تحقق من خلال آلية سمعة، لضمان أنه من غير المرجح اختيار القادة البطيئين المعنيين في المستقبل بناءً على تاريخ النشاط الأخير. يحصل المراقبون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا يتم تخصيص درجات منخفضة.
عند تحديث النتيجة في كل مرة، يتم إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي، مع التركيز على القادة ذوي النقاط العالية. لكي يتفق المصدقون على الخريطة الجديدة، يحتاجون إلى التوصل إلى توافق في النقاط، وبالتالي التوصل إلى توافق في التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يجتمع خط الأنابيب وسمعة القيادة بشكل طبيعي، لأنهما يستخدمان نفس التقنية الأساسية: إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
الفرق الوحيد هو أنه بعد ترتيب نقاط الربط في الجولة r، يقوم المدققون بحساب التعيين الجديد F' بدءًا من الجولة r+1 فقط بناءً على التاريخ السببي لنقاط الربط المرتبة في الجولة r. ثم تبدأ عقد المدققين في استخدام دالة اختيار نقاط الربط المحدثة F' لتنفيذ مثيل Bullshark الجديد بدءًا من الجولة r+1.
إزالة وقت الإستجابة
تعتبر المهلة عاملًا حاسمًا في جميع تنفيذات BFT المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد تصحيح الأخطاء ويحتاج إلى المزيد من تقنيات المراقبة.
تزيد المهلة بشكل ملحوظ من وقت الإستجابة، لأن تكوين المهلة بشكل مناسب أمر مهم، وعادة ما يحتاج إلى تعديل ديناميكي، ويعتمد بشكل كبير على البيئة ### الشبكة (. قبل الانتقال إلى القائد التالي، ستدفع البروتوكول العقوبة الكاملة لوقت الإستجابة للزعيم المعطل. لذلك، لا يمكن أن تكون إعدادات المهلة متحفظة للغاية، ولكن إذا كانت قصيرة جداً، قد يتجاوز البروتوكول الزعماء الجيدين.
لسوء الحظ، فإن بروتوكول القائد ) مثل Hotstuff و Jolteon ( يتطلب بشكل جوهري وقت الإستجابة لضمان تقدم البروتوكول في كل مرة يتعطل فيها القائد. بدون وقت الإستجابة، حتى القائد المتعطل قد يتسبب في توقف البروتوكول إلى الأبد. نظرًا لعدم القدرة على تمييز القادة المتعطلين عن القادة البطيئين خلال الفترة غير المتزامنة، قد يؤدي وقت الإستجابة إلى دوران جميع القادة دون وجود نشاط توافق.
في Bullshark، يتم استخدام وقت الإستجابة لبناء DAG، لضمان أن القادة الأمينين يضيفون النقاط المرجعية إلى DAG بسرعة كافية أثناء التزامن.
تلاحظ Shoal أن بنية DAG توفر "ساعة" لتقدير سرعة الشبكة. في غياب التوقف، طالما أن n-f من المدققين الشرفاء يستمرون في إضافة القمم إلى DAG، ستستمر الجولات في التقدم. على الرغم من أن Bullshark قد لا يتمكن من ترتيب ) بسرعة الشبكة بسبب مشكلة القائد (، إلا أن DAG لا يزال ينمو بسرعة الشبكة، على الرغم من وجود بعض المشكلات في القادة أو الشبكة غير المتزامنة. في النهاية، عندما يقوم القادة بدون عطل ببث النقاط المرجعية بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل للنقاط المرجعية.
في Shoal، تجنب انتهاء الوقت مرتبط ارتباطاً وثيقاً بسمعة القائد. الانتظار المتكرر لقادة بطيئين سيزيد من وقت الإستجابة، وآلية سمعة القائد تستبعد المُحققين البطيئين من أن يتم اختيارهم كقادة. بهذه الطريقة، يستفيد النظام من عقد التحقق السريعة لتعمل بسرعة الشبكة في جميع السيناريوهات الواقعية.
يجب ملاحظة أن نتائج عدم إمكانية FLP تشير إلى أنه لا يمكن لأي بروتوكول توافق حتمي تجنب وقت الإستجابة. لا يمكن لـ Shoal تجنب هذه النتيجة، لأنه يوجد جدول زمني نظري للأحداث المتعارضة يمكن أن يمنع ترتيب جميع المراسي. على العكس من ذلك، بعد عدد قابل للتكوين من تخطي المراسي، سيعود Shoal إلى وقت الإستجابة. في الواقع، من غير المحتمل للغاية أن يحدث هذا.
![شرح مفصل لإطار Shoal: كيف يمكن اسقاط وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) استجابة عامة
أوراق Hotstuff شاعت مفهوم الاستجابة المتفائلة، وعلى الرغم من أنها لم تُعرّف بشكل رسمي، إلا أنها تعني بديهيًا أن البروتوكول يمكن أن يعمل بسرعة الشبكة تحت ظروف جيدة ### مع قائد سريع وشبكة متزامنة (.
يقدم Shoal خصائص أفضل تُعرف باسم الاستجابة العامة. على وجه التحديد، مقارنةً بـ Hotstuff، فإن Shoal سيستمر في العمل بسرعة الشبكة حتى في حالة فشل القائد خلال عدد متواصل قابل للتكوين من الجولات أو عندما تمر الشبكة بفترات غير متزامنة.
توفر الاستجابة العامة ضمانات تقدم أفضل بكثير خلال الفترات غير المتزامنة وعند فشل القائد. خلال فترة التزامن مع القائد البطيء، لا يمكن مقارنة هذه الخصائص، لأن ذلك يعتمد على مدى بطء القائد. ومع ذلك، بالنظر إلى سمعة القائد، يجب أن يكون هناك ندرة في القادة البطيئين في Shoal.
تقييم
أبتوس نفذت بول شارك وشول فوق مخزن الكوروم في ناروال. فيما يلي بعض النقاط البارزة للتقييم:
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 18
أعجبني
18
7
مشاركة
تعليق
0/400
OnchainFortuneTeller
· 07-12 17:39
يبدو أن السوق الصاعدة APT قادمة~
شاهد النسخة الأصليةرد0
AirdropSkeptic
· 07-10 22:26
ووه~ رائع! تسارعت كثيرًا
شاهد النسخة الأصليةرد0
UnluckyLemur
· 07-10 03:40
أبتوس دائمًا ما يبدع في بعض الحيل
شاهد النسخة الأصليةرد0
ZkSnarker
· 07-10 03:39
حسناً، تقنياً، أصبح ثور القرش أكثر إثارة بكثير...
شاهد النسخة الأصليةرد0
SmartMoneyWallet
· 07-10 03:36
زيادة السرعة بنسبة 80%؟ البيانات مضللة، داخل السلسلة TPS لم يتغير على الإطلاق
إطار Shoal يقلل بشكل كبير من وقت الإستجابة لنموذج Aptos Bullshark لتحقيق استجابة عامة
تحليل إطار Shoal: اسقاط كبير لوقت الإستجابة Bullshark على Aptos
قامت Aptos Labs مؤخرًا بحل مشكلتين رئيسيتين في DAG BFT، مما أدى إلى إسقاط وقت الإستجابة بشكل ملحوظ، وألغت لأول مرة الحاجة إلى الوقت المستغرق في البروتوكولات الزمنية الحتمية. بشكل عام، تحسن وقت الإستجابة لبولشارك بنسبة 40٪ في حالة عدم وجود أعطال، و80٪ في حالة وجود أعطال.
Shoal هو إطار عمل يعزز بروتوكول الإجماع القائم على Narwhal من خلال آلية خط الأنابيب وسمعة القائد ( مثل DAG-Rider و Tusk و Bullshark ). يعمل خط الأنابيب على تقليل وقت الإستجابة لترتيب DAG من خلال إدخال نقاط مرجعية في كل جولة، بينما تعمل سمعة القائد على تحسين الوقت من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد تحقق. بالإضافة إلى ذلك، تسمح سمعة القائد لشوول باستغلال البناء غير المتزامن لـ DAG للقضاء على الوقت المستغرق في جميع السيناريوهات. هذا يمنح Shoal استجابة عامة، بما في ذلك الاستجابة المتفائلة التي عادة ما تكون مطلوبة.
هذه التقنية بسيطة جدًا، وتتعلق بتشغيل عدة نسخ من البروتوكولات الأساسية بالترتيب. استخدام Bullshark للتجسيد يعادل مجموعة من "الأسماك القرش" في سباق التتابع.
الخلفية والدافع
في السعي لتحقيق أداء عالي لشبكة blockchain، كانت تقليل تعقيد الاتصالات دائمًا محور التركيز. ومع ذلك، لم تؤدي هذه الطريقة إلى تحسين كبير في معدل نقل البيانات. على سبيل المثال، لم تحقق Hotstuff التي تم تنفيذها في Diem المبكر سوى 3500 TPS، وهو أقل بكثير من الهدف البالغ 100000+ TPS.
الاختراق الأخير ناتج عن إدراك أن انتشار البيانات هو العائق الرئيسي القائم على بروتوكول القادة، ويمكن الاستفادة من التوازي. يفصل نظام Narwhal بين انتشار البيانات والمنطق الأساسي للتوافق، ويقترح هيكلًا حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما تقوم مكونات التوافق بترتيب كمية صغيرة من البيانات الوصفية فقط. تقرير ورقة Narwhal يشير إلى قدرة معالجة تصل إلى 160,000 TPS.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ Narwhal، الذي يفصل بين انتشار البيانات والإجماع، لغرض توسيع بروتوكول الإجماع الحالي Jolteon. يجمع Jolteon بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه الاستفادة الكاملة من إمكانات الإنتاجية لـ Narwhal.
لذلك، قررت Aptos نشر Bullshark، بروتوكول إجماع بدون تكلفة اتصالات على Narwhal DAG. ومع ذلك، مقارنةً بـ Jolteon، فإن هيكل DAG الذي يدعم Bullshark ذو القدرة العالية على الإنتاجية يأتي مع تكلفة تأخير بنسبة 50٪.
تم تصميم إطار Shoal لتقليل وقت الإستجابة لـ Bullshark بشكل كبير.
خلفية DAG-BFT
في DAG الخاص بـ Narwhal، يرتبط كل رأس بعدد من الدورات. عند الدخول إلى الدورة رقم r، يجب على المدققين أولاً الحصول على n-f من الرؤوس في الدورة رقم r-1. يمكن لكل مدقق بث رأس واحد في كل دورة، ويجب أن يشير كل رأس على الأقل إلى n-f من الرؤوس في الدورة السابقة. بسبب عدم التزامن في الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي وقت.
خاصية رئيسية لشجرة DAG هي عدم الغموض: إذا كان لدى عقدتي التحقق المحليتين عرض DAG نفسه بنفس الرأس v، فإنهما تمتلكان نفس التاريخ السببي الكامل لـ v.
ترتيب الفهرس
يمكن تحقيق التوافق على الترتيب الكلي لجميع الرؤوس في DAG دون أي تكلفة اتصال إضافية. لهذا، يفسر المدققون في DAG-Rider وTusk وBullshark بنية DAG كنوع من بروتوكول الإجماع، حيث تمثل الرؤوس الاقتراحات، وتمثل الحواف الأصوات.
جميع بروتوكولات التوافق المستندة إلى Narwhal لها الهيكل التالي:
نقطة الربط المحددة مسبقًا: يتم تعيين قائد محدد مسبقًا كل عدة جولات، وتسمى قمته نقطة الربط.
نقاط الترتيب: يقرر المدققون بشكل مستقل ولكن حتمي أي النقاط يجب ترتيبها وأي النقاط يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسومة بالترتيب، ويقومون بترتيب الرؤوس غير المرتبة السابقة في التاريخ السببي لكل نقطة مرسومة.
المفتاح إلى الأمان هو التأكد من أن جميع قوائم نقاط التثبيت المرتبة التي أنشأتها عقد التحقق الأمينة تشترك في نفس البادئة في الخطوة (2). لوحظ في Shoal: جميع المدققين اتفقوا على أول نقطة تثبيت مرتبة.
Bullshark وقت الإستجابة
يعتمد وقت الإستجابة لBullshark على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن بعض إصدارات Bullshark المتزامنة لديها وقت إستجابة أفضل من الإصدارات غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
هناك مشكلتان رئيسيتان:
متوسط وقت الإستجابة للكتل: في الحالات الشائعة، تحتاج قمة الدورة الفردية إلى ثلاث دورات، وتحتاج قمة الدورة الزوجية غير المربوطة إلى أربع دورات لترتيبها.
حالات الخلل وقت الإستجابة: إذا فشل أحد القادة في بث النقاط المرجعية في الوقت المناسب، مما أدى إلى عدم إمكانية ترتيب النقاط المرجعية وتخطيها، يجب على القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. هذا يخفض بشكل كبير من أداء شبكة النسخ الجغرافية.
إطار Shoal
يعمل Shoal على تعزيز Bullshark( أو أي بروتوكول BFT قائم على Narwhal) من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، لتقليل وقت الاستجابة لجميع الرؤوس غير المرتبطة في DAG إلى ثلاث جولات. كما يقدم Shoal آلية سمعة قادة بدون تكلفة في DAG، تميل لاختيار القادة السريعين.
التحدي
في سياق بروتوكول DAG، تعتبر خطوط الأنابيب وسمعة القائد من القضايا الصعبة:
كانت المحاولة السابقة لتعديل منطق Bullshark الأساسي في خط التجميع، لكن يبدو أن هذا غير ممكن في جوهره.
تم إدخال سمعة القائد في DiemBFT، وتم توثيقها في Carousel، ويتم اختيار القادة المستقبليين بشكل ديناميكي بناءً على أداء المُصادقين في الماضي (. على الرغم من أن اختلاف هوية القائد لا ينتهك الأمان، إلا أنه قد يؤدي إلى ترتيب مختلف تمامًا في Bullshark.
تسببت هذه التحديات في عدم دعم تنفيذ Bullshark الحالي في بيئة الإنتاج لهذه الميزات.
) بروتوكول
تعتمد Shoal على القدرة على تنفيذ الحسابات المحلية على DAG، مما يتيح حفظ وإعادة تفسير المعلومات من الجولات السابقة. بناءً على توافق جميع المدققين على رؤية النقطة المرسومة الأولى، تقوم Shoal بترتيب مجموعة من مثيلات Bullshark المتعددة للمعالجة المتسلسلة، مما يجعل:
خط الإنتاج
V تربط الدور بالزعيم. تعمل Shoal على تشغيل مثيلات Bullshark بشكل متتابع، حيث يتم تحديد نقطة ربط كل مثيل مسبقًا بواسطة الخريطة F. يقوم كل مثيل بترتيب نقطة ربط، مما يؤدي إلى الانتقال إلى المثيل التالي.
بدأ Shoal في الجولة الأولى من DAG بإطلاق أول نموذج Bullshark، وتم تشغيله حتى تم تحديد أول نقطة ربط مرتبة ###، على افتراض أنها في الجولة r (. وافق جميع المدققين على هذه النقطة، وبالتالي يمكنهم بشكل قاطع الاتفاق على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal نموذج Bullshark جديد في الجولة r+1.
في الحالة المثالية، يسمح هذا لـ Shoal بترتيب نقطة مرجعية واحدة في كل جولة. يتم ترتيب نقطة المرجعية الأولى بواسطة المثال الأول، ثم يبدأ Shoal في الجولة الثانية بمثال جديد، ويرتب نقطة المرجعية لتلك الجولة، وهكذا.
![شرح شامل لإطار Shoal: كيف تقلل من وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
)# سمعة القادة
عندما تتخطى عملية ترتيب Bullshark النقاط المرجعية، فإن وقت الإستجابة سيزداد. في هذه الحالة، فإن تقنية خط الأنابيب غير فعالة، لأنه لا يمكن بدء مثيل جديد قبل ترتيب النقطة المرجعية للمثيل السابق. تقوم Shoal بتخصيص درجات لكل عقدة تحقق من خلال آلية سمعة، لضمان أنه من غير المرجح اختيار القادة البطيئين المعنيين في المستقبل بناءً على تاريخ النشاط الأخير. يحصل المراقبون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا يتم تخصيص درجات منخفضة.
عند تحديث النتيجة في كل مرة، يتم إعادة حساب الخريطة المحددة مسبقًا F من الجولة إلى القائد بشكل حتمي، مع التركيز على القادة ذوي النقاط العالية. لكي يتفق المصدقون على الخريطة الجديدة، يحتاجون إلى التوصل إلى توافق في النقاط، وبالتالي التوصل إلى توافق في التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يجتمع خط الأنابيب وسمعة القيادة بشكل طبيعي، لأنهما يستخدمان نفس التقنية الأساسية: إعادة تفسير DAG بعد التوصل إلى توافق بشأن أول نقطة ربط مرتبة.
الفرق الوحيد هو أنه بعد ترتيب نقاط الربط في الجولة r، يقوم المدققون بحساب التعيين الجديد F' بدءًا من الجولة r+1 فقط بناءً على التاريخ السببي لنقاط الربط المرتبة في الجولة r. ثم تبدأ عقد المدققين في استخدام دالة اختيار نقاط الربط المحدثة F' لتنفيذ مثيل Bullshark الجديد بدءًا من الجولة r+1.
إزالة وقت الإستجابة
تعتبر المهلة عاملًا حاسمًا في جميع تنفيذات BFT المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد تصحيح الأخطاء ويحتاج إلى المزيد من تقنيات المراقبة.
تزيد المهلة بشكل ملحوظ من وقت الإستجابة، لأن تكوين المهلة بشكل مناسب أمر مهم، وعادة ما يحتاج إلى تعديل ديناميكي، ويعتمد بشكل كبير على البيئة ### الشبكة (. قبل الانتقال إلى القائد التالي، ستدفع البروتوكول العقوبة الكاملة لوقت الإستجابة للزعيم المعطل. لذلك، لا يمكن أن تكون إعدادات المهلة متحفظة للغاية، ولكن إذا كانت قصيرة جداً، قد يتجاوز البروتوكول الزعماء الجيدين.
لسوء الحظ، فإن بروتوكول القائد ) مثل Hotstuff و Jolteon ( يتطلب بشكل جوهري وقت الإستجابة لضمان تقدم البروتوكول في كل مرة يتعطل فيها القائد. بدون وقت الإستجابة، حتى القائد المتعطل قد يتسبب في توقف البروتوكول إلى الأبد. نظرًا لعدم القدرة على تمييز القادة المتعطلين عن القادة البطيئين خلال الفترة غير المتزامنة، قد يؤدي وقت الإستجابة إلى دوران جميع القادة دون وجود نشاط توافق.
في Bullshark، يتم استخدام وقت الإستجابة لبناء DAG، لضمان أن القادة الأمينين يضيفون النقاط المرجعية إلى DAG بسرعة كافية أثناء التزامن.
تلاحظ Shoal أن بنية DAG توفر "ساعة" لتقدير سرعة الشبكة. في غياب التوقف، طالما أن n-f من المدققين الشرفاء يستمرون في إضافة القمم إلى DAG، ستستمر الجولات في التقدم. على الرغم من أن Bullshark قد لا يتمكن من ترتيب ) بسرعة الشبكة بسبب مشكلة القائد (، إلا أن DAG لا يزال ينمو بسرعة الشبكة، على الرغم من وجود بعض المشكلات في القادة أو الشبكة غير المتزامنة. في النهاية، عندما يقوم القادة بدون عطل ببث النقاط المرجعية بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل للنقاط المرجعية.
في Shoal، تجنب انتهاء الوقت مرتبط ارتباطاً وثيقاً بسمعة القائد. الانتظار المتكرر لقادة بطيئين سيزيد من وقت الإستجابة، وآلية سمعة القائد تستبعد المُحققين البطيئين من أن يتم اختيارهم كقادة. بهذه الطريقة، يستفيد النظام من عقد التحقق السريعة لتعمل بسرعة الشبكة في جميع السيناريوهات الواقعية.
يجب ملاحظة أن نتائج عدم إمكانية FLP تشير إلى أنه لا يمكن لأي بروتوكول توافق حتمي تجنب وقت الإستجابة. لا يمكن لـ Shoal تجنب هذه النتيجة، لأنه يوجد جدول زمني نظري للأحداث المتعارضة يمكن أن يمنع ترتيب جميع المراسي. على العكس من ذلك، بعد عدد قابل للتكوين من تخطي المراسي، سيعود Shoal إلى وقت الإستجابة. في الواقع، من غير المحتمل للغاية أن يحدث هذا.
![شرح مفصل لإطار Shoal: كيف يمكن اسقاط وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) استجابة عامة
أوراق Hotstuff شاعت مفهوم الاستجابة المتفائلة، وعلى الرغم من أنها لم تُعرّف بشكل رسمي، إلا أنها تعني بديهيًا أن البروتوكول يمكن أن يعمل بسرعة الشبكة تحت ظروف جيدة ### مع قائد سريع وشبكة متزامنة (.
يقدم Shoal خصائص أفضل تُعرف باسم الاستجابة العامة. على وجه التحديد، مقارنةً بـ Hotstuff، فإن Shoal سيستمر في العمل بسرعة الشبكة حتى في حالة فشل القائد خلال عدد متواصل قابل للتكوين من الجولات أو عندما تمر الشبكة بفترات غير متزامنة.
توفر الاستجابة العامة ضمانات تقدم أفضل بكثير خلال الفترات غير المتزامنة وعند فشل القائد. خلال فترة التزامن مع القائد البطيء، لا يمكن مقارنة هذه الخصائص، لأن ذلك يعتمد على مدى بطء القائد. ومع ذلك، بالنظر إلى سمعة القائد، يجب أن يكون هناك ندرة في القادة البطيئين في Shoal.
تقييم
أبتوس نفذت بول شارك وشول فوق مخزن الكوروم في ناروال. فيما يلي بعض النقاط البارزة للتقييم:
أولاً، من أجل العرض