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