اقترحت Aptos Labs مؤخرًا إطار العمل Shoal، والذي يهدف إلى حل مشكلتين رئيسيتين في إجماع DAG BFT، مما يقلل بشكل كبير من التأخير ويقضي لأول مرة على الاعتماد على المهلات في البروتوكولات غير المتزامنة الحتمية. بشكل عام، يزيد Shoal تأخير Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
تعزز Shoal بروتوكول الإجماع القائم على Narwhal باستخدام نظام خط الأنابيب وآلية سمعة القادة ( مثل DAG-Rider و Tusk و Bullshark وغيرها ). تعمل تقنية خط الأنابيب على تقليل تأخير ترتيب DAG من خلال إدخال نقطة مرجعية في كل جولة، بينما تعمل آلية سمعة القادة على تحسين التأخير بشكل أكبر من خلال ضمان ارتباط النقطة المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من البناء غير المتزامن لـ DAG للقضاء على جميع السيناريوهات التي تؤدي إلى انقضاء الوقت، مما يحقق استجابة شاملة.
الفكرة الأساسية لـ Shoal هي تشغيل عدة مثيلات من البروتوكول الأساسي بالتسلسل. كمثال على ذلك Bullshark، يمكن تصورها كمجموعة من "القرش" التي تتسابق في سباق التتابع.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
الدافع
شبكة البلوكتشين كانت تسعى دائماً لتحقيق أداء أعلى، وكانت تركز في البداية على تقليل تعقيد الاتصالات. ومع ذلك، لم تحقق هذه الطريقة زيادة ملحوظة في معدل المعالجة. على سبيل المثال، فإن Hotstuff الذي تم تنفيذه في النسخة المبكرة من Diem لم يحقق سوى 3500 TPS، وهو أقل بكثير من الهدف المتمثل في 100,000+ TPS.
أحدثت الاختراقات الأخيرة من خلال إدراك أن انتشار البيانات هو العائق الرئيسي القائم على بروتوكول القادة، ويمكن الاستفادة منه من خلال التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن منطق الإجماع الأساسي، ويقترح بنية حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما تقوم مكونات الإجماع بفرز كمية صغيرة فقط من البيانات الوصفية، مما يحقق قدرة معالجة تصل إلى 160 ألف معاملة في الثانية.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ لـ Narwhal، الذي يفصل بين نشر البيانات والإجماع، ويستخدم لتوسيع بروتوكول الإجماع الحالي Jolteon. يجمع Jolteon بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه الاستفادة الكاملة من إمكانيات الإنتاجية لـ Narwhal.
لذلك، قررت Aptos نشر Bullshark فوق Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. لكن دعم Bullshark لهيكل DAG عالي الإنتاجية أدى إلى تكلفة تأخير بنسبة 50%. الهدف من إطار Shoal هو تقليل تأخير Bullshark بشكل كبير.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة معينة. للدخول في الجولة r، يجب أولاً الحصول على n-f من الرؤوس في الجولة r-1. يمكن لكل مُحقق بث رأس واحد في كل جولة، ويجب أن يُشير كل رأس على الأقل إلى n-f من الرؤوس في الجولة السابقة. بسبب عدم تزامن الشبكة، قد يلاحظ المحققون المختلفون وجهات نظر DAG محلية مختلفة.
أحد الخصائص الرئيسية لـ DAG هو عدم الغموض: إذا كان لدى اثنين من عقد التحقق نفس الرأس v في عرض DAG المحلي، فإنهما يمتلكان تاريخًا سببيًا متطابقًا تمامًا لـ v.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
الترتيب الكلي
يمكن تحقيق توافق على الترتيب الإجمالي لجميع الرؤوس في DAG دون أي تكلفة إضافية للتواصل. تفسر بروتوكولات مثل DAG-Rider وTusk وBullshark هيكل DAG كبروتوكول توافق، حيث تمثل الرؤوس الاقتراحات وتمثل الحواف التصويت.
على الرغم من أن المنطق المحدد مختلف، إلا أن جميع بروتوكولات الإجماع المعتمدة على Narwhal تتمتع بالهيكل التالي:
النقطة المحددة: كل بضع جولات يوجد زعيم محدد مسبقًا، وتسمى قمته النقطة المحددة.
نقاط الربط المرتبة: يحدد المدققون بشكل مستقل ولكن حاسم أي نقاط ربط يجب ترتيبها أو تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسومة المرتبة واحدة تلو الأخرى، وترتيب الرؤوس غير المرتبة مسبقًا في التاريخ السببي لكل نقطة مرسومة.
الشرط الأساسي لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تشارك قائمة نقاط الربط المرتبة التي تحمل نفس البادئة. يلاحظ شوال ملاحظة مهمة بشأن جميع هذه البروتوكولات: يتفق جميع المدققين على أول نقطة ربط مرتبة.
مشكلة تأخير Bullshark
تعتمد تأخيرات Bullshark على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن بعض إصدارات المزامنة لديها تأخير أقل من الإصدارات غير المتزامنة، إلا أنها لا تزال بعيدة عن الأمثل.
يوجد مشكلتان رئيسيتان:
متوسط تأخير الكتلة: في الحالات الشائعة، تحتاج رؤوس الدورات الفردية إلى ثلاث دورات لترتيبها، بينما تحتاج رؤوس الدورات الزوجية غير المرساة إلى أربع دورات.
تأخير حالة العطل: إذا فشل قائد الجولة في بث النقطة المرجعية في الوقت المناسب، فسيتم تخطي تلك النقطة المرجعية، ويجب على جميع القمم غير المرتبة من الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. هذا يقلل بشكل كبير من أداء الشبكة الموزعة جغرافياً، خاصةً لأن Bullshark تستخدم الانتظار حتى انتهاء المهلة للقائد.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
إطار Shoal
تعزز Shoal Bullshark( أو أي بروتوكول BFT قائم على Narwhal) من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط واحدة في كل جولة، مما يقلل من تأخير جميع القمم غير المرتبطة إلى ثلاث جولات. كما تقدم Shoal آلية سمعة القادة بدون تكلفة في DAG، مما يميل لاختيار القادة السريعين.
تحدي
يعتبر تنفيذ الخطوط المتوازية وسمعة القائد في بروتوكول DAG أمرًا صعبًا:
يبدو أن محاولة تعديل منطق Bullshark الأساسي غير ممكنة.
قد تؤدي سمعة القادة إلى ترتيبات مختلفة، ويحتاج المدققون إلى التوصل إلى توافق بشأن التاريخ المنظم لاختيار نقاط الربط المستقبلية.
كإثبات لصعوبة المشكلة، فإن تطبيق Bullshark في بيئة الإنتاج الحالية لا يدعم هذه الميزات.
بروتوكول
حلول Shoal بسيطة نسبياً. تستفيد من القدرة على تنفيذ حسابات محلية على DAG، مما يحقق وظيفة حفظ وإعادة تفسير معلومات الجولات السابقة. استنادًا إلى توافق جميع المدققين حول الرؤية الأولى لنقطة الربط المرتبة، تجمع Shoal بشكل متسلسل عدة مثيلات من Bullshark للمعالجة المتسلسلة، مما يجعل:
النقطة المرجعية المرتبة الأولى هي نقطة التحويل للتجربة
تاريخ السبب والنتيجة للنقطة المرجعية يُستخدم لحساب سمعة القادة
خط الإنتاج
V تربط الدور بقائد. تعمل Shoal بتسلسل على مثيلات Bullshark، حيث تقوم كل مثيل بترتيب نقطة تثبيت واحدة وتفعيل الانتقال إلى المثيل التالي.
بدأ Shoal من الجولة الأولى من DAG بتشغيل أول نسخة من Bullshark، حتى تم تحديد أول نقطة ربط مرتبة ( المفترضة في الجولة r ). اتفق جميع المدققين على هذه النقطة، وبالتالي يمكن باليقين الاتفاق على إعادة تفسير DAG من الجولة r+1. بدأ Shoal نسخة جديدة من Bullshark في الجولة r+1.
في الحالة المثالية، يسمح هذا لـ Shoal بترتيب نقطة ربط واحدة في كل جولة. يتم ترتيب نقطة الربط في الجولة الأولى بواسطة المثال الأول، ثم يبدأ المثال الجديد في ترتيب نقطة الربط لتلك الجولة في الجولة الثانية، وهكذا.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
سمعة القادة
عندما يقفز Bullshark فوق نقطة الربط، فإن التأخير سيزداد. تقنية خطوط الأنابيب لا تفيد في هذه الحالة، لأنه يجب الانتظار حتى ينتهي المثال السابق من ترتيب نقطة الربط قبل بدء مثال جديد. تقوم Shoal بتخصيص درجات لكل عقدة تحقق من خلال آلية السمعة، بناءً على تاريخ نشاطها الأخير. يحصل الموثقون الذين يستجيبون بسرعة على درجات عالية، بينما يحصل أولئك الذين لا يستجيبون بسرعة على درجات منخفضة.
الفكرة هي إعادة حساب خريطة F من الجولات إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث الدرجات، مع الميل نحو القادة ذوي الدرجات العالية. لكي يتوصل المدققون إلى توافق بشأن الخريطة الجديدة، يحتاجون إلى التوصل إلى توافق بشأن الدرجات، ومن ثم التوصل إلى توافق بشأن التاريخ المستخدم لاستنتاج الدرجات.
في Shoal، يمكن دمج سمعة خط الأنابيب والقائد بشكل طبيعي، حيث أنهما كلاهما يعتمد على إعادة تفسير DAG بعد الوصول إلى توافق عند أول نقطة ربط مرتبة. الاختلاف الوحيد هو أنه بعد نقطة الربط المرتبة في الجولة r، يقوم المدققون بحساب التمثيل الجديد F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي لتلك النقطة. ثم يتم تنفيذ مثيل Bullshark الجديد باستخدام F' المحدث بدءًا من الجولة r+1.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
إزالة المهلة
تعتبر المهلة أمرًا حاسمًا في جميع تطبيقات BFT القابلة للتحديد القائمة على القائد. ومع ذلك، فإنها تزيد من التعقيد، وتتطلب مزيدًا من إدارة الحالة الداخلية والمراقبة، مما يجعل من الصعب تصحيح الأخطاء.
سيؤدي تجاوز الوقت أيضًا إلى زيادة التأخير بشكل ملحوظ، لأن التكوين الصحيح مهم وغالبًا ما يحتاج إلى تعديلات ديناميكية. قبل الانتقال إلى القائد التالي، يتعين على البروتوكول دفع العقوبة الكاملة لتأخير تجاوز الوقت للقائد الذي يواجه مشكلة. لذلك، لا ينبغي أن تكون إعدادات تجاوز الوقت متحفظة للغاية، ولكن إذا كانت قصيرة جدًا، فقد يتم تخطي القادة الجيدين.
للأسف، تتطلب بروتوكولات القادة مثل Hotstuff و Jolteon ( أساسًا مهلة لضمان التقدم في حالة فشل القائد. إذا لم تكن هناك مهلة، حتى القائد المتعطل قد يتوقف عن تنفيذ البروتوكول إلى الأبد. نظرًا لعدم إمكانية التمييز بين الفشل والقادة البطيئين خلال فترة غير متزامنة، قد تؤدي المهلة إلى استبدال جميع القادة دون وجود نشاط إجماعي.
في Bullshark، يُستخدم المهلة لبناء DAG، لضمان أن القادة الأمناء يضيفون النقاط المرجعية إلى DAG بسرعة كافية أثناء التزامن.
لقد لاحظنا أن بناء DAG يوفر "ساعة" لتقدير سرعة الشبكة. طالما أن n-f من المدققين الأمناء يستمرون في إضافة رؤوس إلى DAG، سيتقدم الدور. على الرغم من أن Bullshark قد لا يكون قادرًا على ترتيب بسرعات الشبكة، إلا أن DAG لا يزال ينمو بسرعة الشبكة. في النهاية، عندما يقوم قائد غير معطل ببث النقطة المرجعية بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل للنقطة المرجعية.
في التقييم، قمنا بمقارنة Bullshark مع وبدون تجاوز للوقت:
القادة السريعون: طريقتان تؤجلان بنفس القدر، لأن النقاط المرجعية تم ترتيبها ولا تستخدم المهلة.
القادة الخاطئون: بدون تأخير Bullshark لأكثر من الوقت، لأن عقد التحقق سيتخطى نقاط الارتباط على الفور.
القادة البطيئون: أداء Bullshark أفضل مع وجود المهلة، لأن المدققين سينتظرون النقطة المرجعية، بينما قد يتجاهلون النقطة المرجعية بدون مهلة.
في Shoal، يتعلق تجنب المهلة ارتباطًا وثيقًا بسمعة القادة. إن الانتظار المتكرر لقادة بطيئين سيزيد من التأخير، بينما يستبعد آلية السمعة المُتحققين البطيئين من أن يتم اختيارهم كقادة. بهذه الطريقة، يمكن للنظام العمل بسرعة الشبكة في جميع السيناريوهات الواقعية.
من المهم ملاحظة أن نتيجة عدم إمكانية FLP تشير إلى أنه لا يوجد بروتوكول إجماع حتمي يمكنه تجنب المهلة بالكامل. لا يمكن لـ Shoal تجاوز هذه النتيجة، لأن هناك جدول زمني للأحداث العدائية يمكن أن يمنع ترتيب جميع النقاط المرجعية نظريًا. بدلاً من ذلك، بعد عدد محدد من تخطي النقاط المرجعية القابلة للتكوين، سترجع Shoal إلى المهلة. لكن من غير المحتمل أن يحدث هذا في الواقع.
) استجابة شاملة
أوراق Hotstuff روجت لمفهوم الاستجابة المتفائلة، مما يعني بشكل بديهي أن البروتوكول يمكن أن يعمل بسرعة الشبكة ### في الحالات الجيدة بما في ذلك القادة السريعين والشبكة المتزامنة (.
تقدم Shoal ميزة أفضل تُعرف بالاستجابة الشاملة. بشكل أكثر تحديدًا، مقارنة بـ Hotstuff، حتى إذا فشل القائد خلال عدد من الجولات المستمرة القابلة للتكوين أو واجهت الشبكة فترات غير متزامنة، فإن Shoal ستستمر في العمل بسرعة الشبكة.
الاستجابة العامة توفر ضمانات تقدم أكثر صرامة خلال الفترات غير المتزامنة وعند فشل القادة. خلال فترة التزامن مع القادة البطيئين، لا يمكن مقارنة هذه الخصائص بشكل مباشر، لأنها تعتمد على سرعة القائد. ولكن بالنظر إلى آلية سمعة القائد، يجب أن يظهر القادة البطيئون نادراً في Shoal.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 18
أعجبني
18
7
إعادة النشر
مشاركة
تعليق
0/400
GasGrillMaster
· منذ 21 س
يا إلهي وقت الإستجابة قُصِرَ إلى النصف ثور واو
شاهد النسخة الأصليةرد0
MysteriousZhang
· 08-12 04:51
أربعة وثلاثون في المئة تجرؤ على التفاخر؟ kkk
شاهد النسخة الأصليةرد0
SerumSquirter
· 08-12 04:50
أخيرًا يمكنني الاستمرار في إنفاق المال هنا
شاهد النسخة الأصليةرد0
ContractCollector
· 08-12 04:48
هذه الموجة من وقت الإستجابة مثيرة للغاية!
شاهد النسخة الأصليةرد0
LiquidityWitch
· 08-12 04:44
هذا قاسي جدًا وقت الإستجابة زاد بنسبة 40
شاهد النسخة الأصليةرد0
GateUser-26d7f434
· 08-12 04:41
هل يمكن أن يعمل بسرعة 40% مع الشبكة الرئيسية؟
شاهد النسخة الأصليةرد0
YieldHunter
· 08-12 04:41
من الناحية التقنية... 40% ليست سيئة ولكن يظهر لي إحصائيات العائد
إطار Shoal: تحسين وقت الإستجابة بنسبة 40% على سلسلة Aptos وإلغاء الاعتماد على المهلة
إطار Shoal: حل مبتكر لتحسين أداء البلوكتشين Aptos
اقترحت Aptos Labs مؤخرًا إطار العمل Shoal، والذي يهدف إلى حل مشكلتين رئيسيتين في إجماع DAG BFT، مما يقلل بشكل كبير من التأخير ويقضي لأول مرة على الاعتماد على المهلات في البروتوكولات غير المتزامنة الحتمية. بشكل عام، يزيد Shoal تأخير Bullshark بنسبة 40% في حالة عدم وجود أعطال، وبنسبة 80% في حالة وجود أعطال.
تعزز Shoal بروتوكول الإجماع القائم على Narwhal باستخدام نظام خط الأنابيب وآلية سمعة القادة ( مثل DAG-Rider و Tusk و Bullshark وغيرها ). تعمل تقنية خط الأنابيب على تقليل تأخير ترتيب DAG من خلال إدخال نقطة مرجعية في كل جولة، بينما تعمل آلية سمعة القادة على تحسين التأخير بشكل أكبر من خلال ضمان ارتباط النقطة المرجعية بأسرع عقدة تحقق. بالإضافة إلى ذلك، تتيح سمعة القادة لـ Shoal الاستفادة من البناء غير المتزامن لـ DAG للقضاء على جميع السيناريوهات التي تؤدي إلى انقضاء الوقت، مما يحقق استجابة شاملة.
الفكرة الأساسية لـ Shoal هي تشغيل عدة مثيلات من البروتوكول الأساسي بالتسلسل. كمثال على ذلك Bullshark، يمكن تصورها كمجموعة من "القرش" التي تتسابق في سباق التتابع.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
الدافع
شبكة البلوكتشين كانت تسعى دائماً لتحقيق أداء أعلى، وكانت تركز في البداية على تقليل تعقيد الاتصالات. ومع ذلك، لم تحقق هذه الطريقة زيادة ملحوظة في معدل المعالجة. على سبيل المثال، فإن Hotstuff الذي تم تنفيذه في النسخة المبكرة من Diem لم يحقق سوى 3500 TPS، وهو أقل بكثير من الهدف المتمثل في 100,000+ TPS.
أحدثت الاختراقات الأخيرة من خلال إدراك أن انتشار البيانات هو العائق الرئيسي القائم على بروتوكول القادة، ويمكن الاستفادة منه من خلال التوازي. يقوم نظام Narwhal بفصل انتشار البيانات عن منطق الإجماع الأساسي، ويقترح بنية حيث يقوم جميع المدققين بنشر البيانات في نفس الوقت، بينما تقوم مكونات الإجماع بفرز كمية صغيرة فقط من البيانات الوصفية، مما يحقق قدرة معالجة تصل إلى 160 ألف معاملة في الثانية.
قدمت Aptos سابقًا Quorum Store، وهو تنفيذ لـ Narwhal، الذي يفصل بين نشر البيانات والإجماع، ويستخدم لتوسيع بروتوكول الإجماع الحالي Jolteon. يجمع Jolteon بين المسار السريع الخطي لـ Tendermint وتغيير العرض بأسلوب PBFT، مما يقلل من تأخير Hotstuff بنسبة 33%. ومع ذلك، فإن بروتوكول الإجماع القائم على القيادة لا يمكنه الاستفادة الكاملة من إمكانيات الإنتاجية لـ Narwhal.
لذلك، قررت Aptos نشر Bullshark فوق Narwhal DAG، وهو بروتوكول إجماع بدون تكلفة اتصالات. لكن دعم Bullshark لهيكل DAG عالي الإنتاجية أدى إلى تكلفة تأخير بنسبة 50%. الهدف من إطار Shoal هو تقليل تأخير Bullshark بشكل كبير.
خلفية DAG-BFT
كل رأس في Narwhal DAG مرتبط بدورة معينة. للدخول في الجولة r، يجب أولاً الحصول على n-f من الرؤوس في الجولة r-1. يمكن لكل مُحقق بث رأس واحد في كل جولة، ويجب أن يُشير كل رأس على الأقل إلى n-f من الرؤوس في الجولة السابقة. بسبب عدم تزامن الشبكة، قد يلاحظ المحققون المختلفون وجهات نظر DAG محلية مختلفة.
أحد الخصائص الرئيسية لـ DAG هو عدم الغموض: إذا كان لدى اثنين من عقد التحقق نفس الرأس v في عرض DAG المحلي، فإنهما يمتلكان تاريخًا سببيًا متطابقًا تمامًا لـ v.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
الترتيب الكلي
يمكن تحقيق توافق على الترتيب الإجمالي لجميع الرؤوس في DAG دون أي تكلفة إضافية للتواصل. تفسر بروتوكولات مثل DAG-Rider وTusk وBullshark هيكل DAG كبروتوكول توافق، حيث تمثل الرؤوس الاقتراحات وتمثل الحواف التصويت.
على الرغم من أن المنطق المحدد مختلف، إلا أن جميع بروتوكولات الإجماع المعتمدة على Narwhal تتمتع بالهيكل التالي:
النقطة المحددة: كل بضع جولات يوجد زعيم محدد مسبقًا، وتسمى قمته النقطة المحددة.
نقاط الربط المرتبة: يحدد المدققون بشكل مستقل ولكن حاسم أي نقاط ربط يجب ترتيبها أو تخطيها.
ترتيب التاريخ السببي: يقوم المدققون بمعالجة قائمة النقاط المرسومة المرتبة واحدة تلو الأخرى، وترتيب الرؤوس غير المرتبة مسبقًا في التاريخ السببي لكل نقطة مرسومة.
الشرط الأساسي لضمان الأمان هو التأكد من أن جميع عقد التحقق الصادقة تشارك قائمة نقاط الربط المرتبة التي تحمل نفس البادئة. يلاحظ شوال ملاحظة مهمة بشأن جميع هذه البروتوكولات: يتفق جميع المدققين على أول نقطة ربط مرتبة.
مشكلة تأخير Bullshark
تعتمد تأخيرات Bullshark على عدد الدورات بين النقاط الثابتة المرتبة في DAG. على الرغم من أن بعض إصدارات المزامنة لديها تأخير أقل من الإصدارات غير المتزامنة، إلا أنها لا تزال بعيدة عن الأمثل.
يوجد مشكلتان رئيسيتان:
متوسط تأخير الكتلة: في الحالات الشائعة، تحتاج رؤوس الدورات الفردية إلى ثلاث دورات لترتيبها، بينما تحتاج رؤوس الدورات الزوجية غير المرساة إلى أربع دورات.
تأخير حالة العطل: إذا فشل قائد الجولة في بث النقطة المرجعية في الوقت المناسب، فسيتم تخطي تلك النقطة المرجعية، ويجب على جميع القمم غير المرتبة من الجولات السابقة الانتظار حتى يتم ترتيب النقطة المرجعية التالية. هذا يقلل بشكل كبير من أداء الشبكة الموزعة جغرافياً، خاصةً لأن Bullshark تستخدم الانتظار حتى انتهاء المهلة للقائد.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
إطار Shoal
تعزز Shoal Bullshark( أو أي بروتوكول BFT قائم على Narwhal) من خلال خط الأنابيب، مما يسمح بوجود نقطة ربط واحدة في كل جولة، مما يقلل من تأخير جميع القمم غير المرتبطة إلى ثلاث جولات. كما تقدم Shoal آلية سمعة القادة بدون تكلفة في DAG، مما يميل لاختيار القادة السريعين.
تحدي
يعتبر تنفيذ الخطوط المتوازية وسمعة القائد في بروتوكول DAG أمرًا صعبًا:
يبدو أن محاولة تعديل منطق Bullshark الأساسي غير ممكنة.
قد تؤدي سمعة القادة إلى ترتيبات مختلفة، ويحتاج المدققون إلى التوصل إلى توافق بشأن التاريخ المنظم لاختيار نقاط الربط المستقبلية.
كإثبات لصعوبة المشكلة، فإن تطبيق Bullshark في بيئة الإنتاج الحالية لا يدعم هذه الميزات.
بروتوكول
حلول Shoal بسيطة نسبياً. تستفيد من القدرة على تنفيذ حسابات محلية على DAG، مما يحقق وظيفة حفظ وإعادة تفسير معلومات الجولات السابقة. استنادًا إلى توافق جميع المدققين حول الرؤية الأولى لنقطة الربط المرتبة، تجمع Shoal بشكل متسلسل عدة مثيلات من Bullshark للمعالجة المتسلسلة، مما يجعل:
خط الإنتاج
V تربط الدور بقائد. تعمل Shoal بتسلسل على مثيلات Bullshark، حيث تقوم كل مثيل بترتيب نقطة تثبيت واحدة وتفعيل الانتقال إلى المثيل التالي.
بدأ Shoal من الجولة الأولى من DAG بتشغيل أول نسخة من Bullshark، حتى تم تحديد أول نقطة ربط مرتبة ( المفترضة في الجولة r ). اتفق جميع المدققين على هذه النقطة، وبالتالي يمكن باليقين الاتفاق على إعادة تفسير DAG من الجولة r+1. بدأ Shoal نسخة جديدة من Bullshark في الجولة r+1.
في الحالة المثالية، يسمح هذا لـ Shoal بترتيب نقطة ربط واحدة في كل جولة. يتم ترتيب نقطة الربط في الجولة الأولى بواسطة المثال الأول، ثم يبدأ المثال الجديد في ترتيب نقطة الربط لتلك الجولة في الجولة الثانية، وهكذا.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
سمعة القادة
عندما يقفز Bullshark فوق نقطة الربط، فإن التأخير سيزداد. تقنية خطوط الأنابيب لا تفيد في هذه الحالة، لأنه يجب الانتظار حتى ينتهي المثال السابق من ترتيب نقطة الربط قبل بدء مثال جديد. تقوم Shoal بتخصيص درجات لكل عقدة تحقق من خلال آلية السمعة، بناءً على تاريخ نشاطها الأخير. يحصل الموثقون الذين يستجيبون بسرعة على درجات عالية، بينما يحصل أولئك الذين لا يستجيبون بسرعة على درجات منخفضة.
الفكرة هي إعادة حساب خريطة F من الجولات إلى القائد بشكل حتمي في كل مرة يتم فيها تحديث الدرجات، مع الميل نحو القادة ذوي الدرجات العالية. لكي يتوصل المدققون إلى توافق بشأن الخريطة الجديدة، يحتاجون إلى التوصل إلى توافق بشأن الدرجات، ومن ثم التوصل إلى توافق بشأن التاريخ المستخدم لاستنتاج الدرجات.
في Shoal، يمكن دمج سمعة خط الأنابيب والقائد بشكل طبيعي، حيث أنهما كلاهما يعتمد على إعادة تفسير DAG بعد الوصول إلى توافق عند أول نقطة ربط مرتبة. الاختلاف الوحيد هو أنه بعد نقطة الربط المرتبة في الجولة r، يقوم المدققون بحساب التمثيل الجديد F' بدءًا من الجولة r+1 استنادًا إلى التاريخ السببي لتلك النقطة. ثم يتم تنفيذ مثيل Bullshark الجديد باستخدام F' المحدث بدءًا من الجولة r+1.
! [10,000 كلمة تشرح الإطار الضحل: كيفية تقليل زمن انتقال Bullshark على Aptos؟] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
إزالة المهلة
تعتبر المهلة أمرًا حاسمًا في جميع تطبيقات BFT القابلة للتحديد القائمة على القائد. ومع ذلك، فإنها تزيد من التعقيد، وتتطلب مزيدًا من إدارة الحالة الداخلية والمراقبة، مما يجعل من الصعب تصحيح الأخطاء.
سيؤدي تجاوز الوقت أيضًا إلى زيادة التأخير بشكل ملحوظ، لأن التكوين الصحيح مهم وغالبًا ما يحتاج إلى تعديلات ديناميكية. قبل الانتقال إلى القائد التالي، يتعين على البروتوكول دفع العقوبة الكاملة لتأخير تجاوز الوقت للقائد الذي يواجه مشكلة. لذلك، لا ينبغي أن تكون إعدادات تجاوز الوقت متحفظة للغاية، ولكن إذا كانت قصيرة جدًا، فقد يتم تخطي القادة الجيدين.
للأسف، تتطلب بروتوكولات القادة مثل Hotstuff و Jolteon ( أساسًا مهلة لضمان التقدم في حالة فشل القائد. إذا لم تكن هناك مهلة، حتى القائد المتعطل قد يتوقف عن تنفيذ البروتوكول إلى الأبد. نظرًا لعدم إمكانية التمييز بين الفشل والقادة البطيئين خلال فترة غير متزامنة، قد تؤدي المهلة إلى استبدال جميع القادة دون وجود نشاط إجماعي.
في Bullshark، يُستخدم المهلة لبناء DAG، لضمان أن القادة الأمناء يضيفون النقاط المرجعية إلى DAG بسرعة كافية أثناء التزامن.
لقد لاحظنا أن بناء DAG يوفر "ساعة" لتقدير سرعة الشبكة. طالما أن n-f من المدققين الأمناء يستمرون في إضافة رؤوس إلى DAG، سيتقدم الدور. على الرغم من أن Bullshark قد لا يكون قادرًا على ترتيب بسرعات الشبكة، إلا أن DAG لا يزال ينمو بسرعة الشبكة. في النهاية، عندما يقوم قائد غير معطل ببث النقطة المرجعية بسرعة كافية، سيتم ترتيب التاريخ السببي الكامل للنقطة المرجعية.
في التقييم، قمنا بمقارنة Bullshark مع وبدون تجاوز للوقت:
القادة السريعون: طريقتان تؤجلان بنفس القدر، لأن النقاط المرجعية تم ترتيبها ولا تستخدم المهلة.
القادة الخاطئون: بدون تأخير Bullshark لأكثر من الوقت، لأن عقد التحقق سيتخطى نقاط الارتباط على الفور.
القادة البطيئون: أداء Bullshark أفضل مع وجود المهلة، لأن المدققين سينتظرون النقطة المرجعية، بينما قد يتجاهلون النقطة المرجعية بدون مهلة.
في Shoal، يتعلق تجنب المهلة ارتباطًا وثيقًا بسمعة القادة. إن الانتظار المتكرر لقادة بطيئين سيزيد من التأخير، بينما يستبعد آلية السمعة المُتحققين البطيئين من أن يتم اختيارهم كقادة. بهذه الطريقة، يمكن للنظام العمل بسرعة الشبكة في جميع السيناريوهات الواقعية.
من المهم ملاحظة أن نتيجة عدم إمكانية FLP تشير إلى أنه لا يوجد بروتوكول إجماع حتمي يمكنه تجنب المهلة بالكامل. لا يمكن لـ Shoal تجاوز هذه النتيجة، لأن هناك جدول زمني للأحداث العدائية يمكن أن يمنع ترتيب جميع النقاط المرجعية نظريًا. بدلاً من ذلك، بعد عدد محدد من تخطي النقاط المرجعية القابلة للتكوين، سترجع Shoal إلى المهلة. لكن من غير المحتمل أن يحدث هذا في الواقع.
) استجابة شاملة
أوراق Hotstuff روجت لمفهوم الاستجابة المتفائلة، مما يعني بشكل بديهي أن البروتوكول يمكن أن يعمل بسرعة الشبكة ### في الحالات الجيدة بما في ذلك القادة السريعين والشبكة المتزامنة (.
تقدم Shoal ميزة أفضل تُعرف بالاستجابة الشاملة. بشكل أكثر تحديدًا، مقارنة بـ Hotstuff، حتى إذا فشل القائد خلال عدد من الجولات المستمرة القابلة للتكوين أو واجهت الشبكة فترات غير متزامنة، فإن Shoal ستستمر في العمل بسرعة الشبكة.
الاستجابة العامة توفر ضمانات تقدم أكثر صرامة خلال الفترات غير المتزامنة وعند فشل القادة. خلال فترة التزامن مع القادة البطيئين، لا يمكن مقارنة هذه الخصائص بشكل مباشر، لأنها تعتمد على سرعة القائد. ولكن بالنظر إلى آلية سمعة القائد، يجب أن يظهر القادة البطيئون نادراً في Shoal.
![شرح مفصل عن إطار Shoal: كيفية تقليل