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

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

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

Досвід користувачів при крос-ланцюгових операціях L2

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

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

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

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

Це стосується сценарію "копіювання та вставлення адреси для платежу". У випадку, коли dapp запитує депозит, ідеальним рішенням є розширення web3 API, що дозволяє dapp надсилати специфічні для ланцюга платіжні запити. Гаманець може гнучко задовольнити цей запит. Для забезпечення хорошого користувацького досвіду також необхідно стандартизувати запит getAvailableBalance, гаманець має серйозно розглянути, на яких ланцюгах за замовчуванням зберігаються активи користувача, щоб збалансувати безпеку та зручність переказів.

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

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

![Vitalik нова стаття: бачення ідеального Гаманця, всебічне оновлення від крос-ланцюгового досвіду до захисту приватності])https://img-cdn.gateio.im/webp-social/moments-e340d9eff581bff30a541c8aac3178af.webp(

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

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

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

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

( Вибір опікуна

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

Другий варіант - це нагляд з боку установи: спеціалізовані послуги, які підписують транзакції лише після отримання додаткової підтверджуючої інформації за запитом користувача ), такої як код підтвердження або відеозв'язок з високовартісним користувачем ###. Хоча протягом тривалого часу існують спроби створити такі послуги, наразі вони не є дуже успішними.

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

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

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

Централізований 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 або інші токени на будь-яку нову адресу, незалежно від суми переказу. Тут немає єдиного панацеї, а скоріше цілий ряд постійних покращень, спрямованих на різні категорії загроз. Продовження роботи над покращенням в цій сфері є дуже цінним.

![Vitalik нова стаття: Візія ідеального Гаманця, всебічне оновлення від крос-ланцюгового досвіду до захисту приватності])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp###

Приватність

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

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

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

Ця технологія є не лише природним шляхом для захисту приватних активів, а й природним шляхом для захисту приватної особи. Ідентичність вже існує в ланцюгу: будь-який застосунок з контролем доступу за допомогою посвідчення особи (, як-от Gitcoin Grants ), будь-який токенізований чат, протоколи, що слідують за Ethereum, тощо, є ідентичністю в ланцюгу. Ми сподіваємося, що ця екосистема також зможе захистити приватність. Це означає, що активність користувачів у ланцюзі не повинна збиратися в одному місці: кожен проєкт має зберігатися окремо, а гаманець користувача має бути єдиним об'єктом з "глобальним оглядом", що дозволяє одночасно бачити всі підтвердження. Наявна екосистема, в якій кожен користувач має кілька облікових записів, сприяє досягненню цієї мети, так само як і протоколи підтвердження поза ланцюгом, такі як EAS і Zupass.

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