إطار Shoal: حل مبتكر لتقليل وقت الإستجابة Bullshark على Aptos
حققت Aptos Labs مؤخرًا تقدمًا كبيرًا في مجال DAG BFT، حيث حلت مشكلتين رئيسيتين، مما أدى إلى تقليل وقت الإستجابة بشكل ملحوظ، وألغت الحاجة إلى المهلة لأول مرة في بروتوكولات الحسم. بشكل عام، ارتفع وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار يعزز أي بروتوكول إجماع قائم على Narwhal مثل DAG-Rider و Tusk و Bullshark ( من خلال معالجة خط الأنابيب وسمعة القائد. تقلل معالجة خط الأنابيب من وقت الإستجابة من خلال إدخال نقاط الربط في كل جولة، بينما تحسن سمعة القائد وقت الإستجابة من خلال ضمان ارتباط نقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك، تمكن سمعة القائد Shoal من الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات المتعلقة بالمهل. وهذا يسمح لـ Shoal بتقديم خاصية نسميها "الاستجابة العامة"، التي تتضمن الاستجابة التفاؤلية المطلوبة عادة.
تقنيتنا بسيطة جدًا، فهي في جوهرها عبارة عن عدة أمثلة من البروتوكولات الأساسية تعمل بالتسلسل. لذلك، عندما يتم إنشاء مثيل من Bullshark، نحصل على مجموعة من "أسماك القرش" التي تجري في سباق التتابع.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
الخلفية والدافع
في سعيها لتحقيق أداء عالٍ لشبكة البلوكشين، كانت تقليل تعقيد الاتصالات دائمًا محور التركيز، ولكن هذه الطريقة لم تحقق زيادة ملحوظة في الإنتاجية. على سبيل المثال، حقق الإصدار المبكر من Diem والذي تم تنفيذه باستخدام Hotstuff فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100000+ 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.
تتناول هذه المقالة كيفية تقليل وقت الإستجابة لـ Bullshark بشكل كبير بواسطة Shoal.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة. للدخول إلى الجولة r، يجب على المحققين أولاً الحصول على n-f رأسًا من الجولة r-1. يمكن لكل محقق بث رأس واحد في كل جولة، ويجب أن يشير كل رأس على الأقل إلى n-f رأسًا من الجولة السابقة. نظرًا للاختلاف الزمني في الشبكة، قد يلاحظ المحققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
خاصية رئيسية لـ DAG هي عدم الغموض: إذا كان لدى عقدتي التحقق نفس الرأس v في عرض DAG المحلي الخاص بهما، فإنهما تمتلكان تاريخ سببي v متطابق تمامًا.
![شرح مفصل عن إطار Shoal: كيف تقلل وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
الترتيب العام
يمكن تحقيق توافق إجماعي على الترتيب الكلي لجميع القمم في DAG دون أي تكاليف اتصالات إضافية. لهذا السبب، يقوم المدققون في DAG-Rider وTusk وBullshark بتفسير بنية DAG كبروتوكول إجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف الأصوات.
على الرغم من اختلاف منطق تقاطع المجموعات في هيكل DAG، إلا أن جميع بروتوكولات الإجماع الحالية المستندة إلى Narwhal تتمتع بالهيكل التالي:
نقاط الربط المحجوزة: كل عدة جولات ) مثل جولتين في Bullshark ( سيكون هناك قائد محدد مسبقًا، ويطلق على قمته نقطة الربط.
نقاط الترتيب: يقوم المُحققون بتحديد أي النقاط يجب ترتيبها وأي النقاط يجب تجاوزها بشكل مستقل ولكن بحسم.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، ولأجل كل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخها السببي وفقاً لبعض القواعد الحتمية.
المفتاح لضمان الأمان هو التأكد من أن قائمة نقاط التثبيت المرتبة التي أنشأتها جميع عقد التحقق الصادقة تشترك في نفس البادئة في الخطوة )2(. في Shoal، نقوم بالتعليق على جميع البروتوكولات المذكورة أعلاه كما يلي:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullsharkوقت الإستجابة
تعتمد وقت الإستجابة ل Bullshark على عدد الدورات بين النقاط المرسخة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية من Bullshark تتمتع بوقت إستجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة ربط في كل دورة زوجية، ويتم تفسير قمة كل دورة فردية على أنها تصويت. في الحالات الشائعة، يتطلب الأمر دورتين من DAG لترتيب نقاط الربط، ومع ذلك، يحتاج القمة في التاريخ السببي لنقاط الربط إلى مزيد من الدورات للانتظار حتى يتم ترتيب نقاط الربط. في الحالات الشائعة، تحتاج القمة في الدورات الفردية إلى ثلاث دورات، بينما تحتاج القمم غير المرتبطة في الدورات الزوجية إلى أربع دورات.
السؤال 2: وقت الإستجابة حالات الخطأ. ينطبق تحليل الوقت الإستجابة أعلاه على الحالات الخالية من الأخطاء، من ناحية أخرى، إذا فشل القائد في الجولة في بث النقاط الأساسية بسرعة كافية، فلن يمكن ترتيب النقاط الأساسية ) وبالتالي يتم تخطيها (، وبالتالي يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة الأساسية التالية. هذا سيقلل بشكل كبير من أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم الوقت المستغرق للانتظار للقائد.
![شرح مفصل لإطار عمل Shoal: كيف تقلل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
إطار 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-46d37add0d9e81b2f295edf8eddd907f.webp(
) معالجة خط التدفق
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.
لا مزيد من وقت الإستجابة
تلعب مهلة الوقت الإستجابة دورًا حيويًا في جميع تطبيقات BFT المحددة القائمة على القيادة. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب تقنيات مراقبة أكثر.
سيؤدي انتهاء الوقت أيضًا إلى زيادة وقت الإستجابة بشكل كبير، لأنه من المهم تكوينها بشكل صحيح وغالبًا ما تحتاج إلى تعديل ديناميكي، لأنها تعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستدفع البروتوكول عقوبة كاملة على وقت الإستجابة للقائد الذي به عطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة متحفظة للغاية، ولكن إذا كان وقت الإستجابة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في الحالات ذات الأحمال العالية، كان القادة في Jolteon/Hotstuff مثقلين، وقد انتهى وقت الإستجابة قبل أن يدفعوا للتقدم.
لسوء الحظ، فإن اتفاقية القائد ### مثل Hotstuff و Jolteon ( تحتاج أساسًا إلى وقت الإستجابة لضمان أن كل مرة يحدث فيها فشل للقائد
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 13
أعجبني
13
6
إعادة النشر
مشاركة
تعليق
0/400
SandwichDetector
· 08-12 06:15
تحسين الأداء حقًا ثور، زيادة بنسبة 80% أمر لا يصدق.
شاهد النسخة الأصليةرد0
NFTRegretful
· 08-12 06:15
يبدو أن الأمور جيدة، لكن السرعة ليست كافية بعد.
شاهد النسخة الأصليةرد0
BearMarketSurvivor
· 08-12 05:55
وقت الإستجابة اسقاط 80% هذا هو القوة الصلبة في ساحة المعركة، نتطلع إلى الأداء في المعركة.
شاهد النسخة الأصليةرد0
CoinBasedThinking
· 08-12 05:54
مشروع موثوق ترقية تقنية آمل أن لا يكون بداية قوية ونهاية ضعيفة
تحسين كفاءة الإجماع Aptos من خلال إطار Shoal ، اسقاط Bullshark بنسبة 80%
إطار Shoal: حل مبتكر لتقليل وقت الإستجابة Bullshark على Aptos
حققت Aptos Labs مؤخرًا تقدمًا كبيرًا في مجال DAG BFT، حيث حلت مشكلتين رئيسيتين، مما أدى إلى تقليل وقت الإستجابة بشكل ملحوظ، وألغت الحاجة إلى المهلة لأول مرة في بروتوكولات الحسم. بشكل عام، ارتفع وقت الإستجابة لـ Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
Shoal هو إطار يعزز أي بروتوكول إجماع قائم على Narwhal مثل DAG-Rider و Tusk و Bullshark ( من خلال معالجة خط الأنابيب وسمعة القائد. تقلل معالجة خط الأنابيب من وقت الإستجابة من خلال إدخال نقاط الربط في كل جولة، بينما تحسن سمعة القائد وقت الإستجابة من خلال ضمان ارتباط نقاط الربط بأسرع عقد تحقق. بالإضافة إلى ذلك، تمكن سمعة القائد Shoal من الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات المتعلقة بالمهل. وهذا يسمح لـ Shoal بتقديم خاصية نسميها "الاستجابة العامة"، التي تتضمن الاستجابة التفاؤلية المطلوبة عادة.
تقنيتنا بسيطة جدًا، فهي في جوهرها عبارة عن عدة أمثلة من البروتوكولات الأساسية تعمل بالتسلسل. لذلك، عندما يتم إنشاء مثيل من Bullshark، نحصل على مجموعة من "أسماك القرش" التي تجري في سباق التتابع.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
الخلفية والدافع
في سعيها لتحقيق أداء عالٍ لشبكة البلوكشين، كانت تقليل تعقيد الاتصالات دائمًا محور التركيز، ولكن هذه الطريقة لم تحقق زيادة ملحوظة في الإنتاجية. على سبيل المثال، حقق الإصدار المبكر من Diem والذي تم تنفيذه باستخدام Hotstuff فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100000+ 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.
تتناول هذه المقالة كيفية تقليل وقت الإستجابة لـ Bullshark بشكل كبير بواسطة Shoal.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة. للدخول إلى الجولة r، يجب على المحققين أولاً الحصول على n-f رأسًا من الجولة r-1. يمكن لكل محقق بث رأس واحد في كل جولة، ويجب أن يشير كل رأس على الأقل إلى n-f رأسًا من الجولة السابقة. نظرًا للاختلاف الزمني في الشبكة، قد يلاحظ المحققون المختلفون وجهات نظر محلية مختلفة لـ DAG في أي نقطة زمنية.
خاصية رئيسية لـ DAG هي عدم الغموض: إذا كان لدى عقدتي التحقق نفس الرأس v في عرض DAG المحلي الخاص بهما، فإنهما تمتلكان تاريخ سببي v متطابق تمامًا.
![شرح مفصل عن إطار Shoal: كيف تقلل وقت الإستجابة لBullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
الترتيب العام
يمكن تحقيق توافق إجماعي على الترتيب الكلي لجميع القمم في DAG دون أي تكاليف اتصالات إضافية. لهذا السبب، يقوم المدققون في DAG-Rider وTusk وBullshark بتفسير بنية DAG كبروتوكول إجماع، حيث تمثل القمم الاقتراحات، وتمثل الحواف الأصوات.
على الرغم من اختلاف منطق تقاطع المجموعات في هيكل DAG، إلا أن جميع بروتوكولات الإجماع الحالية المستندة إلى Narwhal تتمتع بالهيكل التالي:
نقاط الربط المحجوزة: كل عدة جولات ) مثل جولتين في Bullshark ( سيكون هناك قائد محدد مسبقًا، ويطلق على قمته نقطة الربط.
نقاط الترتيب: يقوم المُحققون بتحديد أي النقاط يجب ترتيبها وأي النقاط يجب تجاوزها بشكل مستقل ولكن بحسم.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة واحدة تلو الأخرى، ولأجل كل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخها السببي وفقاً لبعض القواعد الحتمية.
المفتاح لضمان الأمان هو التأكد من أن قائمة نقاط التثبيت المرتبة التي أنشأتها جميع عقد التحقق الصادقة تشترك في نفس البادئة في الخطوة )2(. في Shoal، نقوم بالتعليق على جميع البروتوكولات المذكورة أعلاه كما يلي:
جميع المدققين يتفقون على أول نقطة ربط مرتبة.
Bullsharkوقت الإستجابة
تعتمد وقت الإستجابة ل Bullshark على عدد الدورات بين النقاط المرسخة المرتبة في DAG. على الرغم من أن النسخة المتزامنة الأكثر عملية من Bullshark تتمتع بوقت إستجابة أفضل من النسخة غير المتزامنة، إلا أنها لا تزال بعيدة عن المثالية.
السؤال 1: متوسط وقت الإستجابة للكتل. في Bullshark، يوجد نقطة ربط في كل دورة زوجية، ويتم تفسير قمة كل دورة فردية على أنها تصويت. في الحالات الشائعة، يتطلب الأمر دورتين من DAG لترتيب نقاط الربط، ومع ذلك، يحتاج القمة في التاريخ السببي لنقاط الربط إلى مزيد من الدورات للانتظار حتى يتم ترتيب نقاط الربط. في الحالات الشائعة، تحتاج القمة في الدورات الفردية إلى ثلاث دورات، بينما تحتاج القمم غير المرتبطة في الدورات الزوجية إلى أربع دورات.
السؤال 2: وقت الإستجابة حالات الخطأ. ينطبق تحليل الوقت الإستجابة أعلاه على الحالات الخالية من الأخطاء، من ناحية أخرى، إذا فشل القائد في الجولة في بث النقاط الأساسية بسرعة كافية، فلن يمكن ترتيب النقاط الأساسية ) وبالتالي يتم تخطيها (، وبالتالي يجب على جميع القمم غير المرتبة في الجولات السابقة الانتظار حتى يتم ترتيب النقطة الأساسية التالية. هذا سيقلل بشكل كبير من أداء شبكة النسخ الجغرافي، خاصة لأن Bullshark تستخدم الوقت المستغرق للانتظار للقائد.
![شرح مفصل لإطار عمل Shoal: كيف تقلل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
إطار 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-46d37add0d9e81b2f295edf8eddd907f.webp(
) معالجة خط التدفق
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.
لا مزيد من وقت الإستجابة
تلعب مهلة الوقت الإستجابة دورًا حيويًا في جميع تطبيقات BFT المحددة القائمة على القيادة. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية التصحيح، ويتطلب تقنيات مراقبة أكثر.
سيؤدي انتهاء الوقت أيضًا إلى زيادة وقت الإستجابة بشكل كبير، لأنه من المهم تكوينها بشكل صحيح وغالبًا ما تحتاج إلى تعديل ديناميكي، لأنها تعتمد بشكل كبير على البيئة ( الشبكة ). قبل الانتقال إلى القائد التالي، ستدفع البروتوكول عقوبة كاملة على وقت الإستجابة للقائد الذي به عطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة متحفظة للغاية، ولكن إذا كان وقت الإستجابة قصيرًا جدًا، فقد يتخطى البروتوكول القادة الجيدين. على سبيل المثال، لاحظنا أنه في الحالات ذات الأحمال العالية، كان القادة في Jolteon/Hotstuff مثقلين، وقد انتهى وقت الإستجابة قبل أن يدفعوا للتقدم.
لسوء الحظ، فإن اتفاقية القائد ### مثل Hotstuff و Jolteon ( تحتاج أساسًا إلى وقت الإستجابة لضمان أن كل مرة يحدث فيها فشل للقائد