Гаманці — це вікно між користувачами та світом Ethereum, і я вважаю, що зосередження на атрибутах безпеки та конфіденційності є найціннішим.
Особлива подяка Liraz Siri, Yoav Weiss і розробникам ImToken, Metamask і OKX за їхні відгуки та огляд.
Критичний рівень стека інфраструктури Ethereum, який часто недооцінюють основні дослідники та розробники L1, — це гаманець. Гаманці є вікном між користувачами та світом Ethereum, і користувачі можуть отримати вигоду від будь-якої децентралізації, стійкості до цензури, безпеки, конфіденційності чи інших атрибутів, які пропонують Ethereum та його програми, лише якщо сам гаманець також має ці атрибути.
Нещодавно ми побачили, що гаманці Ethereum досягли великих успіхів у покращенні взаємодії з користувачем, безпеки та функціональності. Мета цієї статті — висловити мою власну думку щодо деяких функцій, які повинен мати ідеальний гаманець Ethereum. Це не вичерпний список; він відображає мої нахили до шифрпанку, він зосереджений на безпеці та конфіденційності та майже напевно неповний з точки зору взаємодії з користувачем. Однак я не вважаю, що списки побажань настільки ефективні для оптимізації взаємодії з користувачем, як просте розгортання та ітерація на основі відгуків, тому я вважаю, що зосередження на атрибутах безпеки та конфіденційності є найціннішим.
Взаємодія з користувачем для трансакцій між L2
Зараз існує дедалі детальніша дорожня карта для покращення взаємодії з користувачем на рівні 2 із короткостроковою та довгостроковою частинами. Тут я розповім про короткострокову частину: ідеї, які теоретично можливо реалізувати навіть сьогодні.
Основна ідея полягає в (i) вбудованому перехресному надсиланні L2 і (ii) ланцюжкові адреси та платіжні запити. Ваш гаманець повинен мати можливість надати вам адресу (дотримуючись стилю цього проекту ERC), як це:
Коли хтось (або якась програма) надає вам адресу в цьому форматі, ви зможете вставити її в поле «Кому» свого гаманця та натиснути «Надіслати». Гаманець повинен автоматично обробляти надіслані дані будь-яким можливим способом:
Якщо у вас уже є достатньо токенів потрібного типу в цільовому ланцюжку, надішліть токени безпосередньо
Якщо у вас є потрібний тип токена в іншому ланцюжку (або кількох інших ланцюжках), надішліть токен за допомогою протоколу, такого як ERC-7683 (фактично крос-ланцюжок DEX)
Якщо у вас є різні типи токенів в одному або інших ланцюжках, використовуйте децентралізований обмін, щоб конвертувати їх у потрібний тип валюти в правильному ланцюжку та надіслати їх. Для цього потрібен явний дозвіл від користувача: користувачі бачитимуть, скільки вони заплатили та скільки отримав одержувач.
Модель можливого інтерфейсу гаманця з підтримкою міжланцюжкових адрес
Наведене вище стосується випадку використання «ви копіюєте та вставляєте адресу (або ENS, наприклад, vitalik.eth @optimism.eth ) і хтось вам платить». Якщо прикладна програма запитує депозит (наприклад, див. цей приклад Polymarket), тоді ідеальним способом було б розширити API web3 і дозволити програмі здійснювати платіжні запити для певного ланцюга. Тоді ваш гаманець зможе виконати запит будь-яким необхідним способом. Для якісної взаємодії з користувачем запити getAvailableBalance також мають бути стандартизовані, а гаманці мають ретельно враховувати, у яких ланцюгах активи користувача зберігатимуться за замовчуванням, щоб максимізувати безпеку та зручність передачі.
Запити на платіж, що стосуються конкретної мережі, також можна вводити в QR-коди, які можна сканувати мобільними гаманцями. У сценарії особистого платежу (або в режимі онлайн) одержувач видасть QR-код або виклик web3 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 у нас є четвертий варіант: централізований ідентифікатор пакета ZK. Цей тип включає zk-email, Anon Aadhaar, Myna Wallet тощо. По суті, ви берете централізований ідентифікатор в одній із його багатьох форм (корпоративний чи урядовий) і перетворюєте його на адресу Ethereum, і ви можете відправляти транзакції, лише згенерувавши ZK-SNARK, який підтверджує, що у вас є централізований ідентифікатор.
Завдяки цьому доповненню ми тепер маємо широкий спектр опцій і унікальну «зручність для новачків» централізованих ідентифікаторів, загорнутих у ZK.
Для цього його потрібно реалізувати за допомогою спрощеного та інтегрованого інтерфейсу користувача: ви повинні мати можливість просто вказати, що ви хочете «example@gmail.com» як опікуна, і він повинен автоматично створити відповідну адресу електронної пошти zk Ethereum у капот. Досвідчені користувачі повинні мати можливість ввести свою електронну пошту (і, можливо, інформацію про конфіденційність, збережену в цій електронній пошті) у сторонній програмі з відкритим кодом і підтвердити, що отримана адреса правильна. Те саме стосується будь-якого іншого підтримуваного типу опікуна.
Зауважте, що практична проблема, з якою сьогодні стикається zk-email, полягає в тому, що він покладається на підписи DKIM, які використовують ключі, які змінюються кожні кілька місяців і самі по собі не підписані жодним іншим органом. Це означає, що сьогоднішній zk-email має певний рівень довіри, крім самого провайдера, який можна зменшити, якщо zk-email використовує TLSNotary у довіреному обладнанні для перевірки оновлених ключів, але це не ідеально. Сподіваємося, що постачальники послуг електронної пошти почнуть безпосередньо підписувати свої ключі DKIM. Сьогодні я рекомендую zk-email для одного опікуна, але не для більшості опікунів: не зберігайте кошти в налаштуваннях, де несправний zk-email означає, що ви не можете використовувати кошти.
Нові користувачі та гаманець у програмі
Нові користувачі насправді не хочуть вводити велику кількість опікунів під час першої реєстрації. Тому гаманець повинен надати їм дуже просту опцію. Природним шляхом було б зробити 2 з 3 за допомогою електронної пошти zk на їхню адресу електронної пошти, ключ, який зберігається локально на пристрої користувача (можливо, головний ключ), і резервний ключ, який зберігається у постачальника. У міру того, як користувачі стають більш досвідченими або накопичують більше активів, у певний момент їм слід запропонувати додати більше опікунів.
Інтеграція гаманця в додатки неминуча, оскільки додатки, які намагаються зацікавити користувачів, які не використовують криптовалюту, не хочуть, щоб користувачі завантажували дві нові програми (саму програму та гаманець Ethereum) одночасно. Однак користувачі багатьох гаманців додатків повинні мати можливість зв’язати всі свої гаманці разом, щоб мати лише одну «проблему контролю доступу», про яку варто турбуватися. Найпростіший підхід полягає в застосуванні багаторівневої схеми, де є швидкий процес «зв’язування», який дозволяє користувачам налаштувати свій основний гаманець як опікуна всіх гаманців у програмі. Клієнт Farcaster Warpcast вже підтримує це:
За замовчуванням відновлення вашого облікового запису Warpcast контролюється командою Warpcast. Однак ви можете «заволодіти» своїм обліковим записом Farcaster і змінити відновлення на свою власну адресу.
Захистіть користувачів від шахрайства та інших зовнішніх загроз
Окрім безпеки облікових записів, сучасні гаманці роблять багато для виявлення підроблених адрес, фішингу, шахрайства та інших зовнішніх загроз і намагаються захистити користувачів від таких загроз. У той же час багато контрзаходів все ще досить примітивні: наприклад, потрібно натиснути кнопку, щоб надіслати ETH або інші токени на будь-яку нову адресу, незалежно від того, надсилаєте ви $100 або $100 000. Тут немає жодної чарівної кулі. Це повільна серія виправлень і вдосконалень для різних класів загроз. Проте продовження роботи над удосконаленнями має велике значення.
конфіденційність
Настав час серйозніше ставитися до конфіденційності в Ethereum. Технологія ZK-SNARK зараз є дуже розвинутою, технології конфіденційності, які не покладаються на бекдори для зменшення регулятивного ризику (такі як пули конфіденційності), стають все більш зрілими, а вторинна інфраструктура, як-от мемпули Waku та 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. Більш сучасні протоколи конфіденційності іноді зберігають зашифровані дані в ланцюжку та використовують єдиний приватний ключ для їх дешифрування. Це ризиковано, оскільки якщо станеться витік ключів або квантові комп’ютери стануть можливими, усі дані будуть публічними. Оффчейн докази, такі як EAS і Zupass, мають більш очевидну потребу у зберіганні даних поза ланцюгом.
Гаманець має бути програмним забезпеченням, яке не лише зберігає права доступу в мережі, але й ваші особисті дані. Наприклад, некриптосвіт все більше визнає це. Перегляньте нещодавню роботу Тіма Бернерса-Лі про зберігання персональних даних. Усі проблеми, які нам потрібно вирішити, пов’язані з надійним забезпеченням контролю доступу, ми також маємо вирішити, щоб забезпечити доступність даних і відсутність витоку. Можливо, ці рішення підійдуть: якщо у вас N опікунів, скористайтеся M-of-N обміном секретами між цими N опікунами для зберігання ваших даних. Дані за своєю суттю важче захистити, оскільки ви не можете відкликати чиюсь частку даних, але ми повинні розробити децентралізовані рішення для хостингу, які є максимально безпечними.
Безпечний ланцюжок доступу
Сьогодні гаманці довіряють своєму постачальнику RPC, щоб повідомити їм будь-що про ланцюг. Це вразливість двома способами:
Провайдери RPC можуть намагатися вкрасти гроші, наприклад, надаючи їм неправдиву інформацію. Про ринкову ціну.
Постачальники RPC можуть отримувати особисту інформацію про програми та інші облікові записи, з якими взаємодіє користувач.
В ідеалі ми хотіли б закрити обидві ці лазівки. Щоб вирішити першу проблему, нам потрібні стандартизовані легкі клієнти для L1 і L2, які можуть безпосередньо перевіряти консенсус блокчейну. Helios вже робить це для L1 і виконує певну попередню роботу для підтримки деяких конкретних L2. Щоб належним чином охопити весь L2, нам потрібен стандарт, згідно з яким контракт конфігурації, що представляє L2 (також використовується для специфічних для ланцюга адрес), може оголосити функцію, можливо, подібним до ERC-3668, що містить функцію отримання найближчого корінь стану та Перевірте логічні стани сертифікації та квитанції щодо коренів цих станів. Таким чином ми можемо мати універсальний легкий клієнт, який дозволяє гаманцям безпечно перевіряти будь-який стан або подію на рівнях L1 і L2.
З точки зору конфіденційності єдиний реалістичний підхід на сьогодні — це запустити власний повний вузол. Однак тепер, коли з’являється рівень L2, запустити повний вузол із усім стає дедалі складніше. Еквівалентом легкого клієнта тут є приватне отримання інформації (PIR). PIR включає сервер, який зберігає копію всіх даних, і клієнт, який надсилає зашифрований запит на сервер. Сервер виконує обчислення з усіма даними, повертаючи потрібні клієнту дані, зашифровані ключем клієнта, не повідомляючи серверу, до якої частини даних клієнт отримав доступ.
Щоб сервер був чесним, окремі проекти баз даних самі є форками Merkle, тому клієнти можуть використовувати легкі клієнти для їх перевірки.
PIR (Примітка Deep Chao: зазвичай відноситься до "приватного отримання інформації" (приватного отримання інформації), протоколу або технології, яка дозволяє користувачам отримувати інформацію з бази даних, не розкриваючи отриману інформацію.) Обсяг обчислень дуже великий. Існує кілька способів вирішення цієї проблеми:
За допомогою грубої сили: удосконалення алгоритмів або спеціалізованого обладнання може зробити PIR достатньо швидким. Ці методи можуть залежати від попередньої обробки: сервер може зберігати зашифровані та зашифровані дані для кожного клієнта, а клієнти можуть запитувати ці дані. Головним завданням у середовищі Ethereum є адаптація цих технологій до наборів даних, що швидко змінюються (як і країни). Це здешевлює обчислення в реальному часі, але, ймовірно, збільшує загальні витрати на обчислення та зберігання.
Послабте вимоги до конфіденційності: наприклад, може бути лише 1 мільйон «міксинів» на пошук, тому сервер знатиме 1 мільйон можливих значень, до яких клієнт має доступ, але не будь-яку дрібнішу деталізацію.
Багатосерверний PIR: якщо ви використовуєте кілька серверів, і чесність між цими серверами вважається 1 із N, тоді алгоритм PIR зазвичай працює швидше.
Анонімність замість конфіденційності: запити можна надсилати через гібридну мережу, приховуючи відправника запиту, а не приховуючи вміст запиту. Однак якщо це зробити ефективно, це неминуче збільшить затримку, що погіршить взаємодію з користувачем.
Виявлення правильної комбінації технологій для максимального забезпечення конфіденційності, зберігаючи практичність у середовищі Ethereum, є відкритим дослідницьким питанням, і я запрошую криптографів спробувати це зробити.
Ідеальний гаманець для зберігання ключів
На додаток до транспортування та доступу до стану, інший важливий робочий процес, який має безперебійно працювати в контекстах рівня 2, — це зміна конфігурації автентифікації облікового запису: зміна ключів (наприклад, відновлення) чи внесення глибших змін до всієї логіки обліковий запис. Тут є три рівні рішень у порядку зростання складності:
Повторне відтворення оновлень: коли користувач змінює свою конфігурацію, повідомлення про авторизацію цієї зміни буде відтворено в кожному ланцюжку, де гаманець виявляє, що користувач володіє активами. Потенційно формати повідомлень і правила перевірки можуть бути незалежними від ланцюжка і тому автоматично відтворюватися в якомога більшій кількості ланцюжків.
Сховище ключів на L1: інформація про конфігурацію знаходиться на L1, а гаманець на L2 зчитує її за допомогою L1SLOAD або віддалених статичних викликів. Таким чином, вам потрібно лише оновити конфігурацію на L1, і конфігурація автоматично почне діяти.
Сховище ключів на L2: інформація про конфігурацію існує на L2, а гаманець на L2 зчитує її за допомогою ZK-SNARK. Це те саме, що й (2), за винятком того, що оновлення сховища ключів можуть бути дешевшими, але читання, з іншого боку, дорожче.
Рішення (3) особливо потужне, оскільки воно добре поєднується з конфіденційністю. У звичайному «рішенні конфіденційності» користувач має секрет s, публікує «ліцеве значення» L у ланцюжку, і користувач доводить, що L = hash(s, 1) і N = hash(s, 2) для деяких (s, 2) вони контролюють секрети, які ніколи не були розкриті). Інвалідатор N видається таким чином, що майбутні витрати того самого аркуша будуть невдалими без виявлення L, що залежить від безпеки користувача. Рішення конфіденційності, зручне для відновлення, скаже: s — це розташування (наприклад, адреса та слот для зберігання) у мережі, і користувач повинен підтвердити запит стану: L = hash(sload(s), 1) .
Безпека Dapp
Найслабшою ланкою в безпеці користувача часто є програма. У більшості випадків користувачі взаємодіють із програмами, відвідуючи веб-сайт, який неявно завантажує код інтерфейсу користувача в реальному часі з сервера, а потім виконує його в браузері. Якщо зламано сервер або DNS, користувачі отримають підроблену копію інтерфейсу, яка може обманом змусити їх виконувати довільні дії. Такі функції гаманця, як симуляції торгівлі, дуже допомагають зменшити ризик, але вони далекі від досконалості.
В ідеалі ми б перевели екосистему на керування версіями вмісту в ланцюжку: користувачі мали б доступ до dapp через своє ім’я ENS, яке містило б хеш IPFS інтерфейсу. Для оновлення інтерфейсу потрібна транзакція в ланцюжку від multisig або DAO. Гаманець показуватиме користувачам, чи взаємодіють вони з більш безпечним інтерфейсом on-chain або менш безпечним інтерфейсом Web2. Гаманці також можуть показувати користувачам, чи взаємодіють вони з ланцюжком безпеки (наприклад, Етап 1+, кілька перевірок безпеки).
Для користувачів, які піклуються про конфіденційність, гаманець також може додати параноїдальний режим, який вимагає від користувачів клацання, щоб прийняти HTTP-запити, а не лише операції web3:
Можлива модель інтерфейсу для параноїдального режиму
Більш просунутий підхід полягав би у тому, щоб вийти за рамки HTML + Javascript і написати бізнес-логіку dapp спеціальною мовою (можливо, відносно тонке накладання на Solidity або Vyper). Потім браузер може автоматично генерувати інтерфейс користувача для будь-якої бажаної функції. OKContract вже це робить.
Іншим напрямком є криптоекономічний захист інформації: розробники програмних додатків, охоронні компанії, розгортачі ланцюгів та інші можуть встановити заставу, яка буде виплачена одержувачу, якщо програму буде зламано або завдано шкоди користувачам у дуже оманливий спосіб ) вирішуються деякими DAO у ланцюзі. Гаманець може відображати оцінку користувачеві на основі розміру облігації.
довгострокове майбутнє
Вищевказане все в контексті традиційного інтерфейсу, який включає вказівку та натискання елементів і введення текстів у текстові поля. Однак ми також стоїмо на порозі більш глибокої зміни парадигми:
Штучний інтелект, який може привести нас від парадигми «натисни для введення» до парадигми «скажи, що ти хочеш зробити, і робот це зрозуміє».
Інтерфейси мозок-комп’ютер, починаючи від «м’яких» методів, таких як відстеження очей, до більш прямих і навіть інвазивних методів (див.: перший цьогорічний пацієнт Neuralink)
Проактивний захист на стороні клієнта: Brave Browser проактивно захищає користувачів від реклами, трекерів та багатьох інших небажаних об’єктів. У багатьох браузерах, плагінах і криптогаманцях цілі команди активно працюють над захистом користувачів від різних загроз безпеці та конфіденційності. Ці «позитивні опікуни» лише зміцняться протягом наступного десятиліття.
Разом ці три тенденції призведуть до глибшого перегляду того, як працюють інтерфейси. Завдяки введенню природною мовою, відстеженню очей або, зрештою, більш прямому інтерфейсу «мозок-комп’ютер» у поєднанні з вашою історією (можливо, включаючи текстові повідомлення, якщо всі дані обробляються локально), «гаманець» може чітко та інтуїтивно зрозуміти, куди ви хочете йти. Потім штучний інтелект може перетворити цю інтуїцію на конкретний «план дій»: серію взаємодій у ланцюзі та поза ланцюгом для досягнення бажаного. Це може значно зменшити потребу в інтерфейсах сторонніх розробників. Якщо користувач все-таки взаємодіє зі сторонньою програмою (або іншим користувачем), штучний інтелект повинен мислити протилежно від імені користувача, ідентифікувати будь-які загрози та запропонувати план дій, щоб їх уникнути. В ідеалі ці штучні інтелекти повинні мати відкриту екосистему, яку створюють різні групи з різними упередженнями та структурами стимулів.
Ці більш радикальні ідеї залежать від технологій, які сьогодні є дуже незрілими, тому я б не став класти свої активи в гаманець, який сьогодні покладається на них. Однак здається очевидним, що щось подібне – це шлях майбутнього, тому варто почати активніше досліджувати в цьому напрямку.
