Откуда берутся сетевые эффекты L2? Что делает L2 липким?

Автор: Алана Левин; Составитель: Huohuo, народный блокчейн

Два года назад разработчики приложений столкнулись с довольно простым выбором при принятии решения о том, где развернуть свои приложения: Ethereum, Solana, Cosmos или, возможно, какую-то другую цепочку уровня 1. Rollup еще не используется, и мало кто слышал термин «модульный стек». Различия между L1 (пропускная способность, стоимость и т. д.) очевидны и их относительно легко понять.

** Сегодня все выглядит совсем иначе. Разработчики приложений сталкиваются с более широким выбором: L1, общие накопительные пакеты (Optimistic и zk), расширенная инфраструктура IBC, поставщики накопительных пакетов как услуги, цепочки приложений и многое другое. **

Больше вариантов вызывает больше вопросов, в том числе: должны ли команды развертывать общие накопительные пакеты или создавать накопительные пакеты для конкретных приложений? Если вы выберете общий накопительный пакет, какой выбрать? Если они выберут накопительный пакет приложений, какой пакет SDK или накопительный пакет как услугу использовать? Какой уровень доступности данных выбрать? Может ли EigenLayer помочь? Как думать о секвенсорах? Если они решат пойти по пути OP Stack, останется ли в экосистеме суперчейна Optimism смайлик с красочной сферой? Эти вопросы каверзные.

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

1. Фреймворк высокого уровня

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

1) Пользователи с большей вероятностью будут использовать приложение, если оно находится в отдельной сети?

2) Если приложение находится в собственной цепочке, может ли пользователь в равной степени использовать приложение?

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

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

Лучшее управление могло бы улучшить взаимодействие с пользователем, если бы оно было бесплатным. Таким образом, ответ на основной вопрос — будут ли пользователи по-прежнему использовать приложение, если оно будет в своей собственной цепочке — действительно зависит от того, насколько серьезен этот компромисс между контролем и соединением. **

2. Сколько подключений может потерять приложение?

Связи бывают разных форм. Двумя наиболее важными являются: 1) Внимание и 2) Капитал.

** Обратите внимание на собственный дистрибутив. Если проект команды — это первое, с чем пользователи взаимодействуют при входе в экосистему, это веский аргумент в пользу того, чтобы у приложения был собственный дистрибутив. ** Приложения, контролирующие внимание, лучше подходят для запуска собственной цепочки; пользователи будут использовать это приложение независимо от того, в какой цепочке оно существует. На мой взгляд, текущие примеры приложений, которые имеют собственный дистрибутив, включают Mirror, Zora, Manifold, Sound.xyz и OnCyber. Есть также аргумент, что приложения без надежного дистрибутива могут запускать свои собственные сети, чтобы вызвать интерес.

Второй компонент «связности» — это капитал. Часто средства, развернутые пользователями для одного приложения, возвращаются из другого приложения в той же экосистеме. Я называю это «общей ликвидностью», и последствия этого вполне реальны. Мы видели, как новые приложения выбирают один универсальный накопитель вместо другого из-за большего количества ETH, подключенного к экосистеме; ** существующий капитал в экосистеме может помочь устранить барьеры для принятия пользователями (вместо того, чтобы пытаться убедить пользователей ввести новая экосистема)**. Эти соображения относятся к любому приложению, которое встраивает в свой продукт какую-либо форму финансиализации. Примеры за пределами чистого DeFi могут включать сбор статей NFT через Mirror, оплату «кражи» изображений на Stealcam или что-либо с функцией чаевых в продукте.

** Потеря этой «связности с фондами» означает, что приложения должны заставлять пользователей размещать свои ресурсы в сети. ** Одна из причин может заключаться в том, что потребители часто используют приложение — процесс перехода болезненный, поэтому будет легче поддерживать здоровый запас средств в сети. Но еще более убедительно, чем бездействующий инвентарь, предоставление пользователям вариантов, приносящих доход. Это может выглядеть как нативная форма yield, приложение, создающее смежный продукт, который обеспечивает доходность (например, протокол кредитования Blur), или что-то еще.

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

Другими словами, ончейн-игры выигрывают от высокой степени контроля и не подвергаются существенному влиянию, если они изолированы. Другие приложения, которые хорошо подходят для объединения приложений, могут делать это путем субсидирования транзакций (например, первые несколько транзакций бесплатны) или не требовать оплаты поначалу (например, пользовательский контент в сети, определенные социальные приложения, сети DePIN, и т. д.) Минимизируйте авансовые требования к пользовательскому капиталу.

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

3. Минимизируйте потери соединения

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

Единичная экономика Rollups — еще одна область, на которую влияет «подключение». ** Плата за транзакцию L2 состоит из двух факторов: 1) стоимость публикации данных в L1 и 2) стоимость, которую пользователи платят за включение. ** Оператор сводных данных группирует данные о звонках для транзакций, что позволяет распределить затраты на публикацию между пользователями — чем больше транзакций, тем ниже средняя стоимость на пользователя. Это также означает, что менее активные сводки могут задерживать отправку транзакций в L1 до тех пор, пока они не приобретут достаточно большой размер пакета. Следствием этого является более медленное время финализации и худшее взаимодействие с пользователем. Общие заказы, по-видимому, все чаще служат слоями агрегации, где группирование транзакций из нескольких небольших объединений может помочь создать жизнеспособную экономическую единицу для существования длинного хвоста.

4. Мы находимся в переломном моменте?

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

Но в последние месяцы мы начали наблюдать первый приток жителей. Lattice создала OpCraft, автономный сетевой мир, поддерживаемый собственным накопительным пакетом. Такие проекты, как Lit Protocol и Synapse, объявили о своих собственных обновлениях (хотя оба они больше ориентированы на инфраструктуру, чем на приложения). Zora запустила Zorachain. Недавние разговоры с более зрелыми командами прикладного уровня (особенно с теми, кто рассматривает стратегии L2) начали исследовать, подходит ли им объединение приложений.

Я предполагаю, что настоящий переломный момент наступит (как минимум) через 6-12 месяцев. ** Игровые и социальные приложения имеют наиболее очевидное соответствие рынку продуктов благодаря сворачиваниям для конкретных приложений: социальные и игровые приложения в значительной степени зависят от индексации (и получают значительные преимущества, поскольку им не нужно конкурировать с общим состоянием), проблем с порядком (особенно в игровом процессе) и специальные функции (например, безгазовые транзакции) особенно полезны для потребительских товаров, ориентированных на развлечения**. Многие из этих прикладных команд все еще находятся в стадии создания. В частности, на разработку и выпуск игр могут уйти годы.

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

Наконец, я очень верю, что в будущем мы увидим больше накопительных пакетов. Существует множество проектов, создающих инфраструктурные сервисы для свертки приложений. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer и т. д. предоставляют решения с низким уровнем подъема для команд, которые могут запустить свой собственный накопительный пакет.

Espresso, Astria и SUAVE от Flashbots — одни из первых участников рынка секвенсоров. Затраты на установку снижаются, а компромисс «подключения» становится менее серьезным. Оба усиливают аргументы в пользу усыновления. ** Но такое большое количество новых поставщиков инфраструктуры также означает, что команды разработчиков приложений могут потратить время на изучение различных вариантов и испытание этих различных игроков в бою, прежде чем выбрать победителя. **Опять же, хотя есть признаки усыновления, я думаю, что переломный момент наступит еще через несколько месяцев.