У моїй попередній статті про три зміни я описав деякі з ключових причин, чому важливо почати чітко думати про підтримку L1 + крос-L2, безпеку гаманця та конфіденційність як необхідні фундаментальні функції стеку екосистеми. Речі побудовані як плагіни. які можна індивідуально спроектувати за допомогою одного гаманця.
Ця публікація буде зосереджена безпосередньо на технічних аспектах конкретної підпроблеми, наприклад: як легше читати L1 з L2, L2 з L1 або L2 з іншого L2. Вирішення цієї проблеми має вирішальне значення для включення архітектур розділення активів/сховищ ключів, але воно також має цінні варіанти використання в інших сферах, особливо оптимізуючи надійні ланцюжки викликів між L2, включаючи випадки використання, такі як переміщення ресурсів між L1 і L2.
Цей каталог статей
Яка мета?
Як виглядає крос-ланцюжковий доказ?
Яку схему доказів ми можемо використати?
Доказ Меркла
ЖК СНАРКс
Спеціальний сертифікат KZG
Доказ дерева Verkle
полімеризація
пряме читання статусу
Як L2 дізнається останній кореневий стан Ethereum?
Гаманці на ланцюгах, які не належать до L2
захист конфіденційності
Підведіть підсумки
1. Яка мета?
Коли L2 стане основним, користувачі будуть володіти активами в кількох L2 і, можливо, також L1. Щойно гаманці з розумними контрактами (multisig, social recovery або інші) стануть основними, ключі, необхідні для доступу до певних облікових записів, з часом зміняться, і старі ключі більше не повинні бути дійсними. Коли ці дві речі відбудуться, користувачам знадобиться спосіб змінити ключі, які мають доступ до багатьох облікових записів, розташованих у багатьох різних місцях, без здійснення надзвичайно великої кількості транзакцій.
Зокрема, нам потрібен спосіб боротьби з контрфактичними адресами: адресами, які жодним чином не були «зареєстровані» в ланцюжку, але все одно потрібно безпечно отримувати та зберігати кошти. Ми всі покладаємося на гіпотетичні адреси: коли ви вперше використовуєте Ethereum, ви можете створити адресу ETH, яку хтось може використовувати для оплати вам, не «реєструючи» адресу в ланцюжку (це вимагає сплати комісії за передачу, тому вже маєте трохи ETH).
Для EOA всі адреси починаються з контрфактичної адреси. З гаманцями смарт-контрактів все ще можливі контрфактичні адреси значною мірою завдяки CREATE2, який дозволяє мати адресу ETH, яку можна заповнити лише смарт-контрактом із кодом, який відповідає певному хешу.
Алгоритм обчислення адреси EIP-1014 (CREATE2).
Однак гаманці з розумними контрактами створюють новий виклик: можливість змінювати ключ доступу. Ця адреса є хешем початкового коду та може містити лише початковий ключ перевірки гаманця. Поточний ключ підтвердження зберігатиметься в сховищі гаманця, але цей запис у сховищі не буде чарівним чином поширюватися на інші L2.
Якщо користувач має багато адрес на багатьох рівнях L2, включно з адресами, не відомими L2, на якому вони знаходяться (оскільки вони суперечливі), то, здається, є лише один спосіб дозволити користувачам змінювати свої ключі: архітектура поділу активів/сховища ключів. Кожен користувач має (i) «контракт сховища ключів» (або на рівні L1, або на одному конкретному рівні L2), який зберігає ключі перевірки для всіх гаманців і правила для зміни ключів, і (ii) «контракти гаманця», які зчитують ключі перевірки між ланцюжками.
Є два способи досягти цього:
Полегшена версія (перевіряє лише наявність оновлених ключів): кожен гаманець зберігає ключ підтвердження локально та містить функцію, яку можна викликати для перевірки міжланцюжкового підтвердження поточного стану сховища ключів і оновлення його локально збереженого ключа підтвердження для відповідності. Коли гаманець вперше використовується на певному L2, ця функція має бути викликана, щоб отримати поточний ключ автентифікації зі сховища ключів.
-Плюси: міжланцюгові докази використовуються економно, тому не має значення, чи дорогі міжланцюгові докази. Усі кошти можна використовувати лише з поточним ключем, тому він залишається безпечним.
Недолік: щоб змінити ключ перевірки, вам потрібно змінити ключ у ланцюжку в сховищі ключів і в кожному ініціалізованому гаманці (хоча це не контрфактичний гаманець). Це може коштувати багато газу.
Важка версія (перевіряйте кожну передачу): кожна транзакція потребує підтвердження перехресного ланцюга, яке показує поточний ключ у сховищі ключів.
Плюси: менша складність системи, дешеві оновлення сховища ключів.
Мінуси: Одиночна передача коштує дорого, тому потрібні додаткові розробки, щоб зробити перехресні докази набагато дешевшими. Також непросто сумісний з ERC-4337, який наразі не підтримує читання змінних об’єктів у контрактах під час перевірки.
2. Як виглядає крос-ланцюгове доказ?
Щоб продемонструвати всю складність, ми розглянемо найскладніший випадок: сховище ключів на одному L2, гаманець на іншому L2. Лише половина цього дизайну потрібна, якщо сховище ключів у гаманці знаходиться на рівні L1.
Припустімо, що сховище ключів знаходиться на Linea, а гаманець – на Kakarot. Повний доказ ключа гаманця включає:
Доказ поточного кореня стану Linea, враховуючи поточний корень стану Ethereum, відомий Kakarot
— Підтвердження поточного ключа в сховищі ключів, враховуючи поточний корень стану Linea
Тут є дві головні складні проблеми реалізації:
Які докази ми використовуємо? (Це доказ Меркель? Щось інше?
Як L2 спочатку дізнається найближчий корінь стану L1 (Ethereum) (або, як ми побачимо, можливо, повний стан L1)? Або як L1 вивчає корені стану L2?
Якою в обох випадках є затримка між тим, що відбувається з одного боку, і тим, що можна продемонструвати з іншого?
3. Які типи схем доказів ми можемо використовувати?
Є п'ять основних варіантів:
-Доказ Меркла
-Загальні ЗК-СНАРКи
Спеціальне доказування (наприклад, за допомогою KZG)
Verkle демонструє, що вони знаходяться між KZG і ZK-SNARK з точки зору навантаження на інфраструктуру та вартості.
Докази не потрібні, покладається на пряме зчитування штату
З точки зору необхідної інфраструктурної роботи та вартості користувача, я б приблизно оцінив їх таким чином:
«Агрегація» означає агрегацію всіх доказів, наданих користувачами в межах кожного блоку, в один великий мета-доказ, який поєднує всі докази. Це можливо з SNARK і KZG, але не з форками Merkle (ви можете трохи комбінувати форки Merkle, але це лише заощадить ваш журнал (txs на блок)/log (загальну кількість сховищ ключів), на практиці це, мабуть, 15-30% посередині, тож, ймовірно, не вартий цієї ціни).
Агрегація стає корисною лише тоді, коли в сценарії є велика кількість користувачів, тому на практиці реалізація версії 1 може не використовувати агрегацію та реалізувати її у версії 2.
4. Як працюватимуть докази Merkle?
Це легко: просто дотримуйтеся схеми в попередньому розділі. Точніше, кожен «доказ» (припускаючи випадок доведення максимальної складності одного L2 до іншого L2) міститиме:
Гілка Merkle, яка підтверджує кореневий стан L2, що містить сховище ключів, враховуючи останній кореневий стан Ethereum, відомий L2. Сховище ключів містить корінь стану L2, що зберігається у відомому слоті зберігання за відомою адресою (контракт на L1 представляє L2), тому шлях через дерево може бути жорстко закодований.
Гілка Merkle, що засвідчує поточний ключ перевірки, враховуючи корінь стану L2, що містить сховище ключів. І тут ключ автентифікації зберігається у відомому слоті зберігання за відомою адресою, тому шлях може бути жорстко закодований.
На жаль, докази стану Ethereum є складними, але існують бібліотеки для їх перевірки, і якщо ви використовуєте ці бібліотеки, цей механізм не надто складний для впровадження.
**Найбільшою проблемою є вартість. **Докази Меркла дуже довгі, на жаль, дерево Patricia приблизно в 3,9 рази довше, ніж потрібно (якщо бути точним: ідеальне доказ Merkle для дерева, що містить N об’єктів, має довжину 32 * log2(N) байтів, і тому що дерева Patricia Ethereum мають 16 листків на дочірню частину, і доказ цих дерев має довжину 32 * 15 * log16(N) ~= 125 * log2(N) байтів). У державі з приблизно 250 мільйонами (~2²⁸) облікових записів це робить кожне підтвердження 125 * 28 = 3500 байт, або приблизно 56 000 газу, плюс додаткові витрати на декодування та перевірку хешу.
Разом ці два докази коштуватимуть приблизно від 100 000 до 150 000 газів (якщо вони використовуються для однієї транзакції, за винятком перевірки підпису) – це набагато більше, ніж поточна базова ціна в 21 000 газів за транзакцію. Однак, якщо доказ перевірено на L2, розбіжність погіршується. Обчислення всередині L2 дешеві, оскільки обчислення виконуються поза ланцюгом і в екосистемі з набагато меншою кількістю вузлів, ніж L1. З іншого боку, дані повинні бути опубліковані в L1. Отже, порівняння полягає не в 21 тис. газу проти 15 тис. газу; це 21 тис. газу L2 проти 100 тис. газу L1.
Ми можемо розрахувати, що це означає, порівнявши вартість газу L1 і вартість газу L2:
Наразі L1 у 15-25 разів дорожчий, ніж L2 для простого надсилання, і в 20-50 разів дорожчий для обміну токеном. Просте надсилання – це відносно великий обсяг даних, але розрахунковий обсяг обміну набагато більший. Таким чином, своп є кращим орієнтиром для приблизної вартості обчислення L1 порівняно з обчисленням L2. Беручи все це до уваги, якщо ми припустимо 30-кратне співвідношення витрат між обчислювальними витратами L1 і L2, це, здається, означає, що вартість розміщення доказу Merkle на L2 може бути еквівалентна 50 регулярним транзакціям.
Звичайно, використання бінарного дерева Merkle зменшує вартість приблизно в 4 рази, але навіть тоді, у більшості випадків, ціна надто висока – якщо ми готові пожертвувати несумісністю з поточним шестикутним деревом стану Ethereum, ми Шукайте кращі варіанти.
5. Як буде працювати перевірка ZK-SNARK?
Використання ZK-SNARK також концептуально легко зрозуміти: ви просто замінюєте докази Merkle на діаграмі вище на ZK-SNARK, які доводять існування цих доказів Merkle. Для обчислення ZK-SNARK потрібно ~400 000 GAS, що займає близько 400 байт (порівняно з: базова транзакція вимагає 21 000 gas і 100 байт, які можна скоротити до ~ 25 слів після стиснення в майбутньому фестивалі). Таким чином, з обчислювальної точки зору вартість ZK-SNARK у 19 разів перевищує вартість сьогоднішніх базових транзакцій, а з точки зору даних вартість ZK-SNARK у 4 рази перевищує вартість сучасних базових транзакцій і в 16 разів вартість майбутніх базових операцій.
Ці цифри є великим покращенням порівняно з доказом Меркель, але вони все ще досить дорогі. Є два способи покращити це: (i) докази KZG спеціального призначення або (ii) агрегація, подібна до агрегації ERC-4337, але з використанням більш химерної математики. Ми можемо вивчати обидва одночасно.
6. Як працюватимуть перевірки KZG спеціального призначення?
Попередження, цей розділ більш математичний, ніж інші. Це тому, що ми виходимо за межі інструментів загального призначення та створюємо дешевші інструменти спеціального призначення, тож нам потрібно глибше йти «під капот». Якщо вам не подобається глибока математика, перейдіть одразу до наступного розділу.
По-перше, підсумок того, як працюють зобов’язання KZG:
Ми можемо представити набір даних [D_1...D_n], використовуючи доказ KZG полінома, отриманого з даних: зокрема, полінома P, де P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w тут «рівномірний корінь», значення wN = 1 для деякого розміру області оцінки N (все це робиться в кінцевих полях).
Щоб «закріпити» 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) (або hash(com(L_i)), тому щоразу комусь потрібно Під час оновлення дерева on-chain вони можуть просто надати доказ своєї правильності відповідному com(L_i).
Тож у нас є структура, за якою ми можемо продовжувати додавати значення в кінець зростаючого списку, хоча й з певним обмеженням розміру (насправді сотні мільйонів можуть бути здійсненними). Потім ми використовуємо це як нашу структуру даних для керування (i) зобов’язаннями щодо списку ключів на кожному L2, що зберігаються на цьому L2 та віддзеркалюються на L1, і (ii) зобов’язаннями щодо списку зобов’язань ключів L2, що зберігається на Ethereum L1 і віддзеркалюється до кожного L2.
Оновлення зобов’язань може бути частиною основної логіки L2 або реалізовано через міст депозиту та зняття без зміни основного протоколу L2.
Отже, повний доказ вимагає:
Сховище ключів містить останній com (список ключів) на рівні L2 (48 байт)
-KZG доводить, що com(список ключів) є com(значення в дзеркалі_списку), прихильність до всіх списків подання списків ключів (48 байт)
-KZG доводить, що ваш ключ знаходиться в com (список ключів) (48 байт, плюс 4 байти для індексу)
Насправді можна об’єднати два докази KZG в одне, тому ми отримаємо загальний розмір лише 100 байт.
Зверніть увагу на тонкість: оскільки список ключів — це список, а не карта ключ/значення, як у стані, списку ключів потрібно призначати позиції в порядку. Контракт обіцянки ключа міститиме власний внутрішній реєстр, який зіставлятиме кожне сховище ключів з ідентифікатором, і для кожного ключа зберігатиме хеш (адресу сховища ключів) замість ключа, щоб явно спілкуватися з іншими L2, яке сховище ключів йдеться про певний запис.
Перевагою цієї техніки є те, що вона дуже добре працює на L2. Дані становлять 100 байтів, що приблизно в 4 рази коротше, ніж ZK-SNARK, і коротше, ніж докази Merkle. Розрахункова вартість в основному становить одну пару чеків, або близько 119 000 газ. На L1 дані менш важливі, ніж обчислення, тому, на жаль, KZG трохи дорожчі, ніж докази Merkle.
7. Як буде працювати дерево Веркла?
Дерева Verkle по суті передбачають об’єднання зобов’язань KZG (або зобов’язань IPA, які можуть бути ефективнішими та використовувати простіше шифрування): щоб зберігати значення 2⁴⁸, ви робите зобов’язання KZG щодо списку значень 2²⁴, кожне з яких саме по собі є зобов’язанням KZG щодо 2²⁴ Вартість. Дерева Verkle наполегливо розглядаються як дерева стану Ethereum, оскільки дерева Verkle можна використовувати для зберігання зіставлення ключів і значень, а не лише для списків (загалом, ви можете створити дерево розміром 2²⁵⁶, але почати пустим, лише якщо ви заповнюєте лише певні частини дерево, коли вам дійсно потрібно їх заповнити).
Як виглядає дерево Віккера. Фактично, ви можете надати кожному вузлу ширину 256 == 2⁸ для дерев на основі IPA та 2²⁴ для дерев на основі KZG.
Докази в деревах Verkle дещо довші, ніж у KZG; вони можуть мати довжину в сотні байтів. Їх також важко перевірити, особливо якщо спробувати зібрати багато доказів в одне.
Насправді дерева Verkle слід розглядати як дерева Merkle, але більш здійсненні без SNARKing (через меншу вартість даних), а SNARKing дешевший (через нижчу вартість доказів).
Найбільшою перевагою дерев Verkle є те, що вони можуть координувати структури даних: докази Verkle можна використовувати безпосередньо для станів L1 або L2, не мають структури суперпозиції та використовують точно той самий механізм для L1 та L2. Як тільки квантові комп’ютери стануть проблемою або як тільки розгалуження Merkle виявиться досить ефективним, дерева Verkle можна буде замінити на місці бінарними хеш-деревами з відповідними SNARK-дружніми хеш-функціями.
8. Агрегати
Якщо N користувачам, які здійснюють N транзакцій (або більш реалістично, N ERC-4337 UserOperations), потрібно підтвердити N крос-чейн заяв, ми можемо заощадити багато грошей, об’єднавши ці докази: об’єднавши ці транзакції в блок або конструктор комплекту який входить до блоку, може створити доказ, який підтверджує всі ці твердження одночасно.
Це може означати:
Докази ZK-SNARK для філій N Merkle
Мультизахист KZG
Verkle multi-proof (або multi-proof ZK-SNARK)
У всіх трьох випадках для кожного доказу потрібно лише кілька сотень тисяч газу. Розробнику потрібно зробити один із них на кожному L2 для користувачів цього L2; таким чином, для простоти побудови вся схема має бути достатньо використана, щоб зазвичай було принаймні кілька транзакцій у тому самому блоці на кількох основних L2 торгівлі .
Якщо використовуються ZK-SNARK, основна гранична вартість — це просто «бізнес-логіка» передачі номерів між контрактами, тому кожному користувачеві може знадобитися кілька тисяч газу L2. Якщо використовується KZG multi-proof, пруверу потрібно додати 48 газів для кожного сховища ключів, що містить L2, що використовується в блоці, тому гранична вартість схеми на користувача буде на L2 (а не на користувача), а потім додано ~800 газу L1 . Але ці витрати набагато нижчі, ніж без агрегації, яка неминуче включає понад 10 000 газу L1 і сотні тисяч газу L2 на користувача. Для дерев Verkle ви можете безпосередньо використовувати мультидокази Verkle, додаючи близько 100-200 байт на кожного користувача, або ви можете створити ZK-SNARK для мультидоказів Verkle, які коштують так само, як і розгалужені Merkle ZK-SNARK, але підтвердження коштує набагато нижче.
З точки зору впровадження, для пакетувальників краще збирати міжланцюгові докази за допомогою стандарту абстракції облікового запису ERC-4337. ERC-4337 вже має механізм, за допомогою якого розробники можуть агрегувати частини дій користувача власним чином. Існує навіть реалізація агрегації сигнатур BLS, яка може зменшити витрати газу на L2 у 1,5-3 рази, залежно від інших включених форм стиснення.
Діаграма з допису про впровадження гаманця BLS, що показує робочий процес для сукупних підписів BLS у ранній версії ERC-4337. Робочий процес для агрегування міжланцюжкових доказів може виглядати дуже схожим.
9. Пряме зчитування стану
Остання можливість, також доступна лише для L2, що читає L1 (а не для L1, що читає L2), полягає в тому, щоб змінити L2 так, щоб вони безпосередньо здійснювали статичні виклики контрактів на L1.
Це можна зробити за допомогою кодів операцій або попередньої компіляції, яка дозволяє викликати L1, де ви надаєте цільову адресу, газ і дані виклику, і він повертає вихідні дані, але оскільки ці виклики є статичними, вони фактично не можуть змінити будь-який стан L1. L2 має знати, що L1 уже обробив депозит, тому ніщо взагалі не заважає застосувати таку річ; це здебільшого проблема технічної реалізації (див. це з оптимістичного запиту на підтримку статичних викликів до L1).
Зауважте, що якщо сховище ключів знаходиться на L1, а L2 інтегрує статичні виклики L1, докази взагалі не потрібні! Однак, якщо L2 не інтегрує статичні виклики L1 або якщо сховище ключів знаходиться на L2 (що, можливо, зрештою доведеться зробити, коли L1 стане надто дорогим для користувачів, щоб навіть трохи його використовувати), тоді буде потрібно підтвердження.
10. Як L2 дізнається останній кореневий стан Ethereum?
Усі наведені вище схеми вимагають доступу L2 до найближчого кореня стану L1 або всього найближчого стану L1. На щастя, усі L2 вже мають деякі функції для доступу до останнього стану L1. Це тому, що їм потрібна така функціональність для обробки повідомлень від L1 до L2, особливо депозитів.
Фактично, якщо L2 має функцію депозиту, тоді ви можете використовувати цей L2 як є, щоб перемістити корінь стану L1 у контракт на L2: просто попросіть контракт на L1 викликати код операції BLOCKHASH і передати його L2 як повідомлення депозиту . Повний заголовок блоку може бути отриманий на стороні L2 і витягнути його корінь стану. Однак кожен L2 переважно має явний спосіб прямого доступу до повного останнього стану L1 або найближчого кореня стану L1.
Основна проблема в оптимізації способу отримання L2 останнього кореня стану L1 полягає в тому, щоб досягти безпеки та низької затримки одночасно:
Якщо L2 реалізує функцію «прямого читання L1» ледачим способом, лише зчитуючи остаточний корінь стану L1, тоді затримка зазвичай становить 15 хвилин, але в екстремальних випадках витоків бездіяльності (з якими ви повинні терпіти), затримка може бути тижнів.
L2, безумовно, може бути розроблений для читання оновлених коренів стану L1, але оскільки L1 може відновлюватися (що трапляється під час неактивних витоків навіть із завершеністю одного сокета), L2 також має мати можливість відновлюватися. З точки зору розробки програмного забезпечення, це технічно складно, але принаймні Optimistic має такі можливості.
Якщо ви використовуєте депозитний міст, щоб перенести коріння стану L1 на L2, тоді проста економіка може вимагати тривалого часу між оновленнями депозиту: якщо повна вартість депозиту становить 100 000 газу, припустимо, що $1800 в ETH і комісія 200 gwei, і корені L1 входять до L2 раз на день, це коштуватиме 236 доларів США за L на день, або 13 148 доларів США за L2 на рік для підтримки системи. Година затримки коштує колосальних $315 569 за L2 на рік. У кращому випадку є постійний потік нетерплячих заможних користувачів, які платять за оновлення та підтримку системи в актуальному стані для всіх інших. У гіршому випадку деяким акторам-альтруїстам доведеться платити за це самим.
«Оракули» (принаймні технологія, яку деякі співробітники DeFi називають «оракулами») тут не є прийнятним рішенням: керування ключами гаманця є дуже важливою для безпеки низькорівневою функцією, тому вона повинна залежати щонайбільше від кількох дуже простих, низькорівнева інфраструктура, яка не потребує криптографічної довіри.
Крім того, у зворотному напрямку (L1s читається як L2):
У Optimistic Aggregation корінням стану потрібен тиждень, щоб досягти рівня L1 через затримки підтвердження шахрайства. У зведених версіях ZK тепер це займає години через поєднання часу перевірки та економічних обмежень, хоча майбутні технології скоротять це.
Попереднє підтвердження (від секвенсора, сертифікатора тощо) не є прийнятним рішенням для L1 зчитування L2. Керування гаманцем є дуже важливою для безпеки низькорівневою функцією, тому рівень безпеки зв’язку L2 – L1 має бути абсолютним: неможливо навіть надіслати неправильний корінь стану L1, переймаючи набір валідатора L2. Єдиний кореневий стан, якому L1 повинен довіряти, це той, який був прийнятий як остаточний кореневий стан згідно з договором утримання кореневого стану L2 на L1.
У багатьох випадках використання DeFi деякі з них є неприйнятно повільними для надійних міжланцюжкових операцій; у цих випадках вам справді потрібні швидші мости з більш недосконалими моделями безпеки. Однак у разі використання оновлення ключів гаманця прийнятніші тривалі затримки: замість того, щоб затримувати транзакції на години, ви відкладаєте зміни ключів. Вам просто потрібно довше зберігати старий ключ. Якщо ви змінюєте свій ключ через те, що його вкрали, у вас є вразливість протягом тривалого часу, але її можна пом’якшити, наприклад. Через гаманець із функцією заморожування.
Зрештою, найкраще рішення для мінімізації затримки полягає в тому, щоб L2 оптимально реалізував пряме читання кореня стану L1, де кожен блок L2 (або журнал обчислень кореня стану) містить вказівник на останній блок L1, тому, якщо L1 відновиться, і L2 також може відновитися. Контракти сховища ключів слід розміщувати в основній мережі або на L2 ZK Rollup, щоб їх можна було швидко закріпити за L1.
Блоки ланцюга L2 можуть залежати не тільки від попередніх блоків L2, а й від блоків L1. Якщо L1 відновлюється через таке посилання, L2 також відновиться. Варто зазначити, що це також те, як передбачалося, що попередні (до Dank) версії шардингу працюватимуть; код див. тут.
11. Скільки з’єднань з Ethereum потрібно іншому ланцюжку, щоб утримувати сховище ключів на основі Ethereum або гаманця L2?
На диво, не так багато. Насправді це навіть не обов’язково має бути зведенням: якщо це L3 або перевірка, добре зберігати там гаманець, доки ви тримаєте сховище ключів на зведенні L1 або ZK. Що вам дійсно потрібно, так це ланцюжок, щоб мати прямий доступ до кореня стану Ethereum, а також технічні та соціальні зобов’язання, щоб бути готовими до реорганізації, якщо Ethereum реорганізується, і до хардфорку, якщо Ethereum хардфорк.
Цікаве питання дослідження полягає в тому, щоб визначити ступінь, до якого ланцюжок може мати таку форму зв’язку з багатьма іншими ланцюгами (наприклад, Ethereum і Zcash). Зробити це наївно можливо: якщо Ethereum або Zcash реорганізуються, ваш ланцюжок може погодитися на реорганізацію (і хардфорк, якщо Ethereum або Zcash хардфорк), але ваші оператори вузлів і ваша спільнота зазвичай мають подвійну технологічну та політичну залежність. Таким чином, цю техніку можна використовувати для підключення до деяких інших ланцюгів, але з підвищеною ціною. Схеми на основі мостів ZK мають привабливі технічні властивості, але їх ключовим недоліком є те, що вони не стійкі до атак 51% або хардфорків. Можуть бути й розумніші рішення.
12. Захист конфіденційності
В ідеалі ми також хочемо зберегти конфіденційність. Якщо у вас багато гаманців, якими керує одне сховище ключів, ми хочемо переконатися, що:
– Незрозуміло, чи всі ці гаманці пов’язані один з одним.
– Опікуни соціальної реабілітації не знають, яку адресу охороняють.
Це створює деякі проблеми:
Ми не можемо безпосередньо використовувати докази Merkle, оскільки вони не захищають конфіденційність.
Якщо ми використовуємо KZG або SNARK, то підтвердження має надати сліпу версію ключа підтвердження без розкриття розташування ключа підтвердження.
Якщо ми використовуємо агрегацію, то агрегатор не повинен вивчати позиції у відкритому тексті; натомість агрегатор повинен отримувати сліпі докази та мати спосіб агрегувати ці докази.
Ми не можемо використовувати «полегшену версію» (оновлюємо ключі, використовуючи лише міжланцюгові докази), оскільки це створює витік конфіденційності: якщо багато гаманців оновлюються одночасно внаслідок процесу оновлення, з часом витікає інформація, яка може стосуватися ці гаманці.
Тому ми повинні використовувати «важку версію» (перехресне підтвердження кожної транзакції).
З SNARK рішення концептуально просте: за замовчуванням докази приховані, а агрегатори повинні генерувати рекурсивні SNARK, щоб підтвердити SNARK.
Основна проблема цього підходу наразі полягає в тому, що агрегація вимагає від агрегатора створення рекурсивного SNARK, який зараз дуже повільний.
За допомогою KZG ми можемо використовувати цю роботу (див. також: більш формальну версію цієї роботи в документі Caulk) на неіндексованих доказах KZG, що розкривають як відправну точку. Однак агрегування сліпих доказів є відкритою проблемою, яка потребує більшої уваги.
На жаль, читання L1 безпосередньо з L2 не зберігає конфіденційність, хоча реалізація функції прямого читання все ще дуже корисна як для мінімізації затримки, так і через її корисність для інших програм.
13. Підсумок
Щоб мати міжланцюговий гаманець соціального відновлення, найбільш реалістичним робочим процесом є гаманець, який підтримує сховище ключів в одному місці, і гаманець, який підтримує гаманці в багатьох місцях, де гаманець зчитує сховище ключів, щоб (i) оновити свій ключ автентифікації локально переглянути, або (іі) у процесі перевірки кожної транзакції.
Ключовим елементом, який робить це можливим, є міжланцюгові докази. Нам потрібно працювати над оптимізацією цих доказів. ZK-SNARK або спеціальні рішення KZG, які очікують перевірки Verkle, здаються найкращими варіантами.
У довгостроковій перспективі для мінімізації витрат необхідний протокол агрегації (де пакетувальники генерують агреговані докази як частину створення набору всіх дій користувачів, надісланих користувачами). Ймовірно, це слід інтегрувати в екосистему ERC-4337, хоча можуть знадобитися зміни в ERC-4337.
L2 має бути оптимізовано, щоб мінімізувати затримку читання стану L1 (або принаймні кореня стану) з L2. Для L2 ідеально підходить для прямого зчитування стану L1, заощаджуючи місце для перевірки.
Гаманці можуть бути не лише на рівні 2; ви також можете розмістити гаманці на системах із нижчим рівнем підключення до Ethereum (L3, або навіть погодитися включити кореневу систему стану Ethereum і незалежний ланцюг форків).
Однак сховище ключів має бути на рівні L1 або високозахищеному зведеному ZK L2. Використання L1 економить багато складності, але навіть це може бути занадто дорогим у довгостроковій перспективі, тому сховище ключів потрібно використовувати на L2.
Збереження конфіденційності вимагатиме додаткової роботи та ускладнюватиме певний вибір. Але нам, ймовірно, все одно варто звернутися до рішень для збереження конфіденційності, принаймні переконавшись, що все, що ми придумаємо, сумісне із збереженням конфіденційності.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Бутерін: інформація про перехресне читання L2 для гаманців та інших випадків використання
Автор: Віталік Бутерін Компіляція: Vernacular Blockchain
У моїй попередній статті про три зміни я описав деякі з ключових причин, чому важливо почати чітко думати про підтримку L1 + крос-L2, безпеку гаманця та конфіденційність як необхідні фундаментальні функції стеку екосистеми. Речі побудовані як плагіни. які можна індивідуально спроектувати за допомогою одного гаманця.
Ця публікація буде зосереджена безпосередньо на технічних аспектах конкретної підпроблеми, наприклад: як легше читати L1 з L2, L2 з L1 або L2 з іншого L2. Вирішення цієї проблеми має вирішальне значення для включення архітектур розділення активів/сховищ ключів, але воно також має цінні варіанти використання в інших сферах, особливо оптимізуючи надійні ланцюжки викликів між L2, включаючи випадки використання, такі як переміщення ресурсів між L1 і L2. Цей каталог статей Яка мета? Як виглядає крос-ланцюжковий доказ? Яку схему доказів ми можемо використати? Доказ Меркла ЖК СНАРКс Спеціальний сертифікат KZG Доказ дерева Verkle полімеризація пряме читання статусу Як L2 дізнається останній кореневий стан Ethereum? Гаманці на ланцюгах, які не належать до L2 захист конфіденційності Підведіть підсумки
1. Яка мета?
Коли L2 стане основним, користувачі будуть володіти активами в кількох L2 і, можливо, також L1. Щойно гаманці з розумними контрактами (multisig, social recovery або інші) стануть основними, ключі, необхідні для доступу до певних облікових записів, з часом зміняться, і старі ключі більше не повинні бути дійсними. Коли ці дві речі відбудуться, користувачам знадобиться спосіб змінити ключі, які мають доступ до багатьох облікових записів, розташованих у багатьох різних місцях, без здійснення надзвичайно великої кількості транзакцій. Зокрема, нам потрібен спосіб боротьби з контрфактичними адресами: адресами, які жодним чином не були «зареєстровані» в ланцюжку, але все одно потрібно безпечно отримувати та зберігати кошти. Ми всі покладаємося на гіпотетичні адреси: коли ви вперше використовуєте Ethereum, ви можете створити адресу ETH, яку хтось може використовувати для оплати вам, не «реєструючи» адресу в ланцюжку (це вимагає сплати комісії за передачу, тому вже маєте трохи ETH). Для EOA всі адреси починаються з контрфактичної адреси. З гаманцями смарт-контрактів все ще можливі контрфактичні адреси значною мірою завдяки CREATE2, який дозволяє мати адресу ETH, яку можна заповнити лише смарт-контрактом із кодом, який відповідає певному хешу.
Алгоритм обчислення адреси EIP-1014 (CREATE2).
Однак гаманці з розумними контрактами створюють новий виклик: можливість змінювати ключ доступу. Ця адреса є хешем початкового коду та може містити лише початковий ключ перевірки гаманця. Поточний ключ підтвердження зберігатиметься в сховищі гаманця, але цей запис у сховищі не буде чарівним чином поширюватися на інші L2. Якщо користувач має багато адрес на багатьох рівнях L2, включно з адресами, не відомими L2, на якому вони знаходяться (оскільки вони суперечливі), то, здається, є лише один спосіб дозволити користувачам змінювати свої ключі: архітектура поділу активів/сховища ключів. Кожен користувач має (i) «контракт сховища ключів» (або на рівні L1, або на одному конкретному рівні L2), який зберігає ключі перевірки для всіх гаманців і правила для зміни ключів, і (ii) «контракти гаманця», які зчитують ключі перевірки між ланцюжками.
Є два способи досягти цього:
Полегшена версія (перевіряє лише наявність оновлених ключів): кожен гаманець зберігає ключ підтвердження локально та містить функцію, яку можна викликати для перевірки міжланцюжкового підтвердження поточного стану сховища ключів і оновлення його локально збереженого ключа підтвердження для відповідності. Коли гаманець вперше використовується на певному L2, ця функція має бути викликана, щоб отримати поточний ключ автентифікації зі сховища ключів. -Плюси: міжланцюгові докази використовуються економно, тому не має значення, чи дорогі міжланцюгові докази. Усі кошти можна використовувати лише з поточним ключем, тому він залишається безпечним.
2. Як виглядає крос-ланцюгове доказ?
Щоб продемонструвати всю складність, ми розглянемо найскладніший випадок: сховище ключів на одному L2, гаманець на іншому L2. Лише половина цього дизайну потрібна, якщо сховище ключів у гаманці знаходиться на рівні L1.
Припустімо, що сховище ключів знаходиться на Linea, а гаманець – на Kakarot. Повний доказ ключа гаманця включає:
3. Які типи схем доказів ми можемо використовувати?
Є п'ять основних варіантів: -Доказ Меркла -Загальні ЗК-СНАРКи
«Агрегація» означає агрегацію всіх доказів, наданих користувачами в межах кожного блоку, в один великий мета-доказ, який поєднує всі докази. Це можливо з SNARK і KZG, але не з форками Merkle (ви можете трохи комбінувати форки Merkle, але це лише заощадить ваш журнал (txs на блок)/log (загальну кількість сховищ ключів), на практиці це, мабуть, 15-30% посередині, тож, ймовірно, не вартий цієї ціни). Агрегація стає корисною лише тоді, коли в сценарії є велика кількість користувачів, тому на практиці реалізація версії 1 може не використовувати агрегацію та реалізувати її у версії 2.
4. Як працюватимуть докази Merkle?
Це легко: просто дотримуйтеся схеми в попередньому розділі. Точніше, кожен «доказ» (припускаючи випадок доведення максимальної складності одного L2 до іншого L2) міститиме: Гілка Merkle, яка підтверджує кореневий стан L2, що містить сховище ключів, враховуючи останній кореневий стан Ethereum, відомий L2. Сховище ключів містить корінь стану L2, що зберігається у відомому слоті зберігання за відомою адресою (контракт на L1 представляє L2), тому шлях через дерево може бути жорстко закодований. Гілка Merkle, що засвідчує поточний ключ перевірки, враховуючи корінь стану L2, що містить сховище ключів. І тут ключ автентифікації зберігається у відомому слоті зберігання за відомою адресою, тому шлях може бути жорстко закодований. На жаль, докази стану Ethereum є складними, але існують бібліотеки для їх перевірки, і якщо ви використовуєте ці бібліотеки, цей механізм не надто складний для впровадження. **Найбільшою проблемою є вартість. **Докази Меркла дуже довгі, на жаль, дерево Patricia приблизно в 3,9 рази довше, ніж потрібно (якщо бути точним: ідеальне доказ Merkle для дерева, що містить N об’єктів, має довжину 32 * log2(N) байтів, і тому що дерева Patricia Ethereum мають 16 листків на дочірню частину, і доказ цих дерев має довжину 32 * 15 * log16(N) ~= 125 * log2(N) байтів). У державі з приблизно 250 мільйонами (~2²⁸) облікових записів це робить кожне підтвердження 125 * 28 = 3500 байт, або приблизно 56 000 газу, плюс додаткові витрати на декодування та перевірку хешу. Разом ці два докази коштуватимуть приблизно від 100 000 до 150 000 газів (якщо вони використовуються для однієї транзакції, за винятком перевірки підпису) – це набагато більше, ніж поточна базова ціна в 21 000 газів за транзакцію. Однак, якщо доказ перевірено на L2, розбіжність погіршується. Обчислення всередині L2 дешеві, оскільки обчислення виконуються поза ланцюгом і в екосистемі з набагато меншою кількістю вузлів, ніж L1. З іншого боку, дані повинні бути опубліковані в L1. Отже, порівняння полягає не в 21 тис. газу проти 15 тис. газу; це 21 тис. газу L2 проти 100 тис. газу L1. Ми можемо розрахувати, що це означає, порівнявши вартість газу L1 і вартість газу L2:
Наразі L1 у 15-25 разів дорожчий, ніж L2 для простого надсилання, і в 20-50 разів дорожчий для обміну токеном. Просте надсилання – це відносно великий обсяг даних, але розрахунковий обсяг обміну набагато більший. Таким чином, своп є кращим орієнтиром для приблизної вартості обчислення L1 порівняно з обчисленням L2. Беручи все це до уваги, якщо ми припустимо 30-кратне співвідношення витрат між обчислювальними витратами L1 і L2, це, здається, означає, що вартість розміщення доказу Merkle на L2 може бути еквівалентна 50 регулярним транзакціям. Звичайно, використання бінарного дерева Merkle зменшує вартість приблизно в 4 рази, але навіть тоді, у більшості випадків, ціна надто висока – якщо ми готові пожертвувати несумісністю з поточним шестикутним деревом стану Ethereum, ми Шукайте кращі варіанти.
5. Як буде працювати перевірка ZK-SNARK?
Використання ZK-SNARK також концептуально легко зрозуміти: ви просто замінюєте докази Merkle на діаграмі вище на ZK-SNARK, які доводять існування цих доказів Merkle. Для обчислення ZK-SNARK потрібно ~400 000 GAS, що займає близько 400 байт (порівняно з: базова транзакція вимагає 21 000 gas і 100 байт, які можна скоротити до ~ 25 слів після стиснення в майбутньому фестивалі). Таким чином, з обчислювальної точки зору вартість ZK-SNARK у 19 разів перевищує вартість сьогоднішніх базових транзакцій, а з точки зору даних вартість ZK-SNARK у 4 рази перевищує вартість сучасних базових транзакцій і в 16 разів вартість майбутніх базових операцій. Ці цифри є великим покращенням порівняно з доказом Меркель, але вони все ще досить дорогі. Є два способи покращити це: (i) докази KZG спеціального призначення або (ii) агрегація, подібна до агрегації ERC-4337, але з використанням більш химерної математики. Ми можемо вивчати обидва одночасно.
6. Як працюватимуть перевірки KZG спеціального призначення?
Попередження, цей розділ більш математичний, ніж інші. Це тому, що ми виходимо за межі інструментів загального призначення та створюємо дешевші інструменти спеціального призначення, тож нам потрібно глибше йти «під капот». Якщо вам не подобається глибока математика, перейдіть одразу до наступного розділу. По-перше, підсумок того, як працюють зобов’язання KZG: Ми можемо представити набір даних [D_1...D_n], використовуючи доказ KZG полінома, отриманого з даних: зокрема, полінома P, де P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n. w тут «рівномірний корінь», значення wN = 1 для деякого розміру області оцінки N (все це робиться в кінцевих полях). Щоб «закріпити» 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)) Деякі ключові властивості, які слід знати, включають:
Отже, повний доказ вимагає:
7. Як буде працювати дерево Веркла?
Дерева Verkle по суті передбачають об’єднання зобов’язань KZG (або зобов’язань IPA, які можуть бути ефективнішими та використовувати простіше шифрування): щоб зберігати значення 2⁴⁸, ви робите зобов’язання KZG щодо списку значень 2²⁴, кожне з яких саме по собі є зобов’язанням KZG щодо 2²⁴ Вартість. Дерева Verkle наполегливо розглядаються як дерева стану Ethereum, оскільки дерева Verkle можна використовувати для зберігання зіставлення ключів і значень, а не лише для списків (загалом, ви можете створити дерево розміром 2²⁵⁶, але почати пустим, лише якщо ви заповнюєте лише певні частини дерево, коли вам дійсно потрібно їх заповнити).
Як виглядає дерево Віккера. Фактично, ви можете надати кожному вузлу ширину 256 == 2⁸ для дерев на основі IPA та 2²⁴ для дерев на основі KZG. Докази в деревах Verkle дещо довші, ніж у KZG; вони можуть мати довжину в сотні байтів. Їх також важко перевірити, особливо якщо спробувати зібрати багато доказів в одне. Насправді дерева Verkle слід розглядати як дерева Merkle, але більш здійсненні без SNARKing (через меншу вартість даних), а SNARKing дешевший (через нижчу вартість доказів). Найбільшою перевагою дерев Verkle є те, що вони можуть координувати структури даних: докази Verkle можна використовувати безпосередньо для станів L1 або L2, не мають структури суперпозиції та використовують точно той самий механізм для L1 та L2. Як тільки квантові комп’ютери стануть проблемою або як тільки розгалуження Merkle виявиться досить ефективним, дерева Verkle можна буде замінити на місці бінарними хеш-деревами з відповідними SNARK-дружніми хеш-функціями.
8. Агрегати
Якщо N користувачам, які здійснюють N транзакцій (або більш реалістично, N ERC-4337 UserOperations), потрібно підтвердити N крос-чейн заяв, ми можемо заощадити багато грошей, об’єднавши ці докази: об’єднавши ці транзакції в блок або конструктор комплекту який входить до блоку, може створити доказ, який підтверджує всі ці твердження одночасно. Це може означати:
Діаграма з допису про впровадження гаманця BLS, що показує робочий процес для сукупних підписів BLS у ранній версії ERC-4337. Робочий процес для агрегування міжланцюжкових доказів може виглядати дуже схожим.
9. Пряме зчитування стану
Остання можливість, також доступна лише для L2, що читає L1 (а не для L1, що читає L2), полягає в тому, щоб змінити L2 так, щоб вони безпосередньо здійснювали статичні виклики контрактів на L1. Це можна зробити за допомогою кодів операцій або попередньої компіляції, яка дозволяє викликати L1, де ви надаєте цільову адресу, газ і дані виклику, і він повертає вихідні дані, але оскільки ці виклики є статичними, вони фактично не можуть змінити будь-який стан L1. L2 має знати, що L1 уже обробив депозит, тому ніщо взагалі не заважає застосувати таку річ; це здебільшого проблема технічної реалізації (див. це з оптимістичного запиту на підтримку статичних викликів до L1). Зауважте, що якщо сховище ключів знаходиться на L1, а L2 інтегрує статичні виклики L1, докази взагалі не потрібні! Однак, якщо L2 не інтегрує статичні виклики L1 або якщо сховище ключів знаходиться на L2 (що, можливо, зрештою доведеться зробити, коли L1 стане надто дорогим для користувачів, щоб навіть трохи його використовувати), тоді буде потрібно підтвердження.
10. Як L2 дізнається останній кореневий стан Ethereum?
Усі наведені вище схеми вимагають доступу L2 до найближчого кореня стану L1 або всього найближчого стану L1. На щастя, усі L2 вже мають деякі функції для доступу до останнього стану L1. Це тому, що їм потрібна така функціональність для обробки повідомлень від L1 до L2, особливо депозитів. Фактично, якщо L2 має функцію депозиту, тоді ви можете використовувати цей L2 як є, щоб перемістити корінь стану L1 у контракт на L2: просто попросіть контракт на L1 викликати код операції BLOCKHASH і передати його L2 як повідомлення депозиту . Повний заголовок блоку може бути отриманий на стороні L2 і витягнути його корінь стану. Однак кожен L2 переважно має явний спосіб прямого доступу до повного останнього стану L1 або найближчого кореня стану L1. Основна проблема в оптимізації способу отримання L2 останнього кореня стану L1 полягає в тому, щоб досягти безпеки та низької затримки одночасно:
Блоки ланцюга L2 можуть залежати не тільки від попередніх блоків L2, а й від блоків L1. Якщо L1 відновлюється через таке посилання, L2 також відновиться. Варто зазначити, що це також те, як передбачалося, що попередні (до Dank) версії шардингу працюватимуть; код див. тут.
11. Скільки з’єднань з Ethereum потрібно іншому ланцюжку, щоб утримувати сховище ключів на основі Ethereum або гаманця L2?
На диво, не так багато. Насправді це навіть не обов’язково має бути зведенням: якщо це L3 або перевірка, добре зберігати там гаманець, доки ви тримаєте сховище ключів на зведенні L1 або ZK. Що вам дійсно потрібно, так це ланцюжок, щоб мати прямий доступ до кореня стану Ethereum, а також технічні та соціальні зобов’язання, щоб бути готовими до реорганізації, якщо Ethereum реорганізується, і до хардфорку, якщо Ethereum хардфорк. Цікаве питання дослідження полягає в тому, щоб визначити ступінь, до якого ланцюжок може мати таку форму зв’язку з багатьма іншими ланцюгами (наприклад, Ethereum і Zcash). Зробити це наївно можливо: якщо Ethereum або Zcash реорганізуються, ваш ланцюжок може погодитися на реорганізацію (і хардфорк, якщо Ethereum або Zcash хардфорк), але ваші оператори вузлів і ваша спільнота зазвичай мають подвійну технологічну та політичну залежність. Таким чином, цю техніку можна використовувати для підключення до деяких інших ланцюгів, але з підвищеною ціною. Схеми на основі мостів ZK мають привабливі технічні властивості, але їх ключовим недоліком є те, що вони не стійкі до атак 51% або хардфорків. Можуть бути й розумніші рішення.
12. Захист конфіденційності
В ідеалі ми також хочемо зберегти конфіденційність. Якщо у вас багато гаманців, якими керує одне сховище ключів, ми хочемо переконатися, що: – Незрозуміло, чи всі ці гаманці пов’язані один з одним. – Опікуни соціальної реабілітації не знають, яку адресу охороняють. Це створює деякі проблеми:
Основна проблема цього підходу наразі полягає в тому, що агрегація вимагає від агрегатора створення рекурсивного SNARK, який зараз дуже повільний. За допомогою KZG ми можемо використовувати цю роботу (див. також: більш формальну версію цієї роботи в документі Caulk) на неіндексованих доказах KZG, що розкривають як відправну точку. Однак агрегування сліпих доказів є відкритою проблемою, яка потребує більшої уваги. На жаль, читання L1 безпосередньо з L2 не зберігає конфіденційність, хоча реалізація функції прямого читання все ще дуже корисна як для мінімізації затримки, так і через її корисність для інших програм.
13. Підсумок
Щоб мати міжланцюговий гаманець соціального відновлення, найбільш реалістичним робочим процесом є гаманець, який підтримує сховище ключів в одному місці, і гаманець, який підтримує гаманці в багатьох місцях, де гаманець зчитує сховище ключів, щоб (i) оновити свій ключ автентифікації локально переглянути, або (іі) у процесі перевірки кожної транзакції. Ключовим елементом, який робить це можливим, є міжланцюгові докази. Нам потрібно працювати над оптимізацією цих доказів. ZK-SNARK або спеціальні рішення KZG, які очікують перевірки Verkle, здаються найкращими варіантами. У довгостроковій перспективі для мінімізації витрат необхідний протокол агрегації (де пакетувальники генерують агреговані докази як частину створення набору всіх дій користувачів, надісланих користувачами). Ймовірно, це слід інтегрувати в екосистему ERC-4337, хоча можуть знадобитися зміни в ERC-4337. L2 має бути оптимізовано, щоб мінімізувати затримку читання стану L1 (або принаймні кореня стану) з L2. Для L2 ідеально підходить для прямого зчитування стану L1, заощаджуючи місце для перевірки. Гаманці можуть бути не лише на рівні 2; ви також можете розмістити гаманці на системах із нижчим рівнем підключення до Ethereum (L3, або навіть погодитися включити кореневу систему стану Ethereum і незалежний ланцюг форків). Однак сховище ключів має бути на рівні L1 або високозахищеному зведеному ZK L2. Використання L1 економить багато складності, але навіть це може бути занадто дорогим у довгостроковій перспективі, тому сховище ключів потрібно використовувати на L2. Збереження конфіденційності вимагатиме додаткової роботи та ускладнюватиме певний вибір. Але нам, ймовірно, все одно варто звернутися до рішень для збереження конфіденційності, принаймні переконавшись, що все, що ми придумаємо, сумісне із збереженням конфіденційності.