Авторы статьи: Mysten Labs, Kostas Chalkias и Mahdi Sedaghat

https://www.sui.io/blog/suis-post-quantum-signature-schemes

Краткий обзор

  • Sui выбрала ML-DSA-65 уровня NIST 3, а не более низкий уровень безопасности с более низкой стоимостью. Сегодня ИИ-помощь в криптоанализе уже может взломать некоторые решеточные криптографические схемы, которые годами проходили ручную проверку; при этом дополнительные затраты, связанные с выбором большего запаса безопасности, почти незаметны: производительность проверки ML-DSA-65 практически сопоставима с Ed25519.

  • Два решения из двух разных математических систем. Вариант SLH-DSA работает в Move, а не на уровне протокола; поэтому даже если произойдет прорыв в решеточной криптографии, это не повлияет на путь безопасности, основанный на хэшировании. Кроме того, Sui может адаптироваться к изменениям внешних стандартов без обновления протокола.

  • Существующие пользователи не пострадают. Приватный ключ по‑прежнему составляет 32 байта, так что способ бэкапа кошелька менять не нужно. В постквантовых аккаунтах используется режим добровольного выбора; псевдонимы адресов позволяют существующим аккаунтам, сохранив исходные адрес и активы, переключить ключ авторизации на постквантальный.

В недавно опубликованной статье (Sui готовится к квантовой эпохе) мы рассказали о направлении развития Sui в области постквантовой безопасности: нативная аутентификация аккаунта с помощью ML-DSA-65, защита высокоценных хранилищ с помощью SLH-DSA-SHA2-128s, а также наличие пути миграции, который позволяет сохранить существующие адреса и мнемоническую фразу для восстановления.

А в этой статье мы поговорим о стоящем за этим «почему» и подробно объясним эти выборы с точки зрения криптографов. Почему выбрали ML-DSA-65, а не более дешёвый уровень безопасности? Почему, несмотря на то что подписи Falcon меньше, мы всё же не выбрали его? Почему SLH-DSA помещён в смарт-контракт, а не на уровень протокола? Почему мы не использовали напрямую существующие библиотеки, а написали собственную Rust‑обёртку? И в процессе — что мы ещё обнаружили? Если после прочтения предыдущей статьи вы хотите понять техническую логику, стоящую за этими решениями, то эта статья — ответ.

Настоящая сложность этих решений на самом деле не в выборе алгоритма. NIST уже несколько лет назад в основном решил эту задачу. Для подписи фактически существует всего два кандидата: ML-DSA (FIPS 204) и SLH-DSA (FIPS 205). Большая работа нужна после этого — целый ряд вопросов: какой уровень безопасности выбрать, какую реализацию использовать, как проверять код, как обращаться с уже существующими ключами, и какие технически привлекательные «обходные пути» в итоге не стоит применять.

Сначала представим нашу предысторию. Наши исследования в области постквантовых систем начались задолго до Sui: в 2017 году в Corda R3 был представлен промышленного уровня безсостояний постквантовый протокол — первый в распределённых бухгалтерских книгах безсостояний и допускающий многократное использование постквантовых подписей; затем в последующие годы вместе с Mike Hearn мы исследовали структуры постквантовой криптографии, применимые к блокчейну; в Meta мы построили Winterfell — первый в мире open-source STARK‑прозводитель; а также исследования по PQ-EdDSA, HashWires и Truncator.

Что касается конкретной стратегии миграции для Sui, мы начали планировать это ещё в публикации (Как обеспечить безопасность Sui в эпоху квантовых вычислений) от апреля 2025 года — рассматривая подписи, хеши, шифрование и доказательства с нулевым разглашением. Ниже описана часть про подписи; к настоящему моменту соответствующие решения уже окончательно определены.

Точное определение угроз

Алгоритм Шора может непосредственно взломать RSA и криптографию на эллиптических кривых. Алгоритм Гровера даёт ускорение лишь квадратичного уровня для хеш-функций, а увеличение длины вывода хеш‑функции компенсирует этот эффект. Поэтому для блокчейна квантовый риск почти полностью сосредоточен на подписях, а не на хешах.

Особенность блокчейна не в алгоритмах как таковых, а в том, как и когда раскрывается публичный ключ. В большинстве систем публичный ключ находится за некоторой границей доступа, и атакующему нужно сначала взломать систему — отсчёт риска в реальности начинается только после этого. Но в ончейне публичный ключ становится навсегда открытым уже тогда, когда аккаунт выполняет первую транзакцию. Похожим на «собрать сейчас, расшифровать потом» образом атаки на подписи даже не требуют иметь квантовое «железо» прямо сейчас: достаточно хранить данные и терпение. Собираем открытый ключ сегодня и фальсифицируем подпись, когда в будущем квантовые вычисления станут достаточно мощными. Это окно сбора открыто уже несколько лет, а прогнозы относительно развития квантовых вычислений всё время двигались в одном направлении: оценки для необходимого ресурса, чтобы разложить 2048‑битный RSA‑ключ, падали — с примерно 20 миллионов квантовых битов в 2019 году до менее чем 1 миллиона в 2025 году. Каждая корректировка означает, что требуемые машины становятся меньше и дешевле, а не дороже.

Это также переопределяет сроки миграции. В административном указе № 14412, опубликованном США в июне 2026 года, требуется, чтобы федеральные агентства завершили миграцию по установлению ключей, устойчивых к квантовым атакам, до декабря 2030 года, а миграцию цифровых подписей — до декабря 2031 года; это раньше, чем график миграции NIST, который пока остаётся в стадии проекта, и рассчитан на 2035 год. А для ключей в блокчейне фактические сроки ещё более ранние, потому что риски накапливаются во времени: ключ, опубликованный в первый день, уже с первого дня находится в экспонированном состоянии — а не начинает подвергаться риску лишь с наступлением дедлайна.

Почему выбрали ML-DSA-65, а не ML-DSA-44

NIST разделяет постквантовые схемы на пять уровней безопасности. Каждый уровень соответствует не абстрактной величине «количества битов безопасности», а конкретному базису для грубой переборной атаки:

  • Уровень 1: сложность взлома как минимум сопоставима с восстановлением ключа AES-128

  • Уровень 3: соответствует AES-192

  • Уровень 5: соответствует AES-256

Чётные уровни определяются коллизиями хеша: уровень 2 соответствует SHA-256, уровень 4 — SHA-384.

ML-DSA предоставляет три набора параметров:

ML-DSA-44：Уровень 2

ML-DSA-65：Уровень 3

ML-DSA-87：Уровень 5

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

Окончательный выбор в Sui: для сборки ML-DSA-65 уровня 3 использовать как нативную схему подписи протокола, а не более дешёвую ML-DSA-44.

Одна из важных причин — то, что Anthropic недавно обнаружил атаку на схему подписи HAWK. HAWK — решётчатая криптографическая схема, глубоко изученная, принимавшая множество раундов криптоаналитической проверки. Важно подчеркнуть, что HAWK и ML-DSA основаны на разных решётчатых задачах, поэтому атака, нацеленная на HAWK, не может напрямую применяться к ML-DSA. Но ключевое здесь другое: этот случай показывает, что ИИ‑помощник в криптоанализе уже начинает обнаруживать проблемы, которые не были выявлены людьми годами тщательной проверки.

Это меняет то, как мы должны оценивать, сколько запаса по безопасности оставлять в предположениях для решётчатой криптографии. Уровень 1 оставляет сравнительно небольшой запас при изменении оценок безопасности, а Уровень 3 даёт больший буфер; и фактически оказалось, что стоимость этого дополнительного запаса безопасности очень невысока.

Есть ещё две второстепенные причины. Во‑первых, Chrome и Cloudflare в уже защищающем большой объём веб‑трафика постквантовом обмене ключами выбрали Уровень 3, поэтому у этого уровня уже больше практического опыта внедрения. Во‑вторых, когда мы обсуждали механизмы установления ключей с регулируемым финансовым сектором, Уровень 3 также лучше соответствовал их ожиданиям по безопасности.

Поддержка на аппаратуре — ещё один важный фактор, который мы учитывали. Мы напрямую проверили совместимость FIPS 204 с помощью SDK производителей HSM и аппаратных кошельков. Мы также тестировали ML-DSA на устройствах уровня DePIN с сверхнизким энергопотреблением — это типичная среда ограниченных CPU и RAM для NFC‑постквантовых кошельков, то есть именно тот сценарий, где слишком «тяжёлые» алгоритмы первыми начинают проявлять проблемы.

Вся экосистема тоже движется к подобному выбору. Ledger недавно добавил в свой SDK предварительную поддержку официального ML-DSA (FIPS 204) и обеспечивает побитовую совместимость со стандартом NIST. Мы также проверили, что между Ledger и нашей реализацией возможна двусторонняя интероперабельность подписи.

