Автор оригіналу: засновник Ethereum Віталік Бутерін
Особлива подяка Дену Фінлі, Карлу Флершу, Девіду Хоффману та командам Scroll і SoulWallet за їхні відгуки, відгуки та пропозиції.
Оскільки Ethereum переходить від молодої, експериментальної технології до зрілого технологічного стеку, здатного по-справжньому забезпечувати відкритий, глобальний і бездозвільний досвід звичайним користувачам, стек повинен буде пройти через три основні технологічні переходи приблизно одночасно:
Перехід розширення L2 - усі переходять на зведення
Перехід на безпеку гаманця — усі переходять на гаманці зі смарт-контрактами
Перехід на конфіденційність — переконайтеся, що перекази коштів із збереженням конфіденційності доступні, а також переконайтеся, що всі інші гаджети, що розробляються (соціальне відновлення, ідентичність, репутація), зберігають конфіденційність
Трикутник переходу екосистеми.
Без першого Ethereum зазнав би невдачі, оскільки кожна транзакція коштує 3,75 доларів США (82,48 доларів США, якщо у нас буде ще один зростання), і кожен продукт, призначений для масового ринку, неминуче забуде про ланцюжок і прийме централізоване обхідне рішення для всього.
Без другого Ethereum зазнав би краху, оскільки користувачі не бажали зберігати свої кошти (і нефінансові активи), і всі звернулися до централізованих бірж.
Без третього Ethereum зазнав би невдачі, оскільки всі транзакції (і POAP тощо) є централізованим рішенням, яке максимально приховує ваші дані.
Ці три переходи є критичними з причин, описаних вище. Але вони також є складними, тому що для їх належного вирішення потрібна тісна координація. Покращення потребує не лише функціональність протоколу; у деяких випадках спосіб взаємодії з Ethereum має фундаментально змінитися, вимагаючи серйозних змін у програмах і гаманцях.
Ці три переходи принципово змінять відносини між користувачами та адресами
У розширеному світі L2 користувачі будуть існувати на багатьох L2. Ви є учасником ExampleDAO, який покладається на Optimism? Тоді у вас є обліковий запис Optimism! Ви тримаєте CDP у системі стейблкойнів на ZkSync? Тоді у вас є обліковий запис на ZkSync! Ви пробували деякі програми на kakarot? Тоді у вас є обліковий запис на Kakarot! Пройшли часи, коли користувач мав лише одну адресу.
*Згідно з моїм поглядом Brave Wallet, я маю ETH у чотирьох місцях. Так, Arbitrum і Arbitrum Nova різні. Не хвилюйтеся, з часом стане ще брудніше! *
Розумні контрактні гаманці додають складності та ускладнюють наявність однакової адреси в L1 та різних L2. Сьогодні більшість користувачів використовують зовнішні облікові записи, адреси яких фактично є хешами відкритих ключів, які використовуються для перевірки підписів, тому нічого не змінюється між рівнями L1 і L2. Однак із гаманцями зі смарт-контрактами зарезервувати адресу стає важче. Хоча було зроблено багато роботи, щоб спробувати зробити адреси хеш-кодом, еквівалентним у всіх мережах, особливо CREATE2 та ERC-2470 singleton factories, було важко змусити це працювати бездоганно. Деякі L2 (наприклад, "Type 4 ZK-EVM") не зовсім еквівалентні EVM, зазвичай натомість використовуються Solidity або проміжні збірки, щоб запобігти хеш-еквівалентності. Навіть якби ви могли мати хеш-еквівалент, можливість зміни власника гаманців через ключові зміни має інші неінтуїтивні наслідки.
Конфіденційність вимагає більшої кількості адрес на користувача та може навіть змінити типи адрес, з якими ми маємо справу. Якщо пропозиція невидимої адреси широко використовується, замість кількох адрес на користувача або однієї адреси на L2 користувачі можуть мати одну адресу на транзакцію. Інші схеми конфіденційності, навіть існуючі, такі як Tornado Cash, змінюють спосіб зберігання активів по-різному: кошти багатьох користувачів зберігаються в одному смарт-контракті (і, отже, за тією самою адресою). Щоб надіслати кошти певному користувачеві, користувач повинен буде покладатися на власну внутрішню систему адресації схеми конфіденційності.
Як ми бачили, кожен із цих трьох переходів по-різному послаблює розумову модель «один користувач ~= одна адреса», причому деякі з цих ефектів повертаються до складності реалізації переходу. Два особливі складні моменти:
Якби ви хотіли заплатити комусь, як би ви отримали інформацію про те, як їм заплатити?
Якщо користувач має багато активів у різних мережах, які зберігаються в різних місцях, як він виконує ключові зміни та соціальне відновлення?
Три переходи та платежі в ланцюжку (і ідентифікатори)
У мене є монети на Scroll, і я хочу заплатити за каву (якщо «я» буквально стосується мене як автора цієї статті, тоді «кава», звичайно, є метонімом до «зеленого чаю»). Ви продаєте мені каву, але ви можете отримати лише монети на 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.
Три переходи та відновлення ключа
Стандартний спосіб впровадження критичних змін і соціального відновлення в світі, де кожен користувач має кілька адрес, полягає в тому, щоб користувач просто запустив процес відновлення для кожної адреси окремо. Це можна зробити в один клік: гаманці можуть містити програмне забезпечення, яке може виконувати процедури відновлення на всіх адресах користувача одночасно. Однак, навіть із таким спрощенням взаємодії з користувачем, є три проблеми з простим багатоадресним відновленням:
Вартість газу є непрактичною: це не пояснює себе.
Виправдані адреси: адреси, які смарт-контракт ще не видав (насправді це означає облікові записи, з яких ви ще не надсилали кошти). Як користувач, ви можете мати нескінченну кількість контрфактичних адрес: одну або більше адрес на кожному L2, включаючи L2, які ще не існують, і інший нескінченний набір контрфактичних адрес, отриманих в результаті схеми скритної адреси.
Конфіденційність: якщо користувач навмисно має кілька адрес, щоб не пов’язувати їх одна з одною, він, звичайно, не хоче публічно пов’язувати їх усі, відновлюючи їх приблизно в один і той же час!
Вирішити ці проблеми складно. На щастя, існує елегантне рішення, яке працює достатньо добре: архітектура, яка відокремлює логіку перевірки від утримання активів.
Кожен користувач має договір сховища ключів, який існує в одному місці (це може бути основна мережа або певний L2). Тоді користувачі мають адреси на різних рівнях L2, де логіка перевірки для кожної адреси є вказівником на договір сховища ключів. Витрати з цих адрес вимагають підтвердження входу в договір сховища ключів із зазначенням поточного (або, більш реалістично, останнього) видатного відкритого ключа.
Доказ можна отримати кількома способами:
Прямий доступ лише для читання L1 у L2. L2 можна модифікувати для безпосереднього зчитування стану L1. Якщо договір сховища ключів знаходиться на L1, це означає, що контракти в межах L2 мають «вільний» доступ до сховища ключів
Гілка Меркель. Гілки Merkle можуть засвідчити стан L1 на L2, або стан L2 на L1, або ви можете поєднати обидва, щоб підтвердити частковий стан одного L2 на інший L2. Основним недоліком доказів Merkle є висока вартість газу через довжину доказу: для доказу може знадобитися 5 Кбайт, але в майбутньому цей розмір буде зменшено до < 1 Кбайт завдяки деревам Verkle.
ЗК-СНАРКи. Ви можете зменшити витрати на передачу даних, використовуючи ZK-SNARK форків Merkle замість самих форків. Можна створити методи агрегації поза ланцюгом (наприклад, на основі EIP-4337), щоб ZK-SNARK перевіряв усі підтвердження стану між ланцюгами в блоці.
Обіцянка КЗГ. L2 або схеми, побудовані на їх основі, можуть запроваджувати послідовну систему адресації, дозволяючи доказам стану в цій системі мати довжину лише 48 байтів. Подібно до ZK-SNARK, схеми кількох доказів можуть об’єднати всі ці докази в єдине доказ для кожного блоку.
Якщо ми хочемо уникнути створення доказів для кожної транзакції, ми можемо реалізувати спрощену схему, яка потребує лише одного перехресного доказу L2 для відновлення. Витрати з облікового запису залежатимуть від ключа витрат, відповідний відкритий ключ якого зберігається в обліковому записі, але для відновлення знадобиться транзакція для копіювання поточного відкритого ключа витрат у сховищі ключів. Кошти на фіктивних адресах у безпеці, навіть якщо ваші старі ключі ні: «активація» фіктивної адреси для перетворення її на робочий контракт потребує перехресного підтвердження рівня L2, щоб дублювати поточний витратний ключ_pubkey. Ця тема на форумах Safe описує, як працює подібна архітектура.
Щоб додати такій схемі конфіденційності, ми просто шифруємо цей покажчик, а потім виконуємо всі докази в ZK-SNARK:
З додатковими зусиллями (наприклад, використовуючи цю роботу як відправну точку), ми також можемо усунути більшу частину складності ZK-SNARK і створити простішу схему на основі KZG.
Ці сценарії можуть ускладнюватися. Позитивним є те, що між ними існує багато потенційних синергій. Наприклад, концепція «контрактів сховища ключів» також може вирішити проблему «адреси», згадану в попередньому розділі: якщо ми хочемо, щоб користувачі мали постійні адреси, які не змінюються кожного разу, коли користувач повторно вводить ключ, ми можемо розмістити приховані мета-адреси , ключі шифрування та інша інформація вставляється в контракт сховища ключів, а адреса контракту сховища ключів використовується як «адреса» користувача.
Необхідно оновити багато вторинної інфраструктури
Використання ENS коштує дорого. Сьогодні, у червні 2023 року, все не так погано: комісія за транзакції висока, але все ще порівнянна з комісією за домен ENS. Реєстрація на zuzalu.eth обійшлася мені приблизно в 27 доларів США, з яких 11 доларів США становили комісії за транзакції. Але якщо у нас буде інший бичачий ринок, збори різко зростуть. Навіть без підвищення ціни ETH повернення плати за газ до 200 gwei збільшить комісію за передачу за реєстрацію домену до 104 доларів США. Отже, якщо ми хочемо, щоб люди дійсно використовували ENS, особливо для таких випадків використання, як децентралізовані соціальні медіа, де користувачі вимагають майже безкоштовної реєстрації (а плата за домен ENS не є проблемою, оскільки ці платформи надають своїм користувачам субдомени), нам потрібна ENS на рівні 2 для роботи .
На щастя, команда ENS активізувалася, і ENS на L2 відбувається! ERC-3668 (він же «стандарт CCIP») разом із ENSIP-10 надає можливість автоматично перевіряти субдомени ENS на будь-якому L2. Стандарт CCIP вимагає створення смарт-контракту, який описує метод перевірки доказів даних L2, і що домени (наприклад, Optinames використовують ecc.eth) можуть бути передані під контроль такого контракту. Після того, як контракт CCIP бере контроль над ecc.eth на L1, доступ до певного субдомену.ecc.eth автоматично включатиме пошук і перевірку підтвердження стану (наприклад, гілка Merkle) на рівні L2, де фактично зберігається цей субдомен.
Насправді отримання доказів включає список URL-адрес, що зберігається в контракті, який, безперечно, виглядає централізованим, але я думаю, що насправді це не так: це модель довіри 1 із N (недійсні докази виловлюються логікою перевірки у функції зворотного виклику контракту CCIP , якщо одна з URL-адрес повертає дійсне підтвердження, це нормально). Список URL-адрес може містити десятки.
Зусилля ENS CCIP є історією успіху, і це слід розглядати як ознаку того, що така радикальна реформа, яка нам потрібна, насправді можлива. Але ще потрібно виконати багато реформ прикладного рівня. Кілька прикладів:
Багато прикладних програм покладаються на те, що користувачі надають підписи поза мережею. З обліковим записом у зовнішній власності (EOA) це легко. ERC-1271 надає стандартизований спосіб для розумних гаманців контрактів, щоб зробити це. Однак багато програм досі не підтримують ERC-1271; їм знадобиться.
Dapps, які використовують «Це EOA?» для диференціації користувачів і контрактів (наприклад, запобігання передачі або стягнення роялті), будуть порушені. Загалом, я б не радив шукати тут суто технічні рішення; з’ясування того, чи є певна передача криптографічного контролю передачею бенефіціарної власності, є складною проблемою, яку неможливо вирішити без звернення до деяких позамережевих механізмів, керованих спільнотою. Швидше за все, додаткам доведеться менше покладатися на запобігання відтоку, а більше на такі методи, як податки Harberger.
Треба покращити взаємодію гаманців із витратами та ключами шифрування. Наразі гаманці зазвичай використовують детерміновані підписи для генерації ключів додатків: підписання стандартного nonce (наприклад, хешу назви додатку) за допомогою приватного ключа EOA генерує детерміноване значення, яке неможливо згенерувати без приватного ключа, тому це безпечно. у суто технічному сенсі. Однак ці методи є «непрозорими» для гаманців, не дозволяючи гаманцям здійснювати перевірки безпеки на рівні інтерфейсу користувача. У більш зрілих екосистемах гаманці мають більш чітко обробляти підпис, шифрування та пов’язані функції.
Легкі клієнти (такі як Helios) повинні будуть автентифікувати L2, а не тільки L1. Сьогодні легкі клієнти зосереджуються на перевірці дійсності заголовків L1 (за допомогою протоколу синхронізації легкого клієнта) і перевірці розгалужень Merkle стану L1 і транзакцій, що ґрунтуються на заголовках L1. Завтра їм також потрібно перевірити підтвердження стану L2, яке корениться в корені стану, що зберігається в L1 (досконаліша версія фактично дивиться на попереднє підтвердження L2).
Гаманцям потрібно буде захистити активи та дані
Сьогодні гаманці служать для захисту активів. Усе знаходиться в ланцюжку, і єдине, що має захищати гаманець, це приватні ключі, які зараз захищають ці активи. Якщо ви зміните свій ключ, ви можете безпечно опублікувати свій попередній закритий ключ в Інтернеті наступного дня. Однак у світі ZK це вже не так: гаманець не лише захищає облікові дані автентифікації, він також зберігає ваші дані.
Ми побачили перші ознаки такого світу з Zupass, системою ідентифікації на основі ZK-SNARK, яку використовує Zuzalu. Користувач має приватний ключ для автентифікації в системі, який можна використовувати для створення базових доказів, таких як «довести, що я є жителем Зузалу, не розкриваючи, якого саме». Але система Zupass також почала будувати інші додатки поверх неї, зокрема stamp (версія POAP Zupass).
Одна з моїх багатьох марок Zupass, яка підтверджує, що я гордий член Team Cat.
Ключовою особливістю, яку пропонують штампи порівняно з POAP, є те, що штампи є приватними: ви зберігаєте дані локально, і якщо ви хочете, щоб хтось мав інформацію про вас, вам просто потрібно підтвердити комусь штамп (або певні обчислення на штампі). Але це додає ризику: якщо ви втратите цю інформацію, ви втратите штамп.
Звичайно, проблему зберігання даних можна звести до проблеми зберігання єдиного ключа шифрування: якась третя сторона (або навіть мережа) може зберігати зашифровану копію даних. Це має зручну перевагу, оскільки виконана вами дія не змінює ключ шифрування, тому не потрібна взаємодія із системою, яка зберігає ваш ключ шифрування. Але навіть тоді, якщо ви втратите свій ключ шифрування, ви втратите все. З іншого боку, якщо хтось побачить ваш ключ шифрування, він зможе побачити все, що зашифровано цим ключем.
Практичне рішення Zupass полягає в тому, щоб заохочувати людей зберігати свої ключі на кількох пристроях (наприклад, ноутбуці та телефоні), оскільки ймовірність того, що вони втратять доступ до всіх них одночасно, невелика. Ми можемо піти далі й використати секретний ресурс для зберігання ключів, розподілених між кількома опікунами.
Це соціальне відновлення через MPC не є адекватним рішенням для гаманців, оскільки це означає, що не лише поточні опікуни, але й попередні опікуни можуть вступити в змову, щоб викрасти ваші активи, що є неприйнятно високим ризиком. Але ризик порушення конфіденційності зазвичай нижчий, ніж загальний ризик втрати активів, і люди з високим рівнем конфіденційності завжди можуть прийняти вищий ризик втрати, не створюючи резервні копії ключів, пов’язаних із цими операціями, що потребують конфіденційності.
Щоб уникнути перевантаження користувачів візантійськими системами з кількома шляхами відновлення, гаманцям, які підтримують соціальне відновлення, може знадобитися керувати як відновленням активів, так і відновленням ключа шифрування.
Назад до ідентичності
Одна зі спільних рис цих змін полягає в тому, що концепція «адреси», криптографічного ідентифікатора, який ви використовуєте для представлення «ви» в ланцюжку, має фундаментально змінитися. «Інструкції щодо взаємодії зі мною» більше не будуть просто адресою ETH; це має бути деяка комбінація кількох адрес на кількох рівнях L2, прихованих мета-адрес, ключів шифрування та інших даних у певній формі.
Один із способів – зробити ENS вашою особою: ваш запис ENS може просто містити всю цю інформацію, і якщо ви надішлете комусь bob.eth (або bob.ecc.eth, або...), вони зможуть знайти та побачити все про те, як він платить і взаємодіє з вами, включаючи більш складні міждоменні методи та методи збереження конфіденційності.
Але цей підхід, орієнтований на ENS, має дві слабкості:
Це пов’язує занадто багато речей з вашим доменним іменем. Ваше доменне ім’я – це не ви, ваше доменне ім’я – один із багатьох ваших атрибутів. Повинна бути можливість змінити ваше доменне ім’я без переміщення всього вашого профілю ідентифікації та оновлення цілої купи записів у багатьох програмах.
Ви не можете мати ненадійну контрфактичну кукурудзу. Ключовою особливістю UX будь-якого блокчейну є можливість надсилати монети людям, які ще не взаємодіяли з ланцюгом. Без такої функції є заковика 22: взаємодія з ланцюжком вимагає сплати комісій за транзакції, для чого потрібно... вже мати монети. Адреси ETH, включаючи адреси смарт-контрактів із CREATE2, мають таку функцію. Імена ENS не будуть, тому що якщо обидва боби вирішать, що вони є bob.ecc.eth поза ланцюгом, немає можливості вибрати, хто з них отримає ім’я.
Одне з можливих рішень — додати більше вмісту в договір сховища ключів, згаданий в архітектурі раніше в цій статті. Контракт сховища ключів може містити будь-яку інформацію про вас і те, як ви з ним взаємодієте (для CCIP частина цієї інформації може бути поза мережею), і користувачі використовуватимуть свій контракт сховища ключів як основний ідентифікатор. Але фактичні активи, які вони отримають, зберігатимуться в різних місцях. Контракти сховища ключів не залежать від імен і є контрфактичними: ви можете згенерувати адресу, яка може бути ініціалізована лише контрактом сховища ключів із деякими фіксованими початковими параметрами.
Інший тип рішення схожий на платіжний протокол Bitcoin, повністю відмовляючись від концепції орієнтованих на користувача адрес. Одна з ідей полягає в тому, щоб більше покладатися на прямі канали зв’язку між відправником і одержувачем; наприклад, відправник може надіслати посилання на вимогу (як явну URL-адресу або QR-код), яке одержувач може використовувати, щоб стежити за своєю готовністю прийняти платіж.
Незалежно від того, відправник чи одержувач переходить першим, більше покладаючись на гаманці для безпосереднього створення актуальної платіжної інформації в режимі реального часу зменшує тертя. Тим не менш, постійні ідентифікатори зручні (особливо з ENS), тоді як припущення про прямий зв’язок між відправником і одержувачем є дуже складним на практиці, тому ми можемо побачити комбінацію різних технологій.
У всіх цих дизайнах найважливішим є те, щоб зробити речі водночас дискретними та легкими для розуміння користувачами. Нам потрібно переконатися, що користувачі мають легкий доступ до найновішої інформації про їхні поточні активи та новини, які для них публікуються. Ці перспективи повинні спиратися на відкриті інструменти, а не на власні рішення. Щоб утримати складнішу платіжну інфраструктуру від перетворення на непрозору «вежу абстракції», де розробникам важко зрозуміти, що відбувається, і адаптувати її до нового середовища, потрібно буде важко попрацювати. Незважаючи на труднощі, досягнення масштабованості, безпеки гаманця та конфіденційності для звичайних користувачів має вирішальне значення для майбутнього Ethereum. Справа не лише в технічній здійсненності, а й у реальній доступності для звичайного користувача. Ми повинні прийняти цей виклик.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Віталік Бутерін: три технічні переходи Ethereum
Автор оригіналу: засновник Ethereum Віталік Бутерін
Особлива подяка Дену Фінлі, Карлу Флершу, Девіду Хоффману та командам Scroll і SoulWallet за їхні відгуки, відгуки та пропозиції.
Оскільки Ethereum переходить від молодої, експериментальної технології до зрілого технологічного стеку, здатного по-справжньому забезпечувати відкритий, глобальний і бездозвільний досвід звичайним користувачам, стек повинен буде пройти через три основні технологічні переходи приблизно одночасно:
Без першого Ethereum зазнав би невдачі, оскільки кожна транзакція коштує 3,75 доларів США (82,48 доларів США, якщо у нас буде ще один зростання), і кожен продукт, призначений для масового ринку, неминуче забуде про ланцюжок і прийме централізоване обхідне рішення для всього.
Без другого Ethereum зазнав би краху, оскільки користувачі не бажали зберігати свої кошти (і нефінансові активи), і всі звернулися до централізованих бірж.
Без третього Ethereum зазнав би невдачі, оскільки всі транзакції (і POAP тощо) є централізованим рішенням, яке максимально приховує ваші дані.
Ці три переходи є критичними з причин, описаних вище. Але вони також є складними, тому що для їх належного вирішення потрібна тісна координація. Покращення потребує не лише функціональність протоколу; у деяких випадках спосіб взаємодії з Ethereum має фундаментально змінитися, вимагаючи серйозних змін у програмах і гаманцях.
Ці три переходи принципово змінять відносини між користувачами та адресами
У розширеному світі L2 користувачі будуть існувати на багатьох L2. Ви є учасником ExampleDAO, який покладається на Optimism? Тоді у вас є обліковий запис Optimism! Ви тримаєте CDP у системі стейблкойнів на ZkSync? Тоді у вас є обліковий запис на ZkSync! Ви пробували деякі програми на kakarot? Тоді у вас є обліковий запис на Kakarot! Пройшли часи, коли користувач мав лише одну адресу.
Розумні контрактні гаманці додають складності та ускладнюють наявність однакової адреси в L1 та різних L2. Сьогодні більшість користувачів використовують зовнішні облікові записи, адреси яких фактично є хешами відкритих ключів, які використовуються для перевірки підписів, тому нічого не змінюється між рівнями L1 і L2. Однак із гаманцями зі смарт-контрактами зарезервувати адресу стає важче. Хоча було зроблено багато роботи, щоб спробувати зробити адреси хеш-кодом, еквівалентним у всіх мережах, особливо CREATE2 та ERC-2470 singleton factories, було важко змусити це працювати бездоганно. Деякі L2 (наприклад, "Type 4 ZK-EVM") не зовсім еквівалентні EVM, зазвичай натомість використовуються Solidity або проміжні збірки, щоб запобігти хеш-еквівалентності. Навіть якби ви могли мати хеш-еквівалент, можливість зміни власника гаманців через ключові зміни має інші неінтуїтивні наслідки.
Конфіденційність вимагає більшої кількості адрес на користувача та може навіть змінити типи адрес, з якими ми маємо справу. Якщо пропозиція невидимої адреси широко використовується, замість кількох адрес на користувача або однієї адреси на L2 користувачі можуть мати одну адресу на транзакцію. Інші схеми конфіденційності, навіть існуючі, такі як Tornado Cash, змінюють спосіб зберігання активів по-різному: кошти багатьох користувачів зберігаються в одному смарт-контракті (і, отже, за тією самою адресою). Щоб надіслати кошти певному користувачеві, користувач повинен буде покладатися на власну внутрішню систему адресації схеми конфіденційності.
Як ми бачили, кожен із цих трьох переходів по-різному послаблює розумову модель «один користувач ~= одна адреса», причому деякі з цих ефектів повертаються до складності реалізації переходу. Два особливі складні моменти:
Якби ви хотіли заплатити комусь, як би ви отримали інформацію про те, як їм заплатити?
Якщо користувач має багато активів у різних мережах, які зберігаються в різних місцях, як він виконує ключові зміни та соціальне відновлення?
Три переходи та платежі в ланцюжку (і ідентифікатори)
У мене є монети на Scroll, і я хочу заплатити за каву (якщо «я» буквально стосується мене як автора цієї статті, тоді «кава», звичайно, є метонімом до «зеленого чаю»). Ви продаєте мені каву, але ви можете отримати лише монети на Taiko. що робити
В основному є два рішення:
Звичайно, ці рішення можна поєднувати: одержувач надає список L2, який він готовий прийняти, а гаманець відправника визначає платіж, який може передбачати пряме надсилання або перехідний шлях через L2, якщо йому пощастить.
Але це лише один із прикладів ключових проблем, пов’язаних із цими трьома переходами: такі прості дії, як оплата комусь, починають вимагати більше інформації, ніж просто 20-байтова адреса.
На щастя, перехід на смарт-контрактні гаманці не перевантажить систему адресації, але все ще є деякі технічні проблеми, які потрібно вирішити в інших частинах стеку програм. Гаманці потрібно буде оновити, щоб переконатися, що вони не просто надсилають 21000 газу разом із транзакцією, і важливіше переконатися, що сторона гаманця, яка приймає платіж, не лише відстежує переказ ETH від EOA, але також відстежує ETH надісланий кодом смарт-контракту. Програми, які покладаються на припущення про незмінне право власності на адреси (наприклад, NFT, які забороняють смарт-контракти для стягнення роялті), повинні будуть знайти інші способи досягнення своїх цілей. Гаманці з розумними контрактами також спростять роботу - зокрема, якщо хтось отримає лише токен ERC20, не пов’язаний з ETH, він зможе використовувати цей токен для оплати газу за допомогою платіжників ERC-4337.
З іншого боку, конфіденційність знову створює серйозну проблему, яку ми ще не вирішували. Оригінальний Tornado Cash не створював жодної з цих проблем, оскільки не підтримував внутрішні перекази: користувачі могли лише вносити кошти в систему та знімати з неї. Однак, коли внутрішні передачі стануть можливими, користувачам доведеться використовувати внутрішню схему адресації системи конфіденційності. На практиці «платіжне повідомлення» користувача має містити (i) якийсь «відкритий ключ, що витрачає», обіцянку секрету, який одержувач може використовувати для витрачання, і (ii) певний спосіб для відправника надсилати криптовалюту лише інформація, яку одержувач може розшифрувати, щоб допомогти одержувачу виявити платіж.
Протокол невидимої адреси спирається на концепцію мета-адреси, яка працює таким чином: частина мета-адреси є сліпою версією ключа відправника, а інша частина є ключем шифрування відправника (хоча мінімальні реалізації можуть встановити обидва ключі однакові).
Ключовий урок тут полягає в тому, що в екосистемі, яка підтримує конфіденційність, користувачі матимуть як відкриті ключі споживання, так і відкриті ключі шифрування, а «платіжна інформація» користувача повинна містити обидва ключі. Крім платежів, є вагомі причини для розширення в цьому напрямку. Наприклад, якщо нам потрібні зашифровані електронні листи на основі Ethereum, користувачам потрібно буде публічно надати якийсь ключ шифрування. У «світі EOA» ми могли б повторно використовувати для цього ключі облікового запису, але у світі безпечних гаманців із розумними контрактами ми, ймовірно, повинні надати для цього більш чітку функцію. Це також допомагає зробити ідентифікатори на основі Ethereum більш сумісними з не-Ethereum децентралізованими екосистемами конфіденційності, особливо з ключами PGP.
Три переходи та відновлення ключа
Стандартний спосіб впровадження критичних змін і соціального відновлення в світі, де кожен користувач має кілька адрес, полягає в тому, щоб користувач просто запустив процес відновлення для кожної адреси окремо. Це можна зробити в один клік: гаманці можуть містити програмне забезпечення, яке може виконувати процедури відновлення на всіх адресах користувача одночасно. Однак, навіть із таким спрощенням взаємодії з користувачем, є три проблеми з простим багатоадресним відновленням:
Вирішити ці проблеми складно. На щастя, існує елегантне рішення, яке працює достатньо добре: архітектура, яка відокремлює логіку перевірки від утримання активів.
Доказ можна отримати кількома способами:
Щоб додати такій схемі конфіденційності, ми просто шифруємо цей покажчик, а потім виконуємо всі докази в ZK-SNARK:
Ці сценарії можуть ускладнюватися. Позитивним є те, що між ними існує багато потенційних синергій. Наприклад, концепція «контрактів сховища ключів» також може вирішити проблему «адреси», згадану в попередньому розділі: якщо ми хочемо, щоб користувачі мали постійні адреси, які не змінюються кожного разу, коли користувач повторно вводить ключ, ми можемо розмістити приховані мета-адреси , ключі шифрування та інша інформація вставляється в контракт сховища ключів, а адреса контракту сховища ключів використовується як «адреса» користувача.
Необхідно оновити багато вторинної інфраструктури
Використання ENS коштує дорого. Сьогодні, у червні 2023 року, все не так погано: комісія за транзакції висока, але все ще порівнянна з комісією за домен ENS. Реєстрація на zuzalu.eth обійшлася мені приблизно в 27 доларів США, з яких 11 доларів США становили комісії за транзакції. Але якщо у нас буде інший бичачий ринок, збори різко зростуть. Навіть без підвищення ціни ETH повернення плати за газ до 200 gwei збільшить комісію за передачу за реєстрацію домену до 104 доларів США. Отже, якщо ми хочемо, щоб люди дійсно використовували ENS, особливо для таких випадків використання, як децентралізовані соціальні медіа, де користувачі вимагають майже безкоштовної реєстрації (а плата за домен ENS не є проблемою, оскільки ці платформи надають своїм користувачам субдомени), нам потрібна ENS на рівні 2 для роботи .
На щастя, команда ENS активізувалася, і ENS на L2 відбувається! ERC-3668 (він же «стандарт CCIP») разом із ENSIP-10 надає можливість автоматично перевіряти субдомени ENS на будь-якому L2. Стандарт CCIP вимагає створення смарт-контракту, який описує метод перевірки доказів даних L2, і що домени (наприклад, Optinames використовують ecc.eth) можуть бути передані під контроль такого контракту. Після того, як контракт CCIP бере контроль над ecc.eth на L1, доступ до певного субдомену.ecc.eth автоматично включатиме пошук і перевірку підтвердження стану (наприклад, гілка Merkle) на рівні L2, де фактично зберігається цей субдомен.
Зусилля ENS CCIP є історією успіху, і це слід розглядати як ознаку того, що така радикальна реформа, яка нам потрібна, насправді можлива. Але ще потрібно виконати багато реформ прикладного рівня. Кілька прикладів:
Гаманцям потрібно буде захистити активи та дані
Сьогодні гаманці служать для захисту активів. Усе знаходиться в ланцюжку, і єдине, що має захищати гаманець, це приватні ключі, які зараз захищають ці активи. Якщо ви зміните свій ключ, ви можете безпечно опублікувати свій попередній закритий ключ в Інтернеті наступного дня. Однак у світі ZK це вже не так: гаманець не лише захищає облікові дані автентифікації, він також зберігає ваші дані.
Ми побачили перші ознаки такого світу з Zupass, системою ідентифікації на основі ZK-SNARK, яку використовує Zuzalu. Користувач має приватний ключ для автентифікації в системі, який можна використовувати для створення базових доказів, таких як «довести, що я є жителем Зузалу, не розкриваючи, якого саме». Але система Zupass також почала будувати інші додатки поверх неї, зокрема stamp (версія POAP Zupass).
Ключовою особливістю, яку пропонують штампи порівняно з POAP, є те, що штампи є приватними: ви зберігаєте дані локально, і якщо ви хочете, щоб хтось мав інформацію про вас, вам просто потрібно підтвердити комусь штамп (або певні обчислення на штампі). Але це додає ризику: якщо ви втратите цю інформацію, ви втратите штамп.
Звичайно, проблему зберігання даних можна звести до проблеми зберігання єдиного ключа шифрування: якась третя сторона (або навіть мережа) може зберігати зашифровану копію даних. Це має зручну перевагу, оскільки виконана вами дія не змінює ключ шифрування, тому не потрібна взаємодія із системою, яка зберігає ваш ключ шифрування. Але навіть тоді, якщо ви втратите свій ключ шифрування, ви втратите все. З іншого боку, якщо хтось побачить ваш ключ шифрування, він зможе побачити все, що зашифровано цим ключем.
Практичне рішення Zupass полягає в тому, щоб заохочувати людей зберігати свої ключі на кількох пристроях (наприклад, ноутбуці та телефоні), оскільки ймовірність того, що вони втратять доступ до всіх них одночасно, невелика. Ми можемо піти далі й використати секретний ресурс для зберігання ключів, розподілених між кількома опікунами.
Це соціальне відновлення через MPC не є адекватним рішенням для гаманців, оскільки це означає, що не лише поточні опікуни, але й попередні опікуни можуть вступити в змову, щоб викрасти ваші активи, що є неприйнятно високим ризиком. Але ризик порушення конфіденційності зазвичай нижчий, ніж загальний ризик втрати активів, і люди з високим рівнем конфіденційності завжди можуть прийняти вищий ризик втрати, не створюючи резервні копії ключів, пов’язаних із цими операціями, що потребують конфіденційності.
Щоб уникнути перевантаження користувачів візантійськими системами з кількома шляхами відновлення, гаманцям, які підтримують соціальне відновлення, може знадобитися керувати як відновленням активів, так і відновленням ключа шифрування.
Назад до ідентичності
Одна зі спільних рис цих змін полягає в тому, що концепція «адреси», криптографічного ідентифікатора, який ви використовуєте для представлення «ви» в ланцюжку, має фундаментально змінитися. «Інструкції щодо взаємодії зі мною» більше не будуть просто адресою ETH; це має бути деяка комбінація кількох адрес на кількох рівнях L2, прихованих мета-адрес, ключів шифрування та інших даних у певній формі.
Один із способів – зробити ENS вашою особою: ваш запис ENS може просто містити всю цю інформацію, і якщо ви надішлете комусь bob.eth (або bob.ecc.eth, або...), вони зможуть знайти та побачити все про те, як він платить і взаємодіє з вами, включаючи більш складні міждоменні методи та методи збереження конфіденційності.
Але цей підхід, орієнтований на ENS, має дві слабкості:
Одне з можливих рішень — додати більше вмісту в договір сховища ключів, згаданий в архітектурі раніше в цій статті. Контракт сховища ключів може містити будь-яку інформацію про вас і те, як ви з ним взаємодієте (для CCIP частина цієї інформації може бути поза мережею), і користувачі використовуватимуть свій контракт сховища ключів як основний ідентифікатор. Але фактичні активи, які вони отримають, зберігатимуться в різних місцях. Контракти сховища ключів не залежать від імен і є контрфактичними: ви можете згенерувати адресу, яка може бути ініціалізована лише контрактом сховища ключів із деякими фіксованими початковими параметрами.
Інший тип рішення схожий на платіжний протокол Bitcoin, повністю відмовляючись від концепції орієнтованих на користувача адрес. Одна з ідей полягає в тому, щоб більше покладатися на прямі канали зв’язку між відправником і одержувачем; наприклад, відправник може надіслати посилання на вимогу (як явну URL-адресу або QR-код), яке одержувач може використовувати, щоб стежити за своєю готовністю прийняти платіж.
У всіх цих дизайнах найважливішим є те, щоб зробити речі водночас дискретними та легкими для розуміння користувачами. Нам потрібно переконатися, що користувачі мають легкий доступ до найновішої інформації про їхні поточні активи та новини, які для них публікуються. Ці перспективи повинні спиратися на відкриті інструменти, а не на власні рішення. Щоб утримати складнішу платіжну інфраструктуру від перетворення на непрозору «вежу абстракції», де розробникам важко зрозуміти, що відбувається, і адаптувати її до нового середовища, потрібно буде важко попрацювати. Незважаючи на труднощі, досягнення масштабованості, безпеки гаманця та конфіденційності для звичайних користувачів має вирішальне значення для майбутнього Ethereum. Справа не лише в технічній здійсненності, а й у реальній доступності для звичайного користувача. Ми повинні прийняти цей виклик.