Автор: Виталик, основатель Ethereum Перевод: криптонатив Jinse Finance
По мере того, как Ethereum развивается от молодой экспериментальной технологии к зрелому технологическому стеку, способному предоставить обычным пользователям открытый, глобальный и не требующий разрешения опыт, одновременно должны произойти три основных технологических перехода:
Первое — трансформация расширения емкости L2 — все обращаются к технологии Rollup;
Второе — преобразование безопасности кошелька — все начинают использовать кошельки со смарт-контрактами;
Третье — преобразование конфиденциальности — обеспечение доступности функции перевода средств с сохранением конфиденциальности и обеспечение того, чтобы все другие разрабатываемые инструменты (социальное восстановление, проверка личности, репутация и т. д.) имели функции сохранения конфиденциальности.
*Треугольник трансформации экосистемы Эфириума. Вы можете выбрать только все три. *
Без первого элемента Ethereum потерпит неудачу, потому что каждая транзакция стоит 3,75 доллара (82,48 доллара, если мы пройдем еще один бычий рост), и каждый продукт массового рынка неизбежно откажется от торговли в сети и примет централизованное решение.
Без второго элемента Ethereum потерпит неудачу, поскольку пользователи не захотят хранить свои средства (и нефинансовые активы), и все обратятся к централизованным биржам.
Без третьего элемента Ethereum потерпел бы неудачу, потому что для многих пользователей все транзакции (и POAP и т. д.) были бы общедоступны, жертва конфиденциальностью была бы слишком велика, и каждый обратился бы хотя бы к некоторому уровню скрытых данных. Централизованное решение.
По причинам, изложенным выше, эти три перехода являются критическими. Но они также сложны из-за сложности координации. Необходимо улучшить не только функциональность протокола; в некоторых случаях способ нашего взаимодействия с Ethereum должен измениться фундаментально и глубоко, что потребует серьезных изменений в приложениях и кошельках.
Эти три преобразования коренным образом изменят отношения между пользователями и адресами.
В мире масштабирования L2 пользователи будут существовать в нескольких сетях L2. Являетесь ли вы участником ExampleDAO? ExampleDAO находится на оптимизме. Тогда у вас есть аккаунт в Optimism! У вас есть CDP системы стейблкоинов на ZkSync? Тогда у вас есть аккаунт на ZkSync! Вы когда-нибудь пробовали некоторые из приложений, расположенных на Kakarot? Тогда у вас есть аккаунт на Какарот! Прошли те времена, когда у пользователей был только один адрес.
*Мой вид кошелька Brave, я держу Ethereum в четырех местах. Да, Arbitrum и Arbitrum Nova разные. Не волнуйтесь, со временем все будет усложняться! *
**Кошельки со смарт-контрактами усложняют работу, поскольку затрудняют использование одного и того же адреса в сетях L1 и различных сетях L2. **Большинство пользователей сегодня используют внешние учетные записи, чьи адреса на самом деле являются хэшами открытых ключей, используемых для проверки подписей, поэтому между уровнями L1 и L2 ничего не меняется. Однако поддерживать адрес становится сложнее при использовании кошелька смарт-контракта. Несмотря на то, что было проделано много работы, чтобы попытаться сделать адреса хэш-кодом, который эквивалентен в разных сетях, наиболее важными из которых являются CREATE2 и фабрика синглетонов ERC-2470, добиться этого в совершенстве сложно. Некоторые сети L2 (например, «ZK-EVM четвертого типа») не совсем эквивалентны EVM, часто используют Solidity или промежуточный язык ассемблера, а не хэш-эквиваленты. Даже если эквивалентность хэша может быть достигнута, возможность смены владельца кошелька посредством смены ключа приводит к другим, менее предсказуемым последствиям.
**Конфиденциальность требует большего количества адресов на пользователя и может даже изменить типы адресов, которые мы обрабатываем. ** Если предложение скрытых адресов широко используется, пользователи могут иметь один адрес на транзакцию вместо нескольких адресов на пользователя или одного адреса на сеть L2. Другие схемы конфиденциальности, даже существующие, такие как Tornado Cash, изменяют способ хранения активов по-разному: средства многих пользователей хранятся в одном и том же смарт-контракте (и, следовательно, на одном и том же адресе). Чтобы отправить средства конкретному пользователю, ему нужно будет полагаться на собственную внутреннюю систему адресации схемы конфиденциальности.
Как мы видели, эти три преобразования по-разному ослабляют ментальную модель «один пользователь ≈ один адрес», некоторые из которых, в свою очередь, усложняют выполнение этих преобразований. Двумя особенно сложными вопросами являются:
**1. Если вы хотите заплатить кому-то, как вы получите платежную информацию? **
**2. Если пользователи хранят активы в разных местах в разных сетях, как они вносят ключевые изменения и социальное восстановление? **
Эти три перехода и внутрисетевые платежи (и личность)
У меня есть жетоны на Свитке, и я хочу использовать их для покупки кофе (если буквальное «я» относится к Виталику, автору этой статьи, то «кофе», конечно же, означает «зеленый чай»). Вы продаете кофе на Taiko, но принимаете только жетоны на Taiko. что делать?
В основном есть два решения:
Принимающий кошелек (который может быть продавцом или обычным человеком) стремится поддерживать каждый L2 и имеет некоторые функции асинхронного слияния средств.
Получатель платежа предоставляет свою информацию L2 рядом с адресом, а кошелек отправителя автоматически направляет средства на целевой L2 через какую-то систему моста между L2.
Конечно, эти решения можно использовать в комбинации: получатель платежа предоставляет список L2, который он готов принять, а кошелек отправителя определяет способ оплаты, который может быть отправлен напрямую (если повезет) или оплачен по мостовому пути через Л2.
Но это лишь один пример ключевой проблемы, связанной с тремя преобразованиями: Простые способы оплаты начинают требовать больше информации, чем просто 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 имеют «свободный» доступ к хранилищу ключей.
**Ветви Меркла. ** Ветви Меркла могут подтвердить состояние L1 для L2 или состояние L2 для L1, или их комбинация может подтвердить частичное состояние одного L2 для другого L2. Основным недостатком доказательств Меркла является высокая стоимость газа из-за длины доказательства, для которой может потребоваться длина доказательства 5 КБ, но из-за использования деревьев Веркла в будущем она будет уменьшена до <1 КБ.
**ЗК-СНАРКС. ** Вы можете снизить затраты на передачу данных, используя ZK-SNARK ветвей Merkle вместо использования самих ветвей. Методы агрегации вне цепочки (например, поверх EIP-4337) могут быть созданы, чтобы позволить одному ZK-SNARK проверять все доказательства состояния между цепочками в блоке.
**Обещание KZG. **Будь то L2 или построенная на нем схема, может быть введена система последовательной адресации, позволяющая доказывать состояние внутри системы всего 48 байт. Подобно ZK-SNARK, схемы множественных доказательств могут объединять все эти доказательства в одно доказательство для каждого блока.
Если мы хотим избежать необходимости подтверждения для каждой транзакции, мы можем реализовать более легкую схему, которая требует восстановления только через доказательства L2. Расходы из учетной записи будут зависеть от ключа расходов с соответствующим открытым ключом, хранящимся внутри учетной записи, но для восстановления потребуется транзакция для копирования текущего открытого ключа расходов в хранилище ключей. Даже если ваши старые ключи не защищены, средства на виртуальном адресе в безопасности: «активация» виртуального адреса для превращения его в пригодный для использования контракт потребует подтверждения кросс-L2 для репликации текущего открытого ключа расходов. На форумах Safe есть ветка, в которой описывается, как работает подобная архитектура.
Чтобы добавить конфиденциальности в такую схему, нам нужно только зашифровать указатели и сделать все доказательства внутри ZK-SNARKs:
При дальнейшей работе (например, используя эту работу в качестве отправной точки) мы также можем снять ZK - большая часть сложности SNARK, построение более упрощенной схемы на основе KZG.
Эти сценарии могут усложняться. Положительным моментом является то, что между ними существует много потенциальных синергий. Например, концепция «контракта хранилища ключей» также может быть решением «адреса», упомянутого в предыдущем разделе: если мы хотим, чтобы у пользователей были постоянные адреса, которые не меняются каждый раз, когда они обновляют свои ключи, мы можем поместить скрытность Мета-адрес, ключ шифрования и другая информация помещаются в контракт хранилища ключей, а адрес контракта хранилища ключей используется в качестве «адреса» пользователя.
Много вторичной инфраструктуры нуждается в обновлении
Использование ENS стоит дорого. Хотя это не так дорого, как раньше в июне 2023 года, комиссия за транзакцию регистрации доменного имени по-прежнему относительно высока, что сопоставимо со стоимостью доменного имени ENS. Например, регистрация на zuzalu.eth стоит около 27 долларов, из которых 11 долларов — комиссия за транзакцию. Но если рынок снова станет бычьим, комиссии возрастут. Даже если цена ETH не увеличится, а плата за газ вернется к 200 gwei, комиссия за транзакцию регистрации доменного имени достигнет 104 долларов США. Поэтому, если мы хотим, чтобы люди действительно использовали ENS, особенно в таких случаях, как децентрализованные социальные сети, где пользователи запрашивают почти бесплатную регистрацию (плата за домен ENS не является проблемой, поскольку эти платформы могут предоставлять пользователям поддомены), нам нужен ENS. используется на уровне 2.
К счастью, команда ENS уже активизировалась, и ENS внедряется на уровне 2! ERC-3668 (также известный как «стандарт CCIP») и ENSIP-10 обеспечивают способ автоматической проверки субдоменов ENS на любом уровне 2. Стандарт CCIP требует создания смарт-контракта, описывающего метод проверки доказательств данных на уровне 2, и доменное имя (например, ecc.eth для Optinames) может быть передано под контроль такого контракта. Как только контракт CCIP контролирует ecc.eth на L1, доступ к определенному субдомену.ecc.eth автоматически найдет и проверит доказательство, хранящее состояние уровня 2 этого конкретного субдомена (например, ветвь Merkle).
фактически для получения этих доказательств требуется доступ к списку URL-адресов, хранящихся в контракте, хотя это Каким-то образом это может выглядеть как централизация, но я бы сказал, что на самом деле это не так: это модель доверия 1-к-N (недействительные доказательства перехватываются логикой проверки в функции обратного вызова контракта CCIP, если один из URL-адресов A который возвращает действительное доказательство, в порядке). Список URL-адресов может содержать десятки URL-адресов.
**Усилия ENS CCIP — это история успеха, и ее следует рассматривать как знак того, что радикальные реформы, в которых мы нуждаемся, действительно возможны. ** Но предстоит еще много реформ на уровне приложений. Вот некоторые примеры:
** Многие DApp полагаются на то, что пользователи предоставляют автономные подписи. **Для внешних учетных записей (EOA) это просто. ERC-1271 предоставляет стандартизированный способ сделать это для смарт-контрактных кошельков. Однако многие DApp по-прежнему не поддерживают ERC-1271, и их необходимо адаптировать.
** У DApp, которые используют «это EOA?» для разграничения пользователей и контрактов (например, для предотвращения передачи или обеспечения соблюдения лицензионных платежей), возникнут проблемы. ** В общем, я бы посоветовал не пытаться найти здесь чисто техническое решение; определение того, является ли конкретная передача криптографического контроля передачей бенефициарного права, является сложной проблемой, которая не может быть решена без обращения к некоторым внечейновым инициативам сообщества. механизмы решают. Скорее всего, приложения будут меньше полагаться на технические средства блокировки переводов и больше на такие методы, как налог Харбергера.
**Взаимодействие кошелька с выплатами и ключами шифрования нуждается в улучшении. ** В настоящее время кошельки обычно используют детерминированные подписи для генерации ключей для конкретного приложения: подписание стандартного одноразового номера (например, хэша имени приложения) с закрытым ключом EOA будет генерировать детерминированное значение, если закрытый ключ не находится во владении, в противном случае значение не может быть сгенерирован и поэтому чисто технически безопасен. Однако эти методы «непрозрачны» для кошелька, что не позволяет кошелькам реализовывать проверки безопасности на уровне пользовательского интерфейса. В более зрелой экосистеме подпись, шифрование и связанные с ними функции должны будут обрабатываться кошельками более явно.
Легкие клиенты (например, Helios) должны будут аутентифицировать уровень 2, а не только уровень 1**. **В настоящее время легкий клиент сосредоточен на проверке достоверности информации заголовка блока L1 (с использованием протокола синхронизации легкого клиента) и проверке ветви Merkle состояния L1 и транзакций на основе информации заголовка блока L1. В будущем им также потребуется проверять доказательства состояния L2, расположенные в корневом каталоге состояния, хранящемся в L1 (в более продвинутых версиях фактически будет проверяться предварительное подтверждение L2).
Кошельки должны будут защищать активы и данные
В настоящее время миссией кошелька является защита активов. Все хранится в цепочке, все, что нужно защитить кошельку, — это закрытые ключи, которые в настоящее время защищают эти активы. Если вы измените ключ, вы можете безопасно опубликовать предыдущий закрытый ключ в открытом доступе в Интернете на следующий день. Однако в мире с нулевым разглашением это уже не так: кошельки не только защищают учетные данные для аутентификации, но и хранят ваши данные.
Мы видим первые признаки такого мира в Zuzalu с Zupass, системой идентификации на основе ZK-SNARK. У пользователя есть закрытый ключ, который используется для аутентификации в системе, который можно использовать для создания основных доказательств, таких как «доказать, что я житель Зузалу, не раскрывая, какой я житель». Система Zupass также начала создавать другие приложения поверх нее, в первую очередь штампы (версия POAP от Zupass).
*Один из моих многочисленных штампов Zupass, подтверждающий, что я являюсь членом Team Cat. *
Ключевой особенностью штампов по отношению к POAP является то, что они являются частными: вы храните данные локально и подтверждаете штамп их ZK (или выполняете некоторые вычисления на штампах), только если хотите передать эту информацию кому-либо. Но это также связано с дополнительным риском: если вы потеряете эту информацию, вы потеряете свои марки.
Конечно, проблема хранения данных может быть сведена к проблеме хранения одного ключа шифрования: третья сторона (даже в сети) может хранить зашифрованную копию данных. Удобным преимуществом этого является то, что предпринимаемые вами действия не изменяют ключ шифрования, поэтому не требуется никакого взаимодействия с системой, содержащей ключ шифрования. Но даже тогда, если вы потеряете ключ шифрования, вы потеряете все свои данные. И, в свою очередь, если кто-то увидит ваш ключ шифрования, он сможет увидеть все, что зашифровано с помощью этого ключа. **
Практическое решение Zupass состоит в том, чтобы побудить людей хранить свои ключи на нескольких устройствах (например, на ноутбуке и телефоне), поскольку вероятность того, что они потеряют доступ ко всем из них одновременно, невелика. Мы можем сделать еще один шаг вперед, используя совместное использование ключей, чтобы разделить хранилище ключей между несколькими защитниками.
Социальное восстановление через MPC не является адекватным решением для кошельков, так как это означает, что не только текущий защитник, но и предыдущие защитники могут вступить в сговор с целью кражи ваших активов, что является недопустимо высоким риском. Хотя нарушение конфиденциальности обычно менее рискованно, чем полная потеря активов, для случаев использования с высокими требованиями к конфиденциальности можно принять более высокий риск потери, если не создавать резервные копии ключей, связанных с этими потребностями в конфиденциальности.
Чтобы не увязнуть пользователей в сложной системе с несколькими путями восстановления, кошельки, которые поддерживают социальное восстановление, могут нуждаться в управлении как аспектами восстановления активов, так и восстановлением ключа шифрования.
Вернуться к личности
Общей темой среди этих изменений является то, что концепция «адреса» как представления личности в блокчейне должна будет коренным образом измениться. ** «Инструкции по взаимодействию со мной» больше не будет просто адресом ETH; экспресс. **
Один из этих способов — использовать ENS в качестве вашей личности: ваша запись ENS может содержать всю информацию о том, как платить и взаимодействовать с вами, если вы отправляете кому-то bob.eth (или bob.ecc.eth и т. д.), они могут запросить и узнайте обо всем, что взаимодействует с вами, в том числе более сложными способами в разных доменах и с защитой конфиденциальности.
Однако этот подход, ориентированный на ЭНС, имеет два недостатка:
**С вашим именем связано слишком много контента. **Ваше имя не говорит о вас все, это лишь один из многих ваших атрибутов. Должна быть возможность изменить свое имя без переноса всего профиля вашей личности и обновления записей во многих приложениях.
**У вас не может быть вымышленных имен, не требующих доверия. **Ключевой особенностью любого блокчейна для пользователей является возможность отправлять токены людям, которые еще не взаимодействовали с цепочкой. Без такого функционала возникает дилемма: взаимодействие с цепочкой требует оплаты комиссии за транзакцию, а оплата комиссии за транзакцию требует... уже владения токенами. Адреса ETH, в том числе адреса смарт-контрактов с CREATE2, имеют эту функциональность. Имен ENS нет, потому что, если оба Боба вне сети решат, что они bob.ecc.eth, нет возможности выбрать, какой Боб получит имя.
Одним из возможных решений является добавление большего количества содержимого в контракт хранилища ключей, упомянутый ранее в архитектуре этой статьи. Контракт хранилища ключей может содержать различную информацию о вас и взаимодействиях с вами (и с CCIP часть этой информации может быть вне сети), пользователи будут использовать свой контракт хранилища ключей в качестве своего основного идентификатора. Однако фактически полученные ими активы будут храниться в самых разных местах. Контракты хранилища ключей не зависят от имени и удобны для виртуального имени: вы можете сгенерировать адрес, который может быть инициализирован только контрактом хранилища ключей с определенными фиксированными начальными параметрами.
Другой класс решений включает полный отказ от понятия адресов, обращенных к пользователю, подобно платежному протоколу Биткойн. Одна из идей состоит в том, чтобы больше полагаться на прямые каналы связи между отправителем и получателем; например, отправитель может отправить ссылку запроса (в виде явного URL-адреса или QR-кода), которую получатель может использовать для отправки любого запроса, который он пожелает принять. оплата.
Будь то отправитель или получатель, который действует первым, больше полагаясь на кошельки для создания актуальной платежной информации в режиме реального времени, уменьшается трение. Однако постоянные идентификаторы удобны (особенно с ENS), тогда как на практике полагаться на прямую связь между отправителем и получателем — очень сложная проблема, поэтому можно увидеть комбинацию различных методов.
Во всех этих проектах крайне важно оставаться децентрализованным и понятным для пользователей. Нам необходимо обеспечить, чтобы пользователи могли легко получить доступ к актуальному представлению своих текущих активов и адресованных им сообщений. Эти представления должны основываться на открытых инструментах, а не на проприетарных решениях. Потребуется тяжелая работа, чтобы не допустить, чтобы более сложная платежная инфраструктура превратилась в непрозрачную «башню абстракции», которую трудно понять и адаптировать к новым условиям. Несмотря на проблемы, достижение масштабируемости, безопасности кошелька и конфиденциальности Ethereum для обычных пользователей имеет первостепенное значение. Речь идет не только о технической осуществимости, но и о фактической доступности для среднего пользователя. Мы должны принять этот вызов.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Виталик: Экосистеме Ethereum нужны три технологические трансформации
Автор: Виталик, основатель Ethereum Перевод: криптонатив Jinse Finance
По мере того, как Ethereum развивается от молодой экспериментальной технологии к зрелому технологическому стеку, способному предоставить обычным пользователям открытый, глобальный и не требующий разрешения опыт, одновременно должны произойти три основных технологических перехода:
*Треугольник трансформации экосистемы Эфириума. Вы можете выбрать только все три. *
Без первого элемента Ethereum потерпит неудачу, потому что каждая транзакция стоит 3,75 доллара (82,48 доллара, если мы пройдем еще один бычий рост), и каждый продукт массового рынка неизбежно откажется от торговли в сети и примет централизованное решение.
Без второго элемента Ethereum потерпит неудачу, поскольку пользователи не захотят хранить свои средства (и нефинансовые активы), и все обратятся к централизованным биржам.
Без третьего элемента Ethereum потерпел бы неудачу, потому что для многих пользователей все транзакции (и POAP и т. д.) были бы общедоступны, жертва конфиденциальностью была бы слишком велика, и каждый обратился бы хотя бы к некоторому уровню скрытых данных. Централизованное решение.
По причинам, изложенным выше, эти три перехода являются критическими. Но они также сложны из-за сложности координации. Необходимо улучшить не только функциональность протокола; в некоторых случаях способ нашего взаимодействия с Ethereum должен измениться фундаментально и глубоко, что потребует серьезных изменений в приложениях и кошельках.
Эти три преобразования коренным образом изменят отношения между пользователями и адресами.
В мире масштабирования L2 пользователи будут существовать в нескольких сетях L2. Являетесь ли вы участником ExampleDAO? ExampleDAO находится на оптимизме. Тогда у вас есть аккаунт в Optimism! У вас есть CDP системы стейблкоинов на ZkSync? Тогда у вас есть аккаунт на ZkSync! Вы когда-нибудь пробовали некоторые из приложений, расположенных на Kakarot? Тогда у вас есть аккаунт на Какарот! Прошли те времена, когда у пользователей был только один адрес.
**Кошельки со смарт-контрактами усложняют работу, поскольку затрудняют использование одного и того же адреса в сетях L1 и различных сетях L2. **Большинство пользователей сегодня используют внешние учетные записи, чьи адреса на самом деле являются хэшами открытых ключей, используемых для проверки подписей, поэтому между уровнями L1 и L2 ничего не меняется. Однако поддерживать адрес становится сложнее при использовании кошелька смарт-контракта. Несмотря на то, что было проделано много работы, чтобы попытаться сделать адреса хэш-кодом, который эквивалентен в разных сетях, наиболее важными из которых являются CREATE2 и фабрика синглетонов ERC-2470, добиться этого в совершенстве сложно. Некоторые сети L2 (например, «ZK-EVM четвертого типа») не совсем эквивалентны EVM, часто используют Solidity или промежуточный язык ассемблера, а не хэш-эквиваленты. Даже если эквивалентность хэша может быть достигнута, возможность смены владельца кошелька посредством смены ключа приводит к другим, менее предсказуемым последствиям.
**Конфиденциальность требует большего количества адресов на пользователя и может даже изменить типы адресов, которые мы обрабатываем. ** Если предложение скрытых адресов широко используется, пользователи могут иметь один адрес на транзакцию вместо нескольких адресов на пользователя или одного адреса на сеть L2. Другие схемы конфиденциальности, даже существующие, такие как Tornado Cash, изменяют способ хранения активов по-разному: средства многих пользователей хранятся в одном и том же смарт-контракте (и, следовательно, на одном и том же адресе). Чтобы отправить средства конкретному пользователю, ему нужно будет полагаться на собственную внутреннюю систему адресации схемы конфиденциальности.
Как мы видели, эти три преобразования по-разному ослабляют ментальную модель «один пользователь ≈ один адрес», некоторые из которых, в свою очередь, усложняют выполнение этих преобразований. Двумя особенно сложными вопросами являются:
**1. Если вы хотите заплатить кому-то, как вы получите платежную информацию? **
**2. Если пользователи хранят активы в разных местах в разных сетях, как они вносят ключевые изменения и социальное восстановление? **
Эти три перехода и внутрисетевые платежи (и личность)
У меня есть жетоны на Свитке, и я хочу использовать их для покупки кофе (если буквальное «я» относится к Виталику, автору этой статьи, то «кофе», конечно же, означает «зеленый чай»). Вы продаете кофе на Taiko, но принимаете только жетоны на Taiko. что делать?
В основном есть два решения:
Принимающий кошелек (который может быть продавцом или обычным человеком) стремится поддерживать каждый L2 и имеет некоторые функции асинхронного слияния средств.
Получатель платежа предоставляет свою информацию L2 рядом с адресом, а кошелек отправителя автоматически направляет средства на целевой L2 через какую-то систему моста между L2.
Конечно, эти решения можно использовать в комбинации: получатель платежа предоставляет список L2, который он готов принять, а кошелек отправителя определяет способ оплаты, который может быть отправлен напрямую (если повезет) или оплачен по мостовому пути через Л2.
Но это лишь один пример ключевой проблемы, связанной с тремя преобразованиями: Простые способы оплаты начинают требовать больше информации, чем просто 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, и логика проверки для каждого адреса — это указатель на контракт хранилища ключей. Для расходования средств с этих адресов потребуется предоставить доказательство текущего (или, что более реалистично, совсем недавнего) открытого ключа расходования средств.
Это доказательство может быть получено несколькими способами:
Если мы хотим избежать необходимости подтверждения для каждой транзакции, мы можем реализовать более легкую схему, которая требует восстановления только через доказательства L2. Расходы из учетной записи будут зависеть от ключа расходов с соответствующим открытым ключом, хранящимся внутри учетной записи, но для восстановления потребуется транзакция для копирования текущего открытого ключа расходов в хранилище ключей. Даже если ваши старые ключи не защищены, средства на виртуальном адресе в безопасности: «активация» виртуального адреса для превращения его в пригодный для использования контракт потребует подтверждения кросс-L2 для репликации текущего открытого ключа расходов. На форумах Safe есть ветка, в которой описывается, как работает подобная архитектура.
Чтобы добавить конфиденциальности в такую схему, нам нужно только зашифровать указатели и сделать все доказательства внутри ZK-SNARKs:
Эти сценарии могут усложняться. Положительным моментом является то, что между ними существует много потенциальных синергий. Например, концепция «контракта хранилища ключей» также может быть решением «адреса», упомянутого в предыдущем разделе: если мы хотим, чтобы у пользователей были постоянные адреса, которые не меняются каждый раз, когда они обновляют свои ключи, мы можем поместить скрытность Мета-адрес, ключ шифрования и другая информация помещаются в контракт хранилища ключей, а адрес контракта хранилища ключей используется в качестве «адреса» пользователя.
Много вторичной инфраструктуры нуждается в обновлении
Использование ENS стоит дорого. Хотя это не так дорого, как раньше в июне 2023 года, комиссия за транзакцию регистрации доменного имени по-прежнему относительно высока, что сопоставимо со стоимостью доменного имени ENS. Например, регистрация на zuzalu.eth стоит около 27 долларов, из которых 11 долларов — комиссия за транзакцию. Но если рынок снова станет бычьим, комиссии возрастут. Даже если цена ETH не увеличится, а плата за газ вернется к 200 gwei, комиссия за транзакцию регистрации доменного имени достигнет 104 долларов США. Поэтому, если мы хотим, чтобы люди действительно использовали ENS, особенно в таких случаях, как децентрализованные социальные сети, где пользователи запрашивают почти бесплатную регистрацию (плата за домен ENS не является проблемой, поскольку эти платформы могут предоставлять пользователям поддомены), нам нужен ENS. используется на уровне 2.
К счастью, команда ENS уже активизировалась, и ENS внедряется на уровне 2! ERC-3668 (также известный как «стандарт CCIP») и ENSIP-10 обеспечивают способ автоматической проверки субдоменов ENS на любом уровне 2. Стандарт CCIP требует создания смарт-контракта, описывающего метод проверки доказательств данных на уровне 2, и доменное имя (например, ecc.eth для Optinames) может быть передано под контроль такого контракта. Как только контракт CCIP контролирует ecc.eth на L1, доступ к определенному субдомену.ecc.eth автоматически найдет и проверит доказательство, хранящее состояние уровня 2 этого конкретного субдомена (например, ветвь Merkle).
**Усилия ENS CCIP — это история успеха, и ее следует рассматривать как знак того, что радикальные реформы, в которых мы нуждаемся, действительно возможны. ** Но предстоит еще много реформ на уровне приложений. Вот некоторые примеры:
Кошельки должны будут защищать активы и данные
В настоящее время миссией кошелька является защита активов. Все хранится в цепочке, все, что нужно защитить кошельку, — это закрытые ключи, которые в настоящее время защищают эти активы. Если вы измените ключ, вы можете безопасно опубликовать предыдущий закрытый ключ в открытом доступе в Интернете на следующий день. Однако в мире с нулевым разглашением это уже не так: кошельки не только защищают учетные данные для аутентификации, но и хранят ваши данные.
Мы видим первые признаки такого мира в Zuzalu с Zupass, системой идентификации на основе ZK-SNARK. У пользователя есть закрытый ключ, который используется для аутентификации в системе, который можно использовать для создания основных доказательств, таких как «доказать, что я житель Зузалу, не раскрывая, какой я житель». Система Zupass также начала создавать другие приложения поверх нее, в первую очередь штампы (версия POAP от Zupass).
*Один из моих многочисленных штампов Zupass, подтверждающий, что я являюсь членом Team Cat. *
Ключевой особенностью штампов по отношению к POAP является то, что они являются частными: вы храните данные локально и подтверждаете штамп их ZK (или выполняете некоторые вычисления на штампах), только если хотите передать эту информацию кому-либо. Но это также связано с дополнительным риском: если вы потеряете эту информацию, вы потеряете свои марки.
Конечно, проблема хранения данных может быть сведена к проблеме хранения одного ключа шифрования: третья сторона (даже в сети) может хранить зашифрованную копию данных. Удобным преимуществом этого является то, что предпринимаемые вами действия не изменяют ключ шифрования, поэтому не требуется никакого взаимодействия с системой, содержащей ключ шифрования. Но даже тогда, если вы потеряете ключ шифрования, вы потеряете все свои данные. И, в свою очередь, если кто-то увидит ваш ключ шифрования, он сможет увидеть все, что зашифровано с помощью этого ключа. **
Практическое решение Zupass состоит в том, чтобы побудить людей хранить свои ключи на нескольких устройствах (например, на ноутбуке и телефоне), поскольку вероятность того, что они потеряют доступ ко всем из них одновременно, невелика. Мы можем сделать еще один шаг вперед, используя совместное использование ключей, чтобы разделить хранилище ключей между несколькими защитниками.
Социальное восстановление через MPC не является адекватным решением для кошельков, так как это означает, что не только текущий защитник, но и предыдущие защитники могут вступить в сговор с целью кражи ваших активов, что является недопустимо высоким риском. Хотя нарушение конфиденциальности обычно менее рискованно, чем полная потеря активов, для случаев использования с высокими требованиями к конфиденциальности можно принять более высокий риск потери, если не создавать резервные копии ключей, связанных с этими потребностями в конфиденциальности.
Чтобы не увязнуть пользователей в сложной системе с несколькими путями восстановления, кошельки, которые поддерживают социальное восстановление, могут нуждаться в управлении как аспектами восстановления активов, так и восстановлением ключа шифрования.
Вернуться к личности
Общей темой среди этих изменений является то, что концепция «адреса» как представления личности в блокчейне должна будет коренным образом измениться. ** «Инструкции по взаимодействию со мной» больше не будет просто адресом ETH; экспресс. **
Один из этих способов — использовать ENS в качестве вашей личности: ваша запись ENS может содержать всю информацию о том, как платить и взаимодействовать с вами, если вы отправляете кому-то bob.eth (или bob.ecc.eth и т. д.), они могут запросить и узнайте обо всем, что взаимодействует с вами, в том числе более сложными способами в разных доменах и с защитой конфиденциальности.
Однако этот подход, ориентированный на ЭНС, имеет два недостатка:
Одним из возможных решений является добавление большего количества содержимого в контракт хранилища ключей, упомянутый ранее в архитектуре этой статьи. Контракт хранилища ключей может содержать различную информацию о вас и взаимодействиях с вами (и с CCIP часть этой информации может быть вне сети), пользователи будут использовать свой контракт хранилища ключей в качестве своего основного идентификатора. Однако фактически полученные ими активы будут храниться в самых разных местах. Контракты хранилища ключей не зависят от имени и удобны для виртуального имени: вы можете сгенерировать адрес, который может быть инициализирован только контрактом хранилища ключей с определенными фиксированными начальными параметрами.
Другой класс решений включает полный отказ от понятия адресов, обращенных к пользователю, подобно платежному протоколу Биткойн. Одна из идей состоит в том, чтобы больше полагаться на прямые каналы связи между отправителем и получателем; например, отправитель может отправить ссылку запроса (в виде явного URL-адреса или QR-кода), которую получатель может использовать для отправки любого запроса, который он пожелает принять. оплата.
Будь то отправитель или получатель, который действует первым, больше полагаясь на кошельки для создания актуальной платежной информации в режиме реального времени, уменьшается трение. Однако постоянные идентификаторы удобны (особенно с ENS), тогда как на практике полагаться на прямую связь между отправителем и получателем — очень сложная проблема, поэтому можно увидеть комбинацию различных методов.
Во всех этих проектах крайне важно оставаться децентрализованным и понятным для пользователей. Нам необходимо обеспечить, чтобы пользователи могли легко получить доступ к актуальному представлению своих текущих активов и адресованных им сообщений. Эти представления должны основываться на открытых инструментах, а не на проприетарных решениях. Потребуется тяжелая работа, чтобы не допустить, чтобы более сложная платежная инфраструктура превратилась в непрозрачную «башню абстракции», которую трудно понять и адаптировать к новым условиям. Несмотря на проблемы, достижение масштабируемости, безопасности кошелька и конфиденциальности Ethereum для обычных пользователей имеет первостепенное значение. Речь идет не только о технической осуществимости, но и о фактической доступности для среднего пользователя. Мы должны принять этот вызов.