Параллельно мы продолжаем следить за прогрессом в криптоанализе против ML-DSA. Эта постоянно сохраняющаяся неопределённость — одна из причин, почему мы в первую очередь вывели SLH-DSA как решение для смарт-контрактов и рекомендуем его для высокоценных хранилищ: его безопасность опирается на хеш-функцию, а не на решётчатую криптографию. Поэтому даже если в будущем появятся прорывы в решётчатой криптографии, влияющие на оценки безопасности ML-DSA, это не затронет SLH-DSA.

Почему не выбрали Falcon?

Ещё один кандидат от «решётки» — это Falcon (FN-DSA, будущий FIPS 206). Его главное преимущество — подписи меньшего размера. Подпись FN-DSA-512 на Уровне 1 имеет размер всего 666 байт, а подпись ML-DSA-65 на Уровне 3 — 3 309 байт.

Тем не менее мы не выбрали Falcon, причины включают:

  • Нет уровня 3. Falcon предлагает только Уровень 1 и Уровень 5 (FN-DSA-512 и FN-DSA-1024): либо выбираем наш только что упомянутый Уровень 1 с небольшим запасом, либо, чтобы получить больший запас безопасности, платим стоимость Уровня 5 — но он примерно удваивает показатели.

  • Стандартизация ещё не завершена. FIPS 206 пока не утверждён окончательно; в отличие от этого, FIPS 204 с 2024 года уже официально утверждён.

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

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

  • Более высокая сложность безопасной реализации. При использовании механизма гауссовой выборки нужно обеспечивать выполнение с постоянным временем, устойчивость к атакам сбоев и к атакам через кэш, а также качество случайных чисел — это требует более строгих требований к реализации.

  • Защита от побочных каналов сложнее. Поскольку в Falcon задействованы гауссовая выборка и FFT, считается, что Falcon сложнее сделать безопасным и надёжным, чем ML-DSA, в плане защиты от временных атак, атак через кэш и атак с воздействием на сбои.

  • Скорость верификации. На более высоких уровнях безопасности верификация у Falcon медленнее, чем наши результаты тестов ML-DSA. Конкретно: на одной и той же машине время верификации FN-DSA-1024 составляет 49,8 микросекунды, а ML-DSA-65 — только 23,2 микросекунды. То есть при наличии достаточного запаса безопасности верификация набора параметров Falcon примерно в 2 раза медленнее выбранной нами схемы.

  • Экосистема железа. Многие производители HSM, смарт‑карт, TPM и элементов безопасности в первую очередь поддерживают ML-DSA: он раньше завершил стандартизацию, его проще реализовать, и это также один из вариантов, который особенно часто требуется поддерживать корпоративным клиентам. По отзывам, которые мы получили, аппаратная поддержка Falcon улучшается, но по степени распространённости она всё ещё уступает ML-DSA.

  • Не менее важно и то, что есть зрелая экосистема и инструменты. На данный момент ML-DSA более зрелён в плане криптографических библиотек, SDK, тест-векторов, compliance-наборов и сертифицированных реализаций. Это снижает инженерный риск реализации, особенно когда ML-DSA выступает в роли нативной функции протокола.

Поэтому меньший размер подписи не компенсирует эти недостатки.

Почему SLH-DSA работает в Move, а не на уровне протокола

Для высокоценных активов мы предоставляем хеш‑основанный SLH-DSA-SHA2-128s (FIPS 205) через Move smart contract-контейнеры, а не как нативную схему подписи протокола. Это не потому, что мы не доверяем SLH-DSA. Как раз наоборот: хеш-основанная криптография — это класс, который понятнее в обоих подходах, и SHA-256 уже широко применяется. Некоторые команды аппаратных кошельков, с которыми мы консультировались, даже больше склонялись к хеш-основанным схемам, потому что инженерам их глубже понимать.

