Блог V God: Розуміння гаманців та інших прикладних випадків. Перехресне читання рівня 2

Автор: Віталік Бутерін; Упорядник: Bulu said

У статті The Three Transitions Віталік Бутерін, засновник Ethereum, чітко описав «основну мережу (далі – L1) + крос-ланцюг рівня 2 (далі – крос-L2) підтримка"" "Безпека гаманця" і "конфіденційність" є важливими значеннями як необхідні функції стека екосистеми. Вони не повинні бути просто додатковими компонентами, а окремий гаманець забезпечує відповідні функції.

І ця стаття, зазначив Віталік Бутерін, буде зосереджена на ключовій технічній проблемі: як легше читати дані L1 з L2; чи читати дані L2 з L1; або як легше читати дані L2 з L2 Читати дані з іншого L2 . **

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

**Яка мета цього? **

Щойно L2 стане основним, користувачі зможуть володіти активами на кількох L2 і, можливо, також L1.

Щойно гаманці з розумними контрактами стануть основними, поширені зараз «ключі» більше не використовуватимуться.

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

Зокрема, нам потрібен спосіб поводитися з адресами, які є «контрфактичними» (також відомими як «гіпотетичні адреси»): адреси, які ще жодним чином не «зареєстровані» в ланцюжку, але все ще потребують безпечного отримання та зберігання активів. .

Фактично, ми всі покладаємося на це «контрфактичне налаштування» адрес: коли користувач використовує Ethereum вперше, користувач може створити адресу ETH, а інші можуть платити на цей рахунок без необхідності реєструватися в блокчейні. адресу (але вам потрібно буде сплатити комісію за транзакцію, тому вам потрібно мати трохи ETH).

Для зовнішніх облікових записів (EOA) фактично всі адреси починаються з адреси «контрфактичного налаштування».

«Контрфактично встановлені» адреси все ще можливі з гаманцями смарт-контрактів, багато в чому завдяки CREATE2, який дозволяє вам мати адресу ETH, яку можна створити лише за допомогою коду смарт-контракту, який відповідає певному заповненню хешу.

△ Алгоритм обчислення адреси EIP-1014 (CREATE2).

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

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

Структура цієї розділеної архітектури полягає в тому, що кожен користувач має (i) «контракт на зберігання ключів» (або на рівні L1, або на певному ланцюжку L2), який зберігає ключі перевірки для всіх гаманців і правила для зміни ключів, і (ii) «контракти гаманців» " на L1 і багатьох ланцюгах L2, які отримують ключі перевірки через перехресне читання.

Існує два способи реалізації архітектури розділення сховища активів і ключів:

Полегшена версія (тобто перевіряє лише наявність оновлених ключів): кожен гаманець зберігає ключ підтвердження локально та містить функцію виклику для перевірки міжланцюжкового підтвердження поточного стану сховища ключів та оновлення локального сховища Автентифікація ключ для відповідності. Виклик цієї функції для отримання поточного ключа автентифікації зі сховища ключів потрібен під час першого використання гаманця на L2.

• **Переваги: **Використання крос-ланцюгових доказів є більш розумним, і не буде надто дорогих витрат на експлуатацію мережі. Усі активи можна використовувати лише з поточним ключем, тому безпека все одно гарантована.
• **Недоліки: **Потрібно змінити ключ підтвердження, зміну ключа в ланцюжку потрібно виконати в сховищі ключів і кожному ініціалізованому гаманці, і може споживати багато плати за газ.

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

• Переваги: Системна складність низька, а сховище ключів оновлюється швидко.
• **Недоліки: **Висока плата за роботу мережі за одну транзакцію, і нелегко бути сумісним з ERC-4337. ERC-4337 наразі не підтримує читання змінних об’єктів у контрактах під час перевірки.

**Що таке крос-ланцюжок? **

Щоб продемонструвати складність міжланцюгових доказів, ми вибрали один із найскладніших сценаріїв застосування, щоб продемонструвати та пояснити цей технічний принцип. Цей складний сценарій застосування такий: ключ зберігається на одному L2, а гаманець – на інший L2. Якщо сховище ключів у гаманці знаходиться на L1, потрібна лише половина цього дизайну.

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

• Доказ поточного кореня стану Linea, враховуючи поточний корень стану Ethereum, відомий Kakarot.
• Підтвердження поточного ключа в сховищі ключів з урахуванням поточного кореня стану Linea.

Тут є два головних складних питання реалізації: «Який тип доказу необхідно використовувати? (Це доказ Меркла? Чи щось інше?)» і «Як L2 дізнається найближчий корінь стану L1?» Або «L1 Як дізнатися корінь стану L2?"

Отже, в обох випадках, якою є затримка між моментом, коли відбувається подія з однієї сторони, і моментом, коли інша сторона може надати доказ?

**Які схеми доказів доступні для нас? **

Існує п’ять основних методів на вибір:

• Доказ Меркла
• Загальні ЗК-СНАРКи
• Сертифікат спеціального призначення (наприклад, з використанням КЗГ)
• Доказ Verkle, між KZG і ZK-SNARK, враховуючи зусилля і вартість інфраструктури
• немає доказів, покладається на пряме зчитування стану

З точки зору необхідної інфраструктурної роботи та витрат користувача, їх можна приблизно класифікувати таким чином:

«Агрегація» означає агрегування всіх доказів, наданих користувачами в кожному блоці, в одне велике метадоказ, об’єднуючи їх разом. Це працює для SNARK і KZG, але не для вилок Merkle.

Насправді «агрегація» є цінною лише тоді, коли рішення має велику кількість користувачів. невважати

**Як працюють докази Merkle? **

Ця задача дуже проста, і її можна безпосередньо прослідкувати за діаграмою в попередньому розділі. Кожен «доказ» (за умови, що один L2 є іншим L2, що є найскладнішим сценарієм застосування) включатиме:

Форк Merkle, який засвідчує, що містить корінь стану сховища ключів L2, останнього кореня стану Ethereum, відомого L2. Корені стану, що містять сховище ключів L2, зберігаються у відомих слотах зберігання за відомими адресами (контракти L1 представляють L2), тому шляхи можуть бути жорстко закодовані.

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

Однак підтвердження стану в Ethereum є складними, але є бібліотеки, які можна використовувати для їх перевірки, і якщо використовувати ці бібліотеки, механізм не надто складний.

Однак більшою проблемою є вартість. **Меркл виявився дуже довгим, а дерево Патриції було в 3,9 раза довшим, ніж потрібно, що набагато вище поточної базової ціни в 21 000 комісії за газ за транзакцію.

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

Ми можемо розрахувати, що це означає, порівнявши вартість плати за газ L1 і вартість плати за газ L2:

Наразі, якщо це відносно проста операція надсилання, вартість у мережі L1 приблизно в 15–25 разів перевищує вартість L2, а вартість обміну токеном приблизно у 20–50 разів перевищує вартість L2.

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

Зібравши вищезазначене, якщо ми припустимо 30-кратне співвідношення витрат між обчислювальними витратами L1 і L2, це, здається, означає, що вартість розміщення доказів Merkle на L2 може бути еквівалентна приблизно п’ятдесяти регулярним транзакціям.

Звичайно, використання бінарного дерева Merkle зменшило б вартість приблизно в 4 рази, але навіть тоді вартість у більшості випадків була б непомірно високою, і якби ми захотіли відмовитися від сумісності з поточним деревом шістнадцяткового стану Ethereum, це могло б Буду шукати кращі варіанти.

**Як працює перевірка ZK-SNARK? **

Використання ZK-SNARK також концептуально легко зрозуміти: ви просто замінюєте докази Merkle на діаграмі вище на ZK-SNARK, які доводять існування цих доказів Merkle. Розрахункова сума ZK-SNARK становить близько 400 000 Gas Fee, приблизно 400 байт; базова транзакція вимагає 21 000 Gas Fee і 100 байт.

Таким чином, з точки зору розрахунку вартість ZK-SNARK у 19 разів перевищує поточну базову вартість транзакції; з точки зору даних вартість ZK-SNARK у 4 рази перевищує поточну базову вартість транзакції та в 16 разів перевищує майбутню. базова вартість операції.

Ці цифри представляють величезне покращення в порівнянні з доказами Merkle, але все ще досить дорогі. Є два способи покращити цю ситуацію: (i) докази KZG спеціального призначення або (ii) агрегація, подібна до агрегації ERC-4337.

**Як працює доказ KZG спеціального призначення? **

По-перше, підсумок того, як працюють обіцянки KZG:

*[D_1 ...D_n] представляє набір даних, за допомогою яких виводиться доказ полінома KZG. *

*Зокрема, поліном P, де P(w) = D_1, P(w²) = D_2 ... P(wⁿ) = D_n. w тут є «рівномірним коренем» для деякого поля оцінки розмір N, значення wN = 1 (все це робиться в кінцевих полях). *

• Щоб «здійснити» P, ми створюємо точку еліптичної кривої com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. тут:*

G — твірна точка кривої

Pi — i-й коефіцієнт полінома P

Si — i-та точка в довіреному налаштуванні

• Щоб довести, що P(z) = a, ми створюємо частковий поліном Q = (P - a) / (X - z) і створюємо зобов'язання com(Q). Створити такий поліном можливо, лише якщо P(z) фактично дорівнює a. *

• Щоб перевірити доказ, ми перевіряємо рівняння Q * (X - z) = P - a, виконуючи перевірку еліптичної кривої на доказі com(Q) і зобов’язанні полінома com(P): ми перевіряємо e(com( Q), com (X - z))? = e(com(P) - com(a), com(1))*

Деякі ключові властивості, про які також варто знати, включають:

Доказом є лише значення com(Q), яке становить 48 байтів

com（P₁） + com（P₂） = com（P₁ + P₂）

*Це також означає, що ви можете "редагувати" значення в існуючому контракті. *

• Припустімо, що ми знаємо, що D_i наразі дорівнює a, ми хочемо встановити його як b, а існуюче зобов’язання щодо D дорівнює com(P). обіцяємо "P, але P(wⁱ) = b, і жодних інших змін оцінки", тоді ми встановлюємо com(new_P) = com(P) + (ba)*com(Li), де Li є "лангерианом відставання" поліном", що дорівнює 1 в wⁱ і 0 в інших точках wj. *

• Для ефективного виконання цих оновлень кожен клієнт може попередньо обчислити та зберегти всі N зобов’язань для полінома Лагранжа (com(Li)). У онлайн-контракті може бути забагато зберігати всі N зобов’язань, тому ви можете зробити KZG-зобов’язання для набору значень com(L_i), тому щоразу, коли комусь потрібно оновити дерево в ланцюзі, вони можуть просто подати до Proper com(L_i) надає доказ своєї правильності. *

Отже, майте структуру, яка продовжує додавати значення в кінець зростаючого списку, але з певним обмеженням розміру. Потім використовуйте цю структуру як структуру даних для (i) зобов’язань щодо списку ключів на кожному L2, що зберігається на цьому L2 і віддзеркалюється на L1, і (ii) зобов’язань щодо списку зобов’язань щодо ключів L2, що зберігається в Ethereum на L1 і дзеркально відображено до кожного L2.

Оновлення зобов’язань може бути частиною основної логіки рівня L2 або реалізовано через міст депозиту та зняття коштів без зміни основного протоколу рівня L2.

Повний доказ вимагає наступного:

1. Збережіть останній com (список ключів) сховища ключів на L2.
2. Доказ KZG із com(keylist) як значенням у com(mirror list), який є списком усіх зобов’язань списку ключів.
3. Оформити сертифікат КЗГ ключа користувача в com (список ключів).

Насправді два наведені вище докази KZG можна об’єднати в одне із загальним розміром лише 100 байт.

Зверніть увагу на одну деталь: оскільки список ключів — це список, а не карта ключ/значення, як стан, списку ключів потрібно призначати позиції в порядку. Контракт обіцянки ключа міститиме власний внутрішній реєстр, що зіставлятиме кожне сховище ключів з ідентифікатором, і для кожного ключа зберігатиме хеш (ключ, адресу сховища ключів) замість ключа, щоб чітко повідомляти іншим L2, про які сховище ключів, на яке посилається певний запис.

Перевагою цієї техніки є те, що вона дуже добре працює на L2. Приблизно в 4 рази коротше, ніж ZK-SNARK, набагато коротше, ніж докази Merkle. Розрахункова вартість становить близько 119 000 Плата за газ.

На L1 обчислювальна потужність важливіша за дані, тому KZG трохи дорожчий, ніж доказ Merkle.

**Як працюють дерева Verkle? **

Дерева Verkle по суті передбачають об’єднання зобов’язань KZG разом: щоб зберегти значення 2⁴⁸, зобов’язання KZG можна зробити до списку значень 2²⁴, кожне з яких саме по собі є зобов’язанням KZG щодо значень 2²4.

Дерева Verkle розглядаються як дерева стану Ethereum, оскільки дерева Verkle можна використовувати для зберігання карт ключ-значення.

Докази в деревах Verkle довші, ніж докази KZG, вони можуть мати довжину в сотні байтів.

Насправді дерева Verkle слід розглядати як дерева Merkle, але вони більш здійсненні без SNARKing, але показано, що SNARKing має нижчу вартість доказів.

Великою перевагою дерев Веркле є те, що вони можуть координувати структури даних: тому їх можна використовувати безпосередньо для L1 або L2, немає структури суперпозиції, і той самий механізм використовується для L1 і L2.

Щойно квантові комп’ютери стануть проблемою або як тільки гілки Merkle виявляться досить ефективними, дерева Verkle знайдуть більше застосувань.

полімеризація

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

• Доказ ZK-SNARK гілок N Merkle
• Багаторазовий сертифікат KZG
• Мультизахист Verkle (або багатозахищений ZK-SNARK)

У всіх трьох випадках кожне підтвердження коштує лише кілька сотень тисяч плати за газ.

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

Якщо використовуються ZK-SNARK, кожному користувачеві може знадобитися витратити тисячі комісій за газ L2. Якщо використовується KZG multi-proof, верифікатор повинен додати 48 зборів за газ до L2 кожного сховища ключів, що використовується в блоці.

Тим не менш, ці витрати набагато нижчі, ніж без агрегації, яка неминуче передбачає понад 10 000 плати за газ L1 і сотні тисяч плати за газ L2 на користувача.

Для дерева Verkle користувачі можуть безпосередньо використовувати Verkle multi-proof, кожен користувач додає близько 100~200 байт, або ви можете створити Verkle multi-proof ZK-SNARK, його вартість подібна до ZK-SNARK філії Merkle, але доказ Це виглядає явно дешево.

З точки зору впровадження, можливо, було б найкраще дозволити пакетникам агрегувати міжланцюгові докази за допомогою стандарту абстракції облікового запису ERC-4337. ERC-4337 вже має механізм, за допомогою якого розробники можуть агрегувати частини операцій користувача власним способом. Існує навіть реалізація агрегації підписів BLS, яка може зменшити плату за газ L2 у 1,5–3 рази.

Прочитати статус безпосередньо

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

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

Зауважте, що якщо сховище ключів знаходиться на L1, а L2 містить функцію статичних викликів L1, то атестація взагалі не потрібна.

Однак, якщо L2 не включає статичні виклики L1 або якщо сховище ключів знаходиться на L2, тоді потрібне підтвердження.

**Як L2 дізнається останній кореневий стан Ethereum? **

Усі наведені вище схеми вимагають доступу L2 до найближчого кореня стану L1 або всього найближчого стану L1.

Насправді, якщо L2 має функцію депонування, тоді ви можете використовувати цей L2 як є, щоб перемістити корінь стану L1 у контракт на L2: просто попросіть контракт на L1 викликати код операції BLOCKHASH і внести його як актив. Повідомлення передається до L2. Повний заголовок блоку може бути отриманий на стороні L2 і витягнути його корінь стану.

Однак кожен L2 переважно має явний спосіб прямого доступу до повного останнього стану L1 або найближчого кореня стану L1.

Основна проблема в оптимізації способу отримання L2 останнього кореня стану L1 полягає в тому, щоб досягти безпеки та низької затримки одночасно:

