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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приватність

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

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

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

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

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

Етер