Видение идеального кошелька Ethereum: всестороннее обновление от кросс-чейн опыта до защиты конфиденциальности
Слой Кошелька в инфраструктуре Ethereum имеет решающее значение, но часто недооценивается исследователями и разработчиками основного L1. Кошелек является окном, через которое пользователи взаимодействуют с миром Ethereum, и только когда сам Кошелек обладает соответствующими характеристиками, пользователи могут по-настоящему воспользоваться децентрализованностью, устойчивостью к цензуре, безопасностью и конфиденциальностью, которые предоставляют Ethereum и его приложения.
Недавно кошельки Ethereum добились значительного прогресса в улучшении пользовательского опыта, безопасности и функциональности. Эта статья направлена на изложение некоторых характеристик, которыми должен обладать идеальный кошелек Ethereum. Это не полный список, а скорее отражение криптопанк-склонностей автора, акцентирующего внимание на безопасности и конфиденциальности, что может привести к недостаткам в пользовательском опыте. Однако, в отличие от простого развертывания и итерации на основе отзывов, список желаемого может быть менее эффективным в оптимизации пользовательского опыта, поэтому фокусировка на свойствах безопасности и конфиденциальности может быть более ценной.
Пользовательский опыт кросс-L2 транзакций
Дорожная карта по улучшению пользовательского опыта при переходе между L2 становится все более ясной, включая краткосрочную и долгосрочную части. В этой статье будут обсуждены идеи, которые можно реализовать в краткосрочной перспективе.
Основная идея заключается в том, что: ( встроенная функция отправки через кросс-чейн L2, ) адреса конкретной цепи и запросы на оплату. Кошелек должен предоставлять пользователям адрес, соответствующий определенному стилю проекта ERC.
Когда пользователь получает адрес в таком формате, он может вставить его в поле "Получатель" кошелька и нажать "Отправить". Кошелек должен автоматически обработать процесс отправки:
Если на целевой цепи уже достаточно необходимых токенов, отправьте напрямую
Если на других цепях есть необходимые токены, используйте кросс-чейн DEX протокол, подобный ERC-7683, для отправки
Если на одной или другой цепочке есть токены разных типов, используйте DEX для преобразования в правильный тип и отправки, требуется явное разрешение пользователя.
Это относится к сценарию "копировать и вставить адрес для платежа". В случае запроса dapp на депозит, идеальная практика заключается в расширении web3 API, позволяя dapp отправлять специфические для цепочки запросы на платеж. Кошелек может гибко удовлетворять этот запрос. Для обеспечения хорошего пользовательского опыта также необходимо стандартизировать запрос getAvailableBalance, кошелек должен серьезно рассмотреть, на каких цепочках по умолчанию хранятся активы пользователей, чтобы сбалансировать безопасность и удобство перевода.
Запросы на оплату, специфичные для блокчейна, также могут быть помещены в QR-код для сканирования мобильным кошельком. В сценариях оплаты лицом к лицу или онлайн, получатель может выдать QR-код или веб-API вызов с сообщением "Мне нужно Y единиц токена Z на блокчейне X, идентификатор ссылки W", кошелек может гибко удовлетворить этот запрос. Другой вариант - протокол ссылки на претензию, кошелек пользователя генерирует QR-код или URL, содержащий авторизацию на претензию, получатель отвечает за перевод средств на свой кошелек.
Другой связанной темой является оплата газа. Если пользователь получает активы на L2 без ETH и нуждается в отправке транзакции, Кошелек должен автоматически использовать протокол (, такой как RIP-7755), для оплаты газа с других цепочек, где есть ETH. Если Кошелек предполагает, что пользователь будет совершать больше транзакций на этой L2 в будущем, он также может использовать DEX для отправки достаточного количества ETH, чтобы покрыть сотни оплат газа, чтобы будущие транзакции могли напрямую оплачивать газ на L2, поскольку это дешевле (.
![Vitalik новая статья: Видение идеального Кошелька, всеобъемлющее обновление от кросс-чейн опыта до защиты конфиденциальности])https://img-cdn.gateio.im/webp-social/moments-e340d9eff581bff30a541c8aac3178af.webp(
Безопасность аккаунта
Хороший концептуальный подход к безопасности аккаунта заключается в том, что отличный Кошелек должен выполнять две функции: )1( защищать пользователей от хакерских атак или злонамеренных действий со стороны разработчиков Кошелька, )2( защищать пользователей от последствий собственных ошибок.
Предпочтительным решением является социальное восстановление и мультиподписной кошелек с многоуровневым контролем доступа. Учетные записи пользователей имеют два уровня ключей: основной ключ и N опекунов ), где N=5(. Основной ключ может использоваться для операций низкой стоимости и не финансовых операций. Для выполнения необходимых операций требуется большинство опекунов:)1( для операций высокой стоимости, таких как отправка всех средств со счета, )2( изменение основного ключа или любого опекуна. При необходимости основной ключ может выполнять операции высокой стоимости через тайм-лок.
Это базовый дизайн, который можно расширять. Механизмы прав, такие как сеансовый ключ и ERC-7715, могут помочь сбалансировать удобство и безопасность между различными приложениями. Более сложная архитектура опекунов, такая как наличие нескольких периодов блокировки времени при различных порогах, может максимизировать шансы успешного восстановления законного аккаунта, одновременно минимизируя риск кражи.
![Vitalik новая статья: Видение идеального Кошелька, полное обновление от кросс-чейн опыта до защиты конфиденциальности])https://img-cdn.gateio.im/webp-social/moments-66ec52b10d00460414381b99c15622ee.webp(
) Выбор опекуна
Для опытных пользователей в крипто-сообществе можно выбрать ключи друзей и семьи в качестве опекунов. Если требуется, чтобы каждый предоставил новый адрес, даже не нужно знать личность друг друга. Однако это не применимо для большинства новых пользователей.
Второй вариант — это институциональный куратор: специальная служба, которая подписывает транзакции только после получения дополнительной подтверждающей информации по запросу пользователя, такой как код подтверждения или видеозвонок с пользователем высокой ценности (. Несмотря на то, что на протяжении долгого времени предпринимались попытки создать такие услуги, на данный момент они не очень успешны.
Третьим вариантом являются несколько персональных устройств ), таких как смартфоны, настольные ПК, аппаратные кошельки ###. Это возможно, но новички могут испытывать трудности с настройкой и управлением. Существует также риск одновременной потери или кражи устройств, особенно если они находятся в одном месте.
Недавно мы начали видеть больше решений на основе универсальных ключей. Ключи могут быть просто скопированы на устройство, становясь личным устройством, или могут быть сохранены в облаке, безопасность которых зависит от сложного смешанного криптографического обеспечения, предположений о институтах и доверенном аппаратном обеспечении. Хотя это представляет собой ценное увеличение безопасности для среднестатистического пользователя, их недостаточно для защиты накоплений пользователей на протяжении всей жизни.
К счастью, с ZK-SNARK у нас есть четвертый вариант: централизованный ID на основе ZK. Этот тип включает в себя zk-email, Anon Aadhaar, Myna Wallet и т.д. В основном, можно использовать различные формы ( компании или правительства ) централизованного ID и преобразовать их в адрес Ethereum, пользователи могут отправлять транзакции, только генерируя доказательство ZK-SNARK с централизованным ID.
Централизованный ID в упаковке ZK обладает уникальной "дружелюбностью для новичков". Для этого необходимо реализовать упрощенный и интегрированный интерфейс: пользователю нужно просто указать желаемый "example@gmail.com" в качестве опекуна, и он должен автоматически генерировать соответствующий zk-email адрес Эфир в фоновом режиме. Продвинутые пользователи должны иметь возможность вводить свои электронные почты ( и, возможно, сохраненные значения соли конфиденциальности ) в приложения третьих сторон с открытым исходным кодом и подтверждать, что сгенерированный адрес правильный. То же самое должно относиться и к любым другим поддерживаемым типам опекунов.
Следует отметить, что в настоящее время zk-email сталкивается с одной реальной проблемой, заключающейся в том, что он зависит от подписи DKIM, которая использует ключи, меняющиеся каждые несколько месяцев, и эти ключи сами по себе не подписаны никакими другими организациями. Это означает, что на сегодняшний день zk-email в определенной степени требует доверия к самому провайдеру; если zk-email будет использовать TLSNotary для проверки обновленных ключей на доверенном оборудовании, это может уменьшить такую зависимость, но это не идеальный вариант. Надеемся, что поставщики электронной почты начнут напрямую подписывать свои DKIM ключи. В настоящее время рекомендуется использовать один zk-email в качестве опекуна, но не рекомендуется большинству опекунов: не храните средства в настройках, где повреждение zk-email означает невозможность доступа к средствам.
( Новые пользователи и кошелек внутри приложения
Новые пользователи на самом деле не хотят вводить множество опекунов при первой регистрации. Поэтому кошелек должен предложить им очень простой выбор. Естественным способом является использование zk-email на их адресе электронной почты, локально хранящийся на устройстве пользователя ключ ), который может быть универсальным ключом (, и резервный ключ, который хранит провайдер, для выбора 2 из 3. По мере накопления пользователем большего опыта или активов, в какой-то момент следует предложить им добавить больше опекунов.
Интеграция Кошелька в приложение неизбежна, так как приложения, пытающиеся привлечь не крипто-пользователей, не хотят, чтобы пользователи одновременно загружали два новых приложения ) само приложение плюс Эфир Кошелек ### создает путаницу в пользовательском опыте. Тем не менее, многие пользователи внутренних кошельков должны иметь возможность связать все кошельки вместе, так что нужно сосредоточиться только на одной "проблеме контроля доступа". Наиболее простой способ - использовать иерархическую схему, через быстрый процесс "ссылки", позволяющий пользователям установить основной кошелек в качестве опекуна для всех внутренних кошельков.
( Защита пользователей от мошенничества и других внешних угроз
Помимо безопасности аккаунта, современные кошельки также выполняют множество задач по выявлению поддельных адресов, фишинга, мошенничества и других внешних угроз, стараясь защитить пользователей. В то же время многие меры все еще довольно примитивны: например, требуется кликнуть, чтобы отправить ETH или другие токены на любой новый адрес, независимо от суммы отправления. Здесь нет единственного панацеи, а есть ряд постоянных улучшений, направленных на разные категории угроз. Продолжение работы над улучшением в этой области имеет большую ценность.
![Vitalik новая статья: Видение идеального кошелька, всеобъемлющее обновление от кросс-чейн опыта до защиты конфиденциальности])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(
Приватность
Теперь пришло время серьезнее относиться к приватности Ethereum. Технология ZK-SNARK уже очень развита, не полагается на бэкдоры для снижения регуляторных рисков, такие как приватные пулы ) становятся все более зрелыми, а вторичная инфраструктура, такая как Waku и мемпулы ERC-4337, также медленно становятся более стабильными. Однако в настоящее время для осуществления частных переводов на Ethereum пользователям необходимо явно загружать и использовать "Кошелек". Это создает огромное неудобство и снижает количество желающих проводить частные переводы. Решением будет интеграция частных переводов непосредственно в кошелек.
Простая реализация выглядит следующим образом. Кошелек может хранить часть активов пользователя в "приватном балансе" в пуле конфиденциальности. Когда пользователь совершает перевод, он сначала автоматически выходит из пула конфиденциальности. Если пользователю нужно получить средства, кошелек может автоматически сгенерировать невидимый адрес.
Кроме того, Кошелек может автоматически генерировать новый адрес для каждого приложения, в котором участвует пользователь ###, например, для протоколов defi (. Депозиты будут поступать из пула конфиденциальности, а вывод средств будет осуществляться напрямую в пул конфиденциальности. Это позволяет пользователям разъединять свои действия в одном приложении от действий в других приложениях.
Эта технология не только является естественным способом защиты передачи приватных активов, но и естественным способом защиты приватной идентичности. Идентичность уже существует в цепочке: любое приложение с контролем идентификации ), такое как Gitcoin Grants (, любой токен-контролируемый чат, протоколы, соответствующие Ethereum, и т. д., являются идентичностью в цепочке. Мы надеемся, что эта экосистема также сможет защитить приватность. Это означает, что активность пользователей в цепочке не должна собираться в одном месте: каждый проект должен храниться отдельно, а кошелек пользователя должен быть единственным, кто имеет "глобальный обзор", чтобы видеть все доказательства одновременно. Нативная экосистема, в которой каждый пользователь имеет несколько учетных записей, способствует достижению этой цели, как и такие протоколы, как EAS и Zupass.
Это представляет собой прагматичное видение конфиденциальности Ethereum в среднесрочной перспективе. Хотя некоторые функции можно ввести на L1 и L2 для повышения эффективности и надежности передачи конфиденциальности, это уже можно реализовать сейчас. Некоторые защитники конфиденциальности считают, что единственным приемлемым вариантом является полная конфиденциальность всего: шифрование всего EVM. Это может быть идеальным долгосрочным результатом, но это требует более фундаментального переосмысления программной модели.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
15 Лайков
Награда
15
7
Поделиться
комментарий
0/400
APY追逐者
· 5ч назад
Децентрализация и что с того, все равно это те же старые проблемы.
Посмотреть ОригиналОтветить0
MultiSigFailMaster
· 07-16 22:49
Давайте, мне нравится такой подход, когда все начинается с самого низа.
Посмотреть ОригиналОтветить0
gas_guzzler
· 07-16 22:47
Кошелек есть кошелек, зачем столько лишних наворотов?
Посмотреть ОригиналОтветить0
DarkPoolWatcher
· 07-16 22:40
Безопасность - это главное, все остальное - пустое.
Посмотреть ОригиналОтветить0
BlockchainFoodie
· 07-16 22:40
точно так же, как идеально слоеный милле-фей, каждая функция кошелька добавляет глубину безопасности... восхитительно.
Посмотреть ОригиналОтветить0
FromMinerToFarmer
· 07-16 22:39
Старый майнер больше не притворяется, давайте начинать!
Посмотреть ОригиналОтветить0
GateUser-e87b21ee
· 07-16 22:36
Невероятно, что кто-то действительно исследует Кошелек??
Идеальный кошелек Ethereum: всеобъемлющее обновление от кросс-чейн до конфиденциальности
Видение идеального кошелька Ethereum: всестороннее обновление от кросс-чейн опыта до защиты конфиденциальности
Слой Кошелька в инфраструктуре Ethereum имеет решающее значение, но часто недооценивается исследователями и разработчиками основного L1. Кошелек является окном, через которое пользователи взаимодействуют с миром Ethereum, и только когда сам Кошелек обладает соответствующими характеристиками, пользователи могут по-настоящему воспользоваться децентрализованностью, устойчивостью к цензуре, безопасностью и конфиденциальностью, которые предоставляют Ethereum и его приложения.
Недавно кошельки Ethereum добились значительного прогресса в улучшении пользовательского опыта, безопасности и функциональности. Эта статья направлена на изложение некоторых характеристик, которыми должен обладать идеальный кошелек Ethereum. Это не полный список, а скорее отражение криптопанк-склонностей автора, акцентирующего внимание на безопасности и конфиденциальности, что может привести к недостаткам в пользовательском опыте. Однако, в отличие от простого развертывания и итерации на основе отзывов, список желаемого может быть менее эффективным в оптимизации пользовательского опыта, поэтому фокусировка на свойствах безопасности и конфиденциальности может быть более ценной.
Пользовательский опыт кросс-L2 транзакций
Дорожная карта по улучшению пользовательского опыта при переходе между L2 становится все более ясной, включая краткосрочную и долгосрочную части. В этой статье будут обсуждены идеи, которые можно реализовать в краткосрочной перспективе.
Основная идея заключается в том, что: ( встроенная функция отправки через кросс-чейн L2, ) адреса конкретной цепи и запросы на оплату. Кошелек должен предоставлять пользователям адрес, соответствующий определенному стилю проекта ERC.
Когда пользователь получает адрес в таком формате, он может вставить его в поле "Получатель" кошелька и нажать "Отправить". Кошелек должен автоматически обработать процесс отправки:
Это относится к сценарию "копировать и вставить адрес для платежа". В случае запроса dapp на депозит, идеальная практика заключается в расширении web3 API, позволяя dapp отправлять специфические для цепочки запросы на платеж. Кошелек может гибко удовлетворять этот запрос. Для обеспечения хорошего пользовательского опыта также необходимо стандартизировать запрос getAvailableBalance, кошелек должен серьезно рассмотреть, на каких цепочках по умолчанию хранятся активы пользователей, чтобы сбалансировать безопасность и удобство перевода.
Запросы на оплату, специфичные для блокчейна, также могут быть помещены в QR-код для сканирования мобильным кошельком. В сценариях оплаты лицом к лицу или онлайн, получатель может выдать QR-код или веб-API вызов с сообщением "Мне нужно Y единиц токена Z на блокчейне X, идентификатор ссылки W", кошелек может гибко удовлетворить этот запрос. Другой вариант - протокол ссылки на претензию, кошелек пользователя генерирует QR-код или URL, содержащий авторизацию на претензию, получатель отвечает за перевод средств на свой кошелек.
Другой связанной темой является оплата газа. Если пользователь получает активы на L2 без ETH и нуждается в отправке транзакции, Кошелек должен автоматически использовать протокол (, такой как RIP-7755), для оплаты газа с других цепочек, где есть ETH. Если Кошелек предполагает, что пользователь будет совершать больше транзакций на этой L2 в будущем, он также может использовать DEX для отправки достаточного количества ETH, чтобы покрыть сотни оплат газа, чтобы будущие транзакции могли напрямую оплачивать газ на L2, поскольку это дешевле (.
![Vitalik новая статья: Видение идеального Кошелька, всеобъемлющее обновление от кросс-чейн опыта до защиты конфиденциальности])https://img-cdn.gateio.im/webp-social/moments-e340d9eff581bff30a541c8aac3178af.webp(
Безопасность аккаунта
Хороший концептуальный подход к безопасности аккаунта заключается в том, что отличный Кошелек должен выполнять две функции: )1( защищать пользователей от хакерских атак или злонамеренных действий со стороны разработчиков Кошелька, )2( защищать пользователей от последствий собственных ошибок.
Предпочтительным решением является социальное восстановление и мультиподписной кошелек с многоуровневым контролем доступа. Учетные записи пользователей имеют два уровня ключей: основной ключ и N опекунов ), где N=5(. Основной ключ может использоваться для операций низкой стоимости и не финансовых операций. Для выполнения необходимых операций требуется большинство опекунов:)1( для операций высокой стоимости, таких как отправка всех средств со счета, )2( изменение основного ключа или любого опекуна. При необходимости основной ключ может выполнять операции высокой стоимости через тайм-лок.
Это базовый дизайн, который можно расширять. Механизмы прав, такие как сеансовый ключ и ERC-7715, могут помочь сбалансировать удобство и безопасность между различными приложениями. Более сложная архитектура опекунов, такая как наличие нескольких периодов блокировки времени при различных порогах, может максимизировать шансы успешного восстановления законного аккаунта, одновременно минимизируя риск кражи.
![Vitalik новая статья: Видение идеального Кошелька, полное обновление от кросс-чейн опыта до защиты конфиденциальности])https://img-cdn.gateio.im/webp-social/moments-66ec52b10d00460414381b99c15622ee.webp(
) Выбор опекуна
Для опытных пользователей в крипто-сообществе можно выбрать ключи друзей и семьи в качестве опекунов. Если требуется, чтобы каждый предоставил новый адрес, даже не нужно знать личность друг друга. Однако это не применимо для большинства новых пользователей.
Второй вариант — это институциональный куратор: специальная служба, которая подписывает транзакции только после получения дополнительной подтверждающей информации по запросу пользователя, такой как код подтверждения или видеозвонок с пользователем высокой ценности (. Несмотря на то, что на протяжении долгого времени предпринимались попытки создать такие услуги, на данный момент они не очень успешны.
Третьим вариантом являются несколько персональных устройств ), таких как смартфоны, настольные ПК, аппаратные кошельки ###. Это возможно, но новички могут испытывать трудности с настройкой и управлением. Существует также риск одновременной потери или кражи устройств, особенно если они находятся в одном месте.
Недавно мы начали видеть больше решений на основе универсальных ключей. Ключи могут быть просто скопированы на устройство, становясь личным устройством, или могут быть сохранены в облаке, безопасность которых зависит от сложного смешанного криптографического обеспечения, предположений о институтах и доверенном аппаратном обеспечении. Хотя это представляет собой ценное увеличение безопасности для среднестатистического пользователя, их недостаточно для защиты накоплений пользователей на протяжении всей жизни.
К счастью, с ZK-SNARK у нас есть четвертый вариант: централизованный ID на основе ZK. Этот тип включает в себя zk-email, Anon Aadhaar, Myna Wallet и т.д. В основном, можно использовать различные формы ( компании или правительства ) централизованного ID и преобразовать их в адрес Ethereum, пользователи могут отправлять транзакции, только генерируя доказательство ZK-SNARK с централизованным ID.
Централизованный ID в упаковке ZK обладает уникальной "дружелюбностью для новичков". Для этого необходимо реализовать упрощенный и интегрированный интерфейс: пользователю нужно просто указать желаемый "example@gmail.com" в качестве опекуна, и он должен автоматически генерировать соответствующий zk-email адрес Эфир в фоновом режиме. Продвинутые пользователи должны иметь возможность вводить свои электронные почты ( и, возможно, сохраненные значения соли конфиденциальности ) в приложения третьих сторон с открытым исходным кодом и подтверждать, что сгенерированный адрес правильный. То же самое должно относиться и к любым другим поддерживаемым типам опекунов.
Следует отметить, что в настоящее время zk-email сталкивается с одной реальной проблемой, заключающейся в том, что он зависит от подписи DKIM, которая использует ключи, меняющиеся каждые несколько месяцев, и эти ключи сами по себе не подписаны никакими другими организациями. Это означает, что на сегодняшний день zk-email в определенной степени требует доверия к самому провайдеру; если zk-email будет использовать TLSNotary для проверки обновленных ключей на доверенном оборудовании, это может уменьшить такую зависимость, но это не идеальный вариант. Надеемся, что поставщики электронной почты начнут напрямую подписывать свои DKIM ключи. В настоящее время рекомендуется использовать один zk-email в качестве опекуна, но не рекомендуется большинству опекунов: не храните средства в настройках, где повреждение zk-email означает невозможность доступа к средствам.
( Новые пользователи и кошелек внутри приложения
Новые пользователи на самом деле не хотят вводить множество опекунов при первой регистрации. Поэтому кошелек должен предложить им очень простой выбор. Естественным способом является использование zk-email на их адресе электронной почты, локально хранящийся на устройстве пользователя ключ ), который может быть универсальным ключом (, и резервный ключ, который хранит провайдер, для выбора 2 из 3. По мере накопления пользователем большего опыта или активов, в какой-то момент следует предложить им добавить больше опекунов.
Интеграция Кошелька в приложение неизбежна, так как приложения, пытающиеся привлечь не крипто-пользователей, не хотят, чтобы пользователи одновременно загружали два новых приложения ) само приложение плюс Эфир Кошелек ### создает путаницу в пользовательском опыте. Тем не менее, многие пользователи внутренних кошельков должны иметь возможность связать все кошельки вместе, так что нужно сосредоточиться только на одной "проблеме контроля доступа". Наиболее простой способ - использовать иерархическую схему, через быстрый процесс "ссылки", позволяющий пользователям установить основной кошелек в качестве опекуна для всех внутренних кошельков.
( Защита пользователей от мошенничества и других внешних угроз
Помимо безопасности аккаунта, современные кошельки также выполняют множество задач по выявлению поддельных адресов, фишинга, мошенничества и других внешних угроз, стараясь защитить пользователей. В то же время многие меры все еще довольно примитивны: например, требуется кликнуть, чтобы отправить ETH или другие токены на любой новый адрес, независимо от суммы отправления. Здесь нет единственного панацеи, а есть ряд постоянных улучшений, направленных на разные категории угроз. Продолжение работы над улучшением в этой области имеет большую ценность.
![Vitalik новая статья: Видение идеального кошелька, всеобъемлющее обновление от кросс-чейн опыта до защиты конфиденциальности])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(
Приватность
Теперь пришло время серьезнее относиться к приватности Ethereum. Технология ZK-SNARK уже очень развита, не полагается на бэкдоры для снижения регуляторных рисков, такие как приватные пулы ) становятся все более зрелыми, а вторичная инфраструктура, такая как Waku и мемпулы ERC-4337, также медленно становятся более стабильными. Однако в настоящее время для осуществления частных переводов на Ethereum пользователям необходимо явно загружать и использовать "Кошелек". Это создает огромное неудобство и снижает количество желающих проводить частные переводы. Решением будет интеграция частных переводов непосредственно в кошелек.
Простая реализация выглядит следующим образом. Кошелек может хранить часть активов пользователя в "приватном балансе" в пуле конфиденциальности. Когда пользователь совершает перевод, он сначала автоматически выходит из пула конфиденциальности. Если пользователю нужно получить средства, кошелек может автоматически сгенерировать невидимый адрес.
Кроме того, Кошелек может автоматически генерировать новый адрес для каждого приложения, в котором участвует пользователь ###, например, для протоколов defi (. Депозиты будут поступать из пула конфиденциальности, а вывод средств будет осуществляться напрямую в пул конфиденциальности. Это позволяет пользователям разъединять свои действия в одном приложении от действий в других приложениях.
Эта технология не только является естественным способом защиты передачи приватных активов, но и естественным способом защиты приватной идентичности. Идентичность уже существует в цепочке: любое приложение с контролем идентификации ), такое как Gitcoin Grants (, любой токен-контролируемый чат, протоколы, соответствующие Ethereum, и т. д., являются идентичностью в цепочке. Мы надеемся, что эта экосистема также сможет защитить приватность. Это означает, что активность пользователей в цепочке не должна собираться в одном месте: каждый проект должен храниться отдельно, а кошелек пользователя должен быть единственным, кто имеет "глобальный обзор", чтобы видеть все доказательства одновременно. Нативная экосистема, в которой каждый пользователь имеет несколько учетных записей, способствует достижению этой цели, как и такие протоколы, как EAS и Zupass.
Это представляет собой прагматичное видение конфиденциальности Ethereum в среднесрочной перспективе. Хотя некоторые функции можно ввести на L1 и L2 для повышения эффективности и надежности передачи конфиденциальности, это уже можно реализовать сейчас. Некоторые защитники конфиденциальности считают, что единственным приемлемым вариантом является полная конфиденциальность всего: шифрование всего EVM. Это может быть идеальным долгосрочным результатом, но это требует более фундаментального переосмысления программной модели.