بيب، بيب، بيب. بيب، بيب، بيب.

تحطم نوم ستيفن بسبب الدقات القاسية لهاتفه ، مما جره فجأة من أحلامه. في الظلام ، تضيء الشاشة بشكل مشرق ، وتهتز بشراسة على طاولة سريره. صفارة ، صفارة ، صفير. يتأوه ، ويفرك عينيه بترنح ، ويصل إلى الجهاز. يحدق في الرسالة ، يغرق قلبه - العقدة معطلة. دون تردد ، ينهض من السرير ، نصف مرتديا ملابسه ، يتحسس لفتح هاتفه مع تدفق المزيد من الرسائل. ثم يضربه - الكتلة بأكملها معطلة.

في هذه اللحظة الدقيقة، عبر العالم، في مدن متناثرة ومناطق زمنية مختلفة، يقوم مئات من مشغلي العقد بالنظر إلى هواتفهم مع نفس الإدراك: لقد حان الوقت الذي يخشونه - حدوث انقطاع في الخدمة.

مقدمة

مثل جميع الأنظمة الموزعة، تعمل سولانا تحت واقع أن خطأ تنفيذ واحد أو حالة حافة غامضة يمكن أن تؤدي إلى فشل على مستوى الشبكة. تعتبر الانقطاعات، على الرغم من كونها مزعجة، جزءاً لا مفر منه في الحفاظ على البنية التحتية الموزعة المعقدة - سواء في سلاسل كتل اللامركزية، أو التبادلات المركزية، أو حتى مزودي خدمات السحاب الرئيسيين مثل أمازون أو مايكروسوفت.

السؤال ليس ما إذا كانت حالات الفشل ستحدث ، ولكن متى - وكيف تتطور الشبكة للتكيف وتحصين نفسها ضد الحوادث المستقبلية. على الرغم من اختبارات المحاكاة الصارمة ، وشبكة الاختبار المحفزة ، وبرنامج مكافأة الأخطاء النشط ، لا يمكن لأي نظام - بغض النظر عن مدى تصميمه الجيد - توقع كل وضع فشل محتمل. الدروس الأكثر قيمة تأتي من عمليات العالم الحقيقي.

على مدى السنوات الخمس الماضية ، شهدت Solana سبع حوادث انقطاع منفصلة ، خمسة منها كانت ناجمة عن أخطاء العميل واثنتان بسبب عدم قدرة الشبكة على التعامل مع فيضانات من الرسائل غير المرغوب فيها للمعاملات. افتقرت الإصدارات المبكرة من Solana إلى آليات إدارة الازدحام الرئيسية ، مثل رسوم الأولوية وأسواق الرسوم المحلية ، والتي أثبتت لاحقا أنها ضرورية في التخفيف من إجهاد الشبكة. أدى الافتقار إلى مثل هذه الآليات إلى فترات طويلة من تدهور الأداء والازدحام طوال عام 2022 حيث حفزت الشبكة بشكل أساسي البريد العشوائي.

الحالات التاريخية لانقطاعات وأداء ضعيف لـ سولانا

سيقوم هذا المقال بتحليل كل انقطاع في سولانا بالتفصيل، مع دراسة الأسباب الجذرية والأحداث المحفزة، والتدابير المتخذة لحلها. بالإضافة إلى ذلك، سنناقش الجوانب الرئيسية لإعادة تشغيل الشبكة، وتقارير الأخطاء، والمفاهيم الأساسية لفشل الحيوية والسلامة. على الرغم من أن هذه الأقسام يفضل قراءتها بالترتيب، إلا أن كل منها مصمم ليكون مستقلاً، مما يتيح للقراء الانتقال إلى المواضيع أو حوادث الانقطاع التي تثير اهتمامهم أكثر.

الحيوية والسلامة

وفقًا لنظرية CAP، المعروفة أيضًا باسم نظرية بروير، يمكن للنظام الموزع تحقيق خاصيتين فقط من بين ثلاث خصائص:

• الاتساق - كل قراءة ترى جميع الكتابات السابقة.
• التوفر - يتلقى كل طلب ردا.
• تحمل القسمة - يستمر النظام في العمل على الرغم من تقسيم الشبكة.

بالنسبة لسلاسل الكتل، فإن تحمل القسمة ضروري — انقطاعات الشبكة لا مفر منها. هذا يضطر إلى اتخاذ خيار بين AP (التوفر + تحمل القسمة) و CP (الاتساق + تحمل القسمة). مثل معظم سلاسل PoS ذات النهاية السريعة، تولي سولانا أولوية للاتساق على حساب التوفر، مما يجعلها نظامًا CP. يتوقف خلال الأخطاء الحرجة بدلاً من تقديم البيانات الباهتة أو السماح بكتابات غير آمنة. وبينما يعني هذا أن برنامج العقد قد يدخل في حالة لا يمكن استعادتها تتطلب تدخل يدوي، إلا أنه يضمن سلامة أموال المستخدمين.

موقف سولانا ضمن مقايضات نظرية CAP

فشل الحياة: يحدث عندما يتوقف blockchain عن التقدم ، مما يمنع تأكيد المعاملات وإنتاج الكتل بسبب تعطل المدقق أو أقسام الشبكة أو توقف الإجماع. في سياق نظرية CAP ، يتوافق هذا مع فقدان التوافر.

فشل السلامة: يحدث عندما يتم تغيير حالة سلسلة الكتل النهائية أو تشعبها بشكل غير صحيح. يمكن أن يؤدي ذلك إلى تضارب في التاريخ أو الإنفاق المزدوج، والذي يسبب غالبًا من العلل في الاتفاق أو الهجمات الخبيثة. في سياق نظرية CAP، يتوافق هذا مع فقدان الاتساق.

تولي سولانا الأمان أولاً على الحيوية. وبالتالي، ستتوقف الشبكة في حالات الضغط الشديد على الشبكة أو فشل التوافق بدلاً من تعريض الحالة للفساد. بينما قد تكون الانقطاعات مزعجة ويمكن أن تؤثر على التطبيقات والمستخدمين والمصادقين، إلا أنها تفضل على العواقب الكارثية لدفاتر الأستاذ غير المتسقة أو المعطوبة.

إعادة تشغيل الشبكة

تتضمن إعادة تشغيل شبكة Solana تحديد آخر فتحة كتلة مؤكدة بشكل متفائل وإعادة تشغيل العقد من لقطة ولاية محلية موثوقة لتلك الفتحة. نظرا لعدم تحديد فتحة إعادة التشغيل على السلسلة، يجب على مشغلي المدققين التوصل إلى إجماع خارج السلسلة للاتفاق على نقطة استرجاع آمنة. يحدث هذا التنسيق علنا في قناة #mb-validators على Solana Tech Discord ، حيث يتواصل مشغلو المدققين المحترفين في الوقت الفعلي. لدى معظم المشغلين أنظمة تنبيه آلية تخطرهم لحظة توقف إنتاج الكتلة ، مما يضمن استجابة سريعة.

بمجرد التوصل إلى توافق بشأن فتحة إعادة التشغيل الصحيحة، يستخدم المشغلون أداة الدفتر الأساسي لإنشاء لقطة محلية جديدة، وإعادة تشغيل محققيهم الخاصين، وانتظار عودة ما لا يقل عن 80٪ من إجمالي الرهان على الإنترنت. وفقط بعد ذلك يستأنف الشبكة إنتاج الكتل والتحقق. يتحقق من أن هناك على الأكثر 20٪ من الرهان غير المتصل عند إعادة تشغيل العنقود، مما يضمن وجود ما يكفي من ميزة السلامة للبقاء على الإنترنت في حال تفرع العقدات أو العودة للوضع عدم الاتصال على الفور بعد الإعادة التشغيل.

الإبلاغ عن الأخطاء

تكافؤ الثغرات يكافأ الباحثين الأمنيين عن تحديد والإبلاغ عن ثغرات البرمجيات. هذا خط دفاع حيوي، حيث يحفز بشكل استباقياصطياد الأخطاء قبل استغلالها. يتم تشجيع الباحثين والمطورين الأمنيين الذين يحددون نقاط الضعف المحتملة في عميل Agave على الإبلاغ عنها من خلال قنوات الأمان المناسبة. يمكن العثور على إرشادات الكشف المفصلة في مستودع Agave على GitHub.

تُقدم مكافآت للتقارير الصحيحة حول الثغرات الحرجة، مع دفعات مستندة إلى الخطورة:

• فقدان الأموال: تصل إلى 25,000 SOL
• الإجماع أو انتهاكات السلامة: ما يصل إلى 12500 SOL
• الحيوية أو فقدان التوفر: تصل إلى 5،000 SOL

بالإضافة إلى ذلك، عميل FireDancer لديه برنامج مكافأة عثرات منفصل استضافتها Immunefi ، وتقدم مكافأة قصوى قدرها 500,000 دولار أمريكي للنتائج الحاسمة.

حالات الانقطاع

تقدم الأقسام التالية تحليلاً مفصلاً وزمنياً لانقطاعات سولانا وفترات الأداء المتدهورة، بدءًا من إطلاق Mainnet Beta في 16 مارس 2020. سيسلط هذا الفحص الضوء على الحوادث الرئيسية وأسبابها الجذرية وتحسينات الشبكة لاحقًا، مما يوفر رؤية حول كيفية تطور سولانا لتعزيز الاستقرار والمرونة مع مرور الوقت.

خلل توربيني: ديسمبر 2020

وقت التوقف: حوالي ست ساعات

مشكلة الجذر: علة انتشار الكتلة

اصلاحات:

• تتبع الكتل حسب العنوان التشفيري بدلاً من رقم الترتيب
• إصلاح الأماكن في التوربين حيث يمكن القيام بالكشف عن الأعطال في وقت سابق
• نشر العيب المكتشف أولاً إلى جميع المحققين من خلال الفضول

تسببت هذه الانقطاع فيمشكلة إصلاح الكتل ومعالجة الشيفرة المعروفة سابقًامُشَغَّلَة بواسطة خلل غير معروف فيآلية انتشار الكتل في سولانا، سولاناحدث الفشل عندما قام محقق بإرسال كتلتين مختلفتين لفتحة واحدة ونشرهما إلى قسمين منفصلين (A و B) بينما اكتشف قسم ثالث بشكل مستقل الاختلاف.

نظرًا لأن كل قسم كان يمتلك حصة أقلية فقط، لم يتمكن أي منها من تحقيق توافق غالب للتقدم في السلسلة. المشكلة الأساسية نشأت من كيفية تتبع هياكل البيانات الداخلية لـ سولانا للكتل وحالتها المحسوبة. استخدم النظام رقم فتحة (PoH) لتاريخ الدليل (معرف u64) للإشارة إلى الحالة والكتلة في تلك الفتحة. بمجرد أن تنقسم الشبكة إلى أقسام، تفسر العقد كتلة A وكتلة B على أنهما متطابقتان، مما يمنع الإصلاح السليم ومزامنة الكتلة.

افترض كل قسم أن الآخر لديه نفس الكتلة ، مما يؤدي إلى صراع أساسي:

• العُقد الذين يحملون الكتلة A رفضوا الشوكات المشتقة من الكتلة B
• العقد التي تحمل الكتلة B الشوكات المرفوضة المشتقة من الكتلة A

نظرًا لاختلاف عمليات الانتقال الحالية بين الأقسام، لم يتمكن المحققون من إصلاح أو التوفيق بين الشوكات، مما يمنع الاستقرار النهائي.

كانت إصلاحات هذه المشكلةالسماح للخدمات بتتبع الكتل حسب الهاش بدلاً من رقم الفتحةإذا أنشأ أي عدد من الكتل لنفس الفتحة تقسيمات، فإنها لا تُعامل بشكل مختلف عن تقسيمات تحتوي على كتل تحتل فتحات مختلفة. سيتمكن العقد من إصلاح جميع الشوكات المحتملة، وستكون الوضوح قادرة على حل التقسيمات.

على الرغم من أن الخلل كان السبب الأساسي في حدوث الانقطاع عن الخدمة، إلا أن معظم وقت التوقف نتج عن انتظار كفاية من الوزن النسبي للعودة عبر الإنترنت، حيث تتطلب سولانا مشاركة على الأقل 80% من الوزن النسبي لاستئناف إنتاج الكتل.

مرحبا بكم في بروتوكول العنب IDO: سبتمبر 2021

فترة التوقف: سبعة عشر ساعة

القضية الأساسية: تجاوز الذاكرة ناتج عن معاملات الروبوت

تصليحات:

• تجاهل أقفال الكتابة على البرامج
• حدود معدل التحويل النقدي
• سلوك إعادة المحاولة قابل للتكوين في RPC
• ترتيب أولوية معاملة التصويت TPU

في 14 سبتمبر 2021 ، واجهت Solana كشكا رئيسيا للشبكة بعد إطلاق Grape Protocol لعرض DEX الأولي على السلسلة (IDO) على منصة التمويل الجماعي Raydium AcceleRaytor. في غضون 12 دقيقة من IDO ، أصبحت الشبكة غارقة في فيضان غير مسبوق من المعاملات التي يحركها الروبوت وتوقفت عن إنتاج فتحات الجذور. نفذت هذه الروبوتات بشكل فعال هجوم رفض الخدمة الموزع (DDoS) ، مما دفع أحمال المعاملات إلى ما هو أبعد من سعة الشبكة.

في ذروة الازدحام:

• كان بعض المدققين يتلقون أكثر من 300000 معاملة في الثانية.
• تجاوزت بيانات المعاملات الخام 1 جيجابايت في الثانية، مع 120،000 حزمة في الثانية.
• في بعض الأحيان تجاوزت حركة المرور الحدود الفعلية لواجهات الشبكة، مما تسبب في فقدان الحزم عند منفذ التبديل قبل الوصول إلى المحققين.

عدد فتحات سولانا في الثانية خلال انقطاع الخدمة الكبير لـ غريب في 14 سبتمبر 2021(مصدر البيانات: Jump Crypto)

أحد الروبوتات هيكلت معاملاتها لكتابة قفل 18 حسابًا رئيسيًا، بما في ذلك برنامج رمز SPL العالمي وبرنامج Serum DEX الذي أصبح غير فعال الآن. وقد حجب هذا جميع المعاملات التفاعلية مع هذه الحسابات، مما أدى إلى تقليل قدرة معالجة سولانا المتوازية بشكل كبير. بدلاً من تنفيذ المعاملات بشكل مستقل، أصبح الشبكة محصورة، وتقوم بمعالجة المعاملات بشكل تسلسلي، مما يفاقم الازدحام.

تم بالفعل تطوير إصلاح يتجاهل أقفال الكتابة على البرامج وجدولته للإصدار. في وقت لاحق ، مكنت إعادة تشغيل الشبكة هذه الترقية ، مما أدى إلى إزالة ناقل الهجوم هذا بشكل دائم.

خلال حدث IDO ، تلقى المدققون طوفانا من المعاملات التي يحركها الروبوت ، وبالتالي قاموا بإعادة توجيه المعاملات الزائدة إلى القائد التالي ، مما أدى إلى تضخيم الازدحام. أدخلت إعادة تشغيل الشبكة حدودا لمعدل إعادة توجيه المعاملات لمنع عواصف المعاملات المستقبلية من التغلب على القادة.

تقوم عقد RPC في Solana بإعادة محاولة المعاملات الفاشلة تلقائيا ، وهي ميزة مصممة لتحسين الموثوقية. ومع ذلك ، أدت آلية إعادة المحاولة هذه إلى تفاقم إغراق المعاملات في ظل الازدحام الشديد ، مما أبقى المعاملات القديمة قيد التداول بدلا من السماح للشبكة بالتعافي. قدم Solana 1.8 سلوك إعادة محاولة RPC قابل للتكوين ، مما يمكن التطبيقات من تحسين عمليات إعادة المحاولة بأوقات انتهاء صلاحية أقصر واستراتيجيات تراجع أسية.

تحت الازدحام الشديد، فشل قادة سولانا في تضمين معاملات التصويت، التي تعتبر حاسمة للحفاظ على التوافق. ونتيجة لذلك، أدى نقص التصويتات المؤكدة إلى تعطيل التوافق، مما أوقف إنتاج كتل الجذر الجديدة. أدخلت الإصدارات اللاحقة من عميل سولانا آلية لتحديد أولوية معاملات التصويت، مما يمنع غرقها في معاملات عادية في الأحداث المستقبلية.

خطأ ثان: تجاوز عدد صحيح

أثناء إعادة تشغيل الشبكة ، ظهرت مشكلة ثانية. أبلغ المدققون عن مبالغ حصة نشطة متقلبة بشكل كبير. نشأت هذه المشكلة من خطأ تم فيه ضرب النسبة المئوية للحصة بشكل غير صحيح في 100 ، متجاوزة الحد الأقصى للقيمة الممكنة. خلقت آلية التضخم العديد من رموز SOL الجديدة لدرجة أنها فاضت عددا صحيحا غير موقع 64 بت. تم التعرف على هذا الخطأ وتصحيحه بسرعة قبل إعادة التشغيل الثانية.

ارتفاع الازدحام: يناير 2022

وقت توقف: لا شيء

السبب الجذري: المعاملات المكررة المفرطة

إصلاح جزئي:

• إصدارات Solana 1.8.12 و 1.8.14
• تحسين تكرار SigVerify
• تحسينات في أداء ذاكرة التخزين المؤقت للمنفذ

بين 6 يناير و 12 يناير 2022، تعرضت الشبكة الرئيسية لـ سولانا لازدحام شديد، مما أدى إلى تقليل الأداء وحدوث انقطاعات جزئية. كان الاضطراب ناتجًا عن الروبوتات التي قامت بإرسال عمليات تكرارية زائدة بشكل مفرط، مما أدى إلى تقليل قدرة الشبكة بشكل كبير. استغرقت الكتل وقتًا أطول من المتوقع لمعالجتها، مما تسبب في تفرع الزعيم التالي وتقليل معدل الإنتاجية بشكل أكبر. في ذروتها، تراجعت نسب نجاح المعاملات بنسبة تصل إلى 70٪. واجه العميل صعوبة في التعامل مع عمليات الشبكة العالية التعقيد والحساب العالية بشكل متزايد، مما كشف عن قيود في قدرته على تلبية الطلب.

حدثت استقرارات إضافية من 21 يناير إلى 23 يناير، مع استمرار الازدحام. في 22 يناير، نقطة نهاية RPC العامة (https://api.mainnet-beta.solana.com) تم الخروج عن الخط بسبب الإساءة، حيث غمرت مكالمات RPC المجمعة بالبريد المزعج النظام.

لمعالجة هذه المشاكل، إصدار سولانا 1.8.12 استهدف بشكل خاص استنفاد ذاكرة التخزين المؤقت للبرنامج، بينما تمت إدخال إصدار 1.8.14 تحسينات على ذاكرة التخزين المؤقت لـ Sysvar، والتجاهل SigVerify، وتكرار SigVerify.

رسائل البريد العشوائي لآلة الحلوى: أبريل / مايو 2022

وقت التوقف: ثماني ساعات

المشكلة الأساسية: رسائل غير مرغوب فيها من حسابات الروبوت

إصلاحات:

• ضريبة البوت على برنامج آلة الحلوى
• تحسينات في الذاكرة في سولانا v1.10

في 30 أبريل 2022، شهدت سولانا ارتفاعًا غير مسبوق في طلبات المعاملات. أفاد بعض العقد بالوصول إلى ستة ملايين طلب في الثانية، مما أدى إلى توليد أكثر من 100 جيجابت في الثانية من حركة المرور لكل عقد. كان هذا الارتفاع ناتجًا عن الروبوتات التي حاولت تأمين NFTs المضافة حديثًا من خلال برنامج Metaplex Candy Machine. عمل آلية القطع على أساس من يأتي أولاً، يخدم أولاً، مما يخلق حافز اقتصادي قوي لغمر الشبكة بالمعاملات والفوز بالقطعة.

تعطل آلة الحلوى في 30 أبريل / 1 مايو 2022 ، حزم في الثانية الواحدة(مصدر البيانات: Jump Crypto)

مع ارتفاع حجم المعاملات بشكل كبير، نفد ذاكرة المحققين وتعطلوا، مما أدى في النهاية إلى تعثر التوافق. لمنع القدرة الشبكية غير الكافية على التصويت من تحقيق تثبيت الكتل السابقة، مما يمنع تنظيف الشوكات المهجورة. نتيجة لذلك، أصبح المحققون مُرهَقين من عدد الشوكات الهائلة التي يجب عليهم تقييمها، تجاوز قدرتهم حتى بعد إعادة التشغيل واحتاجوا إلى تدخل يدوي لاستعادة الشبكة.

بينما تشترك هذه الانقطاعات في بعض الشبه مع حادث سبتمبر 2021، أظهرت سولانا تحسنا في المرونة. على الرغم من تجربة 10,000% المزيد من طلبات المعاملات مقارنة بالانقطاع السابق، بقيت الشبكة تعمل لفترة أطول بكثير، مما يعكس التحسنات التي قامت بها مجتمع الموثقين استجابةً للتحديات السابقة في التوسعة.

تعطل آلة الحلوى في 30 أبريل / 1 مايو 2022، والمحققون النشطون(مصدر البيانات: Jump Crypto)

استغرقت إعادة تشغيل الشبكة أقل من 1.5 ساعة بعد اللقطة الكنسية التي تم الاتفاق عليها. تضمنت Solana v1.10 تحسينات في استخدام الذاكرة لتمديد الوقت الذي يمكن للعقد أن تتحمل فيه الموافقة البطيئة أو المتعثرة.

ومع ذلك، لا تزال القضايا الأساسية غير محل حل. لا يزال القائد يعالج المعاملات التي تتنافس على نفس البيانات المحاسبية على أساس أولوية الوصول دون وقاية فعالة من الرسائل المزعجة، مما يترك المستخدمين غير قادرين على تحديد أولوية عملياتهم. ولحل هذه المشكلة، تم اقتراح ثلاث آليات طويلة الأجل كحلول عملية.

اعتماد بروتوكول QUIC: في السابق، اعتمدت سولانا على بروتوكول الشبكات UDP (User Datagram Protocol) لإرسال المعاملات من خلال خليج الخليج من خوادم RPC إلى الزعيم الحالي. على الرغم من كون UDP سريعًا وفعالًا، إلا أنه لا يوجد به تحكم في التدفق ولا تأكيدات استلام. وبناءً على ذلك، لا يوجد وسيلة معنوية لردع أو التخفيف من السلوك الفاسد. وللسيطرة على حركة المرور في الشبكة، تمت إعادة تنفيذ بروتوكول استيعاب المعاملات للمحقق (مرحلة الاسترجاع من TPU) مع QUIC.

يحاول QUIC تقديم ما هو أفضل من TCP و UDP. إنه يسهل الاتصال السريع، الغير متزامن مشابه لـ UDP ولكن مع جلسات آمنة واستراتيجيات متقدمة لمراقبة تدفقات TCP. هذا يسمح بوضع حدود على مصادر حركة المرور الفردية بحيث يمكن للشبكة التركيز على معالجة المعاملات الحقيقية. يحتوي QUIC أيضًا على مفهوم تدفقات منفصلة، لذلك إذا تم إسقاط معاملة واحدة، فإنها لا تحجب المتبقية. تم دمج QUIC في النهاية في عميل Solana Labs مع الإصدار 1.13.4.

جودة الخدمة المرتبطة بالرهن (SWQoS): تم تقديم نظام جديد يعطي أولوية لحركة المرور على الشبكة بناءً على الرهان الذي يمتلكه المحققون، مما يضمن أن يتمكن أولئك الذين يمتلكون رهانًا أعلى من إرسال المعاملات بكفاءة أكبر. بموجب هذه الآلية، يمكن لمحقق يمتلك 3٪ من الرهان الإجمالي إرسال ما يصل إلى 3٪ من الحزم الإجمالية إلى القائد. يعمل SWQoS كإجراء لمقاومة سايبل، مما يجعل من الأصعب على الجهات الخبيثة غمر الشبكة بالمعاملات ذات الجودة المنخفضة. تحل هذه الطريقة محل النموذج السابق الذي كان يقبل المعاملات عشوائيًا دون النظر في مصدرها.

مقدمة لرسوم الأولوية: بمجرد استيعاب المعاملات ، لا يزالون يتنافسون للوصول إلى بيانات الحساب المشتركة. في السابق ، تم حل هذا الخلاف على أساس بسيط من يأتي أولا يخدم أولا ، ولا يوفر للمستخدمين أي طريقة للإشارة إلى إلحاح معاملاتهم. نظرا لأنه يمكن لأي شخص تقديم المعاملات ، فإن ترجيح الحصة غير مناسب لتحديد الأولويات في هذه المرحلة. لمعالجة هذا الأمر ، تمت إضافة تعليمات جديدة إلى برنامج Compute Budget ، مما يسمح للمستخدمين بتحديد رسوم إضافية يتم تحصيلها عند التنفيذ وإدراج الكتلة. تحدد نسبة الرسوم إلى الوحدة المحسوبة أولوية تنفيذ المعاملة ، مما يضمن اتباع نهج أكثر ديناميكية ومدفوعا بالسوق لترتيب المعاملات.

ضريبة روبوت آلة الحلوى

أدخلت Metaplex بسرعة ضريبة بوت مُشفرة بقيمة 0.01 SOL على عمليات الإنتاجالتفاعل مع برنامج آلة الحلوى لمكافحة الرسائل غير المرغوب فيها التي تديرها الروبوتات. فرضت هذه الآلية المضادة للرسائل غير المرغوب فيها رسمًا دنياً لردع الأنشطة الضارة من دون معاقبة المستخدمين الشرعيين الذين ارتكبوا أخطاء عرضية. تم تطبيق الضريبة في سيناريوهات محددة، بما في ذلك:

• محاولة الضرب عندما لم تكن آلة الحلوى مباشرة
• محاولة الانتاج عندما لا تبقى أي عناصر
• المعاملات التي لم تكن عملية الإنتاج أو تعيين المجموعة هي التعليمات النهائية
• استخدام معرف جمع غير صحيح
• تعليمات جمع مجموعة متناسقة
• تعارض بين موقع التوقيع والدافع بين مجموعة الجمع وتعليمات الإصدار
• المعاملات المشبوهة المتضمنة لبرامج ممنوعة
• محاولة سك العملة من آلة Candy المحمية بواسطة AllowList دون الاحتفاظ بالرمز المميز المطلوب للقائمة المسموح بها

ثبت أن هذا الرادع الاقتصادي كان فعالًا للغاية. تم استنزاف قناصي العملات الرقمية بسرعة، وتوقفت النشاطات المزعجة. خلال الأيام القليلة الأولى، خسر البوترز بشكل جماعي أكثر من 426 SOL.

علة Nonce الدائمة: يونيو 2022

وقت التوقف: أربع ساعات ونصف

القضية الجذرية: خلل دائم في الرقم التسلسلي يؤدي إلى فشل التوافق

اصلاحات:

• تعطيل مؤقت لمعاملات الرقم العشوائي المتين
• سولانا 1.10.23 تحديث

خطأ في تشغيل البرنامج سمح بمعالجة معاملات الرقم العشوائي المتينة المعينة مرتين - مرة كمعاملة عادية ومرة أخرى كمعاملة رقمية - إذا استخدموا blockhash الأخير بدلاً من الرقم العشوائي المتين في حقل recent_blockhash. أدى هذا إلى سلوك غير قاطع بين المحققين، حيث رفض بعض العقد الثانية بينما قبلها آخرون. والأمر الحاسم هو أنه نظرًا لقبول أكثر من ثلثي المحققين للكتلة، فإنه منع الأغلبية المطلوبة من الوصول إلى توافق.

على عكس المعاملات القياسية ، لا تنتهي صلاحية معاملات nonce الدائمة وتتطلب آلية فريدة لمنع التنفيذ المزدوج. تتم معالجتها بشكل متسلسل باستخدام قيمة nonce على السلسلة مرتبطة بكل حساب ، والتي يتم تدويرها في كل مرة تتم فيها معالجة معاملة nonce دائمة. بمجرد التدوير ، يجب ألا تكون نفس المعاملة nonce صالحة مرة أخرى.

للتخفيف من المشكلة، تم تعطيل المعاملات المؤقتة المتينة مؤقتًا.تم تنفيذ إصلاح لاحقا في Solana 1.10.23، الذي منع التنفيذ المكرر عن طريق فصل النونس ومجالات blockhash. ضمن التحديث أنه عند تقدم حسابات nonce، يتم تجزئة blockhash مع سلسلة ثابتة، مما يجعل blockhash غير صالح كقيمة nonce. نتيجة لذلك، لا يمكن إعادة تنفيذ عملية مرة واحدة كعملية عادية وكعملية دائمة، والعكس صحيح. بالإضافة إلى ذلك، نوع DurableNonce الجديد استبدل قيم blockhash السابقة في حالة حساب nonce، مما يضيف سلامة النوع ويمنع المشاكل المماثلة في المستقبل.

اقرأ مقالة بلوق Helius السابقة لدينا لفهم المزيد حول الأرقام العشوائية المتينة واستخداماتها.

خطأ كتلة مكرر: سبتمبر 2022

وقت التوقف: ثمانية ساعات ونصف

المشكلة الجذرية: خلل في قواعد اختيار الفork أدى إلى فشل التوافق

إصلاح:

• تصحيح العميل

تم تشغيل هذا الانقطاع بواسطة مدقق ينتج عن طريق الخطأ كتل مكررة بنفس ارتفاع الكتلة. حدث هذا لأن كل من العقدة الأساسية للمدقق والعقدة الاحتياطية الخاصة به أصبحت نشطة في وقت واحد ، باستخدام نفس هوية العقدة ولكن اقتراح كتل مختلفة. استمرت هذه الحالة لمدة 24 ساعة على الأقل قبل انقطاع التيار ، حيث تعاملت الشبكة بشكل صحيح مع الفتحات السابقة المكررة للمدقق.

أوقفت العقدة في النهاية عندما واجهت الشبكة شوكة لا يمكن استعادتها بسبب خطأ في منطق اختيار الشوكة. هذا الخطأ منع منتجي الكتل من البناء على الكتلة السابقة، مما أدى إلى فشل في التوافق.

الشوكات حدث يومي على سولانا، وعادة ما يقوم المحققون بحلها عن طريق التوافق على الشوكة التي تحظى بأكثرية الأصوات (أثقل شوكة). عندما يختار محقق الشوكة الخاطئة، يجب عليه التبديل إلى الشوكة الأثقل للبقاء متزامنًا مع الشبكة. ومع ذلك، في هذه الحالة، لم يتمكن المحققون من العودة إلى البنك الأثقل إذا كان فتحتهم تتطابق مع فتحتهم الأخيرة التي صوتوا عليها. هذا العيب تسبب في تعلق المحققين، مما منع التوافق من التقدم وأدى في نهاية المطاف إلى توقف الشبكة.

خلل في تكرار كتلة العوارض اختيار الفork، سبتمبر 2022(المصدر: Laine، Michael Hubbard)

في المثال أعلاه ، ينتج المدقق الخاطئ C كتلا مكررة للفتحات الرائدة من 5 إلى 8. عندما يتولى المدقق G منصب القائد التالي ، فإنه يلاحظ واحدا فقط من التكرارات ويوسع شوكته وفقا لذلك. ومع ذلك ، يكتشف القائد التالي ، المدقق D ، كلا الكتلتين المكررة من المدقق C ويقرر تجاهلها ، وبدلا من ذلك يبني شوكته أعلى الفتحة 4.

مع تقدم الشبكة، يكتسب الشوكة التي بناها محقق G أصواتًا من غالبية الحصة، مما يؤسس نفسه كسلسلة كانونية. مدركًا أن شوكته تخسر، يحاول المحقق D الانتقال إلى شوكة محقق G. ومع ذلك، تفشل الانتقال بسبب خلل في منطق اختيار الشوكة. ينشأ هذا المشكلة لأن السلف المشترك للشوكتين - كتلة مكررة في الفتحة 5 - لم يتم التعامل معها بشكل صحيح، مما يمنع المحقق D من التعرف على الشوكة الأكثرية. نتيجة لذلك، يظل المحقق D عالقًا في شوكته الخاصة، غير قادر على الانضمام مرة أخرى إلى السلسلة الرئيسية.

تم حل المشكلة بعد استعراض من قبل الفريق الأساسي.تم دمج التصحيح في الفرع الرئيسي ونقله إلى جميع فروع الإصدار.

كتلة كبيرة تغمر التوربين: فبراير 2023

وقت التوقف: تقريبا 19 ساعة

مشكلة الجذر: فشل منطق الاستبعاد في خدمات إعادة التوجيه الجزئي

إصلاحات:

• تحسينات متعددة على منطق إلغاء البيانات المكررة في التوربينات والتصفية
• إضافة تصحيح العميل يجبر منتجي الكتل على الإجهاض إذا قاموا بإنشاء كتل كبيرة

تعطلت خدمة إعادة توجيه التمزيق المخصصة للمدقق ، حيث أرسلت كتلة كبيرة بشكل استثنائي (ما يقرب من 150000 قطعة) ، وعدة أوامر من حيث الحجم أكبر من الكتلة القياسية ، أثناء الفتحة الرئيسية. أدى هذا إلى إرباك عوامل تصفية إلغاء البيانات المكررة للمدقق ، مما تسبب في إعادة توجيه البيانات باستمرار. تفاقمت المشكلة مع إنتاج كتل جديدة ، مما أدى في النهاية إلى تشبع البروتوكول.

عطل كبير في الكتلة، تمزيقات لكل كتلة، فبراير 2023 (المصدر: لين ، مايكل هوبارد)

طغت الزيادة في حركة مرور الشبكة غير الطبيعية على التوربينات ، مما أجبر على نقل بيانات الكتلة عبر بروتوكول إصلاح الكتلة الاحتياطي الأبطأ بكثير. على الرغم من أن التوربينات مصممة لتحمل الكتل الكبيرة عن طريق تصفيتها ، إلا أن خدمات إعادة توجيه التقطيع تعمل في اتجاه المنبع من منطق الترشيح هذا ، مما يقلل من فعاليتها. وخلال الفترة المتدهورة، تحول قادة الكتل تلقائيا إلى وضع التصويت فقط، وهي آلية أمان يستبعد فيها القادة المعاملات الاقتصادية غير التصويتية.

كان السبب الجذري للمشكلة هو الفشل في منطق إلغاء البيانات المكررة داخل خدمات إعادة توجيه التمزيق ، مما يمنع إعادة إرسال القطع الزائدة عن الحاجة. بالإضافة إلى ذلك ، لم يتم تصميم مرشح إلغاء البيانات المكررة في خط أنابيب إعادة النقل في الأصل لمنع التكرار داخل شجرة التوربينات ، مما أدى إلى تفاقم المشكلة.

تمت إعادة تشغيل الشبكة يدويًا مع التنزيل إلى أخر إصدار معروف من بحر البرمجيات الثابتة. للتخفيف من هذه المشاكل،قدمت سولانا v1.13.7 و v1.14.17 تحسينات على منطق التكرار، وتحسين قدرته على منع تشبع المرشح وضمان أداء شبكة أكثر قوة.

حلقة إعادة ترجمة لانهائية: فبراير 2024

وقت التوقف: ما يقرب من خمس ساعات

المشكلة الجذرية: خلل يتسبب في حلقة إعادة ترجمة لانهائية في ذاكرة التخزين المؤقت للتنفيذ الفوري

اصلاحات:

• تعطيل اللودر القديم v1.17.20

يقوم محقق Agave بترجمة جميع البرامج في الوقت الفعلي (JIT) قبل تنفيذ المعاملات التي تشير إليها. من أجل تحسين الأداء، يتم تخزين إخراج JIT للبرامج المستخدمة بشكل متكرر، مما يقلل من عمليات إعادة الترجمة غير الضرورية. كجزء من Agave v1.16، تم استبدال آلية التخزين الموجودة، LoadedPrograms، بتنفيذ جديد يسمى ExecutorsCache، الذي قدم عدة كفاءات.

قدمت LoadedPrograms عرضا عاما مدركا للشوكة للبرامج المخزنة مؤقتا ، مما يقلل من تكرار بيانات المحاسبة ويسمح لمؤشرات ترابط تنفيذ المعاملات بتحميل برامج جديدة بشكل تعاوني ، مما يمنع تعارضات التجميع. كانت الميزة الرئيسية لهذا النظام هي تتبع الفتحة التي يصبح فيها البرنامج نشطا (المعروف باسم ارتفاع الفتحة الفعال) لاكتشاف إبطال ذاكرة التخزين المؤقت عند تحديث بيانات البرنامج على السلسلة.

تم اشتقاق ارتفاع فتحة البرنامج الفعالة لمعظم البرامج من فتحة النشر الخاصة بها، والتي تم تخزينها في حساباتها على السلسلة. ومع ذلك، لم تحتفظ البرامج التي تم نشرها باستخدام محملات الإرث بهذه الفتحة الخاصة بالنشر في حساباتها. حيث قامت البرامج المحملة بتعيين ارتفاع فتحة فعالة بصفر كحل بديل لهذه المشكلة.

حدث استثناء عند اكتشاف تعليمات نشر ، مما يشير إلى أنه تم استبدال الرمز الثانوي للبرنامج. في هذه الحالة، قامت البرامج المحملة بإدراج إدخال بارتفاع الفتحة الفعال الصحيح مؤقتا. غير أنه نظرا لأن المعاملة لم تشر قط إلى هذا البند، فإنها كانت شديدة التأثر بالإخلاء. عند الإخلاء ، تم تجاهل إخراج JIT ، وتم وضع علامة على البرنامج على أنه غير محمل ، ولكن تم الاحتفاظ بارتفاع الفتحة الفعال.

إذا كانت المعاملة تشير في وقت لاحق إلى هذا البرنامج الغير محمّل، قامت البرامج المحمّلة بإعادة تجميعه وإعادة إدخال إدخال في ارتفاع الفتحة الفعالة. عادةً ما يجعل هذا البرنامج متاحًا للتنفيذ في التكرار التالي. ومع ذلك، بالنسبة لبرامج تحميل الإرث، تم تعيين إخراج JIT الجديد ارتفاع الفتحة الواقية صفر، مما يضعه خلف الإدخال غير المحمّل السابق. نتيجة لذلك، لم تعترف LoadedPrograms أبدًا بالبرنامج كمحمل، مشغّلًا حلقة إعادة تجميع مستمرة في كل تكرار.

في Agave v1.16، لم يدعم LoadedPrograms التحميل التعاوني، مما سمح بتعبئة الصفقة المؤدية إلى كتلة. تم توزيع هذه الكتلة عبر الشبكة، مما تسبب في إعادة تشغيل كل محقق لها والدخول في حلقة إعادة تركيب لا نهائية. نظرًا لأن أكثر من 95% من حصة العنقود كانت تعمل بـ Agave v1.17 أثناء الانقطاع، أصبح معظم المحققين معلقين على هذه الكتلة، مما أوقف الشبكة.

تم التعرف على هذا الخلل في الأسبوع السابق خلال التحقيق في انقطاع تجمع Devnet، وتم جدولة تثبيت التصحيح.@jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0">كان التخفيف المختار هو دعم التغييرات إلى Agave v1.17 وإزالة بوابة الميزة على الفور عند إعادة تشغيل الشبكة. أدى هذا إلى تعطيل اللودر القديم المسؤول عن تشغيل الخطأ ، مما يمنع حدوث المزيد من الحوادث.

تصحيح الثغرة المنسق: أغسطس 2024

توقف: لا شيء

مشكلة الجذر: افتراض توجيه عنوان ELF غير صحيح

إصلاحات:

• تحديث التصحيح

في ٥ أغسطس، تم تنبيه المهندسين الأساسيين في Anza إلى ثغرة أمنية في عميل Agave ، أبلغ عنها باحث خارجي. كان من الممكن أن يستغل المهاجم هذا الخلل لتعطل مدققي القائد ، مما يؤدي إلى توقف على مستوى الشبكة. ردا على ذلك ، طور مهندسو أنزا بسرعة رقعة ، قامت العديد من شركات الأمن التابعة لجهات خارجية بتدقيقها بعد ذلك.

تم تجميع برامج سولانا باستخدام LLVM إلى تنفيذي وصيغة قابلة للربط (ELF). نشأت الثغرة الأمنية من افتراض محاذاة عنوان غير صحيح داخل ملفات ELF التي تم إنشاؤها. على الرغم من أن تعقيم ELF يفرض عادة العديد من فحوصات السلامة ، إلا أنه لم يتحقق من صحة محاذاة قسم .text. كان من الممكن أن يسمح هذا الإغفال لملف ELF تم إعداده بشكل ضار بتحديد قسم .text غير محاذ ، مما يؤدي إلى انتقال الجهاز الظاهري إلى عنوان غير صالح. سيؤدي هذا إلى حدوث خطأ في تجزئة المضيف ، مما يؤدي إلى تعطل المدقق.

يمكن أن يكون المهاجم قد استغل هذا الثغرة عن طريق:

• إنشاء برنامج خبيث لـ Solana يستخدم تعليمات الكود CALL_REG.
• معالجة ملف ELF لمحاذاة المقطع .text بشكل خاطئ.
• نشر البرنامج واستدعائه على الشبكة ، مما يؤدي إلى تعطل المدقق.

عملية تحديث التصحيح

أي تحديث تصحيح تم إصداره علنا سيجعل الثغرة الأمنية واضحة للجميع على الفور. قد يتيح ذلك للمهاجم وقتا كافيا لإجراء هندسة عكسية للثغرة الأمنية وإيقاف الشبكة قبل ترقية قدر كاف من الحصة. ستحتاج الكتلة الحرجة من المدققين إلى اعتماد أي إصدار تصحيح في أسرع وقت ممكن لتجنب مثل هذا السيناريو.

بحلول 7 أغسطس ، قام العديد من أعضاء تواصلت مؤسسة سولانا مع المدققين من خلال الرسائل الخاصة على منصات الاتصال المختلفة، لإبلاغهم بتصحيح حرج قادم ومشاركة رسالة مجزأة تؤكد تاريخ الحادث ومعرفه الفريد. شارك العديد من أعضاء Anza و Jito و Solana Foundation البارزين هذه التجزئة على X و GitHub و LinkedIn للتحقق من دقة الرسالة. مثال على التجزئة المشتركة:

وخلال اليوم التالي، واصل الأعضاء الأساسيون التواصل مع المدققين، مؤكدين على أهمية الاستعجال والسرية. في الوقت المحدد مسبقا ، 8 أغسطس ، 2 مساء بالتوقيت العالمي المنسق ، تلقى مشغلو المدقق رسالة أخرى تحتوي على تعليمات لتنزيل التصحيح والتحقق منه وتطبيقه. تمت استضافة التصحيح على مستودع Github لمهندس Anza معروف ، وليس مستودع Agave الرئيسي. تضمنت التعليمات التحقق من ملفات التصحيح التي تم تنزيلها مقابل shasums الموردة.

بحلول الساعة 8 مساء بالتوقيت العالمي المنسق في 8 أغسطس ، تم تصحيح الغالبية العظمى من الحصة ، مما يضمن أمان الشبكة. بعد ذلك ، تم الكشف عن الثغرة الأمنية والتصحيح المقابل لها علنا ، مصحوبة بدعوة لجميع المدققين المتبقين للترقية.

أثار التوزيع الهادئ للرقعة والتنسيق وراء الكواليس للمدققين مخاوف بشأن لامركزية سولانا. بعد وقت قصير من الحادث ، تناول المدير التنفيذي لمؤسسة سولانا ، دان ألبرت ، هذه الانتقادات في مقابلة إعلامية.

"أعتقد أنه من المهم عدم الخلط بين المركزية والقدرة على التنسيق. هناك 1500 عقدة منتجة للكتل في جميع أنحاء العالم يتم تشغيلها من قبل العديد من الأفراد تقريبا.... القدرة على التواصل معهم، أو بعضهم، طواعية، لا ينبغي الخلط بينها وبين المركزية".

أسبوع بلوكتشين الكوري (KBW) 2024

أعتقد أنه من المهم عدم الخلط بين المركزية والقدرة على التنسيق. هناك 1500 عقدة منتجة للكتل في جميع أنحاء العالم يتم تشغيلها من قبل العديد من الأفراد تقريبا.... لا ينبغي الخلط بين القدرة على التواصل معهم ، أو بعضهم ، طواعية ، وبين المركزية.

استنتاج

بحلول كتابة هذا، تجاوزت سولانا عامًا دون انقطاع، مما يشكل إنجازًا رئيسيًا لإزالة علامة "بيتا" من mainnet-beta. يبدو أن تردد حدوث الانقطاعات يقل بينما ينضج الشبكة، ومن المتوقع أن يعزز تقديم Firedancer تنوع العملاء، مما يقلل من خطر وجود علل غير مكتشفة أو حالات حواف تتسبب في إغلاق كامل للعنقود. ومع ذلك، توقع بعض قادة المجتمع، بما في ذلك مؤسس Helius Mert Mumtaz، أن تستمر الانقطاعات. الزمن سيظهر الحقيقة.

الكثير من الشكر لزانتسو (شينوبي سيستمز) وأوكسيتشيغو على مراجعة النسخ السابقة من هذا العمل.

اخلاء المسؤوليه:

1. تمت إعادة طبع هذه المقالة من [هيليوس]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [لوستن]. إذا كانت هناك اعتراضات على هذه الإعادة طباعتها، يرجى الاتصال بالبوابة التعلمالفريق، وسوف يتولى التعامل معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي آراء المؤلف فقط ولا تشكل أي نصيحة استثمارية.
3. فريق تعلم بوابة يقوم بترجمة المقالات إلى لغات أخرى. يُحظر نسخ أو توزيع أو نسخ المقالات المترجمة ما لم يُذكر.