Критерий сравнения: где хранится state и где исполняются правила
«On-chain games vs Web2 games» — сравнение архитектуры on-chain игр и Web2 игр: где исполняются правила и где хранится игровой state (прогресс, инвентарь, параметры персонажа).
Ключевое различие «игры с NFT» и fully on-chain — в том, что в одном случае токен может быть on-chain, а прогресс и правила остаются на сервере.
- Web2 → предметы и прогресс — записи в базе разработчика; доступ определяется аккаунтом и правилами сервиса.
- On-chain → часть логики и/или состояния фиксируется в блокчейне; активы могут быть NFT, а действия — транзакциями.
- Web3-гибрид → NFT может храниться в кошельке, но геймплей и прогресс обычно обновляются на сервере.
- Fully on-chain → правила и state находятся в смарт-контрактах; клиентские приложения могут меняться, а правила исполнения и контрактный state (события и записи контракта) остаются в сети.
Ключевой вывод: при отключении серверов Web2 доступ и прогресс обычно прекращаются. В Web3-гибриде NFT часто сохраняется в кошельке, но игровая утилити исчезает, если правила использования и прогресс были серверными.
«Источник истины» — слой, который хранит права на актив и итоговый state: сервер/БД студии или смарт-контракт и данные сети.
Актуализация: уточнены определения Web3-гибрида и fully on-chain, добавлены критерии проверки «источника истины» и последствия сценария «server off».
Вывод в 4 пункта: Web2, гибрид и fully on-chain
Критерии сравнения: где хранится прогресс (state) и кто валидирует правила (сервер или смарт-контракт).
- Важно не наличие NFT, а место хранения прогресса и слой исполнения правил.
- Web2 → сервер — единственный источник истины и единственная точка отказа.
- Web3-гибрид → токен может сохраниться в кошельке, но правила использования часто задаёт сервер.
- Fully on-chain → правила и state в контрактах, клиент — интерфейс к данным сети.
Сравнение моделей: активы, прогресс, зависимость от сервера
Сравнение по слоям: источник истины, активы, прогресс, зависимость от серверов и последствия отключения сервиса.
| Параметр | Web2 | Web3-гибрид (частично on-chain) |
Fully on-chain |
|---|---|---|---|
| Источник истины | Сервер/БД студии | Сервер + блокчейн для части прав/активов | Смарт-контракты и данные сети |
| Активы | Внутриигровая запись | NFT/токены в кошельке; утилити часто определяется сервером | NFT/токены + правила использования в контракте |
| Прогресс (state) | Серверный | Обычно серверный | On-chain (контрактный state) |
| «Сервер выключили» | Доступ и прогресс обычно прекращаются | NFT может сохраниться, но режимы/правила/прогресс могут исчезнуть | Правила и state сохраняются в сети, интерфейс может смениться |
| UX/скорость | Максимальные | Средние (кошелёк, подписи) | Компромисс (комиссии, латентность, инфраструктура доступа) |
| Главные риски | Централизация: студия может менять правила и доступ | Токен существует, но утилити зависит от серверов | Безопасность контрактов + масштабирование и UX |
Термины для чтения: NFT, on-chain/off-chain, смарт-контракт, state
Минимальный набор понятий для сравнения: что является активом, где хранится state и где исполняются правила.
- NFT — уникальный токен в блокчейне, подтверждающий владение цифровым объектом (например, предметом).
- Смарт-контракт — код в блокчейне, который исполняет правила и хранит/обновляет данные.
- On-chain — действие или данные фиксируются в сети блокчейна.
- Off-chain — действие или данные хранятся вне блокчейна (сервер, клиент, закрытая БД).
- Fully on-chain — логика и состояние игры находятся в блокчейне; клиент — интерфейс к данным и правилам контракта.
- Источник истины — слой, который определяет итоговое состояние: кто владеет активом, какой уровень, какой инвентарь.
Границы моделей: Web2-игра, Web3-гибрид, fully on-chain
Разделение по критерию исполнения: «токенизированные активы» и «правила и state в контрактах» — разные модели.
Web2-игры: состояние (прогресс, инвентарь, параметры персонажа) хранится и обновляется на централизованных серверах.
On-chain игры: действия и/или состояние фиксируются в блокчейне и исполняются правилами смарт-контрактов.
Web3-гибрид: активы токенизируются (NFT/токены), но существенная часть логики и прогресса остаётся off-chain.
Fully on-chain: блокчейн используется как слой исполнения: логика и state размещены в контрактах, интерфейсы могут быть разными.
Ключевой тезис: наличие NFT не гарантирует сохранность утилити. Утилити сохраняется только если правила использования и/или критический state закреплены в контрактах, либо существует совместимый клиент, который читает контрактный state и исполняет те же правила.
Права на активы: «в базе» против «в кошельке»
Владение токеном и наличие игровой утилити — разные состояния, потому что их определяют разные слои.
Web2: актив как запись в системе разработчика
Предмет существует как строка в базе, а доступ — как право аккаунта использовать функции сервиса.
- Аккаунт и правила платформы определяют, какие предметы и режимы доступны.
- Блокировка аккаунта или закрытие сервиса обычно прекращают доступ к предметам и прогрессу.
- Передача и торговля чаще ограничены правилами продукта и инфраструктурой студии.
Следствие: актив остаётся записью в базе, а не независимым объектом вне сервиса.
Web3: актив как токен (NFT/токен) на адресе кошелька
Владелец контролирует токен ключами, но утилити определяется тем, где исполняются правила использования токена.
- Токен может сохраниться независимо от аккаунта игры, потому что запись находится в сети.
- Если правила использования токена задаёт сервер, студия может отключить утилити, не затрагивая сам токен.
- После закрытия сервиса цена токена может упасть, если нет совместимых клиентов или on-chain правил использования.
Следствие: токен может оставаться на адресе, но «игровая полезность» исчезает при отключении серверных правил и прогресса.
Разграничение: «NFT в кошельке» означает владение токеном. «Токен даёт игровые права» зависит от слоя, где описаны и исполняются правила использования.
Ключевая мысль: NFT может сохраниться, даже если утилити перестала обслуживаться сервером.
Прогресс и проверки: серверный state vs контрактный state
Ключевой вопрос: где обновляется state и какой слой подтверждает переходы состояния — сервер или смарт-контракт.
Серверный state: прогресс хранится в базе сервиса, «официальную версию» задаёт сервер.
Контрактный state: прогресс фиксируется в данных смарт-контракта и событиях сети, переходы проверяются логикой контракта.
| Что сравнивается | Серверный state | Контрактный state |
|---|---|---|
| Где хранится прогресс | База данных сервиса | Данные контракта + события сети |
| Кто подтверждает переходы | Серверная логика и правила сервиса | Логика смарт-контракта (что разрешено и что запрещено) |
| Кто задаёт итоговую версию | Сервер как единственный арбитр | Сеть и контракт как источник истины |
| Админ-изменения | Возможны (например, откат выдачи награды) | Ограничены правилами контракта и транзакциями |
| Как подтверждается результат | По данным сервиса и аккаунта | По данным сети (state контракта и события) |
| Если сервис отключён | Прогресс и «официальная версия» могут исчезнуть вместе с БД | State и события остаются в сети, интерфейс может смениться |
Пример: если итог сезона (рейтинг и награда) записан on-chain, его можно подтвердить по данным сети даже при смене клиента; если итог сезона хранится на сервере, «официальная версия» исчезает при отключении сервиса.
Компромисс: on-chain права и on-chain итоги, off-chain геймплей
- On-chain: владение, редкие награды и итоги сезонов (то, что нужно подтверждать независимо от сервера).
- Off-chain: высокочастотные действия (бой, перемещения, матчмейкинг) ради скорости и UX.
- Следствие: on-chain закрепляет редкие, но значимые события, а не каждое действие геймплея.
Чем больше прав и итоговых результатов записано в контрактах, тем меньше зависимость от серверов для подтверждения владения и сезонных результатов.
Сценарий отключения сервиса: что теряется в каждой модели
Отключение серверов влияет на активы и прогресс по-разному, потому что в разных моделях отличается источник истины.
Web2: отключение инфраструктуры прекращает обновление серверного state и выдачу данных аккаунту.
Следствие: доступ к прогрессу и предметам обычно прекращается вместе с сервисом.
Web3-гибрид: NFT остаётся на адресе как запись в сети, но серверные элементы (прогресс, режимы, правила использования) могут исчезнуть.
Следствие: токен существует, но утилити прекращается при отключении серверов.
Fully on-chain: логика и state находятся в контрактах, поэтому данные остаются в сети независимо от одной компании.
Ограничение: удобный доступ зависит от клиентских приложений и инфраструктуры чтения данных (RPC и индексаторы).
Ограничения on-chain: комиссии, задержки, UX и риск контрактов
On-chain повышает проверяемость, но добавляет комиссии, задержки и требования к управлению ключами.
- Пропускная способность и задержки: запись действий требует транзакций и подтверждений.
- Стоимость операций: хранение и обновление state on-chain может быть дорогим.
- UX-барьеры: кошелёк, ключи, подписи и восстановление доступа — отдельный слой рисков.
- Инфраструктура доступа: RPC, индексаторы и интерфейсы влияют на удобство и доступность чтения state.
- Безопасность контрактов: ошибки кода и неверные разрешения приводят к необратимым последствиям для state и активов.
Следствие для геймдизайна: частые микродействия редко переносятся on-chain; чаще on-chain фиксирует редкие, но значимые события (права, награды, итоги сезонов).
Причина популярности гибрида: блокчейн используется для прав и экономических событий, а высокочастотный геймплей оставляют off-chain, чтобы избежать комиссий и задержек на каждом действии.
Ключевой компромисс: on-chain проверяемость оплачивается комиссией и трением в UX.
Критерии выбора: когда on-chain даёт ценность, когда нет
Фильтр по архитектуре: где важны права на активы и проверяемые итоги, а где важнее скорость и бесшовный UX.
On-chain чаще оправдан
Когда ценность привязана к владению активом, происхождению и вторичному рынку.
- Коллекционные предметы и карты, где важен вторичный рынок.
- Экономики ресурсов и крафт с правилами, проверяемыми по событиям сети.
- Долгоживущие миры, где критично сохранить права на активы и итоги сезонов.
Web2 чаще рациональнее
Когда важнее скорость, минимальное трение и отсутствие комиссий на каждом действии.
- Real-time жанры (шутеры, экшен), где критична задержка.
- Казуальные игры с массовым онбордингом без кошельков и подписей.
- Проекты, где предметы не имеют ценности вне сервиса.
Примеры (ориентиры по подходам)
Это не рекомендация и не оценка качества. Цель раздела — показать, как рынок обычно называет разные архитектуры.
Проверка по критериям: (1) прогресс хранится в аккаунте или в контракте? (2) существует ли альтернативный клиент/просмотр state без официального сайта? (3) утилити NFT определяется контрактом или серверными правилами?
- Токенизированные активы (часто гибрид) → предметы и персонажи как NFT, а геймплей и прогресс — off-chain.
- Экономические и коллекционные форматы → чаще закрепляют on-chain права на активы и правила рынка вокруг активов.
- Fully on-chain направления → пытаются держать правила и state в контрактах, а клиент — как интерфейс к данным сети.
Критерий проверки: важнее место хранения прогресса и слой исполнения правил, чем наличие NFT.
Три частые ошибки восприятия
Ошибки ожиданий обычно связаны с тем, что «владение токеном» смешивается с «работающей утилити» и «источником истины».
«Есть NFT — значит игру нельзя закрыть»
Токен может существовать в сети, а серверный геймплей и серверный прогресс могут исчезнуть.
- Владение токеном не создаёт обязательство сервиса поддерживать игровые правила.
- Риск определяется местом хранения прогресса и местом исполнения правил использования токена.
Следствие: проверка должна начинаться с прогресса и правил, а не с наличия NFT.
«On-chain = полностью децентрализовано»
On-chain может использоваться точечно: для активов, но не для прогресса и правил матча.
- On-chain активы не означают on-chain прогресс.
- Гибридная модель может сохранять критические зависимости от серверов.
Следствие: «источник истины» для прогресса и правил нужно искать в сервере или в контракте.
«Fully on-chain не имеет ограничений»
Контрактный state остаётся в сети, но комиссии, задержки и доступ через инфраструктуру чтения влияют на UX.
- Комиссии и подтверждения ограничивают частоту on-chain действий.
- Доступность клиентов, RPC и индексаторов влияет на удобство чтения state.
Следствие: важно оценивать число on-chain действий и доступность просмотра state без одного фронтенда.
FAQ
Что такое on-chain gaming?
В чём разница Web2 и Web3 игр простыми словами?
Что будет с NFT, если игра закроется?
Можно ли играть в Web3-игры без кошелька?
Можно ли сохранить прогресс без серверов?
Почему fully on-chain игр пока мало?
Итоговая проверка: on-chain vs Web2 по трём признакам
Оценка модели сводится к одному вопросу: где находится «источник истины» для прогресса и правил.
- Прогресс: итог сезона и ключевые награды записываются в контракт или остаются в базе сервиса.
- Правила: переходы state подтверждаются смарт-контрактом или серверной логикой.
- Риск отключения: при исчезновении сервиса сохраняются только данные сети и совместимый доступ к ним.
Если прогресс и правила живут на сервере, on-chain-элементы остаются активами, но не сохраняют «официальную версию» игры.