Впровадження транзакцій cross-L2 для користувачів

Тепер є все більш деталізована дорожня карта для поліпшення користувацького досвіду переходу між різними рівнями (L2), яка має короткострокову та довгострокову частини. Тут я розповім про короткострокову частину: ідеї, які теоретично можна реалізувати вже сьогодні.

Основні ідеї - це (i) вбудовані кросс-Л2 пересилки та (ii) ланцюжко-специфічні адреси та запити на оплату. Ваш гаманець повинен надати вам адресу, яка (відповідно до стилю цей проект ERC) виглядає таким чином:

0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@optimism.eth

Коли хтось (або додаток) надає вам адресу у цьому форматі, ви повинні мати можливість вставити її в поле "для" гаманця та натиснути "відправити". Гаманець повинен автоматично обробити цю відправку будь-яким чином, яким він може.

• Якщо у вас вже є достатньо монет потрібного типу на цільовому ланцюжку, відправте монети безпосередньо
• Якщо у вас є монети потрібного типу на іншому ланцюжку (або кількох інших ланцюжках), використовуйте протокол, подібний до gate.ERC-7683 (фактично, крос-чейн DEX) для відправлення монет
• Якщо у вас є монети іншого типу на тій самій або інших ланцюжках, скористайтеся децентралізованими біржами, щоб перетворити їх у правильний тип монети на правильному ланцюжку та надіслати їх. Для цього потрібен явний дозвіл від користувача: користувач побачить, скільки з чого вони платять і скільки отримує отримувач.

Макет можливого інтерфейсу гаманця з підтримкою адреси міжланцюжкового зв'язку

Вищевказане стосується «скопіювання адреси (або ENS, наприклад,vitalik.eth@optimism.eth) для когось, щоб заплатити вам” використання. Якщо додаток запитує депозит (наприклад, див. цей приклад полімаркету), то ідеальним потоком є розширення web3 API і дозвіл децентралізованій програмі робити запит на оплату для конкретного ланцюга. Тоді ваш гаманець зможе задовольнити цей запит будь-яким способом. Щоб забезпечити хорошу роботу користувацького досвіду, також знадобиться стандартизація запиту getAvailableBalance, і гаманцям потрібно буде серйозно продумати, в яких мережах вони зберігають активи користувачів за замовчуванням, щоб максимізувати безпеку та простоту переказів.

Запити на оплату для конкретного ланцюжка також можуть бути поміщені в QR-коди, які можуть сканувати мобільні гаманці. У сценарії особистих (або онлайн) споживчих платежів одержувач зробить виклик QR-коду або web3 API, який говорить: «Я хочу X одиниць токена Y в ланцюжку Z, з ідентифікатором посилання або зворотним викликом W», і гаманець буде вільний задовольнити цей запит будь-яким способом. Іншим варіантом є протокол посилання на претензію, де гаманець користувача генерує QR-код або URL-адресу, яка містить дозвіл на отримання певної кількості коштів зі свого ончейн-контракту, і завдання одержувача полягає в тому, щоб з'ясувати, як потім перемістити ці кошти на власний гаманець.

Ще одна пов'язана тема - це платежі за газ. Якщо ви отримуєте активи на L2, де у вас ще немає ETH, і вам потрібно відправити транзакцію на цьому L2, гаманець повинен автоматично використовувати протокол (наприклад, RIP-7755) щоб заплатити за газ на ланцюжку, де у вас є ETH. Якщо гаманець очікує, що ви будете робити більше транзакцій на цьому L2 у майбутньому, він також може використовувати DEX, щоб надіслати, наприклад, кілька мільйонів газу, вартого ETH, щоб майбутні транзакції могли безпосередньо витрачати газ там (це дешевше).

Безпека облікового запису

Один зі способів, яким я уявляю виклик безпеки облікового запису, полягає в тому, що гарний гаманець повинен одночасно бути гарним у двох напрямках: (i) захищати користувача від того, щоб розробник гаманця був взламаний або зловмисний, та (ii) захищати користувача від власних помилок.

Помилка «mistakles» ліворуч була навмисною. Однак, побачивши це, я зрозумів, що вона ідеально підходить для контексту, тому вирішив залишити її.

Моє перевагане рішення для понаддесятьроки, це були гаманці з соціальним відновленням та мультипідписом, з градуйованим контролем доступу. Обліковий запис користувача має два рівні ключів: первинний ключ і N опікунів (напр. N = 5). Первинний ключ здатний здійснювати малоцінні та нефінансові операції. Більшість опікунів зобов'язані виконати або (i) важливі операції, наприклад, відправити всю вартість з рахунку, або (ii) змінити первинний ключ або будь-якого з опікунів. За бажанням первинному ключу можна дозволити виконувати важливі операції з блокуванням часу.

Вищесказане є базовою конструкцією, і може бути доповнено. Ключі сеансів і механізми дозволів, такі як ERC-7715, може допомогти підтримувати різні баланси між зручністю та безпекою для різних застосувань. Більш складні архітектури опіки, такі як наявність кількох тривалостей термінового блокування при різних порогах, можуть допомогти максимізувати шанс успішного відновлення легітимного облікового запису, знижуючи ризик крадіжки.

Хто або що повинні бути опікунами?

Для досвідченого користувача криптовалюти, який знаходиться всередині спільноти досвідчених користувачів криптовалюти, життєво важливою опцією є ключі ваших друзів та сім'ї. Якщо ви попросите кожного з них надати вам свою нову адресу, то ніхто не повинен знати, хто вони - насправді ваші опікуни навіть не повинні знати, хто вони одне для одного. Ймовірність того, що вони зговоряться без того, щоб один з них попередив вас, мізерна. Однак для більшості нових користувачів ця опція недоступна.

Друга опція - це інституційні опікуни: фірми, які спеціалізуються на виконанні послуги лише підписування транзакції, якщо вони отримують підтвердження, що запит надійшов від вас: наприклад, код підтвердження або, для користувачів з великими сумами, відеодзвінок. Люди намагалися створити їх протягом довгого часу, наприклад, Я профілював CryptoCorp в 2013 році. Однак, до цього часу такі фірми не були дуже успішними.

