L1 против L2, Rollups против Integrated, General-purpose против App-specific

Введение

В этой короткой заметке мы расскажем о конкретных преимуществах:

• L1 против L2
• Роллапы против интегрированных
• Специфические для приложений против универсальных

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

Как отмечается во вступительном сообщении Eclipse перед предстоящим запуском мейннета:

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

Подкаты и L2 - это не плохой UX. Фрагментированные рулоны и L2 - это плохой UX. Правильно разработанные рулоны и L2 должны улучшить UX.

Роллапы против интегрированных

Все цепочки могут со временем взять на вооружение лучшую технологию (например, DAS + ZK), если она окажется полезной. Как говорилось в моем последнем докладе " Наследуют ли роллапы безопасность?", различие между ними выглядит примерно следующим образом:

• "Роллапы" a.k.a. "Модульный" - постройте логически раздельные цепочки, которые передают данные своей основной цепочке (уровень DA). Они повторно используют консенсус принимающей цепочки.
• "Интегрированный" a.k.a. "Монолитный" - интегрируйте все в один протокол с собственным консенсусом. Не публикуйте данные в отдельной цепочке хостов. (Даже если уровень DA и уровень исполнения в каком-то смысле являются логически отдельными частями общего протокола).

Солана и Затмение представляют собой параллельные пути, как показано в " Тезисе Соланы" Syncracy:

Как я уже говорил в недавнем эпизоде Uncommon Core с Хасу, оба подхода будут иметь долгосрочную ценность.

Солана придерживается подхода, при котором все сводится к одному консенсусу. Он стремится к минимальной задержке(время выполнения слота в настоящее время составляет в среднем ~400-500 мс , а в будущем надеется достичь 200 мс), поддерживая при этом большой набор валидаторов(~2 000). Это невероятное достижение потребовало нескольких технических прорывов.

Однако эти две цели (максимальная децентрализация + минимальная задержка) по своей сути противоречат друг другу. Невероятно сложно поддерживать стабильность этого набора консенсуса, работая на максимальной скорости и пропускной способности. В TowerBFT нет формального анализа безопасности или живучести, и неясно, является ли доказательство истории в настоящее время полезным и устойчивым в состязательной модели или его можно просто убрать. Экономичность системы с низкой задержкой также, конечно, увеличивает стимул к централизации.

Eclipse использует подход, основанный на развязывании консенсуса. Роллапы могут иметь меньший набор секвенсоров, подобранных вручную (возможно, даже управляемых одним оператором), чтобы работать в контролируемой среде. Это может еще больше повысить надежность и уменьшить задержки, предлагая продукт Web2 с преимуществами криптографических рельсов. Code, приложение для платежей, развернутое как нечто вроде L2 на Solana с использованием долговечных несов, схоже в своем стремлении к мгновенным и надежным платежам. Помимо отличного пользовательского интерфейса, обеспечивающего почти мгновенную задержку, расширение нижней границы также необходимо для высокоценных финансовых приложений с низкой задержкой.

Затем роллапы могут отправить свои данные в другой децентрализованный набор консенсуса для более надежной проверки в более медленном временном масштабе. Например, Celestia имеет время блокировки 15 с при однослотовом окончании, что на самом деле даже не сильно отличается от Solana! В Solana подтверждения занимают ~400 мс, а окончательность достигается после 32 слотов (~12,8 с).

Здесь нет бесплатного обеда. Существует потенциальный компромисс между свойствами набора валидаторов реального времени (например, в Solana гораздо больше валидаторов, чем секвенсоров в роллапах) и предоставляемыми гарантиями (например, контролируемая отказоустойчивая среда, еще более низкая задержка и т.д.). Соответствующий уровень приверженности (и в каком масштабе времени) - это спектр. Остаются открытые инженерные вопросы, и наилучший вариант, скорее всего, будет зависеть от конкретного случая использования. Само собой разумеется, что стоимость здесь также играет важную роль, поэтому потребуются масштабируемые уровни DA, такие как Celestia (который используется в Eclipse).

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

