ثغرة خطيرة على سولانا تم الكشف عنها للتو: هاكر يهدد بإحداث شلل في الشبكة

عندما طلب فريق صيانة Solana من المدققين التحديث بسرعة إلى Agave v3.0.14، تم إصدار الرسالة بمستوى أعلى من الطوارئ، وهي تفاصيل تقنية.

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

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

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

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

خلال أكثر من 10 أيام بعد ذلك، أصبح المشهد أكثر وضوحًا وفائدة مقارنة بالعناوين الأولية.

أعلنت مجموعة Anza، التي تقف وراء Agave، في 16/1 عن ملخص للتصحيحات الأمنية، موضحة لماذا يعتبر v3.0.14 مهمًا ولماذا يُطلب من المشغلين التحديث بسرعة.

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

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

شبكة بلوكشين عالية السرعة لا تزال تعتمد على البشر الذين يديرونها

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

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

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

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

يزيد هذا من أهمية تصور عميل Solana. أكثر عملاء الشبكة انتشارًا حاليًا هو سلسلة البرامج التي يتم صيانتها عبر fork Agave من Anza. في الوقت نفسه، تتجه الشبكة نحو تنويع العملاء من خلال جهود Firedancer من Jump Crypto، مع Frankendancer كمرحلة وسيطة.

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

هذا هو السياق الذي ظهر فيه v3.0.14. الطوارئ تهدف إلى سد الطرق التي قد تؤدي إلى انقطاع قبل أن يتم استغلالها.

التغييرات خلال 10 أيام بعد ذلك: الأسباب علنًا، والدوافع الاقتصادية تظهر

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

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

الثغرة الثانية تتعلق بمعالجة التصويت — وهو جوهر آلية الإجماع. وفقًا لـ Anza، خطوة تحقق مفقودة قد تسمح للمهاجمين بملء المدققين برسائل تصويت غير صالحة، مما يسبب تشويش عملية التصويت العادية وقد يؤدي إلى توقف الإجماع على نطاق واسع.

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

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

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

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

بالنسبة للمشغلين المفوضين من قبل المؤسسة، يصبح التحديث مسألة اقتصادية: عدم الامتثال قد يؤدي إلى سحب الحصص المفوضة حتى يتم استيفاء المعايير.

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

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

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

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

حدث v3.0.14 لم يوقف إصدار Solana الأوسع.

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

مستوى الجاهزية أصبح الآن قابلًا للقياس عبر مؤشرات محددة.

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

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

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

بدأ حدث v3.0.14 بوصف “عاجل” وقلق بشأن سرعة التطبيق، ثم تطور ليصبح رؤية أوضح لكيفية تصحيح Solana للأخطاء، والتنسيق، وتنفيذ المعايير على فريق من المدققين الموزعين.

Vương Tiễn