Особая благодарность Liraz Siri, Yoav Weiss и разработчикам ImToken, Metamask и OKX за их отзывы и рецензии.
Ключевым слоем инфраструктуры Ethereum является кошелек, который часто недооценивается основными исследователями и разработчиками L1. Кошелек - это окно между пользователем и миром Ethereum, и пользователи могут получать выгоду только от децентрализованных, устойчивых к цензуре, безопасных, конфиденциальных или других свойств, предоставляемых Ethereum и его приложениями, при условии, что сам кошелек также обладает этими свойствами.
Недавно мы увидели значительный прогресс в кошельках Ethereum в улучшении пользовательского опыта, безопасности и функциональности. Цель этой статьи - представить мой взгляд на некоторые характеристики, которые должен иметь идеальный кошелек Ethereum. Это не полный список; он отражает мои наклонности к криптопанку, которые сосредоточены на безопасности и конфиденциальности, и, вероятно, он неполный с точки зрения пользовательского опыта. Тем не менее, я считаю, что список желаемого не так эффективен в оптимизации пользовательского опыта, как простое развертывание и итерация на основе обратной связи, поэтому я считаю, что сосредоточение на характеристиках безопасности и конфиденциальности наиболее ценно.
Пользовательский опыт при кросс-L2 транзакциях
Теперь у нас есть все более подробная дорожная карта по улучшению пользовательского опыта между L2, которая включает в себя краткосрочную и долгосрочную части. Здесь я поговорю о краткосрочной части: идеи, которые теоретически могут быть реализованы даже сегодня.
Основная идея состоит в том, что (i) встроенная функция отправки между L2, а также (ii) адреса и платежные запросы, специфичные для цепочки. Ваш кошелек должен быть в состоянии предоставить вам адрес (в соответствии с этим ERC-проектом), как показано ниже:
Когда кто-то (или какое-то приложение) предоставляет вам адрес в этом формате, вы должны иметь возможность вставить его в поле «Получатель» вашего кошелька и затем нажать «Отправить». Кошелек должен автоматически обрабатывать отправляемые данные любым возможным образом:
Если у вас уже есть достаточное количество необходимых токенов на целевой цепочке, отправьте токены напрямую.
Если у вас есть необходимые токены на другой цепочке (или нескольких других цепочках), используйте протоколы, такие как ERC-7683 (по сути, это кросс-цепочный DEX), чтобы отправить токены.
Если у вас есть разные типы токенов на той же цепочке или на других цепочках, используйте децентрализованный обмен, чтобы преобразовать их в правильную валюту правильного типа на нужной цепочке и отправить. Это должно требовать явного согласия пользователя: пользователь увидит, сколько они заплатили, и сколько получил получатель.
Модель интерфейса возможного кошелька с поддержкой кросс-цепочных адресов
Содержимое выше относится к случаям использования «вы копируете и вставляете адрес (или ENS, например, vitalik.eth @ optimism.eth), чтобы кто-то мог вам заплатить». Если dapp запрашивает депозит (например, см. этот пример Polymarket), то идеальный процесс заключается в расширении веб3 API и разрешении dapp отправлять платежные запросы, специфичные для цепочки. Затем ваш кошелек сможет удовлетворить этот запрос любым необходимым образом. Для обеспечения хорошего пользовательского опыта также необходимо стандартизировать запросы getAvailableBalance, и кошелек должен серьезно подумать о том, на каких цепочках по умолчанию хранить активы пользователя, чтобы максимизировать безопасность и удобство перевода.
Платежные запросы, специфичные для цепочки, также могут быть помещены в QR-коды, которые мобильный кошелек может сканировать. В сценариях платежей потребителей лицом к лицу (или онлайн) получатель будет выдавать QR-код или вызывать веб3 API, указывая: «Я хочу X единиц токена Y Z на цепочке с идентификатором или обратным вызовом W», и кошелек будет вольным образом удовлетворять этот запрос. Другой вариант - это протокол claim link, в котором кошелек пользователя генерирует QR-код или URL с авторизацией на получение определенного количества средств из их контракта в цепочке, и задача получателя состоит в том, чтобы выяснить, как перевести эти средства на свой собственный кошелек.
Еще одной важной темой являются платежи за газ. Если вы получили активы на L2, у которого еще нет ETH, и вам нужно отправить транзакцию на этом L2, ваш кошелек должен автоматически использовать протокол (например, RIP-7755), чтобы оплатить газ на цепочке, где у вас есть ETH. Если кошелек ожидает, что вы будете совершать больше транзакций на L2 в будущем, он также должен просто использовать DEX для отправки, например, ETH, стоимостью несколько миллионов газ для будущих транзакций, чтобы они могли тратить газ напрямую там (поскольку это дешевле).
Безопасность аккаунта
Одна из концептуализаций проблемы безопасности аккаунтов заключается в том, что хороший кошелек должен одновременно выполнять две роли: (i) защищать пользователей от атак хакеров или злоумышленников, связанных с разработчиками кошельков, и (ii) защищать пользователей от последствий собственных ошибок.
«Ошибка» слева была случайной. Однако, когда я это увидел, я понял, что это очень подходит для контекста, поэтому я решил оставить это.
Мое предпочтительное решение для этого на протяжении более десяти лет - это социальное восстановление и мультиподписные кошельки с уровнями доступа. У аккаунта пользователя есть два уровня ключей: основной ключ и N опекунов (например, N = 5). Основной ключ позволяет выполнять операции низкой стоимости и не финансовые. Большинство опекунов нужно для выполнения (i) операций высокой стоимости, таких как отправка всей стоимости в аккаунте, или (ii) изменения основного ключа или любого опекуна. При необходимости основной ключ может выполнять операции высокой стоимости через временные блокировки.
Вышеизложенное представляет собой базовый дизайн, который можно расширять. Механизмы разрешений, такие как сеансовые ключи и ERC-7715, могут помочь поддерживать разные балансировки удобства и безопасности для различных приложений. Более сложные схемы опекунов, например, с несколькими временными блокировками при разных порогах, могут помочь максимизировать шансы на успешное восстановление законного аккаунта, одновременно минимизируя риск кражи.
Вышеизложенное представляет собой базовый дизайн, который можно расширять. Механизмы разрешений, такие как сеансовые ключи и ERC-7715, могут помочь поддерживать разные балансировки удобства и безопасности для различных приложений. Более сложные схемы опекунов, например, с несколькими временными блокировками при разных порогах, могут помочь максимизировать шансы на успешное восстановление законного аккаунта, одновременно минимизируя риск кражи.
Кто или что должны быть опекунами?
Для опытных пользователей криптовалют в сообществе опытным пользователям доступен жизнеспособный вариант - ключи ваших друзей и семьи. Если вы попросите всех предоставить вам новый адрес, то никто не будет знать, кто они - на самом деле, ваши опекуны даже не обязаны знать друг друга. Если они не настроят вас, вероятность того, что они сговорятся, очень мала. Тем не менее, для большинства новых пользователей этот вариант недоступен.
Второй вариант - это корпоративные опекуны: компании, которые предоставляют услуги подписи транзакций только при получении дополнительной подтверждающей информации по вашему запросу: например, код подтверждения или видеозвонок для пользователей с высокой стоимостью. Люди давно пытались создать такие компании, например, я представил CryptoCorp в 2013 году. Тем не менее, до сих пор эти компании не добились большого успеха.
Третьим вариантом являются множественные личные устройства (например, телефон, настольный компьютер, аппаратный кошелек). Это может сработать, но для неопытных пользователей это также может быть сложно настроить и управлять. Существует также риск одновременной потери или кражи устройств, особенно когда они находятся в одном месте.
Недавно мы начали видеть больше решений на основе универсальных ключей. Ключи могут быть сохранены только на вашем устройстве, что делает его решением для личного устройства, также можно делать резервные копии в облаке, что делает безопасность зависимой от сложных гипотез о безопасности паролей, организаций и доверенных аппаратных средств. На самом деле, ключи являются ценным средством безопасности для обычных пользователей, но их недостаточно для защиты сбережений пользователя на всю жизнь.
К счастью, с ZK-SNARK у нас есть четвёртый вариант: централизованный ID, упакованный в ZK. Этот тип включает в себя zk-email, Anon Aadhaar, Myna Wallet и т.д. По сути, вы можете принять централизованный ID в различных формах (компания или правительство) и преобразовать его в адрес Ethereum, через который вы можете отправлять транзакции, только сгенерировав доказательство, подтверждающее, что вы обладаете централизованным идентификатором через 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), что приводит к запутанному пользовательскому опыту. Тем не менее, пользователи многих кошельков приложений должны иметь возможность связывать все свои кошельки, чтобы им нужно было беспокоиться только о одной «проблеме контроля доступа». Самый простой способ - использовать иерархическую схему, в которой есть быстрый процесс «ссылки», позволяющий пользователям устанавливать свой основной кошелек в качестве опекуна для всех кошельков внутри приложения. Клиент Farcaster Warpcast уже поддерживает это:
По умолчанию восстановление вашего аккаунта Warpcast контролируется командой Warpcast. Однако вы можете «взять на себя» свой аккаунт Farcaster и изменить восстановление на свой собственный адрес.
Защита пользователей от мошенничества и других внешних угроз
Помимо безопасности аккаунтов, современные кошельки также делают много работы по идентификации поддельных адресов, фишинга, мошенничества и других внешних угроз, стараясь защитить пользователей от таких угроз. В то же время многие меры все еще довольно примитивные: например, требуется кликнуть, чтобы отправить ETH или другие токены на любой новый адрес, независимо от того, отправляете вы 100 долларов или 100 000 долларов. Здесь нет единого универсального решения. Это серия медленных постоянных исправлений и улучшений для различных категорий угроз. Тем не менее, продолжение усилий по улучшению здесь имеет множество ценностей.
Конфиденциальность
Теперь пришло время начать серьезно относиться к конфиденциальности Ethereum. Технология ZK-SNARK сейчас очень развита, технологии конфиденциальности, не полагающиеся на бэкдоры для снижения рисков регулирования (например, конфиденциальные пулы), становятся все более зрелыми, в то время как вторичная инфраструктура, такая как Waku и ERC-4337 mempools, также постепенно становится более стабильной. Тем не менее, до сих пор для совершения частных переводов на Ethereum пользователи должны явно загружать и использовать «конфиденциальные кошельки», такие как Railway (или Umbra для невидимых адресов). Это создает огромное неудобство и уменьшает число желающих совершать частные переводы. Решением будет необходимость прямой интеграции частных переводов в кошельки.
Простая реализация выглядит следующим образом. Кошелек может хранить часть активов пользователя как «приватный баланс» в конфиденциальном пуле. Когда пользователь совершает перевод, он автоматически выходит из конфиденциального пула. Если пользователь должен получить средства, кошелек может автоматически сгенерировать невидимый адрес.
Кроме того, кошелек может автоматически генерировать новый адрес для каждого приложения, в котором участвует пользователь (например, протоколы defi). Депозиты будут поступать из конфиденциального пула, а выводы напрямую в конфиденциальный пул. Это позволяет пользователю анонимизировать свои действия в одном приложении, отменяя их связь с действиями в других приложениях.
Одним из преимуществ этой технологии является то, что она является не только естественным способом защиты конфиденциальности при передаче активов, но и естественным способом защиты конфиденциальности идентичности. Идентичность уже существует в цепочке: любые приложения с проверкой удостоверений личности (например, Gitcoin Grants), любой токенизированный чат, протоколы, соблюдающие Ethereum и др. - это идентичность в цепочке. Мы хотим, чтобы эта экосистема также защищала конфиденциальность. Это означает, что активность пользователя в цепочке не должна собираться в одном месте: каждый проект должен храниться отдельно, а кошелек пользователя должен быть единственным, у кого есть «глобальный обзор», чтобы одновременно видеть все ваши доказательства. Нативная экосистема, в которой каждый пользователь имеет несколько аккаунтов, способствует этому, как и цепочные доказательства, такие как EAS и Zupass.
Это представляет собой прагматичное видение конфиденциальности Ethereum в среднесрочной перспективе. Хотя можно ввести некоторые функции на L1 и L2, чтобы сделать защиту конфиденциальности более эффективной и надежной, это уже можно реализовать. Некоторые защитники конфиденциальности считают, что единственным приемлемым вариантом является полная конфиденциальность для всего: шифрование всего EVM. Я считаю, что это может быть идеальным долгосрочным результатом, но это требует более основательного переосмысления программной модели и в настоящее время не достигло уровня зрелости, готового к развертыванию на Ethereum. Нам действительно нужна конфиденциальность по умолчанию, чтобы получить достаточно большую анонимную группу. Тем не менее, сначала сосредоточив внимание на (i) переводах между аккаунтами и (ii) идентификацией и связанными с ней случаями использования (например, приватными доказательствами), является прагматичным первым шагом, который легче реализовать, и который кошельки могут начать использовать уже сейчас.
Кошельки Ethereum также должны стать кошельками данных.
Одним из последствий любого эффективного решения для защиты конфиденциальности является то, что независимо от того, используется ли оно для платежей, идентификации или других случаев, оно создает необходимость для пользователей хранить данные вне цепочки. Это очевидно в Tornado Cash, который требует от пользователей сохранять «квитанции» для депозитов в диапазоне от 0.1 до 100 ETH. Более современные протоколы конфиденциальности иногда сохраняют зашифрованные данные в цепочке и используют один частный ключ для их расшифровки. Это рискованно, поскольку если ключ будет скомпрометирован, или квантовые компьютеры станут жизнеспособными, все данные станут общедоступными. Цепочка доказательств, такая как EAS и Zupass, подчеркивает необходимость хранения данных вне цепочки.
Кошелек должен не только хранить программное обеспечение для доступа к данным в цепочке, но и программное обеспечение для хранения ваших личных данных. Невозможно не заметить, что и в не крипто-мире это становится все более актуальным, например, обратите внимание на недавние работы Тима Бернерса-Ли по хранению личных данных. Все, что нам нужно, это решить вопросы, касающиеся надежного обеспечения контроля доступа, мы также должны решить вопросы, касающиеся обеспечения доступности данных и предотвращения их утечек. Возможно, эти решения могут быть наложены друг на друга: если у вас есть N опекунов, храните свои данные с помощью M из N секретного распределения. Защита данных по сути более сложна, поскольку вы не можете отозвать чью-то долю в данных, но мы должны предложить максимально безопасные решения для децентрализованного хранения.
Безопасный доступ к цепочке
В настоящее время кошельки доверяют своим RPC провайдерам, что они сообщают им любую информацию о цепочке. Это уязвимость, имеющая два аспекта:
Поставщики RPC могут пытаться украсть деньги, предоставляя им ложную информацию, например, о рыночных ценах.
Поставщики RPC могут извлекать личную информацию о приложениях и других аккаунтах, с которыми взаимодействует пользователь.
В идеале мы хотим закрыть эти два уязвимости. Для решения первой проблемы нам нужны стандартизированные легкие клиенты для L1 и L2, которые могут напрямую проверять консенсус блокчейна. Helios уже сделал это для L1 и ведет некоторую предварительную работу для поддержки некоторых конкретных L2. Чтобы правильно охватить все L2, нам нужен стандарт, по которому конфигурационный контракт, представляющий L2 (также используемый для адресов, специфичных для цепочки), может объявить функцию, возможно, аналогично ERC-3668, которая включает в себя логику получения последнего состояния корня и проверки доказательства состояния и квитанций для этих корней. Таким образом, у нас может быть универсальный легкий клиент, который позволяет кошелькам безопасно проверять любое состояние или событие как на L1, так и на L2.
С точки зрения конфиденциальности, единственным реальным способом на сегодняшний день является запуск вашего собственного полного узла. Однако теперь, когда L2 входит в поле зрения, становится все труднее запускать полный узел для всего. То, что эквивалентно легкому клиенту, - это приватный информационный поиск (PIR). PIR включает в себя серверы, которые хранят все копии данных, и клиент, который отправляет зашифрованные запросы на сервер. Сервер выполняет вычисления на всех данных, возвращает данные, необходимые клиенту, и шифрует их с помощью ключа клиента, не раскрывая серверу, к каким данным клиент получил доступ.
Чтобы обеспечить честность серверов, отдельные проекты баз данных сами по себе являются ветвями Merkle, так что клиенты могут использовать легкие клиенты для их проверки.
Объем вычислений PIR (глубокая волна примечания: обычно относится к «приватному информационному поиску» (Private Information Retrieval), что представляет собой протокол или технологию, позволяющую пользователям извлекать информацию из базы данных без раскрытия информации, извлекаемой из нее) очень велик. Существует несколько подходов для решения этой проблемы:
С помощью грубой силы: улучшения алгоритмов или специализированного оборудования могут заставить PIR работать достаточно быстро. Эти технологии могут зависеть от предварительной обработки: сервер может хранить зашифрованные и перемешанные данные для каждого клиента, и клиент может запрашивать эти данные. Основная проблема в среде Ethereum заключается в том, чтобы адаптировать эти технологии к быстро меняющимся наборам данных (как в случае с государствами). Это снижает затраты на вычисления в реальном времени, но очень вероятно, что это увеличит общие затраты на вычисления и хранение.
Ослабление требований к конфиденциальности: например, каждый раз, когда необходимо выполнить поиск, может быть только 1 миллион «миксинов», поэтому сервер будет знать о миллионе возможных значений, к которым клиент может получить доступ, но не знает никаких более тонких деталей.
Многофункциональный PIR: если вы используете несколько серверов, и предположение о честности между этими серверами равно 1 из N, то алгоритм PIR обычно работает быстрее.
Анонимность, а не конфиденциальность: запросы могут быть отправлены через смешивающую сеть, скрывая отправителя запроса, а не скрывая содержание запроса. Однако эффективное выполнение этого неизбежно увеличивает задержку, что ухудшает пользовательский опыт.
Выявление правильной комбинации технологий в среде Ethereum для максимизации конфиденциальности при сохранении практичности является открытым исследовательским вопросом, и я приветствую криптографов, которые попытаются это сделать.
Идеальный кошелек для хранения ключей
Кроме передачи и доступа к состоянию, еще одним важным рабочим процессом, который необходимо плавно интегрировать в контексте кросс-L2, является изменение конфигурации верификации аккаунта: либо изменение его ключа (например, восстановление), либо более глубокие изменения в логике аккаунта. Здесь есть три уровня решения, упорядоченных по возрастанию сложности:
Обновления воспроизведения: когда пользователь меняет свою конфигурацию, сообщение, уполномочивающее это изменение, будет воспроизведено на каждом on-chain, где кошелек обнаруживает, что у пользователя есть активы. Возможно, формат сообщения и правила проверки могут быть независимы от цепочки, так что они могут быть автоматически воспроизведены на как можно большем количестве цепочек.
Хранилище ключей на L1: информация о конфигурации находится на L1, кошельки на L2 используют L1S LOAD для ее чтения или удаленного статического вызова. Таким образом, конфигурация должна обновляться только на L1, и она автоматически вступит в силу.
Хранилище ключей на L2: информация о конфигурации находится на L2, кошельки на L2 используют ZK-SNARK для ее чтения. Это похоже на (2), за исключением того, что обновление хранилища ключей может быть дешевле, но, с другой стороны, чтение более дорогое.
Решение (3) особенно мощно, поскольку оно хорошо сочетается с конфиденциальностью. В обычных «решениях конфиденциальности» у пользователя есть секрет s, который публикуется на цепочке как «значение листа» L, пользователь доказывает, что L = hash(s, 1) и N = hash(s, 2) для некоторого (никогда не раскрытого) секрета, которым он управляет. Неверный символ N публикуется, чтобы гарантировать, что будущие расходы из этого же листа не удастся произвести, не раскрывая при этом L, что зависит от безопасности пользователя s. Дружественное к восстановлению решение конфиденциальности будет говорить: s - это местоположение (например, адрес и слот хранения) в цепочке, пользователь должен доказать запрос состояния: L = hash(sload(s), 1).
Безопасность Dapp
Самая уязвимая точка безопасности пользователей часто находится в dapp. Чаще всего пользователи взаимодействуют с приложением через веб-сайты, которые неявно загружают код пользовательского интерфейса в реальном времени с сервера, а затем выполняют его в браузере. Если сервер подвергся атаке, или DNS был атакован, пользователи получат ложную копию интерфейса, что может ввести их в заблуждение для выполнения произвольных действий. Функции кошелька, такие как симуляция транзакций, очень полезны для снижения рисков, но они все еще далеки от совершенства.
В идеале мы переместим экосистему на цепочку контроля версий контента: пользователи будут получать доступ к dapp через свое имя ENS, это имя будет содержать IPFS хэш интерфейса. Обновление интерфейса требует on-chain транзакции от мультиподписей или DAO. Кошелек будет показывать пользователям, взаимодействуют ли они с более безопасным on-chain интерфейсом или менее безопасным Web2 интерфейсом. Кошелек также может показывать пользователям, взаимодействуют ли они с безопасной цепочкой (например, этап 1+, многоуровневая безопасность аудита).
Для пользователей, ориентированных на конфиденциальность, кошелек также может добавить параноидальный режим, требующий от пользователей нажать, чтобы подтвердить HTTP-запросы, а не просто операции web3:
Модель интерфейса для параноидального режима
Более продвинутый подход - это выход за пределы HTML + Javascript и написание бизнес-логики dapp на специализированном языке (возможно, относительно тонком слое над Solidity или Vyper). Затем браузер может автоматически генерировать пользовательский интерфейс для любой необходимой функции. OKContract уже делает это.
Другим направлением является защита информации в криптоэкономике: разработчики dapp, компании по безопасности, развертыватели цепочек и другие могут создать облигацию, которая будет выплачена пострадавшим пользователям (определенным) в случае, если dapp будет взломан или причинит пользователям вред в крайне вводящем в заблуждение виде, через некоторый DAO по цепочке. Кошелек может показывать пользователям баллы, основанные на размере облигации.
Долгосрочное будущее
Все вышеперечисленное осуществляется в контексте традиционного интерфейса, который включает в себя указание и нажатие на объекты, а также ввод данных в текстовые поля. Однако мы также находимся на пороге более глубоких изменений в парадигме:
Искусственный интеллект, который может привести нас от парадигмы написания текстом к парадигме «скажите, что вы хотите сделать, и робот разберется»
Интерфейсы мозг-компьютер, как «мягкие» методы, такие как отслеживание взгляда, так и более прямые, даже инвазивные технологии (см. первого пациента Neuralink в этом году)
Активная защита клиента: браузер Brave активно защищает пользователей от рекламы, трекеров и множества других нежелательных объектов. Многие браузеры, плагины и криптокошельки имеют целые команды, активно работающие над защитой пользователей от различных угроз безопасности и конфиденциальности. Эти «активные защитники» станут только сильнее в ближайшие десять лет.
Эти три тенденции вместе приведут к более глубокому переосмыслению того, как работают интерфейсы. С помощью ввода на естественном языке, отслеживания взгляда или, в конечном счете, более прямых интерфейсов «мозг-компьютер», а также вашей истории (возможно, включая текстовые сообщения, при условии, что все данные обрабатываются локально), «кошелек» может четко и интуитивно понять, что вы хотите сделать. Затем искусственный интеллект может преобразовать эту интуицию в конкретный «план действий»: серию взаимодействий на цепочке и вне ее, чтобы выполнить то, что вы хотите. Это может значительно сократить потребность в сторонних пользовательских интерфейсах. Если пользователь действительно взаимодействует со сторонними приложениями (или другими пользователями), искусственный интеллект должен представлять пользователя, проводя антагонистическое мышление, выявляя любые угрозы и предлагая план действий для их предотвращения. В идеале эти искусственные интеллекты должны являться частью открытой экосистемы, создаваемой разными группами с различными предвзятостями и структурами стимулов.
Эти более радикальные идеи зависят от технологий, которые сегодня очень незрелы, поэтому я сегодня не буду помещать свои активы в кошельки, полагающиеся на них. Тем не менее, подобные вещи, похоже, очевидно являются тенденцией будущего, поэтому стоит начать более активно исследовать это направление.
