Побудова віртуального світу: як використовувати технологію блокчейн, щоб зберегти час для «цифрових богів»?

Оригінальна адреса:

Переклав: Джастін @captainz

Як творці віртуальних світів, ми маємо на меті створити середовище, яке буде цікавим і привабливим для користувачів. Це вимагає від нас знайти баланс між розробкою цифрової фізики, яка дозволяє виникати складним і несподіваним поведінкам, і забезпеченням того, щоб існуюча інфраструктура підтримувала цю поведінку. Для цього нам потрібно розглянути три основні виміри цифрової фізики: час, форму його законів і міру, до якої ці закони застосовуються.

час

Ми називаємо плин часу у віртуальному світі повторюваним застосуванням законів світу до самого себе. Кожна окрема програма є «миттю» в потоці часу в цьому світі. Один із способів спроектувати час у світі — зробити його безперервним із зовнішнім часом. У віртуальному світі, заснованому на блокчейні, кожен блок відповідає певній кількості минулих моментів у світі, незалежно від того, які транзакції блок містить. Це відоме як синхронний час або явище «тикання». Такий підхід може зробити світ цікавішим для користувачів, оскільки вони можуть бачити результати своїх дій у режимі реального часу. Крім того, це призводить до довшого часу перебування у світі, і світ постійно оновлюється, що заохочує цікаву поведінку.

Однак цей підхід має і свої недоліки. Більші часові рамки зазвичай вимагають більше обчислювальних ресурсів, які можуть швидко перевищити можливості ланцюга або сервера. Також може бути складно реалізувати цю систему на звичайному блокчейні, оскільки всі зміни в ланцюжку повинні бути ініційовані транзакціями, ініційованими зовнішніми користувачами.

Ця складність стає очевидною, коли ви уявляєте щось, здавалося б, просте: мережеву гру з неігровими персонажами (NPC). У головній мережі Ethereum ви можете визначити функцію оновлення, яка встановлює положення кожного NPC на карті гри, і мати зовнішній обліковий запис періодично викликати її, щоб оновити їхнє положення. Але це може бути ненадійним, оскільки ви не можете гарантувати, що зовнішній рахунок не буде перевищувати плату за газ у блоці, який має викликати оновлення. Таким чином, структура часу у вашій грі буде дрейфувати (візьміть як приклад оригінальну функцію CryptoKitties giveBirth(); у міру збільшення комісії за газ у ланцюжку Axiom Zen фактично має збільшити винагороду за виклик функції giveBirth, щоб гарантувати, що новий NFT Транзакція народження викликається через 256 блоків після того, як користувач розводить Кітті). Ми називаємо цей спосіб використання зовнішніх облікових записів «ручним позначенням».

Користувальницькі зведення дають нам більше можливостей для додавання функціональних можливостей «галочки» в ланцюжку, немає потреби у зовнішніх облікових записах, а протокол гарантує синхронізоване просування часу. Ми називаємо цей метод «автоматична галочка». Автоматичні тіки можна реалізувати шляхом написання «тикового контракту», який викликається самим протоколом, а не зовнішнім обліковим записом.

Як приклад, @therealbytes розробив ланцюжок перевірок концепції на основі OP Stack, який запускає реалізацію Game of Life від Конвея, яка тикає автоматично (демонстраційне відео про це можна знайти тут). Bytes використовує модифіковану системну транзакцію для автоматичного виклику контракту симуляції стільникового автомата. Щоб повністю перевірити межі самого ланцюжка, він реалізував гру двома способами: один як смарт-контракт Solidity, що працює в ланцюжку, а інший як попередня компіляція самого ланцюжка. Реалізація Solidity максимально використовує ЦП після досягнення сітки 70x70 з двома оновленнями на блок (1 блок/сек, або приблизно 10 тис. комірок/сек), тоді як ланцюжок спеціального попередньо скомпільованого двигуна використовує приблизно 6 %. Досягнення тієї ж швидкості для 256x256 сітка з вищим процесором (близько 130 тис. комірок/с).

В останньому реченні останнього абзацу ключовим словом є «досягнення межі». Ланцюжки тік-тік додають додатковий рівень складності: кожен додатковий блок вимагає більше станів, до яких торкаються транзакції, які імітують гру. Згодом вузли зведення будуть обмежені необробленими обчисленнями (ЦП, дисковий IO тощо). Єдиним рішенням тут є використання вузлів більшої ємності.

Альтернативою «синхронному часу» є «асинхронний час». За цією схемою плин часу у світі не обов’язково просувається вперед, як просувається зовнішній час. Натомість час зазвичай рухається вперед, коли відбуваються певні події (як правило, дії користувача). Традиційні настільні ігри, які не включають таймер, належать до подібної категорії. Досягти асинхронного часу в ланцюжку легше, оскільки це модель, яку блокчейни розроблені для підтримки. Однак він також жертвує деякими функціями, які можуть зробити світ цікавішим (наприклад, автоматичне переміщення NPC).

WildWood, рання версія гри з підтвердженням концепції від @notdavidhuang і cha0sg0d, розкриває цю жертву. У цій грі двоє гравців повинні захистити свою базу від облоги агресивних NPC. У попередніх версіях гри рух NPC запускався лише тоді, коли гравець рухався сам — непрактична реалізація асинхронного часу. Після додавання позначок NPC перемістилися, але інша проблема залишилася. Ланцюжок тикає кожну секунду, а це означає, що якщо гравець рухається більше одного разу на секунду, гра повинна транслювати позицію гравця на карті з оновленнями з оптимістичного зведення. Однак ваші товариші по команді не бачитимуть вашого клієнта автоматично, а це означає, що оновлення позиції гравця буде із затримкою. Щоб подолати цю проблему, команда використала службу ретрансляції MUD, однорангову мережу для трансляції локальних клієнтів до повного ланцюга. Вуаля, перехід від асинхронного часу до синхронного виконано.

Закони закритої та відкритої форм

Будівельники світу також повинні вирішити, чи буде їхній віртуальний світ відкритим чи закритим. Вирази закритої форми мають фіксовану кількість операцій. Однак кількість операцій, виражених у відкритій формі (або рекурсивно), зростає відповідно до заданих змінних. У відкритих представленнях майбутній стан світу можна розрахувати лише шляхом багаторазового застосування законів світу до відомих станів. Складні графічні середовища, як-от Dwarf Fortress, зазвичай підпадають під цю категорію. Представлення закритої форми, з іншого боку, дозволяють обчислювати будь-який майбутній стан на основі минулих станів і часу, що минув між ними (припускаючи, що жодні майбутні дії користувача не змінюють стан), наприклад, швидкість видобутку ресурсів в Age of Empires II.

Відкриті форми можуть зробити віртуальні світи цікавішими, оскільки, як і реальний світ, вони непередбачувані. Прогнозування майбутнього стану світу вимагає все більше часу та обчислювальних ресурсів (гарним прикладом є Game of Life Конвея, реалізована в ланцюжку: ви не можете обчислити довільні майбутні стани, тому що вам потрібно запустити гру вчасно). Крім того, несподівана макроскопічна поведінка може виникнути в результаті простих мікроскопічних взаємодій. У світі, керованому закритою формою, ця емерджентна поведінка зазвичай відбувається лише зовні, через дії користувачів (їх самих, як у відкритій формі), а не в самій фізиці світу.

Компроміс між відкритою та закритою формами передбачає баланс, подібний до балансу часу. Закриті форми можуть зробити світ менш потенційно цікавим, але вони також роблять його більш ефективним з точки зору обчислень. Закрита форма може використовуватися з синхронним або асинхронним часом. При реалізації на блокчейні вони мають значні переваги перед відкритими формами, коли мова заходить про синхронізацію часу. Оскільки вартість постійна протягом будь-якого періоду часу, світ можна спроектувати так, щоб стан у мережі оновлювався лише тоді, коли користувач надсилає транзакцію, але для нього встановлювався стан після часу, що минув з моменту останнього оновлення.

Діапазон часу та форми

Розглянемо поточний стандартний підхід до динаміки в ланцюжку, підхід, відомий як «ліниві оновлення». У відкладеному оновленні гравець ініціює початок і кінець дії, але час між ними симулюється, а не обчислюється безпосередньо. Наприклад, гравець садить яблуню в 1-й частині, а потім збирає яблука в 10-й частині. Логіку відкладеного оновлення можна написати так, щоб гравці могли збирати одне яблуко за одиницю часу, загалом 9 яблук. Це чудово підходить для логіки оновлення із функціями закритої форми (наприклад, одне яблуко на блок), але не працює, якщо логіка ведення господарства змінюється на основі введення між діями гравця. Якщо в блоці 5 проливний дощ прискорює ріст яблук, а в блоці 7 чума сарани майже знищує врожай, то в блоці 10 не має значення, скільки яблук гравець може зібрати. Обчислення, якщо ви не застосувате всі події, що відбулися (у вас не буде достатньо обчислювальної потужності, щоб наздогнати новий стан). Тим не менш, відкладені оновлення чудово підходять для дешевих розрахунків певних мобів (наприклад, рослин із фіксованою швидкістю росту), але цього все одно недостатньо для повного інструментарію для динамічного світу.

У реальному світі час є скрізь і минає миттєво, а Всесвіт потенційно нескінченний (хоча й з деякими ускладненнями відносності). Однак у віртуальному світі це не обов’язково так.

По-перше, віртуальні світи можуть бути чітко обмежені. Можливості для інтриги загалом зростають із збільшенням розміру — у світі з 20 мільярдами галактик відбувається більше речей, ніж у світі з двома атомами — але так само зростає вартість обчислень. Обидва ці зв’язки тісно пов’язані з двома компромісами, згаданими раніше: плином часу та фізичною формою.

По-друге, час не обов’язково має проходити всюди у віртуальному світі. Світ можна розділити на окремі регіони з різними проміжками часу, щоб зменшити обчислювальний тягар світу. Наприклад, більш складні та дорогі правила фізики можна використовувати в зонах активності користувачів, а прості правила фізики в місцях, де активності немає. Недоліки цього підходу подвійні: він може зробити світ непослідовним і неповним, що обмежує простір проектування для світових правил і чинить тиск на творців світу, щоб вони не заплутували користувачів; Обмеження поширення причинно-наслідкових зв’язків у світі, якщо дії однієї області не може мати наслідків у віддалених областях, простір між двома заморожено в часі. Розмір області, де застосовуються правила фізики, є важливим фактором дизайну, який впливатиме на ресурси, які потрібні світу, і рівень задоволення, який він може досягти.

Щоб створити цікавий і захоплюючий віртуальний світ, необхідно ретельно збалансувати обчислювальну ефективність і задоволення. Це включає в себе рішення про те, який тип часу використовувати (синхронний чи асинхронний) і оцінку форми законів фізики, які керують світом. Ще одним важливим рішенням є розмір території, до якої застосовуються закони фізики. Роблячи цей вибір обережно, розробники світу можуть не тільки зберегти інтерес до управління обчислювальним навантаженням у світі, вони також можуть надати іншим розробникам дуже плідну базу для інновацій.