إطار Shoal: اسقاط كبير في وقت الإستجابة Bullshark على Aptos
قامت Aptos Labs مؤخرًا بحل مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى اسقاط وقت الإستجابة بشكل ملحوظ، وألغت لأول مرة الحاجة إلى المهلة في بروتوكول حقيقي حتمي. بشكل عام، تم تحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، و80% في حالة وجود أعطال.
Shoal هو إطار عمل يعزز أي بروتوكول إجماع يعتمد على Narwhal من خلال خط الأنابيب وسمعة القادة ( مثل DAG-Rider، Tusk، Bullshark ). يقلل خط الأنابيب من وقت الإستجابة من خلال إدخال نقطة مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين الوقت من خلال ضمان ارتباط النقاط المرجعية بأسرع عقد التحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي تتضمن تجاوزات الوقت. هذا يسمح لـ Shoal بتقديم ما يسمى بالاستجابة العامة، والتي تتضمن الاستجابة المتفائلة المطلوبة عادةً.
تتمتع هذه التقنية بالبساطة، حيث تتضمن تشغيل عدة مثيلات من البروتوكول الأساسي بترتيب معين. لذلك، عندما يتم استنساخها باستخدام Bullshark، نحصل على مجموعة من "الأسماك" التي تتنافس في سباق التتابع.
الدافع
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا مهتمين باسقاط تعقيد الاتصالات. ومع ذلك، لم تؤد هذه الطريقة إلى زيادة ملحوظة في الإنتاجية. على سبيل المثال، حقق 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. للأسف، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يأتي بتكلفة تأخير تبلغ 50% مقارنةً بـ Jolteon.
تتناول هذه المقالة كيفية تحقيق Shoal لأسقاط كبير في وقت الإستجابة Bullshark.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة معينة. للدخول في الدورة r، يجب على المدقق أولاً الحصول على n-f من الرؤوس التي تنتمي إلى الدورة r-1. يمكن لكل مدقق في كل دورة بث رأس واحد، ويجب أن يشير كل رأس إلى n-f من الرؤوس في الدورة السابقة على الأقل. بسبب اللامزامنة في الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي لحظة.
خاصية رئيسية من DAG هي أنها ليست غامضة: إذا كان لدى عقدتي التحقق اثنين نفس الرأس v في عرضهما المحلي لـ DAG، فإنهما يمتلكان نفس تاريخ السبب v تمامًا.
المقدمة
يمكن تحقيق التوافق على الترتيب الكلي لجميع القمم في DAG دون أي تكاليف اتصالات إضافية. لهذا، يقوم المدققون في DAG-Rider وTusk وBullshark بتفسير هيكل DAG كنوع من بروتوكول الإجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تداخل المجموعات في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع الحالية القائمة على Narwhal تتمتع بالهيكل التالي:
نقطة الربط المحجوزة: كل بضع جولات ( على سبيل المثال، في Bullshark يوجد قائد محدد مسبقًا في كل جولتين )، وتسمى قمة القائد نقطة الربط;
نقاط الربط المرتبة: يقرر الموثقون بشكل مستقل ولكن محدد أي نقاط ربط يجب ترتيبها وأيها يجب تخطيها؛
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، وبالنسبة لكل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخها السببي وفقًا لبعض القواعد الحتمية.
المفتاح لضمان الأمان هو التأكد من أنه في الخطوة (2)، تقوم جميع العقد الموثوقة بإنشاء قائمة نقاط مرجعية مرتبة، بحيث تشترك جميع القوائم في نفس البادئة. في شوال، نقدم الملاحظات التالية حول جميع البروتوكولات المذكورة أعلاه:
جميع المدققين متفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
تعتمد وقت الإستجابة لبولشارك على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية لبولشارك تتمتع بوقت إستجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن كونها مثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، تحتوي كل جولة زوجية على نقطة ربط، بينما يتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى دورتين من DAG لترتيب نقاط الربط، ومع ذلك، فإن القمم في التاريخ السببي للنقطة الربط تحتاج إلى المزيد من الجولات في انتظار ترتيب النقطة الربط. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرتبطة في الجولات الزوجية إلى أربع جولات.
السؤال 2: حالات العطل وقت الإستجابة. ينطبق تحليل الوقت الإستجابة المذكور أعلاه على الحالات الخالية من الأعطال، ومن ناحية أخرى، إذا فشل أحد القادة في بث النقطة المرجعية بسرعة كافية، فلا يمكن ترتيب النقطة المرجعية ( وبالتالي يتم تخطيها )، لذا يجب أن تنتظر جميع القمم غير المرتبة في الجولات السابقة النقطة المرجعية التالية ليتم ترتيبها. هذا سيؤدي إلى اسقاط كبير في أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم مهلة للانتظار على القائد.
إطار Shoal
حل Shoal هذين المشكلتين وقت الإستجابة، حيث عزز Bullshark( أو أي بروتوكول BFT آخر قائم على Narwhal) من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، وتقليل وقت الإستجابة لجميع القمم غير المرتبطة في DAG إلى ثلاث جولات. كما أدخل Shoal آلية سمعة القادة صفر التكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، يُعتبر كل من خط الأنابيب وسمعة القائد مسائل صعبة، للأسباب التالية:
محاولات خط التجميع السابقة كانت تحاول تعديل منطق Bullshark الأساسي، لكن يبدو أن هذا من الناحية الجوهرية غير ممكن.
تمت إدخال سمعة القائد في DiemBFT وتثبيتها رسميًا في Carousel، وهي تعتمد على اختيار القادة المستقبليين بشكل ديناميكي استنادًا إلى أداء المدققين في الماضي، فكرة أن ( Bullshark هو نقطة الربط في ). على الرغم من أن وجود خلافات حول هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار نقطة الربط الديناميكية والمحددة هو أمر ضروري لحل التوافق، ويحتاج المدققون إلى التوصل إلى توافق حول التاريخ المرتب لاختيار نقاط الربط المستقبلية.
كدليل على صعوبة المشكلة، نلاحظ أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
البروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحقيقة تشير إلى أن الحلول مخفية في البساطة.
في Shoal، نعتمد على القدرة على تنفيذ الحسابات المحلية على DAG، ونحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على الفهم الأساسي للنقطة المرجعية المترتبة الأولى، يقوم Shoal بترتيب وتجميع عدة أمثلة من Bullshark ومعالجتها بشكل متسلسل، مما يجعل ( النقطة المرجعية المترتبة الأولى نقطة تحول للمثال، و ) التاريخ السببي للنقطة المرجعية يُستخدم في حساب سمعة القائد.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
خط الإنتاج
V تربط بين الأدوار والقادة. يعمل Shoal واحدًا تلو الآخر على تشغيل حالات Bullshark، بحيث يتم تحديد الربط مسبقًا بواسطة الخريطة F لكل حالة. يقوم كل حالة بطلب ربط، مما يؤدي إلى الانتقال إلى الحالة التالية.
في البداية، أطلق Shoal أول مثيل لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى تم تحديد أول نقطة ربط مرتبة، مثل في الجولة r. وافق جميع المدققين على هذه النقطة الربط. وبالتالي، يمكن لجميع المدققين أن يتفقوا بشكل مؤكد على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal فقط مثيلًا جديدًا لـ Bullshark في الجولة r+1.
في أفضل الحالات، يسمح هذا لشول بطلب مرساة في كل جولة. يتم ترتيب نقاط المرسى في الجولة الأولى حسب المثال الأول. بعد ذلك، يبدأ شول مثالا جديدا في الجولة الثانية، والذي يحتوي على نقطة مرسى خاصة به، ويتم ترتيب هذه المرسى حسب هذا المثال، ثم يتم طلب نقطة مرسى جديدة في الجولة الثالثة، ثم تستمر هذه العملية.
سمعة القادة
عند تخطي نقاط الربط خلال ترتيب Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، تكون تقنية خطوط الأنابيب عديمة الفائدة، لأن لا يمكن بدء مثيل جديد قبل طلب نقطة الربط السابقة. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة، مما يجعل من غير المحتمل اختيار القادة المعنيين في المستقبل للتعامل مع نقاط الربط المفقودة. سيحصل المصدقون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا، سيتم تخصيص درجات منخفضة لعقدة التحقق، لأنها قد تنهار أو تكون بطيئة أو تتصرف بسوء.
فكرتها هي إعادة حساب التعيين المحدد F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع تفضيل القائد الذي حصل على درجة أعلى. لكي يتوصل المدققون إلى توافق في الآراء حول التعيين الجديد، ينبغي عليهم التوصل إلى توافق حول النقاط، وبالتالي الوصول إلى توافق حول التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن أن تتكامل خطوط الأنابيب وسمعة القيادة بشكل طبيعي، لأنها تستخدم نفس التكنولوجيا الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المصدقون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقدة التحقق في استخدام دالة اختيار النقاط المرجعية المحدثة F' لتنفيذ مثيل جديد من Bullshark بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
تلعب مدة الانتظار دورًا حاسمًا في جميع تنفيذات BFT القابلة للتحديد المعتمدة على القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
سيزيد وقت الاستجابة أيضًا بشكل كبير ، لأن تكوينها بشكل صحيح مهم للغاية وغالبًا ما يحتاج إلى تعديل ديناميكي ، لأنه يعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي ، ستدفع البروتوكول عقوبة وقت الاستجابة الكامل للقائد الذي به خلل. لذلك ، يجب ألا تكون إعدادات وقت الاستجابة متحفظة للغاية ، ولكن إذا كان وقت الاستجابة قصيرًا جدًا ، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال ، لاحظنا أنه في حالات الحمل العالي ، Jolteon/
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 22
أعجبني
22
5
مشاركة
تعليق
0/400
BlockchainFries
· 07-21 02:44
انتظر، 40% و 80%، هل أنت متأكد أنها ليست مجرد وعود غير قابلة للتحقيق؟
شاهد النسخة الأصليةرد0
YouMustMakeBigMoneyEvery
· 07-20 12:23
لا تزال التحفيز السوق بقوة. إنه سيء للغاية. اخترق 6 يوان وزيادة المركز
شاهد النسخة الأصليةرد0
HalfBuddhaMoney
· 07-20 09:59
وقت الإستجابة降这么多 aptos值得期待啊
شاهد النسخة الأصليةرد0
SleepyArbCat
· 07-20 09:58
هذه الليلة تقترب من الفجر، أخيرًا تحفيز السوق بقوة لـ aptos... وقت الإستجابة إذا انخفض أكثر سأتمكن من تناول الطعام.
إسقاط إطار 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، نحصل على مجموعة من "الأسماك" التي تتنافس في سباق التتابع.
الدافع
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا مهتمين باسقاط تعقيد الاتصالات. ومع ذلك، لم تؤد هذه الطريقة إلى زيادة ملحوظة في الإنتاجية. على سبيل المثال، حقق 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. للأسف، فإن هيكل DAG الذي يدعم Bullshark ذو السعة العالية يأتي بتكلفة تأخير تبلغ 50% مقارنةً بـ Jolteon.
تتناول هذه المقالة كيفية تحقيق Shoal لأسقاط كبير في وقت الإستجابة Bullshark.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة معينة. للدخول في الدورة r، يجب على المدقق أولاً الحصول على n-f من الرؤوس التي تنتمي إلى الدورة r-1. يمكن لكل مدقق في كل دورة بث رأس واحد، ويجب أن يشير كل رأس إلى n-f من الرؤوس في الدورة السابقة على الأقل. بسبب اللامزامنة في الشبكة، قد يلاحظ المدققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي لحظة.
خاصية رئيسية من DAG هي أنها ليست غامضة: إذا كان لدى عقدتي التحقق اثنين نفس الرأس v في عرضهما المحلي لـ DAG، فإنهما يمتلكان نفس تاريخ السبب v تمامًا.
المقدمة
يمكن تحقيق التوافق على الترتيب الكلي لجميع القمم في DAG دون أي تكاليف اتصالات إضافية. لهذا، يقوم المدققون في DAG-Rider وTusk وBullshark بتفسير هيكل DAG كنوع من بروتوكول الإجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق تداخل المجموعات في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع الحالية القائمة على Narwhal تتمتع بالهيكل التالي:
نقطة الربط المحجوزة: كل بضع جولات ( على سبيل المثال، في Bullshark يوجد قائد محدد مسبقًا في كل جولتين )، وتسمى قمة القائد نقطة الربط;
نقاط الربط المرتبة: يقرر الموثقون بشكل مستقل ولكن محدد أي نقاط ربط يجب ترتيبها وأيها يجب تخطيها؛
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، وبالنسبة لكل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخها السببي وفقًا لبعض القواعد الحتمية.
المفتاح لضمان الأمان هو التأكد من أنه في الخطوة (2)، تقوم جميع العقد الموثوقة بإنشاء قائمة نقاط مرجعية مرتبة، بحيث تشترك جميع القوائم في نفس البادئة. في شوال، نقدم الملاحظات التالية حول جميع البروتوكولات المذكورة أعلاه:
جميع المدققين متفقون على أول نقطة ربط مرتبة.
Bullshark وقت الإستجابة
تعتمد وقت الإستجابة لبولشارك على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية لبولشارك تتمتع بوقت إستجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن كونها مثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، تحتوي كل جولة زوجية على نقطة ربط، بينما يتم تفسير قمة كل جولة فردية على أنها تصويت. في الحالات الشائعة، تحتاج إلى دورتين من DAG لترتيب نقاط الربط، ومع ذلك، فإن القمم في التاريخ السببي للنقطة الربط تحتاج إلى المزيد من الجولات في انتظار ترتيب النقطة الربط. في الحالات الشائعة، تحتاج القمم في الجولات الفردية إلى ثلاث جولات، بينما تحتاج القمم غير المرتبطة في الجولات الزوجية إلى أربع جولات.
السؤال 2: حالات العطل وقت الإستجابة. ينطبق تحليل الوقت الإستجابة المذكور أعلاه على الحالات الخالية من الأعطال، ومن ناحية أخرى، إذا فشل أحد القادة في بث النقطة المرجعية بسرعة كافية، فلا يمكن ترتيب النقطة المرجعية ( وبالتالي يتم تخطيها )، لذا يجب أن تنتظر جميع القمم غير المرتبة في الجولات السابقة النقطة المرجعية التالية ليتم ترتيبها. هذا سيؤدي إلى اسقاط كبير في أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم مهلة للانتظار على القائد.
إطار Shoal
حل Shoal هذين المشكلتين وقت الإستجابة، حيث عزز Bullshark( أو أي بروتوكول BFT آخر قائم على Narwhal) من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط في كل جولة، وتقليل وقت الإستجابة لجميع القمم غير المرتبطة في DAG إلى ثلاث جولات. كما أدخل Shoal آلية سمعة القادة صفر التكلفة في DAG، مما يجعل الاختيار يميل نحو القادة السريعين.
التحدي
في سياق بروتوكول DAG، يُعتبر كل من خط الأنابيب وسمعة القائد مسائل صعبة، للأسباب التالية:
محاولات خط التجميع السابقة كانت تحاول تعديل منطق Bullshark الأساسي، لكن يبدو أن هذا من الناحية الجوهرية غير ممكن.
تمت إدخال سمعة القائد في DiemBFT وتثبيتها رسميًا في Carousel، وهي تعتمد على اختيار القادة المستقبليين بشكل ديناميكي استنادًا إلى أداء المدققين في الماضي، فكرة أن ( Bullshark هو نقطة الربط في ). على الرغم من أن وجود خلافات حول هوية القائد لا ينتهك أمان هذه البروتوكولات، إلا أنه في Bullshark، قد يؤدي إلى ترتيب مختلف تمامًا، مما يثير جوهر المشكلة، وهو أن اختيار نقطة الربط الديناميكية والمحددة هو أمر ضروري لحل التوافق، ويحتاج المدققون إلى التوصل إلى توافق حول التاريخ المرتب لاختيار نقاط الربط المستقبلية.
كدليل على صعوبة المشكلة، نلاحظ أن تنفيذ Bullshark، بما في ذلك التنفيذ الحالي في بيئة الإنتاج، لا يدعم هذه الميزات.
البروتوكول
على الرغم من التحديات المذكورة أعلاه، إلا أن الحقيقة تشير إلى أن الحلول مخفية في البساطة.
في Shoal، نعتمد على القدرة على تنفيذ الحسابات المحلية على DAG، ونحقق القدرة على حفظ وإعادة تفسير المعلومات من الجولات السابقة. بفضل توافق جميع المدققين على الفهم الأساسي للنقطة المرجعية المترتبة الأولى، يقوم Shoal بترتيب وتجميع عدة أمثلة من Bullshark ومعالجتها بشكل متسلسل، مما يجعل ( النقطة المرجعية المترتبة الأولى نقطة تحول للمثال، و ) التاريخ السببي للنقطة المرجعية يُستخدم في حساب سمعة القائد.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
خط الإنتاج
V تربط بين الأدوار والقادة. يعمل Shoal واحدًا تلو الآخر على تشغيل حالات Bullshark، بحيث يتم تحديد الربط مسبقًا بواسطة الخريطة F لكل حالة. يقوم كل حالة بطلب ربط، مما يؤدي إلى الانتقال إلى الحالة التالية.
في البداية، أطلق Shoal أول مثيل لـ Bullshark في الجولة الأولى من DAG واستمر في تشغيله حتى تم تحديد أول نقطة ربط مرتبة، مثل في الجولة r. وافق جميع المدققين على هذه النقطة الربط. وبالتالي، يمكن لجميع المدققين أن يتفقوا بشكل مؤكد على إعادة تفسير DAG بدءًا من الجولة r+1. أطلق Shoal فقط مثيلًا جديدًا لـ Bullshark في الجولة r+1.
في أفضل الحالات، يسمح هذا لشول بطلب مرساة في كل جولة. يتم ترتيب نقاط المرسى في الجولة الأولى حسب المثال الأول. بعد ذلك، يبدأ شول مثالا جديدا في الجولة الثانية، والذي يحتوي على نقطة مرسى خاصة به، ويتم ترتيب هذه المرسى حسب هذا المثال، ثم يتم طلب نقطة مرسى جديدة في الجولة الثالثة، ثم تستمر هذه العملية.
سمعة القادة
عند تخطي نقاط الربط خلال ترتيب Bullshark، سيزداد وقت الإستجابة. في هذه الحالة، تكون تقنية خطوط الأنابيب عديمة الفائدة، لأن لا يمكن بدء مثيل جديد قبل طلب نقطة الربط السابقة. تضمن Shoal من خلال استخدام آلية السمعة تخصيص درجة لكل عقدة تحقق بناءً على تاريخ النشاط الأخير لكل عقدة، مما يجعل من غير المحتمل اختيار القادة المعنيين في المستقبل للتعامل مع نقاط الربط المفقودة. سيحصل المصدقون الذين يستجيبون ويشاركون في البروتوكول على درجات عالية، وإلا، سيتم تخصيص درجات منخفضة لعقدة التحقق، لأنها قد تنهار أو تكون بطيئة أو تتصرف بسوء.
فكرتها هي إعادة حساب التعيين المحدد F من الجولة إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث النقاط، مع تفضيل القائد الذي حصل على درجة أعلى. لكي يتوصل المدققون إلى توافق في الآراء حول التعيين الجديد، ينبغي عليهم التوصل إلى توافق حول النقاط، وبالتالي الوصول إلى توافق حول التاريخ المستخدم لاشتقاق النقاط.
في Shoal، يمكن أن تتكامل خطوط الأنابيب وسمعة القيادة بشكل طبيعي، لأنها تستخدم نفس التكنولوجيا الأساسية، وهي إعادة تفسير DAG بعد التوصل إلى توافق حول أول نقطة ربط مرتبة.
في الواقع، الاختلاف الوحيد هو أنه بعد ترتيب النقاط المرجعية في الجولة r، يحتاج المصدقون فقط إلى حساب التعيين الجديد F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي للنقاط المرجعية المرتبة في الجولة r. ثم، يبدأ عقدة التحقق في استخدام دالة اختيار النقاط المرجعية المحدثة F' لتنفيذ مثيل جديد من Bullshark بدءًا من الجولة r+1.
لا مزيد من وقت الإستجابة
تلعب مدة الانتظار دورًا حاسمًا في جميع تنفيذات BFT القابلة للتحديد المعتمدة على القائد. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى إدارة ومراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب المزيد من تقنيات المراقبة.
سيزيد وقت الاستجابة أيضًا بشكل كبير ، لأن تكوينها بشكل صحيح مهم للغاية وغالبًا ما يحتاج إلى تعديل ديناميكي ، لأنه يعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي ، ستدفع البروتوكول عقوبة وقت الاستجابة الكامل للقائد الذي به خلل. لذلك ، يجب ألا تكون إعدادات وقت الاستجابة متحفظة للغاية ، ولكن إذا كان وقت الاستجابة قصيرًا جدًا ، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال ، لاحظنا أنه في حالات الحمل العالي ، Jolteon/