Почему мы разместили это в контракте? Главным образом по трём причинам:

  • Характеристика по стоимости. Стоимость валидации SLH-DSA заметно выше, чем у Ed25519, а размер подписи больше; из‑за этого кэширование не позволяет эффективно снижать накладные расходы. Для ML-DSA часть данных — публичный ключ — можно повторно использовать, поэтому кэширование даёт заметную выгоду; для SLH-DSA аналогичной оптимизации нет.

  • Риск изменений стандарта. Bitcoin, Ethereum и следующая итерация стандартов NIST с высокой вероятностью в итоге сойдутся к меньшему набору схем подписи, чем сейчас. Какой бы вариант не выбрали сообщества Bitcoin и Ethereum — включая все обсуждаемые на данный момент хешированные схемы — мы хотим быстро реализовать совместимость. Мост Sui ↔ Ethereum и Hashi для Bitcoin делают этот запрос особенно практичным: если реализовывать в смарт-контрактах, то в Sui можно поддерживать совместимый постквантовый Bitcoin‑кошелёк без выпуска новой основной версии Sui; если же использовать нативную схему, то при каждом изменении внешнего целевого стандарта может понадобиться обновление протокола.

  • Область реализации. При реализации SLH-DSA в Move основная работа связана с операциями, относящимися к деревьям Меркла; по сравнению с добавлением нативного аутентификатора область реализации меньше, а код проще и понятнее. Кроме того, его можно включить без ветвления или обновления протокола: необходимые для работы с байтами и хеш‑примитивы уже присутствуют в языке Move.

Эти две схемы опираются на разные математические системы — и именно в этом заключается ключ к дизайну. Если разрушится предположение безопасности решётчатой криптографии, это не повлияет на хеш‑основанный путь безопасности — и наоборот.

Для аккаунтов с максимальной ценностью существующий механизм 2-of-2 мультиподписей в Sui всё ещё позволяет пользователям одновременно требовать традиционную подпись и постквантовую подпись для авторизации транзакции. Поэтому ни одна схема не станет единственной точкой отказа в системе безопасности. Это также соответствует идее гибридной безопасности, которую недавно отстаивали в обсуждениях, инициированных Bernstein.

Обе эти схемы следуют алгоритмам постквантовой криптографии, стандартизованным NIST (ML-KEM, ML-DSA, SLH-DSA), а также «дорожной карте» по постквантовой готовности, совместно разработанной CISA, NSA и NIST.

Тест производительности

Ни один из перечисленных выборов в итоге не обходится без стоимости. Мы проводили тесты на Apple M2 Max с помощью fastcrypto.

Здесь по-настоящему важно две вещи.

Производительность верификации почти совпадает с Ed25519 и на самом деле чуть лучше, поэтому CPU‑стоимость, необходимая веридактору для обработки каждого подписи, не увеличивается. Это очень важно, потому что Sui — один из самых быстрых L1 в мире, и даже после постквантовой миграции мы должны продолжать удерживать это лидерство. По-настоящему важный показатель — стоимость верификации: вычислительные расходы в разных частях процесса происходят в разных местах. Генерация ключей и подписи выполняются офлайн для каждой транзакции на устройстве подписанта; верификация же требует, чтобы каждый валидатор выполнял проверку для каждой транзакции. Если смотреть на абсолютные числа, скорость подписи действительно ниже, но на клиентском устройстве это занимает лишь около 66 микросекунд, а даже в браузере это всё равно миллисекунды — пользователи практически не почувствуют разницу.

Приватный ключ по-прежнему остаётся 32 байта, потому что по сути это семя. Кошелёк может продолжать делать бэкап и восстановление полностью тем же способом, а новые ключи будут генерироваться через новый стандартный путь вывода из той же самой мнемонической фразы пользователя.

Реальная цена, которую придётся заплатить — объём данных: связанные с каждой транзакцией данные увеличатся примерно в 50 раз. Это стоимость, которую вынуждено платить всё индустрия ради обретения постквантовых возможностей, и именно на ней сейчас сосредоточены наши оптимизации. Однако для Sui есть два фактора, которые смягчают эту проблему. Во‑первых, верхний предел размера транзакции в Sui может доходить до 128 КБ, поэтому пространства больше — в сравнении с блокчейнами, где ограничения по размеру транзакции более жёсткие. Во‑вторых, мы уже внедрили и фактически запускали схемы с крупными подписями, включая мультиподписи и zkLogin. Кроме того, блоки программируемых транзакций (PTB) позволяют одной подписи авторизовать несколько действий, поэтому средние дополнительные накладные расходы на одно действие на практике оказываются ниже, чем выводить только из размера одной подписи. В будущем ещё можно использовать подобный текущему механизму кэша публичного ключа в zkLogin: пользователь один раз отправляет свой публичный ключ, а затем в следующих транзакциях достаточно отправлять подпись. Однако эта функция не будет включена в самой первой версии. Мы хотим, чтобы первая реализация оставалась относительно консервативной, и затем — после тщательного продумывания — поэтапно включить эту оптимизацию.

