Застосування zk-SNARKs у повноцінних іграх: на прикладі гри на знищення
У розробці ігор на блокчейні оптимізація досвіду гравців завжди була в центрі уваги галузі. Наприклад, в грі на блокчейні під назвою "Гра на знищення" тривалість кожного раунду становить 4 хвилини, і гравець повинен знищити всі елементи на ігровому полі в установлені терміни, щоб отримати токен. Однак через особливості взаємодії з блокчейном, кожна дія гравця потребує очікування щонайменше 2 секунд, що серйозно впливає на ігровий досвід.
Щоб вирішити цю проблему, розробники запропонували використовувати технологію zk-SNARKs для зменшення частоти взаємодії гравців з блокчейном. Їхнє припущення таке: процес гри не записується в блокчейн, але через певний механізм забезпечується відсутність ризику шахрайства. Конкретно, кожна дія гравця генерує zk-SNARK, а zk-SNARK наступних дій базується на попередньому, формуючи самодостатній zk-SNARK, подібний до структури блокчейну. Коли гра закінчується, потрібно лише надіслати zk-SNARK останньої дії в блокчейн, де смарт-контракт перевіряє результат.
Однак цей план стикається з безліччю викликів під час реалізації:
Захист від шахрайства під час гри та її результатів: потрібно не лише генерувати ZKP для остаточного результату, а й перевіряти весь процес гри.
Технічні проблеми, що виникають під час поступового створення ZKP: кожен крок ZKP залежить від попереднього, як забезпечити можливість створення та перевірки є під питанням.
Обробка відкритих ігрових даних: дані самої гри є відкритими, використання zk-SNARKs для приховування інформації здається зайвим. Одночасно, як зберегти ігрові дані на стороні смарт-контракту також стало проблемою.
Проблема витрат ігрових предметів: коли йдеться про витрати токенів, що представляють ігрові предмети, питання, як обробляти передачу токенів у системі ZKP, є складним.
Характеристика приховування даних ZKP: для сценаріїв, де не потрібно приховувати ігрові дані, використання ZKP навпаки збільшує складність отримання даних та невизначеність реалізації.
Після глибокого аналізу ми дійшли таких висновків:
Для таких повністю ланцюгових ігор, де немає потреби приховувати дані гри, використання ZKP для приховування інформації може бути більше шкідливим, ніж корисним. Щоб покращити ігровий досвід, можна розглянути можливість того, щоб процес гри не фіксувався в ланцюгу, а лише остаточний результат перевірявся на ланцюзі. Ключове завдання полягає в тому, щоб знайти спосіб гарантувати, що на кожному етапі гри, починаючи з початку і до закінчення, не буде можливості для шахрайства.
На даний момент, технологія ZKP в ігровій сфері в основному підходить для двох типів сценаріїв:
Інформаційне приховування в іграх з неповною інформацією, таких як Темний ліс, Техаський холдем, Гра в вовка тощо.
Докази результатів одноразових ігор, таких як лотерея, вгадування чисел, камінь-ножиці-папір тощо.
Варто зазначити, що через складність технології zk-SNARKs, аналіз і висновки цієї статті можуть мати певні обмеження. Ми сподіваємося, що більше фахівців глибше обговорять цю тему, щоб надати більше інноваційних ідей для розвитку повноцінних ігор.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
7
Репост
Поділіться
Прокоментувати
0/400
CountdownToBroke
· 08-02 02:20
2 секунди очікування, краще піти пограти в мобільні ігри
Переглянути оригіналвідповісти на0
MidnightSnapHunter
· 07-31 11:56
Чотири хвилини на гру? Чекайте, поки сервер зависне.
Переглянути оригіналвідповісти на0
TokenomicsTrapper
· 07-31 10:50
лmao ще один недопечений zkp копіум... класичний патерн виходу з пампу завантажується rn fr
Переглянути оригіналвідповісти на0
ImpermanentLossFan
· 07-30 10:06
Коли це закінчиться? Щоб пограти в гру «знищити», потрібно ще й zk-SNARKs.
Переглянути оригіналвідповісти на0
NftDataDetective
· 07-30 10:01
хмм 2с затримка? чесно кажучи, все ще здається дещо повільно для гри в три в ряд, якщо бути відвертим
Переглянути оригіналвідповісти на0
TrustMeBro
· 07-30 09:59
Дві секунди затримки вже не рухаються.
Переглянути оригіналвідповісти на0
ZKProofster
· 07-30 09:55
технічно кажучи... 2сек затримка все ще погана для ігор, чесно кажучи. жодна кількість zkp не може виправити цю фундаментальну проблему
Виклики та обмеження впровадження технології zk-SNARKs в іграх на блокчейні
Застосування zk-SNARKs у повноцінних іграх: на прикладі гри на знищення
У розробці ігор на блокчейні оптимізація досвіду гравців завжди була в центрі уваги галузі. Наприклад, в грі на блокчейні під назвою "Гра на знищення" тривалість кожного раунду становить 4 хвилини, і гравець повинен знищити всі елементи на ігровому полі в установлені терміни, щоб отримати токен. Однак через особливості взаємодії з блокчейном, кожна дія гравця потребує очікування щонайменше 2 секунд, що серйозно впливає на ігровий досвід.
Щоб вирішити цю проблему, розробники запропонували використовувати технологію zk-SNARKs для зменшення частоти взаємодії гравців з блокчейном. Їхнє припущення таке: процес гри не записується в блокчейн, але через певний механізм забезпечується відсутність ризику шахрайства. Конкретно, кожна дія гравця генерує zk-SNARK, а zk-SNARK наступних дій базується на попередньому, формуючи самодостатній zk-SNARK, подібний до структури блокчейну. Коли гра закінчується, потрібно лише надіслати zk-SNARK останньої дії в блокчейн, де смарт-контракт перевіряє результат.
Однак цей план стикається з безліччю викликів під час реалізації:
Захист від шахрайства під час гри та її результатів: потрібно не лише генерувати ZKP для остаточного результату, а й перевіряти весь процес гри.
Технічні проблеми, що виникають під час поступового створення ZKP: кожен крок ZKP залежить від попереднього, як забезпечити можливість створення та перевірки є під питанням.
Обробка відкритих ігрових даних: дані самої гри є відкритими, використання zk-SNARKs для приховування інформації здається зайвим. Одночасно, як зберегти ігрові дані на стороні смарт-контракту також стало проблемою.
Проблема витрат ігрових предметів: коли йдеться про витрати токенів, що представляють ігрові предмети, питання, як обробляти передачу токенів у системі ZKP, є складним.
Характеристика приховування даних ZKP: для сценаріїв, де не потрібно приховувати ігрові дані, використання ZKP навпаки збільшує складність отримання даних та невизначеність реалізації.
Після глибокого аналізу ми дійшли таких висновків:
Для таких повністю ланцюгових ігор, де немає потреби приховувати дані гри, використання ZKP для приховування інформації може бути більше шкідливим, ніж корисним. Щоб покращити ігровий досвід, можна розглянути можливість того, щоб процес гри не фіксувався в ланцюгу, а лише остаточний результат перевірявся на ланцюзі. Ключове завдання полягає в тому, щоб знайти спосіб гарантувати, що на кожному етапі гри, починаючи з початку і до закінчення, не буде можливості для шахрайства.
На даний момент, технологія ZKP в ігровій сфері в основному підходить для двох типів сценаріїв:
Інформаційне приховування в іграх з неповною інформацією, таких як Темний ліс, Техаський холдем, Гра в вовка тощо.
Докази результатів одноразових ігор, таких як лотерея, вгадування чисел, камінь-ножиці-папір тощо.
Варто зазначити, що через складність технології zk-SNARKs, аналіз і висновки цієї статті можуть мати певні обмеження. Ми сподіваємося, що більше фахівців глибше обговорять цю тему, щоб надати більше інноваційних ідей для розвитку повноцінних ігор.