Квантовий план TRON може залишити деякі гаманці спроможними платити, але нездатними замінити свої ключі

Квантовий підпис TRON може залишити деякі мігруючі акаунти нездатними замінити свої ключі після того, як управління мережею відключить схему підпису, від якої вони залежать. Деякі з цих акаунтів все ще можуть здійснювати платежі через окремий дозвіл.

Дизайн включає можливий шлях відновлення через другу схему підпису, стійку до квантових атак. Щоб її використовувати, власники повинні мати залишкові ключі, які відповідають порогу існуючого власника акаунта, рівню повноважень, необхідному для зміни дозволів. Резервний ключ, уповноважений лише для платежів, залишить цю можливість ремонту недоступною.

Це практичне питання за ініціативою Джастіна Суна щодо квантових технологій. 8 серпня 2026 року @justinsuntron заявив, що його мета полягає в тому, щоб TRON став першою квантово-стійкою блокчейн-мережею та послався на тестування в тестовій мережі Nile. Це застаріле висловлення амбіцій створює фон для дизайну міграції, управлінські перемикачі якого можуть пізніше відкликати схвалення для схеми підпису.

Станом на 12 вересня TIP-899 залишається позначеним як чернетка. Випуск програмного забезпечення Nile 30 червня включав реалізації на основі Falcon FN-DSA-512 та ML-DSA-44, кожна з яких підлягає своїм власним налаштуванням активації. Кожна реалізація все ще потребує власного схвалення управління, перш ніж мережа прийме її підписи.

Перевірка параметрів Nile 12 вересня повернула getAllowFnDsa512 зі значенням 1. Налаштування ML-DSA з'явилося без значення, не надаючи позитивного показника активації. Відповідь основної мережі не містила жодного з налаштувань. Розробники заявили під час свого дзвінка 15 липня, що терміни основної мережі не визначені; поточні перевірки не встановлюють активацію основної мережі.

Перемикач мережі відповідає порогу акаунта

TIP-899 дозволяє управлінню активувати або деактивувати кожну запропоновану схему окремо. 27 обраних суперпредставників TRON управляють через пропозиції в ланцюгу. Запропоновані перемикачі належать до цього процесу.

Налаштування активації також були перенумеровані. TIP-899 та реалізація Nile використовують коди 1000 та 1001, тоді як попередня дискусія про міграцію все ще містить 99 та 100. Дзвінок розробників 1 липня пояснює, що більші числа були обрані, щоб уникнути конфліктів з майбутнім нумеруванням основної мережі. Ці числа ідентифікують запропоновані налаштування; активація вимагає окремого рішення управління.

На рівні акаунта питання полягає в тому, які підписи залишаються прийнятними. TRON присвоює ключам ваги та вимагає, щоб дійсні підписувачі вибраного дозволу відповідали або перевищували його поріг. Запропонований шлях квантового підпису використовує те ж саме обчислення дозволу.

Є важлива деталь у перевірнику транзакцій: підпис від деактивованої схеми викликає відмову. Отже, робоча резервна транзакція повинна використовувати прийняті підписи та пропустити підпис деактивованої схеми, навіть якщо залишкові ключі мають достатню вагу.

Вимкнення схеми може, отже, усунути маршрут підпису без зміни налаштованого порогу акаунта. Нічого в цьому перемикачі автоматично не надає іншому ключу відсутні повноваження.

Документація TRON щодо дозволів розділяє повноваження власника та активні дозволи. Дозвіл власника може уповноважити будь-який тип контракту та змінити дозволи акаунта. Активний дозвіл обмежений операціями, які йому призначені, такими як перекази.

Оновлення дозволу повинно бути підписане під існуючим дозволом власника. Це робить конфігурацію власника центральною для відновлення: ключ, здатний надіслати платіж, не обов'язково має повноваження замінити ключі акаунта.

Розгляньте дозвіл власника, що містить лише ключ Falcon з вагою 1 та порогом 1. Коли Falcon вимкнено, цей дозвіл власника не може авторизувати передачу або оновлення дозволу. Окремо налаштований активний дозвіл все ще може дозволяти транзакції, тому це не обов'язково робить весь рахунок нездатним до витрат.

Зберігання ключа для існуючого методу підписання ECDSA TRON разом із Falcon не завжди відновлює доступ. При вазі ECDSA 1, вазі Falcon 1 та порозі 2, потрібні обидва підписи. Після вимкнення Falcon залишкова вага ECDSA не може досягти порогу.

Наступні приклади застосовують запропоновані правила до гіпотетичних конфігурацій. Вони показують висновки з документованих правил дозволу та перевірки; жоден спостережуваний блокування або виконане тестування відкату не лежить в основі цих прикладів. Припустимо, що Falcon було вимкнено, будь-які ключі ML-DSA були налаштовані заздалегідь, ML-DSA залишається активним і безпечним, і власник все ще може використовувати ці ключі.

Ці результати стосуються авторитету підпису; інші вимоги до транзакцій все ще застосовуються. Розрізнення працює в іншому напрямку також. Залишковий дозвіл власника ML-DSA може авторизувати транзакції безпосередньо та замінити вимкнений активний дозвіл Falcon.

Другий квантовий ключ допомагає лише якщо він може діяти

Приклад власника з двома схемами зберігає квантово-стійкий шлях до ремонту дозволу, якщо будь-який ключ може незалежно досягти порогу власника. Вимога обох ключів створює залежність від того, щоб обидві схеми залишалися доступними. Поріг визначає, які з цих властивостей має рахунок.

Класичний шлях відновлення також не зберігає ту ж мету безпеки. Пропозиція міграції чітко говорить, що додавання квантово-стійкого ключа не забезпечує жодного квантового захисту, якщо набір підписів лише ECDSA все ще може досягти порогу. Шлях власника лише ECDSA також може замінити активний дозвіл, захищений квантами.

Відповідна конфігурація, отже, є ширшою, ніж ключ, що використовується для рутинних платежів. Влада власника та кожен активний шлях, здатний переміщувати захищені активи, повинні розглядатися разом.

Конфігурація з будь-якою схемою також має обмеження: вона зберігає альтернативу після вимкнення схеми, але не захищає від скомпрометованої схеми, поки ця схема залишається активною та незалежно авторизованою. Доступність після вимкнення та стійкість до все ще прийнятого скомпрометованого ключа є окремими властивостями.

Статус стандартів ML-DSA допомагає пояснити його місце в дизайні. NIST завершив FIPS 204, який специфікує ML-DSA, 13 серпня 2024 року. NIST все ще описує стандартизацію Falcon як таку, що триває. TIP-899 представляє ML-DSA як реалізовану альтернативу стандартизації Falcon та ризику аудиту. Це забезпечує альтернативний алгоритм, а не автоматичне відновлення дозволу.

Залишкова робота виходить за межі додавання кнопки підпису. TIP-899 вимагає зовнішнього криптографічного та реалізаційного аудиту, публічних матеріалів аудиту та покриття за програмою винагороди за помилки перед активацією основної мережі. Переглянуті матеріали пропозиції не надають завершеного незалежного звіту про аудит.

Пропозиція та обговорення розробників 15 липня також визначають роботу з похідними гаманцями, сховищами, SDK та адаптацією апаратних гаманців. Реалізація тестової мережі та інструменти генерації ключів не встановлюють, що споживчі гаманці або кастодіани вже можуть виконувати всі операції міграції та відновлення.

Корисна демонстрація тестової мережі слідувала б за дозволами через невдачу: вимкнути схему, створити транзакцію, використовуючи лише залишкові підписи, показати, які перекази залишаються авторизованими, і показати, чи може існуючий власник замінити постраждалі ключі. Результат повинен відповідати конфігурації, яку фактично мають користувачі.

Якщо обидві запропоновані квантові схеми були б вимкнені і жоден дійсний набір підписів не міг би відповідати власнику або відповідному активному порогу, описані правила не забезпечили б жодного звичайного шляху для витрат або ротації ключів. Це не встановлює постійну втрату. Реактивація управління або пізніша зміна протоколу були б іншим шляхом відновлення; швидший канал надзвичайних ситуацій та ідеї відновлення з нульовими знаннями залишаються поза межами поточного обсягу цієї пропозиції.

Для гаманців і кастодіанів безперервність платежів сама по собі залишила б центральне питання відновлення без відповіді. Конфігурація міграції потребує шляху, авторизованого вижившим власником, для заміни ключів, а також способу переміщення коштів, при цьому обидва шляхи зберігають його ціль стійкості до квантових загроз.