Особлива подяка Ліразу Сірі, Йоаву Вайсу, а також розробникам 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', гаманець зможе задовольнити цей запит будь-яким способом. Ще одним варіантом є протокол посилань на претензії, в якому гаманець користувача генерує 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, відправляючи транзакцію лише шляхом генерування доказу, що ви володієте централізованим 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 та ERC-4337 mempools, також повільно стають більш стабільними. Однак до цього часу проведення приватних транзакцій в Ethereum вимагало від користувачів явного завантаження та використання 'конфіденційних гаманців', таких як Railway (або Umbra для невидимих адрес). Це призводить до величезних незручностей і зменшує кількість охочих проводити приватні транзакції. Рішенням є те, що приватні транзакції повинні бути безпосередньо інтегровані в гаманець.
Просте впровадження виглядає наступним чином. Гаманець може зберігати частину активів користувача як 'приватний баланс' у конфіденційному пулі. Коли користувач здійснює переказ, він спочатку автоматично виходить з конфіденційного пулу. Якщо користувач потребує отримати кошти, гаманець може автоматично згенерувати невидиму адресу.
Крім того, гаманець може автоматично генерувати нову адресу для кожного застосування, в якому бере участь користувач (наприклад, протокол дефі). Депозити надходитимуть з конфіденційного пулу, а зняття коштів буде здійснюватися безпосередньо в конфіденційний пул. Це дозволяє активності користувача в одному додатку бути відключеною від його активності в інших додатках.
Однією з переваг цієї технології є те, що вона є природним способом захисту конфіденційності при передачі активів, а також природним способом захисту конфіденційності ідентичності. Ідентичність вже відбувається в онлайні: будь-яке застосування, що використовує контроль доступу на основі особи (наприклад, гранти Gitcoin), будь-який токенізований чат, протоколи 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 передбачає наявність серверів, які зберігають всі копії даних, та клієнтів, які надсилають зашифровані запити на сервер. Сервери виконують обчислення над усіма даними, повертають клієнту необхідні дані та зашифровують їх до ключа клієнта, не розкриваючи серверу, до яких даних отримав доступ клієнт.
Щоб зберегти чесність серверів, різні проекти бази даних самі є Мерклі-вітками, тому клієнти можуть використовувати легкі клієнти для їх перевірки.
Обчислення PIR (глибокий潮注: зазвичай означає 'приватний інформаційний запит' (Private Information Retrieval), протокол або технологія, що дозволяє користувачам витягувати інформацію з бази даних без розкриття запитуваної інформації) є дуже великим. Існує кілька способів вирішення цієї проблеми:
Використовуючи грубу силу: покращення алгоритмів або спеціалізованого апаратного забезпечення можуть зробити PIR достатньо швидким. Ці технології можуть залежати від попередньої обробки: сервери можуть зберігати зашифровані та перемішані дані для кожного клієнта, а клієнти можуть запитувати ці дані. Основним викликом в екосистемі Ethereum є адаптація цих технологій до швидко змінюваних наборів даних (як у випадку з країнами). Це знижує вартість обчислень у реальному часі, але ймовірно підвищує загальні витрати на обчислення та зберігання.
Зменшення вимог до конфіденційності: наприклад, кожен пошук може мати лише 1 мільйон 'міксинів', так що сервер буде знати про мільйон можливих значень, до яких може отримати доступ клієнт, але не знати про будь-яку іншу деталь.
Багато серверів PIR: якщо ви використовуєте кілька серверів, і гіпотеза чесності між цими серверами є 1 з N, тоді алгоритм PIR зазвичай буде швидшим.
Анонімність, а не конфіденційність: запити можуть бути надіслані через змішувальні мережі, що приховує відправника запиту, а не зміст запиту. Проте ефективне виконання цього, безумовно, збільшить затримки, що погіршить досвід користувача.
Визначення правильного технологічного поєднання в середовищі Ethereum для максимізації конфіденційності, зберігаючи при цьому практичність, є відкритим дослідницьким питанням, і я вітаю криптографів, які намагатимуться це зробити.
Ідеальний гаманець для ключів
Окрім передачі та доступу до стану, ще одним важливим робочим процесом, що потребує плавної роботи в контексті між L2, є зміна конфігурації верифікації облікового запису: чи то зміна його ключа (наприклад, відновлення), чи то більш глибокі зміни в логіці облікового запису. Тут є три рівні рішень, впорядкованих за зростанням складності:
Оновлення відтворення: коли користувач змінює свою конфігурацію, повідомлення, що авторизує цю зміну, відтворюється на кожному ланцюзі, де гаманець виявляє, що у користувача є активи. Можливо, формат повідомлення та правила верифікації можуть бути незалежними від ланцюга, тому можуть автоматично відтворюватися на якомога більшій кількості ланцюгів.
Ключова бібліотека на 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 хеш інтерфейсу. Оновлення інтерфейсу вимагатиме онлайнової транзакції від мультипідпису або DAO. Гаманець показуватиме користувачеві, чи взаємодіє він із більш безпечним онлайновим інтерфейсом чи менш безпечним Web2 інтерфейсом. Гаманець також може показувати користувачеві, чи взаємодіє він з безпечною мережею (наприклад, етап 1+, багаторазова безпечна перевірка).
Для користувачів, які дбають про конфіденційність, гаманець також може додати параноїдний режим, що вимагає від користувача натискання для прийняття HTTP запитів, а не лише web3 операцій:
Модель інтерфейсу можливого параноїдного режиму
Більш просунутим підходом є вихід за межі HTML + Javascript і написання бізнес-логіки dapp за допомогою спеціалізованої мови (можливо, відносно тонкого шару над Solidity або Vyper). Тоді браузер може автоматично згенерувати UI для будь-яких необхідних функцій. OKContract вже займається цим.
Ще одним напрямком є захист інформації в криптоекономіці: розробники dapp, компанії з безпеки, розгортальники ланцюга та інші можуть створити облігацію, якщо dapp буде зламано або завдасть шкоди користувачам в сильно оманливий спосіб, ця облігація буде виплачена постраждалим користувачам (визначеним) через DAO з ланцюга. Гаманець може показувати користувачеві бал за облігацією.
Довгострокова перспектива
Усе вище згадане відбувається на фоні традиційного інтерфейсу, в якому є вказівник та клацання на речах, а також введення речей у текстові поля. Проте ми також перебуваємо на краю більш глибоких змін парадигми:
Штучний інтелект, що може призвести до переходу від парадигми клацання та набору тексту до парадигми 'скажіть, що ви хочете зробити, і робот зрозуміє'.
Інтерфейси мозок-комп'ютер, як м'які методи, такі як відстеження очей, так і більш прямі, навіть інвазивні технології (див. першу пацієнтку Neuralink цього року).
Активний захист клієнта: браузер Brave активно захищає користувачів від реклами, трекерів та багатьох інших шкідливих об'єктів. Багато браузерів, плагінів та крипто-гаманців мають цілі команди, які активно працюють над захистом користувачів від різних загроз безпеці та конфіденційності. Ці 'активні захисники' лише посиляться протягом наступного десятиліття.
Ці три тенденції разом призведуть до більш глибокого переосмислення способу роботи інтерфейсів. Завдяки введенню природною мовою, відстеженню погляду або, в кінцевому підсумку, більш прямим інтерфейсам мозок-комп'ютер, разом з вашою історією (можливо, включаючи текстові повідомлення, за умови, що всі дані обробляються локально), 'гаманець' може чітко та інтуїтивно зрозуміти, що ви хочете зробити. Тоді штучний інтелект може перетворити цю інтуїцію в конкретний 'план дій': серію взаємодій в онлайні та поза ним, щоб виконати те, що ви хочете. Це може значно зменшити потребу в інтерфейсах користувачів третьої сторони. Якщо користувач дійсно взаємодіє з програмами третьої сторони (або іншими користувачами), штучний інтелект повинен представляти користувача, проводячи контрдумки, виявляючи будь-які загрози та пропонуючи план дій для уникнення загроз. В ідеалі ці штучні інтелекти повинні мати відкриту екосистему, створену різними групами з різними упередженнями та структурами стимулів.
Ці більш радикальні ідеї залежать від технологій, які сьогодні дуже недосконалі, тому я сьогодні не покладу свої активи в гаманець, що покладається на них. Проте подібні речі, здається, очевидно є тенденцією майбутнього, тому варто почати більш активно досліджувати в цьому напрямку.
