إطار Shoal: كيفية اسقاط وقت الإستجابة على Bullshark في Aptos
أبتوس لابز حلت مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى اسقاط وقت الإستجابة بشكل كبير، وأول مرة في بروتوكول فعلي محدد ألغت الحاجة إلى انتهاء الوقت. بشكل عام، تم تحسين وقت الإستجابة لبلشرك بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول توافق قائم على Narwhal مثل DAG-Rider و Tusk و Bullshark ( من خلال خط أنابيب و سمعة القادة. يقلل خط الأنابيب من وقت الإستجابة لترتيب DAG من خلال إدخال نقاط مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات الزمنية. يسمح ذلك لـ Shoal بتوفير خصائص الاستجابة الشاملة، بما في ذلك الاستجابة المتفائلة المطلوبة عادة.
تكنولوجيا هذه بسيطة للغاية، حيث تتعلق بتشغيل عدة مثيلات من البروتوكول الأساسي بالترتيب. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تشارك في سباق التتابع.
![شرح مفصل لإطار عمل Shoal: كيف يمكن تقليل وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا مهتمين باسقاط تعقيد الاتصال. ومع ذلك، لم تؤد هذه الطريقة إلى زيادة كبيرة في الإنتاجية. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
تأتي الانفراجة الأخيرة من إدراك أن انتشار البيانات هو عنق الزجاجة الرئيسي الذي يعتمد على بروتوكول القادة، ويمكن أن يستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات والمنطق الأساسي للإجماع، ويقترح أن يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة من البيانات الوصفية. أفادت ورقة Narwhal أن السعة كانت 160,000 TPS.
تم تنفيذ Quorum Store الذي تم تقديمه سابقًا بواسطة Narwhal، حيث يفصل بين نشر البيانات والتوافق، ويستخدم لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لتندرمينت وتغيير العرض بأسلوب PBFT، مما يقلل وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكولات التوافق القائمة على القيادة لا يمكنها الاستفادة الكاملة من إمكانيات سعة Narwhal.
لذلك، تم اتخاذ قرار بنشر Bullshark فوق Narwhal DAG، وهو بروتوكول توافق بدون تكلفة اتصال. للأسف، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يجلب تكلفة تأخير بنسبة 50% مقارنةً بـ Jolteon.
تقدم هذه المقالة كيفية تقليل وقت الإستجابة ل Bullshark بشكل كبير.
![شرح مفصل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة معينة. للدخول في الدورة r، يجب على المدققين أولاً الحصول على n-f رؤوس من الدورة r-1. يمكن لكل مدقق بث رأس واحد في كل دورة، ويجب أن يشير كل رأس إلى n-f رؤوس على الأقل من الدورة السابقة. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
أحد الخصائص الرئيسية لـ DAG هو عدم الغموض: إذا كان لدى عقدتي التحقق في عرض DAG المحلي نفس الرأس v، فإن لهما تاريخ سببي متطابق تمامًا لـ v.
![شرح شامل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
تسلسل كامل
يمكن تحقيق توافق تام على كل الرؤوس في DAG دون أي نفقات اتصال إضافية. لتحقيق ذلك، يفسر المتحققون في DAG-Rider وTusk وBullshark هيكل DAG كبرتوكول توافق، حيث تمثل الرؤوس المقترحات، وتمثل الحواف التصويت.
جميع بروتوكولات الإجماع المستندة إلى Narwhal الحالية لها الهيكل التالي:
نقاط الربط المحددة سلفًا: كل عدة جولات يوجد قائد محدد مسبقًا، ويطلق على قمة القائد نقاط الربط.
نقاط الربط المرتبة: يقرر المدققون بشكل مستقل ولكن حتمي أي نقاط ربط يتم ترتيبها وأي النقاط يتم تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدًا تلو الآخر، وترتيب جميع الرؤوس غير المرتبة السابقة في تاريخ السبب لكل نقطة ربط وفقًا لقواعد حتمية.
المفتاح لضمان الأمان هو التأكد من أن قائمة نقاط التحقق المرتبة التي أنشأتها جميع العقد الصحيحة في الخطوة )2( تشترك في نفس البادئة. تقدم Shoal الملاحظات التالية حول جميع هذه البروتوكولات:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
يعتمد وقت الإستجابة لBullshark على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن الإصدارات الجزئية المتزامنة لديها وقت إستجابة أفضل من الإصدارات غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة مرجعية في كل جولة زوجية، ويتم تفسير القمة في كل جولة فردية على أنها تصويت. في الحالات الشائعة، يتطلب الأمر جولتين من DAG لترتيب النقاط المرجعية، ومع ذلك، تحتاج القمم في التاريخ السببي للنقاط المرجعية إلى المزيد من الجولات في انتظار ترتيب النقاط المرجعية. عادةً ما تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرجعية في الجولات الزوجية إلى أربع جولات.
السؤال 2: حالات العطل وقت الإستجابة. إذا فشل الزعيم في بث النقاط المرجعية بسرعة كافية، فلن يكون بالإمكان ترتيب النقاط المرجعية ) التي تم تخطيها (، يجب أن تنتظر جميع النقاط غير المرتبة في الجولات السابقة النقطة المرجعية التالية لترتيبها. هذا يقلل بشكل كبير من أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم وقت الإستجابة في انتظار الزعيم.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
إطار Shoal
يعمل Shoal على تعزيز Bullshark) أو أي بروتوكول BFT آخر قائم على Narwhal من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، مما يقلل وقت الاستجابة لجميع القمم غير المرتبطة في DAG إلى ثلاث جولات. كما يقدم Shoal آلية سمعة القادة بدون تكلفة في DAG، مما يميل لاختيار القادة السريعين.
تحدي
في سياق بروتوكول DAG، تعتبر سمعة خطوط الأنابيب والقادة من المشاكل الصعبة، والأسباب كما يلي:
المحاولة السابقة لتعديل منطق Bullshark الأساسي في خط الأنابيب كانت تبدو في جوهرها مستحيلة.
تم إدخال سمعة القادة في DiemBFT وتوثيقها رسميًا في Carousel، حيث يتم اختيار القادة المستقبليين ديناميكيًا بناءً على أداء المصدقين في الماضي (. على الرغم من أن وجود انقسام في هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه قد يؤدي إلى ترتيب مختلف تمامًا في Bullshark، مما يثير القضية الجوهرية: إن اختيار العجلات الديناميكي الحتمي للأقفال هو ما تحتاجه لتلبية متطلبات الإجماع، ويحتاج المصدقون إلى التوافق بشأن التاريخ المنظم لاختيار الأقفال المستقبلية.
كأدلة على صعوبة السؤال، يتضمن تنفيذ Bullshark ) أن ( في بيئة الإنتاج الحالية لا تدعم هذه الميزات.
البروتوكول
تعتمد Shoal على القدرة على تنفيذ الحسابات المحلية على DAG، مما يحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل اتفاق جميع المُصادقين على رؤية أول نقطة ربط مرتبة، تقوم Shoal بترتيب وتجميع عدة أمثلة من Bullshark للمعالجة المتسلسلة، مما يجعل ) أول نقطة ربط مرتبة هي نقطة تبديل الأمثلة، وتُستخدم السجل السببي لنقطة الربط ( لحساب سمعة القائد.
) خط التجميع
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. بعد ذلك، يبدأ عقد التحقق في استخدام دالة اختيار نقاط الربط المحدثة F' لتنفيذ حالة جديدة من Bullshark اعتبارًا من الجولة r+1.
![شرح مفصل لإطار Shoal: كيف يمكن خفض وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( لا يوجد وقت الإستجابة
يلعب الوقت المستغرق دوراً حاسماً في جميع تطبيقات BFT المعتمدة على القادة. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
سيؤدي أيضًا تجاوز الوقت المحدد إلى زيادة وقت الإستجابة بشكل كبير، لأن تكوينها بشكل صحيح أمر مهم، وعادة ما يحتاج إلى ضبط ديناميكي، ويعتمد بشكل كبير على البيئة ) الشبكة ###. قبل الانتقال إلى القائد التالي، ستدفع البروتوكولات عقوبة وقت الإستجابة الكامل للقائد الذي يعاني من عطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة متحفظة للغاية، ولكن إذا كانت قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه تحت حمل مرتفع، كان القادة في Jolteon/Hotstuff مرهقين، وانتهى وقت الإستجابة قبل دفع التقدم.
للأسف، فإن بروتوكول القائد ( مثل Hotstuff وJolteon ) يحتاج بشكل أساسي إلى وقت الإستجابة لضمان تقدم البروتوكول في كل مرة يحدث فيها فشل للقائد. بدون وقت الإستجابة، حتى القائد المعطل قد يتسبب في توقف البروتوكول إلى الأبد. نظرًا لأنه لا يمكن التمييز بين القائد المعطل والقائد البطيء خلال الفترة غير المتزامنة، قد يؤدي وقت الإستجابة إلى تغيير جميع القادة بدون نشاط توافق.
في Bullshark، يُستخدم وقت الإستجابة لبناء DAG، لضمان أن القادة الأمناء يضيفون النقاط المرجعية إلى DAG بسرعة كافية خلال فترة التزامن.
لقد لاحظنا أن بناء DAG يوفر "ساعة" لتقدير سرعة الشبكة. في حالة عدم وجود انقطاع، طالما يستمر n-f من المدققين الشرفاء في إضافة نقاط إلى DAG، ستستمر الدورات في التقدم. على الرغم من أن Bullshark قد لا يمكنه ترتيب ### بسرعة الشبكة بسبب مشكلات القيادة (، إلا أن DAG لا يزال ينمو بسرعة الشبكة، على الرغم من أن بعض القادة لديهم مشكلات أو أن الشبكة غير متزامنة. في النهاية، عندما يقوم القادة الخاليون من الأخطاء ببث نقاط الربط بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل لنقاط الربط.
في تقييمنا، تم مقارنة Bullshark في الحالات التالية مع أو بدون وقت الإستجابة:
القائد السريع: يجب أن يكون أسرع على الأقل من غيره من المدققين. توفر طريقتان نفس وقت الإستجابة، لأن المرساة مرتبة ولا تستخدم اسقاط.
قادة خطأ: يقدم Bullshark بدون وقت الإستجابة أفضل اسقاط، لأن العقدة المصدقة تتخطى على الفور.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 10
أعجبني
10
4
إعادة النشر
مشاركة
تعليق
0/400
HashRateHermit
· منذ 6 س
وقت الإستجابة改进80%؟ هذه موجة ثور哇
شاهد النسخة الأصليةرد0
SelfRugger
· منذ 6 س
80% وقت الإستجابة减少 ما دير كان صرخ ثور
شاهد النسخة الأصليةرد0
CommunitySlacker
· منذ 7 س
ثور啤 وقت الإستجابة都优化80%了
شاهد النسخة الأصليةرد0
Hash_Bandit
· منذ 7 س
تبا، هذا مثل عندما قمنا بتحسين صعوبة تعدين البيتكوين في عام 2013... مكاسب كبيرة في معدل التجزئة.
Shoal框架：تحسين وقت الإستجابة Bullshark على Aptos
إطار Shoal: كيفية اسقاط وقت الإستجابة على Bullshark في Aptos
أبتوس لابز حلت مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى اسقاط وقت الإستجابة بشكل كبير، وأول مرة في بروتوكول فعلي محدد ألغت الحاجة إلى انتهاء الوقت. بشكل عام، تم تحسين وقت الإستجابة لبلشرك بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول توافق قائم على Narwhal مثل DAG-Rider و Tusk و Bullshark ( من خلال خط أنابيب و سمعة القادة. يقلل خط الأنابيب من وقت الإستجابة لترتيب DAG من خلال إدخال نقاط مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات الزمنية. يسمح ذلك لـ Shoal بتوفير خصائص الاستجابة الشاملة، بما في ذلك الاستجابة المتفائلة المطلوبة عادة.
تكنولوجيا هذه بسيطة للغاية، حيث تتعلق بتشغيل عدة مثيلات من البروتوكول الأساسي بالترتيب. لذلك، عند استخدام Bullshark للتجسيد، نحصل على مجموعة من "الأسماك" التي تشارك في سباق التتابع.
![شرح مفصل لإطار عمل Shoal: كيف يمكن تقليل وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا مهتمين باسقاط تعقيد الاتصال. ومع ذلك، لم تؤد هذه الطريقة إلى زيادة كبيرة في الإنتاجية. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
تأتي الانفراجة الأخيرة من إدراك أن انتشار البيانات هو عنق الزجاجة الرئيسي الذي يعتمد على بروتوكول القادة، ويمكن أن يستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات والمنطق الأساسي للإجماع، ويقترح أن يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية صغيرة من البيانات الوصفية. أفادت ورقة Narwhal أن السعة كانت 160,000 TPS.
تم تنفيذ Quorum Store الذي تم تقديمه سابقًا بواسطة Narwhal، حيث يفصل بين نشر البيانات والتوافق، ويستخدم لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القيادة، يجمع بين المسار السريع الخطي لتندرمينت وتغيير العرض بأسلوب PBFT، مما يقلل وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكولات التوافق القائمة على القيادة لا يمكنها الاستفادة الكاملة من إمكانيات سعة Narwhal.
لذلك، تم اتخاذ قرار بنشر Bullshark فوق Narwhal DAG، وهو بروتوكول توافق بدون تكلفة اتصال. للأسف، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يجلب تكلفة تأخير بنسبة 50% مقارنةً بـ Jolteon.
تقدم هذه المقالة كيفية تقليل وقت الإستجابة ل Bullshark بشكل كبير.
![شرح مفصل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة معينة. للدخول في الدورة r، يجب على المدققين أولاً الحصول على n-f رؤوس من الدورة r-1. يمكن لكل مدقق بث رأس واحد في كل دورة، ويجب أن يشير كل رأس إلى n-f رؤوس على الأقل من الدورة السابقة. بسبب عدم تزامن الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
أحد الخصائص الرئيسية لـ DAG هو عدم الغموض: إذا كان لدى عقدتي التحقق في عرض DAG المحلي نفس الرأس v، فإن لهما تاريخ سببي متطابق تمامًا لـ v.
![شرح شامل لإطار Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
تسلسل كامل
يمكن تحقيق توافق تام على كل الرؤوس في DAG دون أي نفقات اتصال إضافية. لتحقيق ذلك، يفسر المتحققون في DAG-Rider وTusk وBullshark هيكل DAG كبرتوكول توافق، حيث تمثل الرؤوس المقترحات، وتمثل الحواف التصويت.
جميع بروتوكولات الإجماع المستندة إلى Narwhal الحالية لها الهيكل التالي:
نقاط الربط المحددة سلفًا: كل عدة جولات يوجد قائد محدد مسبقًا، ويطلق على قمة القائد نقاط الربط.
نقاط الربط المرتبة: يقرر المدققون بشكل مستقل ولكن حتمي أي نقاط ربط يتم ترتيبها وأي النقاط يتم تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدًا تلو الآخر، وترتيب جميع الرؤوس غير المرتبة السابقة في تاريخ السبب لكل نقطة ربط وفقًا لقواعد حتمية.
المفتاح لضمان الأمان هو التأكد من أن قائمة نقاط التحقق المرتبة التي أنشأتها جميع العقد الصحيحة في الخطوة )2( تشترك في نفس البادئة. تقدم Shoal الملاحظات التالية حول جميع هذه البروتوكولات:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
يعتمد وقت الإستجابة لBullshark على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن الإصدارات الجزئية المتزامنة لديها وقت إستجابة أفضل من الإصدارات غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة مرجعية في كل جولة زوجية، ويتم تفسير القمة في كل جولة فردية على أنها تصويت. في الحالات الشائعة، يتطلب الأمر جولتين من DAG لترتيب النقاط المرجعية، ومع ذلك، تحتاج القمم في التاريخ السببي للنقاط المرجعية إلى المزيد من الجولات في انتظار ترتيب النقاط المرجعية. عادةً ما تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرجعية في الجولات الزوجية إلى أربع جولات.
السؤال 2: حالات العطل وقت الإستجابة. إذا فشل الزعيم في بث النقاط المرجعية بسرعة كافية، فلن يكون بالإمكان ترتيب النقاط المرجعية ) التي تم تخطيها (، يجب أن تنتظر جميع النقاط غير المرتبة في الجولات السابقة النقطة المرجعية التالية لترتيبها. هذا يقلل بشكل كبير من أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم وقت الإستجابة في انتظار الزعيم.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
إطار Shoal
يعمل Shoal على تعزيز Bullshark) أو أي بروتوكول BFT آخر قائم على Narwhal من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، مما يقلل وقت الاستجابة لجميع القمم غير المرتبطة في DAG إلى ثلاث جولات. كما يقدم Shoal آلية سمعة القادة بدون تكلفة في DAG، مما يميل لاختيار القادة السريعين.
تحدي
في سياق بروتوكول DAG، تعتبر سمعة خطوط الأنابيب والقادة من المشاكل الصعبة، والأسباب كما يلي:
المحاولة السابقة لتعديل منطق Bullshark الأساسي في خط الأنابيب كانت تبدو في جوهرها مستحيلة.
تم إدخال سمعة القادة في DiemBFT وتوثيقها رسميًا في Carousel، حيث يتم اختيار القادة المستقبليين ديناميكيًا بناءً على أداء المصدقين في الماضي (. على الرغم من أن وجود انقسام في هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه قد يؤدي إلى ترتيب مختلف تمامًا في Bullshark، مما يثير القضية الجوهرية: إن اختيار العجلات الديناميكي الحتمي للأقفال هو ما تحتاجه لتلبية متطلبات الإجماع، ويحتاج المصدقون إلى التوافق بشأن التاريخ المنظم لاختيار الأقفال المستقبلية.
كأدلة على صعوبة السؤال، يتضمن تنفيذ Bullshark ) أن ( في بيئة الإنتاج الحالية لا تدعم هذه الميزات.
البروتوكول
تعتمد Shoal على القدرة على تنفيذ الحسابات المحلية على DAG، مما يحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل اتفاق جميع المُصادقين على رؤية أول نقطة ربط مرتبة، تقوم Shoal بترتيب وتجميع عدة أمثلة من Bullshark للمعالجة المتسلسلة، مما يجعل ) أول نقطة ربط مرتبة هي نقطة تبديل الأمثلة، وتُستخدم السجل السببي لنقطة الربط ( لحساب سمعة القائد.
) خط التجميع
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. بعد ذلك، يبدأ عقد التحقق في استخدام دالة اختيار نقاط الربط المحدثة F' لتنفيذ حالة جديدة من Bullshark اعتبارًا من الجولة r+1.
![شرح مفصل لإطار Shoal: كيف يمكن خفض وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( لا يوجد وقت الإستجابة
يلعب الوقت المستغرق دوراً حاسماً في جميع تطبيقات BFT المعتمدة على القادة. ومع ذلك، فإن التعقيد الذي يتم تقديمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
سيؤدي أيضًا تجاوز الوقت المحدد إلى زيادة وقت الإستجابة بشكل كبير، لأن تكوينها بشكل صحيح أمر مهم، وعادة ما يحتاج إلى ضبط ديناميكي، ويعتمد بشكل كبير على البيئة ) الشبكة ###. قبل الانتقال إلى القائد التالي، ستدفع البروتوكولات عقوبة وقت الإستجابة الكامل للقائد الذي يعاني من عطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة متحفظة للغاية، ولكن إذا كانت قصيرة جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه تحت حمل مرتفع، كان القادة في Jolteon/Hotstuff مرهقين، وانتهى وقت الإستجابة قبل دفع التقدم.
للأسف، فإن بروتوكول القائد ( مثل Hotstuff وJolteon ) يحتاج بشكل أساسي إلى وقت الإستجابة لضمان تقدم البروتوكول في كل مرة يحدث فيها فشل للقائد. بدون وقت الإستجابة، حتى القائد المعطل قد يتسبب في توقف البروتوكول إلى الأبد. نظرًا لأنه لا يمكن التمييز بين القائد المعطل والقائد البطيء خلال الفترة غير المتزامنة، قد يؤدي وقت الإستجابة إلى تغيير جميع القادة بدون نشاط توافق.
في Bullshark، يُستخدم وقت الإستجابة لبناء DAG، لضمان أن القادة الأمناء يضيفون النقاط المرجعية إلى DAG بسرعة كافية خلال فترة التزامن.
لقد لاحظنا أن بناء DAG يوفر "ساعة" لتقدير سرعة الشبكة. في حالة عدم وجود انقطاع، طالما يستمر n-f من المدققين الشرفاء في إضافة نقاط إلى DAG، ستستمر الدورات في التقدم. على الرغم من أن Bullshark قد لا يمكنه ترتيب ### بسرعة الشبكة بسبب مشكلات القيادة (، إلا أن DAG لا يزال ينمو بسرعة الشبكة، على الرغم من أن بعض القادة لديهم مشكلات أو أن الشبكة غير متزامنة. في النهاية، عندما يقوم القادة الخاليون من الأخطاء ببث نقاط الربط بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل لنقاط الربط.
في تقييمنا، تم مقارنة Bullshark في الحالات التالية مع أو بدون وقت الإستجابة:
القائد السريع: يجب أن يكون أسرع على الأقل من غيره من المدققين. توفر طريقتان نفس وقت الإستجابة، لأن المرساة مرتبة ولا تستخدم اسقاط.
قادة خطأ: يقدم Bullshark بدون وقت الإستجابة أفضل اسقاط، لأن العقدة المصدقة تتخطى على الفور.