Видение идеального Кошелька Ethereum: всестороннее обновление от кросс-чейн опыта до защиты конфиденциальности

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

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

Пользовательский опыт кросс-L2 транзакций

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

Основная идея заключается в том, что ( встроена функция отправки кросс-чейн между L2, ) адреса и платежные запросы, специфичные для цепочки. Кошелек должен предоставлять пользователям адрес, соответствующий стилю черновика ERC.

Когда пользователь получает адрес в таком формате, ему просто нужно вставить его в поле "Получатель" кошелька и нажать "Отправить", и кошелек должен автоматически обработать отправку:

• Если на целевой цепи уже достаточно токенов, отправьте напрямую
• Если на других блокчейнах требуется токен, используйте кросс-чейн DEX протокол для отправки
• Если имеются токены разных типов, используйте DEX для преобразования в правильный тип, затем отправьте (, требуется подтверждение пользователя )

В сценариях, когда dapp запрашивает депозит, идеальным вариантом является расширение API web3, позволяющее dapp отправлять платежные запросы, специфичные для цепочки. Кошелек должен стандартизировать запрос getAvailableBalance и внимательно учитывать, на каких цепочках по умолчанию хранятся активы пользователя, чтобы обеспечить безопасность и удобство перевода.

Специфичный для цепочки платежный запрос также может быть помещен в QR-код для сканирования мобильным кошельком. В сценариях лицом к лицу или онлайн-платежах QR-код или вызов API, выданный получателем, указывает "Я хочу Y единиц токена Z на цепочке X, ссылка ID W", и кошелек может свободно выбирать способ удовлетворения этого запроса. Другой вариант - это протокол ссылки на возмещение, где кошелек пользователя генерирует QR-код или URL с авторизацией, а получатель отвечает за извлечение средств.

Оплата газа также является связанной темой. Если пользователь получает активы на каком-либо L2, но у него нет ETH, кошелек должен автоматически использовать протокол для оплаты газа на цепочке, где у пользователя есть ETH. Если кошелек предполагает, что пользователь в будущем будет совершать больше транзакций на этом L2, он также может использовать DEX для отправки определенного количества ETH в качестве резерва газа.

Безопасность аккаунта

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

Моё долгосрочное предпочтительное решение — это социальное восстановление и мультиподписный Кошелек с многоуровневым контролем доступа. Учетные записи пользователей имеют два уровня ключей: основной ключ и N опекунов (, где N=5). Основной ключ может использоваться для низкозначительных и не финансовых операций. Большинство опекунов необходимо для выполнения: (1) высокозначительных операций, таких как отправка всех средств со счета, (2) изменение основного ключа или любого опекуна. При необходимости основному ключу может быть разрешено выполнять высокозначительные операции через временную блокировку.

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

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

1. Для опытных пользователей криптовалюты можно выбрать ключи друзей и семьи.
2. Институциональный куратор: компания, предоставляющая услуги подписи, требуется дополнительное подтверждение информации.
3. Несколько личных устройств (, таких как мобильные телефоны, компьютеры, аппаратные кошельки ), но новым пользователям может быть трудно их настроить и управлять.
4. Решение на основе менеджера паролей, может быть локально или в облаке, но полагаться только на них недостаточно для защиты всех активов пользователя.
5. Централизованный ID с ZK-упаковкой: такие как zk-email, Anon Aadhaar и т.д., могут преобразовать централизованный ID в Ethereum адрес.

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

Для новых пользователей Кошелек может предложить простые варианты, такие как схема 2 из 3 на основе zk-email, локально хранящегося ключа и резервной копии ключа провайдера. По мере роста опыта пользователя или увеличения активов следует предложить добавить больше опекунов.

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

Защита пользователей от мошенничества и других внешних угроз

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

Приватность

Пришло время серьезно отнестись к приватности Ethereum. Технология ZK-SNARK достигла значительного прогресса, не полагаясь на бэкдоры, и приватные технологии (, такие как приватные пулы ), становятся все более зрелыми. Вторичная инфраструктура, такая как Waku и мемпулы ERC-4337, также постепенно стабилизируется. Однако на данный момент для проведения приватных переводов пользователям необходимо явно загружать и использовать "Кошелек для приватности", что увеличивает неудобства и снижает количество пользователей. Решение заключается в том, чтобы напрямую интегрировать приватные переводы в кошелек.

Одним из простых решений является: Кошелек хранит часть активов пользователя в качестве "приватного баланса" в пуле конфиденциальности. При переводе средства автоматически выходят из пула конфиденциальности, а при получении средств автоматически генерируется невидимый адрес.

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

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

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

Кошелек Ethereum также должен стать кошельком данных

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

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

Безопасный доступ к цепочке

В настоящее время кошелек зависит от поставщиков RPC для получения информации о цепочке, что создает два уязвимости:

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

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

Что касается конфиденциальности, в настоящее время единственный реальный способ - это запуск собственного полного узла. Однако с распространением L2 становится все труднее запускать полный узел, который охватывает все. Здесь эквивалент легкого клиента - это частный информационный поиск (PIR). PIR включает в себя серверы, которые хранят все копии данных, и клиентов, отправляющих зашифрованные запросы на сервер. Сервер выполняет вычисления над всеми данными и возвращает клиенту зашифрованные данные, не зная, к каким данным обращался клиент.

Для обеспечения честности сервера, каждый элемент базы данных является ветвью Меркла, и клиент может использовать легкий клиент для проверки.

PIR расчет требует больших вычислительных ресурсов. Решения включают:

• Брутфорс: алгоритмы или специализированное оборудование могут улучшить работу PIR достаточно быстро.
• Ослабление требований к конфиденциальности: например, при каждом поиске только 1 миллион "mixins".
• Многосерверный PIR: использование нескольких серверов, предполагая честность 1 из N, алгоритм PIR обычно работает быстрее.
• Анонимность, а не конфиденциальность: запросы отправляются через смешанные сети, скрывая отправителя, а не содержание. Однако это увеличивает задержку.

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

Идеальный кошелек для ключей

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