原标题: Як я навчився перестати хвилюватися та любити уцію Sharding
Посилання на відео:
Спікер: Скотт Сунарто (@smsunarto) у День досліджень
Редагування та обробка статті: Джастін Чжао (@hiCaptainZ)
Привіт, я Скотт (@smsunarto), засновник August Labs (@ArgusLabs_). Сьогодні я збираюся поговорити про тему, якої ми давно не торкалися. Оскільки зведення стає мейнстрімом часу, ми обговорюємо не стільки сегментування виконання, скільки сегментування даних. Отже, давайте повернемося до цієї дещо занедбаної теми – сегментування виконання.
Це буде легка розмова. Я знаю, що ви чули складні концепції цілий день, тому я спробую зробити це обговорення максимально практичним. Для цієї презентації я підготував відповідний дизайн слайда.
Для тих, хто мене не знає, смішно те, що в Твіттері я відома як аніме-дівчина. Я також пропустив закінчення коледжу лише заради того, щоб бути тут, на превеликий розчарування моїх батьків. Зараз я є засновником Argus Labs. Ми вважаємо себе ігровою компанією, а не інфраструктурною чи криптовалютною компанією. Одне з моїх найбільших роздратувань полягає в тому, що всі в криптоіграх хочуть створювати інструменти, але ніхто не хоче створювати контент або програми. Нам потрібно більше додатків, якими користувачі могли б реально користуватися.
Раніше я створив Dark Forest (@darkforest_eth) разом зі своїми розумними друзями Брайаном Гу (@gubsheep) і Аланом Луо (@alanluo_0). Зараз Брайан використовує 0xPARC (@0xPARC), і він набагато розумніший за мене.
Сьогоднішнє обговорення буде зосереджено на виконанні шардингу, але в контексті більшість людей не знайомі з обговоренням виконання шардингу. Зазвичай ми обговорюємо сегментування виконання в контексті Рівня 1, наприклад шардинг Ethereum або шардинг Near. Але сьогодні я хочу трохи змінити контекст. Давайте подумаємо про те, як шардинг виглядав би в згорнутому середовищі.
Головне питання тут полягає в тому, навіщо ігровій компанії створювати власний згорнутий пакет і чого ми можемо навчитися в World of Warcraft, щоб розробити зведений додаток. Крім того, ми дослідимо, як простір дизайну для згорнутих пакетів виходить далеко за межі поточних реалій.
Щоб відповісти на ці питання, повернемося в 2020 рік, коли вперше виникла ідея Темного лісу. Ми запитали себе, а що, якби ми створили гру, у якій кожна ігрова дія була транзакцією в ланцюжку? Тоді ця передумова була смішною, і вона залишається для багатьох людей сьогодні. Але це була цікава гіпотеза, тому ми створили її, і народився Темний ліс.
Dark Forest — це повна ланцюжкова гра MMORTS для дослідження космосу, яка повністю базується на Ethereum і підтримується ZK-Snarks. У 2020 році ЗК не був таким популярним, як сьогодні, тому що документації майже не було. Єдина доступна документація для Circom – це Google Docs Jordi Baylina (@jbaylina). Незважаючи на труднощі, ми багато чому навчилися на цьому шляху, і Dark Forest є втіленням цих знань.
Dark Forest — це більший експеримент, ніж ми думали. У нас понад 10 000 гравців, витрачено трильйони газу, хаос у грі, люди б’ють ножем у спину на ланцюзі. Найбільш захоплююча річ у Dark Forest та мережевих іграх — це платформа. Маючи гру з повним ланцюгом, ви відкриваєте двері в простір дизайну для нової поведінки, дозволяючи людям створювати смарт-контракти, які взаємодіють з грою, а також альтернативні клієнти та ігрові режими, такі як Dark Forest Arena і GPU-майнери.
Однак із великою владою приходить велика відповідальність. Коли ми запустили Dark Forest на xDai, тепер відомий як Gnosis Chain, ми заповнили весь блоковий простір ланцюжка. Це робить ланцюжок практично непридатним для будь-чого іншого, включаючи DeFi, NFT або будь-які інші речі xDAI.
І що тепер? Ми зайшли в глухий кут? Повноланцюгові ігри ніколи не стануть реальністю? Або ми повернемося до створення ігор, де лише маленькі зображення JPEG будуть включені в мережу, і переконаємо людей, що гроші ростуть на деревах? Відповідь: ми дозволяємо програмному забезпеченню робити щось. Багато з нас мають дуже жорстке уявлення про блокчейн і згортання, начебто немає місця для вдосконалення. Але я не згоден. Ми можемо експериментувати та знаходити нові можливості.
Ми поставили собі запитання: якби ми створили з нуля блокчейн для ігор і тільки для ігор, як би це виглядало? Нам потрібна висока пропускна здатність, тому нам потрібно масштабувати читання та запис. Більшість блокчейнів створені для інтенсивного запису. Кількість транзакцій за секунду (TPS) — це показник, яким люди хваляться, але насправді читання не менш важливі. Як дізнатися, де знаходиться гравець, якщо ви не можете читати з блокчейн-вузла? Насправді це перше вузьке місце, яке ми знайшли в побудові блокчейну.
У Dark Forest є проблема, коли повні вузли активно використовуються, а введення/виведення вибухає, тому що нам потрібно зчитувати дані зі стану on-chain. Це призвело до витрат на сервер у тисячі доларів, які щедро покрила команда xDAI. Однак це не ідеально для довгострокової перспективи. Нам потрібна висока пропускна здатність не лише для транзакцій, що записуються за секунду, але й для читання, наприклад отримання даних із самого блокчейну.
Нам також потрібен горизонтально масштабований блокчейн, щоб уникнути проблеми шумного сусіда. Ми не хочемо, щоб популярна гра раптово почала давати збої в блокчейні, зупиняючи всю роботу. Нам також потрібна гнучкість і можливість налаштування, щоб ми могли модифікувати кінцевий автомат, розроблений для гри. Це включає наявність циклу гри, її самовиконання тощо.
І останнє, але не менш важливе: для тих, хто не знайомий з архітектурою онлайн-ігор, це може бути трохи розпливчастим, нам потрібен високий тікрейт. Тики — це атомарна одиниця часу в ігровому світі. У контексті блокчейнів ми маємо блоки як атомарні одиниці часу. В іграх ми маємо галочки. Це майже так само, коли ви створюєте гру з повним ланцюгом, де швидкість генерації тиків або блоків у вашому блокчейні дорівнює тикам самої гри.
Тому нам потрібен блокчейн із високою пропускною спроможністю, горизонтальною масштабованістю, гнучкістю та можливістю налаштування, а також високою частотою тіків. Такий дизайн може задовольнити потреби блокчейну, який ми розробили з нуля для гри.
Якщо у вас вищий показник тиків або більше блоків на секунду, гра буде сприйнятливішою. І навпаки, якщо ваш тик-рейт низький, гра буде повільною. Одна ключова річ, про яку слід пам’ятати, полягає в тому, що якщо блоки затримуються, ви відчуєте помітне відставання в грі. Це поганий досвід. Якщо ви коли-небудь мали справу з розлюченими гравцями, які кричали на комп’ютер за програш у грі, це абсолютно жахлива ситуація.
Наразі наші зведення мають один блок на секунду, що еквівалентно одному тику. Якщо ми хочемо мати крутіші ігри, нам потрібні вищі показники тику. Наприклад, Minecraft, проста піксельна гра, має 26 тиків на секунду. Ми ще далекі від створення такої швидкої гри, як Minecraft.
Можливим рішенням є розгортання нашого власного зведення. Хоча здається, що це вирішує проблему, насправді це не усуває першопричину проблеми. Наприклад, ви матимете вищу пропускну здатність запису, але не зовсім до рівня, який потрібен іграм. Звичайно, якщо у вашій грі сто гравців, цього буде достатньо. Однак, якщо ви хочете створити гру, яка потребує вищої пропускної здатності, існують дуже суворі обмеження через те, як виконується введення-виведення в поточній збірці.
З боку читання ви не отримаєте приросту продуктивності. Ви все ще повинні покладатися на індексатори. У вас насправді немає горизонтальної масштабованості. Якщо ви спробуєте запустити нове зведення для горизонтального масштабування гри, ви зруйнуєте існуючу екосистему смарт-контрактів. Торгові майданчики, які розгортають гравці, не працюватимуть з іншими мережами, які ви запускаєте для горизонтального масштабування гри. Це викликає багато питань.
Нарешті, висока частота тиків і блоків за секунду все ще є певним викликом, хоча ми можемо наполягати на цьому якомога сильніше, ми можемо отримувати два блоки за секунду, можливо, три, але насправді це те, як ці блокчейни рухаються. найдальше, тому що є купа речей, як-от повторне сортування, які значною мірою залежать від обчислювальних циклів.
Щоб відповісти на це питання, ми повернемося до початку 2000-х і кінця 1990-х років, коли онлайн-ігри, такі як MMO, тільки з’являлися. У них є концепція шардингу. Це не нова концепція, вона існувала в минулому. Слово «шардинг», яке ми використовуємо в архітектурі баз даних, насправді походить від посилання на Ultima Online. Вони були першими, хто використав слово «шард» для пояснення своїх різних серверів.
Отже, як працює шардинг в іграх? Це не універсальне рішення. Це інструмент у наборі інструментів, і те, як ви адаптуєте його до своєї гри, залежить від випадку до випадку. Наприклад, першу структуру сегментування я люблю називати сегментуванням на основі розташування. Хороша ментальна модель полягає в тому, щоб уявити декартову систему координат, поділену на чотири квадранти, кожен зі своїм власним ігровим сегментом. Кожного разу, коли ви хочете пройти через шард, ви надсилаєте повідомлення іншому шарду з фразою «привіт, я хочу перейти туди», і вас телепортують до вашого шарду, залишаючи гравців перед вашим тілом. Роблячи це, ви розподіляєте робоче навантаження сервера між кількома фізичними примірниками, а не змушуєте один сервер виконувати всі обчислення для всього ігрового світу. Друга конфігурація зараз більш популярна. Це називається шардинг мультивсесвіту, коли у вас є кілька екземплярів гри, які віддзеркалюють один одного. Ви можете вибрати будь-який сегмент, до якого хочете перейти, і за замовчуванням він збалансований навантаженням, щоб кожен сервер не був переповнений.
Тепер ключове питання полягає в тому, як довести цю концепцію до зведення? Ось чому ми створили World Engine. World Engine — це наша флагманська інфраструктура, по суті, самовпевнений сортувальник сегментів, розроблений для стартапів. Наш інший і краще відповідає нашим потребам, ніж багато інших сортувальників сегментів, які ми бачили в останніх кількох дискусіях. Напрямок нашої оптимізації: A, пропускна здатність, B, ми хочемо переконатися, що немає блокувань, які блокують час виконання, щоб гарантувати, що частота тактів і час блокування є максимально ефективними, тому за замовчуванням це синхронно, шлях ми розробляємо сортувальник часткового сортування, а не примусового повного впорядкування (кожна транзакція має відбуватися після іншої).
Ключовими компонентами тут є те, що ми маємо дві основні речі. У нас є шардинг на основі EVM, який схожий на чистий ланцюг EVM, на якому гравці можуть розгортати смарт-контракти, поєднувати з іграми, створювати ринки з податками тощо. Це як звичайний ланцюг, чи не так? Щось на кшталт одного блоку в секунду чи щось подібне, цього достатньо, щоб ви могли використовувати всі свої типові пристрої та ринки.
Секретний інгредієнт тут полягає в тому, що ми також використовуємо ігровий сегмент, який, по суті, є міні-блокчейном, розробленим як високопродуктивний ігровий сервер. У нас є інтерфейс впровадження, щоб ви могли налаштувати цей сегмент на свій смак. Ви можете створювати власні осколки та вводити їх у базовий шард. Вам потрібно лише реалізувати набір стандартних інтерфейсів, так само, як Cosmos, з яким ви знайомі, Cosmos має інтерфейс ABC. По суті, ви можете об’єднати це в схожу специфікацію, додавши власні шарди до стеку World Engine.
Ключовим моментом тут є те, що ми маємо високий рівень тику, якого ми зараз не можемо досягти за допомогою поточної конструкції сегментування. Тут я хочу представити кардинала. Cardinal — це перша реалізація ігрового шардингу World Engine. Він використовує Entity-Component-System (ECS) з орієнтованою на дані архітектурою. Це дозволяє розпаралелити гру та збільшити пропускну здатність ігрових обчислень. Він має настроювану швидкість до 20 тактів на секунду. Для людей, які займаються блокчейном, це 20 блоків на секунду.
Ми також можемо геолокувати його, щоб зменшити затримку. Наприклад, у вас може бути сортувальник у США, а азіатам доведеться чекати 300 мілісекунд, поки транзакція досягне сортувальника. Це величезна проблема в іграх, тому що 300 мс — це довго. Якщо ви спробуєте зіграти в FPS із затримкою в 200 мс, ви, по суті, мертві.
Ще один ключовий момент, який також важливий для нас, — це самоіндексація. Нам більше не потрібні зовнішні індексатори. Нам не потрібні ці фреймворки для кешування стану гри. Це також дозволяє нам створювати більше ігор у реальному часі без проблем із затримкою, оскільки індексатор усе ще намагається наздогнати блоки сортувальника.
У нас також є система плагінів, яка дозволяє людям розпаралелювати перевірку ZK тощо. Найкраще, принаймні для мене, це те, що ви можете написати свій код у Go. Більше не потрібно використовувати Solidity, щоб ваша гра працювала. Якщо ви коли-небудь намагалися створити блокчейн-гру за допомогою Solidity, це був кошмар.
Однак ключовим моментом нашої шард-конструкції є те, що ви можете створити будь-що як шард. Вони схожі на нескінченний дизайнерський простір, яким може бути шард.
Якщо припустити, що вам не подобається писати код гри в Go, ви можете вибрати інші способи. Однак ми працюємо над ігровим фрагментом Solidity, який дозволить вам реалізовувати ігри в Solidity таким чином, щоб надавати можливості програмування, зберігаючи при цьому багато переваг Cardinal. Ви також можете створити карбований шард NFT з унікальною конструкцією mempool і порядку, вирішуючи проблему Noisy Neighbor, подібно до базового карбування. Ви навіть можете створити шард ідентифікаційної інформації гри та використовувати NFT для представлення вашої ідентифікаційної інформації гри, щоб ви могли легко проводити транзакції ідентифікаційної інформації гри через NFT замість того, щоб ділитися особистими ключами.
Це високорівнева архітектура, і я не буду вдаватися в подробиці сьогодні через обмеження часу. Важливо те, що ми дозволяємо поєднувати смарт-контракти EVM з ігровими шардами за допомогою спеціального вибору та передачі. Ми створили обгортку навколо Geth, щоб забезпечити спілкування між ними, що відкриває багато простору для дизайну в обох напрямках. Ми синхронні за замовчуванням і можемо плавно взаємодіяти між шардами без блокувань.
Наш спільний сортувальник відрізняється тим, що він не використовує конструкцію спільної послідовності атомарних зв’язків, які надають пріоритет глобальному сортуванню, що вимагає механізму блокування та спричиняє проблеми, як-от блокування основного потоку, що призводить до нестабільної швидкості тактів і часу блокування, а результатом є відставання в грі. Він також накладає обмеження на час блокування кожного фрагмента та вимагає різноманітних криптоекономічних засобів і конструкцій для запобігання відмові в обслуговуванні. Існує також велика проблема, про яку я не згадував у багатьох конструкціях сортувальника відеомагнітофонів: якщо у вас є різні фрагменти, які залежать один від одного та спричиняють взаємоблокування, як її вирішити? З асинхронним дизайном це не проблема, тому що кожен робить те, що хоче робити, а потім відпускає це.
Насправді, атомарні пучки та згортання по осколках зазвичай не потрібні. Для нашого сценарію використання нам не потрібно нічого, що вимагає атомних променів, і ми не вважаємо, що це те, що ми повинні розробляти наші зведені версії відповідно до чистоти варіантів використання. Це також приносить багато інших цікавих функцій. Наприклад, кожен шард гри може мати окремий рівень DA для базового ланцюжка. Наприклад, ви можете використовувати базовий шард для надсилання даних до Ethereum, а ігровий сегмент може надсилати дані до Celestia (подібно до комітету доступності даних). Ви також можете зменшити вимоги до апаратного забезпечення для запуску повного вузла, оскільки ви можете запустити повний вузол базового шарда Geth окремо, не запускаючи вузол сегмента гри, що полегшує вам інтеграцію з такими речами, як Alchemy.
Підводячи підсумок, я хочу бути відвертим, що багато людей очікують, що їхні конструкції вирішать усі їхні проблеми, але ми цього не робимо. Ми вважаємо, що наша конструкція працює для нас, але вона може не працювати для вашого випадку використання. Нереалістично припустити, що наші конструкції працюватимуть для всіх. Для нас це відповідає нашим потребам, забезпечує високу пропускну здатність, горизонтальну масштабованість, гнучкість і високу кількість тиків, але це не ліки від раку. Якщо вам потрібен протокол DeFi, який вимагає синхронної компонування, ця конструкція може вам не підійти.
Загалом, я дійсно вірю в концепцію орієнтованої на людину архітектури блокчейну. Розробляючи конкретні ролі користувачів і випадки використання, ви зможете краще знаходити компроміси, а не намагатися вирішити проблеми кожного. Настала епоха Відродження, і кожен може розробити власні Roll-Ups відповідно до власних потреб, замість того, щоб покладатися на загальне рішення. Я думаю, що ми повинні прийняти Кембрійський вибух. Не створюйте згортання, подібні до першого шару, з універсальними засобами, оскільки вони зовсім не призначені для вирішення тієї самої проблеми. Особисто я з нетерпінням чекаю, коли більше людей дослідять більше простору дизайну Roll-Up для випадків використання. Наприклад, як би виглядав Roll-up, спеціально розроблений для обміну активами? Чи базуватиметься це на намірі? Як би виглядав Roll-up, спеціально розроблений для CLOB (Центральна книга лімітних ордерів) у мережі? Тут я передаю мікрофон MJ. Дякуємо за запрошення.
Англійська версія:
Переглянути оригінал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Чому Argus використовує шардинг для створення повної ігрової інфраструктури?
原标题: Як я навчився перестати хвилюватися та любити уцію Sharding
Посилання на відео:
Спікер: Скотт Сунарто (@smsunarto) у День досліджень
Редагування та обробка статті: Джастін Чжао (@hiCaptainZ)
Привіт, я Скотт (@smsunarto), засновник August Labs (@ArgusLabs_). Сьогодні я збираюся поговорити про тему, якої ми давно не торкалися. Оскільки зведення стає мейнстрімом часу, ми обговорюємо не стільки сегментування виконання, скільки сегментування даних. Отже, давайте повернемося до цієї дещо занедбаної теми – сегментування виконання.
Це буде легка розмова. Я знаю, що ви чули складні концепції цілий день, тому я спробую зробити це обговорення максимально практичним. Для цієї презентації я підготував відповідний дизайн слайда.
Для тих, хто мене не знає, смішно те, що в Твіттері я відома як аніме-дівчина. Я також пропустив закінчення коледжу лише заради того, щоб бути тут, на превеликий розчарування моїх батьків. Зараз я є засновником Argus Labs. Ми вважаємо себе ігровою компанією, а не інфраструктурною чи криптовалютною компанією. Одне з моїх найбільших роздратувань полягає в тому, що всі в криптоіграх хочуть створювати інструменти, але ніхто не хоче створювати контент або програми. Нам потрібно більше додатків, якими користувачі могли б реально користуватися.
Раніше я створив Dark Forest (@darkforest_eth) разом зі своїми розумними друзями Брайаном Гу (@gubsheep) і Аланом Луо (@alanluo_0). Зараз Брайан використовує 0xPARC (@0xPARC), і він набагато розумніший за мене.
Сьогоднішнє обговорення буде зосереджено на виконанні шардингу, але в контексті більшість людей не знайомі з обговоренням виконання шардингу. Зазвичай ми обговорюємо сегментування виконання в контексті Рівня 1, наприклад шардинг Ethereum або шардинг Near. Але сьогодні я хочу трохи змінити контекст. Давайте подумаємо про те, як шардинг виглядав би в згорнутому середовищі.
Головне питання тут полягає в тому, навіщо ігровій компанії створювати власний згорнутий пакет і чого ми можемо навчитися в World of Warcraft, щоб розробити зведений додаток. Крім того, ми дослідимо, як простір дизайну для згорнутих пакетів виходить далеко за межі поточних реалій.
Щоб відповісти на ці питання, повернемося в 2020 рік, коли вперше виникла ідея Темного лісу. Ми запитали себе, а що, якби ми створили гру, у якій кожна ігрова дія була транзакцією в ланцюжку? Тоді ця передумова була смішною, і вона залишається для багатьох людей сьогодні. Але це була цікава гіпотеза, тому ми створили її, і народився Темний ліс.
Dark Forest — це повна ланцюжкова гра MMORTS для дослідження космосу, яка повністю базується на Ethereum і підтримується ZK-Snarks. У 2020 році ЗК не був таким популярним, як сьогодні, тому що документації майже не було. Єдина доступна документація для Circom – це Google Docs Jordi Baylina (@jbaylina). Незважаючи на труднощі, ми багато чому навчилися на цьому шляху, і Dark Forest є втіленням цих знань.
Dark Forest — це більший експеримент, ніж ми думали. У нас понад 10 000 гравців, витрачено трильйони газу, хаос у грі, люди б’ють ножем у спину на ланцюзі. Найбільш захоплююча річ у Dark Forest та мережевих іграх — це платформа. Маючи гру з повним ланцюгом, ви відкриваєте двері в простір дизайну для нової поведінки, дозволяючи людям створювати смарт-контракти, які взаємодіють з грою, а також альтернативні клієнти та ігрові режими, такі як Dark Forest Arena і GPU-майнери.
Однак із великою владою приходить велика відповідальність. Коли ми запустили Dark Forest на xDai, тепер відомий як Gnosis Chain, ми заповнили весь блоковий простір ланцюжка. Це робить ланцюжок практично непридатним для будь-чого іншого, включаючи DeFi, NFT або будь-які інші речі xDAI.
І що тепер? Ми зайшли в глухий кут? Повноланцюгові ігри ніколи не стануть реальністю? Або ми повернемося до створення ігор, де лише маленькі зображення JPEG будуть включені в мережу, і переконаємо людей, що гроші ростуть на деревах? Відповідь: ми дозволяємо програмному забезпеченню робити щось. Багато з нас мають дуже жорстке уявлення про блокчейн і згортання, начебто немає місця для вдосконалення. Але я не згоден. Ми можемо експериментувати та знаходити нові можливості.
Ми поставили собі запитання: якби ми створили з нуля блокчейн для ігор і тільки для ігор, як би це виглядало? Нам потрібна висока пропускна здатність, тому нам потрібно масштабувати читання та запис. Більшість блокчейнів створені для інтенсивного запису. Кількість транзакцій за секунду (TPS) — це показник, яким люди хваляться, але насправді читання не менш важливі. Як дізнатися, де знаходиться гравець, якщо ви не можете читати з блокчейн-вузла? Насправді це перше вузьке місце, яке ми знайшли в побудові блокчейну.
У Dark Forest є проблема, коли повні вузли активно використовуються, а введення/виведення вибухає, тому що нам потрібно зчитувати дані зі стану on-chain. Це призвело до витрат на сервер у тисячі доларів, які щедро покрила команда xDAI. Однак це не ідеально для довгострокової перспективи. Нам потрібна висока пропускна здатність не лише для транзакцій, що записуються за секунду, але й для читання, наприклад отримання даних із самого блокчейну.
Нам також потрібен горизонтально масштабований блокчейн, щоб уникнути проблеми шумного сусіда. Ми не хочемо, щоб популярна гра раптово почала давати збої в блокчейні, зупиняючи всю роботу. Нам також потрібна гнучкість і можливість налаштування, щоб ми могли модифікувати кінцевий автомат, розроблений для гри. Це включає наявність циклу гри, її самовиконання тощо.
І останнє, але не менш важливе: для тих, хто не знайомий з архітектурою онлайн-ігор, це може бути трохи розпливчастим, нам потрібен високий тікрейт. Тики — це атомарна одиниця часу в ігровому світі. У контексті блокчейнів ми маємо блоки як атомарні одиниці часу. В іграх ми маємо галочки. Це майже так само, коли ви створюєте гру з повним ланцюгом, де швидкість генерації тиків або блоків у вашому блокчейні дорівнює тикам самої гри.
Тому нам потрібен блокчейн із високою пропускною спроможністю, горизонтальною масштабованістю, гнучкістю та можливістю налаштування, а також високою частотою тіків. Такий дизайн може задовольнити потреби блокчейну, який ми розробили з нуля для гри.
Якщо у вас вищий показник тиків або більше блоків на секунду, гра буде сприйнятливішою. І навпаки, якщо ваш тик-рейт низький, гра буде повільною. Одна ключова річ, про яку слід пам’ятати, полягає в тому, що якщо блоки затримуються, ви відчуєте помітне відставання в грі. Це поганий досвід. Якщо ви коли-небудь мали справу з розлюченими гравцями, які кричали на комп’ютер за програш у грі, це абсолютно жахлива ситуація.
Наразі наші зведення мають один блок на секунду, що еквівалентно одному тику. Якщо ми хочемо мати крутіші ігри, нам потрібні вищі показники тику. Наприклад, Minecraft, проста піксельна гра, має 26 тиків на секунду. Ми ще далекі від створення такої швидкої гри, як Minecraft.
Можливим рішенням є розгортання нашого власного зведення. Хоча здається, що це вирішує проблему, насправді це не усуває першопричину проблеми. Наприклад, ви матимете вищу пропускну здатність запису, але не зовсім до рівня, який потрібен іграм. Звичайно, якщо у вашій грі сто гравців, цього буде достатньо. Однак, якщо ви хочете створити гру, яка потребує вищої пропускної здатності, існують дуже суворі обмеження через те, як виконується введення-виведення в поточній збірці.
З боку читання ви не отримаєте приросту продуктивності. Ви все ще повинні покладатися на індексатори. У вас насправді немає горизонтальної масштабованості. Якщо ви спробуєте запустити нове зведення для горизонтального масштабування гри, ви зруйнуєте існуючу екосистему смарт-контрактів. Торгові майданчики, які розгортають гравці, не працюватимуть з іншими мережами, які ви запускаєте для горизонтального масштабування гри. Це викликає багато питань.
Нарешті, висока частота тиків і блоків за секунду все ще є певним викликом, хоча ми можемо наполягати на цьому якомога сильніше, ми можемо отримувати два блоки за секунду, можливо, три, але насправді це те, як ці блокчейни рухаються. найдальше, тому що є купа речей, як-от повторне сортування, які значною мірою залежать від обчислювальних циклів.
Щоб відповісти на це питання, ми повернемося до початку 2000-х і кінця 1990-х років, коли онлайн-ігри, такі як MMO, тільки з’являлися. У них є концепція шардингу. Це не нова концепція, вона існувала в минулому. Слово «шардинг», яке ми використовуємо в архітектурі баз даних, насправді походить від посилання на Ultima Online. Вони були першими, хто використав слово «шард» для пояснення своїх різних серверів.
Отже, як працює шардинг в іграх? Це не універсальне рішення. Це інструмент у наборі інструментів, і те, як ви адаптуєте його до своєї гри, залежить від випадку до випадку. Наприклад, першу структуру сегментування я люблю називати сегментуванням на основі розташування. Хороша ментальна модель полягає в тому, щоб уявити декартову систему координат, поділену на чотири квадранти, кожен зі своїм власним ігровим сегментом. Кожного разу, коли ви хочете пройти через шард, ви надсилаєте повідомлення іншому шарду з фразою «привіт, я хочу перейти туди», і вас телепортують до вашого шарду, залишаючи гравців перед вашим тілом. Роблячи це, ви розподіляєте робоче навантаження сервера між кількома фізичними примірниками, а не змушуєте один сервер виконувати всі обчислення для всього ігрового світу. Друга конфігурація зараз більш популярна. Це називається шардинг мультивсесвіту, коли у вас є кілька екземплярів гри, які віддзеркалюють один одного. Ви можете вибрати будь-який сегмент, до якого хочете перейти, і за замовчуванням він збалансований навантаженням, щоб кожен сервер не був переповнений.
Тепер ключове питання полягає в тому, як довести цю концепцію до зведення? Ось чому ми створили World Engine. World Engine — це наша флагманська інфраструктура, по суті, самовпевнений сортувальник сегментів, розроблений для стартапів. Наш інший і краще відповідає нашим потребам, ніж багато інших сортувальників сегментів, які ми бачили в останніх кількох дискусіях. Напрямок нашої оптимізації: A, пропускна здатність, B, ми хочемо переконатися, що немає блокувань, які блокують час виконання, щоб гарантувати, що частота тактів і час блокування є максимально ефективними, тому за замовчуванням це синхронно, шлях ми розробляємо сортувальник часткового сортування, а не примусового повного впорядкування (кожна транзакція має відбуватися після іншої).
Ключовими компонентами тут є те, що ми маємо дві основні речі. У нас є шардинг на основі EVM, який схожий на чистий ланцюг EVM, на якому гравці можуть розгортати смарт-контракти, поєднувати з іграми, створювати ринки з податками тощо. Це як звичайний ланцюг, чи не так? Щось на кшталт одного блоку в секунду чи щось подібне, цього достатньо, щоб ви могли використовувати всі свої типові пристрої та ринки.
Секретний інгредієнт тут полягає в тому, що ми також використовуємо ігровий сегмент, який, по суті, є міні-блокчейном, розробленим як високопродуктивний ігровий сервер. У нас є інтерфейс впровадження, щоб ви могли налаштувати цей сегмент на свій смак. Ви можете створювати власні осколки та вводити їх у базовий шард. Вам потрібно лише реалізувати набір стандартних інтерфейсів, так само, як Cosmos, з яким ви знайомі, Cosmos має інтерфейс ABC. По суті, ви можете об’єднати це в схожу специфікацію, додавши власні шарди до стеку World Engine.
Ключовим моментом тут є те, що ми маємо високий рівень тику, якого ми зараз не можемо досягти за допомогою поточної конструкції сегментування. Тут я хочу представити кардинала. Cardinal — це перша реалізація ігрового шардингу World Engine. Він використовує Entity-Component-System (ECS) з орієнтованою на дані архітектурою. Це дозволяє розпаралелити гру та збільшити пропускну здатність ігрових обчислень. Він має настроювану швидкість до 20 тактів на секунду. Для людей, які займаються блокчейном, це 20 блоків на секунду.
Ми також можемо геолокувати його, щоб зменшити затримку. Наприклад, у вас може бути сортувальник у США, а азіатам доведеться чекати 300 мілісекунд, поки транзакція досягне сортувальника. Це величезна проблема в іграх, тому що 300 мс — це довго. Якщо ви спробуєте зіграти в FPS із затримкою в 200 мс, ви, по суті, мертві.
Ще один ключовий момент, який також важливий для нас, — це самоіндексація. Нам більше не потрібні зовнішні індексатори. Нам не потрібні ці фреймворки для кешування стану гри. Це також дозволяє нам створювати більше ігор у реальному часі без проблем із затримкою, оскільки індексатор усе ще намагається наздогнати блоки сортувальника.
У нас також є система плагінів, яка дозволяє людям розпаралелювати перевірку ZK тощо. Найкраще, принаймні для мене, це те, що ви можете написати свій код у Go. Більше не потрібно використовувати Solidity, щоб ваша гра працювала. Якщо ви коли-небудь намагалися створити блокчейн-гру за допомогою Solidity, це був кошмар.
Однак ключовим моментом нашої шард-конструкції є те, що ви можете створити будь-що як шард. Вони схожі на нескінченний дизайнерський простір, яким може бути шард.
Якщо припустити, що вам не подобається писати код гри в Go, ви можете вибрати інші способи. Однак ми працюємо над ігровим фрагментом Solidity, який дозволить вам реалізовувати ігри в Solidity таким чином, щоб надавати можливості програмування, зберігаючи при цьому багато переваг Cardinal. Ви також можете створити карбований шард NFT з унікальною конструкцією mempool і порядку, вирішуючи проблему Noisy Neighbor, подібно до базового карбування. Ви навіть можете створити шард ідентифікаційної інформації гри та використовувати NFT для представлення вашої ідентифікаційної інформації гри, щоб ви могли легко проводити транзакції ідентифікаційної інформації гри через NFT замість того, щоб ділитися особистими ключами.
Це високорівнева архітектура, і я не буду вдаватися в подробиці сьогодні через обмеження часу. Важливо те, що ми дозволяємо поєднувати смарт-контракти EVM з ігровими шардами за допомогою спеціального вибору та передачі. Ми створили обгортку навколо Geth, щоб забезпечити спілкування між ними, що відкриває багато простору для дизайну в обох напрямках. Ми синхронні за замовчуванням і можемо плавно взаємодіяти між шардами без блокувань.
Наш спільний сортувальник відрізняється тим, що він не використовує конструкцію спільної послідовності атомарних зв’язків, які надають пріоритет глобальному сортуванню, що вимагає механізму блокування та спричиняє проблеми, як-от блокування основного потоку, що призводить до нестабільної швидкості тактів і часу блокування, а результатом є відставання в грі. Він також накладає обмеження на час блокування кожного фрагмента та вимагає різноманітних криптоекономічних засобів і конструкцій для запобігання відмові в обслуговуванні. Існує також велика проблема, про яку я не згадував у багатьох конструкціях сортувальника відеомагнітофонів: якщо у вас є різні фрагменти, які залежать один від одного та спричиняють взаємоблокування, як її вирішити? З асинхронним дизайном це не проблема, тому що кожен робить те, що хоче робити, а потім відпускає це.
Насправді, атомарні пучки та згортання по осколках зазвичай не потрібні. Для нашого сценарію використання нам не потрібно нічого, що вимагає атомних променів, і ми не вважаємо, що це те, що ми повинні розробляти наші зведені версії відповідно до чистоти варіантів використання. Це також приносить багато інших цікавих функцій. Наприклад, кожен шард гри може мати окремий рівень DA для базового ланцюжка. Наприклад, ви можете використовувати базовий шард для надсилання даних до Ethereum, а ігровий сегмент може надсилати дані до Celestia (подібно до комітету доступності даних). Ви також можете зменшити вимоги до апаратного забезпечення для запуску повного вузла, оскільки ви можете запустити повний вузол базового шарда Geth окремо, не запускаючи вузол сегмента гри, що полегшує вам інтеграцію з такими речами, як Alchemy.
Підводячи підсумок, я хочу бути відвертим, що багато людей очікують, що їхні конструкції вирішать усі їхні проблеми, але ми цього не робимо. Ми вважаємо, що наша конструкція працює для нас, але вона може не працювати для вашого випадку використання. Нереалістично припустити, що наші конструкції працюватимуть для всіх. Для нас це відповідає нашим потребам, забезпечує високу пропускну здатність, горизонтальну масштабованість, гнучкість і високу кількість тиків, але це не ліки від раку. Якщо вам потрібен протокол DeFi, який вимагає синхронної компонування, ця конструкція може вам не підійти.
Загалом, я дійсно вірю в концепцію орієнтованої на людину архітектури блокчейну. Розробляючи конкретні ролі користувачів і випадки використання, ви зможете краще знаходити компроміси, а не намагатися вирішити проблеми кожного. Настала епоха Відродження, і кожен може розробити власні Roll-Ups відповідно до власних потреб, замість того, щоб покладатися на загальне рішення. Я думаю, що ми повинні прийняти Кембрійський вибух. Не створюйте згортання, подібні до першого шару, з універсальними засобами, оскільки вони зовсім не призначені для вирішення тієї самої проблеми. Особисто я з нетерпінням чекаю, коли більше людей дослідять більше простору дизайну Roll-Up для випадків використання. Наприклад, як би виглядав Roll-up, спеціально розроблений для обміну активами? Чи базуватиметься це на намірі? Як би виглядав Roll-up, спеціально розроблений для CLOB (Центральна книга лімітних ордерів) у мережі? Тут я передаю мікрофон MJ. Дякуємо за запрошення.
Англійська версія: