ستيلار (XLM) تُلزم مدققي الشبكة باعتماد بروتوكول Bell 30 قبل 23 نوفمبر

ستيلار تثبّت ترقية Bell في 23 نوفمبر

مشغّلو العقد ومطوّرو المحافظ وفرق الهندسة في المنصات الذين يشغّلون بنية ستيلار (XLM) هم الأطراف التي تُلزمها خطة الترقية المنشورة حديثًا. نشرت ستيلار دليل ترقية Bell بتاريخ الثلاثاء 20 أكتوبر، ويحدد الدليل موعدين حاسمين: ترقية الشبكة التجريبية يوم الثلاثاء 3 نوفمبر، وتفعيل الشبكة الرئيسية يوم الاثنين 23 نوفمبر عبر تصويت نهائي للمدققين. وقد بدأ طرح الإصدارات المستقرة من البنية التحتية وحزم SDK التي يتطلبها تغيير البروتوكول يوم الجمعة 16 أكتوبر، وسيستمر حتى الجمعة 23 أكتوبر 2026، أي أن نافذة الاستعداد انفتحت بالفعل. ويتيح دليل الترقية المنشور على مدونة المطوّرين في المشروع رؤية ما يتعين على كل طرف إطلاقه خطوة بخطوة، فيما تؤكد الإعلان على X من الحساب الرسمي لستيلار الجدول الزمني نفسه. المخاطر بالنسبة لفرق البنية التحتية ملموسة: أي محفظة أو منصة أو عقد يفشل في تحديث SDK الخاص به قبل 23 نوفمبر سيفقد القدرة على التعرّف إلى كتل السجل الجديدة، وهو ما يعني عمليًا الخروج من الشبكة الحية. أما حاملو العملة من الأفراد فخارج هذه الالتزامات كليًا؛ تبقى العملات في أماكنها، ولا يلزم أي استبدال يدوي أو ترحيل للأصول، ولا يُطلب أي إجراء من أي شخص يحتفظ بـ Stellar (XLM) في محفظة شخصية. وتصف ملاحظات الإصدار ترقية Bell، الاسم الرمزي للبروتوكول 30، بأنها حزمة صُممت لجعل الحسابات الذكية قابلة للنشر من قِبل الشركات على نطاق واسع، ولبدء العمل على التوقيعات الآمنة كميًا، ولنقل توقيت السجل إلى دقة زمنية أدق، وهي ثلاثة تغييرات تستهدف تبسيط اندماج منصات التقنية المالية الكبرى وخدمات الحفظ بالوكالة مع الشبكة. ولم يتضمن الإعلان أي توجيه متعلق بسعر XLM، ولا حاجة إليه في تحديث صلب يترك الأرصدة كما هي؛ ما يمسه هو منفعة العملة، لأن الحزمة تغيّر من يستطيع البناء على الشبكة بتكلفة منخفضة وبأي حجم من المعاملات.

@StellarOrg · منشور على X

الإعلان على X.

عرض على X

مقترحات CAP-84 وCAP-88 وCAP-87

تجمع حزمة Bell ثلاثة مقترحات تقدّم جوهري، يزيل كل منها عائقًا معماريًا محددًا أمام المستخدمين التجاريين. يقدّم CAP-84 ما يُعرف بالعناوين W، وهي مخطط تعدد إرسال للعقود الذكية يتيح لبنك أو منصة إدارة أرصدة ملايين العملاء عبر عقد واحد بدلًا من إنشاء محفظة منفصلة لكل مستخدم؛ هذا التصميم هو ما يجعل خدمة الحفظ بالوكالة على نطاق واسع ممكنة عبر عقد واحد. وينقل CAP-88 ساعة النظام من الثواني إلى المللي ثانية، وهي خطوة هندسية تضعها ملاحظات الإصدار أساسًا لإغلاق السجل في أقل من ثانية في إصدار مستقبلي. أما CAP-87 فيكتب دعم معيار التوقيع ما بعد الكمي ML-DSA مباشرة في Stellar (XLM) Core، ممتدًا الحماية المقاومة للكم إلى عقود Soroban الذكية دون إضافة تكلفة على المعاملات، وهو تغيير يصلّح أمن المفتاح الخاص على مستوى البروتوكول لا على مستوى المحفظة. وتربط المنطق التجاري بين هذه الأجزاء: نماذج الحفظ الأبسط تخفض تكلفة تشغيل منصات التقنية المالية على الشبكة، ويربط دليل الترقية هذا الخفض بالحجم الأعلى للمعاملات وبالطلب العضوي على XLM كأصل لرسوم الشبكة، وهي نفس المسارات التي تشتغل عليها حالات استخدام المدفوعات PayFi؛ ولمن يريد فهم الآلية، يستعرض دليلنا رسوم شبكات العملات الرقمية التفاصيل. وجاهزية الكم والتسوية دون ثانية هما، بتأطير ملاحظات الإصدار، متطلبان أساسيان لترميز الأصول الحقيقية، وهو القطاع الذي تستهدفه ستيلار استراتيجيًا؛ وتمنح بصمة الشبكة في الأصول الحقيقية المرمنة ودورها في خدمة ترميز بقيمة 30 تريليون دولار سياقًا قابلًا للقياس لذلك الهدف، فيما يشير التفعيل الأخير لـ Chainlink Data Streams إلى الاتجاه نفسه. ويضيف الدليل لحاملي العملة على المدى الطويل ضمانة إضافية: لأن الانتقال إلى البروتوكول الجديد إلزامي تمامًا لكل مشغّل عقد، لن يحدث أي تشعب غير رسمي أو انقسام في العملة.

قراءتنا أن Bell أقرب إلى اختبار جاهزية للبنية التحتية منها إلى محفّز سوقي، وأن القيد الحقيقي يقع على المنصات والمحافظ لا على الحاملين. التصميم الإلزامي يستبعد خطر الانقسام، فيمحو الغموض الذي يحيط عادة بالتحديث الصلب، لكنه يعني أيضًا أن موثوقية الشبكة حتى 23 نوفمبر معلقة على وصول تحديثات SDK في موعدها من أطراف ثالثة. والأدوات المرمنة مثل xStocks وتوسّع الأصول الحقيقية يمنحان ستيلار قصة طلب يُفترض أن التوقيعات الآمنة كميًا والسجلات الأسرع تدعمها؛ وسيتضح إن كان ذلك يتحول إلى طلب مستدام على رسوم Stellar (XLM) من حجم المعاملات بعد التفعيل. الإجراء المتبقي بيد مشغّلي البنية التحتية: تحديثات SDK قبل 23 نوفمبر، وتصويت المدققين الذي لم يُطرح بعد.