В моей предыдущей статье о трех сменах я изложил некоторые из ключевых причин, по которым полезно начать явно думать о поддержке L1 + cross-L2, безопасности кошелька и конфиденциальности как о необходимых фундаментальных функциях стека экосистемы. Все построено как плагины. который может быть индивидуально разработан одним кошельком.
В этом посте основное внимание будет уделено техническим аспектам конкретной подзадачи, например: как проще прочитать L1 из L2, L2 из L1 или L2 из другого L2. Решение этой проблемы имеет решающее значение для включения архитектур разделения активов и хранилищ ключей, но оно также имеет ценные варианты использования в других областях, в первую очередь для оптимизации надежных цепочек вызовов между L2, включая такие варианты использования, как перемещение активов между L1 и L2.
Этот каталог статей
Какова цель?
Как выглядит перекрестное доказательство?
Какую схему доказательства мы можем использовать?
Доказательство Меркла
ЗК СНАРК
Выделенный сертификат KZG
Доказательство дерева Веркле
полимеризация
прямое чтение статуса
Как L2 узнает самый последний корень состояния Ethereum?
Кошельки в цепочках, отличных от L2s
защита конфиденциальности
Подведем итог
1. Какова цель?
Как только L2 станет основным, пользователи будут владеть активами на нескольких L2 и, возможно, L1. Как только кошельки со смарт-контрактами (мульти-подпись, социальное восстановление или другие) станут массовыми, ключи, необходимые для доступа к определенным учетным записям, со временем изменятся, и старые ключи больше не должны быть действительными. Как только эти две вещи произойдут, пользователям понадобится способ изменить ключи, которые имеют доступ ко многим учетным записям, расположенным в разных местах, без совершения чрезвычайно большого количества транзакций.
В частности, нам нужен способ работы с контрафактными адресами: адресами, которые не были каким-либо образом «зарегистрированы» в цепочке, но все же должны безопасно получать и хранить средства. Мы все полагаемся на вымышленные адреса: когда вы впервые используете 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, известный Какарот.
Доказательство текущего ключа в хранилище ключей с учетом текущего корня состояния Linea
Здесь есть две основные сложные проблемы реализации:
Какие доказательства мы используем? (Это доказательство Меркель? Что-то еще?
Как L2 сначала узнает ближайший корень состояния L1 (Ethereum) (или, как мы увидим, возможно, полное состояние L1)? Или как L1 узнает корни состояния L2?
В обоих случаях, как долго длится задержка между тем, что происходит на одной стороне, и тем, что можно продемонстрировать на другой стороне?
3. Какие типы схем доказательства мы можем использовать?
Есть пять основных вариантов:
-доказательство Меркла
-Общие ZK-SNARKs
Специальное доказательство (например, с использованием KZG)
Веркле демонстрирует, что они находятся между KZG и ZK-SNARKs с точки зрения нагрузки на инфраструктуру и стоимости.
Доказательство не требуется, полагается на прямое чтение состояния
С точки зрения требуемой работы с инфраструктурой и затрат на пользователей я бы примерно ранжировал их следующим образом:
«Агрегация» означает объединение всех доказательств, предоставленных пользователями в каждом блоке, в одно большое мета-доказательство, объединяющее все доказательства. Это возможно со SNARK и KZG, но не с форками Merkle (вы можете немного комбинировать форки Merkle, но это только экономит ваш лог (транзакции на блок)/лог (общее количество хранилищ ключей), на практике это, вероятно, 15-30% посередине, так что это, вероятно, не стоит цены).
Агрегация имеет смысл только тогда, когда в сценарии много пользователей, поэтому на практике реализация версии 1 может не включать агрегацию и реализовывать ее в версии 2.
4. Как будут работать доказательства Меркла?
Это легко: просто следуйте схеме в предыдущем разделе. Точнее, каждое «доказательство» (при условии доказательства максимальной сложности одного L2 для другого L2) будет содержать:
Ветвь Merkle, свидетельствующая о корне состояния L2, содержащем хранилище ключей, с учетом последнего корня состояния Ethereum, известного L2. Хранилище ключей содержит корень состояния L2, хранящийся в известном слоте хранилища по известному адресу (контракт на L1 представляет L2), поэтому путь через дерево может быть жестко запрограммирован.
Ветвь Merkle, подтверждающая текущий ключ проверки, с учетом корня состояния L2, содержащего хранилище ключей. Здесь снова ключ аутентификации хранится в известном слоте хранилища по известному адресу, поэтому путь может быть жестко закодирован.
К сожалению, доказательства состояния Ethereum сложны, но существуют библиотеки для их проверки, и если вы используете эти библиотеки, реализовать этот механизм не так уж сложно.
**Большая проблема – стоимость. ** Доказательства Меркла очень длинные, к сожалению, дерево Патрисии примерно в 3,9 раза длиннее, чем необходимо (точнее: идеальное доказательство Меркла для дерева, содержащего N объектов, имеет длину 32 * log2(N) байт, и поскольку деревья Патриции Эфириума имеют 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. Так что сравнение не 21k газа против 15k газа, это 21k газа L2 против 100k газа L1.
Мы можем рассчитать, что это означает, посмотрев на сравнение стоимости газа L1 и стоимости газа L2:
В настоящее время L1 в 15-25 раз дороже L2 для простой отправки и в 20-50 раз дороже для свопов токенов. Простая отправка относительно большого объема данных, но расчетная сумма обмена намного больше. Таким образом, своп является лучшим показателем приблизительной стоимости вычислений L1 по сравнению с вычислениями L2. Принимая все это во внимание, если мы предположим 30-кратное соотношение затрат между вычислительными затратами L1 и вычислительными затратами L2, это, по-видимому, означает, что стоимость размещения доказательства Меркла на L2 может быть эквивалентна 50 обычным транзакциям.
Конечно, использование бинарных деревьев Меркла снижает стоимость примерно в 4 раза, но даже в этом случае, в большинстве случаев, цена слишком высока — если мы готовы пожертвовать совместимостью с текущим гексагональным деревом состояний Эфириума, мы ищем лучшие варианты.
5. Как будет работать доказательство ZK-SNARK?
Использование ZK-SNARK также концептуально легко понять: вы просто заменяете доказательства Меркла на диаграмме выше на ZK-SNARK, доказывающие существование этих доказательств Меркла. ZK-SNARK требует ~ 400 000 GAS для вычислений, что занимает около 400 байт (по сравнению с: для базовой транзакции требуется 21 000 газа и 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 ), ком( 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)) , поэтому всякий раз, когда кому-то нужно. При обновлении ончейн-дерева они могут просто предоставить подтверждение своей правильности соответствующему com(L_i).
Итак, у нас есть структура, в которой мы можем продолжать добавлять значения в конец растущего списка, хотя и с некоторым ограничением размера (на самом деле, сотни миллионов могут быть выполнимы). Затем мы используем это в качестве нашей структуры данных для управления (i) обязательствами по списку ключей на каждом L2, хранящемся на этом L2 и отражаемом на L1, и (ii) обязательствам по списку обязательств по ключам L2, хранящемуся на Ethereum L1 и зеркалируется на каждый L2.
Обновление обязательств может быть частью основной логики L2 или реализовано через мост депозита и снятия без изменения основного протокола L2.
Таким образом, полное доказательство требует:
Хранилище ключей содержит последний com (список ключей) на уровне L2 (48 байт).
-KZG доказывает, что com(список ключей) является com(значение в зеркале_list), приверженность всем спискам отправки списков ключей (48 байт)
-KZG доказывает, что ваш ключ находится в com (списке ключей) (48 байт, плюс 4 байта для индекса)
На самом деле можно объединить два доказательства KZG в одно, поэтому мы получаем общий размер всего 100 байт.
Обратите внимание на одну тонкость: поскольку список ключей представляет собой список, а не карту ключ/значение, как состояние, списку ключей должны быть назначены позиции по порядку. Контракт с обязательством по ключу будет содержать собственный внутренний реестр, сопоставляя каждое хранилище ключей с идентификатором, и для каждого ключа будет храниться хэш (адрес хранилища ключей), а не только ключ, чтобы явно сообщать другим L2, какое хранилище ключей конкретная запись говорит о.
Преимущество этого метода в том, что он очень хорошо работает на L2. Данные составляют 100 байт, что примерно в 4 раза короче, чем ZK-SNARK, и короче, чем доказательства Меркла. Стоимость расчета в основном составляет одну проверку пары или около 119 000 газа. В L1 данные менее важны, чем вычисления, поэтому, к сожалению, KZG немного дороже, чем доказательства Меркла.
7. Как будет работать дерево Веркле?
Деревья Verkle, по сути, включают в себя объединение обязательств KZG (или обязательств IPA, которые могут быть более эффективными и использовать более простое шифрование): для хранения значений 2⁴⁸ вы делаете обязательство KZG для списка значений 2²⁴, каждое из которых само по себе является обязательством KZG для 2²⁴ Значение. Деревья Verkle настоятельно рекомендуются для деревьев состояний Ethereum, потому что деревья Verkle могут использоваться для хранения сопоставлений ключ-значение, а не только списков (по сути, вы можете создать дерево размером 2²⁵⁶, но начать пустым, только если вы заполните только определенные части дерево, когда вам действительно нужно их заполнить).
Как выглядит дерево Виккера. На самом деле, вы можете задать каждому узлу ширину 256 == 2⁸ для деревьев на основе IPA и 2²⁴ для деревьев на основе KZG.
Доказательства в деревьях Веркле несколько длиннее, чем в KZG, они могут занимать сотни байт. Их также трудно проверить, особенно если попытаться объединить множество доказательств в одно.
На самом деле деревья Веркла следует рассматривать как деревья Меркла, но они более осуществимы без SNARK (из-за более низкой стоимости данных), а SNARK дешевле (из-за более низкой стоимости доказательства).
Самым большим преимуществом деревьев Веркла является то, что они могут координировать структуры данных: доказательства Веркла могут использоваться непосредственно для состояний L1 или L2, не имеют структуры суперпозиции и используют точно такой же механизм для L1 и L2. Как только квантовые компьютеры станут проблемой или когда ветвление Меркла окажется достаточно эффективным, деревья Веркла можно будет заменить на месте бинарными хеш-деревьями с подходящими хеш-функциями, удобными для SNARK.
8. Агрегаты
Если N пользователям, совершающим N транзакций (или, что более реалистично, N UserOperations ERC-4337) необходимо доказать N межцепочечных утверждений, мы можем сэкономить много денег, объединив эти доказательства: объединив эти транзакции в блок или создатель пакета который входит в блок, может создать доказательство, доказывающее все эти утверждения одновременно.
Это может означать:
Доказательства ZK-SNARK для ветвей N Merkle
мультидоказательство KZG
Мультидоказательство Веркле (или мультидоказательство ZK-SNARK)
Во всех трех случаях для каждого доказательства требуется всего несколько сотен тысяч газа. Строитель должен сделать одну из них на каждом L2 для пользователей в этом L2; таким образом, для простоты построения вся схема должна быть достаточно использована, чтобы обычно было по крайней мере несколько транзакций в одном блоке на нескольких крупных торговых L2. .
Если используются ZK-SNARK, основная предельная стоимость — это просто «бизнес-логика» передачи чисел между контрактами, поэтому каждому пользователю может потребоваться несколько тысяч газа L2. Если используется мультипроверка KZG, доказывающему необходимо добавить 48 газа для каждого хранилища ключей, содержащего L2, используемого в блоке, поэтому предельные затраты схемы на пользователя будут на L2 (а не на пользователя), а затем добавлено ~800 газа L1. . Но эти затраты намного ниже, чем без агрегации, которая неизбежно включает более 10 000 газа L1 и сотни тысяч газа L2 на пользователя. Для деревьев Verkle вы можете использовать мультипроверки Verkle напрямую, добавляя около 100-200 байт на пользователя, или вы можете сделать ZK-SNARKs мультипроверок Verkle, которые стоят так же, как ZK-SNARKs, разветвленные Merkle, но доказательство стоит намного ниже.
С точки зрения реализации сборщикам лучше агрегировать кроссчейн доказательства через стандарт абстракции учетной записи ERC-4337. В ERC-4337 уже есть механизм, позволяющий разработчикам объединять части действий пользователя нестандартным образом. Существует даже реализация для агрегации сигнатур BLS, которая может снизить затраты газа на L2 в 1,5–3 раза, в зависимости от других включенных форм сжатия.
Схема из сообщения о реализации кошелька BLS, показывающая рабочий процесс для агрегированных подписей BLS в ранней версии ERC-4337. Рабочий процесс для агрегирования доказательств между цепочками может выглядеть очень похоже.
9. Прямое чтение статуса
Последняя возможность, также доступная только для L2, читающего L1 (а не для L1, читающего L2), состоит в том, чтобы модифицировать L2 так, чтобы они напрямую выполняли статические вызовы контрактов на L1.
Это можно сделать с помощью кодов операций или предварительной компиляции, которая разрешает вызовы на L1, где вы предоставляете целевой адрес, газ и данные вызова, и он возвращает выходные данные, но, поскольку эти вызовы являются статическими, они фактически не могут изменить какое-либо состояние L1. L2 должен знать, что L1 уже обработал депозит, так что ничто не мешает реализовать такую вещь, это в основном техническая проблема реализации (см.: это из оптимистичного RFP для поддержки статических вызовов в 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 долларов за л в день или 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 и Zcash). Сделать это наивно можно: если Ethereum или Zcash реорганизуется, ваша сеть может согласиться на реорганизацию (и провести хардфорк, если Ethereum или Zcash хардфоркнет), но операторы ваших узлов и ваше сообщество обычно имеют двойную технологическую и политическую зависимость. Следовательно, этот метод можно использовать для подключения к некоторым другим цепям, но с повышенной стоимостью. Схемы на основе моста ZK обладают привлекательными техническими характеристиками, но их главная слабость заключается в том, что они неустойчивы к атакам 51% или хардфоркам. Могут быть и более разумные решения.
12. Защита конфиденциальности
В идеале мы также хотим сохранить конфиденциальность. Если у вас есть много кошельков, управляемых одним и тем же хранилищем ключей, мы хотим убедиться, что:
Непонятно, связаны ли все эти кошельки друг с другом.
Охранники социальной реабилитации не знают, какой адрес они защищают.
Это создает некоторые проблемы:
Мы не можем использовать доказательства Меркла напрямую, потому что они не защищают конфиденциальность.
Если мы используем KZG или SNARK, то доказательство должно предоставить слепую версию ключа проверки без раскрытия местоположения ключа проверки.
Если мы используем агрегацию, то агрегатор не должен узнавать позиции в открытом тексте, вместо этого агрегатор должен получать слепые доказательства и иметь возможность агрегировать эти доказательства.
Мы не можем использовать «облегченную версию» (обновление ключей только с использованием кросс-чейн доказательств), потому что это создает утечку конфиденциальности: если много кошельков обновляются одновременно из-за процесса обновления, происходит утечка информации, которая может иметь отношение к эти кошельки.
Поэтому мы должны использовать «тяжелую версию» (кроссчейн доказательство каждой транзакции).
Со SNARK решение концептуально простое: по умолчанию доказательства скрыты, и агрегаторы должны генерировать рекурсивные SNARK для проверки SNARK.
Основная проблема с этим подходом в настоящее время заключается в том, что для агрегации требуется, чтобы агрегатор создал рекурсивный SNARK, который в настоящее время очень медленный.
С KZG мы можем использовать эту работу (см. также: более формальную версию этой работы в статье Колка) по неиндексированному раскрытию доказательств KZG в качестве отправной точки. Однако агрегирование слепых доказательств — открытая проблема, требующая большего внимания.
К сожалению, чтение L1 напрямую из L2 не сохраняет конфиденциальность, хотя реализация функции прямого чтения по-прежнему очень полезна как для минимизации задержки, так и из-за ее полезности для других приложений.
13. Резюме
Чтобы иметь кроссчейн кошелек социального восстановления, наиболее реалистичным рабочим процессом является кошелек, который поддерживает хранилище ключей в одном месте, и кошелек, который поддерживает кошельки во многих местах, где кошелек считывает хранилище ключей, чтобы (i) обновить свой ключ аутентификации локально. просмотра или (ii) в процессе проверки каждой транзакции.
Ключевым элементом, который делает это возможным, являются кроссчейн доказательства. Нам нужно работать над оптимизацией этих доказательств. ZK-SNARK или индивидуальные решения KZG, ожидающие подтверждения Verkle, кажутся лучшими вариантами.
В долгосрочной перспективе для минимизации затрат необходим протокол агрегации (где упаковщики генерируют агрегированные доказательства как часть создания пакета всех пользовательских действий, отправленных пользователями). Это, вероятно, следует интегрировать в экосистему ERC-4337, хотя могут потребоваться изменения в ERC-4337.
L2 должен быть оптимизирован, чтобы свести к минимуму задержку чтения состояния L1 (или, по крайней мере, корня состояния) из L2. Для L2 идеально подходит чтение состояния L1 напрямую, что экономит место для проверки.
Кошельки могут быть не только на L2, вы также можете поставить кошельки на системы с более низким уровнем подключения к Ethereum (L3, или даже просто согласиться на включение корня состояния Ethereum и независимой цепочки форков).
Тем не менее, хранилище ключей должно находиться на уровне L1 или свернутом пакете ZK с высоким уровнем безопасности L2. Использование L1 снижает сложность, но даже это может быть слишком дорого в долгосрочной перспективе, поэтому хранилище ключей необходимо использовать на L2.
Сохранение конфиденциальности потребует дополнительной работы и затруднит определенные действия при выборе. Но нам, вероятно, в любом случае следует обратиться к решениям по сохранению конфиденциальности, по крайней мере, убедившись, что все, что мы придумываем, совместимо с сохранением конфиденциальности.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Бутерин: анализ межуровневых чтений для кошельков и других вариантов использования
Автор: Виталик Бутерин Составление: Vernacular Blockchain
В моей предыдущей статье о трех сменах я изложил некоторые из ключевых причин, по которым полезно начать явно думать о поддержке L1 + cross-L2, безопасности кошелька и конфиденциальности как о необходимых фундаментальных функциях стека экосистемы. Все построено как плагины. который может быть индивидуально разработан одним кошельком.
В этом посте основное внимание будет уделено техническим аспектам конкретной подзадачи, например: как проще прочитать L1 из L2, L2 из L1 или L2 из другого L2. Решение этой проблемы имеет решающее значение для включения архитектур разделения активов и хранилищ ключей, но оно также имеет ценные варианты использования в других областях, в первую очередь для оптимизации надежных цепочек вызовов между L2, включая такие варианты использования, как перемещение активов между L1 и L2. Этот каталог статей Какова цель? Как выглядит перекрестное доказательство? Какую схему доказательства мы можем использовать? Доказательство Меркла ЗК СНАРК Выделенный сертификат KZG Доказательство дерева Веркле полимеризация прямое чтение статуса Как L2 узнает самый последний корень состояния Ethereum? Кошельки в цепочках, отличных от L2s защита конфиденциальности Подведем итог
1. Какова цель?
Как только L2 станет основным, пользователи будут владеть активами на нескольких L2 и, возможно, L1. Как только кошельки со смарт-контрактами (мульти-подпись, социальное восстановление или другие) станут массовыми, ключи, необходимые для доступа к определенным учетным записям, со временем изменятся, и старые ключи больше не должны быть действительными. Как только эти две вещи произойдут, пользователям понадобится способ изменить ключи, которые имеют доступ ко многим учетным записям, расположенным в разных местах, без совершения чрезвычайно большого количества транзакций. В частности, нам нужен способ работы с контрафактными адресами: адресами, которые не были каким-либо образом «зарегистрированы» в цепочке, но все же должны безопасно получать и хранить средства. Мы все полагаемся на вымышленные адреса: когда вы впервые используете Ethereum, вы можете сгенерировать адрес ETH, который кто-то может использовать для оплаты без «регистрации» адреса в цепочке (для этого требуется заплатить комиссию за транзакцию, поэтому уже держите некоторое количество ETH). Для EOA все адреса начинаются с предполагаемого адреса. В кошельках со смарт-контрактами по-прежнему возможны вымышленные адреса, во многом благодаря CREATE2, который позволяет вам иметь адрес ETH, который может быть заполнен только смарт-контрактом с кодом, соответствующим определенному хешу.
EIP-1014 (CREATE2) Алгоритм расчета адреса
Однако кошельки со смарт-контрактами представляют новую проблему: возможность изменения ключа доступа. Этот адрес представляет собой хэш кода инициализации и может содержать только ключ начальной проверки кошелька. Текущий ключ проверки будет храниться в хранилище кошелька, но эта запись хранилища не будет волшебным образом распространяться на другие L2. Если у пользователя есть много адресов на многих L2, включая адреса, неизвестные L2, на котором они находятся (потому что они не соответствуют действительности), то, по-видимому, есть только один способ разрешить пользователям изменять свои ключи: архитектура разделения ресурсов и хранилищ ключей. У каждого пользователя есть (i) «контракт хранилища ключей» (либо на L1, либо на одном конкретном L2), в котором хранятся ключи проверки для всех кошельков и правила смены ключей, и (ii) «контракты кошелька», которые считываются через цепочки для ключей проверки.
Есть два способа добиться этого:
Облегченная версия (только проверяет наличие обновленных ключей): каждый кошелек хранит ключ проверки локально и содержит функцию, которую можно вызвать для проверки кросс-чейн подтверждения текущего состояния хранилища ключей и обновления локально сохраненного ключа проверки для соответствия. Когда кошелек впервые используется на определенном L2, эту функцию необходимо вызвать, чтобы получить текущий ключ аутентификации из хранилища ключей.
2. Как выглядит кроссчейн-доказательство?
Чтобы продемонстрировать всю сложность, мы рассмотрим самый сложный случай: хранилище ключей на одном L2, кошелек на другом L2. Только половина этой конструкции нужна, если хранилище ключей кошелька находится на уровне L1.
Предположим, что хранилище ключей находится на Linea, а кошелек — на Kakarot. Полное доказательство ключа кошелька включает в себя:
3. Какие типы схем доказательства мы можем использовать?
Есть пять основных вариантов: -доказательство Меркла -Общие ZK-SNARKs
«Агрегация» означает объединение всех доказательств, предоставленных пользователями в каждом блоке, в одно большое мета-доказательство, объединяющее все доказательства. Это возможно со SNARK и KZG, но не с форками Merkle (вы можете немного комбинировать форки Merkle, но это только экономит ваш лог (транзакции на блок)/лог (общее количество хранилищ ключей), на практике это, вероятно, 15-30% посередине, так что это, вероятно, не стоит цены). Агрегация имеет смысл только тогда, когда в сценарии много пользователей, поэтому на практике реализация версии 1 может не включать агрегацию и реализовывать ее в версии 2.
4. Как будут работать доказательства Меркла?
Это легко: просто следуйте схеме в предыдущем разделе. Точнее, каждое «доказательство» (при условии доказательства максимальной сложности одного L2 для другого L2) будет содержать: Ветвь Merkle, свидетельствующая о корне состояния L2, содержащем хранилище ключей, с учетом последнего корня состояния Ethereum, известного L2. Хранилище ключей содержит корень состояния L2, хранящийся в известном слоте хранилища по известному адресу (контракт на L1 представляет L2), поэтому путь через дерево может быть жестко запрограммирован. Ветвь Merkle, подтверждающая текущий ключ проверки, с учетом корня состояния L2, содержащего хранилище ключей. Здесь снова ключ аутентификации хранится в известном слоте хранилища по известному адресу, поэтому путь может быть жестко закодирован. К сожалению, доказательства состояния Ethereum сложны, но существуют библиотеки для их проверки, и если вы используете эти библиотеки, реализовать этот механизм не так уж сложно. **Большая проблема – стоимость. ** Доказательства Меркла очень длинные, к сожалению, дерево Патрисии примерно в 3,9 раза длиннее, чем необходимо (точнее: идеальное доказательство Меркла для дерева, содержащего N объектов, имеет длину 32 * log2(N) байт, и поскольку деревья Патриции Эфириума имеют 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. Так что сравнение не 21k газа против 15k газа, это 21k газа L2 против 100k газа L1. Мы можем рассчитать, что это означает, посмотрев на сравнение стоимости газа L1 и стоимости газа L2:
В настоящее время L1 в 15-25 раз дороже L2 для простой отправки и в 20-50 раз дороже для свопов токенов. Простая отправка относительно большого объема данных, но расчетная сумма обмена намного больше. Таким образом, своп является лучшим показателем приблизительной стоимости вычислений L1 по сравнению с вычислениями L2. Принимая все это во внимание, если мы предположим 30-кратное соотношение затрат между вычислительными затратами L1 и вычислительными затратами L2, это, по-видимому, означает, что стоимость размещения доказательства Меркла на L2 может быть эквивалентна 50 обычным транзакциям. Конечно, использование бинарных деревьев Меркла снижает стоимость примерно в 4 раза, но даже в этом случае, в большинстве случаев, цена слишком высока — если мы готовы пожертвовать совместимостью с текущим гексагональным деревом состояний Эфириума, мы ищем лучшие варианты.
5. Как будет работать доказательство ZK-SNARK?
Использование ZK-SNARK также концептуально легко понять: вы просто заменяете доказательства Меркла на диаграмме выше на ZK-SNARK, доказывающие существование этих доказательств Меркла. ZK-SNARK требует ~ 400 000 GAS для вычислений, что занимает около 400 байт (по сравнению с: для базовой транзакции требуется 21 000 газа и 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 ), ком( 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. Доказательства в деревьях Веркле несколько длиннее, чем в KZG, они могут занимать сотни байт. Их также трудно проверить, особенно если попытаться объединить множество доказательств в одно. На самом деле деревья Веркла следует рассматривать как деревья Меркла, но они более осуществимы без SNARK (из-за более низкой стоимости данных), а SNARK дешевле (из-за более низкой стоимости доказательства). Самым большим преимуществом деревьев Веркла является то, что они могут координировать структуры данных: доказательства Веркла могут использоваться непосредственно для состояний L1 или L2, не имеют структуры суперпозиции и используют точно такой же механизм для L1 и L2. Как только квантовые компьютеры станут проблемой или когда ветвление Меркла окажется достаточно эффективным, деревья Веркла можно будет заменить на месте бинарными хеш-деревьями с подходящими хеш-функциями, удобными для SNARK.
8. Агрегаты
Если N пользователям, совершающим N транзакций (или, что более реалистично, N UserOperations ERC-4337) необходимо доказать N межцепочечных утверждений, мы можем сэкономить много денег, объединив эти доказательства: объединив эти транзакции в блок или создатель пакета который входит в блок, может создать доказательство, доказывающее все эти утверждения одновременно. Это может означать:
Схема из сообщения о реализации кошелька BLS, показывающая рабочий процесс для агрегированных подписей BLS в ранней версии ERC-4337. Рабочий процесс для агрегирования доказательств между цепочками может выглядеть очень похоже.
9. Прямое чтение статуса
Последняя возможность, также доступная только для L2, читающего L1 (а не для L1, читающего L2), состоит в том, чтобы модифицировать L2 так, чтобы они напрямую выполняли статические вызовы контрактов на L1. Это можно сделать с помощью кодов операций или предварительной компиляции, которая разрешает вызовы на L1, где вы предоставляете целевой адрес, газ и данные вызова, и он возвращает выходные данные, но, поскольку эти вызовы являются статическими, они фактически не могут изменить какое-либо состояние L1. L2 должен знать, что L1 уже обработал депозит, так что ничто не мешает реализовать такую вещь, это в основном техническая проблема реализации (см.: это из оптимистичного RFP для поддержки статических вызовов в 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 и Zcash). Сделать это наивно можно: если Ethereum или Zcash реорганизуется, ваша сеть может согласиться на реорганизацию (и провести хардфорк, если Ethereum или Zcash хардфоркнет), но операторы ваших узлов и ваше сообщество обычно имеют двойную технологическую и политическую зависимость. Следовательно, этот метод можно использовать для подключения к некоторым другим цепям, но с повышенной стоимостью. Схемы на основе моста ZK обладают привлекательными техническими характеристиками, но их главная слабость заключается в том, что они неустойчивы к атакам 51% или хардфоркам. Могут быть и более разумные решения.
12. Защита конфиденциальности
В идеале мы также хотим сохранить конфиденциальность. Если у вас есть много кошельков, управляемых одним и тем же хранилищем ключей, мы хотим убедиться, что:
Основная проблема с этим подходом в настоящее время заключается в том, что для агрегации требуется, чтобы агрегатор создал рекурсивный SNARK, который в настоящее время очень медленный. С KZG мы можем использовать эту работу (см. также: более формальную версию этой работы в статье Колка) по неиндексированному раскрытию доказательств KZG в качестве отправной точки. Однако агрегирование слепых доказательств — открытая проблема, требующая большего внимания. К сожалению, чтение L1 напрямую из L2 не сохраняет конфиденциальность, хотя реализация функции прямого чтения по-прежнему очень полезна как для минимизации задержки, так и из-за ее полезности для других приложений.
13. Резюме
Чтобы иметь кроссчейн кошелек социального восстановления, наиболее реалистичным рабочим процессом является кошелек, который поддерживает хранилище ключей в одном месте, и кошелек, который поддерживает кошельки во многих местах, где кошелек считывает хранилище ключей, чтобы (i) обновить свой ключ аутентификации локально. просмотра или (ii) в процессе проверки каждой транзакции. Ключевым элементом, который делает это возможным, являются кроссчейн доказательства. Нам нужно работать над оптимизацией этих доказательств. ZK-SNARK или индивидуальные решения KZG, ожидающие подтверждения Verkle, кажутся лучшими вариантами. В долгосрочной перспективе для минимизации затрат необходим протокол агрегации (где упаковщики генерируют агрегированные доказательства как часть создания пакета всех пользовательских действий, отправленных пользователями). Это, вероятно, следует интегрировать в экосистему ERC-4337, хотя могут потребоваться изменения в ERC-4337. L2 должен быть оптимизирован, чтобы свести к минимуму задержку чтения состояния L1 (или, по крайней мере, корня состояния) из L2. Для L2 идеально подходит чтение состояния L1 напрямую, что экономит место для проверки. Кошельки могут быть не только на L2, вы также можете поставить кошельки на системы с более низким уровнем подключения к Ethereum (L3, или даже просто согласиться на включение корня состояния Ethereum и независимой цепочки форков). Тем не менее, хранилище ключей должно находиться на уровне L1 или свернутом пакете ZK с высоким уровнем безопасности L2. Использование L1 снижает сложность, но даже это может быть слишком дорого в долгосрочной перспективе, поэтому хранилище ключей необходимо использовать на L2. Сохранение конфиденциальности потребует дополнительной работы и затруднит определенные действия при выборе. Но нам, вероятно, в любом случае следует обратиться к решениям по сохранению конфиденциальности, по крайней мере, убедившись, что все, что мы придумываем, совместимо с сохранением конфиденциальности.