إطار Shoal: تقليل وقت الإستجابة بشكل كبير لـ Bullshark على Aptos
نظرة عامة
حل مختبرات Aptos مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل ملحوظ، ولأول مرة القضاء على الحاجة إلى مهلة في بروتوكولات التأكيد الفعلي. بشكل عام، تم تحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal من خلال خط الأنابيب وسمعة القادة. يقوم خط الأنابيب بتقليل وقت الإستجابة من خلال إدخال نقطة مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت الإضافي من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد التحقق. بالإضافة إلى ذلك، تسمح سمعة القادة لـ 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 الحالية تتمتع بالهيكل التالي:
نقطة الربط المحجوزة: كل بضع جولات يكون هناك قائد مُحدد مسبقًا، وذروة القائد تُسمى نقطة الربط؛
نقاط الطلب: يقرر المصدقون بشكل مستقل ولكن حتمي أي نقاط طلب يجب أن يتم الطلب عليها وأي نقاط يجب تخطيها؛
طلب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، ويقومون بترتيب جميع النقاط غير المرتبة السابقة في التاريخ السببي لكل نقطة ربط.
الشرط الأساسي لضمان الأمان هو التأكد من أن جميع العقد الصادقة تقوم بإنشاء قائمة نقاط مرجعية مرتبة في الخطوة (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، نعتمد على قدرة تنفيذ الحسابات المحلية على DAG، ونحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على البصيرة الأساسية للنقطة المرسومة الأولى، يقوم Shoal بتجميع عدة أمثلة من Bullshark بشكل متسلسل لمعالجتها في خط أنابيب، مما يجعل ) النقطة المرسومة الأولى نقطة التحول للأمثلة، و ( التاريخ السببي للنقاط المرسومة المستخدمة في حساب سمعة القائد.
![شرح شامل لإطار Shoal: كيف نقلل من وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
خط الأنابيب
مثل 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. ثم، تبدأ عقد المُصادقين في استخدام دالة اختيار النقاط المرجعية المحدثة F' لتنفيذ حالة جديدة من Bullshark من الجولة r+1.
![شرح مفصل لإطار Shoal: كيف نقلل من وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
لا مزيد من وقت الإستجابة
يلعب وقت الإستجابة دورًا حاسمًا في جميع تنفيذات BFT القابلة للتحديد المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب المزيد من تقنيات المراقبة.
سيؤدي وقت الإستجابة أيضًا إلى زيادة كبيرة في وقت الإستجابة، لأنه من المهم تكوينها بشكل صحيح وغالبًا ما يتطلب ضبطًا ديناميكيًا، لأنه يعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، ستدفع البروتوكول العقوبة الكاملة لوقت الإستجابة للقائد المعطل. لذلك، لا يمكن إعداد وقت الإستجابة بشكل مفرط الحذر، ولكن إذا كان وقت الإستجابة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل المرتفع، كان القادة في Jolteon/Hotstuff مثقلين، وانتهى وقت الإستجابة قبل أن يتمكنوا من دفع التقدم.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 7
أعجبني
7
5
مشاركة
تعليق
0/400
SchrodingersFOMO
· 08-05 13:55
وقت الإستجابة降这么多 ثور蛙ثور蛙
شاهد النسخة الأصليةرد0
SchroedingerMiner
· 08-05 12:20
هذه السرعة ارتفعت أسرع من درجة حرارة جهاز التعدين في منزلي
أطار Shoal يرفع بشكل كبير من أداء Bullshark على Aptos حيث ان وقت الإستجابة انخفض بنسبة 40%-80%
إطار Shoal: تقليل وقت الإستجابة بشكل كبير لـ Bullshark على Aptos
نظرة عامة
حل مختبرات Aptos مشكلتين مفتوحتين مهمتين في DAG BFT، مما أدى إلى تقليل وقت الإستجابة بشكل ملحوظ، ولأول مرة القضاء على الحاجة إلى مهلة في بروتوكولات التأكيد الفعلي. بشكل عام، تم تحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع قائم على Narwhal من خلال خط الأنابيب وسمعة القادة. يقوم خط الأنابيب بتقليل وقت الإستجابة من خلال إدخال نقطة مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت الإضافي من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد التحقق. بالإضافة إلى ذلك، تسمح سمعة القادة لـ 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 الحالية تتمتع بالهيكل التالي:
نقطة الربط المحجوزة: كل بضع جولات يكون هناك قائد مُحدد مسبقًا، وذروة القائد تُسمى نقطة الربط؛
نقاط الطلب: يقرر المصدقون بشكل مستقل ولكن حتمي أي نقاط طلب يجب أن يتم الطلب عليها وأي نقاط يجب تخطيها؛
طلب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، ويقومون بترتيب جميع النقاط غير المرتبة السابقة في التاريخ السببي لكل نقطة ربط.
الشرط الأساسي لضمان الأمان هو التأكد من أن جميع العقد الصادقة تقوم بإنشاء قائمة نقاط مرجعية مرتبة في الخطوة (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، نعتمد على قدرة تنفيذ الحسابات المحلية على DAG، ونحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على البصيرة الأساسية للنقطة المرسومة الأولى، يقوم Shoal بتجميع عدة أمثلة من Bullshark بشكل متسلسل لمعالجتها في خط أنابيب، مما يجعل ) النقطة المرسومة الأولى نقطة التحول للأمثلة، و ( التاريخ السببي للنقاط المرسومة المستخدمة في حساب سمعة القائد.
![شرح شامل لإطار Shoal: كيف نقلل من وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
خط الأنابيب
مثل 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. ثم، تبدأ عقد المُصادقين في استخدام دالة اختيار النقاط المرجعية المحدثة F' لتنفيذ حالة جديدة من Bullshark من الجولة r+1.
![شرح مفصل لإطار Shoal: كيف نقلل من وقت الإستجابة Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
لا مزيد من وقت الإستجابة
يلعب وقت الإستجابة دورًا حاسمًا في جميع تنفيذات BFT القابلة للتحديد المستندة إلى القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب المزيد من تقنيات المراقبة.
سيؤدي وقت الإستجابة أيضًا إلى زيادة كبيرة في وقت الإستجابة، لأنه من المهم تكوينها بشكل صحيح وغالبًا ما يتطلب ضبطًا ديناميكيًا، لأنه يعتمد بشكل كبير على البيئة ) الشبكة (. قبل الانتقال إلى القائد التالي، ستدفع البروتوكول العقوبة الكاملة لوقت الإستجابة للقائد المعطل. لذلك، لا يمكن إعداد وقت الإستجابة بشكل مفرط الحذر، ولكن إذا كان وقت الإستجابة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في حالات الحمل المرتفع، كان القادة في Jolteon/Hotstuff مثقلين، وانتهى وقت الإستجابة قبل أن يتمكنوا من دفع التقدم.
غير محظوظ