Квантовый план 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 и адаптации аппаратных кошельков. Реализация тестовой сети и инструменты генерации ключей не подтверждают, что потребительские кошельки или хранители уже могут выполнять каждую операцию миграции и восстановления.

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

Если обе предложенные квантовые схемы были бы отключены и ни один действительный набор подписей не мог бы соответствовать владельцу или соответствующему активному порогу, описанные правила не предоставили бы немедленного обычного пути для расходования или ротации ключей. Это не устанавливает постоянную утрату. Реактивация управления или последующее изменение протокола стали бы другим маршрутом восстановления; более быстрый аварийный канал и идеи нулевого знания остаются вне текущего объема этого предложения.

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

Этот контент предоставляется исключительно в общих информационных целях и не является финансовым, инвестиционным, юридическим или налоговым советом. Любые мероприятия, вознаграждения, онлайн-акции или связанная с ними информация, упомянутые в настоящем документе, не должны рассматриваться как рекомендация, приглашение к покупке, продаже, торговле или иной сделке с какими-либо криптоактивами. Криптоактивы очень волатильны и могут привести к убыткам. Доступность услуг, продуктов WEEX и связанных с ними событий может варьироваться в зависимости от региона. Вы несете ответственность за обеспечение того, чтобы ваше участие соответствовало применимым местным законам и нормативным актам.