Объясняется с помощью иллюстраций

Небольшое напоминание — в сериале ожидается, что пользователи будут использовать игровые предметы в игровом мире. Использование их для убийства монстров дает им лучшие атрибуты предметов как в игровом мире (в режиме реального времени), так и в сетевом мире (по запросу для экономии газа). Давайте обсудим создание разумного и справедливого механизма, позволяющего пользователям изменять атрибуты игрового лута. Ключевыми правилами должны быть:

  • пользователи не могут вносить изменения самостоятельно (иначе они смогут несправедливо повышать параметры игровых предметов без отражения в игровом мире)
  • владелец игры не может вносить какие-либо изменения в добычу пользователей

Создание записи об изменении

Итак, что мы видим здесь, так это то, что концепция заключается в следующем: владелец игры на основе достижений игроков в игре создает файл с описанием изменения (какие значения атрибутов должны быть увеличены), однако не может применить его (поскольку он не владеет добычей, ни готовы ли они платить за транзакцию).

Применение записи об изменении

Точно так же игрок может загрузить запись об изменении из игры и решить, применять ее или нет, однако игрок не может самостоятельно создать запись об изменении и применить изменение, поскольку смарт-контракт будет проверьте, является ли изменение законным — если оно исходит от игры и владельца смарт-контракта.

Объем атомарных изменений

С самого начала концепция заключалась в том, чтобы проектировать изменения таким образом, чтобы они описывали все изменения параметров — пользователи могут либо выполнить изменение полностью, либо полностью отказаться от изменения.

Запись концептуальных изменений

{ "attributes": { "Level" : NEWlevel, "Damage" : NEWdamage, "Agility": NEWagility }, "image": "ipfs://content-based-path-to-NEW-image", "signature": "some way of proving the change is legit" }

Приведенный выше пример будет в порядке, если все параметры будут храниться в цепочке. Но единственное, что хранится в цепочке, — это URI, поэтому нет необходимости описывать изменение как эти параметры.

Изменение заключается в назначении нового URI, который сам хранит все параметры, представленные выше. Таким образом, на самом деле запись об изменении де-факто будет выглядеть так:

{ "newURI" : "ipfs://new-uri-here", "signature" : some way of proving the change is legit }

Подписание транзакции с использованием EIP-712

Заявив, что игрок может применять только изменения, первоначально созданные владельцем SC, мы должны иметь возможность позволить владельцу создать запись об изменении и подписать ее — так, чтобы позже, когда игрок применит ее , это признается действительным изменением, исходящим от владельца смарт-контракта/разработчика игры.

Дополнительно (или в качестве первого теста он может проверить, является ли отправитель tx владельцем элемента)

Полный жизненный цикл действительного изменения показан ниже:

Ручной интерфейс для подписания изменений

В реальном сценарии разработчику игры не нужно ничего делать. Сервер, отслеживающий прогресс игрока, должен подписать изменение и позволить игроку применить его.

В нашем случае автоматического механизма не будет. Разработчик игры будет подписывать изменения вручную (когда захочет). Это позволяет лучше понять, как работает подпись изменений с использованием метамаски :)

Чтобы узнать все, что связано с подписанием и проверкой, ознакомьтесь с моей другой записью в блоге

Первоначально опубликовано на https://rotynski.dev