Также нужно уточнить: приведённые выше данные — это лишь одна тестовая конфигурация. Для более полного и строгого отчёта по производительности нужно охватить Rust‑исполнение на стороне валидатора, конфигурацию для обычных разработчиков и подписи в браузере через TypeScript‑стек. Мы планируем позже опубликовать более полный набор тестовых данных. Более подробное сравнение кандидатов подписи в NIST см. в nist-sigs-zoo.

Кроме того, исследование Remora компании Sui по расширениям исполнения делает вопросы с расширением пропускной способности в процессе постквантовой миграции проще для решения. Эти два направления исследований изначально продвигались совместно.

Как реализовали и почему мы сделали сами

Почти в любом языке программирования есть крупные криптографические библиотеки, и во многих из них уже есть ML-DSA, поэтому завести готовую библиотеку кажется самым очевидным решением. Но мы сделали иначе: разработали mysten-mldsa-native-rs — лёгкую Rust‑обёртку, написанную нами на основе mldsa-native. mldsa-native — это компактная, формально верифицированная реализация ML-DSA, поддерживаемая в рамках проекта pq-code-package под эгидой Linux Foundation. Она использует тот же базовый «сердечник», что и несколько ведущих криптографических библиотек отрасли, например aws-lc, но без остальных компонентов из составных больших библиотек.

Почему мы сделали именно так? Ключевой момент — эта часть кода находится на консенсусном пути выполнения. Каждая проверяющая нода должна запускать проверочный код для каждой транзакции, поэтому мы хотим максимально сузить область реализации, чтобы код был легче читать и аудировать, и при этом избежать предоставления опций, которые могут быть ошибочно сконфигурированы. Эта оболочка предоставляет только один режим: режим FIPS 204 по умолчанию, с hedged signing (подпись с «противовесом»), то есть при каждой подписи используется новая случайность, что повышает устойчивость к атакам отказа и к повторному использованию случайности. В самой оболочке нет генератора случайных чисел — поэтому каждую операцию можно воспроизводить в тестовой среде. Приватный ключ имеет только одну форму сериализации: 32‑байтовое семя, благодаря чему кошелёк может продолжать делать бэкапы и восстанавливать ключи всё тем же способом, полностью совместимым с текущим подходом.

Как упоминалось ранее, наша скорость реализации очень высокая. Это в первую очередь благодаря верифицированным ассемблерным реализациям, предоставленным апстримом для Apple/ARM и серверного x86‑железа. На этапе выполнения система автоматически выбирает соответствующую реализацию для конкретной машины, чтобы гарантировать корректную работу одного и того же бинарника в смешанной среде оборудования проверяющих нод. Независимо от того, какую базовую реализацию используют, сгенерированная в итоге подпись будет полностью идентичной. Отличие только в производительности: скорость работы ассемблерного бэкенда примерно в 2,5 раза выше, чем у портируемой C‑реализации.

Точка отказа, о которой редко кто говорит

Самое по-настоящему опасное в новой криптографии — зачастую не математика, а код и поспешность реализации.

В этом году был раскрыт недостаток корректности у одного из ведущих STARK‑прозводителей: некоторое значение, которому доверяет проверяющая нода, не привязано по‑настоящему к доказательному transcript. Поэтому злоумышленник может подделывать доказательства ошибочных утверждений, и проверяющая нода всё равно примет их. Этот баг существовал в открытом исходном коде с 2024 года, прошёл внешние аудиты и формальную верификацию — но так и не был найден. В итоге в июне 2026 года его обнаружили инструменты ИИ‑аудита; к счастью, до этого уязвимость не успели использовать.

У ML-DSA уже были подобные случаи. Только в 2026 году в трёх независимых кодовых базах для этой схемы подписи было раскрыто 4 уязвимости уровня реализации:

  • В процессе подписи libgcrypt присутствует ошибка записи за пределы буфера (CVE-2026-41990);

  • В crate RustCrypto ml-dsa при вычислении hint присутствует уязвимость по временным побочным каналам, которая может привести к утечке информации о ключе подписи (CVE-2026-22705);

  • В той же crate также есть уязвимость в верификации: она неверно принимает подпись, содержащую повторяющиеся индексы hint (CVE-2026-24850);

  • В постквантальном коде wolfSSL для встраиваемых устройств присутствует уязвимость, допускающая инъекцию сбоев (CVE-2026-3503).

При этом самое заслуживающее пристального внимания — это тот верификационный баг: по стандарту FIPS 204 корректная подпись имеет только один легальный формат кодирования. Если реализация ошибочно принимает второе кодирование, то вопрос «является ли подпись корректной» может зависеть от того, к какому именно узлу вы обращаетесь. В блокчейне это может прямо привести к разветвлению цепочки.

При этом в этот же период число успешных взломов базовой математики ML-DSA равно нулю.

Иными словами, на данный момент математическая основа по‑прежнему надёжна, а реальные риски лежат в первую очередь на уровне реализации кода.

Мы так часто упоминаем этот пример потому, что он даёт нам очень важный и разумный ориентир оценки риска для любой информации, которую мы выпускаем; результаты исследований HAWK указывают в том же направлении. Те механизмы проверки, которым мы долго доверяли — включая ручные аудиты, формальные методы и проверку кода, проходившую много лет публичного использования, — не выявили этих проблем, а вот анализ с помощью ИИ обнаружил их.

Это ещё раз показывает, что нам нужно:

  • Оставлять достаточно большой запас по безопасности при выборе параметров;

  • По возможности сохранять небольшой и легко аудируемый диапазон реализаций;

  • Сделать кросс-реализационную верификацию обязательным порогом в процессе построения;

  • Для компонентов, которые новые и имеют относительно меньшую зрелость, применять более осторожную, пошаговую стратегию выхода в прод.

Вот именно поэтому мы обсудим следующую часть дальше.

Мы пока не нажимаем эту кнопку

На самом деле у нас есть более желательный обходной путь, чем текущая выбранная схема, но пока мы его не выбираем.

Каждый ключ Ed25519 в Sui выводится из семени, защищённого с помощью хеширования. Даже если квантовый компьютер взломает систему эллиптических кривых, он сможет восстановить только скаляр подписи, но не сможет вывести исходное семя, из которого этот скаляр был получен. Наша исследовательская статья Post-Quantum Readiness in EdDSA Chains (Baldimtsi, Chalkias, Roy и Sedaghat, eprint 2025/1368) использует эту асимметрию, чтобы преобразовать её в квантово-устойчивое доказательство владения: пользователь может с помощью нулевого разглашения доказать, что у него есть исходное семя, и тем самым разрешить новый постквантовый ключ, сохранив при этом исходный адрес; при этом в ходе всего процесса не раскрывается никаких секретных данных.

У такого подхода есть несколько более удачных характеристик по сравнению с миграцией через новые пути вывода. Он подходит для аккаунтов, чьи публичные ключи уже раскрыты; его также можно применять ретроспективно к ключам, которые были выведены много лет назад; даже подходит для спящих аккаунтов, которые в будущем никогда больше не будут подписывать никакие транзакции. Это та категория аккаунтов, которую не покрывают другие схемы миграции, и для блокчейнов, которые не поддерживают детерминированный вывод семян, такая миграция вообще невозможна. Именно это — структурное преимущество EdDSA‑блокчейна перед ECDSA‑блокчейном — и именно поэтому данная статья специально исследует EdDSA.

Тогда, если эта схема настолько хороша, почему не включить её прямо сейчас? Потому что эта «кнопка» по сути является системой доказательства с нулевым разглашением. Если сейчас включить её в прод, это значит, что безопасность аккаунта будет зависеть от этой системы доказательств, а сама техника по сравнению с защищаемой ею схемой подписи является более молодой. С учётом рисков реализации, упомянутых в предыдущей части, именно поэтому мы выбираем осторожность.

Цена, которую придётся заплатить, на самом деле невелика, потому что эта «кнопка» не истекает. Семя не перестаёт быть секретным из‑за течения времени. Как только система доказательства с нулевым разглашением накопит достаточно безопасных проверок и доверия, мы всё ещё сможем построить и включить этот механизм. Параллельно мы сначала завершим миграцию более прямым способом: поддержим нативные постквантовые аккаунты через новый путь вывода и воспользуемся псевдонимами адресов, чтобы помочь существующим аккаунтам мигрировать.

Поэтому сейчас мы рассматриваем zkPQ-EdDSA как экстренный переключатель безопасности, который можно будет включить в будущем при необходимости, а не как функцию для первичного релиза. Есть ещё одна примечательная особенность дизайна: поскольку приватный ключ ML-DSA в Sui также является 32‑байтовым семенем, в будущем механизм «доказательства владения семенем» при необходимости можно будет применить и непосредственно к постквантовым аккаунтам.

Механизм миграции

В обоих обновлениях безопасности Sui предоставляет новый стандартный путь вывода и использует добровольный выбор на уровне аккаунта. Для существующих аккаунтов не требуется перевод средств. Размещённые псевдонимы адресов (Address Aliases) позволяют аккаунтам обновлять ключи авторизации на постквантовые ключи, при этом: адрес остаётся неизменным, а активы остаются на месте. Для текущих пользователей фактическую миграционную работу сейчас выполняет именно этот механизм, а не упомянутая ранее и пока отложенная схема с нулевым разглашением (zero-knowledge).

Для квантово-устойчивого хранилища снятие средств использует модель из двух транзакций; простые переводы могут потребовать только одной. Для разработчиков и организаций смысл очень чёткий: квантово-устойчивые аккаунты будут постепенно включаться как новый опциональный функционал — так же, как zkLogin и Passkeys. Это не будет принудительной миграцией, текущие функции не изменятся. Включение — это обычное обновление протокольной функциональности, а не изменение консенсусного механизма или существующего состояния.

Где сейчас находится индустрия

Мы не единственная команда, которая занимается этим, и мы не хотели бы быть единственными. Летом этого года Near уже выпустила ML-DSA-65 как опциональный тип ключа — с той же схемой и уровнем безопасности, что и в Sui. Это ценный независимый сигнал. Дорожная карта консенсуса в Ethereum больше склоняется к хешированным схемам. У Bitcoin сейчас есть несколько активных предложений, но окончательного решения ещё не принято.

Мы считаем, что настоящее лидерство Sui не в том, что выбран какой-то конкретный алгоритм, а в архитектурном дизайне:

  • Две схемы соответствуют двум моделям угроз;

  • Хранилище может адаптироваться к внешним стандартам без обновления протокола;

  • Пользователи смогут сохранить исходные адреса.

Текущий статус и таймлайн

Базовая реализация завершена и прошла тесты производительности. План сейчас такой:

  • Антиквантовое хранилище: в этом году — в mainnet;

  • Нативный аккаунт ML-DSA-65: до конца года — в testnet;

  • Нативная аутентификация аккаунта: самое позднее — в Q1 2027 года в mainnet.

Поддержка для кошельков, SDK и CLI будет выпущена одновременно.

Независимый внешний аудит сейчас проводится. Мы не можем гарантировать, что все аудиты будут завершены в точности по плану; поэтому вместо того чтобы включить в работу аутентификатор без достаточного аудита, мы предпочитаем перенести сроки. Поэтому в статье описано текущее направление, а финальные сроки могут быть скорректированы по результатам аудитов и отзывам testnet.

Всё, что требуется для соответствующих аудитов, уже опубликовано: FIPS 204, FIPS 205, формально верифицированная реализация mldsa-native на C, нативная обёртка Rust от Mysten mysten-mldsa-native-rs, а также наша текущая намеренно отложенная открытая реализация Post-Quantum Readiness in EdDSA Chains.

Вместо того чтобы просто получить одобрение, мы хотим, чтобы эта работа была предметом внимательного рассмотрения. Мы намеренно сузили область реализации до максимально возможной, намеренно сделали кросс‑верификацию обязательным порогом в построении и намеренно отложили использование обходных путей миграции. Если вы работаете над постквантовыми подписями, аппаратными кошельками или доказательными системами и считаете, что в каком-то из решений есть проблема — нам очень хочется услышать ваше мнение.

Пасхальное яйцо

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

В настоящее время ключи Ed25519 в Sui используют следующий путь вывода:

m/44'/784'/0'/0'/0'

При этом 784' обозначает Sui, а 44' — индекс назначения; схемы подписи ECDSA используют соответственно 54' и 74'. Для постквантовых ключей будет использоваться:

m/94'/784'/0'/0'/0'

Здесь «94» — это не просто следующее число в последовательности: оно обозначает год. И совпадение заключается в том, что Peter Shor опубликовал алгоритм, который сделал всё это необходимым, именно в 1994 году. В честь этого совпадения в каждом пути вывода постквантовых ключей Sui будет присутствовать год, с которого начинается этот отсчёт.