Виталик Бутерин: Эфириум должен завершить три трансформации L2, кошелек, конфиденциальность

Оригинальное название: 《Три перехода》

Автор: Vitalik Buterin

Перевод: MK, MarsBit

Когда Ethereum превращается из молодой экспериментальной технологии в зрелый технологический стек, который действительно может предоставить обычным пользователям открытый, глобализированный и безразрешительный опыт, этот стек должен пройти три основных технологических перехода, которые в основном происходят одновременно:

1. Переход L2 расширения - все переходят на rollups
2. Переход безопасности кошельков - все переходят на кошельки на смарт-контрактах
3. Переход конфиденциальности - обеспечение защиты конфиденциальности при переводе средств и гарантирование, что все другие инструменты (социальное восстановление, идентичность, репутация), которые находятся в разработке, могут защищать конфиденциальность

Это треугольное соотношение трансформации экосистемы. Вы можете выбрать только 3 из 3.

Без первого Ethereum потерпит неудачу, потому что каждая транзакция будет стоить 3,75 доллара (если у нас будет еще один бычий рынок, то цена составит 82,48 доллара), и каждый продукт, ориентированный на массовый рынок, в конечном итоге забудет о цепочке и примет централизованные решения по всем вопросам.

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

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

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

Эти три перехода кардинально изменят отношения между пользователями и адресами

В мире L2 расширения пользователи будут существовать в множестве L2. Вы член ExampleDAO, который находится на Optimism? Тогда у вас есть аккаунт на Optimism! У вас есть CDP в системе стейблкоинов ZkSync? Тогда у вас есть аккаунт на ZkSync! Вы когда-либо пробовали некоторые приложения, которые находятся на Kakarot? Тогда у вас есть аккаунт на Kakarot! Дни, когда у пользователя был только один адрес, ушли в прошлое.

У меня есть ETH в четырех местах, согласно моему представлению в Brave Wallet. Да, Arbitrum и Arbitrum Nova - это разные вещи. Не беспокойтесь, со временем это станет еще более сложным!

Кошельки на смарт-контрактах добавляют больше сложности, что делает владение одним и тем же адресом на L1 и различных L2 более трудным. В настоящее время большинство пользователей используют внешние аккаунты, адреса которых фактически являются хешами открытых ключей, используемых для проверки подписей - поэтому между L1 и L2 нет никаких изменений. Однако для кошельков на смарт-контрактах поддерживать один адрес становится более трудным. Несмотря на то, что было сделано много работы, чтобы сделать адреса эквивалентными хешам кода между сетями, особенно с помощью CREATE2 и ERC-2470 одиночных фабрик, добиться этого идеально очень сложно. Некоторые L2 (например, "тип 4 ZK-EVMs") не полностью эквивалентны EVM, часто используя Solidity или промежуточный ассемблер вместо этого, что препятствует хеш-эквивалентности. Даже если вы можете иметь хеш-эквивалентность, возможность изменения владения кошельком через изменения ключей приведет к другим неинтуитивным последствиям.

Конфиденциальность требует, чтобы у каждого пользователя было больше адресов, и даже может изменить типы адресов, с которыми мы работаем. Если предложение о конфиденциальных адресах получит широкое распространение, у каждого пользователя больше не будет всего лишь нескольких адресов, или по одному адресу на каждом L2, а может быть, по одному адресу на каждую транзакцию. Другие схемы конфиденциальности, даже существующие схемы, такие как Tornado Cash, изменят способ хранения активов: средства многих пользователей будут храниться в одном и том же смарт-контракте (поэтому на одном и том же адресе). Чтобы отправить средства конкретному пользователю, пользователю придется полагаться на внутреннюю адресную систему конфиденциальной схемы.

Как мы видим, эти три перехода по-разному подрывают психологическую модель «один пользователь ~= один адрес», и некоторые из этих эффектов возвращаются к сложности выполнения переходов. Две особенно сложные точки:

1. Если вы хотите заплатить кому-то, как вы получите информацию для оплаты им?

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

Три перехода связаны с платежами (и идентичностью) на цепи

У меня есть монеты на Scroll, и я хочу заплатить за кофе (если «я» в буквальном смысле, имея в виду автора этой статьи, то «кофе» конечно же является метафорой для «зеленого чая»). Вы продаете мне кофе, но вы готовы принимать монеты только на Taiko. Что мне делать?

В основном есть два решения:

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

2. Получатель предоставляет свой L2 и свой адрес, а кошелек отправителя автоматически маршрутизирует средства к целевому L2 через какую-то систему мостов между L2.

Конечно, эти решения могут комбинироваться: получатель предоставляет список L2, которые они готовы принимать, а кошелек отправителя рассчитывает платеж, что может включать прямую отправку (если им повезет) или маршрут через мост между L2.

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

Переход на кошельки на смарт-контрактах, к счастью, не создает большого бремени для системы адресов, но в других частях стеков приложений все еще есть некоторые технические проблемы, которые необходимо решить. Кошельки необходимо обновить, чтобы гарантировать, что они не просто отправляют 21000 gas в транзакциях, но что более важно, чтобы гарантировать, что принимающая сторона платежа в кошельках отслеживает не только ETH, переведенный от EOAs, но и ETH, отправленный кодом смарт-контракта. Приложения, которые полагаются на предположение о неизменности владения адресом (например, запрещая смарт-контракты для принудительного взимания роялти NFT), должны будут найти другие способы достижения своих целей. Кошельки на смарт-контрактах также упростят некоторые вещи - особенно если кто-то принимает только не ETH ERC20 токены, они смогут использовать плательщика ERC-4337 для оплаты gas с помощью этого токена.

С другой стороны, конфиденциальность снова ставит перед нами главную проблему, которую мы еще не решили. Изначальный Tornado Cash не вводил эти проблемы, потому что он не поддерживал внутренние переводы: пользователи могли только вносить средства в систему и выводить их. Как только вы можете проводить внутренние переводы, пользователи должны будут использовать внутреннюю адресную схему конфиденциальной системы. На практике «платежная информация» пользователя должна будет содержать (i) некоторый «публичный ключ расхода», то есть секретное обязательство, которое получатель может использовать для расходования, и (ii) способ, которым отправитель отправляет зашифрованную информацию, которую только получатель может расшифровать, чтобы помочь получателю обнаружить платеж.

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

Ключевой урок здесь заключается в том, что в экосистеме, ориентированной на конфиденциальность, пользователи будут иметь публичный ключ расхода и зашифрованный публичный ключ, и «платежная информация» пользователя должна будет содержать оба этих ключа. Кроме платежей, есть и другие хорошие причины для расширения в этом направлении. Например, если мы хотим создать зашифрованную электронную почту на основе Ethereum, пользователям потребуется публично предоставить какую-то форму зашифрованного ключа. В «мире EOA» мы можем повторно использовать ключи аккаунтов для достижения этой цели, но в мире безопасных кошельков на смарт-контрактах мы, возможно, должны иметь более четкие функции для достижения этой цели. Это также поможет сделать идентичность на основе Ethereum более совместимой с децентрализованными экосистемами конфиденциальности, не основанными на Ethereum, наиболее ярким примером которых являются ключи PGP.

Три перехода и восстановление ключей

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

1. Нереалистичные газовые сборы: это очевидно.
2. Контрфактические адреса: адреса, для которых еще не выпущены их смарт-контракты (на самом деле это означает, что вы еще не отправляли средства с этого аккаунта). Как пользователь, вы можете иметь бесконечное количество контрфактических адресов: по одному или нескольким на каждом L2, включая еще не существующие L2, а также совершенно другой набор бесконечных контрфактических адресов, происходящих из схемы конфиденциальных адресов.
3. Конфиденциальность: если пользователь намеренно имеет много адресов, чтобы избежать их связывания, они определенно не хотят открыто связывать все адреса, восстанавливая их одновременно или почти одновременно!

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

У каждого пользователя есть контракт хранилища ключей, который существует в одном месте (возможно, в основной сети или на конкретном L2). Затем у пользователя есть адреса на разных L2, где логика проверки каждого адреса является указателем на контракт хранилища ключей. Расход из этих адресов потребует доказательства доступа к контракту хранилища ключей, показывающего текущий (или более практично, последний) публичный ключ расхода.

Доказательства могут быть реализованы несколькими способами:

1. Прямое чтение только для чтения доступа к L1 в L2. L2 можно изменить, чтобы предоставить им способ прямого чтения состояния L1. Если контракт хранилища ключей находится на L1, это будет означать, что контракты внутри L2 могут «бесплатно» получить доступ к хранилищу ключей.

2. Меркле-ветви. Меркле-ветви могут доказать состояние L1 к L2, или состояние L2 к L1, или вы можете комбинировать оба, чтобы доказать часть состояния L2 другому L2. Основной недостаток меркле-доказательства заключается в высоких газовых сборах из-за длины доказательства: одно доказательство может потребовать 5 кБ, хотя благодаря Verkle-деревьям это в будущем уменьшится до менее 1 кБ.

3. ZK-SNARKs. Вы можете уменьшить стоимость данных, используя ZK-SNARK с меркле-ветвями вместо самой ветви. Можно построить технологии агрегирования вне цепи (например, на основе EIP-4337), позволяющие одному единственному ZK-SNARK проверять все кросс-цепные доказательства состояния в одном блоке.

4. Обещания KZG. L2 или схемы, построенные на его основе, могут ввести систему последовательного адресации, позволяющую доказательства состояния внутри этой системы быть всего 48 байт в длину. Как и ZK-SNARKs, многодоказательная схема может объединить все эти доказательства в одно доказательство для каждого блока.

Если мы хотим избежать необходимости делать доказательство для каждой транзакции, мы можем реализовать более легковесную схему, которая требует делать кросс-цепное доказательство только при восстановлении. Расход из одного аккаунта будет зависеть от расходного ключа, соответствующий публичный ключ которого хранится в этом аккаунте, но восстановление потребует транзакции, копирующей текущий публичный ключ расхода в хранилище ключей. Средства на контрфактических адресах будут безопасны, даже если ваш старый ключ небезопасен: «активация» контрфактического адреса, превращая его в рабочий контракт, потребует сделать кросс-цепное доказательство, копирующее текущий публичный ключ расхода. Эта тема на форуме Safe описывает, как подобная архитектура может работать.

Чтобы добавить конфиденциальности к такой схеме, нам просто нужно зашифровать указатели, а затем сделать все доказательства в ZK-SNARKs:

С помощью большего количества работы (например, начиная с этой работы) мы также можем избавиться от большей части сложности ZK-SNARKs, создав более простую схему на основе KZG.

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

Многочисленная инфраструктура второго уровня нуждается в обновлении

Использование ENS дорого. Сегодня, в июне 2023 года, ситуация еще не так плоха: хотя транзакционные сборы высоки, они все еще сопоставимы с затратами на доменное имя ENS. Регистрация zuzalu.eth обошлась мне примерно в 27 долларов, из которых 11 долларов составляют транзакционные сборы. Но если у нас будет еще один бычий рынок, сборы взлетят. Даже если цена ETH не вырастет, возвращение газовых сборов к 200 gwei увеличит транзакционные сборы за регистрацию доменного имени до 104 долларов. Поэтому, если мы хотим, чтобы люди действительно использовали ENS, особенно в таких приложениях, как децентрализованные социальные медиа, пользователи требуют почти бесплатной регистрации (сборы за доменные имена ENS не являются проблемой, поскольку эти платформы предоставляют поддомены своим пользователям), нам нужно, чтобы ENS работал на L2.

