Виталик Бутерин: Три технических перехода Ethereum

Автор оригинала: основатель Ethereum Виталик Бутерин

Особая благодарность Дэну Финлею, Карлу Флёршу, Дэвиду Хоффману и командам Scroll и SoulWallet за их отзывы, обзоры и предложения.

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

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

Треугольник перехода экосистемы.

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

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

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

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

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

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

*Согласно моему мнению о Brave Wallet, у меня есть ETH в четырех местах. Да, Arbitrum и Arbitrum Nova разные. Не волнуйтесь, со временем он станет грязнее! *

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

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

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

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

Если у пользователя есть много активов в разных цепочках, хранящихся в разных местах, как он выполняет ключевые изменения и социальное восстановление?

Три перехода и платежи по цепочке (и личности)

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

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

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

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

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

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

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

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

Принципиальная схема абстрактной схемы скрытых адресов, основанной на шифровании и ZK-SNARK.

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

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

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

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

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

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

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

• Прямой доступ только для чтения L1 в L2. L2 можно модифицировать для прямого чтения состояния L1. Если контракт хранилища ключей находится на уровне L1, это означает, что контракты на уровне L2 имеют «свободный» доступ к хранилищу ключей.
• Филиал Меркель. Ветви Merkle могут подтверждать состояние L1 для L2 или состояние L2 для L1, или вы можете комбинировать два, чтобы подтвердить частичное состояние одного L2 для другого L2. Основным недостатком доказательств Меркла является высокая стоимость газа из-за длины доказательства: для доказательства может потребоваться 5 КБ, но в будущем это будет уменьшено до < 1 КБ благодаря деревьям Веркла.
• ЗК-СНАРКС. Вы можете снизить затраты на передачу данных, используя ZK-SNARK форков Merkle вместо самих форков. Методы агрегации вне цепочки могут быть построены (например, поверх EIP-4337), чтобы ZK-SNARK проверял все доказательства состояния между цепочками в блоке.
• Обещание КЗГ. L2 или схемы, построенные поверх них, могут ввести систему последовательной адресации, позволяющую доказательствам состояния в этой системе иметь длину всего 48 байтов. Подобно ZK-SNARK, схемы множественных доказательств могут объединять все эти доказательства в одно доказательство для каждого блока.

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

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

Проделав дополнительную работу (например, используя эту работу в качестве отправной точки), мы также можем устранить большую часть сложности ZK-SNARK и сделать более простую схему на основе 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 получает контроль над ecc.eth на уровне L1, доступ к какому-либо субдомену.ecc.eth автоматически включает поиск и проверку подтверждения состояния (например, ветки Merkle) на уровне L2, где фактически хранится этот конкретный субдомен.

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

Проект ENS CCIP — это история успеха, и его следует рассматривать как знак того, что такая радикальная реформа, в которой мы нуждаемся, действительно возможна. Но предстоит еще много реформ на прикладном уровне. Несколько примеров:

• Многие децентрализованные приложения полагаются на пользователей для предоставления автономных подписей. С внешней учетной записью (EOA) это легко. ERC-1271 предоставляет стандартизированный способ для кошельков смарт-контрактов сделать это. Однако многие децентрализованные приложения по-прежнему не поддерживают ERC-1271; им это необходимо.
• Децентрализованные приложения, которые используют «Это EOA?» для различения пользователей и контрактов (например, для предотвращения передачи или обеспечения уплаты лицензионных отчислений), будут нарушены. В целом, я бы посоветовал не искать здесь чисто технические решения, выяснение того, является ли конкретная передача криптографического контроля передачей бенефициарного права, является сложной проблемой, которую невозможно решить без обращения к каким-то внечейновым механизмам, управляемым сообществом. Скорее всего, приложениям придется меньше полагаться на предотвращение утечки и больше на такие методы, как налоги Харбергера.
• Необходимо улучшить взаимодействие кошельков с расходами и ключами шифрования. В настоящее время кошельки обычно используют детерминированные подписи для генерации ключей для конкретного приложения: подписание стандартного одноразового номера (например, хэш имени приложения) с закрытым ключом EOA создает детерминированное значение, которое не может быть сгенерировано без закрытого ключа, поэтому это безопасно. в чисто техническом смысле. Однако эти методы «непрозрачны» для кошельков, что не позволяет кошелькам реализовывать проверки безопасности на уровне пользовательского интерфейса. В более зрелых экосистемах подпись, шифрование и связанные с ними функции должны будут обрабатываться кошельками более явно.
• Легкие клиенты (например, Helios) должны будут аутентифицировать L2, а не только L1. Сегодня легкие клиенты сосредоточены на проверке достоверности заголовков L1 (используя протокол синхронизации легкого клиента) и проверке вилок Merkle состояния L1 и транзакций, основанных на заголовках L1. Завтра им также нужно будет проверить подтверждение состояния L2, которое укоренено в корне состояния, хранящемся в L1 (более продвинутая версия фактически рассматривает предварительное подтверждение L2).

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

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

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

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

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

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

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

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

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

Вернуться к личности

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

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

Но у этого подхода, ориентированного на ЭНС, есть два недостатка:

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

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

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

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

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