Видение идеального Кошелька: всестороннее обновление от кросс-чейн опыта до защиты конфиденциальности
Одним из ключевых уровней инфраструктурного стека Ethereum является Кошелек, но основные исследователи и разработчики L1 часто недооценивают его важность. Кошелек является окном, через которое пользователи взаимодействуют с миром Ethereum, и пользователи могут по-настоящему извлечь выгоду из децентрализованных, антикоррупционных, безопасных и приватных характеристик Ethereum и его приложений только в том случае, если сам Кошелек обладает соответствующими атрибутами.
В последнее время кошелек Ethereum добился значительных успехов в улучшении пользовательского опыта, безопасности и функциональности. Эта статья предназначена для того, чтобы поделиться моими взглядами на идеальные характеристики кошелька Ethereum. Это не полный список, он отражает мои криптоанархистские наклонности, сосредоточенные на безопасности и конфиденциальности, что может быть недостатком в плане пользовательского опыта. Тем не менее, я считаю, что оптимизация пользовательского опыта через развертывание и итерации на основе обратной связи более эффективна, чем список желаний, поэтому я считаю, что акцент на свойствах безопасности и конфиденциальности наиболее ценен.
Пользовательский опыт кросс-чейн транзакций L2
В настоящее время существует все более完善ная дорожная карта по улучшению пользовательского опыта кросс-чейн для L2, включая краткосрочные и долгосрочные аспекты. Здесь в основном обсуждаются краткосрочные аспекты: идеи, которые теоретически можно реализовать уже сейчас.
Основная идея заключается в следующем: (i) встроенная кросс-чейн отправка L2, а также (ii) адреса и платежные запросы, специфичные для цепочки. Ваш Кошелек должен предоставить вам адрес, соответствующий стилю черновика ERC.
Когда кто-то ( или некоторые приложения ) предоставляют вам адрес в таком формате, вы должны быть в состоянии вставить его в поле "Получатель" вашего Кошелек, а затем нажать "Отправить". Кошелек должен автоматически обработать отправленные данные любым возможным способом:
Если у вас уже есть достаточное количество необходимых токенов на целевой цепи, отправьте токены напрямую.
Если у вас есть необходимые токены на другой цепи ( или на нескольких других цепях ), использование протоколов, таких как ERC-7683 (, на самом деле является кросс-чейн DEX ) для отправки токенов.
Если у вас есть токены разных типов на одной или другой цепи, используйте децентрализованный обмен, чтобы преобразовать их в правильную валюту на правильной цепи и отправить. Это должно требовать явного разрешения пользователя: пользователь увидит, сколько он заплатил, и сколько получил получатель.
Содержимое выше применимо к "Вы скопировали и вставили адрес ( или ENS, например, vitalik.eth @ optimism.eth), чтобы кто-то перевел вам деньги". Если dapp запрашивает депозит, то идеальный процесс заключается в расширении web3 API и разрешении dapp отправить платежный запрос, специфичный для цепочки. Затем ваш Кошелек сможет удовлетворить этот запрос любым необходимым образом. Чтобы обеспечить хороший пользовательский опыт, также необходимо стандартизировать запрос getAvailableBalance, и Кошелек должен серьезно обдумать, на каких цепочках по умолчанию хранить активы пользователя, чтобы максимизировать безопасность и удобство перевода.
Специфические для цепочки платежные запросы также могут быть встроены в QR-коды, мобильные кошельки могут сканировать QR-коды. В условиях лицом к лицу ( или онлайн ) сценариев платежей потребителей, получатель выдаст QR-код или вызов web3 API, указывая "Я хочу X единиц токена YZ на цепочке с референсным ID или обратным вызовом W", кошелек сможет свободно удовлетворить этот запрос любым способом. Другой вариант — это протокол ссылки на заявку, в котором кошелек пользователя генерирует QR-код или URL с авторизацией на получение, чтобы получить определенное количество средств из их контракта на цепочке, задача получателя заключается в том, чтобы выяснить, как перевести эти средства в свой собственный кошелек.
Другой связанный вопрос - это оплата Gas. Если вы получили активы на L2, где у вас нет ETH, и вам нужно отправить транзакцию на этом L2, Кошелек должен автоматически использовать протокол (, например RIP-7755), чтобы оплатить Gas в цепочке, где у вас есть ETH. Если Кошелек хочет, чтобы вы проводили больше транзакций на L2 в будущем, он также должен использовать только DEX для отправки, например ETH стоимостью в миллионы Gas, чтобы будущие транзакции могли непосредственно тратить Gas (, потому что это дешевле ).
Безопасность аккаунта
Я представляю концепцию вызовов безопасности аккаунта следующим образом: хороший Кошелек должен одновременно работать в двух направлениях: (i) защищать пользователей от хакерских атак или злонамеренных действий со стороны разработчиков кошелька, а также (ii) защищать пользователей от последствий их собственных ошибок.
Моим предпочтительным решением в течение более десяти лет является социальное восстановление и многофункциональный Кошелек с уровнем контроля доступа. Учетные записи пользователей имеют два уровня ключей: главный ключ и N кураторов (, например, N = 5). Главный ключ может выполнять операции низкой стоимости и не финансовые операции. Большинство кураторов необходимо для выполнения (i) операций высокой стоимости, таких как отправка всей стоимости на счету или (ii) изменение главного ключа или любого куратора. При необходимости, может быть разрешено, чтобы главный ключ выполнял операции высокой стоимости через временную блокировку.
Выше представлено базовое проектирование, которое можно расширить. Механизмы управления доступом, такие как сеансовый ключ и ERC-7715, могут помочь поддерживать различный баланс между удобством различных приложений и безопасностью. Более сложная архитектура опекунов, например, с несколькими временными блокировками на разных порогах, может помочь максимизировать шансы успешного восстановления легитимных аккаунтов, одновременно минимизируя риск кражи.
Кто или что должен быть опекуном?
Для опытных пользователей криптовалют в сообществе опытных крипто-юзеров жизнеспособным вариантом являются ключи ваших друзей и семьи. Если вы попросите каждого предоставить вам новый адрес, то никто не должен знать, кто они - на самом деле, ваши опекуны даже не должны знать друг о друге. Если они не сообщат вам, вероятность их сговора невелика. Однако для большинства новых пользователей этот вариант недоступен.
Второй вариант - это институциональный куратор: компании, которые предоставляют услуги по подписанию транзакций только после получения от вас дополнительной подтверждающей информации, например, кодов подтверждения или видеозвонков для пользователей с высокой ценностью. Люди долгое время пытались создать такие компании, например, я представил CryptoCorp в 2013 году. Однако на данный момент эти компании еще не очень успешны.
Третий вариант — это несколько личных устройств (, таких как телефон, настольный компьютер, аппаратный Кошелек ). Это может работать, но для неопытных пользователей также сложно настроить и управлять. Существует также риск одновременной потери или кражи устройств, особенно когда они находятся в одном месте.
Недавно мы начали видеть больше решений на основе универсального ключа. Ключи могут быть сохранены только на вашем устройстве, что делает их персональным устройством, а также могут быть сохранены в облаке, что делает их безопасность зависимой от сложной гибридной безопасности паролей, инфраструктуры и доверенного аппаратного обеспечения. На самом деле, ключи представляют собой ценное средство безопасности для обычного пользователя, но полагаться только на них недостаточно для защиты сбережений пользователя на протяжении всей жизни.
К счастью, с ZK-SNARK у нас есть четвертый вариант: централизованный ID с ZK-пакетом. Этот тип включает в себя zk-email, Anon Aadhaar, Myna Кошелек и так далее. В основном, вы можете использовать различные формы ( компании или правительства ) централизованного ID и преобразовать их в адрес Ethereum, вы можете отправлять транзакции только путем генерации доказательства наличия централизованного ID с помощью ZK-SNARK.
С этим дополнением у нас теперь есть широкий выбор, и централизованный ID с ZK упаковкой обладает уникальной "дружелюбностью к новичкам".
Для этого необходимо реализовать упрощенный и интегрированный интерфейс: вы должны иметь возможность просто указать, что хотите, чтобы "example@gmail.com" был назначен опекуном, и он должен автоматически сгенерировать соответствующий адрес zk-email на Ethereum под капотом. Продвинутые пользователи должны иметь возможность ввести свою электронную почту ( и, возможно, сохраненные в этой электронной почте значения соли конфиденциальности ) в сторонние открытые приложения и подтвердить, что сгенерированный адрес правильный. Это должно касаться и любых других поддерживаемых типов опекунов.
Обратите внимание, что сегодня zk-email сталкивается с реальной проблемой, заключающейся в том, что он полагается на подпись DKIM, которая использует ключи, меняющиеся каждые несколько месяцев, и эти ключи сами по себе не подписаны никакими другими организациями. Это означает, что сегодня zk-email имеет определенную степень доверия, превышающую саму службу. Если zk-email использует TLSNotary для проверки обновленных ключей в доверенном оборудовании, это может уменьшить эту ситуацию, но это не идеально. Надеюсь, что поставщики электронной почты начнут напрямую подписывать свои DKIM ключи. Сегодня я рекомендую одному опекуну использовать zk-email, но не рекомендую большинству опекунов: не храните средства в zk-email, так как это означает, что вы не сможете использовать средства в случае сбоя.
Новые пользователи и кошелек внутри приложения
Новые пользователи на самом деле не хотят вводить множество опекунов при первой регистрации. Поэтому кошелек должен предоставить им очень простой выбор. Естественным способом является использование zk-email на их электронном адресе, локально хранящегося на устройстве пользователя ключа (, который может быть универсальным ключом ), а также резервного ключа, хранящегося у провайдера, для выбора 2 из 3. По мере того как пользователи становятся более опытными или накапливают больше активов, в какой-то момент им следует предложить добавить больше опекунов.
Интеграция Кошелька в приложение неизбежна, поскольку приложения, пытающиеся привлечь пользователей, не желают, чтобы они одновременно загружали два новых приложения ( само приложение, плюс Кошелек Ethereum ) создает запутанный пользовательский опыт. Тем не менее, пользователи кошельков многих приложений должны иметь возможность связывать все свои кошельки вместе, чтобы им нужно было беспокоиться лишь о одной "проблеме контроля доступа". Самый простой способ - это использование иерархической схемы, в которой есть быстрый процесс "ссылки", позволяющий пользователям устанавливать свой основной кошелек в качестве опекуна для всех кошельков внутри приложения.
Защита пользователей от мошенничества и других внешних угроз
Помимо безопасности аккаунта, современные Кошельки также выполняют множество задач по выявлению фальшивых адресов, фишинга, мошенничества и других внешних угроз, стараясь защитить пользователей от таких угроз. В то же время многие меры все еще довольно примитивны: например, требуется кликнуть, чтобы отправить ETH или другие токены на любой новый адрес, независимо от того, отправляете ли вы 100 долларов или 100 000 долларов. Здесь нет единого решения. Это серия медленных, постоянных исправлений и улучшений для различных категорий угроз. Тем не менее, продолжение работы над улучшениями здесь имеет большую ценность.
Приватность
Теперь пришло время начать более серьезно относиться к эфиру.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
8
Репост
Поделиться
комментарий
0/400
HalfIsEmpty
· 07-20 04:01
Впервые вижу, как говорят о важности Кошелька.
Посмотреть ОригиналОтветить0
Layer2Arbitrageur
· 07-19 12:59
лmao представьте, как вы называете это "конфиденциальностью", когда ваши tx calldata все еще утечет, как решето
Посмотреть ОригиналОтветить0
BearMarketMonk
· 07-18 17:20
Каждый Кошелек говорит о безопасности. Научитесь хорошо управлять Закрытым ключом, чтобы действительно быть в безопасности.
Посмотреть ОригиналОтветить0
LightningClicker
· 07-17 18:50
Распыляющий Кошелек слишком небезопасен.
Посмотреть ОригиналОтветить0
MysteriousZhang
· 07-17 18:47
кросс-чейн безопасность yyds
Посмотреть ОригиналОтветить0
DataPickledFish
· 07-17 18:43
Кошелек, спаси слепого от безобразия!
Посмотреть ОригиналОтветить0
DefiPlaybook
· 07-17 18:38
Говоря по правде, в настоящее время безопасность этих кошельков не на должном уровне. Будьте осторожны, когда входите в позицию.
Идея Кошелька: полное обновление кросс-чейн, безопасности и конфиденциальности
Видение идеального Кошелька: всестороннее обновление от кросс-чейн опыта до защиты конфиденциальности
Одним из ключевых уровней инфраструктурного стека 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 на цепочке с референсным ID или обратным вызовом W", кошелек сможет свободно удовлетворить этот запрос любым способом. Другой вариант — это протокол ссылки на заявку, в котором кошелек пользователя генерирует QR-код или URL с авторизацией на получение, чтобы получить определенное количество средств из их контракта на цепочке, задача получателя заключается в том, чтобы выяснить, как перевести эти средства в свой собственный кошелек.
Другой связанный вопрос - это оплата Gas. Если вы получили активы на L2, где у вас нет ETH, и вам нужно отправить транзакцию на этом L2, Кошелек должен автоматически использовать протокол (, например RIP-7755), чтобы оплатить Gas в цепочке, где у вас есть ETH. Если Кошелек хочет, чтобы вы проводили больше транзакций на L2 в будущем, он также должен использовать только DEX для отправки, например ETH стоимостью в миллионы Gas, чтобы будущие транзакции могли непосредственно тратить Gas (, потому что это дешевле ).
Безопасность аккаунта
Я представляю концепцию вызовов безопасности аккаунта следующим образом: хороший Кошелек должен одновременно работать в двух направлениях: (i) защищать пользователей от хакерских атак или злонамеренных действий со стороны разработчиков кошелька, а также (ii) защищать пользователей от последствий их собственных ошибок.
Моим предпочтительным решением в течение более десяти лет является социальное восстановление и многофункциональный Кошелек с уровнем контроля доступа. Учетные записи пользователей имеют два уровня ключей: главный ключ и N кураторов (, например, N = 5). Главный ключ может выполнять операции низкой стоимости и не финансовые операции. Большинство кураторов необходимо для выполнения (i) операций высокой стоимости, таких как отправка всей стоимости на счету или (ii) изменение главного ключа или любого куратора. При необходимости, может быть разрешено, чтобы главный ключ выполнял операции высокой стоимости через временную блокировку.
Выше представлено базовое проектирование, которое можно расширить. Механизмы управления доступом, такие как сеансовый ключ и ERC-7715, могут помочь поддерживать различный баланс между удобством различных приложений и безопасностью. Более сложная архитектура опекунов, например, с несколькими временными блокировками на разных порогах, может помочь максимизировать шансы успешного восстановления легитимных аккаунтов, одновременно минимизируя риск кражи.
Кто или что должен быть опекуном?
Для опытных пользователей криптовалют в сообществе опытных крипто-юзеров жизнеспособным вариантом являются ключи ваших друзей и семьи. Если вы попросите каждого предоставить вам новый адрес, то никто не должен знать, кто они - на самом деле, ваши опекуны даже не должны знать друг о друге. Если они не сообщат вам, вероятность их сговора невелика. Однако для большинства новых пользователей этот вариант недоступен.
Второй вариант - это институциональный куратор: компании, которые предоставляют услуги по подписанию транзакций только после получения от вас дополнительной подтверждающей информации, например, кодов подтверждения или видеозвонков для пользователей с высокой ценностью. Люди долгое время пытались создать такие компании, например, я представил CryptoCorp в 2013 году. Однако на данный момент эти компании еще не очень успешны.
Третий вариант — это несколько личных устройств (, таких как телефон, настольный компьютер, аппаратный Кошелек ). Это может работать, но для неопытных пользователей также сложно настроить и управлять. Существует также риск одновременной потери или кражи устройств, особенно когда они находятся в одном месте.
Недавно мы начали видеть больше решений на основе универсального ключа. Ключи могут быть сохранены только на вашем устройстве, что делает их персональным устройством, а также могут быть сохранены в облаке, что делает их безопасность зависимой от сложной гибридной безопасности паролей, инфраструктуры и доверенного аппаратного обеспечения. На самом деле, ключи представляют собой ценное средство безопасности для обычного пользователя, но полагаться только на них недостаточно для защиты сбережений пользователя на протяжении всей жизни.
К счастью, с ZK-SNARK у нас есть четвертый вариант: централизованный ID с ZK-пакетом. Этот тип включает в себя zk-email, Anon Aadhaar, Myna Кошелек и так далее. В основном, вы можете использовать различные формы ( компании или правительства ) централизованного ID и преобразовать их в адрес Ethereum, вы можете отправлять транзакции только путем генерации доказательства наличия централизованного ID с помощью ZK-SNARK.
С этим дополнением у нас теперь есть широкий выбор, и централизованный ID с ZK упаковкой обладает уникальной "дружелюбностью к новичкам".
Для этого необходимо реализовать упрощенный и интегрированный интерфейс: вы должны иметь возможность просто указать, что хотите, чтобы "example@gmail.com" был назначен опекуном, и он должен автоматически сгенерировать соответствующий адрес zk-email на Ethereum под капотом. Продвинутые пользователи должны иметь возможность ввести свою электронную почту ( и, возможно, сохраненные в этой электронной почте значения соли конфиденциальности ) в сторонние открытые приложения и подтвердить, что сгенерированный адрес правильный. Это должно касаться и любых других поддерживаемых типов опекунов.
Обратите внимание, что сегодня zk-email сталкивается с реальной проблемой, заключающейся в том, что он полагается на подпись DKIM, которая использует ключи, меняющиеся каждые несколько месяцев, и эти ключи сами по себе не подписаны никакими другими организациями. Это означает, что сегодня zk-email имеет определенную степень доверия, превышающую саму службу. Если zk-email использует TLSNotary для проверки обновленных ключей в доверенном оборудовании, это может уменьшить эту ситуацию, но это не идеально. Надеюсь, что поставщики электронной почты начнут напрямую подписывать свои DKIM ключи. Сегодня я рекомендую одному опекуну использовать zk-email, но не рекомендую большинству опекунов: не храните средства в zk-email, так как это означает, что вы не сможете использовать средства в случае сбоя.
Новые пользователи и кошелек внутри приложения
Новые пользователи на самом деле не хотят вводить множество опекунов при первой регистрации. Поэтому кошелек должен предоставить им очень простой выбор. Естественным способом является использование zk-email на их электронном адресе, локально хранящегося на устройстве пользователя ключа (, который может быть универсальным ключом ), а также резервного ключа, хранящегося у провайдера, для выбора 2 из 3. По мере того как пользователи становятся более опытными или накапливают больше активов, в какой-то момент им следует предложить добавить больше опекунов.
Интеграция Кошелька в приложение неизбежна, поскольку приложения, пытающиеся привлечь пользователей, не желают, чтобы они одновременно загружали два новых приложения ( само приложение, плюс Кошелек Ethereum ) создает запутанный пользовательский опыт. Тем не менее, пользователи кошельков многих приложений должны иметь возможность связывать все свои кошельки вместе, чтобы им нужно было беспокоиться лишь о одной "проблеме контроля доступа". Самый простой способ - это использование иерархической схемы, в которой есть быстрый процесс "ссылки", позволяющий пользователям устанавливать свой основной кошелек в качестве опекуна для всех кошельков внутри приложения.
Защита пользователей от мошенничества и других внешних угроз
Помимо безопасности аккаунта, современные Кошельки также выполняют множество задач по выявлению фальшивых адресов, фишинга, мошенничества и других внешних угроз, стараясь защитить пользователей от таких угроз. В то же время многие меры все еще довольно примитивны: например, требуется кликнуть, чтобы отправить ETH или другие токены на любой новый адрес, независимо от того, отправляете ли вы 100 долларов или 100 000 долларов. Здесь нет единого решения. Это серия медленных, постоянных исправлений и улучшений для различных категорий угроз. Тем не менее, продолжение работы над улучшениями здесь имеет большую ценность.
Приватность
Теперь пришло время начать более серьезно относиться к эфиру.