خطة TRON الكمومية قد تترك بعض المحافظ قادرة على الدفع لكن عاجزة عن استبدال مفاتيحها

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

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

ما هو هدف جاستن صن من التوقيع الكمي؟

في 8 أغسطس 2026، قال @justinsuntron إن هدفه أن تصبح ترون أول شبكة بلوكتشين مقاومة للحوسبة الكمومية، وأشار إلى اختبارات على شبكة نايل التجريبية. هذا التصريح يوضح الخلفية لتصميم ترحيل يمكن للحوكمة فيه إلغاء الموافقة على نظام توقيع لاحقًا.

حتى 12 سبتمبر، لا يزال مقترح TIP-899 مصنفًا كمسودة. تضمن إصدار برنامج نايل في 30 يونيو تطبيقات لنظامي FN-DSA-512 المبني على فالكون وML-DSA-44، وكل نظام له إعداد تفعيل خاص به. ولا يزال كل تطبيق يحتاج إلى موافقة حوكمة قبل أن تقبل الشبكة توقيعاته.

أظهر فحص نقطة بيانات نايل في 12 سبتمبر أن إعداد getAllowFnDsa512 كانت قيمته 1. أما إعداد ML-DSA فظهر بدون قيمة، ما يعني عدم وجود قراءة مؤكدة للتفعيل. ولم تحتوِ استجابة الشبكة الرئيسية على أي من الإعدادين. وكان المطورون قد قالوا في مكالمة 15 يوليو إن توقيت الشبكة الرئيسية لم يُحدد بعد.

كيف تؤثر الحوكمة على صلاحيات الحساب؟

يسمح TIP-899 للحوكمة بتفعيل أو تعطيل كل نظام مقترح على حدة. وتدير ترون شبكتها عبر 27 ممثلًا رئيسيًا منتخبًا يصوتون عبر مقترحات على السلسلة. ومفاتيح التفعيل المقترحة جزء من هذه العملية.

تمت أيضًا إعادة ترقيم إعدادات التفعيل. يستخدم TIP-899 وتطبيق نايل الرمزين 1000 و1001، بينما لا تزال مناقشة الترحيل السابقة تحتوي على 99 و100. وقد أوضحت مكالمة المطورين في 1 يوليو أن الأرقام الأكبر اختيرت لتجنب التعارض مع ترقيم الشبكة الرئيسية المستقبلي.

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

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

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

الفرق بين صلاحية المالك والصلاحيات النشطة

توثيق ترون للصلاحيات يفصل بين سلطة المالك والصلاحيات النشطة. صلاحية المالك يمكنها تفويض أي نوع من العقود وتغيير صلاحيات الحساب. أما الصلاحية النشطة فهي محدودة بالعمليات المسندة إليها، مثل التحويلات.

يجب توقيع تحديث الصلاحية تحت صلاحية المالك الحالية. وهذا يجعل إعداد المالك محوريًا للاستعادة: المفتاح القادر على إرسال دفعة ليس بالضرورة قادرًا على استبدال مفاتيح الحساب.

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

الاحتفاظ بمفتاح لنظام ECDSA الحالي في ترون إلى جانب فالكون لا يعيد الوصول دائمًا. فمع وزن ECDSA 1 ووزن فالكون 1 وحد 2، يلزم التوقيعان معًا. وبعد تعطيل فالكون، لا يستطيع وزن ECDSA المتبقي تحقيق الحد.

أمثلة توضيحية على القواعد المقترحة

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

• إذا كانت صلاحية المالك تعتمد على مفتاح فالكون فقط، فتعطيله يمنع تحديث الصلاحيات.
• إذا كانت صلاحية المالك تضم مفتاح ECDSA ومفتاح فالكون مع حد 2، فلن يكفي ECDSA وحده بعد تعطيل فالكون.
• إذا كانت صلاحية المالك تضم مفتاح ML-DSA يمكنه وحده تحقيق الحد، فيمكنه إصلاح الصلاحيات.
• إذا كانت صلاحية المالك تتطلب مفتاحي فالكون وML-DSA معًا، فإن تعطيل أحدهما يعطل مسار الإصلاح.

هذه النتائج تتعلق بسلطة التوقيع؛ ولا تزال متطلبات المعاملة الأخرى سارية. والتمييز يعمل في الاتجاه المعاكس أيضًا. فصلاحية مالك باقية بنظام ML-DSA يمكنها تفويض المعاملات مباشرة واستبدال صلاحية نشطة معطلة بنظام فالكون.

المفتاح الكمي الثاني يساعد فقط إذا كان قادرًا على العمل

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

ولا يحافظ مسار الاستعادة الكلاسيكي على نفس هدف الأمان. فمقترح الترحيل يقول بوضوح إن إضافة مفتاح مقاوم للكم لا توفر حماية كمومية إذا كان بإمكان مجموعة توقيع ECDSA فقط تحقيق الحد. كما أن مسار مالك يعتمد على ECDSA فقط يمكنه استبدال صلاحية نشطة محمية كموميًا.

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

كما أن إعداد “أي من النظامين” له حد: فهو يحافظ على بديل بعد تعطيل نظام، لكنه لا يحمي من نظام مخترق ما دام مفعلًا ومصرحًا به بشكل مستقل. فالتوفر بعد التعطيل ومقاومة مفتاح مخترق لا يزال مقبولًا خاصيتان منفصلتان.

وضع ML-DSA القياسي يساعد في تفسير موقعه في التصميم. فقد أنهت NIST معيار FIPS 204 الذي يحدد ML-DSA في 13 أغسطس 2024. ولا تزال NIST تصف توحيد Falcon بأنه قيد التنفيذ. ويقدم TIP-899 نظام ML-DSA كبديل منفذ لمخاطر توحيد وتدقيق فالكون.

ما العمل المتبقي قبل التفعيل؟

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

كما يحدد المقترح ونقاش المطورين في 15 يوليو أعمال تكييف للمحافظ ومخازن المفاتيح وأدوات SDK ومحافظ الأجهزة. ولا يثبت تنفيذ الشبكة التجريبية وأدوات توليد المفاتيح أن محافظ المستهلكين أو الجهات الحاضنة يمكنها بالفعل تنفيذ كل عمليات الترحيل والاستعادة.

قد تكون USDC آمنة كموميًا فقط بقدر أبطأ محفظة أو جسر أو بلوكتشين لديها.

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

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

بالنسبة للمحافظ والجهات الحاضنة، فإن استمرارية المدفوعات وحدها ستترك سؤال الاستعادة المركزي دون إجابة. يحتاج إعداد الترحيل إلى مسار باقٍ مصرح به من المالك لاستبدال المفاتيح، بالإضافة إلى طريقة لتحريك الأموال، مع الحفاظ على هدف المقاومة الكمومية في المسارين.

الأسئلة الشائعة

ما المشكلة التي قد يسببها تصميم ترون الكمي؟

قد تمنع بعض الحسابات المنقولة من استبدال مفاتيحها إذا عطلت الحوكمة نظام التوقيع الذي تعتمد عليه، خاصة إذا كانت صلاحية المالك تعتمد على مفتاح واحد أو تتطلب نظامين معًا.

هل يمكن للحساب المتأثر أن يرسل المدفوعات؟

أحيانًا نعم. إذا كانت هناك صلاحية نشطة منفصلة وقادرة على تحقيق حدها، فقد تظل المدفوعات ممكنة. لكن القدرة على إصلاح المفاتيح تحتاج صلاحية مالك صالحة.

ما الذي يجب أن تفعله المحافظ والجهات الحاضنة؟

يجب أن تتأكد من وجود مسار باقٍ مصرح به من المالك لاستبدال المفاتيح، وليس فقط مسار لتحريك الأموال، مع الحفاظ على الحماية الكمومية في كلتا الحالتين.