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