$NEAR يدعم توقيع الحسابات المقاوم للحوسبة الكمومية، لكن هذا لا يعني أن السلسلة بأكملها قد أتمت الانتقال إلى مقاومة الحوسبة الكمومية. يستحق الموضوع الذي يحتل المرتبة السادسة حاليًا في الساحة أن يُحلل إلى مكوناته، لكن المحطات التقنية المرتبطة به تعود إلى يوليو وسبتمبر، ولا يصح تقديمها على أنها ميزة جديدة أُطلقت اليوم.
المستوى الأول هو كيفية تفويض الحساب للمعاملات. صدر nearcore 2.13.0 في 9 يوليو، وأعلن اعتماد ML-DSA-65 بوصفه النوع الثالث لتوقيع المعاملات ومفاتيح الوصول، إلى جانب النوعين السابقين. يمنح هذا التغيير الحساب خيارًا جديدًا للتحقق من التوقيعات، لكنه لا يعني أن جميع الحسابات القائمة ستبدل مفاتيحها تلقائيًا، ولا يمكن الاستناد إليه للتأكيد أن الحسابات كلها اعتمدت الخوارزمية الجديدة.
المستوى الثاني هو قدرة العقد على التحقق من رسالة. أضاف الإصدار المرشح لشبكة الاختبار 2.14.0-rc.1، الصادر في 16 سبتمبر، واجهة ml_dsa_verify للتحقق من الرسائل داخل العقود. وهذا مسار مختلف عن التفويض الأصلي لمعاملات الحسابات: قدرة عقد على التحقق من توقيع لا تثبت مباشرة أن كل العمليات التي يتحكم فيها، أو الأصول الخارجية، أو الرسائل العابرة للسلاسل قد أتمت انتقالها الآمن. كما لا يصح وصف الإصدار المرشح للاختبار بأنه نُشر بالفعل على الشبكة الرئيسية.
أما المستوى الثالث فهو نطاق انتقال النظام بأكمله. توقيع الحسابات حلقة واحدة فحسب؛ إذ يلزم وجود أدلة منفصلة على إصدار البروتوكول الذي تستخدمه العقد، وكيفية تحديث المفاتيح القائمة، وطريقة التعامل مع التبعيات الأخرى. ولا يجوز استنتاج أن اعتماد خوارزمية جديدة في وحدة واحدة يمنح جميع طبقات النظام المستوى نفسه من الحماية.
وينبغي أيضًا التمييز بين التواريخ. عرض سجل المطورين بتاريخ 2 يوليو تجربة لإضافة مفتاح وتحويل أموال في بيئة معزولة؛ أما 9 يوليو فكان موعد إصدار نسخة موجهة إلى الشبكة الرئيسية؛ وأدرج الإصدار نفسه خطة لبدء التصويت على البروتوكول في 20 يوليو. نجاح العرض التوضيحي، وإصدار النسخة، وخطة التصويت، والتفعيل الفعلي على الشبكة ليست حالات إنجاز متطابقة. لم نتحقق في هذه الجولة من نتائج الترقية على الشبكة بأكملها، لذا لن نتعامل مع الموعد المخطط له كما لو كان إيصالًا بالتنفيذ.
بالنسبة إلى المستخدم العادي، السؤال الأكثر تحديدًا هو: هل أُعد مفتاح وصول من هذا النوع فعلًا لحسابه؟ وهل تستطيع المحفظة التي يستخدمها إنشاءه وحفظه وتوقيعه على النحو الصحيح؟ وهل يدعم التطبيق الإجراءات اللازمة؟ لا يكفي الاطلاع على عنوان الخبر للحكم بأن الحساب الذي بحوزته محمي بالفعل بنظام التوقيع الجديد. وبعد إضافة مفتاح جديد، ينبغي التحقق من صلاحيات المفاتيح القديمة وفق إعدادات الحساب الفعلية.
أما المطورون، فعليهم التمييز بين معاملات الحسابات الأصلية والتحقق من رسائل العقود. يتعلق المسار الأول بمن يملك صلاحية تفويض عمليات الحساب، بينما يتعلق الثاني بكيفية تحديد البرنامج لصحة رسالة ما. وحتى اجتياز التحقق من التوقيع لا يعني أن محتوى الرسالة أو نطاق الصلاحيات أو منطق العمل صحيح بطبيعته. يجب أن تتحدد حدود الأمان في مسار التفويض الفعلي.
ما أترقبه هو نقاط التحقق التالية: سجلات الإصدار الرسمي وتفعيل البروتوكول، ومدى دعم المحافظ، والتعليمات الواضحة بشأن الانتقال. ما يمكن تأكيده حاليًا هو أن NEAR تعمل على تطوير قدرات مختلفة على مستوى توقيع الحسابات والتحقق من توقيعات العقود؛ أما ما لا يمكن تأكيده فهو أن جميع الحسابات القديمة والتطبيقات والتبعيات الخارجية قد أتمت الانتقال معًا. هذا تقييم لنطاق تقني، وليس استنتاجًا لاتجاه سعر العملة من اسم الخوارزمية.
المستوى الأول هو كيفية تفويض الحساب للمعاملات. صدر nearcore 2.13.0 في 9 يوليو، وأعلن اعتماد ML-DSA-65 بوصفه النوع الثالث لتوقيع المعاملات ومفاتيح الوصول، إلى جانب النوعين السابقين. يمنح هذا التغيير الحساب خيارًا جديدًا للتحقق من التوقيعات، لكنه لا يعني أن جميع الحسابات القائمة ستبدل مفاتيحها تلقائيًا، ولا يمكن الاستناد إليه للتأكيد أن الحسابات كلها اعتمدت الخوارزمية الجديدة.
المستوى الثاني هو قدرة العقد على التحقق من رسالة. أضاف الإصدار المرشح لشبكة الاختبار 2.14.0-rc.1، الصادر في 16 سبتمبر، واجهة ml_dsa_verify للتحقق من الرسائل داخل العقود. وهذا مسار مختلف عن التفويض الأصلي لمعاملات الحسابات: قدرة عقد على التحقق من توقيع لا تثبت مباشرة أن كل العمليات التي يتحكم فيها، أو الأصول الخارجية، أو الرسائل العابرة للسلاسل قد أتمت انتقالها الآمن. كما لا يصح وصف الإصدار المرشح للاختبار بأنه نُشر بالفعل على الشبكة الرئيسية.
أما المستوى الثالث فهو نطاق انتقال النظام بأكمله. توقيع الحسابات حلقة واحدة فحسب؛ إذ يلزم وجود أدلة منفصلة على إصدار البروتوكول الذي تستخدمه العقد، وكيفية تحديث المفاتيح القائمة، وطريقة التعامل مع التبعيات الأخرى. ولا يجوز استنتاج أن اعتماد خوارزمية جديدة في وحدة واحدة يمنح جميع طبقات النظام المستوى نفسه من الحماية.
وينبغي أيضًا التمييز بين التواريخ. عرض سجل المطورين بتاريخ 2 يوليو تجربة لإضافة مفتاح وتحويل أموال في بيئة معزولة؛ أما 9 يوليو فكان موعد إصدار نسخة موجهة إلى الشبكة الرئيسية؛ وأدرج الإصدار نفسه خطة لبدء التصويت على البروتوكول في 20 يوليو. نجاح العرض التوضيحي، وإصدار النسخة، وخطة التصويت، والتفعيل الفعلي على الشبكة ليست حالات إنجاز متطابقة. لم نتحقق في هذه الجولة من نتائج الترقية على الشبكة بأكملها، لذا لن نتعامل مع الموعد المخطط له كما لو كان إيصالًا بالتنفيذ.
بالنسبة إلى المستخدم العادي، السؤال الأكثر تحديدًا هو: هل أُعد مفتاح وصول من هذا النوع فعلًا لحسابه؟ وهل تستطيع المحفظة التي يستخدمها إنشاءه وحفظه وتوقيعه على النحو الصحيح؟ وهل يدعم التطبيق الإجراءات اللازمة؟ لا يكفي الاطلاع على عنوان الخبر للحكم بأن الحساب الذي بحوزته محمي بالفعل بنظام التوقيع الجديد. وبعد إضافة مفتاح جديد، ينبغي التحقق من صلاحيات المفاتيح القديمة وفق إعدادات الحساب الفعلية.
أما المطورون، فعليهم التمييز بين معاملات الحسابات الأصلية والتحقق من رسائل العقود. يتعلق المسار الأول بمن يملك صلاحية تفويض عمليات الحساب، بينما يتعلق الثاني بكيفية تحديد البرنامج لصحة رسالة ما. وحتى اجتياز التحقق من التوقيع لا يعني أن محتوى الرسالة أو نطاق الصلاحيات أو منطق العمل صحيح بطبيعته. يجب أن تتحدد حدود الأمان في مسار التفويض الفعلي.
ما أترقبه هو نقاط التحقق التالية: سجلات الإصدار الرسمي وتفعيل البروتوكول، ومدى دعم المحافظ، والتعليمات الواضحة بشأن الانتقال. ما يمكن تأكيده حاليًا هو أن NEAR تعمل على تطوير قدرات مختلفة على مستوى توقيع الحسابات والتحقق من توقيعات العقود؛ أما ما لا يمكن تأكيده فهو أن جميع الحسابات القديمة والتطبيقات والتبعيات الخارجية قد أتمت الانتقال معًا. هذا تقييم لنطاق تقني، وليس استنتاجًا لاتجاه سعر العملة من اسم الخوارزمية.