Третя опція - це кілька особистих пристроїв (наприклад, телефон, настільний комп'ютер, апаратний гаманець). Це може працювати, але також складно налаштувати та керувати для неопітних користувачів. Існує також ризик втрати або крадіжки пристроїв одночасно, особливо якщо вони знаходяться в одному місці.

Останнім часом ми почали бачити більше гаманців на основі парольних ключів. Парольні ключі можна резервувати лише на ваших пристроях, що робить їх типом рішення для особистих пристроїв, або резервувати в хмарі, що робить їх безпеку залежною від складний гібриднийПро безпеку паролів, інституційні та довірені апаратні припущення. Реалістично, ключі доступу є цінним засобом безпеки для звичайних користувачів, але самі по собі вони недостатньо міцні, щоб захистити накопичення користувача на все життя.

На щастя, завдяки ZK-SNARKs у нас є четверта опція: централізований ідентифікатор у ZK-обгортці. Цей жанр включаєzk-email, Анон Aadhaar, Myna гаманець, і багато інших. В основному, ви можете взяти багато форм (корпоративних або урядових) централізованих ідентифікаторів і перетворити їх на адресу Ethereum, з якої ви можете відправляти тільки транзакції, згенерувавши доведення володіння централізованим ідентифікатором ZK-SNARK.

З цим додаванням у нас тепер є широкий вибір можливостей, а ZK-wrapped централізований ID є унікально «дружнім для новачків».

Для того, щоб це працювало, його потрібно реалізувати зі спрощеним та інтегрованим інтерфейсом користувача: ви повинні мати змогу просто вказати, що ви хочете “example@gmail.comяк опікувач, і він автоматично має генерувати відповідну адресу Ethereum zk-email під капотом. Досвідчені користувачі повинні мати змогу ввести свою електронну пошту (разом зі значенням солі, можливо, для забезпечення конфіденційності, що буде збережено у цій електронній пошті) в сторонню програму з відкритим кодом і підтвердити, що згенерована адреса є правильною. Те ж саме має бути правдою для будь-якого іншого підтримуваного типу опікуна.

Макет можливого інтерфейсу безпеки

Зверніть увагу, що на сьогодні, одна з практичних проблем з zk-email полягає в тому, що вона залежить від Підписи DKIM, які використовують ключі, які обертаються раз на кілька місяців, і ці ключі самі по собі не підписані жодною іншою владою. Це означає, що у zk-пошті сьогодні є певний рівень вимоги до довіри поза самими постачальниками; це можна зменшити, якщо у zk-пошті використовується TLSNotary всередині довіреного обладнання для перевірки оновлених ключів, але це не ідеально. Будемо сподіватися, що постачальники послуг електронної пошти почнуть підписувати свої ключі DKIM безпосередньо. Сьогодні я б рекомендував використовувати zk-email для одного опікуна, але не для більшості ваших опікунів: не зберігайте кошти в умовах, коли злом zk-email означає, що ви втратите доступ до своїх коштів.

Нові користувачі та вбудовані гаманці

Нові користувачі реалістично не захочуть вводити велику кількість опікунів під час своєї першої реєстрації. Тому гаманці повинні надати їм дуже простий варіант. Один з природних шляхів - це 2 з 3 за допомогою zk-email на їх адресу електронної пошти, ключа, збереженого локально на пристрої користувача (який може бути ключем доступу), та резервного ключа, яким володіє постачальник. Коли користувач стає більш досвідченим або накопичує більше активів, в якийсь момент йому слід буде запросити додати більше опікунів.

Гаманці, інтегровані в додатки, є необхідними, оскільки додатки, які намагаються звернутися до користувачів, які не використовують криптовалюту, не хочуть заплутаного користувацького досвіду, коли їх просять завантажити два нових додатки (сам додаток, плюс гаманець Ethereum) одночасно. Однак користувач багатьох додаткових гаманців повинен мати змогу пов'язати всі свої гаманці разом, щоб вони мали тільки одну "річ для контролю доступу", про яку треба турбуватися. Найпростіший спосіб зробити це - ієрархічна схема, де є швидкий процес "пов'язування", який дозволяє користувачу встановити свій основний гаманець як опікун всіх їх додаткових гаманців. Клієнт Farcaster Warpcast вже підтримує це:

За замовчуванням вашим обліковим записом Warpcast керує команда Warpcast. Однак ви можете «прийняти власність над» своїм обліковим записом Farcaster і змінити адресу відновлення на власну.

Захист користувачів від шахрайства та інших зовнішніх загроз

Помимо безопасности аккаунта, сегодня кошельки делают многое для выявления фальшивых адресов, фишинга, мошенничества и других внешних угроз, и пытаются защитить своих пользователей от таких угроз. В то же время, многие меры по противодействию все еще довольно примитивны: например, требуются переходы для отправки ETH или других токенов на любой новый адрес, независимо от того, отправляете ли вы $100 или $100,000. Здесь нет единого волшебного решения; это серия медленных постоянных исправлений и улучшений в разных категориях угроз. Однако, здесь есть много ценности в продолжении тяжелой работы по улучшению.

Приватність

Зараз настав час серйозніше ставитися до конфіденційності на Ethereum. Технологія ZK-SNARK зараз дуже розвинена, конфіденційні технології, які пом'якшують регуляторні ризики без покладанняся на засуви, такі як Приватні пули, стають більш дорослими, а вторинна інфраструктура, така як Wakuі пули пам'яті ERC-4337 поступово стають більш стабільними. Однак до цього часу для здійснення приватних переказів на Ethereum користувачам потрібно було явно завантажувати й використовувати "конфіденційний гаманець", такий як Залізниця (або Амбрадляприховані адресиЦе додає великі незручності та зменшує кількість людей, які готові здійснювати приватні перекази. Рішенням є те, що приватні перекази потрібно інтегрувати безпосередньо в гаманці.

Проста реалізація виглядає наступним чином. Гаманець може зберігати певну частину активів користувача як «приватний баланс» у приватному пулі. Коли користувач здійснює переказ, спочатку він автоматично знімає кошти з приватного пулу. Якщо користувачу потрібно отримати кошти, гаманець може автоматично створити приховану адресу.

Додатково, гаманець може автоматично генерувати нову адресу для кожного додатку, в якому бере участь користувач (наприклад, протокол 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, щоб отримати від них будь-яку інформацію про ланцюг. Це уразливість двома способами:

1. Постачальник RPC може спробувати вкрасти гроші, подавши їм неправдиву інформацію, наприклад, про ринкові ціни
2. Постачальник RPC може витягнути приватну інформацію про те, з якими програмами та іншими обліковими записами користувач взаємодіє

Ідеально, ми хочемо закрити обидві ці дірки. Щоб закрити першу, нам потрібні стандартизовані легкі клієнти для L1 та L2, які безпосередньо перевіряють консенсус блокчейна.Геліос вже робить це для L1 й провів попередню роботу для підтримки деяких конкретних L2. Щоб належним чином покрити всі L2, нам потрібен стандарт, за допомогою якого конфігураційний контракт, що представляє L2 (також використовується для адрес, специфічних для ланки), може оголосити функцію, можливо, у подібний спосіб, ERC-3668, що містить логіку отримання останніх коренів стану та перевірку доказів стану та квитанцій на основі цих коренів стану. Таким чином, ми можемо мати універсального легкого клієнта, що дозволяє гаманцям безпечно перевіряти будь-який стан або події на L1 та L2.

Для забезпечення конфіденційності, сьогодні єдиним реалістичним підходом є запуск власного повного вузла. Однак, оскільки L2s входять в гру, запуск повного вузла для всього стає все складніше. Еквівалентом легкого клієнта тут єприватний інформаційний доступ (PIR). PIR включає в себе сервер, який має копію всіх даних, і клієнт надсилає серверу зашифрований запит. Сервер виконує обчислення над усіма даними, які повертають бажані дані клієнта, зашифровані ключем клієнта, не розкриваючи серверу, який шматок даних клієнт отримав.

Щоб зберегти чесність сервера, окремі елементи бази даних були б власними гілками Меркля, тому клієнт міг би перевірити їх, використовуючи свій легкий клієнт.

PIR дуже витратний на обчислення. Є кілька шляхів обійти цю проблему:

• Жорстока сила: вдосконалення алгоритмів або спеціалізованого обладнання може зробити PIR достатньо швидким для запуску. Ці техніки можуть залежати від передобробки: сервери можуть зберігати зашифровані та перемішані дані для кожного клієнта, а клієнти можуть запитувати ці дані. Основним викликом в Ethereum-середовищі є адаптація цих технік до наборів даних, які швидко змінюються (як стан робить). Це знижує витрати на обчислення в реальному часі, але може збільшити загальні витрати на обчислення та зберігання.
• Знизити вимогу до конфіденційності: наприклад, кожен пошук може мати лише 1 мільйон "міксінів", тому сервер буде знати мільйон можливих значень, до яких клієнт міг мати доступ, але не буде знати більшої деталізації
• Багатосерверний PIR: Алгоритми PIR часто працюють набагато швидше, якщо ви використовуєте кілька серверів з припущенням чесності 1 з N між цими серверами.
• Анонімність замість конфіденційності: замість приховання вмісту запиту, запит можна відправити через мережу змішування, приховуючи відправника запиту. Однак, це ефективно неодмінно збільшує затримку, погіршуючи враження користувача.

Визначення правильної комбінації технік для максимізації конфіденційності при збереженні практичності в контексті Ethereum є відкритою дослідницькою проблемою, і я вітаю криптографів, які намагаються її вирішити.

Ідеальні гаманці зберігання ключів

Окрім переказів та доступу до стану, ще один важливий робочий процес, який повинен працювати безперешкодно в контексті між-L2, - це зміна конфігурації перевірки облікового запису: чи зміна його ключів (наприклад, відновлення), або глибока зміна всієї логіки облікового запису. Тут існують три рівні рішень, в порядку зростання складності:

1. Оновлення повторено: коли користувач змінює свою конфігурацію, повідомлення, що авторизує цю зміну, повторюється на кожному ланцюжку, де гаманець виявляє, що у користувача є активи. Потенційно, формат повідомлення та правила перевірки можуть бути незалежними від ланцюжка, тому його можна автоматично повторити на якомога більшій кількості ланцюжків.
2. Keystores на L1: інформація про конфігурацію знаходиться на L1, а гаманець на L2 читає її з L1SLOADабоREMOTESTATICCALLТаким чином, оновлення конфігурації потрібно виконувати лише на L1, і конфігурація автоматично стає дієвою.
3. Keystores on L2: інформація конфігурації знаходиться на L2, а гаманець на L2 читає її за допомогою ZK-SNARK. Це так само, як (2), за винятком того, що оновлення ключових сховищ можуть бути дешевшими, хоча, з іншого боку, читання коштує більше.

Рішення (3) є особливо потужним, оскільки воно добре поєднується з конфіденційністю. У звичайному «рішенні конфіденційності» користувач має секрет s, «значення листка» L публікується в ланцюжку, і користувач доводить, що L = хеш(и, 1) і N = хеш(и, 2) для деякої (ніколи не розкритої) таємниці, яку він контролює. Нуліфікатор N публікується, переконуючись, що майбутні витрати одного і того ж листа зазнають невдачі, ніколи не розкриваючи L. Це залежить від безпеки користувача. Натомість у зручному для відновлення рішенні конфіденційності буде сказано: s — це місце розташування (наприклад, адреса та слот для зберігання) ончейн, і користувач повинен довести запит стану: L = hash(sload(sload(s), 1) .

Безпека Dapp

Найбільшою слабкою ланкою в безпеці користувача часто є dapp. Більшість часу користувач взаємодіє з додатком, перейшовши на веб-сайт, який неявно завантажує код інтерфейсу користувача в реальному часі з сервера, а потім виконує його в браузері. Якщо сервер взламаний, або якщо взломаний DNS, користувач отримає фальшиву копію інтерфейсу, яка може обманути користувача на виконання довільних дій. Функції гаманця, такі як симуляції транзакцій, дуже допомагають у пом'якшенні ризиків, але вони далекі від ідеальних.

Ідеальною ситуацією було б перемістити екосистему до версіонування вмісту на ланцюжку: користувач міг би отримати доступ до додатку за його іменем ENS, в якому міститься хеш IPFS інтерфейсу. Для оновлення інтерфейсу потрібна була б транзакція на ланцюжку від мультипідпису або DAO. Гаманці показували б користувачам, чи вони взаємодіють з більш безпечним інтерфейсом на ланцюжку чи менш безпечним веб-інтерфейсом. Гаманці також могли б показувати користувачам, чи вони взаємодіють з безпечним ланцюжком (наприклад, етап 1+, кілька перевірок безпеки).

Для користувачів, які стежать за конфіденційністю, гаманці також можуть додати параноїдальний режим, що вимагає від користувачів підтвердження HTTP-запитів та не лише операцій web3 через натискання.

Макет можливого інтерфейсу для параноїдального режиму

Більш передовий підхід полягає в тому, щоб вийти за межі HTML + Javascript та написати бізнес-логіку dapps на спеціалізованій мові, можливо, на досить тонкому накладанні на Solidity або Vyper. Тоді браузери можуть автоматично генерувати користувацький інтерфейс для будь-якої необхідної функціональності. OKContractвже робить це.

Ще одним напрямком є криптоекономічний захист інформації: розробники додатків, фірми з безпеки, розгортальники ланцюгів та інші можуть внести заставу, яка буде виплачуватися постраждалим користувачам, якщо додаток був взламаний або іншим чином завдав шкоди користувачам, діючи в дуже обманливий спосіб, як визначено деяким DAO для арбітражу на ланцюгу. Гаманець може показати користувачеві оцінку, яка базується на розмірі застави.

Довгострокове майбутнє

Вищезазначене стосувалося всього в контексті традиційних інтерфейсів, які включають вказування та клацання на речі та введення речей у текстові поля. Однак ми також на порозі глибокого зміни парадигм:

• Штучний інтелект може призвести до переходу від парадигми «клацання та набору тексту» до парадигми «говоріть, що ви хочете зробити, а бот зрозуміє».
• Інтерфейси між мозком та комп'ютером, як "легкі" підходи, такі як відстеження очей, а також більш прямі та навіть інвазивні техніки (див.:перший пацієнт Neuralink цього року)
• Клієнти, які займаються активною захистом: браузер Braveактивно захищає користувачів від реклами, трекерів та багатьох інших небажаних об'єктів. У багатьох браузерах, плагінах і криптогаманцях цілі команди активно працюють над захистом користувачів від усіх видів загроз безпеці та конфіденційності. Такого роду «активні охоронці» в найближче десятиліття стануть тільки більш потужними.

Ці три тенденції разом призведуть до набагато глибшого переосмислення того, як працюють інтерфейси. За допомогою введення природною мовою, відстеження очей або, врешті-решт, більш прямого BCI, разом зі знанням вашої історії (можливо, включаючи текстові повідомлення, якщо всі дані обробляються локально), «гаманець» може отримати чітке інтуїтивне уявлення про те, що ви хочете зробити. Потім штучний інтелект може перетворити цю інтуїцію на конкретний «план дій»: серію ончейн і офчейн взаємодій, які досягають того, що ви хочете. Це може значно зменшити потребу в сторонніх інтерфейсах користувача. Якщо користувач взаємодіє зі стороннім додатком (або іншим користувачем), штучний інтелект повинен мислити змагально від імені користувача, виявляти будь-які загрози та пропонувати плани дій для їх уникнення. В ідеалі має існувати відкрита екосистема цих штучних інтелектів, створених різними групами з різними упередженнями та структурами стимулювання.

Ці більш радикальні ідеї залежать від технології, яка сьогодні є дуже неспіввідносною, тому я б не вкладав свої активи сьогодні в гаманець, який на них покладається. Однак щось подібне, здається, досить чітко є майбутнім, тому варто почати активніше досліджувати цим напрямком.

Відмова від відповідальності:

1. Ця стаття перепечатана з [ Віталік]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з Gate Learnкоманда і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою вивчення воріт. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонене.