Firedancer رسميًا يعمل: أخيرًا خرجت Solana من حالة "العميل الوحيد" الخطيرة

خطأ في تصميم الهندسة المعمارية استغرقت 5 سنوات للاعتراف بها

في ديسمبر 2024، أعلنت سولانا عن نقطة تحول مهمة: تم تفعيل عميل المدقق Firedancer على الشبكة الرئيسية بعد 100 يوم من الاختبار الناجح، حيث نجح بعض المدققين في معالجة 50,000 كتلة. لكن الحدث لم يكن فقط عن الأداء—كانت المرة الأولى التي تتعامل فيها سولانا فعليًا مع مشكلة الهيكل التي تسببت في خمسة من أخطر الأعطال خلال السنوات الخمس الماضية.

المشكلة الجذرية بسيطة جدًا: حوالي 90% من المدققين على الشبكة يستخدمون نفس البرنامج—عميل Agave. عندما يكون 70-90% من قوة التوافق في blockchain تعمل على قاعدة كود واحدة، فإن أي خطأ في ذلك العميل لا يكون مشكلة محلية—بل يصبح مشكلة شبكية كاملة. تصبح أوقات التأكيد أقل من ثانية أو القدرة على معالجة آلاف المعاملات في الثانية غير ذات معنى عندما يمكن لخطأ برمجي أن يتسبب في تجميد السلسلة بأكملها.

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

شبكة تعاني من مشاكل بسبب اختيار التكنولوجيا

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

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

مستوى التركيز الحالي يجعل الأمر أكثر خطورة. تقرير صحة الشبكة لشهر يونيو 2025 من مؤسسة سولانا يُظهر أن Agave وتعديله Jito-modified يسيطران على 92% من SOL المرهونة. بحلول أكتوبر 2025، ظل هذا الرقم منخفضًا قليلاً. وفقًا لـ Cherry Servers، لا يزال عميل Jito-Agave يسيطر على أكثر من 70% من الحصة، على الرغم من ظهور عميل هجين يُسمى Frankendancer—يستخدم طبقة الشبكة من Firedancer لكنه يحتفظ بالطبقة التوافقية للخلفية من Agave—ويشكل حوالي 21%. العميل الأصلي Firedancer لم يمتلك بعد أي حصة لأنه لا يزال في وضع الشبكة الرئيسية غير التصويتية.

اعتماد 70% من الحصة على قاعدة كود واحدة يعني أن خطأ في Agave يمكن أن يتسبب في شل الشبكة بالكامل.

Firedancer: هندسة من الصفر، وليس تصحيحًا

Firedancer ليس تحديثًا أو فرعًا من Agave. إنه إعادة كتابة كاملة باستخدام C/C++، تم تطويره بواسطة Jump Crypto مع هندسة مستعارة من أنظمة التداول عالية التردد. هذان العميلان لا يشاركان في الكود المصدري، أو لغة البرمجة، أو حتى هيكلية الصيانة.

الأهم من ذلك: هذا الاستقلال يخلق مجالات أخطاء منفصلة.

تسرب الذاكرة في Agave (الذي يُكتب بلغة Rust) لن ينتقل إلى رمز Firedancer المكتوب بـ C/C++. خطأ منطقي في جدولة الكتل في Agave لن يؤثر على نموذج التنفيذ في Firedancer. عندما يمكن للعميلين أن يفشلا بشكل مستقل، يمكن للشبكة أن تتجاوز خطأ كبير في عميل واحد طالما أن الحصة موزعة بشكل كافٍ لمنع توقف عميل واحد عن العمل من إحداث ازدحام في التوافق.

Frankendancer: خطوة انتقال ذكية

Frankendancer هو نقطة توقف وسط الطريق. يستخدم مكونات الشبكة وإنتاج الكتل من Firedancer، لكنه يحتفظ بطبقة التوافق والتنفيذ من Agave. هذا يسمح للمدققين بالاستفادة من تحسينات الأداء في Firedancer دون المخاطرة بشبكة كاملة مع رمز التوافق غير المختبر.

زيادة حصة Frankendancer من حوالي 8% في يونيو إلى 21% في أكتوبر تُظهر أن هذا النموذج المختلط قادر على جذب المزيد. لكن الأهم: طالما أن جميع المدققين لا يزالون يعتمدون على طبقة Agave المشتركة للتوافق، فإن خطأ في تلك الطبقة يمكن أن يتسبب في شل السلسلة—حتى مع استحواذ Frankendancer على 21% من الحصة.

لهذا السبب، كان إطلاق الشبكة الرئيسية الكاملة لـ Firedancer في ديسمبر خطوة حاسمة حقًا.

ماذا يغير Firedancer من حيث الأداء والموثوقية

تُظهر الاختبارات أن Firedancer يمكنه معالجة من 600,000 إلى أكثر من 1,000,000 معاملة في الثانية في بيئة الاختبار، متجاوزًا قدرات Agave المثبتة. لكن رقم القدرة على المعالجة ليس هو النقطة الأساسية.

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

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

اختيار العميل من قبل المشغل: قرار تجاري، وليس فنيًا فقط

مصطلح “المشغل” (الذي يدير/يشغل) في سياق blockchain يشير إلى الكيانات التي تدير عقد المدقق—من منظمات البنية التحتية مثل Lido أو Rocket Pool إلى المشغلين الأفراد. قرارهم بشأن اختيار العميل هو قرار تجاري، وليس فنيًا فقط.

المنظمات تعتبر سولانا منصة إنتاج، ويجب أن تطرح سؤالًا: ماذا يحدث عند حدوث مشكلة؟ شبكة حيث 90% من المدققين يستخدمون نفس العميل لديها نقطة فشل واحدة. شبكة لا يسيطر فيها أي عميل على أكثر من 33% من الحصة يمكن أن تفقد عميلًا واحدًا بسبب خطأ وتستمر في العمل.

الفارق بين سولانا (مليار و750 مليون دولار من الأصول الحقيقية المرمزة) و إيثيريوم (12.5 مليار دولار) لا يعكس فقط تأثير الشبكة أو اهتمام المطورين. إنه يعكس الثقة في وقت التشغيل. تتطلب إدارة المخاطر في المؤسسات موثوقية قبل الالتزام ببناء تطبيقات مهمة.

لقد لاحظت شركة Levex أن Firedancer “يعالج المخاوف الرئيسية التي أشار إليها المستثمرون المؤسسات بشأن موثوقية سولانا” وأن تنوع العملاء “يوفر الاستدامة التي تتطلبها الشركات للتطبيقات المهمة.”

الطريق القادم: من المركزية إلى التوزيع

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

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

سولانا الآن لديها عميلان مكتوبان بلغتين مختلفتين بكود مستقل. الهندسة جاهزة. السؤال هو: هل سيتحول المشغلون بسرعة كافية؟