Видение идеального кошелька Ethereum: всестороннее обновление от кросс-чейн опыта до защиты конфиденциальности
Ключевым уровнем стека инфраструктуры Ethereum является Кошелек, но его часто недооценивают исследователи и разработчики ядра L1. Кошелек является окном между пользователем и миром Ethereum, и пользователи могут извлекать выгоду только из децентрализованных, устойчивых к цензуре, безопасных, конфиденциальных или других атрибутов, предлагаемых Ethereum и его приложениями, при условии, что сам Кошелек также обладает этими атрибутами.
Недавно кошельки Ethereum добились значительного прогресса в улучшении пользовательского опыта, безопасности и функциональности. Цель этой статьи — представить некоторые мнения о характеристиках, которыми должен обладать идеальный кошелек Ethereum. Это не полный список; он отражает склонности криптопанков, сосредоточенных на безопасности и конфиденциальности, и, безусловно, он неполон в отношении пользовательского опыта. Тем не менее, список желаемых функций не так эффективен в оптимизации пользовательского опыта, как простое развертывание и итерация на основе отзывов, поэтому внимание к свойствам безопасности и конфиденциальности является наиболее ценным.
Пользовательский опыт кросс-L2 транзакций
Сейчас есть все более подробная дорожная карта по улучшению кросс-чейн опыта пользователей L2, которая включает краткосрочную и долгосрочную части. Здесь будет обсуждаться краткосрочная часть: идеи, которые теоретически все еще можно реализовать даже сегодня.
Основная идея заключается в том, что (i) встроенный кросс-чейн для отправки между L2 и (ii) адресами и платежными запросами, специфичными для цепочки. Кошелек должен быть в состоянии предоставить пользователю адрес, соответствующий стилю соответствующего черновика ERC.
Когда кто-то ( или некоторые приложения ) предоставляют пользователю адрес в таком формате, пользователь должен иметь возможность вставить его в поле "Получатель" в кошельке, а затем нажать "Отправить". Кошелек должен автоматически обрабатывать отправленные данные любым возможным способом:
Если у пользователя уже есть достаточное количество необходимых типов токенов на целевой цепочке, пожалуйста, отправьте токены напрямую.
Если у пользователя есть необходимые типы токенов ( на другой цепочке или на нескольких других цепочках ), использование соответствующего протокола ( фактически является кросс-чейн DEX ) для отправки токенов.
Если у пользователя есть разные типы токенов на одной или другой цепочке, он может использовать децентрализованную биржу для их преобразования в правильные валюты нужного типа на нужной цепочке и отправки. Это должно требовать явного согласия пользователя: пользователь увидит, сколько он заплатил в виде комиссии, и сколько получил получатель.
Содержимое выше применимо к случаю "пользователь копирует и вставляет адрес ( или ENS, например, vitalik.eth @ optimism.eth), когда кто-то оплачивает пользователя". Если dapp запрашивает депозит, то идеальный процесс заключается в расширении web3 API и позволении dapp выдавать платежные запросы, специфичные для цепочки. Затем Кошелек сможет удовлетворить этот запрос любым необходимым образом. Для обеспечения хорошего пользовательского опыта также необходимо стандартизировать запрос getAvailableBalance, и Кошелек должен тщательно обдумать, на каких цепочках по умолчанию хранить активы пользователей, чтобы максимизировать безопасность и удобство перевода.
Специфические для цепи платежные запросы также могут быть помещены в QR-код, мобильный кошелек может сканировать QR-код. В сценариях потребительских платежей лицом к лицу ( или онлайн ) получатель будет генерировать QR-код или вызывать web3 API, указывая "Я хочу получить X единиц токенов YZ на цепи с идентификатором ссылки или обратным вызовом W", кошелек сможет свободно удовлетворить этот запрос любым способом. Другим вариантом является протокол claim-link, в котором кошелек пользователя генерирует QR-код или URL с авторизацией на получение, чтобы получить определенное количество средств из их цепочного контракта, задача получателя заключается в том, чтобы выяснить, как перевести эти средства на свой собственный кошелек.
Другой связанной темой является оплата gas. Если пользователь получает активы на L2, на котором у него еще нет ETH, и ему нужно отправить транзакцию на этом L2, кошелек должен автоматически использовать протокол для оплаты gas на цепочке в местах, где у пользователей есть ETH. Если кошелек хочет, чтобы пользователь в будущем проводил больше транзакций на L2, он также должен использовать только DEX для отправки, например, ETH стоимостью в миллионы gas, чтобы будущие транзакции могли напрямую тратить gas(, так как это дешевле).
Безопасность аккаунта
Одним из способов концептуализации вызова безопасности аккаунта является то, что хороший кошелек должен одновременно выполнять две функции: (i) защищать пользователей от хакерских атак или злонамеренных действий со стороны разработчиков кошельков, а также (ii) защищать пользователей от влияния их собственных ошибок.
Предпочтительным решением для этого, на протяжении более десяти лет, были социальное восстановление и мультиподписные Кошельки с градацией доступа. Учетные записи пользователей имеют два уровня ключей: главный ключ и N опекунов (, например, N = 5). Главный ключ может выполнять операции низкой стоимости и неполитические операции. Большинство опекунов требуется для выполнения (i) высокоценных операций, таких как отправка всей стоимости на счету или (ii) изменение главного ключа или любого опекуна. При необходимости, может быть разрешено выполнение высокоценных операций с помощью главного ключа через временную блокировку.
Выше представлено основное проектирование, которое можно расширить. Механизм сеансового ключа и соответствующих прав может помочь поддерживать баланс между удобством различных приложений и их безопасностью. Более сложная архитектура попечителей, например, с несколькими временными блокировками при различных порогах, может помочь максимально увеличить шансы на успешное восстановление законной учетной записи при минимизации риска кражи.
Кто или что должно быть опекуном?
Для опытных пользователей криптовалюты в сообществе опытных крипто-пользователей разумным выбором является ключи друзей и семьи пользователя. Если пользователь попросит каждого предоставить новый адрес, то никому не нужно знать, кто они – на самом деле, даже опекуны пользователя не должны знать друг о друге. Если они не донесут до пользователя информацию, вероятность их сговора очень мала. Однако для большинства новых пользователей этот вариант недоступен.
Второй вариант - это институциональные кураторы: компании, которые предоставляют услуги подписания транзакций только после получения дополнительных подтверждающих данных от пользователя, например, код подтверждения или видеозвонок для пользователей с высокой стоимостью. Люди долгое время пытались создать такие компании, например, в 2013 году был представлен CryptoCorp. Однако на данный момент эти компании еще не добились большого успеха.
Третьим вариантом являются несколько личных устройств (, таких как телефон, настольный компьютер, аппаратный кошелек ). Это может работать, но для inexperienced пользователей также сложно настроить и управлять. Существует риск одновременной потери или кражи устройств, особенно если они находятся в одном и том же месте.
Недавно мы начали наблюдать больше решений на основе универсального ключа. Ключ может быть сохранен только на устройстве пользователя, что делает его персональным решением для устройства, а также может быть сохранен в облаке, что делает его безопасность зависимой от сложной гибридной безопасности пароля, институциональных и надежных аппаратных предположений. На самом деле, ключ является ценным повышением безопасности для обычного пользователя, но полагаться только на него недостаточно для защиты сбережений пользователя на протяжении всей жизни.
К счастью, с ZK-SNARK у нас есть четвертый вариант: централизованный ID в обертке ZK. Этот тип включает zk-email, Anon Aadhaar, Myna Кошелек и так далее. По сути, пользователи могут использовать различные формы ( компании или правительства ) централизованного ID и преобразовывать их в адрес Ethereum, пользователи могут отправлять транзакции только путем генерации доказательства наличия централизованного ID с помощью ZK-SNARK.
С этим дополнением у нас теперь есть широкий выбор, и централизованный ID с ZK-упаковкой обладает уникальной "дружелюбностью к новичкам".
Для этого необходимо реализовать упрощенный и интегрированный интерфейс: пользователи должны иметь возможность просто указать, что они хотят, чтобы "example@gmail.com" был опекуном, и он должен автоматически генерировать соответствующий zk-email Эфир адрес под капотом. Продвинутые пользователи должны иметь возможность вводить свои электронные почты ( и, возможно, приватные соли, сохраненные в этой электронной почте ), в открытые сторонние приложения и подтверждать, что сгенерированный адрес правильный. Это должно быть верно и для любых других поддерживаемых типов опекунов.
Пожалуйста, обратите внимание, что сегодня zk-email сталкивается с реальной проблемой, заключающейся в том, что он зависит от подписей DKIM, которые используют ключи, меняющиеся каждые несколько месяцев, и эти ключи сами по себе не подписаны никаким другим органом. Это означает, что на сегодняшний день zk-email требует определенного уровня доверия, превышающего доверие к самому провайдеру; если zk-email использует TLSNotary для проверки обновленных ключей на доверенном оборудовании, это может уменьшить эту проблему, но это не идеальный вариант. Надеемся, что провайдеры электронной почты смогут начать напрямую подписывать свои DKIM ключи. Сегодня рекомендуется, чтобы опекун использовал zk-email, но большинство опекунов не рекомендуют это: хранение средств в zk-email означает, что пользователи не могут использовать средства в случае его повреждения.
Новые пользователи и Кошелек в приложении
Новые пользователи на самом деле не хотят вводить множество опекунов при первой регистрации. Поэтому кошелек должен предложить им очень простой выбор. Одним из естественных способов является использование zk-email на их адрес электронной почты, локально хранящегося на устройстве пользователя ключа (, который может быть универсальным ключом ), а также резервного ключа, хранящегося у провайдера, для выбора 2 из 3. По мере того как пользователи становятся более опытными или накапливают больше активов, в какой-то момент их следует попросить добавить больше опекунов.
Интеграция Кошелька в приложения неизбежна, поскольку приложения, пытающиеся привлечь пользователей, не желают, чтобы пользователи одновременно загружали два новых приложения (, само приложение и Кошелек Эфир ), что приводит к запутанному пользовательскому опыту. Тем не менее, пользователи многих приложений-кошельков должны иметь возможность связывать все свои кошельки вместе, чтобы им нужно было беспокоиться только об одной "проблеме контроля доступа". Самый простой способ - использовать иерархическую схему, в которой есть быстрый процесс "связи", позволяющий пользователям установить свой основной кошелек в качестве опекуна для всех внутренних кошельков приложений. Некоторые клиенты уже поддерживают это.
По умолчанию восстановление некоторых внутренних учетных записей пользователя может контролироваться командой разработчиков приложения. Однако пользователь может "взять на себя" учетную запись пользователя и изменить восстановление на свой собственный адрес.
Защита пользователей от мошенничества и других внешних угроз
Помимо безопасности аккаунта, современные Кошельки также выполняют много работы по выявлению ложных адресов, фишинга, мошенничества и других внешних угроз, стараясь защитить пользователей от таких угроз. В то же время многие меры все еще довольно примитивны: например, требуется клик, чтобы отправить Эфир или другие токены на любой новый адрес, независимо от того, отправляет ли пользователь 100 долларов или
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
13 Лайков
Награда
13
6
Поделиться
комментарий
0/400
HackerWhoCares
· 07-28 09:01
Безопасность и опыт должны быть на первом месте.
Посмотреть ОригиналОтветить0
BoredWatcher
· 07-28 08:33
Кошелек давно нужно было обновить!
Посмотреть ОригиналОтветить0
TokenUnlocker
· 07-25 09:53
Кошелек – это первая производительная сила!
Посмотреть ОригиналОтветить0
BottomMisser
· 07-25 09:53
Безопасность? Итерационные обновления? Сначала не позволяйте Кошельку быть украденным.
Идеальный кошелек Ethereum: полное обновление кросс-чейн опыта, безопасности и конфиденциальности
Видение идеального кошелька Ethereum: всестороннее обновление от кросс-чейн опыта до защиты конфиденциальности
Ключевым уровнем стека инфраструктуры Ethereum является Кошелек, но его часто недооценивают исследователи и разработчики ядра L1. Кошелек является окном между пользователем и миром Ethereum, и пользователи могут извлекать выгоду только из децентрализованных, устойчивых к цензуре, безопасных, конфиденциальных или других атрибутов, предлагаемых Ethereum и его приложениями, при условии, что сам Кошелек также обладает этими атрибутами.
Недавно кошельки Ethereum добились значительного прогресса в улучшении пользовательского опыта, безопасности и функциональности. Цель этой статьи — представить некоторые мнения о характеристиках, которыми должен обладать идеальный кошелек Ethereum. Это не полный список; он отражает склонности криптопанков, сосредоточенных на безопасности и конфиденциальности, и, безусловно, он неполон в отношении пользовательского опыта. Тем не менее, список желаемых функций не так эффективен в оптимизации пользовательского опыта, как простое развертывание и итерация на основе отзывов, поэтому внимание к свойствам безопасности и конфиденциальности является наиболее ценным.
Пользовательский опыт кросс-L2 транзакций
Сейчас есть все более подробная дорожная карта по улучшению кросс-чейн опыта пользователей L2, которая включает краткосрочную и долгосрочную части. Здесь будет обсуждаться краткосрочная часть: идеи, которые теоретически все еще можно реализовать даже сегодня.
Основная идея заключается в том, что (i) встроенный кросс-чейн для отправки между L2 и (ii) адресами и платежными запросами, специфичными для цепочки. Кошелек должен быть в состоянии предоставить пользователю адрес, соответствующий стилю соответствующего черновика ERC.
Когда кто-то ( или некоторые приложения ) предоставляют пользователю адрес в таком формате, пользователь должен иметь возможность вставить его в поле "Получатель" в кошельке, а затем нажать "Отправить". Кошелек должен автоматически обрабатывать отправленные данные любым возможным способом:
Содержимое выше применимо к случаю "пользователь копирует и вставляет адрес ( или ENS, например, vitalik.eth @ optimism.eth), когда кто-то оплачивает пользователя". Если dapp запрашивает депозит, то идеальный процесс заключается в расширении web3 API и позволении dapp выдавать платежные запросы, специфичные для цепочки. Затем Кошелек сможет удовлетворить этот запрос любым необходимым образом. Для обеспечения хорошего пользовательского опыта также необходимо стандартизировать запрос getAvailableBalance, и Кошелек должен тщательно обдумать, на каких цепочках по умолчанию хранить активы пользователей, чтобы максимизировать безопасность и удобство перевода.
Специфические для цепи платежные запросы также могут быть помещены в QR-код, мобильный кошелек может сканировать QR-код. В сценариях потребительских платежей лицом к лицу ( или онлайн ) получатель будет генерировать QR-код или вызывать web3 API, указывая "Я хочу получить X единиц токенов YZ на цепи с идентификатором ссылки или обратным вызовом W", кошелек сможет свободно удовлетворить этот запрос любым способом. Другим вариантом является протокол claim-link, в котором кошелек пользователя генерирует QR-код или URL с авторизацией на получение, чтобы получить определенное количество средств из их цепочного контракта, задача получателя заключается в том, чтобы выяснить, как перевести эти средства на свой собственный кошелек.
Другой связанной темой является оплата gas. Если пользователь получает активы на L2, на котором у него еще нет ETH, и ему нужно отправить транзакцию на этом L2, кошелек должен автоматически использовать протокол для оплаты gas на цепочке в местах, где у пользователей есть ETH. Если кошелек хочет, чтобы пользователь в будущем проводил больше транзакций на L2, он также должен использовать только DEX для отправки, например, ETH стоимостью в миллионы gas, чтобы будущие транзакции могли напрямую тратить gas(, так как это дешевле).
Безопасность аккаунта
Одним из способов концептуализации вызова безопасности аккаунта является то, что хороший кошелек должен одновременно выполнять две функции: (i) защищать пользователей от хакерских атак или злонамеренных действий со стороны разработчиков кошельков, а также (ii) защищать пользователей от влияния их собственных ошибок.
Предпочтительным решением для этого, на протяжении более десяти лет, были социальное восстановление и мультиподписные Кошельки с градацией доступа. Учетные записи пользователей имеют два уровня ключей: главный ключ и N опекунов (, например, N = 5). Главный ключ может выполнять операции низкой стоимости и неполитические операции. Большинство опекунов требуется для выполнения (i) высокоценных операций, таких как отправка всей стоимости на счету или (ii) изменение главного ключа или любого опекуна. При необходимости, может быть разрешено выполнение высокоценных операций с помощью главного ключа через временную блокировку.
Выше представлено основное проектирование, которое можно расширить. Механизм сеансового ключа и соответствующих прав может помочь поддерживать баланс между удобством различных приложений и их безопасностью. Более сложная архитектура попечителей, например, с несколькими временными блокировками при различных порогах, может помочь максимально увеличить шансы на успешное восстановление законной учетной записи при минимизации риска кражи.
Кто или что должно быть опекуном?
Для опытных пользователей криптовалюты в сообществе опытных крипто-пользователей разумным выбором является ключи друзей и семьи пользователя. Если пользователь попросит каждого предоставить новый адрес, то никому не нужно знать, кто они – на самом деле, даже опекуны пользователя не должны знать друг о друге. Если они не донесут до пользователя информацию, вероятность их сговора очень мала. Однако для большинства новых пользователей этот вариант недоступен.
Второй вариант - это институциональные кураторы: компании, которые предоставляют услуги подписания транзакций только после получения дополнительных подтверждающих данных от пользователя, например, код подтверждения или видеозвонок для пользователей с высокой стоимостью. Люди долгое время пытались создать такие компании, например, в 2013 году был представлен CryptoCorp. Однако на данный момент эти компании еще не добились большого успеха.
Третьим вариантом являются несколько личных устройств (, таких как телефон, настольный компьютер, аппаратный кошелек ). Это может работать, но для inexperienced пользователей также сложно настроить и управлять. Существует риск одновременной потери или кражи устройств, особенно если они находятся в одном и том же месте.
Недавно мы начали наблюдать больше решений на основе универсального ключа. Ключ может быть сохранен только на устройстве пользователя, что делает его персональным решением для устройства, а также может быть сохранен в облаке, что делает его безопасность зависимой от сложной гибридной безопасности пароля, институциональных и надежных аппаратных предположений. На самом деле, ключ является ценным повышением безопасности для обычного пользователя, но полагаться только на него недостаточно для защиты сбережений пользователя на протяжении всей жизни.
К счастью, с ZK-SNARK у нас есть четвертый вариант: централизованный ID в обертке ZK. Этот тип включает zk-email, Anon Aadhaar, Myna Кошелек и так далее. По сути, пользователи могут использовать различные формы ( компании или правительства ) централизованного ID и преобразовывать их в адрес Ethereum, пользователи могут отправлять транзакции только путем генерации доказательства наличия централизованного ID с помощью ZK-SNARK.
С этим дополнением у нас теперь есть широкий выбор, и централизованный ID с ZK-упаковкой обладает уникальной "дружелюбностью к новичкам".
Для этого необходимо реализовать упрощенный и интегрированный интерфейс: пользователи должны иметь возможность просто указать, что они хотят, чтобы "example@gmail.com" был опекуном, и он должен автоматически генерировать соответствующий zk-email Эфир адрес под капотом. Продвинутые пользователи должны иметь возможность вводить свои электронные почты ( и, возможно, приватные соли, сохраненные в этой электронной почте ), в открытые сторонние приложения и подтверждать, что сгенерированный адрес правильный. Это должно быть верно и для любых других поддерживаемых типов опекунов.
Пожалуйста, обратите внимание, что сегодня zk-email сталкивается с реальной проблемой, заключающейся в том, что он зависит от подписей DKIM, которые используют ключи, меняющиеся каждые несколько месяцев, и эти ключи сами по себе не подписаны никаким другим органом. Это означает, что на сегодняшний день zk-email требует определенного уровня доверия, превышающего доверие к самому провайдеру; если zk-email использует TLSNotary для проверки обновленных ключей на доверенном оборудовании, это может уменьшить эту проблему, но это не идеальный вариант. Надеемся, что провайдеры электронной почты смогут начать напрямую подписывать свои DKIM ключи. Сегодня рекомендуется, чтобы опекун использовал zk-email, но большинство опекунов не рекомендуют это: хранение средств в zk-email означает, что пользователи не могут использовать средства в случае его повреждения.
Новые пользователи и Кошелек в приложении
Новые пользователи на самом деле не хотят вводить множество опекунов при первой регистрации. Поэтому кошелек должен предложить им очень простой выбор. Одним из естественных способов является использование zk-email на их адрес электронной почты, локально хранящегося на устройстве пользователя ключа (, который может быть универсальным ключом ), а также резервного ключа, хранящегося у провайдера, для выбора 2 из 3. По мере того как пользователи становятся более опытными или накапливают больше активов, в какой-то момент их следует попросить добавить больше опекунов.
Интеграция Кошелька в приложения неизбежна, поскольку приложения, пытающиеся привлечь пользователей, не желают, чтобы пользователи одновременно загружали два новых приложения (, само приложение и Кошелек Эфир ), что приводит к запутанному пользовательскому опыту. Тем не менее, пользователи многих приложений-кошельков должны иметь возможность связывать все свои кошельки вместе, чтобы им нужно было беспокоиться только об одной "проблеме контроля доступа". Самый простой способ - использовать иерархическую схему, в которой есть быстрый процесс "связи", позволяющий пользователям установить свой основной кошелек в качестве опекуна для всех внутренних кошельков приложений. Некоторые клиенты уже поддерживают это.
По умолчанию восстановление некоторых внутренних учетных записей пользователя может контролироваться командой разработчиков приложения. Однако пользователь может "взять на себя" учетную запись пользователя и изменить восстановление на свой собственный адрес.
Защита пользователей от мошенничества и других внешних угроз
Помимо безопасности аккаунта, современные Кошельки также выполняют много работы по выявлению ложных адресов, фишинга, мошенничества и других внешних угроз, стараясь защитить пользователей от таких угроз. В то же время многие меры все еще довольно примитивны: например, требуется клик, чтобы отправить Эфир или другие токены на любой новый адрес, независимо от того, отправляет ли пользователь 100 долларов или