Исследователи предлагают новую архитектуру квантово безопасного кошелька, которая использует современные инструменты Ethereum для смягчения будущих квантовых атак без изменения консенсуса или примитивов подписи.
Summary
Квантовый риск для кошельков Ethereum и ECDSA
Угроза, которую квантовые вычисления представляют для криптографии на эллиптических кривых, становится более конкретной, хотя криптографически значимая машина пока не существует. Однако алгоритм Шора уже демонстрирует, насколько эффективно он может решить задачу дискретного логарифма и, следовательно, взломать ECDSA.
Фонд Ethereum запустил специальные инициативы по исследованию пост-квантовой безопасности, и была намечена более широкая дорожная карта PQ. Более того, разработчики по всему экосистеме исследуют альтернативы, которые могут укрепить Ethereum до появления крупномасштабного квантового оборудования.
В Ethereum внешне управляемый аккаунт (EOA), который никогда не отправлял транзакцию, фактически устойчив к квантовым атакам, поскольку его публичный ключ скрыт за хешем. Однако, как только EOA подписывает транзакцию, публичный ключ становится навсегда раскрытым в блокчейне, и этот адрес фактически сжигается с точки зрения квантовой устойчивости.
Ограничения текущих усилий по созданию пост-квантовых подписей
Несколько проектов стремятся внедрить схемы пост-квантовых подписей в EVM, среди которых выделяются Falcon и Poqeth. Эти решения необходимы для долгосрочной безопасности. Однако проверка на блокчейне остается дорогой, стоя более 1M gas за проверку Falcon, в то время как подписи на основе хешей в настоящее время требуют около ~200k gas.
Эти затраты могут снизиться, если предложения, такие как EIP-8051 и EIP-8052, будут добавлены в EVM в будущем. Более того, эффективность использования газа — не единственное препятствие: стандартизация, интеграция с аппаратными кошельками и проверенная временем устойчивость к классическим криптографическим атакам остаются сложными задачами для любого нового стандарта подписей ETH.
Даже если бы надежная пост-квантовая подпись была технически готова, стандартизация все равно заняла бы время, а полная замена ECDSA потребовала бы изменений на уровне протокола. Вместо того чтобы полностью отказаться от ECDSA, описанный здесь дизайн делает каждый ключ ECDSA одноразовым, используя его ровно один раз.
Проектирование квантовой безопасности через эфемерные пары ключей
Основная концепция использует абстракцию аккаунта для разделения постоянной идентичности пользователя и ключа подписи. Кошелек на смарт-контракте поддерживает статическую идентичность в блокчейне, в то время как адрес авторизованного подписанта меняется после каждой транзакции, эффективно создавая эфемерные пары ключей.
Этот дизайн не мешает квантовому компьютеру восстановить закрытый ключ, связанный с прошлой транзакцией. Однако он гарантирует, что любой восстановленный ключ бесполезен для будущих операций, поскольку кошелек на смарт-контракте уже перейдет к новому подписанту.
Основной рабочий процесс прост и естественно вписывается в логику кошелька на смарт-контракте. Более того, он использует только сегодняшнюю инфраструктуру и не требует изменений в основных правилах протокола Ethereum.
Поток транзакций и ротация ключей ECDSA
Предложенная схема следует четырем четким шагам для каждой транзакции:
- Пользователь добавляет новый адрес в calldata своего userOp.
- Кошелек на смарт-контракте проверяет userOp и проверяет текущего подписанта.
- UserOp выполняется как обычно, например, выполняя перевод токенов.
- Наконец, кошелек на смарт-контракте обновляет своего авторизованного подписанта на новый адрес.
После выполнения старый закрытый ключ, даже если он восстановлен, не может снова подписать что-либо значимое для этого кошелька. Только новый адрес хранится в кошельке на смарт-контракте, раскрывая только значение, полученное из хеша, и сохраняя новый ключ квантово устойчивым до следующей транзакции.
На практике пользовательский опыт можно улучшить, генерируя последовательность новых адресов с использованием пути деривации BIP44. Этот метод уже является стандартом в широко используемых кошельках, поэтому он сохраняет низкие накладные расходы на реализацию, обеспечивая автоматическую ротацию ключей ecdsa под капотом.
Практическая реализация на Ethereum
Эта архитектура может быть реализована путем внесения незначительных изменений в базовый дизайн SimpleWallet. Все, что требуется, — это логика для разбора следующего адреса подписанта из calldata и функция, которая обновляет владельца кошелька на смарт-контракте соответствующим образом.
Уже существует доказательство концепции, демонстрирующее, что ротация подписанта может быть завершена даже при откате userOp. Более того, это решает ключевую проблему: если ротация происходила бы только при успехе, откат транзакции все равно раскрывал бы текущего подписанта и оставлял бы кошелек уязвимым.
С текущей реализацией примерные транзакции показывают затраты около ~136k gas единиц для перевода ERC20. Это подразумевает накладные расходы на газ менее 100k gas по сравнению со стандартным переводом токенов на той же цепочке. Накладные расходы значительно ниже стоимости проверки большинства пост-квантовых подписей на блокчейне сегодня.
Профиль затрат и преимущества абстракции аккаунта Ethereum
Затраты на газ для логики ротации подписанта, когда она подключена к существующему кошельку на основе абстракции аккаунта, еще ниже и почти незначительны в более широком контексте сложных DeFi взаимодействий. Более того, пользователи наследуют все обычные преимущества абстракции аккаунта Ethereum, такие как пакетные операции и гибкие правила проверки.
Поскольку адрес кошелька остается постоянным, в то время как подписанты меняются, этот дизайн сохраняет стабильную идентичность в блокчейне для dapps, исследователей и контрагентов. Тем не менее, это изменяет модель безопасности: пользователи должны убедиться, что их настройка генерации и хранения ключей может безопасно обрабатывать непрерывный поток новых ключей.
Использование механизмов социального восстановления для ротации ключей
Альтернативный способ достижения аналогичного поведения — повторное использование функций социального восстановления, уже присутствующих во многих кошельках на смарт-контрактах. Если конкретное ограничение не запрещает это, пользователь может установить свой собственный адрес в качестве хранителя восстановления и инициировать процедуру восстановления после каждой транзакции.
Этот подход эффективно передает контроль новому ключу через логику восстановления. Однако он влечет за собой немного более высокие затраты на газ, поскольку механизм, предназначенный для экстренного восстановления, используется для рутинного использования. Преимущество в том, что пользователи могут принять эту структуру, учитывающую квантовые угрозы, без развертывания пользовательских архитектур на блокчейне.
Эксперименты показывают, что дополнительные затраты на газ для этой операции на основе восстановления составляют примерно ~30k gas, в то время как общие накладные расходы базовой архитектуры без восстановления составляют около ~110k gas. Более того, разработчики кошельков могут настраивать эти параметры в зависимости от своих приоритетов безопасности и пользовательского опыта.
Риск утечки в мемпуле и оставшиеся уязвимости
Авторы признают ключевую уязвимость, которую эта модель не полностью устраняет: риск утечки в мемпуле в течение периода ожидания перед тем, как транзакция будет добыта. В этот период публичный ключ пользователя виден в мемпуле, и квантово-способный злоумышленник теоретически может восстановить закрытый ключ и опередить транзакцию.
Учитывая текущие квантовые возможности, этот сценарий не считается немедленно тревожным, поскольку у злоумышленника будет только очень короткий промежуток времени для выполнения вычислений. Однако, если кто-то хочет быть максимально консервативным, маршрутизация транзакций через частные мемпулы может практически устранить эту утечку на уровне мемпула.
Кроме того, развертывание этой архитектуры на сетях Layer 2 помогает снизить риск. L2 обычно имеют более короткие времена подтверждения и различные механизмы упорядочивания, сокращая окно, в течение которого публичный ключ подвергается воздействию злоумышленника.
Позиционирование в рамках более широких стратегий смягчения пост-квантовых угроз
Этот дизайн следует рассматривать как дополнительный инструмент в рамках более широкого ландшафта смягчения пост-квантовых угроз на Ethereum. Он не пытается быть лучшим квантово безопасным кошельком в абсолютном смысле и не заменяет долгосрочную необходимость в нативных пост-квантовых подписях в протоколе.
Вместо этого он устраняет одну конкретную слабость: долгосрочное раскрытие публичного ключа, которое алгоритм Шора мог бы использовать на уровне выполнения. Более того, он использует только текущую инфраструктуру и знакомые шаблоны смарт-контрактов, что делает его развертываемым без ожидания новых EIP или стандартов подписей.
Перспективы квантово безопасных транзакций на Ethereum
Предложенная схема квантово безопасного кошелька достигает квантовой безопасности на уровне выполнения, вращая пары ключей ECDSA после каждой транзакции, сохраняя при этом стабильный адрес смарт-контракта. Она не требует изменений в протоколе и добавляет примерно ~100k gas к базовому переводу, что составляет лишь часть текущих затрат на проверку пост-квантовых подписей.
Она не заменяет предстоящие схемы пост-квантовых подписей, которые остаются жизненно важными для полного, долгосрочного решения на Ethereum. Однако, устраняя длительное раскрытие публичного ключа, она предлагает практическую, постепенную защиту, которую пользователи и разработчики кошельков могут принять уже сегодня, при этом частные мемпулы обеспечивают наилучшее смягчение оставшейся утечки на уровне мемпула.
