App rollups становятся явным победителем в масштабировании определенного набора приложений Ethereum. Эти приложения выигрывают от отсутствия разрешений и сильных гарантий владения, но не требуют одновременного взаимодействия между всеми пользователями приложения. Полностью цепочечные игры (FOG) - лучший пример, который подходит под это описание. Преимущества FOG заключаются в сильной собственности на внутриигровые активы, свободном участии в игре и свободном моддинге. Тем не менее, в большинстве игр не требуется, чтобы все игроки взаимодействовали друг с другом в один и тот же момент. Другие приложения, которые могут извлечь выгоду из стратегий масштабирования app rollup, включают в себя NFT-рынки, вечные биржи и AI-интерпретацию на цепочке.

Свертывание приложений уже является основным способом реализации многих из этих вариантов использования. Однако стандартные реализации сворачивания, т.е. сворачивания EVM, все еще имеют важные ограничения по масштабируемости. Вероятно, они могут достичь пропускной способности около 100 транзакций в секунду. Такая пропускная способность может быть достаточной для некоторых игр на цепочке, в зависимости от типа игры. Однако большинству игр требуется гораздо более высокая пропускная способность для поддержки большого количества (> 1000) одновременно играющих игроков. Эта статья посвящена подходам к масштабированию app-роликов до сотен тысяч одновременных участников. Для каждого подхода я обсуждаю подходящий тип приложений/игр и стоящие перед ним задачи.

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

Горизонтальное масштабирование

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

Горизонтальная масштабируемость означает простое развертывание нескольких приложений-роллапов (OP или ZK) с одним и тем же смарт-контрактом, развернутым на всех роллапах. Передняя панель приложения легко направляет пользователя к одному из рулонов в зависимости от емкости, местоположения или специфических опций приложения. Компания Alt Layer недавно продемонстрировала эту концепцию, запустив масштабируемый 2048 FOCG. Во фронтэнде игры у пользователя есть возможность выбрать, к какому роллапу присоединиться, исходя из своего географического положения. Благодаря простоте и доступности поставщиков услуг Rollup-as-a-service, таких как Caldera, которые выполняют всю инфраструктурную работу, связанную с вращением и управлением этими роллапами, этот подход может быть легко принят разработчиками игр.

Несмотря на простоту, в подходе к масштабированию с использованием нескольких рулонов есть несколько проблем. Первый - это рулонная коммутация сети. Нынешние кошельки, например, Metamask, требуют ручного одобрения для подключения к новой сети, т.е. экземпляру rollup. Это приводит к сложному и запутанному пользовательскому опыту для игроков, которым приходится вручную подключаться к нескольким "сетям", чтобы сыграть в одну и ту же игру. К счастью, можно абстрагироваться от этой сложности с помощью решений AA. Например, EIP 4337, а также встроенные кошельки, такие как Privy и 0xPass.

Еще одной проблемой является управление состоянием игроков во время перехода от одного свертка к другому. В некоторых случаях, например, при снижении производительности, приложению может потребоваться объединить несколько экземпляров сворачивания в один экземпляр, чтобы сэкономить ресурсы. В этом случае все состояние активного игрока должно быть перенесено в новый экземпляр. Современные решения для создания мостов, в частности, мосты zk, могут сыграть решающую роль в решении этой проблемы. Используя эти решения, можно перенести состояние игры игрока на новый экземпляр рулона, сохранив при этом доказательство достоверности этого состояния. Однако задержка существующих мостовых решений может быть менее оптимальной для игровых приложений.

Каналы состояния ZK

Другой подход к масштабированию app rollup, который больше подходит для многопользовательских игр, например, покера, - это zk state channels. В этих играх взаимодействие игроков происходит между небольшим количеством игроков, например, 2-10. Игра между этими игроками важна только в процессе игры. Конечный результат игры, однако, более важен, поскольку он влияет на баланс активов каждого игрока. Следовательно, важно хранить результат в общем постоянном слое.

В этом случае app rollup представляет собой общий информационный слой, где хранятся результаты игр и где находятся игровые активы. Для каждой игры в рулетке может быть инициирован канал ZK State Channel для обслуживания этой игры. Во время игры каждый игрок генерирует транзакции и создает ZKP, доказывающий, что он следовал правилам игры. Доказательства, полученные в результате взаимодействия других игроков, объединяют предыдущие доказательства, используя рекурсивное доказательство. Когда игра заканчивается, итоговый ZKP передается в приложение, чтобы доказать достоверность игрового процесса и правильность конечного результата. Результирующее изменение состояния в игре изменяет состояние игрока на экране приложения.

Каналы состояния ZK перемещают игровые взаимодействия вне цепи. Таким образом, внутриигровые действия и транзакции не учитываются при подсчете пропускной способности приложения. Используя этот подход, приложения можно масштабировать, чтобы поддерживать десятки или сотни тысяч одновременных игроков. Транзакции по сворачиванию приложений будут состоять только из проверки сгенерированных ZKP и транзакций по обновлению состояния, что приведет к увеличению коэффициента масштабирования в 100-1000 раз. Несколько команд, включая Ontropy, сосредоточились на разработке этой технологии.

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

Модификация данного подхода, которая может облегчить эту проблему, заключается в назначении одного из участников канала состояния zk в качестве временного секвенсора. Этот секвенсор будет получать транзакции каждого игрока, генерировать соответствующие ZKP и делиться ZKP со всеми участниками канала. Эту модификацию можно представить как эфемерные ZK L3, которые оседают в app rollup. Команда Cartridge реализовала эту архитектуру, разработав специализированный секвенсор под названием Katana.

Подход с использованием канала состояния zk имеет большой потенциал. Однако остается несколько открытых вопросов, связанных со средой выполнения внутри канала состояния zk и с тем, как оптимизировать ее для рекурсии доказательств. Существующие среды zkEVM не очень эффективны, и большинство из них в настоящее время не поддерживают рекурсию доказательств. Альтернативы включают в себя легкие zkVM или даже использование специализированных zk-схем для взаимодействия с игроком, если количество возможных действий игрока ограничено.

Изменение среды выполнения

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

Главное преимущество этого подхода заключается в том, что для повышения пропускной способности сворачивания не нужно жертвовать композитностью или ограничивать количество вариантов использования. Этот подход может подойти для любого приложения Web 3 при условии, что среда выполнения может обеспечить требуемую приложением пропускную способность. Это делает их единственным жизнеспособным решением для приложений, требующих доступа к общему состоянию, таких как AMM, протоколы кредитования и другие приложения DeFi.

Расширение функциональности EVM с помощью прекомпиляций

Первый подход заключается в том, чтобы свертывание оставалось совместимым с EVM и устраняло некоторые ограничения производительности с помощью прекомпиляции. Идея здесь проста. Прекомпиляция - это просто перемещение вычислительно затратных операций EVM вниз, на уровень узла. Операция, для которой потребовались бы сотни или тысячи EVM OP и расход газа в 100 тысяч с лишним раз, может быть упрощена до одной операции со 100-кратным снижением затрат на газ. Расширение среды сворачивания с помощью прекомпиляций часто называют EVM+. Примерами такого подхода являются поддержка конфиденциальности на цепи и поддержка более эффективных схем подписи, например, подписи BLS. Например, в покерной игре zkHoldem используются специализированные операции FHE и zk, чтобы добиться приватной раздачи и раскрытия покерных карт. Разработка этих специализированных прекомпиляций часто является совместной работой разработчика пакета приложений и провайдеров Raas, которые управляют развертыванием и обслуживанием инфраструктуры пакета приложений.

Использование среды выполнения, отличной от EVM

Другой подход к улучшению среды выполнения рулонов - это отказ от EVM. Этот подход становится все более популярным среди разработчиков-новичков в экосистеме Ethereum и разработчиков, которые считают, что Solidity - не лучший язык для разработки сложных приложений.

Сегодня у нас есть приложения, работающие на WASM, SVM, Cairo и даже на Linux. Большинство из этих подходов позволяют разработчикам писать свои смарт-контракты на языках высокого уровня, таких как Rust или C. Недостатком является то, что часто теряется совместимость с существующими контрактами Solidity. Тем не менее, создать совместимость с EVM все еще возможно. Например, стилус Aributrum использует сопроцессор, чтобы сделать контракты Stylus совместимыми с EVM. Такая конструкция приближает Stylus к архитектуре EVM+, а не к архитектуре не-EVM.

Гибридные среды выполнения

Третий подход, который особенно популярен в FOG, - это объединение лучших характеристик двух предыдущих подходов. Этот подход сочетает в себе совместимость с EVM и специализированную среду выполнения без EVM. Среды, не относящиеся к EVM, сосредоточены на высокопроизводительном выполнении основных игровых примитивов. Управление внутриигровыми активами, например, торговля внутриигровыми NFT, может осуществляться с помощью стандартных контрактов Solidity.

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

Примерами такого подхода являются World Engine от Argus и Keystone от Curio. Движок World Engine отделяет выполнение игровой логики в отдельный слой под названием Game Shard, который работает поверх слоя, совместимого с EVM. Конструкция Game Shard также предусматривает возможность горизонтального масштабирования, чтобы регулировать общую пропускную способность рулона в зависимости от спроса. Аналогично, архитектура Keystone компании Curio объединяет высокопроизводительный игровой движок с EVM в качестве среды выполнения свертывания. Задача здесь состоит в том, чтобы добиться бесшовной совместимости между движком EVM и движком игры.

Вопросы доступности данных

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

Одно приложение может потенциально достигать пропускной способности, превышающей 10 000 tps. Использование Ethereum в качестве уровня DA для этих транзакций невозможно. Во-первых, средняя стоимость публикации данных простого перевода L2 ETH на L1 может превышать $0,10. Эти затраты слишком высоки для большинства приложений. Что еще более важно, L1 Ethereum в настоящее время не может поддерживать более 8k TPS [1] для ролловеров, которые используют L1 для DA.

Развертывание приложений будет в основном зависеть от внешних DA-решений. Celestia и EigenDA в настоящее время позиционируются как наиболее жизнеспособные варианты для сворачивания приложений. Например, компания Eclipse планирует использовать Celestia для высокопроизводительного свертывания на основе SVM. Argus и высокопроизводительные игровые движки также планируют изначально использовать Celestia. Аналогичным образом, EigenDA, который обещает пропускную способность до 10 МБ/с, может стать эффективным решением для множества приложений.

Однако интеграция Celestia или EigneDA имеет главный недостаток - утечку экономической стоимости. Приложение должно оплачивать сборы за уровень DA в дополнение к сборам за расчеты на Ethereum L1. Плата за расчеты очень важна для сворачивания приложений, так как она выравнивает безопасность сворачивания с безопасностью Ethereum. Гарантии DA менее важны, особенно в контексте FOG, где стоимость сделок гораздо меньше. Более того, Celestia и EigenDA обещают низкую плату, поскольку эти сети являются новыми и на начальном этапе будут использоваться слабо. Когда эти сети DA достигают высокого уровня использования, плата за DA также может стать чрезмерной. По моему мнению, вместо этого в сворачивании приложений следует использовать простой Комитет по доступности данных (DAC) для подтверждения доступности данных сворачивания[3] .

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

Я хотел бы поблагодарить Мэтта Катца, Кевина Чжана, Тарренса ван Аса и Ларри Лю за их ценные замечания по этой статье.

[1] Предполагается, что 50% лимита блокчейна Ethereum будет использоваться только для хранения данных с помощью calldata, средний размер tx - 10 байт. 12-секундное время блокировки

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

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