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

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

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

Треугольник перехода экосистем. Вы можете выбрать только 3 из 3.

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

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

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

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

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

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

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

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

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

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

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

Три перехода и внутрицепочечные платежи (и идентификация)

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

В принципе, есть два решения:

1. Принимающие кошельки (которые могут быть торговцами, но могут быть и обычными людьми) очень стараются поддерживать каждый L2 и имеют некоторую автоматизированную функциональность для асинхронной консолидации средств.
2. Получатель указывает свой L2 вместе со своим адресом, и кошелек отправителя автоматически направляет средства в 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. Конфиденциальность: если пользователь намеренно имеет много адресов, чтобы не связывать их друг с другом, он, конечно, не захочет публично связывать их все, восстанавливая их в одно и то же время!

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

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

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

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

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

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

При большем объеме работы (например. используя <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof"> this в качестве отправной точки), мы также можем избавиться от большей части сложности ZK-SNARK и сделать более простую схему на основе KZG.

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

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

Использование ENS стоит дорого. Сегодня, в июне 2023 года, ситуация не так уж плоха: плата за транзакцию значительна, но все же сопоставима с платой за домен ENS. Регистрация zuzalu.eth обошлась мне примерно в $27, из которых $11 составили транзакционные сборы. Но если у нас будет еще один "бычий" рынок, гонорары резко возрастут. Даже без учета роста цен на ETH, возвращение платы за газ к 200 гвеям приведет к тому, что плата за регистрацию домена составит $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 будет автоматически включать поиск и проверку доказательства (например. Ветвь Меркла) состояния в L2, которое на самом деле хранит этот конкретный субдомен.

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

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

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

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

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

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

Один из моих многочисленных штампов Zupass, подтверждающий, что я - гордый член команды "Кошка".

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

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

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

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

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

Назад к личности

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

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

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

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

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

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

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

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

Отказ от ответственности：

1. Эта статья перепечатана с сайта[vitalik], Все авторские права принадлежат автору оригинала[Виталик Бутерин]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.