Автор: Віталік, засновник Ethereum Переклад: Jinse Finance cryptonaitive
Оскільки Ethereum розвивається від молодої експериментальної технології до зрілого технологічного стеку, здатного забезпечувати відкритий, глобальний і бездозвільний досвід звичайним користувачам, є три основні технологічні переходи, які мають відбутися одночасно:
Перший — це трансформація розширення ємності L2 — усі звертаються до технології Rollup;
По-друге, це трансформація безпеки гаманця – усі починають використовувати гаманці зі смарт-контрактами;
Третє — це трансформація конфіденційності — забезпечення доступності функції переказу коштів із збереженням конфіденційності та забезпечення того, щоб усі інші інструменти, що розробляються (соціальне відновлення, перевірка особи, репутація тощо), мали функції збереження конфіденційності.
*Трикутник трансформації екосистеми Ethereum. Ви можете вибрати лише всі три. *
Без першого елемента Ethereum зазнає невдачі, тому що кожна транзакція коштує 3,75 доларів США (82,48 доларів США, якщо ми перейдемо до ще одного підвищення), і кожен продукт для масового ринку неминуче відмовиться від онлайн-торгівлі та прийме централізоване рішення.
Без другого пункту Ethereum зазнав би невдачі, оскільки користувачі не бажали б зберігати свої кошти (і нефінансові активи), і всі звернулися б до централізованих бірж.
Без третього пункту Ethereum зазнав би невдачі, тому що для багатьох користувачів усі транзакції (і POAP тощо) були б загальнодоступними, жертва конфіденційністю була б надто великою, і кожен звернувся б до централізованого рішення прихованих даних хоча б на певному рівні.
З причин, описаних вище, ці три переходи є критичними. Але вони також є складними через складність координації. Удосконалення потребує не лише функціональність протоколу; у деяких випадках спосіб взаємодії з Ethereum потребує фундаментальних і глибоких змін, що потребує серйозних змін у програмах і гаманцях.
Ці три перетворення принципово змінять відносини між користувачами та адресами
У світі масштабування L2 користувачі будуть існувати в кількох мережах L2. Ви є учасником ExampleDAO? ExampleDAO працює на оптимізмі. Тоді у вас є рахунок у Optimism! У вас є CDP системи стейблкойнів на ZkSync? Тоді у вас є обліковий запис на ZkSync! Ви коли-небудь пробували деякі програми, розміщені на Kakarot? Тоді у вас є обліковий запис на Kakarot! Часи, коли користувачі мали лише одну адресу, минули.
*Мій перегляд гаманця Brave, я тримаю Ethereum у чотирьох місцях. Так, Arbitrum і Arbitrum Nova різні. Не хвилюйтеся, з часом все ускладнюватиметься! *
** Гаманці з розумними контрактами додають ще більше складності, оскільки ускладнюють наявність однакової адреси в мережах L1 і в різних мережах L2. **Більшість користувачів сьогодні використовують зовнішні облікові записи, адреси яких фактично є хешами відкритих ключів, які використовуються для перевірки підписів, тому нічого не змінюється між рівнями L1 і L2. Однак підтримка адреси стає складнішою при використанні смарт-контрактного гаманця. Хоча було зроблено багато роботи, щоб спробувати зробити адреси хеш-кодом, еквівалентним у різних мережах, найважливішими з яких є CREATE2 і ERC-2470 singleton factory, важко досягти цього ідеально. Деякі мережі L2 (наприклад, «ZK-EVM четвертого типу») не зовсім еквівалентні EVM, часто використовують Solidity або проміжну мову асемблера, а не хеш-еквіваленти. Навіть якщо хеш-еквівалентність може бути досягнута, можливість зміни власника гаманців через ключові зміни призводить до інших менш передбачуваних наслідків.
**Конфіденційність вимагає більшої кількості адрес на користувача та може навіть змінити типи адрес, які ми обробляємо. **Якщо пропозиція прихованої адреси широко використовується, користувачі можуть мати одну адресу на транзакцію замість кількох адрес на користувача або однієї адреси на мережу L2. Інші схеми конфіденційності, навіть існуючі, такі як Tornado Cash, по-різному змінюють спосіб зберігання активів: кошти багатьох користувачів зберігаються в одному смарт-контракті (і, отже, на одній адресі). Щоб надіслати кошти певному користувачеві, користувач повинен буде покладатися на власну внутрішню систему адресації схеми конфіденційності.
Як ми бачили, ці три перетворення по-різному послаблюють розумову модель «один користувач ≈ одна адреса», деякі з яких, у свою чергу, збільшують складність виконання цих перетворень. Два особливо складних питання:
**1. Якщо ви хочете комусь заплатити, як ви отримаєте платіжну інформацію? **
**2. Якщо користувачі зберігають активи в різних місцях у різних мережах, як вони виконують ключові зміни та соціальне відновлення? **
Ці три трансформації та платежі в мережі (і ідентифікація)
Я тримаю жетони на Scroll і хочу на них купити каву (якщо буквальне «я» стосується Віталіка, автора цієї статті, то «кава», звичайно, означає «зелений чай»). Ви продаєте каву на Taiko, але приймаєте лише жетони на Taiko. що робити?
В основному є два рішення:
Гаманець-одержувач (яким може бути торговець або звичайна особа) прагне підтримувати кожен L2 і має деякі функції асинхронного злиття коштів.
Одержувач платежу надає свою інформацію рівня L2 поруч із адресою, а гаманець відправника автоматично направляє кошти до цільового рівня L2 через певну систему перехресного зв’язку L2.
Звичайно, ці рішення можна використовувати в комбінації: одержувач надає список рівня L2, який він готовий прийняти, а гаманець відправника визначає метод платежу, який можна надіслати безпосередньо (якщо пощастить) або сплатити за допомогою мостового шляху через L2.
Але це лише один із прикладів ключових труднощів, пов’язаних із трьома перетвореннями: Прості способи оплати починають вимагати більше інформації, ніж просто 20-байтова адреса.
На щастя, перехід на смарт-контрактні гаманці не є великим тягарем для адресної системи, але все ще є деякі технічні проблеми, які потрібно вирішити в інших частинах стеку програм. Гаманці потрібно оновити, щоб переконатися, що вони не лише надсилають 21000 газу під час надсилання транзакцій, але потрібно приділити більше уваги тому, щоб приймаючий кінець гаманця відстежував не лише перекази ETH від EOA, але й перекази ETH від код смарт-контракту. Програми, які покладаються на незмінне право власності на адреси (наприклад, NFT, які забороняють розумні контракти для стягнення роялті), повинні будуть знайти інші способи досягнення своїх цілей. Гаманці з розумними контрактами також полегшать деякі речі, особливо якщо хтось приймає лише токени ERC20, що не належать до ETH, вони зможуть використовувати платіжну систему ERC-4337 для оплати газу за допомогою цього токена.
З іншого боку, питання конфіденційності знову є великим викликом, який ми ще не вирішили. Оригінальний Tornado Cash не створював цих проблем, оскільки не підтримував внутрішні перекази: користувачі могли лише вносити та знімати гроші в системі. Однак, коли внутрішні передачі стануть можливими, користувачам доведеться використовувати внутрішню схему адресації системи конфіденційності. На практиці «платіжне повідомлення» користувача повинно містити (i) якийсь «відкритий ключ витрати», секретне зобов’язання, яке одержувач може використати для витрачання, і (ii) відправник може надсилати зашифровані повідомлення, які лише отримувач може розшифрувати. Одержувач допомоги дізнається спосіб оплати.
Протокол невидимої адреси базується на концепції мета-адреси, яка працює наступним чином: частина мета-адреси є ошуканим ключем витрат відправника, а інша частина є зашифрованим ключем відправника (хоча мінімальна реалізація може встановити обидва ключі бути однаковим).
Огляд абстрактних схем скритної адреси на основі шифрування та ZK-SNARK
Ключовий урок тут полягає в тому, що **в екосистемі, яка підтримує конфіденційність, користувачі матимуть відкриті ключі, що витрачають, і відкриті ключі шифрування, а «платіжна інформація» користувачів повинна містити обидва ключі. **Крім оплати, є й інші вагомі причини для розширення цього напрямку. Наприклад, якщо нам потрібні зашифровані електронні листи на основі Ethereum, користувачам потрібно буде публічно надати якийсь ключ шифрування. У «світі EOA» ми могли б повторно використовувати ключі облікового запису, але у світі безпечних гаманців із смарт-контрактами ми, ймовірно, повинні надати для цього більш чіткі функції. Це також допомагає зробити ідентифікатори на основі Ethereum більш сумісними з не-Ethereum децентралізованими екосистемами конфіденційності, особливо з ключами PGP.
Ці три переходи та відновлення ключа
У світі, де кожен користувач має кілька адрес, стандартний спосіб впровадження ключових змін і соціального відновлення полягає в тому, щоб користувачі запускали процес відновлення для кожної адреси окремо. Це можна зробити в один клік: гаманець може надати програмну функцію для виконання процесу відновлення одночасно на всіх адресах користувача. Однак, навіть із таким спрощенням взаємодії з користувачем, є три проблеми з багатоадресним відновленням:
1. Вартість газу нереальна: Це само собою зрозуміло.
2. Контрфактичні адреси: адреси, на які ще не було укладено смарт-контракт (насправді це означатиме рахунки, з яких ви ще не надсилали кошти). Як користувач, ви можете мати нескінченну кількість віртуальних адрес: одну або більше на кожному L2, включаючи L2, які ще не існують, і цілий нескінченний набір віртуальних адрес, що виникають із схеми прихованих адрес.
3. Конфіденційність: якщо користувач навмисно використовує кілька адрес, щоб не пов’язувати їх одна з одною, то він, звичайно, не хоче публічно пов’язувати їх усі, відновлюючи їх одночасно або майже в один і той же час!
Вирішити ці проблеми складно. На щастя, є досить елегантне рішення, яке працює досить добре: Ця архітектура відокремлює логіку перевірки від утримання активів.
Кожен користувач має контракт на сховище ключів, який існує в одному місці (це може бути основна мережа або певний L2). Тоді користувачі мають адреси на різних рівнях L2, і логіка перевірки для кожної адреси є покажчиком на договір сховища ключів. Витрата коштів із цих адрес вимагатиме надання підтвердження поточного (або реалістичніше, зовсім нещодавнього) витраченого відкритого ключа для коштів.
Цей доказ можна отримати кількома способами:
** Доступ лише для читання до L1 безпосередньо в L2. ** L2 можна змінити, щоб дозволити йому безпосередньо читати стан L1. Якщо договір сховища ключів знаходиться на L1, це означає, що контракти на L2 мають «вільний» доступ до сховища ключів.
**Гілки Меркле. **Гілки Меркла можуть підтвердити стан L1 для L2, або стан L2 для L1, або комбінація обох може підтвердити частковий стан одного L2 для іншого L2. Основним недоліком доказів Merkle є висока вартість газу через довжину перевірки, для якої може знадобитися довжина перевірки 5 Кбайт, але через використання дерев Verkle у майбутньому вона буде зменшена до <1 Кбайт.
**ZK-SNARKs. **Ви можете зменшити витрати на передачу даних, використовуючи ZK-SNARK відділень Merkle замість використання самих відділень. Методи позаланцюжкової агрегації (наприклад, на основі EIP-4337) можуть бути створені, щоб дозволити одному ZK-SNARK перевіряти всі докази стану крос-ланцюга в блоці.
**Обіцянка KZG. **Незалежно від того, чи це L2, чи схема, побудована на ньому, система послідовної адресації може бути введена, дозволяючи перевірці стану всередині системи становити лише 48 байт. Подібно до ZK-SNARK, схеми з кількома доказами можуть об’єднати всі ці докази в єдине доказ для кожного блоку.
Якщо ми хочемо уникнути необхідності підтвердження для кожної транзакції, ми можемо реалізувати більш легку схему, яка потребує відновлення лише через підтвердження L2. Витрати з облікового запису залежатимуть від ключа витрат із відповідним відкритим ключем, що зберігається в обліковому записі, але відновлення вимагатиме транзакції для копіювання поточного відкритого ключа витрат у сховище ключів. Навіть якщо ваші старі ключі не захищені, кошти у віртуальній адресі безпечні: «активація» віртуальної адреси, щоб перетворити її на придатний для використання контракт, потребуватиме перехресного підтвердження рівня L2, щоб відтворити поточний відкритий ключ. На форумах Safe є тема, яка описує, як працює подібна архітектура.
Щоб додати конфіденційність такій схемі, нам потрібно лише зашифрувати покажчики та зробити всі докази в ZK-SNARK:
У подальшій роботі (наприклад, використовуючи цю роботу як відправну точку), ми також можемо видалити ZK - Найбільша складність SNARK, побудова більш спрощеної схеми на основі KZG.
Ці сценарії можуть ускладнюватися. Перевагою є те, що між ними є багато потенційних синергій. Наприклад, концепція «контракту сховища ключів» також може бути рішенням «адреси», згаданої в попередньому розділі: якщо ми хочемо, щоб користувачі мали постійну адресу, яка не змінюється кожного разу, коли користувач оновлює ключ, ми Мета-адреса, ключ шифрування та інша інформація вводяться в контракт сховища ключів, а адреса контракту сховища ключів використовується як «адреса» користувача.
Потрібно оновити багато вторинної інфраструктури
Використання ENS коштує дорого. Хоча це не так дорого, як раніше в червні 2023 року, комісія за транзакцію за реєстрацію доменного імені все ще є відносно високою, що можна порівняти з вартістю доменного імені ENS. Наприклад, реєстрація на zuzalu.eth коштує близько 27 доларів США, 11 доларів з яких – комісія за транзакції. Але якщо ринок знову стане бичачим, комісії зростуть. Навіть якщо ціна ETH не зросте, якщо комісія за газ повернеться до 200 gwei, комісія за транзакцію за реєстрацію доменного імені досягне $104. Отже, якщо ми хочемо, щоб люди дійсно використовували ENS, особливо для таких випадків використання, як децентралізовані соціальні медіа, де користувачі просять майже безкоштовну реєстрацію (комісія за домен ENS не є проблемою, оскільки ці платформи можуть надавати користувачам субдомени), нам потрібно використовувати ENS на 2 шар.
На щастя, команда ENS вже активізувалася, і ENS впроваджується на рівні 2! ERC-3668 (також відомий як «стандарт CCIP») і ENSIP-10 забезпечують спосіб автоматичної перевірки субдоменів ENS на будь-якому рівні 2. Стандарт CCIP вимагає створення смарт-контракту, який описує метод перевірки доказів даних на рівні 2, і доменне ім’я (наприклад, ecc.eth для Optinames) може бути поставлено під контроль такого контракту. Після того, як контракт CCIP контролює ecc.eth на L1, доступ до певного субдомену.ecc.eth автоматично знайде та перевірить доказ, що зберігає стан рівня 2 цього конкретного субдомену (наприклад, гілки Merkle).
насправді отримання цих доказів передбачає доступ до списку URL-адрес, збережених у контракті, хоча це є у чомусь це може виглядати як централізація, але я б сказав, що це не так: це модель довіри 1-до-N (недійсні докази будуть виявлені логікою перевірки у функції зворотного виклику контракту CCIP, якщо одна з URL-адрес A який повертає дійсний доказ, це добре). Список URL-адрес може містити десятки URL-адрес.
**Зусилля ENS CCIP є історією успіху, і її слід розглядати як ознаку того, що радикальні реформи, які нам потрібні, насправді можливі. ** Але є ще багато реформ на рівні програми, які потрібно зробити. Ось кілька прикладів:
**Багато DApps покладаються на те, що користувачі надають підписи поза мережею. **Для зовнішніх облікових записів (EOA) це просто. ERC-1271 надає стандартизований спосіб зробити це для гаманців зі смарт-контрактами. Однак багато DApp досі не підтримують ERC-1271, тому їх потрібно адаптувати.
** Програми DApp, які використовують «це EOA?» для розрізнення користувачів і контрактів (наприклад, щоб запобігти передачі або стягнути роялті), виникнуть проблеми. **Загалом я б не радив шукати тут суто технічне рішення; визначення того, чи є певна передача криптографічного контролю передачею бенефіціарного права власності, є складною проблемою, яку неможливо вирішити, не вдаючись до допомоги позамережевої спільноти механізми виріш. Швидше за все, додатки будуть менше покладатися на технічні засоби блокування переказів, а більше на методи, такі як податок Harberger.
**Взаємодію гаманця з виплатами та ключами шифрування потрібно покращити. **Наразі гаманці зазвичай використовують детерміновані підписи для генерації ключів додатків: підписання стандартного nonce (наприклад, хеш назви додатку) за допомогою приватного ключа EOA створить детерміноване значення, якщо приватний ключ не є у власності, інакше значення не може бути згенерований і тому є чисто технічно безпечним. Однак ці методи є «непрозорими» для гаманця, не дозволяючи гаманцям здійснювати перевірки безпеки на рівні інтерфейсу користувача. У більш зрілій екосистемі гаманці мають більш чітко обробляти підпис, шифрування та пов’язані функції.
Легкі клієнти (наприклад, Helios) повинні будуть автентифікувати рівень 2 замість лише рівня 1**. **Наразі легкий клієнт зосереджений на перевірці дійсності інформації заголовка блоку L1 (за допомогою протоколу синхронізації легкого клієнта) і перевірці гілки Merkle стану L1 і транзакцій на основі інформації заголовка блоку L1. У майбутньому їм також потрібно буде перевірити докази стану L2, кореневі в корені стану, що зберігається в L1 (досконаліші версії фактично дивитимуться на попереднє підтвердження L2).
Гаманцям потрібно буде захистити активи та дані
Наразі місія гаманця полягає в захисті активів. Все зберігається в ланцюжку, єдине, що потрібно захистити гаманцю, – це приватні ключі, які зараз захищають ці активи. Якщо ви зміните ключ, ви можете безпечно опублікувати попередній закритий ключ в Інтернеті наступного дня. Однак у світі з нульовими знаннями це вже не так: гаманці не лише захищають облікові дані автентифікації, вони також зберігають ваші дані.
Ми бачимо перші ознаки такого світу в Zuzalu з Zupass, системою ідентифікації на основі ZK-SNARK. Користувач має закритий ключ, який використовується для автентифікації в системі, який можна використовувати для створення базових доказів, таких як «довести, що я є резидентом Zuzalu, не повідомляючи, хто я резидент». Система Zupass також почала створювати інші додатки на її основі, головним чином марки (версія POAP Zupass).
*Одна з багатьох моїх марок Zupass, яка підтверджує, що я є членом Team Cat. *
Ключова особливість штампів щодо POAP полягає в тому, що вони є приватними: ви зберігаєте дані локально та підтверджуєте штамп їхнім ZK (або виконуєте певні обчислення на штампах), якщо бажаєте комусь надати цю інформацію. Але це також пов’язано з додатковим ризиком: якщо ви втратите цю інформацію, ви втратите свої марки.
Звичайно, проблему зберігання даних можна звести до проблеми зберігання єдиного ключа шифрування: третя сторона (навіть у мережі) може зберігати зашифровану копію даних. Це має зручну перевагу в тому, що дія, яку ви виконуєте, не змінює ключ шифрування, тому не потрібно взаємодіяти з системою, яка містить ключ шифрування. Але навіть тоді, якщо ви втратите ключ шифрування, ви втратите всі свої дані. У свою чергу, якщо хтось побачить ваш ключ шифрування, він зможе побачити все, що зашифровано цим ключем. **
Практичне рішення Zupass полягає в тому, щоб заохочувати людей зберігати свої ключі на кількох пристроях (таких як ноутбук і телефон), оскільки ймовірність втрати доступу до них усіх одночасно невелика. Ми можемо піти далі, використовуючи спільний доступ до ключів, щоб розділити сховище ключів між кількома засобами захисту.
Соціальне відновлення через MPC не є адекватним рішенням для гаманців, оскільки це означає, що не лише поточний захисник, але й попередні захисники можуть вступити в змову, щоб викрасти ваші активи, що є неприйнятно високим ризиком. Хоча порушення конфіденційності зазвичай є менш ризикованим, ніж повна втрата активів, для випадків використання з високими потребами конфіденційності можна прийняти вищий ризик втрати, не створюючи резервні копії ключів, пов’язаних із цими потребами конфіденційності.
Щоб уникнути занурення користувачів у складну систему кількох шляхів відновлення, гаманцям, які підтримують соціальне відновлення, може знадобитися керувати обома аспектами відновлення активів і відновленням ключа шифрування.
Назад до ідентичності
Загальною темою цих змін є те, що концепція «адреси» як представлення ідентичності в блокчейні потребує фундаментальних змін. ** «Інструкції щодо взаємодії зі мною» більше не будуть просто адресою ETH; express. **
Одним із цих способів є використання ENS як вашої особи: ваш запис ENS може містити всю інформацію про те, як платити та взаємодіяти з вами. Якщо ви надсилаєте комусь bob.eth (або bob.ecc.eth тощо), вони можуть запитати і дізнаватися про все, що з вами взаємодіє, включно з більш складними способами в різних доменах і із захистом конфіденційності.
Однак цей підхід, орієнтований на ENS, має дві слабкості:
**З вашим іменем асоціюється занадто багато вмісту. **Ваше ім’я не означає все про вас, це лише одна з багатьох ваших характеристик. Повинна бути можливість змінити ваше ім’я без міграції всього профілю особи та оновлення записів у багатьох програмах.
**Ви не можете мати контрфактичні імена, які не потребують довіри. **Ключовою функцією взаємодії з користувачем будь-якого блокчейну є можливість надсилати токени людям, які ще не взаємодіяли з ланцюгом. Без такої функціональності виникає дилема: взаємодія з ланцюжком вимагає сплати комісій за транзакції, а для сплати комісій за транзакції потрібно... вже мати токени. Адреси ETH, включаючи адреси смарт-контрактів із CREATE2, мають таку функцію. Імена ENS – ні, тому що якщо обидва Боби вирішать поза ланцюжком, що вони є bob.ecc.eth, немає можливості вибрати, який Боб отримає ім’я.
Одне з можливих рішень — додати більше вмісту в контракт сховища ключів, згаданий раніше в архітектурі цієї статті. Контракт сховища ключів може містити різну інформацію про вас і взаємодію з вами (і з CCIP частина цієї інформації може бути поза мережею), користувачі використовуватимуть свій контракт сховища ключів як свій основний ідентифікатор. Однак активи, які вони фактично отримають, зберігатимуться в різних місцях. Контракти сховища ключів не залежать від імен і зручні для віртуальних імен: ви можете створити адресу, яка може бути ініціалізована лише контрактом сховища ключів із певними фіксованими початковими параметрами.
Інший клас рішень передбачає повну відмову від поняття адрес, спрямованих на користувача, подібно до платіжного протоколу Bitcoin. Одна з ідей полягає в тому, щоб більше покладатися на прямі канали зв’язку між відправником і одержувачем; наприклад, відправник може надіслати посилання на запит (у вигляді явної URL-адреси або QR-коду), яке одержувач може використовувати для надсилання будь-якого запиту, який він хоче прийняти. оплата.
Незалежно від того, відправник чи одержувач діють першими, більше покладаючись на гаманці для створення актуальної платіжної інформації в режимі реального часу зменшує тертя. Однак постійні ідентифікатори зручні (особливо з ENS), тоді як на практиці покладатися на пряме спілкування між відправником і одержувачем є дуже складною проблемою, тому може спостерігатися комбінація різних методів.
У всіх цих дизайнах важливо залишатися децентралізованими та зрозумілими для користувачів. Ми повинні забезпечити, щоб користувачі могли легко отримати доступ до актуального перегляду своїх поточних активів і повідомлень, націлених на них. Ці перегляди повинні покладатися на відкриті інструменти, а не на власні рішення. Потрібна буде наполеглива робота, щоб утримати більшу складність платіжної інфраструктури від перетворення на непрозору «вежу абстракції», яку важко зрозуміти та адаптувати до нових умов. Незважаючи на труднощі, досягнення масштабованості Ethereum, безпеки гаманця та конфіденційності для звичайних користувачів є першорядним. Справа не лише в технічній здійсненності, а й у реальній доступності для звичайного користувача. Ми повинні відповісти на цей виклик.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Віталік: Екосистема Ethereum потребує трьох технологічних трансформацій
Автор: Віталік, засновник Ethereum Переклад: Jinse Finance cryptonaitive
Оскільки Ethereum розвивається від молодої експериментальної технології до зрілого технологічного стеку, здатного забезпечувати відкритий, глобальний і бездозвільний досвід звичайним користувачам, є три основні технологічні переходи, які мають відбутися одночасно:
*Трикутник трансформації екосистеми Ethereum. Ви можете вибрати лише всі три. *
Без першого елемента Ethereum зазнає невдачі, тому що кожна транзакція коштує 3,75 доларів США (82,48 доларів США, якщо ми перейдемо до ще одного підвищення), і кожен продукт для масового ринку неминуче відмовиться від онлайн-торгівлі та прийме централізоване рішення.
Без другого пункту Ethereum зазнав би невдачі, оскільки користувачі не бажали б зберігати свої кошти (і нефінансові активи), і всі звернулися б до централізованих бірж.
Без третього пункту Ethereum зазнав би невдачі, тому що для багатьох користувачів усі транзакції (і POAP тощо) були б загальнодоступними, жертва конфіденційністю була б надто великою, і кожен звернувся б до централізованого рішення прихованих даних хоча б на певному рівні.
З причин, описаних вище, ці три переходи є критичними. Але вони також є складними через складність координації. Удосконалення потребує не лише функціональність протоколу; у деяких випадках спосіб взаємодії з Ethereum потребує фундаментальних і глибоких змін, що потребує серйозних змін у програмах і гаманцях.
Ці три перетворення принципово змінять відносини між користувачами та адресами
У світі масштабування L2 користувачі будуть існувати в кількох мережах L2. Ви є учасником ExampleDAO? ExampleDAO працює на оптимізмі. Тоді у вас є рахунок у Optimism! У вас є CDP системи стейблкойнів на ZkSync? Тоді у вас є обліковий запис на ZkSync! Ви коли-небудь пробували деякі програми, розміщені на Kakarot? Тоді у вас є обліковий запис на Kakarot! Часи, коли користувачі мали лише одну адресу, минули.
** Гаманці з розумними контрактами додають ще більше складності, оскільки ускладнюють наявність однакової адреси в мережах L1 і в різних мережах L2. **Більшість користувачів сьогодні використовують зовнішні облікові записи, адреси яких фактично є хешами відкритих ключів, які використовуються для перевірки підписів, тому нічого не змінюється між рівнями L1 і L2. Однак підтримка адреси стає складнішою при використанні смарт-контрактного гаманця. Хоча було зроблено багато роботи, щоб спробувати зробити адреси хеш-кодом, еквівалентним у різних мережах, найважливішими з яких є CREATE2 і ERC-2470 singleton factory, важко досягти цього ідеально. Деякі мережі L2 (наприклад, «ZK-EVM четвертого типу») не зовсім еквівалентні EVM, часто використовують Solidity або проміжну мову асемблера, а не хеш-еквіваленти. Навіть якщо хеш-еквівалентність може бути досягнута, можливість зміни власника гаманців через ключові зміни призводить до інших менш передбачуваних наслідків.
**Конфіденційність вимагає більшої кількості адрес на користувача та може навіть змінити типи адрес, які ми обробляємо. **Якщо пропозиція прихованої адреси широко використовується, користувачі можуть мати одну адресу на транзакцію замість кількох адрес на користувача або однієї адреси на мережу L2. Інші схеми конфіденційності, навіть існуючі, такі як Tornado Cash, по-різному змінюють спосіб зберігання активів: кошти багатьох користувачів зберігаються в одному смарт-контракті (і, отже, на одній адресі). Щоб надіслати кошти певному користувачеві, користувач повинен буде покладатися на власну внутрішню систему адресації схеми конфіденційності.
Як ми бачили, ці три перетворення по-різному послаблюють розумову модель «один користувач ≈ одна адреса», деякі з яких, у свою чергу, збільшують складність виконання цих перетворень. Два особливо складних питання:
**1. Якщо ви хочете комусь заплатити, як ви отримаєте платіжну інформацію? **
**2. Якщо користувачі зберігають активи в різних місцях у різних мережах, як вони виконують ключові зміни та соціальне відновлення? **
Ці три трансформації та платежі в мережі (і ідентифікація)
Я тримаю жетони на Scroll і хочу на них купити каву (якщо буквальне «я» стосується Віталіка, автора цієї статті, то «кава», звичайно, означає «зелений чай»). Ви продаєте каву на Taiko, але приймаєте лише жетони на Taiko. що робити?
В основному є два рішення:
Гаманець-одержувач (яким може бути торговець або звичайна особа) прагне підтримувати кожен L2 і має деякі функції асинхронного злиття коштів.
Одержувач платежу надає свою інформацію рівня L2 поруч із адресою, а гаманець відправника автоматично направляє кошти до цільового рівня L2 через певну систему перехресного зв’язку L2.
Звичайно, ці рішення можна використовувати в комбінації: одержувач надає список рівня L2, який він готовий прийняти, а гаманець відправника визначає метод платежу, який можна надіслати безпосередньо (якщо пощастить) або сплатити за допомогою мостового шляху через L2.
Але це лише один із прикладів ключових труднощів, пов’язаних із трьома перетвореннями: Прості способи оплати починають вимагати більше інформації, ніж просто 20-байтова адреса.
На щастя, перехід на смарт-контрактні гаманці не є великим тягарем для адресної системи, але все ще є деякі технічні проблеми, які потрібно вирішити в інших частинах стеку програм. Гаманці потрібно оновити, щоб переконатися, що вони не лише надсилають 21000 газу під час надсилання транзакцій, але потрібно приділити більше уваги тому, щоб приймаючий кінець гаманця відстежував не лише перекази ETH від EOA, але й перекази ETH від код смарт-контракту. Програми, які покладаються на незмінне право власності на адреси (наприклад, NFT, які забороняють розумні контракти для стягнення роялті), повинні будуть знайти інші способи досягнення своїх цілей. Гаманці з розумними контрактами також полегшать деякі речі, особливо якщо хтось приймає лише токени ERC20, що не належать до ETH, вони зможуть використовувати платіжну систему ERC-4337 для оплати газу за допомогою цього токена.
З іншого боку, питання конфіденційності знову є великим викликом, який ми ще не вирішили. Оригінальний Tornado Cash не створював цих проблем, оскільки не підтримував внутрішні перекази: користувачі могли лише вносити та знімати гроші в системі. Однак, коли внутрішні передачі стануть можливими, користувачам доведеться використовувати внутрішню схему адресації системи конфіденційності. На практиці «платіжне повідомлення» користувача повинно містити (i) якийсь «відкритий ключ витрати», секретне зобов’язання, яке одержувач може використати для витрачання, і (ii) відправник може надсилати зашифровані повідомлення, які лише отримувач може розшифрувати. Одержувач допомоги дізнається спосіб оплати.
Протокол невидимої адреси базується на концепції мета-адреси, яка працює наступним чином: частина мета-адреси є ошуканим ключем витрат відправника, а інша частина є зашифрованим ключем відправника (хоча мінімальна реалізація може встановити обидва ключі бути однаковим).
Огляд абстрактних схем скритної адреси на основі шифрування та ZK-SNARK
Ключовий урок тут полягає в тому, що **в екосистемі, яка підтримує конфіденційність, користувачі матимуть відкриті ключі, що витрачають, і відкриті ключі шифрування, а «платіжна інформація» користувачів повинна містити обидва ключі. **Крім оплати, є й інші вагомі причини для розширення цього напрямку. Наприклад, якщо нам потрібні зашифровані електронні листи на основі Ethereum, користувачам потрібно буде публічно надати якийсь ключ шифрування. У «світі EOA» ми могли б повторно використовувати ключі облікового запису, але у світі безпечних гаманців із смарт-контрактами ми, ймовірно, повинні надати для цього більш чіткі функції. Це також допомагає зробити ідентифікатори на основі Ethereum більш сумісними з не-Ethereum децентралізованими екосистемами конфіденційності, особливо з ключами PGP.
Ці три переходи та відновлення ключа
У світі, де кожен користувач має кілька адрес, стандартний спосіб впровадження ключових змін і соціального відновлення полягає в тому, щоб користувачі запускали процес відновлення для кожної адреси окремо. Це можна зробити в один клік: гаманець може надати програмну функцію для виконання процесу відновлення одночасно на всіх адресах користувача. Однак, навіть із таким спрощенням взаємодії з користувачем, є три проблеми з багатоадресним відновленням:
1. Вартість газу нереальна: Це само собою зрозуміло.
2. Контрфактичні адреси: адреси, на які ще не було укладено смарт-контракт (насправді це означатиме рахунки, з яких ви ще не надсилали кошти). Як користувач, ви можете мати нескінченну кількість віртуальних адрес: одну або більше на кожному L2, включаючи L2, які ще не існують, і цілий нескінченний набір віртуальних адрес, що виникають із схеми прихованих адрес.
3. Конфіденційність: якщо користувач навмисно використовує кілька адрес, щоб не пов’язувати їх одна з одною, то він, звичайно, не хоче публічно пов’язувати їх усі, відновлюючи їх одночасно або майже в один і той же час!
Вирішити ці проблеми складно. На щастя, є досить елегантне рішення, яке працює досить добре: Ця архітектура відокремлює логіку перевірки від утримання активів.
Кожен користувач має контракт на сховище ключів, який існує в одному місці (це може бути основна мережа або певний L2). Тоді користувачі мають адреси на різних рівнях L2, і логіка перевірки для кожної адреси є покажчиком на договір сховища ключів. Витрата коштів із цих адрес вимагатиме надання підтвердження поточного (або реалістичніше, зовсім нещодавнього) витраченого відкритого ключа для коштів.
Цей доказ можна отримати кількома способами:
Якщо ми хочемо уникнути необхідності підтвердження для кожної транзакції, ми можемо реалізувати більш легку схему, яка потребує відновлення лише через підтвердження L2. Витрати з облікового запису залежатимуть від ключа витрат із відповідним відкритим ключем, що зберігається в обліковому записі, але відновлення вимагатиме транзакції для копіювання поточного відкритого ключа витрат у сховище ключів. Навіть якщо ваші старі ключі не захищені, кошти у віртуальній адресі безпечні: «активація» віртуальної адреси, щоб перетворити її на придатний для використання контракт, потребуватиме перехресного підтвердження рівня L2, щоб відтворити поточний відкритий ключ. На форумах Safe є тема, яка описує, як працює подібна архітектура.
Щоб додати конфіденційність такій схемі, нам потрібно лише зашифрувати покажчики та зробити всі докази в ZK-SNARK:
Ці сценарії можуть ускладнюватися. Перевагою є те, що між ними є багато потенційних синергій. Наприклад, концепція «контракту сховища ключів» також може бути рішенням «адреси», згаданої в попередньому розділі: якщо ми хочемо, щоб користувачі мали постійну адресу, яка не змінюється кожного разу, коли користувач оновлює ключ, ми Мета-адреса, ключ шифрування та інша інформація вводяться в контракт сховища ключів, а адреса контракту сховища ключів використовується як «адреса» користувача.
Потрібно оновити багато вторинної інфраструктури
Використання ENS коштує дорого. Хоча це не так дорого, як раніше в червні 2023 року, комісія за транзакцію за реєстрацію доменного імені все ще є відносно високою, що можна порівняти з вартістю доменного імені ENS. Наприклад, реєстрація на zuzalu.eth коштує близько 27 доларів США, 11 доларів з яких – комісія за транзакції. Але якщо ринок знову стане бичачим, комісії зростуть. Навіть якщо ціна ETH не зросте, якщо комісія за газ повернеться до 200 gwei, комісія за транзакцію за реєстрацію доменного імені досягне $104. Отже, якщо ми хочемо, щоб люди дійсно використовували ENS, особливо для таких випадків використання, як децентралізовані соціальні медіа, де користувачі просять майже безкоштовну реєстрацію (комісія за домен ENS не є проблемою, оскільки ці платформи можуть надавати користувачам субдомени), нам потрібно використовувати ENS на 2 шар.
На щастя, команда ENS вже активізувалася, і ENS впроваджується на рівні 2! ERC-3668 (також відомий як «стандарт CCIP») і ENSIP-10 забезпечують спосіб автоматичної перевірки субдоменів ENS на будь-якому рівні 2. Стандарт CCIP вимагає створення смарт-контракту, який описує метод перевірки доказів даних на рівні 2, і доменне ім’я (наприклад, ecc.eth для Optinames) може бути поставлено під контроль такого контракту. Після того, як контракт CCIP контролює ecc.eth на L1, доступ до певного субдомену.ecc.eth автоматично знайде та перевірить доказ, що зберігає стан рівня 2 цього конкретного субдомену (наприклад, гілки Merkle).
**Зусилля ENS CCIP є історією успіху, і її слід розглядати як ознаку того, що радикальні реформи, які нам потрібні, насправді можливі. ** Але є ще багато реформ на рівні програми, які потрібно зробити. Ось кілька прикладів:
Гаманцям потрібно буде захистити активи та дані
Наразі місія гаманця полягає в захисті активів. Все зберігається в ланцюжку, єдине, що потрібно захистити гаманцю, – це приватні ключі, які зараз захищають ці активи. Якщо ви зміните ключ, ви можете безпечно опублікувати попередній закритий ключ в Інтернеті наступного дня. Однак у світі з нульовими знаннями це вже не так: гаманці не лише захищають облікові дані автентифікації, вони також зберігають ваші дані.
Ми бачимо перші ознаки такого світу в Zuzalu з Zupass, системою ідентифікації на основі ZK-SNARK. Користувач має закритий ключ, який використовується для автентифікації в системі, який можна використовувати для створення базових доказів, таких як «довести, що я є резидентом Zuzalu, не повідомляючи, хто я резидент». Система Zupass також почала створювати інші додатки на її основі, головним чином марки (версія POAP Zupass).
*Одна з багатьох моїх марок Zupass, яка підтверджує, що я є членом Team Cat. *
Ключова особливість штампів щодо POAP полягає в тому, що вони є приватними: ви зберігаєте дані локально та підтверджуєте штамп їхнім ZK (або виконуєте певні обчислення на штампах), якщо бажаєте комусь надати цю інформацію. Але це також пов’язано з додатковим ризиком: якщо ви втратите цю інформацію, ви втратите свої марки.
Звичайно, проблему зберігання даних можна звести до проблеми зберігання єдиного ключа шифрування: третя сторона (навіть у мережі) може зберігати зашифровану копію даних. Це має зручну перевагу в тому, що дія, яку ви виконуєте, не змінює ключ шифрування, тому не потрібно взаємодіяти з системою, яка містить ключ шифрування. Але навіть тоді, якщо ви втратите ключ шифрування, ви втратите всі свої дані. У свою чергу, якщо хтось побачить ваш ключ шифрування, він зможе побачити все, що зашифровано цим ключем. **
Практичне рішення Zupass полягає в тому, щоб заохочувати людей зберігати свої ключі на кількох пристроях (таких як ноутбук і телефон), оскільки ймовірність втрати доступу до них усіх одночасно невелика. Ми можемо піти далі, використовуючи спільний доступ до ключів, щоб розділити сховище ключів між кількома засобами захисту.
Соціальне відновлення через MPC не є адекватним рішенням для гаманців, оскільки це означає, що не лише поточний захисник, але й попередні захисники можуть вступити в змову, щоб викрасти ваші активи, що є неприйнятно високим ризиком. Хоча порушення конфіденційності зазвичай є менш ризикованим, ніж повна втрата активів, для випадків використання з високими потребами конфіденційності можна прийняти вищий ризик втрати, не створюючи резервні копії ключів, пов’язаних із цими потребами конфіденційності.
Щоб уникнути занурення користувачів у складну систему кількох шляхів відновлення, гаманцям, які підтримують соціальне відновлення, може знадобитися керувати обома аспектами відновлення активів і відновленням ключа шифрування.
Назад до ідентичності
Загальною темою цих змін є те, що концепція «адреси» як представлення ідентичності в блокчейні потребує фундаментальних змін. ** «Інструкції щодо взаємодії зі мною» більше не будуть просто адресою ETH; express. **
Одним із цих способів є використання ENS як вашої особи: ваш запис ENS може містити всю інформацію про те, як платити та взаємодіяти з вами. Якщо ви надсилаєте комусь bob.eth (або bob.ecc.eth тощо), вони можуть запитати і дізнаватися про все, що з вами взаємодіє, включно з більш складними способами в різних доменах і із захистом конфіденційності.
Однак цей підхід, орієнтований на ENS, має дві слабкості:
Одне з можливих рішень — додати більше вмісту в контракт сховища ключів, згаданий раніше в архітектурі цієї статті. Контракт сховища ключів може містити різну інформацію про вас і взаємодію з вами (і з CCIP частина цієї інформації може бути поза мережею), користувачі використовуватимуть свій контракт сховища ключів як свій основний ідентифікатор. Однак активи, які вони фактично отримають, зберігатимуться в різних місцях. Контракти сховища ключів не залежать від імен і зручні для віртуальних імен: ви можете створити адресу, яка може бути ініціалізована лише контрактом сховища ключів із певними фіксованими початковими параметрами.
Інший клас рішень передбачає повну відмову від поняття адрес, спрямованих на користувача, подібно до платіжного протоколу Bitcoin. Одна з ідей полягає в тому, щоб більше покладатися на прямі канали зв’язку між відправником і одержувачем; наприклад, відправник може надіслати посилання на запит (у вигляді явної URL-адреси або QR-коду), яке одержувач може використовувати для надсилання будь-якого запиту, який він хоче прийняти. оплата.
Незалежно від того, відправник чи одержувач діють першими, більше покладаючись на гаманці для створення актуальної платіжної інформації в режимі реального часу зменшує тертя. Однак постійні ідентифікатори зручні (особливо з ENS), тоді як на практиці покладатися на пряме спілкування між відправником і одержувачем є дуже складною проблемою, тому може спостерігатися комбінація різних методів.
У всіх цих дизайнах важливо залишатися децентралізованими та зрозумілими для користувачів. Ми повинні забезпечити, щоб користувачі могли легко отримати доступ до актуального перегляду своїх поточних активів і повідомлень, націлених на них. Ці перегляди повинні покладатися на відкриті інструменти, а не на власні рішення. Потрібна буде наполеглива робота, щоб утримати більшу складність платіжної інфраструктури від перетворення на непрозору «вежу абстракції», яку важко зрозуміти та адаптувати до нових умов. Незважаючи на труднощі, досягнення масштабованості Ethereum, безпеки гаманця та конфіденційності для звичайних користувачів є першорядним. Справа не лише в технічній здійсненності, а й у реальній доступності для звичайного користувача. Ми повинні відповісти на цей виклик.