طوال معظم تاريخها، عملت Solana على تطبيق مدقق واحد. وقد جعلها ذلك سريعة ولكنها هشّة، نظراً لأن خطأ برمجياً واحداً يمكن أن يؤدي إلى توقف السلسلة بأكملها.
يُعالج Firedancer هذه المشكلة. فهو يمنح Solana عميلاً ثانياً ومستقلاً تماماً برمز برمجي منفصل، ولغة مختلفة، وفريق خاص به، وهو نموذج الأمان متعدد العملاء الذي تعتبره Ethereum أساساً لها.
إليك كيفية بناء Firedancer، ومكانه بعد الإطلاق، وما يعنيه لموثوقية Solana وخارطة طريقها. 👇
ما هو Firedancer؟
Firedancer هو عميل مدقق لـ Solana تم تطويره بواسطة Jump Crypto، الذراع الخاص بتقنية بلوكتشين التابع لشركة التداول Jump Trading Group. عميل المدقق هو البرنامج الذي يعالج المعاملات، وينشئ الكتل، ويصوت في الآلية التوافقية، لذا فإن العميل الذي تشغله العقدة يحدد مدى أداء الشبكة.
بدأت Jump المشروع في عام 2022 واتخذت قراراً مدروساً. فبدلاً من تعديل برنامج Solana المستند إلى لغة Rust، قامت بإعادة كتابة المدقق من الصفر بلغتي C وC++، وهما لغتان تمنحان تحكماً دقيقاً في الذاكرة والأجهزة. ولا يتشارك العميل الجديد أي كود مع العميل الحالي، وهذا هو الهدف الأساسي.
العميل الافتراضي لـ Solana هو Agave، وتتم صيانته بواسطة Anza، وهو فريق تم فصله عن Solana Labs. النسخة الأكثر استخداماً هي نسخة Jito المعدلة والمحسنة لـ MEV من Agave. ويتميز Firedancer عن كليهما كبناء مستقل حقاً، إلى جانب عملاء أصغر مثل Sig وMithril وTinydancer.
على الرغم من الارتباك المتكرر، فإن Firedancer ليس توكيناً، أو إيردروب، أو تغييراً في البروتوكول. فهو لا يمس إصدار SOL، أو مكافآت staking، أو قواعد المعاملات. إنه يغير كيفية تشغيل المدققين دون تغيير ما تقوم به الشبكة.
كيف يعمل Firedancer؟
يتعامل Firedancer مع المدقق كمجموعة من المكونات المتخصصة والمعزولة بدلاً من برنامج واحد ضخم، ثم يزيل العبء التشغيلي لنظام التشغيل الذي يحدد الإنتاجية عند التوسع.
1. المعمارية القائمة على البلاطات (Tile-Based Architecture)
يقسم Firedancer عمل المدقق إلى عمليات مستقلة تسمى بلاطات (tiles)، حيث يتعامل كل منها مع مهمة واحدة مثل الشبكات، أو التحقق من التوقيعات، أو تجميع المعاملات، أو إنتاج الكتل. وكل بلاطة مخصصة لنواة وحدة المعالجة المركزية (CPU) الخاصة بها وتتواصل مع البلاطات الأخرى من خلال قنوات الذاكرة المشتركة.
تعمل Agave كعملية أحادية متجولة حيث تتشارك الشبكات والتنفيذ والإجماع الذاكرة. يستغل تصميم Firedancer المقسم الأجهزة المتعددة النوى من خلال التوازي ويحتوي الإخفاقات، حيث نادرًا ما يؤدي الخلل في وحدة واحدة إلى إيقاف المدقق بأكمله. تحافظ عملية تخصيص الذاكرة المدركة لـ NUMA هياكل البيانات الخالية من الأقفال على عدم تنافس النوى على نفس الموارد.
2. شبكات تجاوز نواة نظام التشغيل
تمر كل حزمة بيانات يتعامل معها المدقق القياسي عبر مسار شبكة نواة Linux، والذي يختنق تحت الحمل الثقيل. يتخطى Firedancer معظم هذا المسار باستخدام AF_XDP و eBPF، حيث يقرأ الحزمالقريبة من بطاقة الشبكة بحيث يصبح الحد الأقصى هو الأجهزة وليس البرامج الموجودة أمامها.
فوق ذلك يوجد إصدار مخصص من QUIC يُسمى fd_quic وتوسيع نطاق جانب الاستقبال الذي يوزع حركة المرور عبر النوى. وفقًا لـ وثائق Firedancer, لا تنام وحدات الشبكة مطلقًا، حيث تقوم بالاستطلاع المشغول للحفاظ على ثبات زمن الوصول. التكلفة هي أن هذا يتطلب صلاحيات الجذر (root) أثناء الإعداد وأجهزة شبكة محددة.
3. التحقق المعجل من التوقيعات
يعد التحقق من توقيعات Ed25519 أحد أكثر مهام المدقق تكلفة على نطاق واسع. يستخدم Firedancer تعليمات المتجهات AVX-512 للتحقق من التوقيعات في دفعات متوازية بدلاً من التحقق منها واحدة تلو الأخرى. قام مهندسو Jump بقياس وقت روتينهم بحوالي 3.9 أضعاف سرعة الإصدار القياسي للقيم العددية على نفس الشريحة.
4. انتشار الكتل
يعمل Firedancer أيضًا على تحسين Turbine، وهي الآلية الخاصة بـ Solana لانتشار الكتل، وترميز المحو الخاص بها بحيث تنتشر البيانات بكفاءة تحت الضغط. إلى جانب مكاسب الشبكات والتشفير، هذه هي الطريقة التي يطارد بها العميل إنتاجية أعلى بكثير مما أظهرته البرامج الأصلية.
Frankendancer مقابل Firedancer
يتم الخلط بين الاسمين باستمرار، لذا فإن الفرق مهم. Frankendancer هو برنامج هجين: فهو يربط رموز الشبكات وإنتاج الكتل الخاصة بـ Firedancer مع تشغيل Rust الخاص بـ Agave والإجماع، مما يسمح للمدققين اعتماد جزء من البنية دون الوثوق في رمز إجماع غير مختبَر.
وصل Frankendancer إلى mainnet في عام 2024 واكتسب زخمًا حقيقيًا طوال عام 2025. نظرًا لأنه يعتمد على Agave للتنفيذ والإجماع، فإن أداءه محدود ببيئة التشغيل تلك، وهو لا يحل تمامًا مشكلة العميل الفرد، حيث لا يزال كل عقدة يعتمد على إجماع Agave.
يتخلى Firedancer الكامل عن هذا الاعتماد. فهو ينفذ مسار المدقق بأكمله، بما في ذلك الإجماع والتنفيذ، في قاعدة رموز C و C++ المستقلة. هذا الإصدار هو ما يمنح Solana عميلاً ثانياً حقيقياً ومنطقة فشل منفصلة عن Agave.
إطلاق mainnet والتبني
أعلنت Jump Crypto عن إطلاق mainnet الكامل لـ Firedancer في 12 ديسمبر 2025 في Solana Breakpoint في أبو ظبي. بحلول ذلك الوقت، كان العميل قد عمل بهدوء في الإنتاج على مجموعة مدققين صغيرة لمدة 100 يوم تقريبًا، مما ينتج أكثر من 50,000 كتلة بنظافة. أجرى الفريق تدقيقًا أمنيًا عامًا مدعومًا بمكافأة أخطاء بقيمة مليون دولار أولاً.
كان طرح المنتج بطيئًا بشكل متعمد وليس تحولاً مفاجئاً. صرح المهندس المؤسس ريتشي باتل لـ CoinDesk في مايو 2026 أن العميل قد عالج عشرات الملايين من المعاملات بينما توسع التبني بعناية.
بحلول النصف الأول من عام 2026، عملت عائلة Firedancer على حوالي 20 بالمائة أو أكثر من المدققين النشطين، بينما استحوذ العميل الكامل على حصة منخفضة ذات رقمين من SOL المخزنة. لا يزال فرع Agave التابع لـ Jito يحتفظ بالغلظة، لذا فإن شبكة متعددة العملاء متوازنة تبعد سنوات. ارتفع سعر SOL بنحو 6 بالمائة بعد الإطلاق، واستقرت مجموعة المدققين بالقرب من 840 عقدة، منخفضة عن ذروة تجاوزت 1,300.
لماذا يهم تنوع العملاء
يوضح سجل انقطاع الخدمة في Solana هذا الاهتمام. يربط تحليل Helius لفترة توقف الشبكة خمسة من أصل سبعة توقفات رئيسية بأخطاء في المدقق أو العميل بدلاً من تصميم الإجماع. عندما يعمل حوالي 90 بالمائة من الحصة السوقية على جزء واحد من البرامج، يمكن لخطأ برمجي واحد تجميد إنتاج الكتل بغض النظر عن مدى سرعة السلسلة.
تعلمت Ethereum هذا في وقت مبكر وتتعامل مع تنوع العملاء كقاعدة أمان، بهدف الحفاظ على أي عميل فرد أقل من ثلث قوة الإجماع. يمكن لعميل أعلى من هذا المستوى إيقاف الحسم النهائي؛ وفوق الثلثين يمكنه حسم الكتل السيئة. بدأت Solana بتركيز أكبر بكثير، يقرب من 90 بالمائة على عميل واحد.
يغير Firedancer هذه المعادلة. لا تشترك في أي رموز أو لغة مع Agave، لذا فإن خطأ الذاكرة في مخصص الذاكرة Rust الخاص بـ Agave يجب ألا يصل إلى قاعدة رمز C++ الخاصة بـ Firedancer، ويمكن الاثنين الفشل بشكل مستقل. يمكن للشبكة النجاة من خطأ كارثي في أي منهما، طالما تم توزيع الحصة بحيث لا يستطيع أي عميل إخراج أغلبية ساحقة غير متصلة بالإنترنت في نفس الوقت.
هذا هو الطرح المؤسسي أيضًا. تريد فرق المخاطر معرفة ما يحدث عندما يتعطل شيء ما، ويبدو العملاء المستقلون مختلفين تمامًا بالنسبة لهم. مع ترتيب JPMorgan إصدار أوراق تجارية على Solana واستعداد State Street لصندوق سيولة مرمز للشبكة، فإن تقليل مخاطر العميل الفرد يمثل استجابة لاعتراض رئيسي على بناء التمويل المنظم هناك.
Firedancer و Alpenglow وخريطة طريق Solana
Firedancer هو النصف الآخر من ترقية أكبر، والناس يخلطون بينه وبين النصف الآخر. Alpenglow هو محرك إجماع جديد من Anza يحل محل Proof of History و TowerBFT ويستهدف حسمًا نهائيًا يقارب 150 مللي ثانية. Firedancer هو عميل؛ بينما Alpenglow هو بروتوكول إجماع. وافق المدققون عليه، وهو قيد الاختبار قبل تفعيل mainnet المتوقع في وقت لاحق من عام 2026.
حدود الحوسبة مهمة أيضًا. كانت Solana ترفع الحوسبة لكل كتلة من خلال مقترحات مثل SIMD-0256، والتي دفعت الحد الأقصى لتجاوز 60 مليون وحدة، مع مناقشة المزيد من الزيادات. تفرض الحدود الأعلى ضغطًا أكبر على أجهزة المدقق، وهو بالضبط الضغط الذي صُممت بنية Firedancer لاستيعابه.
يخطط كلا الفريقين أيضًا لأمان ما بعد الكم. في أبريل 2026، استقر فريق Anza وفريق Firedancer بشكل منفصل على Falcon، وهو مخطط توقيع مختار من قِبل NIST تناسب توقيعاته المدمجة شبكة عالية الإنتاجية دون الإضرار بالأداء.
متطلبات الأجهزة لعميل Firedancer
زعمت التغطيات المبكرة أن عميل Firedancer سيجعل عملية التحقق أرخص. وحدث العكس تماماً، فهو يكافئ الأجهزة ذات النواة العالية ومعدات الشبكات المحددة، وقد أدت حدود الحوسبة المتزايدة لشبكة Solana إلى رفع سقف المتطلبات بدلاً من خفضها.
إرشادات المشغلين لعام 2026 تتقارب حول مواصفات إنتاجية مشابهة:
- وحدة المعالجة المركزية (CPU): شريحة ذات 12 نواة و24 خيط معالجة بتردد 2.8 جيجاهرتز هي الحد الأدنى، لكن مشغلي الإنتاج يستهدفون 24 نواة أو أكثر بتردد 3.5 جيجاهرتز وما فوق. وتهيمن معالجات AMD EPYC مثل 9354 و9355، في تصميمات ذات مقبس أحادي لتجنب التأخير عبر المقابس.
- تقنية AVX-512: إلزامية للتشفير المُعسَّر. وبدونها، تتلاشى مكاسب التحقق من التوقيع.
- ذاكرة الوصول العشوائي (RAM): تتراوح تقريباً بين 384 جيجابايت و512 جيجابايت من ذاكرة التصحيح (ECC)، وهي أعلى بكثير من التوجيهات السابقة، للتعامل مع كتل أكبر وحالة الحسابات.
- التخزين: محركات NVMe Gen4 أو Gen5 بمستوى المؤسسات، مع فصل نظام التشغيل على قرص مستقل عن بيانات دفتر الأستاذ.
- الشبكة: اتصال متماثل بسرعة 10 جيجابت في الثانية وبطاقة شبكة تدعم تقنية XDP، والتي يحتاجها تصميم تجاوز النواة ليعمل على الإطلاق.
- الضبط: تعطيل المعالجة الترابطية (Hyperthreading)، وعزل الأنوية عن جدولة النواة (Kernel)، وتعيين تقارب وحدة المعالجة المركزية بحيث تملك كل وحدة (Tile) نواتها الخاصة. تعامل مع كل هذه الأمور كمتطلبات صارمة.
إن عميل Firedancer عبارة عن بنية تحتية بمستوى احترافي مصممة للأجهزة القوية. وهي لا تجعل تشغيل عقدة أخف أو أرخص.
لماذا تبني شركة Jump عميل Firedancer؟
يعود دافع Jump إلى طبيعة عملها الأساسي. فقد أمضت مجموعة Jump Trading Group عقدين من الزمن في بناء أنظمة منخفضة التأخير تنقل أحجام بيانات ضخمة بأقل قدر من التأخير، ويطبق Firedancer هذه الثقافة على المدقق. ووصف باتيل العميل بأنه يتصرف وكأنه محرك تداول حقيقي، وقاد كبير العلماء كيفن باورز عروض الإنتاجية المبكرة.
الهدف المعلن هو الموثوقية والأداء لشبكة Solana، وهي شبكة تستثمر فيها Jump بقوة. والجانب المالي يشكل جزءاً من ذلك أيضاً. يكسب المدققون من القيمة القصوى القابلة للاستخراج (MEV)، وهي الربح الناتج عن ترتيب المعاملات داخل الكتل، وسوق MEV في Solana أصبح الآن نشاطاً تجارياً حقيقياً. لا يغير Firedancer اقتصاديات MEV بشكل مباشر، نظراً لأن ذلك يعيش في الغالب ضمن متغيرات مثل Jito، لكن العميل الأسرع والأكثر استقراراً يعزز البنية التحتية التي يعتمد عليها المشغلون المهتمون بـ MEV.
المخاطر والأسئلة المفتوحة
المخاطر والأسئلة المفتوحة
- المقارنة المعيارية مقابل الإنتاجية الحية: يأتي رقم مليون TPS (معاملة في الثانية) أو أكثر من عروض تجريبية خاضعة للرقابة. الإنتاجية الحقيقية على الشبكة الرئيسية أدنى بكثير، وتصل إلى الآلاف، ولا توضح المقارنات المعيارية الكثير عن السلوك تحت الحمل العدائي أو انقسامات الشبكة.
- الهجرة البطيئة: يتطلب تبديل العملاء جهداً حقيقياً في ضبط الأجهزة والعمليات، ولدى Agave سنوات من تاريخ الشبكة الرئيسية التي لا يستطيع Firedancer مجاراتها بعد. سيتردد المشغلون الحذرون وينتظرون، لذا فإن الحصة تتغير بشكل تدريجي.
- مخاطر العميل الواحد المستمرة: حتى تنتقل حصة كافية إلى عملاء مستقلين، قد يؤدي وجود خلل في برنامج Agave المهيمن إلى تعطيل السلسلة. التنوع يساعد فقط عندما يصبح التوزيع متوازناً حقاً.
- قاعدة أكواد جديدة: إعادة الكتابة من الصفر بلغة C وC++ تحمل مخاطر خاصة بالذاكرة والتزامن، ولهذا السبب أعقب الإطلاق تدقيق طويل ومكافآت للعثور على الثغرات. سجل الإنتاج الضئيل يترك مجالاً للمفاجآت.
- ضغوط المركزية: يفضّل ملف الأجهزة الثقيلة المشغلين المحترفين مراكز البيانات الكبيرة، كما أن قواعد تركز الحصة في برنامج تفويض مؤسسة Solana قد تدفع عملية التحقق نحو عدد أقل من الجهات الأكثر تمويلاً.
- لا يوجد استثمار مباشر: لا توجد عملة رقمية لعميل Firedancer، لذا يتم التعرض له عبر SOL، مع تقلبات العملات الرقمية المعتادة بغض النظر عن أي ترقية فردية.
الأفكار الأخيرة
يغير Firedancer جوهر النقاش الدائر حول Solana. فقد روجت الشبكة دائماً للسرعة، وكانت السرعة حقيقية، لكنها كانت ترتكز على نقطة فشل برمجية واحدة أدت إلى انقطاعات متكررة ومحرجة. العميل الثاني المستقل هو الحل الهيكلي، وقد ظهر بشكله الإنتاجي في ديسمبر 2025.
سيستمر رقم مليون معاملة في الثانية في جذب عناوين الأخبار، لكنه الجزء الأقل إثارة للاهتمام. التغيير الحقيقي هو أن Solana تمتلك الآن مساراً موثوقاً لتحقيق مرونة متعددة العملاء، وهو النوع الذي يسمح للمؤسسات بالتعامل معها كبنية تحتية إنتاجية وليست مجرد تجربة سريعة ولكنها هشّة.
التنفيذ على نطاق واسع هو السؤال المفتوح. يجب أن تهاجر الحصة، ويجب أن تنجو الأكواد الجديدة لسنوات من الظروف العدائية، ولا يمكن لمتطلبات الأجهزة أن تعيد مركزية مجموعة المدققين بهدوء. يمنح Firedancer شبكة Solana البنية التي كانت تحتاجها؛ وما إذا كانت الشبكة ستجني الفائدة الكاملة يعتمد على طريقة طرحها.
