Команда Lattice нещодавно анонсувала Redstone — їхній новий L2, створений з використанням їхнього нового внеску в OP Stack (стек, на якому працює Optimism L2).

Таким чином, у всіх виникає питання: «Чи слід створювати ончейн-ігри на цьому L2 і як це порівняти з альтернативами?». Багато хто звертався до нашої команди в Paima Studios, щоб отримати нашу думку, враховуючи, що ми є одним із найкращих розробників онлайн-ігор з іграми, які живуть у кількох мережах, тому ми докладемо всіх зусиль, щоб зануритися в нюанси.

ПРИМІТКА

На момент написання статті Редстоун був анонсований лише нещодавно. Web3 — це простір, що дуже швидко розвивається, тому ми радимо вам прочитати цю публікацію в блозі з відкритим розумом до Redstone, оскільки вони неминуче повідомлять більше про свою роботу

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

З чого все​почалося​

Отже, ви хочете створити онлайн-гру? Враховуючи, що Redstone є Ethereum L2, ми припустимо, що ви вже вирішили використовувати Ethereum.

Отже, чому ви не можете розгорнути свою гру безпосередньо в Ethereum? Можливо, ви знаєте, що це занадто дорого (понад $1 за ігровий хід на момент написання статті), але чи знаєте ви, чому це коштує занадто багато? Виявляється, є дві основні витрати: вартість виконання та вартість зберігання даних – обидві ці витрати є непомірно дорогими для гри. Однак так само, як процесори дорожчі за жорсткі диски, вартість виконання значно вища за вартість зберігання. То що, якби ми могли винайти спосіб перетворити вартість виконання у вартість зберігання? Хороші новини: зведені програми роблять саме це.

Зведення як​рішення​для масштабування

Зведені бувають у багатьох формах, кожна з яких по-своєму перетворює витрати на виконання у витрати на зберігання:

1. Оптимістичні зведення: запустіть обчислення в автономному режимі, а потім збережіть усі дані, необхідні для виконання функції (тільки дані, без виконання), разом із вашим локально обчисленим значенням результату. Насправді запускайте виконання, лише якщо хтось вважає, що опублікований вами результат є неправильним («доказ шахрайства»). \
   Популярні приклади: Arbitrum, Optimism
2. Зведення ZK: запустіть обчислення поза мережею, а потім збережіть усі дані, необхідні для виконання функції (тільки дані, без виконання) разом із вашим локально обчисленим ZK-підтвердженням результату. \
   Популярні приклади: ZK Sync, Starknet, Polygon zkEVM
3. Суверенне зведення: запустіть обчислення поза мережею, а потім збережіть усі дані, необхідні для виконання функції (лише дані, без виконання). \
   Популярні приклади: Rollkit, Paima Engine

Використання цих рішень знижує вартість транзакції для вашої гри приблизно до 0,05 дол. США (оновлені значення див. у розділі l2fees ), що, безперечно, є великим кроком у правильному напрямку.

Зниження вартості​L2​

Очевидно, що зниження вартості цих L2 є ключовим для успіху ігор. Незважаючи на те, що зведення безперечно стає дешевшим (комп’ютери стають кращими, технологія ZK – кращою тощо), основними витратами є не виконання обчислень поза мережею, а скоріше вартість розміщення даних на L1.

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

Однак EIP4844 має деякі недоліки:

• Дані лише тимчасові (вам знадобиться знайти інше рішення для зберігання, щоб потім зберегти їх на хостингу)
• Обсяг даних обмежений, приблизно 2 Мбайт на блок (спільний для всіх зведених даних на Ethereum)

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

Альтернатива №1: зберігати дані на централізованому сервері (або наборі серверів ).

Однією з альтернатив для збереження низької вартості є просто зберігання даних на централізованому сервері, керування яким люди довіряють вам, і розміщення лише хешу даних у мережі. Варіантом цієї ідеї є використання групи незалежно керованих машин, об’єднаних як мультисиг. Така схема називається «Комітет доступності даних» (DAC), і саме її використовують Arbitrum Nova, Arbitrum Orbit і Polygon CDK.

Ці схеми набагато дешевші (0,001 $/tx для Arbitrum Nova, якщо ігнорувати ринок комісій) в обмін на більш централізовану мережу. Основний ризик полягає в тому, що якщо DAC кожен раз припиняє розміщення даних (наприклад, вони публікують хеш і ніколи не передають дані для цього хешу), мережа зупиняється.

Особлива примітка щодо​Arbitrum​

Вам може бути цікаво, чому Arbitrum з’являється в списку двічі. Arbitrum на даний момент пропонує 3 основні пропозиції:

• Arbitrum One (основна мережа Arbitrum, яка є повним зведенням з даними про Ethereum)
• Arbitrum Nova (L2, який використовує ЦАП)
• Arbitrum Orbit (стек для створення L3 для Arbitrum One)

Як бачите, проблема з Nova полягає в тому, що немає хорошого способу використовувати DeFi для вашої гри (користувачі повинні були б перейти до (Nova -> ETH L1 -> One) і витратити багато на газ просто для мосту), тоді як новий стек Orbit дозволяє легко переходити (Orbit -> One). Крім того, оскільки Orbit — це стек для створення L3, ви можете використовувати існуючий L3, як-от Xai Games, який живить власний ЦАП, або розгорнути свій власний L3 (хоча якщо у вас є спеціальний для гри L3, єдиним зв’язком якого з Ethereum є час від часу публікація публікацій). хеші, можливо, вам буде краще з web2.5)

Альтернатива №2: Зберігайте дані в іншій децентралізованій​мережі​

Замість того, щоб чекати впровадження EIP4844 з обмеженою пропускною здатністю в основній мережі, інші проекти, такі як Celestia, Avail і EigenDA, вирішили впровадити подібну концепцію як окремий ланцюжок (так званий рівень доступності даних (“DA”) і зосередившись виключно на у цьому випадку використання вони також пропонують вищі обмеження даних, ніж планує підтримувати основна мережа Ethereum. Ці платформи не підтримують смарт-контракти, натомість призначені для використання виключно як рівень даних для L2.

Зокрема, можна створити OP Stack з даними про Celestia, а також Arbitrum Orbit з даними про Celestia. Це пов’язано з деякими компромісами:

1. Довіра. Ваше зведення тепер залежить від рівня DA для безпеки поверх Ethereum (але, можливо, краще, ніж DAC)
2. Вартість. Ваш зведений пакет тепер повинен платити мережі DA за його безпеку (яку ви повинні платити у рідному токені рівня DA)
3. швидкість. Час блокування Celestia становить 15 секунд, а час блокування Avail – 20 секунд. Наприклад, дані мають оселитися в Celestia, перш ніж їх можна буде з’єднати з EVM за допомогою контракту blobstream Celestia. Однак поставтеся до цього з недовірою, оскільки всі L2 зазвичай емулюють швидший час блокування, ніж насправді може забезпечити Ethereum (враховуючи, що час блокування Ethereum становить лише 15 секунд, незважаючи на те, що Arbitrum використовує швидший час блокування).

Цей тип налаштувань особливо використовується Mantle (OP Stack + EigenLayer DA) і Manta Pacific (OP Stack + Celestia). Ціна на них ще не визначена, але команда Celestia заявляє приблизно 0,001 дол. США, що означає, що вартість зберігання на рівні DA (порівняно з вартістю виконання на платному ринку з боку EVM) мінімальна.

Альтернатива №3: ​​зберігати дані в ЦАП, який можна​оскаржити​

Нарешті ми можемо поговорити про те, що пропонує Redstone. Якщо вам не подобаються компроміси зберігання даних на рівні DA, але вам не подобається централізація DAC, замість цього ви можете створити DAC, де ви зможете фінансово покарати комітет, якщо вони не нададуть дані .

Щоб зрозуміти, що це означає, розглянемо, як працює протокол DAC:

Як записувати​дані​

1. Sequencer for Redstone отримує вашу транзакцію
2. Секвенсор надсилає дані на ЦАП для збереження
3. DAC повертає підтвердження того, що дані збережено
4. Секвенсор публікує хеш даних у L1

Як читати​дані​

1. Синхронізуйте ланцюжок Ethereum, шукаючи хеші, надіслані в контракт згортання
2. Запит даних для хешу з DAC
3. Обчисліть стан L2 на основі цих даних

Отже, що​змінює​Redstone

Під час читання даних, якщо дані недоступні, ви можете оскаржити DAC, стверджуючи, що він не зробив дані доступними (він же дані не можна завантажити з їхнього сервера).

Щоб належним чином спонукати всіх бути чесними, ми встановлюємо наступні правила скорочення:

1. Якщо претендент нечесний (дані дійсно були доступні), його скорочують (інакше ви можете фінансово атакувати мережу, оскаржуючи кожен блок)
2. Якщо DCA є нечесним (дані недоступні), вони скорочуються.

Це здається простим рішенням, але складність полягає в тому, щоб визначити, хто винен, якщо виникає проблема. Подумайте про такий сценарій:

1. Секвенсор публікує хеш, не передаючи реальні дані
2. Хтось кидає виклик секвенсору
3. Секвенсор, бачачи виклик, робить дані доступними

Якщо ви зовнішній спостерігач, який не стежив за ланцюгом у реальному часі, дані виглядають доступними (якщо ви запитуєте DAC після факту, ви отримуєте дані, як очікувалося), тож схоже, що претендент бреше, хоча вони НЕ були.

Якщо ваше вирішення цієї проблеми полягає в припущенні, що секвенсор ніколи не буде брехати лише для гри, то чому б замість цього не використати стандартний ЦАП. Крім того, припущення, що секвенсор є чесним, не відповідає концепції «суперланцюга» спільного секвенсора, тобто активи не можуть використовувати спільний секвенсор для передачі між ланцюжками OP Stack (тому ви зіткнетеся з тією ж проблемою, що й Arbitrum Nova, якщо Redstone розгортається як L3)

Те, як команда Lattice планує впоратися з цим, буде ключовим моментом, на який слід звернути увагу, оскільки буде доступна додаткова документація та інформація про дорожню карту.

Альтернатива №4: Використовуйте​ZK​

Зауважте, що проблема з нерозповсюдженням даних (атаки на приховування даних), яка впливає на Redstone, не є винятковою для Optimistic rollups. ZK Rollups, дані яких зберігаються поза мережею (так звані «Validium»), страждають від тієї ж проблеми, тому люди, як правило, більше зацікавлені в зведених пакетах (які публікують усі дані в ланцюжку).

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

Як я можу зробити витрати на мою гру ще нижчими, якщо проблемою є сама Solidity ?

Усю цю публікацію в блозі ми говорили про те, як впоратися з витратами на зберігання. Однак деякі ігри можуть бути обмежені процесором (навіть якщо вони запускаються в централізованому ланцюжку EVM, вони працюють). Якщо це ви, можливо, вам буде цікаво використовувати зведений пакет Sovereign, щоб ви могли масштабувати свою гру за межі EVM за допомогою Paima Engine.

Paima Engine дозволяє створювати автомати стану для конкретного додатка в Javascript, які можна розгортати в будь-якому ланцюжку EVM на ваш вибір (включаючи Redstone!). Ці суверенні зведені пакети можуть отримати доступ до інформації EVM (включно з даними двигуна MUD), і тому можуть служити чудовим способом зробити будь-яку частину вашої гри набагато швидшою та дешевшою.

​Висновок​

Підсумовуючи, зниження вартості даних є найважливішим кроком до зниження витрат на онлайн-ігри. Сьогодні існує багато різних існуючих рішень із різними компромісами, і Redstone представляє себе безпечнішим, ніж стандартний ЦАП, але ще належить побачити, чи є він значно безпечнішим, і чи різниця достатньо значуща, щоб бути життєздатною альтернативою до рішень із підтримкою рівня DA. Для проектів, яким потрібно масштабувати обчислення на основі даних, існують такі рішення, як Paima Engine, щоб вирішити цю проблему.

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

Paima​Studios​

Paima Studios, заснована в квітні 2022 року, є основними розробниками Paima Engine: механізму Web3, створеного з використанням нової технології рівня 2, яка дозволяє створювати онлайн-ігри, гейміфікацію та автономні світи. Paima Engine — це безпечний і простий спосіб увійти в Web3, оскільки він може використовуватися з навичками Web2 і не наражає користувачів або розробників на звичайні ризики та хакерські атаки Web3.

• Кодова база Paima Engine: https://github.com/PaimaStudios/paima-engine
• Документація Paima: https://docs.paimastudios.com/
• Шаблон Paima: https://github.com/PaimaStudios/paima-game-templates
• Пакет Paima NPM: <a href="https://www.npmjs.com/package/@paima/sdk""> https://www.npmjs.com/package/@paima/sdk

Ви також можете дізнатися більше з наших соціальних мереж:

• Youtube: <a href="https://www.youtube.com/@paimastudios""> https://www.youtube.com/@paimastudios
• Discord: http://discord.gg/jZ59ArVaxv
• Reddit: https://reddit.com/r/paima
• Twitter: https://twitter.com/PaimaStudios

Хочете працювати разом? Не соромтеся зв’язатися з нами через нашу контактну сторінку: https://paimastudios.com/contact/

Відмова від відповідальності:

1. Цю статтю передруковано з [blog.paimastudios]. Усі авторські права належать оригінальному автору [paimastudios]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.