Firedancer على الشبكة الرئيسية، لكن سولانا لا تزال لم تصل إلى معايير الأمان الخاصة بـ إيثريوم

بعد ثلاث سنوات من التطوير، بدأ Firedancer رسميًا العمل على شبكة Mainnet الخاصة بـ Solana في ديسمبر 2025، بعد أن أنشأ أكثر من 50.000 بلوك خلال 100 يوم من الاختبار مع عدد قليل من المدققين.

العلامة التي أعلنتها حسابات Solana الرسمية في 12/12 ليست مجرد ترقية للأداء. إنها أول محاولة جدية للقضاء على عنق الزجاجة المعماري الذي كان وراء أخطر المشاكل التي واجهها الشبكة: الاعتماد شبه المطلق على عميل مدقق واحد فقط.

على مدى سنوات، روَّجت Solana لقدرة الإنهائية في أقل من ثانية والقدرة على معالجة آلاف المعاملات في الثانية. لكن السرعة تصبح بلا معنى عندما يكون 70%–90% من قوة الاتفاق على الشبكة تعمل بنفس البرنامج. خطأ خطير في عميل مسيطر يمكن أن يتسبب في توقف كامل لسلسلة الكتل، بغض النظر عن الإمكانيات النظرية العالية.

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

ما هو Firedancer ولماذا يختلف

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

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

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

مشكلة “السيطرة الوحيدة” التي لم تتجاوزها Solana

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

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

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

تؤكد البيانات على مدى تعرض هذا الأمر. تقرير صحة الشبكة من مؤسسة Solana في يونيو 2025 أظهر أن Agave ومتغير Jito يسيطران على حوالي 92% من staking SOL. بحلول أكتوبر 2025، انخفض هذا المعدل لكنه لا يزال فوق 70%، في حين زاد Frankendancer إلى حوالي 21%.

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

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

النموذج المرجعي من Ethereum

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

مجتمع Ethereum يعتبر أن الحفاظ على جميع العملاء بنسبة أقل من 33% هو شرط أمني صارم، وليس مجرد تحسين للأداء. الموقف الابتدائي لـ Solana، مع عميل يقارب 90%، يقع خارج نطاق الأمان هذا.

ما الذي يغيره Firedancer حقًا

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

اختبارات الأداء المقدمة في المؤتمرات التقنية تظهر أن Firedancer يعالج من 600,000 إلى أكثر من 1,000,000 معاملة في الثانية في بيئة مراقبة، متفوقًا بشكل ملحوظ على Agave. لكن سقف الأداء ليس المهم بحد ذاته، بل فصل الحقول.

وفقًا للوثائق والإرشادات التنفيذية، تم تصميم Firedancer كجزء موديولي: الشبكة، والمشاركة في الاتفاق، وتنفيذ المعاملات، كلها مكونات مستقلة. أخطاء إدارة الذاكرة في Rust allocator الخاص بـ Agave لا تنتقل إلى قاعدة كود C++ الخاص بـ Firedancer؛ وأخطاء المنطق في جدولة الكتل في Agave لا تؤثر على نموذج التنفيذ “Tile” الخاص بـ Firedancer.

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

تُعد عملية نشر Frankendancer “منصة انطلاق”: استبدال طبقة الشبكة وإنتاج الكتل في Agave بـ Firedancer، مع الاحتفاظ بالاتفاق والتنفيذ. هذا النهج يسمح بتحسين الأداء دون تعريض الشبكة كلها لمخاطر اتفاق غير موثوق به.

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

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

لماذا يهتم المنظمون ببرمجيات المدقق

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

في تقييمات جاهزية المؤسسات، كانت حالات الانقطاع السابقة أكبر عائق، ويُوصف Firedancer كعلاج محتمل. يُعتبر الاعتمادية عاملاً رئيسيًا في التمييز بين Solana وطبقات أخرى.

هذا المنطق يشبه تمامًا حملة تنويع العملاء في Ethereum. بالنسبة للمخاطر، السؤال الرئيسي هو: ماذا يحدث في حال حدوث مشكلة؟

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

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

يقدم Firedancer طريقًا لتضييق الفجوة عبر تحقيق الحد الأدنى من تنوع العملاء الذي تعتبره Ethereum معيارًا أساسيًا للبنية التحتية للإنتاج.

منحنى الاعتماد القادم

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

سجل الإنتاج لمدة 100 يوم، رغم أنه إيجابي، لا يزال قصيرًا مقارنة بعدة سنوات من تشغيل Agave. المشغلون الحذرون سينتظرون مزيدًا من البيانات قبل نقل الحصص.

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

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

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

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