Два года назад разработчики приложений столкнулись с довольно простым выбором, в какой цепочке развернуть свое приложение: Ethereum, Solana, Cosmos или другой блокчейн уровня 1. В то время Rollup еще не запустил основную сеть, и мало кто слышал о термине «модульный стек». Различия между L1 (пропускная способность, комиссии и т. д.) очевидны и относительно просты для понимания.
Сегодня все выглядит совсем иначе. Разработчики приложений сталкиваются с более широким выбором: L1, накопительный пакет общего назначения (Optimistic и zk), инфраструктура IBC, поставщик агрегации как услуги, AppChain и многое другое. Чем больше вариантов, тем больше вопросов: должны ли команды развертывать приложения в общих накопительных пакетах или создавать накопительные пакеты для конкретных приложений. Если они выбирают общий накопительный пакет, какой из них выбрать, если они выбирают маршрут накопительного пакета приложений, какой SDK/накопительный пакет как услугу использовать, какой уровень доступности данных выбрать, может ли EigenLayer помочь, как думать о секвенсорах; если они выберут путь OP Stack, сможет ли он занять место в экосистеме суперчейнов Optimism.
Чтобы сузить проблему, в этой статье будет принята структура приложения, уже развернутого в Ethereum, которое хочет масштабироваться в экосистеме Ethereum. Таким образом, в этой статье основное внимание будет уделено дереву решений, с которым сталкиваются группы разработчиков при принятии решения о запуске собственного накопительного пакета, какие типы приложений особенно подходят для определенных типов инфраструктуры, и когда, я думаю, мы можем достичь критической точки внедрения.
Структура высокого уровня
В основе решения о объединении приложений лежит простой вопрос: если приложение будет построено на собственной цепочке, будут ли пользователи по-прежнему его использовать? Дальнейшее развитие это два вопроса:
Будут ли пользователи более склонны использовать приложение, если оно находится в собственной цепочке?
Если приложение находится в собственной цепочке, будут ли пользователи его использовать?
Преимущества накопительных пакетов для конкретных приложений заключаются в лучшем контроле: возможность абстрагировать затраты на газ, ограничить перегрузку в сети, вызванную другой активностью приложения, лучше экспериментировать с использованием токенов, исследовать различные экономические структуры (например, скидки на газ), создавать и настраивать среду выполнения, реализовать элементы управления доступом (например, развертывание разрешений) и многое другое.
Но цена этого дополнительного контроля — потеря связи с более широкой экосистемой. Приложения в универсальной цепочке имеют доступ к ликвидности, уже имеющейся в этой цепочке (например, нет необходимости в дополнительных мостах между цепочками), компонуемость с другими приложениями и внимание пользователей в цепочке. По сравнению с приложениями, которые запускают свои собственные цепочки, построение на общей цепочке также экономит много инженерных накладных расходов.
Лучшее управление могло бы улучшить взаимодействие с пользователем, если бы оно было бесплатным. Таким образом, ответ на основной вопрос — будут ли пользователи по-прежнему использовать приложение, если оно находится в собственной цепочке — действительно зависит от этого компромисса между контролем и подключением.
**Сколькими связями может пожертвовать приложение? **
Связи бывают разных форм, две наиболее важные из них: 1) внимание и 2) капитал.
Внимание связано с родной коммуникацией. Если проект команды — это первый проект, с которым пользователи взаимодействуют при входе в экосистему, то приложение изначально является вирусным. Приложения, которые могут привлечь внимание, лучше подходят для запуска собственной цепочки; пользователи будут использовать приложение независимо от того, в какой цепочке оно находится. На мой взгляд, текущие приложения с собственным распространением включают Mirror, Zora, Manifold, Sound.xyz и OnCyber. Существует также аргумент, что приложения без сильного распространения могут запустить свои собственные сети, чтобы вызвать интерес пользователей (но я нахожу это менее убедительным, если многие сети идут по этому пути одновременно).
Вторая форма связи – это капитал. Часто средства, которые пользователи размещают в одном приложении, переводятся из другого приложения в той же экосистеме. Я называю это «общей ликвидностью», и последствия этого вполне реальны. Большое количество новых приложений выбирают Universal Rollup из-за большого количества ETH, подключенного к этой экосистеме, а существующий капитал в экосистеме может помочь устранить барьеры для принятия пользователями (вместо того, чтобы пытаться убедить пользователей войти в новую экосистему). Эти факторы следует учитывать при рассмотрении любого приложения, включающего в свой продукт какую-либо форму финансиализации. Примеры за пределами DeFi могут включать в себя: сбор документов NFT через зеркало, оплату «кражи» изображений на Stealcam или что-либо с функцией чаевых в продукте.
Потеря этой «связности с фондами» означает, что приложения должны заставлять пользователей размещать средства в сети. Одной из причин может быть то, что потребители часто используют приложение, в конце концов, кросс-цепочки болезненны, поэтому было бы легче поддерживать здоровую поставку средств в сети. Но еще более привлекательным, чем свободные средства, является предоставление пользователям возможности получать доход. Это выглядит как доходность в виде нативных цепочек, приложений, создающих смежные продукты, которые обеспечивают доходность (например, протокол кредитования Blur) и многое другое.
Внимание и капитал также являются причиной того, почему многие считают онлайн-игры идеальными кандидатами для накопительных пакетов для конкретных приложений: они довольно автономны и в значительной степени зависят от плавного взаимодействия с пользователем. Другими словами, ончейн-игры выигрывают от высокой степени контроля и не несут значительных потерь, если они остаются сиротами. Другие приложения, которые хорошо подходят для Rollup, могут делать это, субсидируя транзакции (например, первые несколько транзакций бесплатны) или не требуя оплаты при входе в систему (например, контент, созданный пользователями в сети, определенные социальные приложения, сети DePIN и т. д.). Сводит к минимуму авансовые требования к пользовательскому капиталу.
Конечно, есть и другие причины, по которым проекты хотят большего контроля над своей инфраструктурой. Проприетарные накопительные пакеты позволяют развертывать разрешения и проверять пользователей (например, KYC для секвенсоров, принадлежащих или управляемых сетью). Однако это также приводит к стиранию границы между базами данных Rollup и централизованными базами данных.
Минимизируйте потери связи
По мере улучшения интероперабельности компромисс между подключением и контролем становится менее важным. Мосты и секвенсоры часто являются обсуждаемой критической инфраструктурой. Они несколько похожи в том, что оба позволяют транзакциям в одной цепочке влиять на транзакции в другой цепочке. Мосты делают это, передавая сообщения или разрешая передачу активов, общие ордера делают это, принимая и упорядочивая транзакции из нескольких цепочек. И общие ордера, и мосты необходимы для атомарной компоновки — ордер гарантированно содержит несколько (кроссчейн) транзакций в блоке, а фактическое выполнение этих транзакций обычно требует моста.
Единичная экономика Rollups — еще одна область, на которую влияет «связность». Плата за транзакцию L2 состоит из двух частей: 1) стоимость публикации данных в L1 и 2) стоимость, которую пользователи платят за транзакцию. Сведение группирует данные вызовов транзакций, чтобы стоимость публикации могла быть разделена между пользователями: чем больше транзакций, тем ниже средняя стоимость на пользователя. Это также означает, что менее активные накопительные пакеты могут откладывать публикацию транзакций на L1 до тех пор, пока они не получат достаточно большой пакет транзакций. Следствием этого является более медленное время финализации и плохой пользовательский опыт. Общие заказы, по-видимому, все чаще служат слоями агрегации, где пакетные транзакции из нескольких небольших объединений могут помочь создать жизнеспособную юнит-экономику для длинных хвостов.
** Мы находимся в точке перегиба? **
Идея цепочек приложений и накопительных пакетов приложений не нова. Однако долгое время это было похоже на строящийся жилой район: строится много инфраструктуры, но нет жителей. В последние месяцы мы начали наблюдать приток первых жителей. Lattice создала OpCraft, автономный сетевой мир, поддерживаемый собственным накопительным пакетом; Lit Protocol и Synapse объявили о своем собственном накопительном пакете (хотя оба проекта больше ориентированы на инфраструктуру, чем на приложения); Zora запустила Zorachain. Недавние разговоры со зрелыми командами приложений (особенно с теми, кто рассматривает стратегии L2) начали исследовать, подходят ли им накопительные пакеты приложений.
Я предполагаю, что настоящий переломный момент наступит (как минимум) через 6-12 месяцев. Игровые и социальные приложения имеют наиболее очевидное соответствие рынку продуктов с накопительными пакетами для конкретных приложений: как социальные, так и игровые приложения в значительной степени зависят от индексации, вопросов упорядочения (особенно в игровом процессе) и пользовательских функций (например, транзакций без газа) для развлекательного потребления. важный. Многие команды приложений находятся в стадии создания, особенно игры, на разработку и выпуск которых могут уйти годы.
Еще один мой вывод: для менее финансовых приложений самое важное — привлечь внимание. До сих пор в этой статье накопительные пакеты приложений определялись как «одно приложение на накопительный пакет». Но этот взгляд может быть слишком узким. Возможно, есть несколько приложений, образующих коллектив, чтобы начать цепочку вместе. Точно так же мы можем видеть, как приложение создает свою собственную цепочку и поощряет развертывание других приложений поверх нее.
Наконец, я твердо верю, что в будущем мы увидим больше роллапов. Будет расти число проектов по созданию инфраструктурных сервисов для агрегированных приложений. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer и т. д. предоставляют группам приложений низкопороговые решения для запуска собственного накопительного пакета. Espresso, Astria и SUAVE от Flashbots были одними из первых исследователей в области секвенсоров. Затраты на запуск имеют тенденцию к снижению, и компромисс «подключения» становится менее важным. Но такое большое количество новых поставщиков инфраструктуры также означает, что командам приложений может потребоваться время, чтобы разобраться в различных вариантах, и между этими игроками разразится война. Опять же, хотя есть признаки принятия, я думаю, что переломный момент еще впереди.
Спасибо Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer и Viktor Bunin за их отзывы, комментарии и обсуждения, которые помогли разработать многие из этих идей.
Посмотреть Оригинал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
В условиях тенденции модульности должно ли приложение строить свою собственную цепочку?
Сценарист: Алана Левин; Составитель: Луффи, Foresight News
Два года назад разработчики приложений столкнулись с довольно простым выбором, в какой цепочке развернуть свое приложение: Ethereum, Solana, Cosmos или другой блокчейн уровня 1. В то время Rollup еще не запустил основную сеть, и мало кто слышал о термине «модульный стек». Различия между L1 (пропускная способность, комиссии и т. д.) очевидны и относительно просты для понимания.
Сегодня все выглядит совсем иначе. Разработчики приложений сталкиваются с более широким выбором: L1, накопительный пакет общего назначения (Optimistic и zk), инфраструктура IBC, поставщик агрегации как услуги, AppChain и многое другое. Чем больше вариантов, тем больше вопросов: должны ли команды развертывать приложения в общих накопительных пакетах или создавать накопительные пакеты для конкретных приложений. Если они выбирают общий накопительный пакет, какой из них выбрать, если они выбирают маршрут накопительного пакета приложений, какой SDK/накопительный пакет как услугу использовать, какой уровень доступности данных выбрать, может ли EigenLayer помочь, как думать о секвенсорах; если они выберут путь OP Stack, сможет ли он занять место в экосистеме суперчейнов Optimism.
Чтобы сузить проблему, в этой статье будет принята структура приложения, уже развернутого в Ethereum, которое хочет масштабироваться в экосистеме Ethereum. Таким образом, в этой статье основное внимание будет уделено дереву решений, с которым сталкиваются группы разработчиков при принятии решения о запуске собственного накопительного пакета, какие типы приложений особенно подходят для определенных типов инфраструктуры, и когда, я думаю, мы можем достичь критической точки внедрения.
Структура высокого уровня
В основе решения о объединении приложений лежит простой вопрос: если приложение будет построено на собственной цепочке, будут ли пользователи по-прежнему его использовать? Дальнейшее развитие это два вопроса:
Преимущества накопительных пакетов для конкретных приложений заключаются в лучшем контроле: возможность абстрагировать затраты на газ, ограничить перегрузку в сети, вызванную другой активностью приложения, лучше экспериментировать с использованием токенов, исследовать различные экономические структуры (например, скидки на газ), создавать и настраивать среду выполнения, реализовать элементы управления доступом (например, развертывание разрешений) и многое другое.
Но цена этого дополнительного контроля — потеря связи с более широкой экосистемой. Приложения в универсальной цепочке имеют доступ к ликвидности, уже имеющейся в этой цепочке (например, нет необходимости в дополнительных мостах между цепочками), компонуемость с другими приложениями и внимание пользователей в цепочке. По сравнению с приложениями, которые запускают свои собственные цепочки, построение на общей цепочке также экономит много инженерных накладных расходов.
Лучшее управление могло бы улучшить взаимодействие с пользователем, если бы оно было бесплатным. Таким образом, ответ на основной вопрос — будут ли пользователи по-прежнему использовать приложение, если оно находится в собственной цепочке — действительно зависит от этого компромисса между контролем и подключением.
**Сколькими связями может пожертвовать приложение? **
Связи бывают разных форм, две наиболее важные из них: 1) внимание и 2) капитал.
Внимание связано с родной коммуникацией. Если проект команды — это первый проект, с которым пользователи взаимодействуют при входе в экосистему, то приложение изначально является вирусным. Приложения, которые могут привлечь внимание, лучше подходят для запуска собственной цепочки; пользователи будут использовать приложение независимо от того, в какой цепочке оно находится. На мой взгляд, текущие приложения с собственным распространением включают Mirror, Zora, Manifold, Sound.xyz и OnCyber. Существует также аргумент, что приложения без сильного распространения могут запустить свои собственные сети, чтобы вызвать интерес пользователей (но я нахожу это менее убедительным, если многие сети идут по этому пути одновременно).
Вторая форма связи – это капитал. Часто средства, которые пользователи размещают в одном приложении, переводятся из другого приложения в той же экосистеме. Я называю это «общей ликвидностью», и последствия этого вполне реальны. Большое количество новых приложений выбирают Universal Rollup из-за большого количества ETH, подключенного к этой экосистеме, а существующий капитал в экосистеме может помочь устранить барьеры для принятия пользователями (вместо того, чтобы пытаться убедить пользователей войти в новую экосистему). Эти факторы следует учитывать при рассмотрении любого приложения, включающего в свой продукт какую-либо форму финансиализации. Примеры за пределами DeFi могут включать в себя: сбор документов NFT через зеркало, оплату «кражи» изображений на Stealcam или что-либо с функцией чаевых в продукте.
Потеря этой «связности с фондами» означает, что приложения должны заставлять пользователей размещать средства в сети. Одной из причин может быть то, что потребители часто используют приложение, в конце концов, кросс-цепочки болезненны, поэтому было бы легче поддерживать здоровую поставку средств в сети. Но еще более привлекательным, чем свободные средства, является предоставление пользователям возможности получать доход. Это выглядит как доходность в виде нативных цепочек, приложений, создающих смежные продукты, которые обеспечивают доходность (например, протокол кредитования Blur) и многое другое.
Внимание и капитал также являются причиной того, почему многие считают онлайн-игры идеальными кандидатами для накопительных пакетов для конкретных приложений: они довольно автономны и в значительной степени зависят от плавного взаимодействия с пользователем. Другими словами, ончейн-игры выигрывают от высокой степени контроля и не несут значительных потерь, если они остаются сиротами. Другие приложения, которые хорошо подходят для Rollup, могут делать это, субсидируя транзакции (например, первые несколько транзакций бесплатны) или не требуя оплаты при входе в систему (например, контент, созданный пользователями в сети, определенные социальные приложения, сети DePIN и т. д.). Сводит к минимуму авансовые требования к пользовательскому капиталу.
Конечно, есть и другие причины, по которым проекты хотят большего контроля над своей инфраструктурой. Проприетарные накопительные пакеты позволяют развертывать разрешения и проверять пользователей (например, KYC для секвенсоров, принадлежащих или управляемых сетью). Однако это также приводит к стиранию границы между базами данных Rollup и централизованными базами данных.
Минимизируйте потери связи
По мере улучшения интероперабельности компромисс между подключением и контролем становится менее важным. Мосты и секвенсоры часто являются обсуждаемой критической инфраструктурой. Они несколько похожи в том, что оба позволяют транзакциям в одной цепочке влиять на транзакции в другой цепочке. Мосты делают это, передавая сообщения или разрешая передачу активов, общие ордера делают это, принимая и упорядочивая транзакции из нескольких цепочек. И общие ордера, и мосты необходимы для атомарной компоновки — ордер гарантированно содержит несколько (кроссчейн) транзакций в блоке, а фактическое выполнение этих транзакций обычно требует моста.
Единичная экономика Rollups — еще одна область, на которую влияет «связность». Плата за транзакцию L2 состоит из двух частей: 1) стоимость публикации данных в L1 и 2) стоимость, которую пользователи платят за транзакцию. Сведение группирует данные вызовов транзакций, чтобы стоимость публикации могла быть разделена между пользователями: чем больше транзакций, тем ниже средняя стоимость на пользователя. Это также означает, что менее активные накопительные пакеты могут откладывать публикацию транзакций на L1 до тех пор, пока они не получат достаточно большой пакет транзакций. Следствием этого является более медленное время финализации и плохой пользовательский опыт. Общие заказы, по-видимому, все чаще служат слоями агрегации, где пакетные транзакции из нескольких небольших объединений могут помочь создать жизнеспособную юнит-экономику для длинных хвостов.
** Мы находимся в точке перегиба? **
Идея цепочек приложений и накопительных пакетов приложений не нова. Однако долгое время это было похоже на строящийся жилой район: строится много инфраструктуры, но нет жителей. В последние месяцы мы начали наблюдать приток первых жителей. Lattice создала OpCraft, автономный сетевой мир, поддерживаемый собственным накопительным пакетом; Lit Protocol и Synapse объявили о своем собственном накопительном пакете (хотя оба проекта больше ориентированы на инфраструктуру, чем на приложения); Zora запустила Zorachain. Недавние разговоры со зрелыми командами приложений (особенно с теми, кто рассматривает стратегии L2) начали исследовать, подходят ли им накопительные пакеты приложений.
Я предполагаю, что настоящий переломный момент наступит (как минимум) через 6-12 месяцев. Игровые и социальные приложения имеют наиболее очевидное соответствие рынку продуктов с накопительными пакетами для конкретных приложений: как социальные, так и игровые приложения в значительной степени зависят от индексации, вопросов упорядочения (особенно в игровом процессе) и пользовательских функций (например, транзакций без газа) для развлекательного потребления. важный. Многие команды приложений находятся в стадии создания, особенно игры, на разработку и выпуск которых могут уйти годы.
Еще один мой вывод: для менее финансовых приложений самое важное — привлечь внимание. До сих пор в этой статье накопительные пакеты приложений определялись как «одно приложение на накопительный пакет». Но этот взгляд может быть слишком узким. Возможно, есть несколько приложений, образующих коллектив, чтобы начать цепочку вместе. Точно так же мы можем видеть, как приложение создает свою собственную цепочку и поощряет развертывание других приложений поверх нее.
Наконец, я твердо верю, что в будущем мы увидим больше роллапов. Будет расти число проектов по созданию инфраструктурных сервисов для агрегированных приложений. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer и т. д. предоставляют группам приложений низкопороговые решения для запуска собственного накопительного пакета. Espresso, Astria и SUAVE от Flashbots были одними из первых исследователей в области секвенсоров. Затраты на запуск имеют тенденцию к снижению, и компромисс «подключения» становится менее важным. Но такое большое количество новых поставщиков инфраструктуры также означает, что командам приложений может потребоваться время, чтобы разобраться в различных вариантах, и между этими игроками разразится война. Опять же, хотя есть признаки принятия, я думаю, что переломный момент еще впереди.
Спасибо Devloper, Jill Gunter, Kyle Samani, Jason Maier, Cem Ozer и Viktor Bunin за их отзывы, комментарии и обсуждения, которые помогли разработать многие из этих идей.