Дилеммы и выходы из ситуации в играх Web3

Автор: Лола, Delphinus Lab

С учетом феноменального успеха “Миф о Черном Боге: Вуконг”, в отрасли снова появился голос, подрывающий популярность игр веб-3. В последнее время на уже очень унылом и самокритичном рыночном настроении добавился еще один уровень дебаффа.

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

Но реальность жесткая. Когда люди пытаются перечислить игры в первой линии Web3, они обнаруживают, что количество качественных игр крайне мало, и большинство игр не предлагают ничего особенного, не обеспечивают игрокам хороший пользовательский опыт и далеко от достижения ожидаемой массовой адопции. Многие команды игр с успешным опытом в Web2 потерпели неудачу в Web3, и, на мой взгляд, это главным образом связано с двумя основными причинами:

1. По сравнению с традиционными играми, игры Web3 затрудняют предоставление постоянного обновления игрового контента

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

Трудности обновления игрового контента

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

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

После обновления контракта невозможно продолжить использовать данные контракта до обновления для обновления логики игры, есть только два выбора:

1 Миграция

2. В начальном проектировании контракта разделяйте уровень данных и логический уровень

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

Нет логического обновления для интерфейса данных

Проведено логическое обновление интерфейса данных

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

Логическое обновление, работающее непосредственно в Виртуальная машина

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

В архитектуре App As A rollup, после аудита миграции данных, они могут быть выполнены в zkVM, что позволяет полностью проверить логику миграции. Поскольку миграция данных во многих сценариях представляет собой пересборку данных с небольшим количеством вычислительной логики, если код, затрагивающий каждый листовой Узел, составляет примерно 1000 строк, то примерно миллион листовых Узлов потребует выполнения TRACE примерно в 1000*100w. В настоящее время обычное время доказательства трассировки для каждого миллиона строк в zkVM составляет 9-15 секунд, поэтому общее время миграции данных в zk по-прежнему является управляемым числом.

Именно благодаря независимости данных Application Rookup появилась новая методология для итерации контента в веб-играх Web3.

Из-за сложности и неотложности обновлений других приложений на цепи игры полностью или верифицируемая, zkVM дает новые возможности.

Дилемма экономики и распределения выгод

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

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

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

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

Поскольку депозит в игре является ключевым шагом обратной связи в игре, негативное влияние Газа на задержку депозита серьезно вредит способности игры привлекать клиентов. Но поскольку цепочечные игры должны нести обязанность традиционного цепочечного обязательства, даже на layer2, Газ все равно безжалостно опережает первоначальный токен игры, связанный с депозитом. Поэтому в Web3 не существует подлинного игрового опыта «сначала играть, потом платить».

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

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

App As A rollup + zkVM: один из возможных путей

При перечислении этого ряда вызовов мы неожиданно обнаружили, что архитектура Application As Rollup может эффективно смягчить соответствующие проблемы.

Во-первых, реальный Газ в нашей собственной роллапе значительно снизится на целую цепочку игр до 1/20 или даже меньше. Это позволит команде проекта полностью избежать помех от платы за Газ в начальной стадии игры и предоставить настоящий игровой опыт free to play, создавая лучшую среду для привлечения игроков в начальной стадии.

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

В процессе обращения Application As a Rollup может эффективно выступать в роли моста для взаимодействия кросс-чейн игровых активов. Когда нам нужно переместить активы в разных блокчейнах, достаточно внести депозит в игру, а затем вывести на другой блокчейн. Эта встроенная функция кросс-чейн взаимодействия позволяет игре самой получать часть ценности от торговли игровыми производными.

Более радикальным является то, что игры могут предоставлять функцию депозита стейблкоинов для кредитования, что позволяет самим играм захватывать ценность TVL, которую раньше могли захватывать только цепочки. Наконец, Application Rollup может предоставлять механизм, похожий на газовую плату для игроков, которые платят за вещи в игре, что в конечном итоге захватывает традиционные газовые платы цепочек. Один из возможных дизайнов такого механизма заключается в том, что при высокой стоимости токена газовая плата будет ниже, а при низкой стоимости токена газовая плата будет выше: это смягчает колебания стоимости токена, связывая стоимость газа и токена через независимость layer3.

Конечно, все это не произойдет за одну ночь, Delphinus Lab zkWASM, как ранний игрок, который продвигает применение zkVM в играх, недавно выпустил zkWASM Mini Rollup. Это набор инструментов для быстрой разработки и развертывания приложений ZK Rollup. Он позволяет разработчикам писать код на Rust, компилировать его в WebAssembly и запускать в среде Node.js. Это SDK обрабатывает транзакции, генерирует Доказательство с нулевым разглашением и взаимодействует с блокчейном.

Его основной процесс состоит в следующем: получение транзакции, обработка транзакции в виртуальной машине WASM, генерация доказательства с использованием облачных служб zkWASM, а затем отправка доказательства для проверки и поселения в блокчейне. Весь этот процесс обеспечивает конфиденциальность и безопасность транзакций, а также значительно повышает масштабируемость блокчейна. Разработчикам достаточно следовать логике приложения, не вдаваясь в сложные детали технологии zk-SNARKs. Он также включает систему мониторинга Rollup, которая может использовать доказательства и данные транзакций для запуска поселения в блокчейне, используя хранилище Merkle root и verify API для проверки подтверждения, чтобы гарантировать поселение в соответствии с порядком Merkle root в блокчейне. Кроме того, этот SDK упрощает настройку локальной среды разработки: достаточно запустить MongoDB и Redis, запустить службу базы данных, а затем выполнить npm run server в каталоге ts, чтобы запустить полноценный локальный сервер.

Появление SDK Mini Rollup zkWASM предоставило потенциальное решение для двойного вызова, с которым сталкиваются веб-игры. С помощью архитектуры Application As A Rollup она не только упрощает процесс обновления игрового контента, но и открывает новые возможности для оптимизации игровой экономической модели.

Этот инновационный подход в первую очередь использует совместимость WASM, что позволяет множеству традиционных разработчиков использовать свои знания в языке программирования, таком как Rust, для написания кода игры. Во-вторых, это позволяет разработчикам игр более легко реализовывать повторное использование данных и логических обновлений, существенно уменьшая расходы на Газ, и даже возможно реализовать истинный опыт «играй сначала, плати потом». В то же время, это предоставляет больше возможностей для захвата ценности в игровых проектах, включая кросс-чейн взаимодействие, передачу активов, функции займа и т.д., что способствует созданию более устойчивой экономической системы игр.

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

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