• Якщо L2 повільно реалізує функцію прямого читання L1, лише зчитуючи остаточний корінь стану L1, тоді затримка зазвичай становить 15 хвилин, але в деяких екстремальних випадках затримка може становити тижні.
• L2, безперечно, можна спроектувати для читання оновлених коренів стану L1, але оскільки L1 може відновлюватися (що трапляється під час неактивних витоків навіть із завершеністю одного сокета), L2 також має мати можливість відновлюватися. З точки зору розробки програмного забезпечення, це технічно складно.
• Якщо міст використовується для переведення коренів стану L1 у L2, тоді оновлення активів займає дуже багато часу, у кращому випадку є постійні користувачі, які платять за оновлення та підтримують систему в актуальному стані для всіх інших.
• Оракули тут не є прийнятним рішенням: керування ключами гаманця є дуже важливою для безпеки низькорівневою функцією, тому вона має покладатися щонайбільше на кілька дуже простих, криптографічно ненадійних низькорівневих інфраструктур.

Крім того, у зворотному напрямку (L1 читається як L2):

• У Optimistic Rollup кореневій системі стану потрібно тиждень, щоб досягти рівня L1 через затримки, пов’язані з шахрайством. У зведених версіях ZK зараз це займає години через поєднання часу перевірки та економічних обмежень, хоча майбутні технології скоротять це.
• Попереднє підтвердження (від секвенсора, сертифікатора тощо) не є прийнятним рішенням для L1 зчитування L2. Керування гаманцем є дуже важливою для безпеки функцією низького рівня, тому рівень безпеки зв’язку від L2 до L1 має бути абсолютно високим. Єдиний кореневий стан, якому L1 повинен довіряти, це той, який був прийнятий як остаточний кореневий стан згідно з договором утримання кореневого стану L2 на L1.

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

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

Зрештою, найкраще рішення для мінімізації затримки полягає в тому, щоб L2 оптимально реалізував пряме читання кореня стану L1, де кожен блок L2 (або журнал обчислень кореня стану) містить вказівник на останній блок L1, тому, якщо L1 відновиться, і L2 також може відновитися. Контракт сховища ключів слід розмістити в основній мережі або на L2 ZK-rollup, щоб його можна було швидко зафіксувати на L1.

**Скільки підключення до Ethereum потрібно іншому ланцюжку, щоб зберігати сховище ключів, що зберігається в Ethereum або гаманці L2? **

На диво, не так багато. Насправді це навіть не обов’язково має бути зведеним.

Якщо це L3 або валідіум, можна зберігати там гаманці, якщо користувачі зберігають ключове сховище на L1 або ZK-rollup, їм справді потрібен прямий доступ до кореня стану Ethereum і вони готові зберігати свої гаманці на Ethereum Під час рефакторингу, хардфорк, коли Ethereum хардфорк.

Схеми на основі мостів ZK мають привабливі технічні властивості, але вони мають ключову слабкість у тому, що вони не стійкі до атак 51% або хардфорків.

захист конфіденційності

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

• Не дозволяйте громадськості знати, що всі ці гаманці пов’язані один з одним.
• Опікуни соціального відновлення не знатимуть, за якою адресою вони є опікунами.

Але це створює проблему:

• Ми не можемо безпосередньо використовувати докази Merkle, оскільки вони не зберігають конфіденційність.
• Якщо ми використовуємо KZG або SNARK, підтвердження має надати сліпу версію ключа підтвердження без розкриття розташування ключа підтвердження.
• Якщо ми використовуємо агрегацію, то агрегатор не повинен знати місцезнаходження в відкритому вигляді; натомість агрегатор повинен отримувати сліпі докази та мати спосіб агрегувати ці докази.
• Ми не можемо використовувати «полегшену версію» (перехресна атестація лише під час повторного введення ключів), тому що це призведе до витоку конфіденційності: якщо багато гаманців оновлюються одночасно завдяки оновленню, то час цих гаманців може бути пов'язана інформація. Тому ми повинні використовувати «повну версію» (перехресне підтвердження кожної транзакції).

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

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

Для KZG ми можемо використовувати неіндексування, щоб виявити роботу доказу KZG. Однак сліпе агрегування є відкритою проблемою, яка потребує більшої уваги.

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