原标题: Как я научился перестать беспокоиться и полюбить ution Sharding
Ссылка на видео:
Спикер: Скотт Сунарто (@smsunarto) в День исследования
Редактирование и окончание статьи: Джастин Чжао (@hiCaptainZ)
Привет, я Скотт (@smsunarto), основатель August Labs (@ArgusLabs_). Сегодня я хочу поговорить о теме, которую мы давно не затрагивали. Поскольку свертки становятся мейнстримом, мы не столько обсуждаем сегментацию выполнения, сколько сегментацию данных. Итак, давайте вернемся к этой несколько забытой теме — шардингу исполнения.
Это будет легкий разговор. Я знаю, что вы весь день слышали о сложных концепциях, поэтому я постараюсь сделать это обсуждение максимально практичным. Я подготовил подходящий дизайн слайдов для этой презентации.
Для тех, кто меня не знает, самое забавное, что в Твиттере я известен как девушка-аниме. Я также пропустил выпускной в колледже только для того, чтобы быть здесь, к большому разочарованию моих родителей. В настоящее время я являюсь основателем Argus Labs. Мы видим себя игровой компанией, а не инфраструктурной или криптовалютной компанией. Одна из моих самых больших проблем заключается в том, что все в крипто-играх хотят создавать инструменты, но никто не хочет создавать контент или приложения. Нам нужно больше приложений, которые пользователи могут использовать.
Ранее я создал Dark Forest (@darkforest_eth) вместе со своими умными друзьями Брайаном Гу (@gubsheep) и Аланом Луо (@alanluo_0). Сейчас у Брайана 0xPARC (@0xPARC), и он намного умнее меня.
Сегодняшнее обсуждение будет сосредоточено на выполнении сегментирования, но в контексте, в котором большинство людей не знакомы с обсуждением выполнения сегментирования. Обычно мы обсуждаем сегментирование выполнения в контексте уровня 1, например, сегментирование Ethereum или близкое сегментирование. Но сегодня я хочу немного изменить контекст. Давайте подумаем, как будет выглядеть сегментирование в среде свертки.
Основной вопрос здесь заключается в том, зачем игровой компании создавать собственный накопительный пакет и чему мы можем научиться у World of Warcraft при разработке накопительных пакетов. Кроме того, мы изучим, как пространство для проектирования свертывания выходит далеко за рамки текущих реалий.
Чтобы ответить на эти вопросы, вернемся в 2020 год, когда впервые зародилась идея Сумрачного леса. Мы спросили себя, что, если мы создадим игру, в которой каждое игровое действие будет транзакцией в сети? Предпосылка была смешной тогда, и она остается для многих людей сегодня. Но это была интересная гипотеза, поэтому мы ее построили, и так родился Dark Forest.
Dark Forest — полномасштабная MMORTS-игра по исследованию космоса, полностью основанная на Ethereum и поддерживаемая ZK-Snarks. Еще в 2020 году ZK не был так популярен, как сегодня, потому что документации практически не было. Единственная доступная документация для Circom — это Документы Google Джорди Байлины (@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 есть проблема, связанная с интенсивным использованием полных узлов и взрывным вводом-выводом, потому что нам нужно считывать данные из состояния в цепочке. Это привело к тысячам долларов на серверные расходы, которые были щедро покрыты для нас командой 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 с уникальным мемпулом и конструкцией упорядочения, решив проблему шумного соседа, аналогичную базовой чеканке. Вы даже можете создать сегмент игрового удостоверения и использовать NFT для представления своего игрового удостоверения, чтобы вы могли легко проводить транзакции с игровым удостоверением через NFT вместо совместного использования закрытых ключей.
Это высокоуровневая архитектура, и сегодня я не буду вдаваться в подробности из-за нехватки времени. Важно отметить, что мы позволяем комбинировать смарт-контракты EVM с игровыми осколками с помощью пользовательского выбора и передачи. Мы создали оболочку вокруг Geth, чтобы обеспечить связь между ними, что открывает много пространства для дизайна в обоих направлениях. Мы синхронны по умолчанию и можем беспрепятственно взаимодействовать между осколками без блокировок.
Наш общий сортировщик отличается тем, что он не использует конструкцию общей последовательности атомарных пакетов, которая отдает приоритет глобальной сортировке, что требует механизма блокировки и вызывает такие проблемы, как блокировка основного потока, что приводит к неустойчивой частоте тактов и времени блокировки, и результат отставание в игре. Он также накладывает ограничения на время блока для каждого сегмента и требует использования различных криптоэкономических методов и конструкций для предотвращения отказа в обслуживании. Есть также большая проблема, о которой я не встречал упоминаний во многих конструкциях сортировщиков VCR: если у вас есть разные осколки, которые зависят друг от друга и вызывают тупиковые ситуации, как вы решаете ее? С асинхронным дизайном это не проблема, потому что каждый делает то, что хочет, а потом отпускает.
На самом деле атомарные лучи и свертывания по осколкам обычно не нужны. Для нашего варианта использования нам не нужно ничего, что требует атомных лучей, и мы не думаем, что это то, что мы должны разрабатывать наши Roll-Ups с учетом чистоты вариантов использования. Это также приносит много других интересных функций. Например, у каждого игрового сегмента может быть отдельный уровень DA для базовой цепочки. Например, вы можете использовать базовый осколок для передачи данных в Ethereum, а игровой осколок может отправлять данные в Celestia (аналогично комитету доступности данных). Вы также можете снизить требования к оборудованию для запуска полного узла, поскольку вы можете запускать полный узел базового сегмента Geth отдельно, не запуская узел игрового сегмента, что упрощает интеграцию с такими вещами, как Alchemy.
Подводя итог, я хочу быть честным здесь, что многие люди ожидают, что их конструкции решат все их проблемы, но мы этого не делаем. Мы думаем, что наша конструкция работает для нас, но может не сработать для вашего варианта использования. Нереально предполагать, что наши конструкции будут работать для всех. Для нас это соответствовало нашим потребностям, предлагая высокую пропускную способность, горизонтальную масштабируемость, гибкость и высокую частоту тиков, но это не было лекарством от рака. Если вам нужен протокол DeFi, требующий синхронной компоновки, то эта конструкция может вам не подойти.
В целом, я действительно верю в концепцию ориентированной на человека архитектуры блокчейна. Разрабатывая дизайн с учетом конкретных ролей пользователей и вариантов использования, вы можете лучше находить компромиссы, а не пытаться решить проблемы всех. Наступила эпоха возрождения, и каждый может создавать свои собственные устройства Roll-Up в соответствии со своими конкретными потребностями, вместо того чтобы полагаться на общее решение. Я думаю, мы должны принять кембрийский взрыв. Не создавайте свертывания, такие как первый слой, с одним размером для всех, потому что он вообще не предназначен для решения одной и той же проблемы. Я лично с нетерпением жду, когда больше людей исследуют больше пространства дизайна 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 использует сегментирование для построения игровой инфраструктуры с полной цепочкой?
原标题: Как я научился перестать беспокоиться и полюбить ution Sharding
Ссылка на видео:
Спикер: Скотт Сунарто (@smsunarto) в День исследования
Редактирование и окончание статьи: Джастин Чжао (@hiCaptainZ)
Привет, я Скотт (@smsunarto), основатель August Labs (@ArgusLabs_). Сегодня я хочу поговорить о теме, которую мы давно не затрагивали. Поскольку свертки становятся мейнстримом, мы не столько обсуждаем сегментацию выполнения, сколько сегментацию данных. Итак, давайте вернемся к этой несколько забытой теме — шардингу исполнения.
Это будет легкий разговор. Я знаю, что вы весь день слышали о сложных концепциях, поэтому я постараюсь сделать это обсуждение максимально практичным. Я подготовил подходящий дизайн слайдов для этой презентации.
Для тех, кто меня не знает, самое забавное, что в Твиттере я известен как девушка-аниме. Я также пропустил выпускной в колледже только для того, чтобы быть здесь, к большому разочарованию моих родителей. В настоящее время я являюсь основателем Argus Labs. Мы видим себя игровой компанией, а не инфраструктурной или криптовалютной компанией. Одна из моих самых больших проблем заключается в том, что все в крипто-играх хотят создавать инструменты, но никто не хочет создавать контент или приложения. Нам нужно больше приложений, которые пользователи могут использовать.
Ранее я создал Dark Forest (@darkforest_eth) вместе со своими умными друзьями Брайаном Гу (@gubsheep) и Аланом Луо (@alanluo_0). Сейчас у Брайана 0xPARC (@0xPARC), и он намного умнее меня.
Сегодняшнее обсуждение будет сосредоточено на выполнении сегментирования, но в контексте, в котором большинство людей не знакомы с обсуждением выполнения сегментирования. Обычно мы обсуждаем сегментирование выполнения в контексте уровня 1, например, сегментирование Ethereum или близкое сегментирование. Но сегодня я хочу немного изменить контекст. Давайте подумаем, как будет выглядеть сегментирование в среде свертки.
Основной вопрос здесь заключается в том, зачем игровой компании создавать собственный накопительный пакет и чему мы можем научиться у World of Warcraft при разработке накопительных пакетов. Кроме того, мы изучим, как пространство для проектирования свертывания выходит далеко за рамки текущих реалий.
Чтобы ответить на эти вопросы, вернемся в 2020 год, когда впервые зародилась идея Сумрачного леса. Мы спросили себя, что, если мы создадим игру, в которой каждое игровое действие будет транзакцией в сети? Предпосылка была смешной тогда, и она остается для многих людей сегодня. Но это была интересная гипотеза, поэтому мы ее построили, и так родился Dark Forest.
Dark Forest — полномасштабная MMORTS-игра по исследованию космоса, полностью основанная на Ethereum и поддерживаемая ZK-Snarks. Еще в 2020 году ZK не был так популярен, как сегодня, потому что документации практически не было. Единственная доступная документация для Circom — это Документы Google Джорди Байлины (@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 есть проблема, связанная с интенсивным использованием полных узлов и взрывным вводом-выводом, потому что нам нужно считывать данные из состояния в цепочке. Это привело к тысячам долларов на серверные расходы, которые были щедро покрыты для нас командой 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 с уникальным мемпулом и конструкцией упорядочения, решив проблему шумного соседа, аналогичную базовой чеканке. Вы даже можете создать сегмент игрового удостоверения и использовать NFT для представления своего игрового удостоверения, чтобы вы могли легко проводить транзакции с игровым удостоверением через NFT вместо совместного использования закрытых ключей.
Это высокоуровневая архитектура, и сегодня я не буду вдаваться в подробности из-за нехватки времени. Важно отметить, что мы позволяем комбинировать смарт-контракты EVM с игровыми осколками с помощью пользовательского выбора и передачи. Мы создали оболочку вокруг Geth, чтобы обеспечить связь между ними, что открывает много пространства для дизайна в обоих направлениях. Мы синхронны по умолчанию и можем беспрепятственно взаимодействовать между осколками без блокировок.
Наш общий сортировщик отличается тем, что он не использует конструкцию общей последовательности атомарных пакетов, которая отдает приоритет глобальной сортировке, что требует механизма блокировки и вызывает такие проблемы, как блокировка основного потока, что приводит к неустойчивой частоте тактов и времени блокировки, и результат отставание в игре. Он также накладывает ограничения на время блока для каждого сегмента и требует использования различных криптоэкономических методов и конструкций для предотвращения отказа в обслуживании. Есть также большая проблема, о которой я не встречал упоминаний во многих конструкциях сортировщиков VCR: если у вас есть разные осколки, которые зависят друг от друга и вызывают тупиковые ситуации, как вы решаете ее? С асинхронным дизайном это не проблема, потому что каждый делает то, что хочет, а потом отпускает.
На самом деле атомарные лучи и свертывания по осколкам обычно не нужны. Для нашего варианта использования нам не нужно ничего, что требует атомных лучей, и мы не думаем, что это то, что мы должны разрабатывать наши Roll-Ups с учетом чистоты вариантов использования. Это также приносит много других интересных функций. Например, у каждого игрового сегмента может быть отдельный уровень DA для базовой цепочки. Например, вы можете использовать базовый осколок для передачи данных в Ethereum, а игровой осколок может отправлять данные в Celestia (аналогично комитету доступности данных). Вы также можете снизить требования к оборудованию для запуска полного узла, поскольку вы можете запускать полный узел базового сегмента Geth отдельно, не запуская узел игрового сегмента, что упрощает интеграцию с такими вещами, как Alchemy.
Подводя итог, я хочу быть честным здесь, что многие люди ожидают, что их конструкции решат все их проблемы, но мы этого не делаем. Мы думаем, что наша конструкция работает для нас, но может не сработать для вашего варианта использования. Нереально предполагать, что наши конструкции будут работать для всех. Для нас это соответствовало нашим потребностям, предлагая высокую пропускную способность, горизонтальную масштабируемость, гибкость и высокую частоту тиков, но это не было лекарством от рака. Если вам нужен протокол DeFi, требующий синхронной компоновки, то эта конструкция может вам не подойти.
В целом, я действительно верю в концепцию ориентированной на человека архитектуры блокчейна. Разрабатывая дизайн с учетом конкретных ролей пользователей и вариантов использования, вы можете лучше находить компромиссы, а не пытаться решить проблемы всех. Наступила эпоха возрождения, и каждый может создавать свои собственные устройства Roll-Up в соответствии со своими конкретными потребностями, вместо того чтобы полагаться на общее решение. Я думаю, мы должны принять кембрийский взрыв. Не создавайте свертывания, такие как первый слой, с одним размером для всех, потому что он вообще не предназначен для решения одной и той же проблемы. Я лично с нетерпением жду, когда больше людей исследуют больше пространства дизайна Roll-Up для вариантов использования. Например, как будет выглядеть Roll-Up, специально разработанный для обмена активами? Будет ли это основано на намерении? Как будет выглядеть Roll-Up, специально разработанный для CLOB в сети (Центральная книга лимитных ордеров)? Вот, я передаю микрофон MJ. Спасибо за Ваше приглашение.
Английская версия: