Виталик: Какой Layer3 имеет смысл?

Автор: Vitalik, «Какой тип layer 3 имеет смысл?»

Перевод: Дун Имин, ChainCatcher

Особая благодарность Георгиосу Константопулосу, Карлу Флёршу и команде Starkware за отзывы и рецензии.

Одной из тем, которая часто вновь возникает в обсуждениях о масштабировании layer 2, является концепция «layer 3». Если мы можем построить протокол layer 2, привязанный к layer 1, с основной целью обеспечения его безопасности и увеличения масштабируемости, то, конечно, мы можем расширить его, построив протокол layer 3, «привязанный к layer 2 для обеспечения безопасности и добавления большей масштабируемости сверху»?

Простая версия этой идеи заключается в следующем: если у вас есть схема, которая позволяет вам достичь квадратичного роста, можете ли вы наложить эту схему на саму себя и получить экспоненциальный рост? Подобные идеи включают мою статью о масштабируемости 2015 года и упомянутую в докладе Plasma многоуровневую масштабируемость. К сожалению, такая простая концепция layer 3 не так легко реализовать в виде жизнеспособной схемы. Из-за ограничений доступности данных, зависимости от пропускной способности layer 1 для экстренного извлечения или многих других проблем в дизайне всегда есть что-то, что нельзя наложить, и это может дать вам только одно повышение масштабируемости.

Новые идеи вокруг layer 3, такие как рамка, предложенная Starkware, более сложны: они не просто накладывают одно и то же на само себя, но также назначают разные цели для layer 2 и layer 3. Если это будет сделано правильным образом, потенциальная форма этого подхода может быть жизнеспособной. Эта статья подробно рассмотрит, что может иметь смысл в трехуровневой архитектуре, а что может не иметь смысла.

Почему вы не можете поддерживать масштабируемость, накладывая rollups на rollups?

Rollups (см. мою долгую статью здесь) — это технология масштабирования, которая сочетает в себе различные технологии для решения двух основных узких мест масштабирования работы блокчейна: вычислений и данных. Вычисления были решены с помощью «доказательства мошенничества» или SNARK и других методов, которые полагаются на небольшое количество участников для обработки и проверки каждого блока, требуя от остальных выполнять лишь небольшое количество вычислений для проверки правильности процесса доказательства. Эти схемы, особенно SNARK, могут масштабироваться практически без ограничений; мы можем продолжать создавать «много SNARK», чтобы свести больше вычислений к одному доказательству.

Данные — это другая история. Rollups используют ряд методов сжатия, чтобы уменьшить объем данных, которые необходимо хранить в цепочке для транзакций: простые денежные переводы сокращаются с примерно 100 байт до примерно 16 байт, переводы ERC20 в EVM-совместимых цепочках сокращаются с примерно 180 байт до 23 байт, а транзакция ZK-SNARK для защиты конфиденциальности может быть сжата с примерно 600 байт до 80 байт. В каждом случае достигается примерно 8-кратное сжатие. Однако rollup все равно должен делать данные доступными в цепочке в среде, которая гарантирует, что пользователи могут получить доступ и проверить их, чтобы они могли независимо вычислять состояние rollup и присоединяться в качестве проверяющих, когда существующие проверяющие оффлайн. Данные могут быть сжаты один раз, но не могут быть сжаты повторно — если бы это было возможно, обычно существует способ встроить логику второго сжимающего устройства в первое и получить те же преимущества, сжав один раз. Таким образом, «rollups на rollups» на самом деле не могут предоставить значительные преимущества в масштабируемости, однако, как мы увидим ниже, эта модель может быть использована для других целей.

Так какой же «разумный» вариант layer 3?

Давайте посмотрим, что предлагает Starkware в своем посте о layer 3. Starkware был создан очень умными криптографами, которые разумны, поэтому, если они выступают за layer 3, их версия будет гораздо более сложной, чем «если rollups сжимают данные в 8 раз, то, очевидно, rollups на rollups сожмут данные в 64 раза».

Вот изображение из поста Starkware:

Цитируя несколько строк:

На изображении выше показан пример такой экосистемы. Его L3 включает:

1. StarkNet с Validium для доступности данных, например, часто используемый в приложениях, чувствительных к ценам.

2. Специфическая для приложения система StarkNet, настроенная для достижения лучшей производительности приложения, например, за счет использования заданной структуры хранения или сжатия доступности данных.

3. Система StarkEx (например, системы, обслуживающие dYdX, Sorare, Immutable и DeversiFi) с доступностью данных Validium или Rollup, немедленно приносящая StarkNet проверенные преимущества масштабируемости.

4. Приватные экземпляры StarkNet (в этом примере также как L4), позволяющие существовать транзакциям типа защиты конфиденциальности, не включая их в публичный StarkNet.

Мы можем сжать статью до «трех видений 'L3s'»:

• L2 используется для масштабирования, L3 — для настройки функций, таких как конфиденциальность. В этом видении нет попытки обеспечить «квадратичный рост масштабируемости»; вместо этого в стеке есть уровень, который может помочь приложениям масштабироваться, а затем есть независимый уровень для удовлетворения потребностей в настройке для различных случаев использования.

• L2 используется для общего масштабирования, L3 — для настраиваемого масштабирования. Настраиваемое масштабирование может принимать различные формы: специализированные приложения, использующие что-то кроме EVM для вычислений, rollups, оптимизированные для формата данных конкретного приложения, включая разделение «данных» и «доказательства» в каждом блоке и замену доказательства на одно SNARK и т.д.

• L2 используется для бездоверительного расширения (rollups), L3 — для слабо доверительного расширения (validiums). Validium — это система, использующая SNARK для проверки вычислений, но оставляющая доступность данных доверенным третьим лицам или комитетам. На мой взгляд, Validium недооценен: особенно многие «корпоративные блокчейн» приложения на самом деле могут лучше обслуживаться проверяющими, работающими на validium, которые регулярно отправляют хэши на централизованный сервер цепочки для обеспечения наилучшего обслуживания. Уровень безопасности Validium ниже, чем у rollups, но может быть гораздо дешевле.

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

Становятся ли депозиты и снятия средств дешевле и проще в подмножестве L2?

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

Но оказывается, что даже между двумя L2 или даже L3, депозиты и снятия могут быть очень дешевыми. Ключевым моментом здесь является то, что токены и другие активы не обязательно должны выпускаться в корневой цепочке. То есть вы можете иметь токен ERC20 на Arbitrum, создать его обертку на Optimism и перемещать их туда-сюда без каких-либо транзакций L1!

Давайте посмотрим, как работает такая система. Есть два смарт-контракта: базовый контракт на Arbitrum и контракт обернутого токена на Optimism. Чтобы перейти с Arbitrum на Optimism, вам нужно отправить токены на базовый контракт, который сгенерирует квитанцию. Как только Arbitrum будет окончательно подтвержден, вы можете получить Меркл-доказательство этой квитанции и привязать его к состоянию L1, а затем отправить его в контракт обернутого токена на Optimism, который проверит его и выдаст вам обернутый токен. Чтобы вернуть токены, вы можете выполнить ту же операцию в обратном порядке.

Хотя для доказательства депозита на Arbitrum требуется Меркл-путь через состояние L1, Optimism просто нужно прочитать корень состояния L1 для обработки депозита — без необходимости транзакций L1. Обратите внимание, что поскольку данные rollups являются самым дефицитным ресурсом, фактическая реализация этой схемы будет использовать SNARK или KZG-доказательства, а не напрямую использовать Меркл-доказательства, чтобы сэкономить место.

У этой схемы есть один фатальный недостаток по сравнению с токенами на основе L1 (по крайней мере, на оптимистичных rollups): депозиты также должны ждать окна против мошенничества. Если токены привязаны к L1, вывод с Arbitrum или Optimism на L1 требует недельной задержки, но депозиты мгновенны. Однако в этой схеме как депозиты, так и снятия требуют недельной задержки. То есть, неясно, является ли трехуровневая архитектура на идеальных rollups лучше: чтобы гарантировать, что игры против мошенничества, происходящие внутри системы, которая сама работает в игре против мошенничества, безопасны, существует множество технических сложностей.

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

У rollups и validiums есть компромисс между временем подтверждения и фиксированными затратами. L3 может помочь решить эту проблему, но есть ли что-то еще, что может это сделать?

Стоимость каждого транзакционного rollups очень низка: это всего лишь 16-60 байт данных, в зависимости от приложения. Однако rollups также должны платить высокие фиксированные затраты каждый раз, когда они отправляют пакет транзакций в цепочку: оптимистичные rollups требуют 21000 L1 gas за пакет, а ZK rollups — более 400,000 gas (если вы хотите использовать STARKS для предоставления квантово-безопасных вещей, потребуется миллионы gas).

Конечно, rollup может просто подождать, пока не наберется 10 миллионов gas стоимости L2 транзакций, чтобы отправить весь пакет (транзакций), но это приведет к очень длинным интервалам между пакетами, заставляя пользователей ждать дольше для получения подтверждений с высокой безопасностью. Таким образом, им нужно взвесить: более длинные интервалы между пакетами и оптимальные затраты или более короткие интервалы между пакетами и значительно увеличенные затраты.

Чтобы дать нам некоторые конкретные цифры, давайте рассмотрим ZK rollup с затратами на пакет в 600,000 gas и полностью оптимизированный ERC20 перевод (23 байта) с затратами на каждую транзакцию в 368 gas. Предположим, что этот rollup находится на ранней или средней стадии внедрения, TPS составляет 5. Мы можем рассчитать gas на каждую транзакцию и интервал между пакетами:

Если мы войдем в мир с большим количеством настраиваемых проверок и специфических для приложений сред, то многие из них будут обрабатывать значительно меньше 5 TPS. Таким образом, компромисс между временем подтверждения и затратами начинает становиться очень важным. На самом деле, парадигма «L3» действительно решает эту проблему! ZK rollup в ZK rollup, даже простая реализация, имеет фиксированные затраты всего около 8,000 layer-1 gas (500 байт для доказательства). Это изменит таблицу выше на:

Проблема в основном решена, так что разве L3 не прекрасно? Возможно, да. Но стоит отметить, что есть еще один способ решения этой проблемы, вдохновленный агрегированным подтверждением ERC 4337.

Стратегия следующая. Сегодня, если каждый ZK rollup или validium получает доказательство, то доказательство S ~new~ = STF(S ~old~ ,D): новый корень состояния должен быть результатом правильной обработки данных транзакции или прироста состояния на старом корне состояния. В этой новой схеме ZK rollup будет принимать сообщения от контракта пакетной проверки, которые сообщают, что он проверил доказательство пакета утверждений, где каждая утверждение имеет форму S ~new~ = STF(S ~old~ ,D). Это пакетное доказательство может быть построено с помощью рекурсивных SNARK или Halo агрегирования.

Это будет открытый протокол: любой ZK-rollup может присоединиться, и любой пакетный проверяющий может агрегировать доказательства из любого совместимого ZK-rollup и получать компенсацию за транзакционные сборы от агрегатора. Контракт пакетного обработчика будет проверять одно доказательство, а затем передавать сообщение каждому rollup с данным тройным (S ~old~ , S ~new~ , D). Факт, что тройка поступает от контракта пакетного обработчика, будет использоваться в качестве доказательства, что преобразование действительно является действительным.

Если оптимизация будет выполнена должным образом, стоимость каждого агрегирования в этой схеме может составить около 8000, из которых 5000 пойдут на добавление новых обновлений состояния, 1280 на старый и новый корни, а дополнительные 1720 на обработку различных данных. Таким образом, это даст нам те же самые сбережения. На самом деле, Starkware уже имеет нечто подобное, называемое SHARP, хотя это (пока) не является открытым протоколом без разрешений.

Одним из ответов на этот подход может быть: но разве это не является еще одной схемой третьего уровня? У нас будет базовый уровень \<- механизм пакетирования \<- rollup или validium вместо базового уровня \<- rollup \<- validium. С точки зрения философской архитектуры это может быть правдой. Но есть важное различие: промежуточный уровень не является сложной полной системой EVM, а представляет собой упрощенный и высокоспециализированный объект, поэтому он более вероятно будет безопасным, более вероятно будет построен без другого специализированного токена, более вероятно будет иметь минимальное управление и не будет изменяться со временем.

Заключение: что такое « Layer »?

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

Тем не менее, как только мы начинаем углубляться в детали, какие архитектуры имеют смысл, мы сталкиваемся с философскими вопросами: что такое «уровень», а что нет? Базовый уровень \<- механизм пакетирования \<- rollup или validium и базовый уровень \<- rollup \<- rollup или validium выполняют одну и ту же работу, но с точки зрения их работы уровень агрегирования доказательств больше похож на ERC-4337, чем на rollups. Обычно мы не называем ERC-4337 «уровнем 2». Точно так же мы не называем Tornado Cash «уровнем 2», поэтому, если мы хотим быть последовательными, мы не будем называть подсистему, ориентированную на конфиденциальность, находящуюся на уровне L2, уровнем L3. Таким образом, существует нерешенный семантический спор о том, что должно называться «уровнем» в первую очередь.

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

1. Их цель — повысить масштабируемость.

2. Они следуют модели «блокчейн в блокчейне»: у них есть собственный механизм обработки транзакций и собственное внутреннее состояние.

3. Они наследуют всю безопасность цепочки Ethereum.

Таким образом, идеальные rollups и ZK rollups являются L2, но схемы проверки, агрегирования доказательств, ERC 4337, системы конфиденциальности на цепочке и Solidity — это другое дело. Называть некоторые из них L3 может иметь смысл, но, возможно, не все; в любом случае, сейчас определять определения, похоже, еще слишком рано, и архитектура многосводной экосистемы далека от неизменности, а большинство обсуждений ведется только в теории.

Тем не менее, языковые споры не столь важны, как технические вопросы о том, какая структура на самом деле имеет наибольшее значение. Очевидно, что некоторые «уровни», обслуживающие такие не масштабируемые потребности, как конфиденциальность, могут играть важную роль и должны каким-то образом заполнять важные функции агрегирования доказательств, желательно через открытые протоколы. Но в то же время у нас есть достаточные технические причины, чтобы сделать промежуточный уровень, ориентированный на пользовательскую среду и L1, как можно более простым; во многих случаях «связующий уровень», действующий как EVM rollup, может быть не правильным подходом. Я предполагаю, что по мере того как экосистема L2 будет развиваться, более сложные (и более простые) структуры, описанные в этой статье, начнут играть более значимую роль.