نشر MagicBlock الإصدار v1.0 من Validator في 6 أكتوبر 2026، وهو أول إصدار رئيسي لبيئة تشغيل آلة فيرتشوال سولانا المتخصصة التي تُمكّن Rollups المؤقتة الخاصة بها. وبعد أكثر من سنة ونصف من البناء والاختبار والتحسين، يُوحّد هذا الإصدار الميزات المستخدمة بالفعل في الإنتاج، ويعزز الأداء تحت الحمل، واستعادة الفشل، وأدوات المشغلين. يمكن للمطورين الآن تفويض حسابات مختارة إلى بيئة تنفيذ سريعة وموضعية تعمل بفترات كتل تقارب 10 مللي ثانية، ثم تُثبّت النتائج مرة أخرى على شبكة سولانا الرئيسية. 

يعمل أربعة مُصدّقين حاليًا على الشبكة الرئيسية عبر آسيا وأوروبا والولايات المتحدة ونسخة بيئة تنفيذ موثوقة. يأتي هذا التحديث مع تزايد طلب التطبيقات في الألعاب والتجارة والدفعات على تقليل التأخير والحفاظ على الخصوصية، وهو ما لا تستطيع الطبقة الأساسية وحدها تزويده، مع الاحتفاظ بالوصول الكامل إلى برامج وسائل السيولة الخاصة بـ Solana. يحول المُصدّق v1.0 Rollups المؤقتة إلى محرك فعلي جاهز للإنتاج من خلال منح المطورين معالجة متعددة الخطوات للنية، وتخزين مؤقت أرخص، وإجراءات تسويات ذرية، واقتصاديات أكثر وضوحًا، مع البقاء مرتبطًا بالكامل بـ Solana.

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

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

تمكّن إجراءات Magic برامج Solana من استخدام حالة التجميع المحدثة أثناء معاملة التسوية نفسها. عندما يتم تضمين إجراء في نفس معاملة Solana كالتزام، فإنه يعمل بشكل ذري: النجاح يُقدّم كل من الالتزام والإجراء؛ والفشل يُعيد تغيير المعاملة بالكامل. يزيل هذا الضمان فئة شائعة من مشكلات الحالة الجزئية التي كانت تتطلب سابقًا منطق استرداد مخصص. تُعيد الدعوات المُستدعاة النتيجة إلى التجميع بحيث يمكن للتطبيق التفاعل فورًا. كما أن إلغاء التفويض التلقائي يبسّط إعادة حسابات الطبقة الأساسية. تسرد ملاحظات الإصدار على GitHub هذه القدرات ضمن تدفقات التسوية، وتشير إلى تحسين معالجة ترتيب الالتزامات واتساق رمز الكتلة. معًا، تخلق حلقة أوثق بين البيئة عالية السرعة وأمان شبكة Solana الرئيسية.

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

تتيح إجراءات ما بعد التفويض للتطبيق ترتيب المهام التي تبدأ فور وصول الحساب إلى الـ rollup. يمكن أن تتضمن هذه الإجراءات تعليمات مشفرة، مما يمكّن من تشغيل سير عمل خاصة دون كشف الحالات الوسيطة. بالاقتران مع حزم النوايا، تدعم هذه الميزة مسار دفع خاص كامل: يوقّع المستخدم مرة واحدة على الشبكة الرئيسية، وتنفذ الـ rollup الجزء السري داخل بيئة تنفيذ موثوقة، ثم يتم تسويته النتيجة النهائية مرة أخرى على Solana. وصف وثائق MagicBlock نموذج الخصوصية بأنه يعتمد على أجهزة Intel TDX، حيث تحمي منطقة المعالج المغلقة الحالة من آلة الاستضافة. التنازل هو الثقة في مورد الأجهزة، وهو ما يذكره المشروع صراحةً. استمرار عمليات نقل الرموز باستخدام واجهات وSDKs Solana القياسية، لذا تظل المحافظ والبرامج الحالية متوافقة.

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

تُمكّن Magic ATAs المستخدم من إرسال رموز إلى مستلم على الـ rollup دون الحاجة أولاً إلى إنشاء حساب الرمز المرتبط بالمستلم على Solana أو دفع إيداع معفى من الإيجار. حساب الرمز المرتبط هو البنية القياسية لـ Solana التي تحتفظ برمز معين لمحفظة معينة؛ وإنشاؤه يتطلب SOL، وهو ما يفضل العديد من المستخدمين عدم إنفاقه مقدماً. تقوم Magic ATAs بتأجيل أو القضاء على هذا التكلفة لنشاط الـ rollup، مما يقلل من العوائق أمام التحويلات عالية التردد أو المؤقتة. تعمل هذه الميزة مع واجهات Token-2022 والرموز القياسية التي تدعمها بالفعل وحدة التحقق. وبما أن الحسابات تظل مؤقتة أثناء وجودها على الـ rollup، تبقى التكلفة الاقتصادية متناسبة مع الاستخدام الفعلي بدلاً من التخزين الدائم.

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

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

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

يُحسّن المُحقق v1.0 طريقة مزامنة الحسابات من الطبقة الأساسية. أصبحت المزامنة الآن أكثر توازيًا وقائمة على الطلب، مع مسارات خالية من القفل، ومشتريات مجمعة واستدعاءات للحسابات، بالإضافة إلى تغطية مُصنّفة لـ gRPC وWebSocket. كما تقلل مجموعات الاتصال، وتخزين الحسابات الفارغة مؤقتًا، وانخفاض تكاليف الأدوات من استهلاك الموارد. تؤدي هذه التغييرات إلى تقليل الحمل الذي يفرضه مُحققو rollup على نقاط نهاية Solana RPC وتحسين المرونة عند تأخر التحديثات أو انقطاع الاتصالات. يمكن استعادة أعمال التسوية المعلقة بعد إعادة التشغيل، مما يعالج فجوة الاسترداد السابقة.

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

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

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

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

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

يتم توسيع دعم التشغيل ليشمل sBPF v3، والتوافق مع Token-2022، ووحدات التشفير المسبقة، ونظام استدعاءات إضافي. تم محاذاة معلمات الإيجار مع السلسلة الأساسية، وتم تحسين محاكاة المعاملات. تُبقي هذه التحديثات المُحقق المؤقت متوافقًا مع تطور سولانا نفسه، مما يقلل من خطر فشل البرامج المكتوبة لشبكة mainnet داخل اللفة. تسجل ملاحظات الإصدار أيضًا تحديثات للاعتمادات التشغيلية المستهدفة لسولانا 4.x. تخفض تحسينات التوافق الحواجز أمام برامج سولانا الحالية لاستخدام بيئة السرعة العالية دون تعديل.

يمكن للمطورين الذين يعتمدون بالفعل على ملحقات Token-2022 أو المبادئ الكryptographic الأحدث الآن دمج هذه الميزات في الجلسات الزمنية الحقيقية. تساعد المحاكاة المحسّنة على اكتشاف المشكلات قبل وصولها إلى البيئة الإنتاجية. يمنع توافق معلمات الإيجار عدم التوافق الاقتصادي الدقيق بين الـ rollup والطبقة الأساسية. معًا، تعزز هذه التغييرات مبدأ التصميم القائل بأن الـ Ephemeral Rollups تمتد على Solana بدلاً من استبدالها. تستمر التطبيقات في التجميع مع مجموعة كاملة من برامج mainnet والسيولة، مع تسريع الأجزاء فقط التي تحتاج إلى زمن استجابة أقل أو خصوصية اختيارية.

إلى جانب إصدار البرنامج، ارتفع رسوم جلسة التفويض إلى 0.003 SOL ورسوم الالتزام إلى 0.001 SOL. تظل المعاملات العادية داخل اللفة مجانية. وفقًا لوثائق الرسوم الخاصة بالمشروع، يذهب حوالي 90 بالمائة من الرسوم المجمعة إلى مشغّل المُدقّق و10 بالمائة إلى البروتوكول. الجلسات والالتزامات هي النقاط التي تتصل فيها اللفة بـ Solana، لذا تنطبق الرسوم فقط على هذه التفاعلات من الطبقة الأساسية. سجّلت تحليلات Solana Compass ما بين 770 و950 معاملة يومية تتضمن برنامج التفويض خلال الأسبوع المنتهي في 5 أكتوبر 2026، مما يوفر قاعدة مرجعية لحجم المعاملات الذي سيتحمل الآن الأسعار الجديدة.

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

تستهدف مكافآت SOL العناوين التي تولد حصة كبيرة من نشاط البروتوكول. تشير MagicBlock إلى أن مجموعة أولية من المُفوّضين النشطين قد تم اختيارها بالفعل، وتدعو مُطوري التطبيقات الإضافيين للتقديم. يُصاغ هذا البرنامج كخطوة أولى نحو الحوافز البرمجية الموصوفة في مواد اقتصاديات الرمز الخاص بالمشروع. إن البدء بـ SOL بدلاً من رمز جديد يسمح للفريق بضبط معلمات المكافآت بناءً على بيانات الاستخدام الفعلية. وتُقدَّم المكافآت المستدامة للمشغلين والمحققين على أنها ضرورية لتحقيق الهدف طويل الأمد المتمثل في شبكة أكثر لامركزية.

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

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

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

تسرد الوثائق أربعة مُحققين نشطين للـ rollup على شبكة Solana الرئيسية: واحد في آسيا، وواحد في أوروبا، وواحد في الولايات المتحدة، بالإضافة إلى واحد يعمل داخل بيئة تنفيذ موثوقة. يدعم التوزيع الجغرافي ادعاء المشروع بشأن التوطين المشترك لتقليل التأخير الكلي. يمكن للتطبيقات توجيه الجلسات نحو المُحقق الأقرب أو الأكثر ملاءمة، مما يقلل من تأخير الشبكة للمستخدمين في تلك المناطق. يوفر مثيل TEE جذر الثقة المادي للسير العمل الخاصة. تُظهر سجل الإصدارات أن الإصدار 0.16.1 تم إصداره في اليوم السابق لإصدار 1.0.0، مما يدل على التكرار المستمر حتى الإصدار البارز.

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

1. ما الذي يغيره Validator v1.0 بالضبط لمستخدمي Ephemeral Rollup الحاليين؟ 

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

2. كيف تؤثر رسوم الجلسة والالتزام الجديدة على تكاليف التطبيق؟ 

كل جلسة تفويض الآن تكلف 0.003 SOL، وكل التزام بعد الأول يكلف 0.001 SOL، بينما تظل معاملات اللفّ العادية مجانية. يمكن للتطبيقات ذات الحجم العالي التقدم للحصول على استردادات SOL لتعويض جزء من هذه الرسوم. وبالتالي، فإن التكلفة الصافية تعتمد على تكرار الجلسات وصلاحية الاستردادات وليس على عدد المعاملات الداخلية.

3. هل نموذج الخصوصية مبني على إثباتات الصفرية المعرفة أم على الأجهزة؟ 

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

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

تم توسيع التوافق ليشمل Token-2022 و sBPF v3 ووحدات التشفير المسبقة ومحاكاة المعاملات المحسّنة. وبالتالي، يمكن لمعظم البرامج المكتوبة لشبكة Solana الرئيسية الحالية التنفيذ داخل اللفة، على الرغم من أن المطورين يجب أن يختبروا نتائج المحاكاة وتوافق معلمات الإيجار.

5. ما الذي لا يزال تجريبيًا في الإصدار 1.0.0؟ 

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

6. كيف يعمل استرداد التسوية بعد إعادة تشغيل المُحقق؟ 

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

7. أين يمكن للمطورين العثور على وثائق التكامل وشفرة المصدر؟ 

توجد الوثائق الرسمية على docs.magicblock.gg، ويمكن الاطلاع على مصدر المُحقق، بما في ذلك ملاحظات الإصدار الكاملة v1.0.0، في مستودع magicblock-labs/magicblock-validator على GitHub. تم تحديث كلا المصدرين بالتوازي مع إعلان 6 أكتوبر 2026.

8. ما هي المسار الطويل الأمد نحو شبكة أكثر لامركزية؟ 

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

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

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