إطار Shoal: كيفية اسقاط وقت الإستجابة Bullshark على Aptos
حل مختبرات Aptos مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى اسقاط كبير في وقت الإستجابة، وأزال لأول مرة الحاجة إلى مهلة في بروتوكول فعلي حتمي. بشكل عام، قام إطار Shoal بتحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالات عدم الفشل و80% في حالات الفشل.
Shoal هو إطار يعزز بروتوكول الإجماع القائم على Narwhal من خلال خط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). يقوم خط الأنابيب بتقليل وقت الإستجابة لترتيب DAG من خلال إدخال نقطة مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت من خلال ضمان ارتباط النقاط المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، فإن سمعة القادة تمكن Shoal من الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي تتضمن وقت المستجيب. وهذا يسمح لـ Shoal بتقديم خاصية نسميها الاستجابة العالمية، التي تحتوي على الاستجابة المتفائلة التي تتطلب عادة.
تقنية Shoal بسيطة للغاية، حيث تتضمن تشغيل عدة مثيلات من البروتوكولات الأساسية واحدًا تلو الآخر بالترتيب. لذلك، عندما نقوم بتجسيد Bullshark، نحصل على مجموعة من "القرش" الذين يتنافسون في سباق التتابع.
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا يهتمون بإسقاط تعقيد الاتصالات. ومع ذلك، لم تؤدِ هذه الطريقة إلى تحسين كبير في الإنتاجية. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
أدى الاختراق الأخير إلى إدراك أن انتشار البيانات هو العائق الرئيسي القائم على بروتوكول القيادة، ويمكن أن يستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات ومنطق الإجماع الأساسي، ويقدم هيكلًا حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية أقل من البيانات الوصفية. تسجل ورقة Narwhal سعة 160,000 TPS.
قدمت Aptos سابقاً Quorum Store، وهو تنفيذهم لـ Narwhal، الذي يفصل بين نشر البيانات والتوافق، ويستخدم لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القائد، يجمع بين مسار Tendermint السريع الخطي وتغيير وجهات نظر بأسلوب PBFT، مما يقلل وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، لا يمكن لبروتوكولات التوافق القائمة على القائد الاستفادة الكاملة من إمكانيات إنتاج Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررت Aptos نشر Bullshark، وهو بروتوكول إجماع بدون تكلفة اتصال، على Narwhal DAG. للأسف، مقارنةً بـ Jolteon، هيكل DAG الذي يدعم Bullshark ذو الإنتاجية العالية يأتي بتكلفة تأخير بنسبة 50٪.
تستعرض هذه المقالة كيف يمكن لشوغال تقليل وقت الإستجابة لبولشارك بشكل كبير.
خلفية DAG-BFT
يرتبط كل رأس في DAG وحيد القرن بدورة معينة. لكي يدخل في الجولة r، يجب على المدقق أولاً الحصول على n-f رأسًا ينتمي إلى الجولة r-1. يمكن لكل مدقق في كل جولة بث رأس واحد، ويجب أن يشير كل رأس على الأقل إلى n-f رأسًا من الجولة السابقة. نظرًا للاختلاف الزمني في الشبكة، قد يلاحظ المدققون المختلفون في أي نقطة زمنية مشاهدات محلية مختلفة لـ DAG.
خاصية رئيسية من DAG ليست غامضة: إذا كان لدى اثنين من عقد التحقق نفس الرأس v في رؤيتهما المحلية لـ DAG، فإن لهما تاريخ سببي v متطابق تمامًا.
ترتيب الفهرس
يمكن تحقيق توافق بشأن الترتيب الإجمالي لجميع رؤوس DAG دون أي تكاليف اتصال إضافية. لهذا السبب، يقوم المدققون في DAG-Rider وTusk وBullshark بتفسير هيكل DAG كبروتوكول إجماع، حيث تمثل الرؤوس الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق التقاطع الجماعي في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع المعتمدة على Narwhal الحالية تتمتع بالهيكل التالي:
نقطة الربط المحجوزة: كل بضع جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد مسبقًا، قمة القائد تُعرف بنقطة الربط.
نقاط الربط المرتبة: يقرر المدققون بشكل مستقل ولكن بشكل حاسم أي نقاط ربط يجب ترتيبها وأي نقاط ربط يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة الخاصة بهم واحدًا تلو الآخر، ولكل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخهم السببي وفقًا لبعض القواعد المحددة.
المفتاح لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تقوم بإنشاء قائمة نقاط مرجعية مرتبة في الخطوة (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 ومعالجتها بالتتابع، مما يجعل ( النقطة المرجعية المرتبة الأولى نقطة التحول للمثيلات، وكذلك ) التاريخ السببي للنقاط المرجعية المستخدمة لحساب سمعة القائد.
( خط التجميع
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. ثم، تبدأ العقدة المدققة من الجولة r+1 باستخدام وظيفة اختيار النقاط المرجعية المحدثة F' لتنفيذ实例 جديد لBullshark.
![شرح شامل لإطار عمل Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp###
( لا مزيد من وقت الإستجابة
تلعب مهلة الوقت دورًا حيويًا في جميع تنفيذات BFT المتزامنة القائمة على القيادة. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب تقنيات مراقبة أكثر.
سيؤدي وقت الإستجابة أيضًا إلى زيادة كبيرة في وقت الإستجابة، لأن تكوينها بشكل مناسب مهم جدًا، وعادةً ما يحتاج إلى تعديل ديناميكي، لأنه يعتمد بشكل كبير على البيئة ) الشبكة ###. قبل الانتقال إلى الزعيم التالي، سيتعين على البروتوكول دفع عقوبة وقت الإستجابة الكامل للزعيم المعطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة محافظة جدًا، ولكن إذا كانت مدة وقت الإستجابة قصيرة جدًا، فقد يكون البروتوكول
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 11
أعجبني
11
8
مشاركة
تعليق
0/400
CryptoGoldmine
· منذ 15 س
80% من وقت الإستجابة المحسّن تقنيًا قريب من نسبة التكلفة إلى العائد المثالية
شاهد النسخة الأصليةرد0
just_here_for_vibes
· 07-27 18:20
هل هناك تحسينات في الأداء بهذا القدر؟ دعونا نجرب.
شاهد النسخة الأصليةرد0
BridgeNomad
· 07-26 20:35
همم... يبدو أن وقت الإستجابة المحسن جيد ولكن لا يزال بحاجة للتحقق من تلك المتجهات الثقة بصراحة
إطار Shoal أسقط وقت الإستجابة Bullshark داخل السلسلة Aptos
إطار Shoal: كيفية اسقاط وقت الإستجابة Bullshark على Aptos
حل مختبرات Aptos مشكلتين مفتوحتين هامتين في DAG BFT، مما أدى إلى اسقاط كبير في وقت الإستجابة، وأزال لأول مرة الحاجة إلى مهلة في بروتوكول فعلي حتمي. بشكل عام، قام إطار Shoal بتحسين وقت الإستجابة لـ Bullshark بنسبة 40% في حالات عدم الفشل و80% في حالات الفشل.
Shoal هو إطار يعزز بروتوكول الإجماع القائم على Narwhal من خلال خط الأنابيب وسمعة القادة ( مثل DAG-Rider و Tusk و Bullshark ). يقوم خط الأنابيب بتقليل وقت الإستجابة لترتيب DAG من خلال إدخال نقطة مرجعية في كل جولة، بينما تعمل سمعة القادة على تحسين مشكلة الوقت من خلال ضمان ارتباط النقاط المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، فإن سمعة القادة تمكن Shoal من الاستفادة من بناء DAG غير المتزامن للقضاء على جميع السيناريوهات التي تتضمن وقت المستجيب. وهذا يسمح لـ Shoal بتقديم خاصية نسميها الاستجابة العالمية، التي تحتوي على الاستجابة المتفائلة التي تتطلب عادة.
تقنية Shoal بسيطة للغاية، حيث تتضمن تشغيل عدة مثيلات من البروتوكولات الأساسية واحدًا تلو الآخر بالترتيب. لذلك، عندما نقوم بتجسيد Bullshark، نحصل على مجموعة من "القرش" الذين يتنافسون في سباق التتابع.
الخلفية
عند السعي لتحقيق أداء عالٍ لشبكة blockchain، كان الناس دائمًا يهتمون بإسقاط تعقيد الاتصالات. ومع ذلك، لم تؤدِ هذه الطريقة إلى تحسين كبير في الإنتاجية. على سبيل المثال، حقق Hotstuff الذي تم تنفيذه في الإصدارات المبكرة من Diem فقط 3500 TPS، وهو أقل بكثير من الهدف البالغ 100k+ TPS.
أدى الاختراق الأخير إلى إدراك أن انتشار البيانات هو العائق الرئيسي القائم على بروتوكول القيادة، ويمكن أن يستفيد من التوازي. يفصل نظام Narwhal بين انتشار البيانات ومنطق الإجماع الأساسي، ويقدم هيكلًا حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما يقوم مكون الإجماع بترتيب كمية أقل من البيانات الوصفية. تسجل ورقة Narwhal سعة 160,000 TPS.
قدمت Aptos سابقاً Quorum Store، وهو تنفيذهم لـ Narwhal، الذي يفصل بين نشر البيانات والتوافق، ويستخدم لتوسيع بروتوكول التوافق الحالي Jolteon. Jolteon هو بروتوكول قائم على القائد، يجمع بين مسار Tendermint السريع الخطي وتغيير وجهات نظر بأسلوب PBFT، مما يقلل وقت الإستجابة لـ Hotstuff بنسبة 33%. ومع ذلك، لا يمكن لبروتوكولات التوافق القائمة على القائد الاستفادة الكاملة من إمكانيات إنتاج Narwhal. على الرغم من فصل نشر البيانات عن التوافق، إلا أن القائد في Hotstuff/Jolteon لا يزال مقيدًا مع زيادة الإنتاجية.
لذلك، قررت Aptos نشر Bullshark، وهو بروتوكول إجماع بدون تكلفة اتصال، على Narwhal DAG. للأسف، مقارنةً بـ Jolteon، هيكل DAG الذي يدعم Bullshark ذو الإنتاجية العالية يأتي بتكلفة تأخير بنسبة 50٪.
تستعرض هذه المقالة كيف يمكن لشوغال تقليل وقت الإستجابة لبولشارك بشكل كبير.
خلفية DAG-BFT
يرتبط كل رأس في DAG وحيد القرن بدورة معينة. لكي يدخل في الجولة r، يجب على المدقق أولاً الحصول على n-f رأسًا ينتمي إلى الجولة r-1. يمكن لكل مدقق في كل جولة بث رأس واحد، ويجب أن يشير كل رأس على الأقل إلى n-f رأسًا من الجولة السابقة. نظرًا للاختلاف الزمني في الشبكة، قد يلاحظ المدققون المختلفون في أي نقطة زمنية مشاهدات محلية مختلفة لـ DAG.
خاصية رئيسية من DAG ليست غامضة: إذا كان لدى اثنين من عقد التحقق نفس الرأس v في رؤيتهما المحلية لـ DAG، فإن لهما تاريخ سببي v متطابق تمامًا.
ترتيب الفهرس
يمكن تحقيق توافق بشأن الترتيب الإجمالي لجميع رؤوس DAG دون أي تكاليف اتصال إضافية. لهذا السبب، يقوم المدققون في DAG-Rider وTusk وBullshark بتفسير هيكل DAG كبروتوكول إجماع، حيث تمثل الرؤوس الاقتراحات، وتمثل الحواف التصويت.
على الرغم من أن منطق التقاطع الجماعي في هيكل DAG مختلف، إلا أن جميع بروتوكولات الإجماع المعتمدة على Narwhal الحالية تتمتع بالهيكل التالي:
نقطة الربط المحجوزة: كل بضع جولات ( مثل جولتين في Bullshark ) سيكون هناك قائد محدد مسبقًا، قمة القائد تُعرف بنقطة الربط.
نقاط الربط المرتبة: يقرر المدققون بشكل مستقل ولكن بشكل حاسم أي نقاط ربط يجب ترتيبها وأي نقاط ربط يجب تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة نقاط الربط المرتبة الخاصة بهم واحدًا تلو الآخر، ولكل نقطة ربط، يتم ترتيب جميع الرؤوس غير المرتبة السابقة في تاريخهم السببي وفقًا لبعض القواعد المحددة.
المفتاح لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تقوم بإنشاء قائمة نقاط مرجعية مرتبة في الخطوة (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 ومعالجتها بالتتابع، مما يجعل ( النقطة المرجعية المرتبة الأولى نقطة التحول للمثيلات، وكذلك ) التاريخ السببي للنقاط المرجعية المستخدمة لحساب سمعة القائد.
( خط التجميع
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. ثم، تبدأ العقدة المدققة من الجولة r+1 باستخدام وظيفة اختيار النقاط المرجعية المحدثة F' لتنفيذ实例 جديد لBullshark.
![شرح شامل لإطار عمل Shoal: كيف يمكن تقليل وقت الإستجابة لـ Bullshark على Aptos؟])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp###
( لا مزيد من وقت الإستجابة
تلعب مهلة الوقت دورًا حيويًا في جميع تنفيذات BFT المتزامنة القائمة على القيادة. ومع ذلك، فإن التعقيد الذي تقدمه يزيد من عدد الحالات الداخلية التي تحتاج إلى الإدارة والمراقبة، مما يزيد من تعقيد عملية تصحيح الأخطاء، ويتطلب تقنيات مراقبة أكثر.
سيؤدي وقت الإستجابة أيضًا إلى زيادة كبيرة في وقت الإستجابة، لأن تكوينها بشكل مناسب مهم جدًا، وعادةً ما يحتاج إلى تعديل ديناميكي، لأنه يعتمد بشكل كبير على البيئة ) الشبكة ###. قبل الانتقال إلى الزعيم التالي، سيتعين على البروتوكول دفع عقوبة وقت الإستجابة الكامل للزعيم المعطل. لذلك، لا يمكن أن تكون إعدادات وقت الإستجابة محافظة جدًا، ولكن إذا كانت مدة وقت الإستجابة قصيرة جدًا، فقد يكون البروتوكول