К счастью, команда ENS уже начала действовать, ENS на L2 действительно происходит! ERC-3668 (также известный как «стандарт CCIP»), вместе с ENSIP-10, предоставляет способ автоматической проверки поддоменов ENS на любом L2. Стандарт CCIP требует настройки смарт-контракта, который описывает способ проверки доказательства данных L2, доменные имена (например, Optinames используют ecc.eth) могут находиться под контролем такого контракта. Как только контракт CCIP на L1 контролирует ecc.eth, доступ к some subdomain.ecc.eth автоматически будет включать поиск и проверку доказательства (например, меркле-ветви) состояния L2, фактически хранящего этот конкретный поддомен.

Фактическое получение доказательства включает доступ к серии URL, хранящихся в контракте, что, признаться, кажется централизованным, хотя я бы утверждал, что это на самом деле не так: это модель доверия 1 из N (недействительные доказательства будут захвачены логикой проверки в обратном вызове контракта CCIP, пока хотя бы один URL возвращает действительное доказательство, проблем не будет). Этот список URL может содержать десятки URL.

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

Многие dapp зависят от пользователей, предоставляющих подписи вне цепи. Для внешних аккаунтов (EOA) это довольно просто. ERC-1271 предоставляет стандартизированный способ реализации этого для кошельков на смарт-контрактах. Тем не менее, многие dapp все еще не поддерживают ERC-1271; им нужно это поддерживать.

Те dapp, которые используют «Это EOA?» для различения пользователей и контрактов (например, чтобы предотвратить переводы или выполнение роялти) будут разрушены. В общем, я рекомендую не пытаться найти чисто техническое решение; выяснить, является ли передача конкретного контроля над криптографией вопросом полезного права, является сложной задачей, которую, возможно, не удастся решить без помощи некоторых механизмов, управляемых сообществом вне цепи. Скорее всего, приложениям придется меньше полагаться на предотвращение переводов и больше полагаться на такие технологии, как налог Харбергера.

Кошельки, как они взаимодействуют с расходными и зашифрованными ключами, нуждаются в улучшении. В настоящее время кошельки обычно используют детерминированные подписи для генерации ключей, специфичных для приложений: они подписывают стандартное случайное число (например, хеш имени приложения) с помощью приватного ключа EOA, создавая детерминированное значение, которое не может быть сгенерировано без приватного ключа, так что технически это безопасно. Однако эти технологии для кошельков «непрозрачны», что мешает кошелькам реализовывать проверки безопасности на уровне пользовательского интерфейса. В более зрелой экосистеме подписи, шифрование и связанные функции должны быть более четко обработаны кошельками.

Легкие клиенты (например, Helios) должны будут проверять L2, а не только L1. В настоящее время легкие клиенты сосредоточены на проверке действительности заголовков L1 (с использованием протоколов синхронизации легких клиентов) и проверке меркле-ветвей состояния и транзакций, происходящих от заголовков L1. Завтра им также нужно будет проверять доказательства состояния L2, происходящие от корня состояния, хранящегося в L1 (эта более продвинутая версия фактически будет смотреть на предварительное подтверждение L2).

Кошельки должны защищать активы и данные

Сейчас бизнес кошельков заключается в защите активов. Все существует на цепи, и единственное, что кошельки должны защищать, это приватные ключи, которые в настоящее время защищают эти активы. Если вы меняете ключи, вы можете безопасно опубликовать свой предыдущий приватный ключ в Интернете на следующий день. Однако в мире нулевых знаний ситуация уже не такова: кошелек не просто защищает удостоверения, он также защищает ваши данные.

Мы увидели первые признаки такого мира в Zupass, системе идентификации на основе ZK-SNARK, используемой в Zuzalu. У пользователя есть приватный ключ, который он использует для аутентификации в системе, и он может использовать его для выполнения основных доказательств, таких как «доказать, что я житель Zuzalu, но не раскрывать, кто именно». Однако система Zupass также начинает иметь другие приложения, наиболее известным из которых являются штампы (версия POAP для Zupass).

Один из моих штампов Zupass, подтверждающий, что я гордый член Team Cat.

Штампы предлагают ключевую особенность, которую не предоставляет POAP: штампы являются приватными: вы храните данные локально, и только когда вы хотите, чтобы они имели эту информацию, вы докажете им штамп (или некоторые вычисления на штампе). Но это увеличивает риск: если вы потеряете эту информацию, вы потеряете свои штампы.

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

Фактическое решение Zupass заключается в том, чтобы поощрять людей хранить свои ключи на нескольких устройствах (например, на ноутбуке и телефоне), поскольку вероятность потерять все устройства одновременно невелика. Мы можем пойти дальше, используя секретное разделение для хранения ключей, разбивая ключи между несколькими хранителями.

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

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

Вернемся к вопросу идентичности

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

Один из способов реализации этого - сделать ENS вашей идентичностью: ваша запись ENS может содержать всю эту информацию, и если вы отправите кому-то bob.eth (или bob.ecc.eth, или…), они смогут искать и узнать, как платить и взаимодействовать с вами, включая более сложные кросс-доменные и защищенные конфиденциальные способы.

Однако такой подход, сосредоточенный на ENS, имеет два слабых места:

• Он связывает слишком много вещей с вашим именем. Ваше имя не является вами, ваше имя - это всего лишь один из ваших многих атрибутов. Вы должны иметь возможность изменить свое имя, не перемещая весь свой профиль идентичности и не обновляя кучу записей в различных приложениях.
• Вы не можете иметь доверенные контрфактические имена. Ключевой UX-функцией любой блокчейн является возможность отправлять монеты людям, которые еще не взаимодействовали с цепью. Без такой функции возникнет проблема курицы и яйца: взаимодействие с цепью требует оплаты транзакционных сборов, а для оплаты сборов нужно… уже иметь монеты. Адреса ETH, включая адреса смарт-контрактов с CREATE2, имеют эту особенность. Имена ENS не имеют, потому что если два Боба решат вне цепи, что они bob.ecc.eth, нет способа выбрать, кто получит это имя.

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

Другой класс решений связан с отказом от концепции адресов, ориентированных на пользователя, что похоже на дух протокола платежей Bitcoin. Одна из идей заключается в том, чтобы больше полагаться на прямые каналы связи между отправителем и получателем; например, отправитель может отправить ссылку на запрос (в виде явного URL или QR-кода), получатель может использовать эту ссылку, чтобы принять платеж любым желаемым способом.

Независимо от того, кто первым предпримет действия, большее доверие к кошелькам для прямого и实时生成最新的付款信息都可以减少摩擦。话虽如此，持久的标识符是方便的（尤其是与 ENS 一起），并且在实践中，发件人和收件人之间存在直接通信的假设是一个非常棘手的问题，所以我们可能会看到不同技术的组合。

在所有这些设计中，保持事物既去中心化又对用户易于理解至关重要。我们需要确保用户能够轻松地访问他们当前资产的最新视图，以及已发布的面向他们的信息。这些视图应该依赖开放的工具，而不是专有解决方案。避免更复杂的支付基础设施变成一个开发人员难以理解正在发生的事情并将其适应到新环境的不透明的「抽象塔」将需要努力工作。尽管面临挑战，但是实现以太坊的可扩展性、钱包安全性和普通用户的隐私至关重要。这不仅仅是关于技术可行性，而是关于普通用户的实际可访问性。我们需要迎接这个挑战。

特别感谢 Dan Finlay、Karl Floersch、David Hoffman 以及 Scroll 和 SoulWallet 团队的反馈、审查和建议。