📝 Блокчейны должны проектироваться как многопользовательские игры (перевод статьи @dantheman)

В своей предыдущей статье я говорил о том, почему блокчейны общего назначения не должны пользоваться UTXO моделью транзакций. Теперь же я объясню, почему блокчейны не должны хранить свое состояние в транзакциях, а сделаю я это на хорошо знакомых примерах из многопользовательских онлайн-игр.

Если задуматься, каждая многопользовательская онлайн-игра - это движок консенсуса. Всем игрокам необходимо достичь консенсуса о состоянии игрового мира. Гейм-дизайнеры уже давно выяснили, что состояние игры слишком велико, чтобы эффективно синхронизировать его между всеми игроками. Вместо этого разработчики игр генерируют детерминированный движок, а затем передают в него информацию от игроков. Предполагается, что все игроки согласны с порядком событий, а потому каждый в точности знает, кто выиграл, а кто проиграл. С таким логом событий становится возможным точно и полностью воспроизвести всю игру.

Представьте, что играете в StarCraft на блокчейне. Пользователи будут генерировать транзакции для каждой команды, которую они дают своим юнитам. Эти транзакции будут собраны сервером, который будет определять глобальный порядок событий, а потом этот блок действий будет распределен по всем пользователям, состояние которых в результате будет синхронизировано.

Очевидно, равное 3 секундам время блока будет влиять на геймплей, но теоретически время блока может быть уменьшено до 20 мс, если производитель блоков будет только один.

Маленькие действия могут запустить крупные изменения состояний

Всего одно действие пользователя, приказывающее всем юнитам атаковать вражескую базу, может привести к бесчисленным изменениям состояния, так как юниты начнут двигаться, атаковать и уничтожать друг друга. Если предположить, что есть 1000 юнитов, каждый из которых двигается по 30 раз в секунду, то мы получим десятки мегабайт изменений состояния, которые были спровоцированы единственным действием пользователя, занявшим менее 1 КБ.

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

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

Прогнозирующий рендеринг

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

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

Заключение

Игроки блокчейн-индустрии сильно заблуждаются, думая, что они решают новые проблемы, тогда как на самом деле почти все, что нужно делать блокчейну, известно разработчикам игр в течение десятилетий. Единственная новая вещь в блокчейне - то, что все действия должны быть подписаны и что существует множество серверов, которые поочередно включают действия в официальный лог. Большинство специализирующихся на блокчейне технологий и систем консенсуса (будь то POS, DPOS, POW или что-нибудь еще) полностью независимы от уже установившихся проектировочных шаблонов, которые доказали свою масштабируемость для многопользовательских онлайн игр.

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

Оригинальный пост и его обсуждение ЗДЕСЬ

Поддержите нашего делегата на Голосе - анонс инициативы BLOCKCHAINED