Блог V God: Понимание кошельков и других случаев применения Уровень 2 Многоуровневое чтение

Автор: Виталик Бутерин Составитель: Булу сказал

В статье Три перехода Виталик Бутерин, основатель Ethereum, подробно остановился на «основной сети (далее L1) + кроссчейн второго уровня (далее кросс-L2) support"" "Безопасность кошелька" и "конфиденциальность" являются важными значениями как необходимые функции стека экосистемы. Они должны быть не просто какими-то дополнительными компонентами, а сопутствующие функции предоставляет отдельный кошелек.

И эта статья, как отметил Виталик Бутерин, будет посвящена ключевому техническому вопросу: как проще читать данные 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, а кошелек — на еще один л2. Если хранилище ключей в кошельке находится на L1, нужна только половина этой конструкции.

Предположим, что хранилище ключей находится на Linea, а кошелек — на Kakarot. Полный процесс сертификации ключа кошелька должен включать:

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

Здесь есть два основных острых вопроса реализации: «Какое доказательство необходимо использовать? (Это доказательство Меркла? Или что-то еще?)» и «Как L2 узнает ближайший корень состояния L1?» Или «L1 Как чтобы узнать корень состояния L2?"

Итак, в обоих случаях, как долго длится задержка между тем, когда событие происходит с одной стороны, и моментом, когда другая сторона может предоставить доказательства?

**Какие схемы проверки доступны нам? **

На выбор предлагается пять основных методов:

• Доказательство Меркла
• Общие ZK-SNARK
• Сертификат специального назначения (например, с использованием КЗГ)
• Доказательство Verkle между KZG и ZK-SNARK, учитывая как усилия по инфраструктуре, так и стоимость
• нет доказательства, полагается на прямое чтение состояния

С точки зрения требуемой работы инфраструктуры и затрат пользователей их можно примерно ранжировать следующим образом:

«Агрегация» означает объединение всех доказательств, предоставленных пользователями в каждом блоке, в одно большое мета-доказательство, объединяя их вместе. Это работает для SNARK и KZG, но не для вилок Merkle.

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

**Как работают доказательства Меркла? **

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

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

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

Тем не менее, доказательства состояния в Ethereum сложны, но есть библиотеки, которые можно использовать для их проверки, и если использовать эти библиотеки, то механизм не слишком сложен.

Однако более серьезной проблемой является стоимость. **Меркл оказался очень длинным, а дерево Патрисии было в 3,9 раза длиннее, чем необходимо, — намного выше текущей базовой цены в 21 000 Gas Fee за транзакцию.

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

Мы можем рассчитать, что это означает, посмотрев на сравнение между стоимостью платы за газ L1 и стоимостью платы за газ L2:

В настоящее время, если это относительно простая операция отправки, стоимость в сети L1 примерно в 15–25 раз выше, чем в L2, а стоимость обмена токенов примерно в 20–50 раз выше, чем в L2.

Простая операция отправки имеет большой объем данных, а операция обмена требует более высокой вычислительной мощности, поэтому операция обмена является лучшим эталоном для аппроксимации стоимости вычислений L1 и L2.

Суммируя вышеизложенное, если мы предположим 30-кратное соотношение затрат между вычислительными затратами L1 и вычислительными затратами L2, это, по-видимому, означает, что стоимость размещения доказательств Меркла на L2 может быть эквивалентна примерно пятидесяти обычным транзакциям.

Конечно, использование бинарного дерева Меркла уменьшило бы стоимость примерно в 4 раза, но даже в этом случае стоимость в большинстве случаев все равно была бы непомерно высокой, и если бы мы захотели отказаться от совместимости с текущим шестнадцатеричным деревом состояний Эфириума, это могло бы Буду искать лучшие варианты.

**Как работает доказательство ZK-SNARK? **

Использование ZK-SNARK также концептуально легко понять: вы просто заменяете доказательства Меркла на диаграмме выше на ZK-SNARK, доказывающие существование этих доказательств Меркла. Расчетная сумма ZK-SNARK составляет около 400 000 комиссий за газ, около 400 байтов; для базовой транзакции требуется 21 000 комиссионных за газ и 100 байт.

Следовательно, с точки зрения расчета стоимость ZK-SNARK в 19 раз превышает текущую базовую стоимость транзакции; с точки зрения данных стоимость ZK-SNARK в 4 раза превышает текущую базовую стоимость транзакции и в 16 раз превышает будущую. базовая стоимость сделки.

Эти цифры представляют собой огромное улучшение по сравнению с доказательствами Меркла, но все еще довольно дороги. Есть два способа исправить эту ситуацию: (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), ком (X - z)) ? = e(com(P) - com(a), com(1))*

Некоторые ключевые свойства, о которых также следует знать, включают:

Доказательство — это просто значение com(Q), которое составляет 48 байт

• ком（P₁） + ком（P₂） = ком（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. Сделать сертификат KZG ключа пользователя в com (список ключей).

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

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

Преимущество этого метода в том, что он очень хорошо работает на L2. Примерно в 4 раза короче, чем ZK-SNARK, намного короче, чем доказательства Меркла. Стоимость расчета составляет около 119 000 Gas Fee.

На L1 вычислительная мощность важнее данных, поэтому KZG немного дороже, чем доказательство Меркла.

**Как работают деревья Веркле? **

Деревья Verkle, по сути, включают в себя объединение обязательств KZG вместе: для хранения значений 2⁴⁸ можно выполнить обязательство KZG для списка значений 2²⁴, каждое из которых само по себе является обязательством KZG для значений 2²⁴.

Деревья Verkle считаются деревьями состояний Ethereum, потому что деревья Verkle могут использоваться для хранения карт значений ключа.

Доказательства в деревьях Веркле длиннее, чем доказательства KZG, они могут быть длиной в сотни байтов.

На самом деле деревья Веркла следует рассматривать как деревья Меркла, но они более осуществимы без SNARK, но было показано, что SNARK имеет меньшую стоимость доказательства.

Большим преимуществом деревьев Веркла является то, что они могут координировать структуры данных: поэтому их можно использовать непосредственно для L1 или L2, нет структуры суперпозиции, и точно такой же механизм используется для L1 и L2.

Как только квантовые компьютеры станут проблемой или когда ветви Меркла окажутся достаточно эффективными, деревья Веркла найдут больше применений.

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

Если N пользователей совершают N транзакций и должны подтвердить N кроссчейн-заявок, мы можем сэкономить много платы за газ, объединив эти доказательства, что может означать:

• ZK-SNARK доказательство N ветвей Merkle
• Многократный сертификат KZG
• Мультипроверка Verkle (или мультипроверка ZK-SNARK)

Во всех трех случаях каждое доказательство стоит всего несколько сотен тысяч газа.

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

Если используются ZK-SNARK, каждому пользователю может потребоваться потратить тысячи комиссий за газ L2. Если используется мультипроверка KZG, верификатор должен добавить 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 и депонировал его как актив. Сообщение передается к Л2. Полный заголовок блока может быть получен на стороне L2 и извлечен корень его состояния.

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

Основная проблема в оптимизации способа, которым L2 получает последний корень состояния L1, заключается в одновременном обеспечении безопасности и низкой задержки:

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

Также в обратном направлении (L1 читается как L2):

• В Optimistic Rollup корневому каталогу состояния требуется неделя, чтобы достичь уровня L1 из-за задержек, связанных с защитой от мошенничества. В сводках ZK теперь это занимает несколько часов из-за сочетания времени проверки и экономических ограничений, хотя будущие технологии сократят это время.
• Предварительное подтверждение (от секвенатора, сертификатора и т. д.) не является приемлемым решением для чтения L2 L1. Управление кошельком — низкоуровневая функция, очень критичная к безопасности, поэтому уровень безопасности связи L2-L1 должен быть абсолютно высоким. Единственный корень состояния, которому должен доверять L1, — это тот, который был принят в качестве конечного корня состояния корнем состояния L2, держащим контракт на L1.

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

Пользователям просто нужно сохранить старый ключ в течение более длительного периода времени. Если пользователь меняет ключ, потому что он был украден, то действительно существует длительный период уязвимости, но его можно смягчить, например. Через кошелек с функцией заморозки.

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

**Какая степень подключения к Ethereum требуется другой цепочке для хранения хранилища ключей, хранящегося в кошельке Ethereum или L2? **

Удивительно, но не так много. На самом деле, это даже не обязательно должен быть Rollup.

Если это L3 или валидация, можно хранить кошельки там, пока пользователи хранят ключи в L1 или ZK-свертке, им действительно нужна возможность прямого доступа к корню состояния Ethereum, и они готовы хранить в Ethereum При рефакторинге делайте хард-форк при хард-форке Ethereum.

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

защита конфиденциальности

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

• Не позволяйте общественности узнать, что все эти кошельки связаны друг с другом.
• Опекуны социального восстановления не будут знать, по какому адресу они являются опекунами.

Но это создает проблему:

• Мы не можем использовать доказательства Меркла напрямую, потому что они не сохраняют конфиденциальность.
• Если мы используем KZG или SNARK, то доказательство должно предоставить слепую версию ключа проверки без раскрытия местоположения ключа проверки.
• Если мы используем агрегацию, то агрегатор не должен знать местонахождение в открытом виде, вместо этого агрегатор должен получать слепые пруфы и иметь возможность эти пруфы агрегировать.
• Мы не можем использовать «облегченную версию» (кроссчейн аттестация только при смене ключей), потому что это создаст утечку конфиденциальности: если многие кошельки обновляются одновременно из-за апдейтера, то время этих кошельков может быть связанная информация. Поэтому мы должны использовать «полную версию» (кроссчейн доказательство каждой транзакции).

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

Текущая основная проблема с этим подходом заключается в том, что для агрегации требуется, чтобы агрегатор создал рекурсивный SNARK, что довольно медленно.

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

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