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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вищезазначене є базовим дизайном, який можна розширити. Ключі сесії та такі механізми доступу, як 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 ) створює хаотичний користувацький досвід. Однак багато користувачів гаманців додатків повинні мати можливість з'єднати всі свої гаманці, щоб їм потрібно було турбуватися лише про одну "проблему контролю доступу". Найпростіший спосіб - це прийняти ієрархічну схему, у якій є швидкий "лінк" процес, що дозволяє користувачам налаштувати свій основний гаманець як опікуна всіх внутрішніх гаманців.

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

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

Приватність

Зараз час почати більш серйозно ставитись до Ефіру