Проект TRON по внедрению квантово-устойчивых подписей может привести к тому, что некоторые перенесенные учетные записи не смогут заменить свои ключи после того, как сетевое управление отключит схему подписи, от которой они зависят. Некоторые из этих учетных записей по-прежнему смогут совершать платежи через отдельное разрешение.
Дизайн включает возможный путь восстановления через вторую квантово-устойчивую схему подписи. Чтобы использовать ее, владельцам потребуется, чтобы оставшиеся ключи соответствовали существующему порогу учетной записи — уровню полномочий, необходимому для изменения разрешений. Резервный ключ, авторизованный только для платежей, оставит эту восстановительную силу недоступной.
Это практический вопрос, стоящий за квантовым продвижением Джастина Сана. 8 августа 2026 года @justinsuntron заявил, что его целью является сделать TRON первой квантово-устойчивой блокчейн-сетью, и упомянул тестирование в тестовой сети Nile. Это заявление о намерениях служит фоном для дизайна миграции, управление которой впоследствии может отозвать одобрение схемы подписи.
По состоянию на 12 сентября TIP-899 остается в статусе Draft. Релиз программного обеспечения Nile от 30 июня включал реализации FN-DSA-512 и ML-DSA-44 на основе Falcon, каждая из которых подлежит собственной настройке активации. Каждая реализация по-прежнему нуждается в собственном одобрении управления, прежде чем сеть примет ее подписи.
Проверка 12 сентября конечной точки параметров Nile вернула 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 остается включенным и безопасным, и владелец все еще может использовать эти ключи.
| Существующая конфигурация разрешения | Расходы после отключения Falcon | Изменение разрешений |
|---|---|---|
| Только владелец Falcon: вес 1, порог 1 | Владелец не может авторизовать; отдельное активное разрешение может по-прежнему работать | Недоступно через этого владельца |
| Владелец: ECDSA вес 1 плюс Falcon вес 1, порог 2 | Владелец не может достичь порога; необходимо оценить отдельные активные разрешения | Недоступно через этого владельца |
| Владелец: Falcon вес 1 плюс ML-DSA вес 1, порог 1; нет ключей ECDSA | Подпись владельца ML-DSA может авторизовать | Подпись владельца ML-DSA может авторизовать |
| Владелец: Falcon вес 1 плюс ML-DSA вес 1, порог 2 | Владелец не может достичь порога; необходимо оценить отдельные активные разрешения | Недоступно через этого владельца |
| Только владелец Falcon плюс действующее активное разрешение 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 и аппаратных кошельков. Реализация тестовой сети и инструменты генерации ключей не подтверждают, что потребительские кошельки или хранители уже могут выполнять все операции миграции и восстановления.
Полезная демонстрация в тестовой сети должна проследить разрешения через сбой: отключить схему, создать транзакцию, используя только оставшиеся подписи, показать, какие переводы остаются авторизованными, и показать, может ли существующий владелец заменить затронутые ключи. Результат должен соответствовать конфигурации, которую пользователи фактически имеют.
Если бы обе предлагаемые квантовые схемы были отключены, и ни один действительный набор подписей не мог бы соответствовать порогу владельца или соответствующему активному порогу, описанные правила не предоставляли бы немедленного обычного пути для расходов или ротации ключей. Это не означает постоянную потерю. Повторная активация управления или последующее изменение протокола были бы другим путем восстановления; более быстрый экстренный канал и идеи восстановления с нулевым разглашением остаются за пределами текущей сферы действия этого предложения.
Для кошельков и хранителей только непрерывность платежей оставила бы центральный вопрос восстановления без ответа. Конфигурация миграции требует наличия действующего пути, авторизованного владельцем, для замены ключей, а также способа перемещения средств, причем оба пути сохраняют свою цель квантовой устойчивости.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
