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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Щодо вибору опікуна, існує кілька варіантів:

1. Для досвідчених користувачів криптовалют можна вибрати ключі друзів і родини.
2. Інституційний опікун: компанія, яка спеціалізується на наданні послуг підпису, потребує додаткового підтвердження інформації.
3. Кілька особистих пристроїв (, таких як мобільний телефон, комп'ютер, апаратний гаманець ), але новим користувачам може бути важко налаштувати управління.
4. Рішення на основі менеджера паролів, яке може зберігатися локально або в хмарі, але лише їх недостатньо для захисту всіх активів користувача.
5. Централізований ID на базі ZK: такі як zk-email, Anon Aadhaar тощо, можуть перетворити централізований ID на адресу Ethereum.

Централізовані ID на базі ZK є більш дружніми до нових користувачів. Гаманець має забезпечити спрощений інтегрований інтерфейс, що дозволяє користувачам безпосередньо вказувати електронну пошту як опікуна та автоматично генерувати відповідну zk-email адресу Етер. Досвідчені користувачі повинні мати можливість перевірити правильність згенерованої адреси.

Для нових користувачів гаманець може запропонувати прості варіанти, такі як схема 2 з 3 на основі zk-email, локального зберігання ключів і резервного копіювання ключів постачальника. У міру зростання досвіду користувачів або збільшення активів слід запропонувати додати більше опікунів.

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

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

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

Приватність

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

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

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

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

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

Гаманець Ethereum також має стати даними гаманець

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

Гаманець не тільки потребує зберігання доступу до ланцюга, але й потребує зберігання приватних даних користувача. Ненадійний світ також все більше усвідомлює це. Нам потрібно побудувати надійні гарантії навколо доступності даних і запобігання витокам. Можливо, ці рішення можна накладати: якщо є N опікунів, використовувати M-з-N секретне розподілення для зберігання даних між цими N опікунами. Дані за своєю суттю важче захистити, оскільки не можна відкликати частку даних когось, але ми повинні запропонувати якомога більш безпечні рішення для децентралізованого зберігання.

Безпечний доступ до ланцюга

Наразі гаманець покладається на постачальників RPC для отримання інформації про ланцюг, що має два недоліки:

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

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

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

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

Обчислення PIR є дуже великими. Рішення включають:

• Брутальна сила: алгоритми або спеціалізоване обладнання можуть зробити виконання PIR достатньо швидким.
• Послаблення вимог до конфіденційності: наприклад, кожного разу лише 1 мільйон "mixins".
• Багато серверів PIR: використання кількох серверів, припускаючи, що 1 з N чесний, алгоритм PIR зазвичай швидший.
• Анонімність, а не конфіденційність: надсилання запитів через змішану мережу, приховуючи відправника, а не вміст. Але це збільшує затримки.

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

Ідеальний гаманець для ключів

У контексті крос-L2 важливим процесом, який також потребує безперебійної роботи, є зміна верифікації облікового запису.