Виталик Бутерин предложил хардфорк для Ethereum на случай квантовых компьютерных атак

Источник: https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901

Предположим, что завтра объявят о доступности квантовых компьютеров, и злоумышленники уже имеют к ним доступ и могут использовать их для кражи средств пользователей. Предотвращение такого сценария - цель криптографии, устойчивой к квантовым вычислениям (например, подписи Winternitz, STARKs), и после внедрения абстракции счета любой пользователь может переключиться на использование квантово-устойчивой схемы подписи по собственному графику. Но что, если у нас нет столько времени, и внезапный переход к квантовым вычислениям происходит гораздо раньше?

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

Основной проблемой с квантовыми компьютерами является следующее. Адрес Ethereum определен как keccak(priv_to_pub(k))[12:], где k - это закрытый ключ, а priv_to_pub - умножение на эллиптической кривой для преобразования закрытого ключа в открытый. С квантовыми компьютерами умножение на эллиптической кривой становится обратимым (потому что это проблема дискретного логарифма), но хеши все еще безопасны. Если пользователь не совершал транзакций с своим счетом, то виден только адрес, и он уже в безопасности. Но если пользователь совершил хотя бы одну транзакцию, то подпись этой транзакции раскрывает открытый ключ, который в пост-квантовом мире позволяет раскрывать закрытый ключ. И так большинство пользователей оказались бы уязвимыми.

Но мы можем сделать намного лучше. Главное понимание заключается в том, что на практике большинство закрытых ключей пользователей являются результатом множества хеширований. Многие ключи генерируются с использованием BIP-32, который генерирует каждый адрес через серию хешей, начиная от мастер-фразы. Многие не-BIP-32 методы генерации ключей работают аналогично: например, если у пользователя есть "мозговой кошелек", то обычно это серия хешей (или KDF средней сложности), применяемых к какой-то пароле.

Это подразумевает естественную структуру EIP для жесткой вилки цепи с целью восстановления после квантового кризиса:

1. Отменить все блоки после первого блока, где становится ясно, что происходит крупномасштабная кража.
2. Отключены традиционные транзакции на основе EOA (внешних адресов).
3. Добавлен новый тип транзакции, чтобы разрешить транзакции из кошельков смарт-контрактов (например, часть RIP-7560), если это еще не предусмотрено.
4. Добавлен новый тип транзакции или опкод, позволяющий предоставить доказательство STARK, подтверждающее знание (i) закрытого преобразования x, (ii) идентификатора хеш-функции 1 <= i < k из списка k утвержденных хеш-функций и (iii) открытого адреса A, такого, что keccak(priv_to_pub(hashes[i](x)))[12:] = A. STARK также принимает в качестве публичного ввода хеш нового кода проверки для этого счета. Если доказательство пройдет, код вашего счета переключится на новый код проверки, и вы сможете использовать его как кошелек смарт-контракта с этого момента и впредь.

По причине эффективности использования газа (в конце концов, STARKs занимают много места), мы можем позволить STARK быть пакетным доказательством, подтверждающим N STARKs указанного типа (это должен быть STARK-of-STARKs, а не прямое доказательство нескольких утверждений, потому что каждый x пользователя должен оставаться приватным для агрегатора).

Инфраструктура для внедрения жесткой вилки подобного рода в принципе может начать строиться уже завтра, что делает экосистему Ethereum максимально готовой в случае возникновения квантового кризиса.