Бачення ідеального гаманця Ethereum: всебічне вдосконалення від крос-ланцюгового досвіду до захисту конфіденційності

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

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

Користувацький досвід крос-ланцюгових L2 транзакцій

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

Основна ідея полягає в (i) вбудованому крос-ланцюговому відправленні L2, а також (ii) адресах специфічних для ланцюга та платіжних запитах. Гаманець має забезпечити користувача адресою, яка відповідає стилю відповідних проектів ERC.

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

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

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

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

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

Безпека рахунку

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

За замовчуванням відновлення деяких вбудованих облікових записів користувача може контролюватися командою розробників програми. Проте користувач може "перехопити" свій обліковий запис і змінити відновлення на власну адресу.

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

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