Формирующаяся структура рынка AppChain
Из-за многих недостатков создания более изолированной экосистемы, AppChain лучше всего подходят для приложений, которые:
- Достигли определенное понятие масштаба (например, количество пользователей, объем доходов от протокола, TVL) и соответствие продукта рынку
- Имеют значительные преимущества для продукта/производительности благодаря выделенному блокчейн-пространству.
- Запрашивают меньше правил к безопасности и атомарности (например, P2E-игры, коллекции NFT, криптосоциальные сети).
Таким образом, вполне логично, что большинство приложений по-прежнему будут запускаться на L1 и L2 с общим блокчейном. Более того, поскольку ландшафт L2 все еще достаточно фрагментирован, мы видим, что команды, особенно протоколы DeFi, будут продолжать запускаться на L1 из-за их свойств безопасности, ликвидности и атомарности, последнее из которых особенно важно, поскольку флэш-кредиты обеспечивают фактически бесконечную эффективность капитала с нулевым балансовым риском.
Кроме того, не-DeFi приложения, скорее всего, будут запускаться на обобщенных L2 и перейдут на специфические для приложений L3 или L1, если они создадут достаточно большую экосистему и сетевые эффекты. Мы можем примерно представить себе этот порядок действий следующим образом:
Вполне логично, что большинство приложений, запускающих AppChain, выберут модульные уровни исполнения (в частности, ролл-апы), а не монолитные цепочки, поскольку у них нет капитала, необходимого для создания большого набора валидаторов. Более того, маловероятно, что высококачественные валидаторы решат направить свои ресурсы на AppChain, чей токен имеет низкую и нестабильную рыночную цену.
Тем не менее, по мере развития криптоиндустрии и принятия криптовалют все больше приложений будут запускать свои собственные AppChain, и будущая структура рынка AppChain будет иметь множество вариантов:
- монолитные блокчейны для конкретных приложений, соединенные различными мостами
- сайдчейны, подключаемые к монолитной цепи
- Роллапы для конкретных приложений, которые оседают на монолитной цепи
- Суверенные ролл-апы для конкретных приложений, не использующие расчетный уровень
Пространство проектирования AppChain
При выборе инфраструктуры AppChain необходимо учитывать несколько компромиссов при проектировании:
Тип безопасности: Насколько сложно атаковать сеть для изменения состояния сети?
- Совместное использование: Состояние сети защищено несколькими разнородными валидаторами, вероятно, управляемыми разными сторонами (например, Polkadot parachains, Skale).
- Изолированное: Безопасность обеспечивается самим приложением; вероятно, используются принадлежащие приложению валидаторы или секвенсоры, а для экономической ставки используется токен приложения (например, цепи Cosmos, Axie Ronin).
- Унаследованное: Безопасность, обеспечиваемая базовым слоем расчета/консенсуса (например, zkSync, Optimism).
Источник безопасности: Откуда берется безопасность и где происходит расчет?
- Ethereum: Использует Ethereum в качестве расчетного уровня для доказательств мошенничества, доказательств достоверности и общей защиты от двойных трат (например, Arbitrum, zkSync).
- Non-Ethereum L1: Использует не-Ethereum безопасность имеет другую модель консенсуса (например, NEAR Aurora, Tezos rollups).
- Токен приложения: Токен приложения используется в качестве крипто экономической безопасности (например, подсети Avalanche, цепочки Cosmos).
Выдача разрешений: Как выбираются узлы и кто может читать/писать состояние?
- Безразрешительная: Любой может читать/писать контракты и проверять переходы состояния (например, Optimism, StarkNet).
- Разрешенный по выбору: Только валидаторы/разработчики, внесенные в белый список, могут читать/писать/валидировать цепочку (например, Polygon Supernets, Avalanche Subnets).
Совместимость: насколько легко и безопасно ликвидность и состояние могут перемещаться между другими приложениями в рамках одной экосистемы.
- Полная: Перемещение в любое приложение с минимальной задержкой и максимальной безопасностью (например, Polkadot XCMP, Cosmos IBC).
- Ограниченная: Имеет ограничения по подключению, задержке и/или
Завершенность: Когда транзакции считаются окончательными? (Предполагается, что вероятностный финал считается окончательным)
- Мгновенная: Обычно при использовании механизмов консенсуса BFT (например, NEAR Aurora, Evmos).
- Эвентуальная: Обычно при роллапах, когда транзакция может считаться окончательной после публикации блока в L1 (и при условии, что данные доступны) (например, Arbitrum, zkSync).
Газовая валюта: В каком токене пользователи платят за транзакции?
- Токен приложения: Обычно сам токен приложения работает на специфическом для приложения L1 или L2 (например, Avalanche Subnets, Osmosis)
- Никто: Валидаторы L1 или L2 или приложение субсидируют аппаратные затраты пользователей. (например, AltLayer, Skale).
- Требуемая ставка: Размер ставки, необходимый приложениям для того, чтобы валидаторы обеспечивали безопасность их цепочки.
- Транзакции в секунду (TPS): субъективная мера пропускной способности, поскольку транзакции могут быть разного размера (т.е. более крупные транзакции приведут к более низкому TPS и наоборот).
- Поддержка EVM: Возможность поддержки опкодов Solidity и EVM без необходимости внесения изменений в кодовую базу разработчиков.
Заключение
Несмотря на существующие проблемы с AppChain, спрос со стороны разработчиков указывает на их постоянный рост. Как продемонстрировала компания Apple, вертикальная интеграция часто приводит к улучшению UX; точно так же разработчики блокчейна будут стремиться к созданию полностью оптимизированных веб-3-приложений, что и позволяют AppChains. Тем не менее, AppChains подходят не всем, и разработчикам следует тщательно продумать потребности своего приложения и компромиссы, прежде чем выделять ресурсы на его запуск.
Существует множество последствий для экономики модели безопасности, стратегий монетизации, защиты платформы, накопления общей стоимости в рамках стека и эффектов второго порядка на структуру криптовалютного рынка, которые будет интересно наблюдать в течение следующих нескольких лет.