З моменту появи Axie та StepN у попередньому циклі, GameFi та ігри на блокчейні завжди були одними з найгарячіших тем у блокчейн-індустрії. Ця нова ігрова модель, заснована на блокчейн-технології, принесла унікальні враження, яких традиційні ігрові платформи ніколи не досягали в аспектах володіння активами гравців, передачі вартості, внутрішньоігрових економічних систем, прозорості правил та управління спільнотою. Хоча ці перспективи звучать багатообіцяюче, вони стикаються з постійною проблемою:
Блокчейн-ігри зазвичай не мають достатньої ігрової привабливості та цікавості, більше тяжіючи до фінансових спекуляцій, що призводить до швидкого зниження кількості користувачів після того, як спекулятивні вигоди зникають.
Це явно протилежне моделі розвитку традиційних ігор. Плавний розвиток традиційних ігор зазвичай ґрунтується на привабливості ігрової механіки, що дозволяє залучати велику кількість користувачів. У той же час розробники ігор можуть створювати прибутковий шлях і розширювати серію супутніх продуктів та інтелектуальної власності завдяки своїй популярності. Можна сказати, що ті традиційні ігри, які успішно працюють, мають позитивну циклічну систему, де гравці отримують задоволення від гри, а також іноді отримують економічну вигоду як у грі, так і поза нею.
У порівнянні з ними, поточні блокчейн-ігри більше покладаються на прості показники повернення для залучення гравців. Крім слабкої ігрової привабливості, Web3-ігри також стикаються з давно відомими проблемами, такими як високий поріг входу для користувачів та складні процеси взаємодії.
Яка ж корінна причина всіх цих проблем? У різних людей можуть бути різні точки зору.
Команда Tabi Chain вважає, що одним із важливих факторів, який впливає на Web3-ігри, є те, що відмінні розробники традиційних ігор через проблеми з технологіями та високі витрати на навчання стикаються з труднощами входу в екосистему Web3. Для тих, хто не знайомий з розробкою ігор або програмного забезпечення, перехід від Web2 до Web3 здається лише зміною наративу та середовища, але насправді все значно складніше.
Тож як можна створити більш дружнє середовище для традиційних розробників ігор або суміжних виробників за допомогою технологій? У тексті нижче ми всебічно проаналізуємо проблеми, з якими стикаються Web3-ігри, та відповідні рішення з різних аспектів, пояснюючи, як індустрія Web3-ігор у майбутньому зможе краще адаптуватися для традиційних розробників ігор.
Бар'єри для традиційних розробників ігор при вході в екосистему Web3 через технічні причини
У попередньому тексті ми коротко згадали, що недружність до користувачів і високі витрати на навчання є основними факторами, які заважають традиційним розробникам ігор увійти в екосистему Web3. Так звана недружність та високі витрати на навчання можна деталізувати так:
Відмінності між Web3-додатками та традиційними програмними структурами
Блокчейн та його додатки (dApps) принципово відрізняються від традиційних програмних архітектур, вимагаючи від розробників володіння новою системою знань, такою як принципи роботи блокчейнів, протоколи консенсусу, моделі програмування смарт-контрактів тощо. Традиційним розробникам ігор потрібно витрачати багато часу на вивчення Solidity або інших мов програмування для смарт-контрактів та розуміння роботи EVM.
Більше того, традиційна ігрова логіка зазвичай виконується на централізованих серверах, які можуть гнучко обробляти складні ігрові стани та високочастотні взаємодії. Запуск ігрової логіки на блокчейні потребує значного спрощення або реструктуризації, оскільки кожна операція повинна бути передана в розподілену мережу і далі на блокчейн, що обмежується продуктивністю блокчейну та витратами.
Обмеження у проєктуванні смарт-контрактів
Хоча Віртуальна машина Ethereum (EVM) є повною по Тьюрингу і теоретично здатна виразити будь-яку логіку, її характеристики дуже несприятливі для розробки ігор. Наприклад:
Відсутність таймерів. Усі операції на блокчейні Ethereum повинні вручну запускатися зовнішнім обліковим записом (EOA). Щоб досягти ефекту, подібного до таймерів, розробникам необхідно розгорнути додаткову службу, підтримувати EOA та список подій, щоб вручну запускати завдання за розкладом. Через затримку у додаванні транзакцій у блокчейн ці завдання не гарантують своєчасного виконання.
Відсутність механізмів зворотного виклику, підтримки багатопоточності та асинхронних операцій. Оскільки Solidity призначена для розробки смарт-контрактів Ethereum, її середовище виконання значно відрізняється від традиційних середовищ виконання. Операції в EVM є транзакційними, і кожен виклик функції повинен бути повністю виконаний в одній транзакції без традиційного поняття "асинхронності". Це означає, що з початку до кінця виклику функції в Solidity процес є атомарним і не може бути перерваний іншими транзакціями.
Відсутність можливості посилання на зовнішні дані. Хоча існують оракули, такі як Chainlink, з точки зору інтеграції або виклику даних їхня зручність використання значно відрізняється від прямих HTTPS-запитів для отримання даних. Це також додає додаткові навантаження на інтеграцію та залежності для розробників.
Обмеження масштабованості та продуктивності. Логіка гри повинна бути спрощена або розділена на кілька простих транзакцій, щоб уникнути високих витрат на газ для однієї транзакції або перевищення максимального ліміту, що обмежує реалізацію складних взаємодій і функціональних можливостей.
Обмеження зберігання даних і викликів
Дороге та обмежене за дизайном місце зберігання смарт-контрактів, що робить його непридатним для зберігання великої кількості ігрових даних.
Необхідність використання логів подій для непрямого відстеження стану гри, але отримання цих подій може бути нестабільним. Питання, як-от коли оновлювати стан гри, часто потребують ручного запуску гравцями або операторами гри.
Структура даних облікового запису, прийнята в EVM, призводить до слабких можливостей індексації даних. При запиті даних облікового запису можна дізнатися лише про його баланс ETH або нативного токена, але не про те, якими активами ERC-20 він володіє або баланс кожного активу. Те ж саме стосується NFT. Ця інформація інкапсульована в контракті, специфічному для кожного активу, а не зберігається у власному обліковому записі користувача.
Інструменти, такі як Etherscan, дозволяють бачити, якими токенами володіє певна адреса та їхні баланси, і все це індексується периферійними інструментами, такими як блокчейн-експлорери. Ці інструменти повинні створювати свої величезні бази даних, повністю сканувати всі блокові дані або слухати події на блокчейні, щоб агрегувати всі дані.
Web3-розробники зазвичай інтегрують сторонніх постачальників даних, таких як Etherscan, NFTscan, The Graph, і навіть можуть бути змушені платити за ключі API. Більше того, ці сторонні сервіси за своєю суттю є офчейн-базами даних і можуть зазнавати затримок, помилок.
Порівнявши формати баз даних більшості ігор із методами зберігання даних у блокчейні, відмінності між ними стають очевидними. Структура даних більшості ігор повністю кастомізована, має хорошу здатність до вираження та індексації і не потребує залежності від сторонніх сервісів.
Складнощі інтеграції з існуючими ігровими активами
Існуючі ігрові активи (такі як предмети та персонажі) зазвичай не створюються і не керуються на блокчейні. Перенесення цих активів на блокчейн часто включає перетворення універсальних, але специфічних даних у стандартні NFT або токени. Цей процес вимагає складної міграції та інтеграції, що може вплинути на існуючу економічну систему гри.
Оновлення, патчі та відновлення після аварій
В Ethereum після розгортання смарт-контракту його код стає незмінним, що ускладнює процес оновлення та виправлення помилок порівняно з традиційним програмним забезпеченням. Розробники часто використовують проксі-контракти або шаблони версій для обходу цього обмеження, що збільшує загальну складність структури. Використання проксі-контрактів вимагає особливої обережності, щоб уникнути конфліктів слотів зберігання, які можуть призвести до пошкодження даних. Крім того, існує серйозний ризик витоку прав управління.
Оновлення коду у традиційних іграх не є настільки складним з технічної точки зору, єдине можливе обмеження — централізовані дозволи на оновлення. Це можна контролювати методами, такими як DAO, замість залежності від смарт-контрактів.
Крім того, традиційні ігри часто виконують створення знімків або резервних копій баз даних. Хоча це може не здаватися критичним у звичайних умовах, це стає життєво важливим, коли оновлення вносить серйозну помилку, дозволяючи швидко відкотити дані — що практично неможливо зробити на блокчейні. Навіть якщо спробувати відкотити частину ігрових даних через відбудову контракту, міграція даних і станів зі старого контракту на новий залишається дуже складним завданням.
Фрагментація екосистеми та проблеми з користувацьким досвідом
Різні публічні ланцюги та віртуальні машини (VM) мають абсолютно різні мови програмування смарт-контрактів, архітектури та структури даних. У Web2 розробники ігор можуть обирати кросплатформені движки фронтенду, такі як Unity, що дозволяє адаптувати та запускати один код на різних середовищах, як-от iPhone, Android та настільних комп'ютерах, без проблем із кросплатформенністю бекенду, оскільки він не працює на кінцевому пристрої користувача.
Проте у Web3 це майже утопічна мрія. Міграція на інший ланцюг або VM означає повне перероблення проєкту, що передбачає значні витрати. Крім того, новачки у Web3 часто не мають досвіду для вибору екосистеми, яка підходить їм з технічної та екосистемної точок зору.
Щодо користувацького досвіду, взаємодія з блокчейном є складною. Колись популярна концепція абстракції облікових записів з'явилася, щоб вирішити проблеми користувацького досвіду у Web3, але її тут не буде детально розглянуто.
Підсумовуючи шість вищезгаданих пунктів: розробники, які переходять з Web2 у Web3, стикаються з суттєвими бар'єрами адаптації. Якщо вони є провідними розробниками у Web2, немає необхідності залишати свою поточну кар'єру для ризикованого кроку у невідоме середовище Web3 з невизначеним успіхом. Можна сказати, що провідні розробники ігор загалом уникають Web3, що певною мірою означає, що Web3-ігри схильні до фінансових спекуляцій, а не забезпечують високу ігрову привабливість і задоволення.
Користувачі також стикаються з подібними бар'єрами, зокрема через кілька кроків, які гальмують конверсію користувачів для Web3-ігор, внаслідок чого велика частина користувачів Web2 не бажає або навіть не знає про існування Web3-ігор.
Чи існує інфраструктурний проєкт, який може вирішити ці проблеми? Tabi Chain може бути одним із найближчих проєктів до вирішення всіх цих завдань для Web3-ігор завдяки своїй основній концепції "Omni Execution Layer": розробники більше не повинні турбуватися про відмінності в різних VM або середовищах виконання, а можуть використовувати свої знайомі або навіть кастомізовані середовища виконання для прямої розробки ігор або їх перенесення.
Крім того, Tabi Chain має модульний консенсус, рівні безпеки та інші функції. Усе є модульним і налаштованим, що відповідає потребам різних ігор та додатків.
Omni Execution Layer: Вибір середовища виконання відповідно до потреб розробника
Згадаємо суть блокчейну. Дехто може сказати, що це децентралізований незмінний реєстр. Але якщо поглянути ближче до технічної суті, це слід описати так: машина станів у розподіленій мережі з перевірюваною, постійною синхронізацією станів.
Тобто блокчейн, по суті, підтримує глобально визнану машину станів та її робочий стан:
Кожен вхід є детермінованим і записується в кожному блоці; Функція переходу станів є детермінованою, вона проявляється у вигляді VM або середовища виконання в клієнті блокчейну; Вихід стану також детермінований і записується в кожному блоці. Тому в консенсусній системі ланцюга не обов'язково повинен бути лише один тип шару виконання (наприклад, тільки EVM). Якщо ланцюг може перевірити стан кількох шарів виконання на собі, дозволяючи кожній грі працювати у власному середовищі, можна вирішити різні зазначені проблеми.
У Tabi кожна гра або dApp може створити окрему незалежну службу. Усі Сервіси передають свої блоки в систему консенсусу мережі; Вузли супервізора містять середовище виконання/VM усіх служб для перевірки стану блоків обслуговування.
В основі Omni Execution Layer Tabi лежить віртуальна машина, здатна до поліморфізму, тому вона називається Polymorphism VM.
Для існуючих віртуальних машин блокчейну віртуальній машині Polymorphism потрібно включити ці віртуальні машини у власне робоче середовище та забезпечити відповідні методи виклику інтерфейсу. "Інкорпорація" тут має дві конкретні реалізації:
Спільний стан світу: схожий на Ethermint, який забезпечує підтримку EVM у Cosmos. Однак EVM — це лише рівень, зосереджений на взаємодії з користувачем, контрактних операціях тощо, що створює враження, що всі операції на стороні користувача реалізовані на EVM. Але остаточні результати та дані цих операцій все ще зберігаються в інших модулях Cosmos. Таким чином, ця сумісність EVM, по суті, є відображенням найнижчого рівня даних.
Тому цей зв’язок зіставлення можна поширити на інші віртуальні машини. Наприклад, Ethermint може додати ще один рівень, SVM, пов’язаний з тими самими базовими даними, що й EVM.
This is similar to using VMWare on a PC to launch a Windows virtual machine. VMWare can access not only the virtual hard disk within the virtual machine but also the physical computer's hard disk. If a Mac virtual machine is launched at this point, it can mount data from the physical disk in the same way. This essentially achieves shared resources and state among multiple virtual machines in the same world.
Основна служба мережі Tabi прийме цю спільну форму світової держави. Таким чином, поки існує адаптація для відповідної віртуальної машини, dApps, розроблені на основі цієї віртуальної машини, можуть вибрати для безпосереднього розгортання в основній службі замість запуску нової служби.
Незалежний світовий стан: через різні потреби різних програм та ігор, деякі з яких можуть мати налаштований час виконання, не всі сценарії підходять для включення всіх віртуальних машин у віртуальну машину Polymorphism за допомогою підходу «спільного світового стану». Отже, незалежна світова держава також необхідна. Цей метод реалізації відносно простий і найкраще підходить для послуг, які потребують повної ізоляції даних.
Незалежно від вибраної форми, її мають перевіряти вузли супервізора, тобто віртуальна машина Polymorphism включає всі віртуальні машини або середовища виконання, які реалізують ці підходи.
Приклад перенесення гри Web2
Polymorphism VM пропонує високий рівень настроюваності, особливо для розробників Web2, дозволяючи їм використовувати свої знайомі мови та фреймворки для перенесення будь-якої бізнес-логіки на Polymorphism VM.
Припустімо, Minecraft хоче перенестися на Tabi, загальний процес буде таким:
Злегка змініть код сервера Minecraft (Java, те ж саме стосується інших мов), перемістивши дані, які повинні бути в ланцюжку, до бази даних (або набору баз даних) і вибравши всі функції, які можуть спричинити зміни в цій БД (тобто функції переходу стану).
Запакуйте цю базу даних і ці функції у файл JAR, який можна розуміти як тип виконуваної програми на Java. Потім додайте JRE, яке є середовищем виконання Java. Весь цей пакет завантажується у Polymorphism VM, і зрештою всі його дані будуть розміщені в блокчейні.
Перемістіть іншу серверну логіку, не пов’язану з ланцюжком (наприклад, формування команди, чат тощо), для роботи на серверах поза мережею.
Запустіть службу в ланцюжку Tabi та повідомте віртуальну машину Polymorphism у вузлах Supervisor для завантаження того самого JRE.
На цих кроках процес завершується.
Для розробників ці зміни внесено в існуючу мову та структуру Java. Той самий принцип застосовується до будь-якого іншого методу розробки ігор. Для користувачів немає суттєвих змін у взаємодії з грою. Очевидно, що цей спосіб перенесення ігор Web2 є дуже швидким і ефективним і потенційно може стати основоположною моделлю для масового впровадження ігор Web3.
Деталі функції переходу стану гри
Вище наведено загальний процес портування гри Web2. Для глибшого розуміння потрібні додаткові деталі. Цього разу ми використовуємо загальний приклад, а не конкретний для будь-якої гри, щоб продемонструвати деталі, пов’язані з часом виконання Omni Execution Layer.
По суті, налаштування середовища виконання гри можна розглядати як створення кінцевого автомата для гри в блокчейні, що називається State Transition Runtime (STR) на Tabi.
STR можна інтегрувати в Polymorphism VM або як двійковий файл, або як модуль.
У блокчейн-подібних системах ми повинні забезпечити прозорість вхідних даних, публічну видимість переходів станів і можливість виражати глобальний стан. Щоб відповідати цим вимогам, нам потрібно створити середовище виконання з такими характеристиками:
Всесвітня база даних (World DB) містить усі дані користувача в додатку, які потрібно записати в блокчейн. Ці дані мають бути цінними та важливими, тому для забезпечення їх доступності потрібна структура, схожа на блокчейн. Не всі дані потрібно записувати в блокчейн. Наприклад, в іграх вміст чату користувача зазвичай не важливий і є одноразовим, тому його не потрібно розміщувати в блокчейні.
Він повинен мати можливість виражати повний світовий стан. У багатьох сценаріях, як в іграх, цей вислів не обов’язково означає високу відстежуваність — достатньо простого накопичувача, тобто такі структури, як дерева Меркла, не завжди потрібні. Однак незалежно від того, яка структура даних використовується для представлення світового стану, надзвичайно важливо, щоб світовий стан Всесвітньої бази даних можна було виразити в підсумковій формі.
Будь-яка функція, яка може викликати зміни у Всесвітній базі даних, називається функцією переходу стану та повинна бути інкапсульована в середовищі виконання переходу стану. Будь-яка модифікація Всесвітньої бази даних поза межами часу виконання повинна вважатися незаконною та відхилятися.
Інтерфейси введення та виведення повинні відповідати дизайну Інтерпретатора вводу та Пропонатора блоків. Цей пункт відносно простий і не буде тут детально розглядатися.
Наступна організаційна структура є обов'язковою в НТР. Tabi зазвичай надає SDK, щоб полегшити розробникам створення цього середовища виконання.
Світова БД
На практиці гра чи програма, швидше за все, використовуватиме більше однієї бази даних, і ці бази даних можуть бути різних типів. Припустімо, що конкретна гра використовує як реляційну базу даних, так і базу даних ключ-значення.
Ось простий приклад реляційної бази даних:
UID: представляє унікального користувача, який може бути відкритим ключем або іншим ідентифікатором.
Nonce: використовується для запобігання повторним атакам.
Додаткові поля даних: Дані будь-якого типу.
Ось простий приклад бази даних ключ-значення:
"0x23417528":"58873",
"0xa9201b73": "9302",
"0xaf82102": "abcde",
...
Функція переходу стану
Це проста функція переходу стану. Коли він отримує дані користувача, він просто множить його на 5 і оновлює дані в реляційній базі даних.
Світовий накопичувач стану
Ми можемо побудувати дуже простий хеш-накопичувач для представлення стану світу:
A_s+1 = хеш(A_s + хеш(запит))
Завдяки такій конструкції ми можемо гарантувати, що завжди буде унікальний і визначений стан, відповідний будь-якій модифікації, внесеній до Всесвітньої бази даних.
Важливо зазначити, що це означає, що кожна функція переходу стану повинна реалізовувати цей метод. Ця вимога може бути виконана за допомогою модифікаторів, інтерфейсів, перехоплювачів або іншої специфічної для мови логіки. Оскільки різні мови мають різні характеристики, ми не будемо обговорювати тут особливості.
Процес оновлення для бази даних ключ-значення (KVDB) такий самий.
Випадкові числа
Випадкові числа не повинні з’являтися в жодній функції переходу стану, оскільки вони призведуть до того, що різні валідатори отримають різні результати під час перевірки, порушуючи послідовність. До вхідних параметрів системи слід включити випадкові числа.
Резюме
За допомогою двох наведених вище прикладів ми бачимо, що Omni Execution Layer від Tabi Chain забезпечує велику гнучкість для розробників ігор у модульній манері. Через обмежений простір ми не можемо обговорювати всі деталі тут, але наданого основного вмісту достатньо, щоб продемонструвати, що рішення Tabi Chain є дуже практичним і новим.
У існуючій системі Web3 роботам, розробленим на різних ланцюгах або віртуальних машинах, бракує переносимості; щоб ігри Web2 увійшли до Web3, це, по суті, означає переписування їх мовою та середовищем, незнайомими для розробників, обмеженими різноманітними неінтуїтивними обмеженнями.
У Tabi розробники використовують свої існуючі мови, платформи розробки та двигуни, їм потрібно лише внести прості адаптації та модифікації, подібні до використання SDK, щоб перенести свої роботи у світ блокчейну. Це збільшення ефективності та зменшення складності є експоненціальними.
Ми з нетерпінням чекаємо, коли це стане ключовим моментом для масового впровадження ігор Web3, залучення чудових розробників ігор Web2 і перенесення справді розважальних ігор у Web3.