كيف كشفت الثغرات الأمنية الحرجة في سولانا عن تحديات تنسيق شبكات "دائمة التشغيل"

المصدر: CryptoNewsNet العنوان الأصلي: عيب مروع في سولانا كشف بسهولة كيف يمكن أن تتوقف شبكة “دائمة التشغيل” بسهولة من قبل القراصنة الرابط الأصلي: عندما طلب مشرفو سولانا من المدققين التحرك بسرعة على Agave v3.0.14، وصلت الرسالة بمزيد من العجلة أكثر من التفاصيل.

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

خلال يوم واحد، انحرفت المحادثة العامة نحو سؤال أصعب: إذا كانت شبكة إثبات الحصة بحاجة إلى ترقية سريعة منسقة، ماذا يحدث عندما لا يتحرك المشغلون معا؟

ظهر هذا الفجوة في لقطات الاعتماد المبكر. في 11 يناير، قال حساب واسع الانتشار إن 18% فقط من الحصة قد تم ترحيلها إلى v3.0.14 في ذلك الوقت، مما ترك جزء كبير من الوزن الاقتصادي للشبكة على إصدارات أقدم خلال فترة وُصفت بأنها عاجلة.

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

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

نشرت أنزا، الفريق وراء Agave، ملخص تصحيح أمني في 16 يناير يوضح لماذا كانت v3.0.14 مهمة ولماذا طُلب من المشغلين الترقية بسرعة.

وفي نفس الوقت تقريبًا، أشار نظام بيئة سولانا إلى أن التنسيق لا يُترك فقط على حسن النية، لأن معايير تفويض مؤسسة سولانا الآن تشير صراحة إلى إصدارات البرمجيات المطلوبة، بما في ذلك Agave 3.0.14 وFrankendancer 0.808.30014، كجزء من المعايير التي يجب أن يلتزم بها المدققون لتلقي الحصة المفوضة.

معًا، تحوّلت تلك التطورات إلى دراسة حالة حول ما يتطلبه “التمويل الدائم” عمليًا على سولانا، ليس فقط من البرمجيات، ولكن من الحوافز وسلوك المشغلين تحت ضغط الوقت.

سلسلة عالية السرعة لا تزال تعتمد على العمليات البشرية

سولانا هي سلسلة كتل إثبات الحصة مصممة لمعالجة كميات كبيرة من المعاملات بسرعة، مع مدققين يصوتون على الكتل ويؤمنون السجل بما يتناسب مع الحصة الموكلة إليهم من SOL.

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

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

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

مشهد مدققي سولانا يرفع من رهانات التنسيق. السلالة الإنتاجية الأكثر شيوعًا هي العميل الذي يتم صيانته من خلال فرع أنزا لـ Agave، والشبكة تتقدم أيضًا نحو تنوع أوسع للعملاء عبر جهود Jump Crypto’s Firedancer، مع Frankendancer كمعلم مبكر على ذلك المسار.

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

هذا هو السياق الذي تم فيه إصدار v3.0.14. كانت العجلة تتعلق بإغلاق مسارات محتملة للاضطراب قبل أن يتم استغلالها.

ما الذي تغير في الأيام العشرة الماضية: السبب أصبح علنيًا، والحوافز أصبحت مرئية

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

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

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

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

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

لا تزال مسألة المشغل مهمة، لكنها تصبح أكثر تحديدًا: كم بسرعة يمكن لأسطول موزع أن ينشر إصلاحًا عندما تكون أوضاع الفشل واضحة ونظامية؟

وفي الوقت نفسه، جعلت قواعد تفويض سولانا آلية التنسيق أسهل في الرؤية. تتضمن معايير تفويض مؤسسة سولانا متطلبات إصدار البرمجيات وموعد استجابتها المعلن.

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

هذه هي الحقيقة التشغيلية وراء “التمويل الدائم”. يبنى من خلال الكود، لكنه يُحافظ عليه من خلال الحوافز ولوحات المعلومات والمعايير التي تدفع آلاف الفاعلين المستقلين للتقارب خلال نوافذ ضيقة تخلقها الحوادث الأمنية.

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

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

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

لم يتوقف حلقة v3.0.14 أيضًا عن إبطاء وتيرة إصدار سولانا الأوسع.

في 19 يناير، أرسل مستودع Agave الإصدار v3.1.7، وُصف بأنه إصدار شبكة اختبار موصى به لـ devnet وحتى 10% من mainnet beta، مما يشير إلى خط أنابيب من التغييرات التي يجب على المشغلين تتبعها والتخطيط لها. في 22 يناير، تم تحديث صفحة جدول إصدار v3.1 الخاص بـ Agave بخطة طرح مؤقتة.

الجاهزية تصبح قابلة للقياس بطرق ملموسة

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

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

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

بدأت حلقة v3.0.14 كتصنيف للعجلة وقلق من الاعتماد، ثم أصبحت نافذة أوضح لكيفية تصحيح سولانا، وتنسيقها، وفرض معايير عبر أسطول مدققي موزع.