- Тема
11k Популярність
13k Популярність
43k Популярність
29k Популярність
732 Популярність
90k Популярність
25k Популярність
26k Популярність
7k Популярність
15k Популярність
- Закріпити
11k Популярність
13k Популярність
43k Популярність
29k Популярність
732 Популярність
90k Популярність
25k Популярність
26k Популярність
7k Популярність
15k Популярність
Як за допомогою OPStack побудувати тактовий цикл повної ланцюжкової гри?
Автор: Gametaverse
Загалом, ігри циклічні. Ігровий цикл — це ітеративний процес, який зазвичай складається з обробки введених користувачем даних, оновлення стану гри та відтворення ігрового світу. Цей цикл продовжується під час роботи гри, як правило, від десятків до сотень разів на секунду, щоб підтримувати ігровий світ.
Однак архітектура блокчейну базується на push-технологіях. Блокчейн — це розподілена база даних, яка обмінюється та зберігає інформацію через вузли в мережі. Коли вузол генерує нову транзакцію (наприклад, переказ, виклик контракту тощо), транзакція буде передана в мережу, а інші вузли перевірять її та додадуть до блокчейну після отримання транзакції. Це пасивний процес, вузли не будуть активно шукати нові транзакції, а чекатимуть, поки інші вузли в мережі надішлють нові транзакції. Тому кажуть, що архітектура блокчейну базується на push.
Тому дуже важливо реалізувати систему циклів із тактовими циклами в повноланцюговій грі. Зрештою, у так званому «автономному світі» ми всі сподіваємося, що деякі NPC або віртуальні середовища можуть автоматично еволюціонувати з часом, замість того, щоб пасивно еволюціонувати після вводу транзакцій, які надсилаються в блокчейн.
@therealbytes розробив ланцюжок тиків із підтвердженням концепції (ланцюжок із тактовими циклами) на основі OP Stack, який запускає автоматичну реалізацію гри життя Конвея «тік-тік», давайте подивимося, як він це реалізував.
Щоб зробити переклад простим, ми буквально перекладаємо tick на «тик», що означає «тактовий цикл».
Ticking-Optimism — це перевірена реалізація концепції «Ticking Blockchain» на основі архітектури зведення Optimism Bedrock.
У ланцюжку тиків існує спеціальний смарт-контракт під назвою «контракт тиків», і кожен блок автоматично викликається протоколом. Це дозволяє іншим смарт-контрактам автоматично запускатися в певний час або проміжки часу, не вимагаючи від користувачів відправляти транзакції.
Як досягти
Нова модульна зведена архітектура Optimism, Optimism Bedrock, представляє новий тип транзакцій під назвою «Депозитні транзакції». На відміну від звичайних операцій, депозитні операції:
Блоки з шару 1.
Перевірка підпису не потрібна.
Купуйте газ L2 на L1, тому газ L2 не повертається.
В оригінальному Bedrock депозитні транзакції використовувалися для двох речей:
— Встановіть властивості L1 (число, позначку часу, хеш тощо) для попередньо розгорнутих контрактів L2 у кожному блоці.
В останньому випадку транзакції створюються вузлами згортання. Він не оплачує газ, а використаний газ не вираховується з газового пулу.
Ticking-Optimism змінює вузол зведення, а також створює «транзакцію tick», яка працює так само, але замість встановлення властивості L1 вона викликає функцію tick() у контракті, попередньо розгорнуту за адресою 0x420000000000000000000000000000000000000000000000000000000000000000000000000000. Цей контракт може викликати інший контракт, встановивши його цільову змінну.
Мотивація
Щоб проілюструвати силу тикчейнів, уявіть собі гру на блокчейні, де кілька NPC (персонажів, які не є гравцями) пересуваються по карті. Без ланцюжка галочок у нас є два основні підходи до проектування:
Ледаве оновлення. На стороні клієнта здається, що NPC постійно рухаються, але їхні позиції оновлюються лише в ланцюжку, коли користувачі надсилають транзакції для взаємодії з ними. Потім контракт обчислює нове місце розташування NPC на основі його останнього оновлення в ланцюжку та кількості блоків, які пройшли з того часу.
Ручна галочка. Ми визначаємо функцію оновлення, яка встановлює положення кожного NPC на карті, і маємо зовнішній обліковий запис періодично викликати її.
З тикчейном рішення подібне до ручного тикання, але тиковий контракт викликає функцію оновлення автоматично, а не вручну.
Переваги використання «автоматичної галочки» ланцюжка галочок замість ручних галочок:
Оновлення гарантовано за домовленістю.
Оновлення буде виконано перед усіма транзакціями в блоці, і його не можна відкрити, оскільки це частина самого протоколу.
Операції оновлення не беруть участь у звичайному ринку газу.
Однак для автоматичних позначок потрібен спеціальний блокчейн. Якщо частота оновлення однакова, ручне й автоматичне відстеження потребують однакових обчислювальних ресурсів на вузлі. З іншого боку, відкладені оновлення зазвичай дешевші, оскільки оновлення в ланцюжку менші та рідше.
Крім того, обчислювальна вартість транзакцій із галочками зростає, коли зростає стан, який потрібно оновити. Це чинить додатковий тиск на розробників, щоб розробляти свої програми таким чином, щоб витрати ніколи не перевищували того, що може підтримувати мережа.
Незважаючи на ці величезні недоліки, автоматичні галочки краще підходять для певних типів програм, ніж відкладені оновлення.
Ціки дозволяють смарт-контрактам отримувати доступ за постійною ціною до динамічного стану, який оновлюється за допомогою виразів відкритої форми.
Стан (у наведеному вище прикладі розташування NPC) завжди читається в ланцюжку за постійної, відносно низької вартості газу. Але вартість розрахунку поточного стану зросте з кількістю блоків з моменту останнього оновлення, а вартість газу зросте ще більше.
Якщо ми оновлюємо позицію об’єкта, що рухається з постійною швидкістю, ми можемо обчислити, де він має бути в будь-якому заданому фрагменті, виходячи з його останнього встановленого положення та кількості фрагментів з моменту оновлення. Вартість цієї операції не зростає зі збільшенням кількості блоків між оновленнями.
З іншого боку, якщо стан, який ми оновлюємо, є чимось на кшталт «Гри в життя» Конвея (або симуляції трьох гравітацій), вартість оновлення зростає лінійно з кількістю кроків після останнього оновлення. Це проблема, оскільки вона може вирости за межі того, що користувачі готові платити, або того, що мережа може підтримувати.
У разі відкладених оновлень логіку оновлення потрібно впровадити як у смарт-контракт, так і в клієнта. За допомогою тикінгу його потрібно лише впровадити в блокчейні, і клієнти можуть просто реагувати на події в ланцюжку.
Відкладені оновлення дозволяють розробникам поширювати свою логіку оновлення між багатьма функціями та смарт-контрактами, причому кожна функція запускається лише тоді, коли виконуються певні транзакції. Навпаки, підхід тік-тік вимагає лише функції оновлення, яка гарантовано запускається періодично. Останнє полегшує підтримку узгодженості та цілісності стану.
Крім того, кожного разу, коли додається новий стан відкладеного оновлення (наприклад, новий тип NPC), усі функції оновлення, можливо, доведеться змінити, щоб це врахувати. Це робить базу коду більш складною та схильною до проблем.
Вартість відкладених оновлень часто коливається в широких межах, і користувачі можуть створювати свої транзакції так, щоб більшість оновлень лягла на інших. З тиками вартість усіх операцій є відносно стабільною та не вразливою до атак MEV.
Демонстрація Конвея Гра життя
Я створив демонстраційну версію Tickchain, яка запускає інтерактивну версію гри Конвея «Game of Life». Ланцюжок було модифіковано, щоб включити логіку клітинних автоматів у механізм виконання, що зробило його більш ефективним, дозволивши використовувати більші ігрові поля, ніж можна було б реалізувати як байт-код смарт-контракту.
Вихідний код демо:
Демонстраційне відео: