- Тема
10k Популярность
13k Популярность
42k Популярность
29k Популярность
676 Популярность
98k Популярность
28k Популярность
26k Популярность
7k Популярность
15k Популярность
- Закрепить
10k Популярность
13k Популярность
42k Популярность
29k Популярность
676 Популярность
98k Популярность
28k Популярность
26k Популярность
7k Популярность
15k Популярность
Как с помощью OPStack построить такт полной цепочки игры?
Добавить Автора
Как правило, игры основаны на циклах. Игровой цикл — это повторяющийся процесс, который обычно состоит из обработки пользовательского ввода, обновления состояния игры и рендеринга игрового мира. Этот цикл продолжается во время работы игры, обычно выполняясь от десятков до сотен раз в секунду, чтобы поддерживать движение игрового мира.
Однако архитектура блокчейна основана на push-уведомлениях. Блокчейн — это распределенная база данных, которая обменивается и хранит информацию через узлы в сети. Когда узел генерирует новую транзакцию (например, перевод, вызов контракта и т. д.), транзакция будет отправлена в сеть, а другие узлы проверят ее и добавят в цепочку блоков после получения транзакции. Это пассивный процесс, узлы не будут активно искать новые транзакции, а будут ждать, пока другие узлы в сети отправят новые транзакции. Поэтому говорят, что архитектура блокчейна основана на push.
Поэтому очень важно реализовать систему циклов с тактовыми циклами в игре с полной цепочкой. В конце концов, в так называемом «автономном мире» мы все надеемся, что некоторые NPC или виртуальные среды могут автоматически развиваться с течением времени, а не пассивно развиваться в соответствии с вводом транзакций, передаваемых в блокчейн.
@therealbytes разработал цепочку тиков для проверки концепции (цепочку с тактовыми циклами) на основе стека OP, которая запускает автоматическую реализацию игры «Жизнь» Конвея, давайте посмотрим, как он ее реализовал.
Чтобы не усложнять перевод, мы буквально переводим тик как «тик», что означает «тактовый цикл».
Ticking-Optimism — это концептуальная реализация «Ticking Blockchain», основанная на накопительной архитектуре Optimism Bedrock.
В цепочке тиков есть специальный смарт-контракт, который называется «тиковый контракт», и каждый блок будет автоматически вызываться протоколом. Это позволяет другим смарт-контрактам автоматически запускаться в определенное время или через определенные промежутки времени, не требуя от пользователей отправки транзакций.
Как добиться
Новая модульная накопительная архитектура Optimism, Optimism Bedrock, представляет новый тип транзакции, который называется «Депозитная транзакция». В отличие от обычных сделок депозитные операции:
Блоки из слоя 1.
Проверка подписи не требуется.
Купите газ L2 на L1, поэтому газ L2 не подлежит возврату.
В оригинальном Bedrock депозитные транзакции использовались для двух целей:
Выполнение транзакций, отправленных непосредственно на L1.
Установите свойства L1 (число, метка времени, хэш и т. д.) для предварительно развернутых контрактов L2 в каждом блоке.
В последнем случае транзакции создаются узлами свертки. Он не платит за газ, и использованный газ не вычитается из газового фонда.
Ticking-Optimism изменяет узел свертки, а также создает «тиковую транзакцию», которая работает таким же образом, но вместо установки свойства L1 вызывает функцию tick() в предварительно развернутом контракте по адресу 0x42000000000000000000000000000000000000000A0. Этот контракт может вызвать другой контракт, установив его целевую переменную.
Мотивация
Чтобы проиллюстрировать мощь тикчейнов, представьте себе игру на блокчейне, в которой несколько NPC (неигровые персонажи) перемещаются по карте. Без цепочки тиков у нас есть два основных подхода к проектированию:
Ленивое обновление. На стороне клиента кажется, что NPC постоянно перемещаются, но их позиции обновляются в цепочке только тогда, когда пользователи отправляют транзакции для взаимодействия с ними. Затем контракт вычисляет новое местоположение NPC на основе его последнего обновления в сети и количества блоков, прошедших с тех пор.
Ручная пометка. Мы определяем функцию обновления, которая устанавливает положение каждого NPC на карте, и периодически вызываем ее из внешней учетной записи.
С тикчейном решение похоже на ручное тикирование, но тиковый контракт вызывает функцию обновления автоматически, а не вручную.
Преимущества использования «автоматического тика» цепочки тиков вместо тиков вручную:
Обновления гарантируются по договоренности.
Обновление будет выполняться перед всеми транзакциями в блоке и не может быть открыто, так как оно является частью самого протокола.
Сделки обновления не участвуют в обычном газовом рынке.
Однако для автоматических тиков требуется индивидуальная цепочка блоков. Если частота обновления одинакова, ручная и автоматическая пометка требуют одинаковых вычислительных ресурсов на узле. Ленивые обновления, с другой стороны, обычно дешевле, потому что обновления в сети меньше и реже.
Кроме того, вычислительная стоимость тиковых транзакций увеличивается по мере роста состояния, которое необходимо обновить. Это оказывает дополнительное давление на разработчиков, чтобы они проектировали свои приложения таким образом, чтобы затраты никогда не превышали возможности сети.
Несмотря на эти огромные недостатки, автоматические тики лучше подходят, чем ленивые обновления для определенных типов приложений.
Тики позволяют смарт-контрактам получать доступ с постоянной стоимостью к динамическому состоянию, которое обновляется с использованием выражений открытой формы.
Состояние (в приведенном выше примере местоположение NPC) всегда доступно для чтения в сети при постоянной и относительно низкой стоимости газа. Но стоимость расчета текущего состояния будет увеличиваться с увеличением количества блоков с момента последнего обновления, а стоимость газа будет увеличиваться еще больше.
Если мы обновляем положение объекта, движущегося с постоянной скоростью, мы можем рассчитать, где он должен находиться в любом заданном фрагменте, исходя из его последней установленной позиции и количества фрагментов с момента обновления. Стоимость этой операции не растет с количеством блоков между обновлениями.
С другой стороны, если состояние, которое мы обновляем, похоже на «Игру жизни» Конвея (или симуляцию трех гравитаций), стоимость обновления растет линейно с количеством шагов, прошедших с момента последнего обновления. Это проблема, потому что она может выйти за пределы того, что пользователи готовы платить, или того, что сеть может поддерживать.
При отложенных обновлениях логика обновления должна быть реализована как в смарт-контракте, так и в клиенте. С тикингом его нужно реализовать только в блокчейне, а клиенты могут просто реагировать на события в цепочке.
Ленивые обновления позволяют разработчикам распространять свою логику обновления на множество функций и смарт-контрактов, при этом каждая функция запускается только при выполнении определенных транзакций. В отличие от этого, подход «тик-тик» требует только функции обновления, которая гарантированно срабатывает периодически. Последнее упрощает поддержание согласованности и целостности состояния.
Кроме того, каждый раз, когда добавляется новое состояние ленивого обновления (например, новый тип NPC), может потребоваться изменить все функции обновления для его учета. Это делает кодовую базу более сложной и подверженной проблемам.
Стоимость ленивых обновлений часто сильно различается, и пользователи могут организовать свои транзакции так, чтобы большая часть бремени обновлений ложилась на других. С тиками стоимость всех операций относительно стабильна и неуязвима для атак MEV.
Демонстрация игры «Жизнь» Конвея
Я создал демо-версию Tickchain, которая запускает интерактивную версию игры Конвея «Жизнь». Цепочка была изменена, чтобы включить логику клеточного автомата в механизм выполнения, что сделало ее более эффективной, позволяя использовать игровое поле большего размера, чем можно было бы реализовать в виде байт-кода смарт-контракта.
Исходный код демо:
Демонстрационное видео: