MultiversX تطلق ترقية Supernova لفصل التوافق والتنفيذ

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

MultiversX، وهي مشاركة في نظام Cointelegraph Decentralization Guardians (CTDG) البيئي، تختبر الآن نهجًا يهدف إلى إزالة هذه النقطة الضيقة. إن ترقية Supernova تفصل توافق الآراء عن تنفيذ المعاملات، مما يمكّن المدققين من التصويت دون انتظار اكتمال التنفيذ—وينقل الحساب إلى خط أنابيب غير متزامن. Supernova نشطة حاليًا على شبكة الاختبار، ويستهدف التخطيط للنشر تاريخ تفعيل على الشبكة الرئيسية لاحقًا هذا العام.

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

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

قضت العديد من الشبكات سنوات في تحسين سرعة التوافق ونشر الكتل. إن منظور MultiversX هو أن هذه المكاسب غير كافية إذا بقي التنفيذ على المسار الحرج. السؤال الأساسي الذي تعالجه Supernova هو هندسي: هل يجب أن يبقى التنفيذ داخل حلقة التوافق، أم يمكن معالجته بشكل غير متزامن مع الحفاظ على السلامة والدقة؟

سوبيرنوفا، المتاحة الآن على الشبكة التجريبية، تقدم تسلسلًا مُعدَّلًا لإنتاج الكتل.

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

مع Supernova، يتغير هذا الترتيب. وفقًا لوصف MultiversX لـ فك الارتباط في Supernova، يختار المقترح المعاملات ويقترح الكتلة دون تنفيذها أولاً. ثم يقوم المدققون بالتحقق من أن الاقتراح يتبع قواعد البروتوكول ويمكنهم التصويت فورًا. يستمر التنفيذ بشكل غير متزامن في الخلفية، مما ينتج مخرجات تُشار إليها عادةً وتُوثق في رأس الكتلة التالية—لذلك يتأخر التنفيذ عن التوافق بكتلة واحدة تقريبًا، أو حوالي 600 مللي ثانية.

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

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

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

لضمان قوة النظام تحت أداء متغير للمُصِحّين، تقدّم MultiversX أيضًا حمايتين مصممتين لاستقرار التشغيل:

• مُقدّر إدراج نتائج التنفيذ (EIE): يحدّ EIE عدد نتائج التنفيذ التي يمكن الإشارة إليها في كتلة. الحد الأقصى مرتبط بما تستطيع العقد ذات المواصفات الدنيا معالجته بأمان، مما يقلل من خطر إغراق العقد الأضعف بالإشارة إلى عدد كبير جدًا من النتائج المعلقة.
• الضغط التلقائي الخلفي: إذا تأخر التنفيذ بشكل كبير، يتم تقليل سعة الكتلة للسماح للشبكة بالتعويض—بدلاً من السماح للتراكم التدريجي للتأخير.

للمطورين، الرسالة الأساسية هي أن "النهائية داخل الشريحة" يمكن أن تحدث فور توفر الإثبات. تشير MultiversX إلى أن هذا يحدث عادةً ضمن الجولة نفسها، ما بين 100–250 مللي ثانية، جنبًا إلى جنب مع ظروف تنفيذ أكثر قابلية للتنبؤ. هذا مهم بشكل خاص للتطبيقات التي تعتمد على حلقات تغذية راجعة سريعة—وتشمل الأمثلة المذكورة مبادئ DeFi عالية التردد وأنظمة دفاتر الأوامر على السلسلة، والتي يمكن أن تتدهور عندما تصبح التأخيرات مشكلة في تجربة المستخدم.

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

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

يأتي الترقية أيضًا ضمن تعاون أوسع في البنية التحتية يشمل Cointelegraph Decentralization Guardians. لاحظ التغطية السابقة أن Cointelegraph انضمت إلى MultiversX كمُحقق من خلال برنامج CTDG في مارس 2026، مما عمق الدور التشغيلي للمنظمة خارج أعمال المحتوى والمجتمع.

يُوصف مركز تطوير CTDG التابع لـ Cointelegraph أيضًا كشريك رسمي لـ MultiversX، ويربط البروتوكول بمجتمع مطورين أوسع. كما يشير المدخل إلى مشاركة عملية مثل تفويض مؤسسة MultiversX لعامل تحقق تابع لـ CTDG، وبناء فريق Dev Hub لوحة مراقبة مخصصة لعامل التحقق على MultiversX.

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

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

تم نشر هذا المقال أصلاً كـ Upgrade Separates Consensus and Execution to Address Scaling Limits على Crypto Breaking News – مصدرك الموثوق لأخبار التشفير، وأخبار البيتكوين، وتحديثات البلوكشين.