L1 против L2

Я использую L1 и L2 в более распространенном смысле, чтобы включить роллапы, валидиумы и т.д. Как рассказывается в книге Виталика " Различные типы второго уровня":

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

Что отличает L1 от L2, так это то, как он справляется с развилками. Валидиум вернется, если его L1 вернет блок, и он будет хардфорком, если его базовый слой сделает хардфорк. Чтобы повысить уровень L2, некоторая форма управления L2 должна жить на L1 в виде бридж-контракта, читаемого на L1.

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

Несмотря на распространенное мнение о том, что войны L1 закончились, Ethereum победил, и все конкуренты Ethereum хотят теперь стать L2 - Ethereum L2 не является лучшим решением для всех цепочек.

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

Аргумент о том, что все цепочки должны быть развернуты как Ethereum L2 для собственной безопасности, чаще всего неверен. Скорее, главным преимуществом L2 была возможность использовать сетевые эффекты Ethereum (пользователи, ликвидность, разработчики, инструментарий и т.д.). Это стратегия выхода на рынок.

Борьба за внимание имеет смысл, учитывая, что внимание - единственный дефицитный ресурс в криптовалюте. L2 естественным образом оказываются в центре внимания разработчиков, пользователей, СМИ и т.д., которые имеют наибольшее значение. Раньше, чтобы привлечь к себе внимание, достаточно было быть L2.

Тем не менее, внимание, получаемое от владения языком L2, ослабевает. Список действующих и предстоящих Ethereum L2 сейчас слишком велик, чтобы за ним мог уследить любой человек. Цепочки, переходящие на L2, не получают того внимания, которое получили ранние участники (например, Optimism и Arbitrum). Даже долгожданные zkEVM с трудом привлекают пользователей, приложения и стоимость.

Таким образом, один лишь статус L2 больше не гарантирует всеобщего внимания. Тем не менее, он может дать преимущество по сравнению с отдельными сетями, если Вы сможете привлечь внимание каким-то другим способом. Например, превращение финансовой пирамиды в квадрат может привлечь ~$700 мм в мультисигму без L2. В качестве альтернативы Вы можете построить первый SVM L2 в Ethereum.

Предполагая, что у Вас есть продукт, привлекающий внимание, давайте теперь рассмотрим, как статус L2 может помочь сети задействовать базу пользователей Ethereum и предложить лучший опыт работы с продуктом. Это произойдет, прежде всего, за счет выгодного использования активов, присущих Ethereum (например, ETH) (например, мостов с привлекательной безопасностью и/или UX).

Ценность этого в целом зависит от двух основных предположений:

1.Что существующие активы Ethereum важны для данного сценария использования (например, DeFi зависит от ETH)

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

Заглядывая в будущее на уровне индустрии, главный вопрос заключается в том, каким будет новое и ценное состояние криптовалюты в будущем?

• Если это будущее состояние будет все больше и больше отвязываться от текущего состояния Ethereum-native (например, уникальное новое состояние, RWA и т.д.), то привлекательность L2 может снизиться.
• Если это будущее состояние будет сильно зависеть от текущего состояния Ethereum-native (например, торговля ETH), то L2 могут играть важную роль.

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

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

Например, часто упоминаемые "гарантии расчетов" Ethereum мало что значат для активов реального мира (RWA), таких как стейблкоины (например, USDC) или токенизированные казначейские векселя. Они "погашены", когда эмитент (например, Circle) считает их таковыми.

При таком сценарии привлекательность статуса Ethereum L2 может уменьшиться по сравнению с долей приложений. Новому платежному приложению на основе USDC по своей сути все равно, является ли оно Ethereum L2 или нет. Им просто нужна самая дешевая, самая быстрая и самая надежная инфраструктура, которая позволит им предложить пользователям лучший опыт работы с продуктами.

Создание новых штатов исторически было препятствием для Соланы, но мы видим, что здесь ветер меняется. Многие известные DeFi и инфраструктурные проекты на Солане уже запустили токены, и еще больше их появится. Это запуск маховика Solana.

2.Что мосты Ethereum ←→ L2 предпочтительнее мостов Ethereum ←→ L1 (например, по соображениям безопасности и/или UX)

Предположим, что первое предположение действительно было выполнено для данного случая использования (т.е. Ethereum-native весьма ценны для Вашего приложения). Затем нам нужно спросить, может ли L2 выставить эти активы в более выгодном свете по сравнению с отдельным L1. Допустим, у пользователя есть некоторое количество ETH, и он хочет обменять его на USDC. Куда они идут?

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

Это сравнимо с классическим соединением консенсуса и верификатора (например, IBC). На практике в таких сценариях не было серьезных сбоев кворума валидаторов. Сбои мостов обычно происходят из-за взлома и/или компрометации мультисигнала моста (чему L2 также подвержены).

Хотя улучшения в области безопасности кажутся мне менее убедительными, удобный доступ к пользователям и активам Ethereum - это главное преимущество L2-моста сегодня, на мой взгляд. Такие роллапы, как Base, Optimism и Arbitrum, больше похожи на расширения Ethereum. Пользователи сохраняют те же кошельки и адреса, родной газовый токен является единственной канонической версией ETH, ETH доминирует в DeFi, например, во всех торговых парах, социальные приложения оценивают NFT в ETH и платят создателям в ETH (например, friend.tech), Вклады в L2 мгновенны (потому что они будут реорганизованы вместе), и т.д.

Нельзя ожидать, что пользователи будут рассуждать о том, какой мост использовать, анализировать различные предположения о безопасности, получать один из нескольких доступных обернутых токенов, приобретать собственный токен цепи для газа и т.д. Они просто хотят перевести свой ETH, получить ETH на другой стороне и продолжать использовать L2 так же, как они использовали бы Ethereum или любой другой L2. Именно поэтому Eclipse будет использовать ETH в качестве своего родного токена, используемого для газа. Принудительное введение нового газового жетона вредит UX.

Так почему же Solana не может просто предоставить те же преимущества, что и Ethereum L2? На самом деле, это больше похоже на инженерный вопрос, чем на что-то фундаментальное, и со временем это станет проще. Это относится и к жетонам на газ, и к другим проблемам UX, связанным с простым отказом от использования EVM (что не свойственно L1 и L2):

• Газовый токен - Оплата газа может быть абстрагирована от пользователей, позволяя им платить любым газовым токеном, который они выберут.
• Bridging - Со временем Bridging, скорее всего, станет более жестким и стандартизированным, что приведет к меньшей путанице среди пользователей и фрагментации ликвидности.
• Кошельки - Недавно представленные привязки MetaMask расширяют поддержку MetaMask для не-EVM цепочек с помощью сторонних интеграций, созданных на их основе, например, с помощью привязок MetaMask от Drift или Solflare.
• Опыт разработчиков - Языковые барьеры будут разрушены. Такие проекты, как Solang и Neon, могут помочь разработчикам Solidity опираться на Solana, а такие проекты, как Stylus, могут помочь разработчикам Rust опираться на Arbitrum.

В будущем возможно даже, что ETH будет играть роль в Solana DeFi, если пользователи выскажут сильное предпочтение ETH по сравнению со скоростью и масштабом Solana. На практике гораздо более вероятно, что эти пользователи с Ethereum-родными активами продолжат использовать их в экосистеме Ethereum L2 по причинам, о которых мы уже говорили, при условии, что у них есть доступ к сопоставимо масштабируемым L2.

Специфические для приложений против универсальных

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

Мы часто видим, как "выделенное блочное пространство" упоминается в качестве причины для развертывания рулонной копии для конкретного приложения. Однако это заблуждение возникло во многом из-за ненужных ограничений однопоточного EVM с глобальными рынками гонораров. Распараллеленная SVM с локальными рынками вознаграждений значительно сокращает потребность в цепочках приложений. Размещение большего количества приложений на общей инфраструктуре значительно снижает сложность для разработчиков и пользователей. Межцепочечный UX и сложность разработчиков в многоцепочечном мире - это недооцененный экзистенциальный риск.

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

1. Масштабируемость & Выделенное блочное пространство - Как уже говорилось выше, этот вариант обычно неубедителен. Один монетный двор NFT не должен эффективно закрывать всю остальную сеть, но ответ, как правило, не в том, чтобы пойти и сделать другую сеть. Эта проблема решается с помощью распараллеленной виртуальной машины с локальными рынками гонораров. Однако если пропускная способность всей сети насыщена, местные рынки тарифов не помогут (т.е. тарифы на общую цепочку будут расти глобально). Тогда Вам нужна еще одна цепочка.
2. Суверенитет - Управление в криптовалюте все еще довольно слабое, и наличие собственной цепочки для форка может стать полезным механизмом координации. Моя интуиция подсказывает, что это очень редкое обстоятельство, но трудно сказать с уверенностью. Это соответствует заинтересованности MakerDAO в создании сети приложений.
3. Настраиваемость - Настройки на уровне консенсуса могут быть ценными для определенных приложений (например, dYdX v4), но на сегодняшний день таких случаев эмпирически мало. Даже dYdX, яркий пример цепочки приложений, "скорее всего, будет двигаться в сторону обобщенного исполнения на цепочке dYdX", как сказал Антонио в своем недавнем эпизоде Bell Curve. Потребность в полнофункциональной настраиваемости, которую невозможно решить на общей цепочке, в большинстве криптовалют отсутствовала. Почти все новые рулоны продолжают быть просто ванильными EVM-вилками с новыми токенами.
4. Захват ценности - Это, пожалуй, подмножество настраиваемости, но оно довольно важно, поэтому мы выделим его отдельно. Может быть гораздо сложнее внедрить ценность в общую инфраструктуру, которая создана не только для Вашего приложения. Цепочки приложений могут упростить распределение стоимости между ответственными приложениями. Однако это скорее инженерная, чем фундаментальная задача, и в Solana ведутся исследования, как именно это сделать. Кроме того, обратите внимание на то, что развертывание собственной цепочки требует серьезных накладных расходов по сравнению с амортизацией затрат на общую инфраструктуру.

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

Запуск собственной сети сегодня сопряжен с болезненными и ненужными компромиссами (сложность, стоимость, худший UX, фрагментарная ликвидность и т.д.), которые большинство приложений не могут оправдать, если речь идет о дополнительных преимуществах. Инфраструктура, необходимая для того, чтобы сделать этот UX конкурентоспособным, кажется далекой. Это не значит, что нет никаких причин для существования цепочек приложений (они, безусловно, есть). Скорее, мы, как индустрия, просто сильно переборщили с индексацией в этом направлении, и поэтому нынешняя тенденция к ре-бандлингу явно полезна, учитывая текущее положение дел.

Заключение

В последние месяцы Солана по праву набрал большую популярность. Такая резкая коррекция в значительной степени стала признанием текущего состояния многоцепочечного UX - он фрагментарен и болезнен. UX при использовании приложений Solana просто невероятен. Гладко и быстро.

Рулоны и L2 получили плохую репутацию за UX, но настоящая проблема заключается во фрагментации. Мы ассоциируем rollups и L2 с фрагментированным горизонтальным масштабированием, потому что на практике большинство из них используют EVM как есть и используют ограниченную пропускную способность DA. В итоге они получаются дорогими и неудобными в использовании.

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

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

Отказ от ответственности：

1. Эта статья перепечатана с сайта[dba]. Все авторские права принадлежат оригинальному автору[Jon Charbonneau]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.