Команда Lattice недавно анонсировала Redstone - свой новый L2, построенный с использованием их нового вклада в OP Stack (стек, который обеспечивает работу Optimism L2).

Поэтому всех интересует вопрос: "Стоит ли строить ончейн-игры на этой L2, и как она выглядит по сравнению с альтернативами?". Многие обращались к нашей команде в Paima Studios, чтобы узнать наше мнение, поскольку мы являемся одним из лучших разработчиков ончейн-игр, и наши игры представлены на нескольких цепочках, поэтому мы постараемся сделать все возможное, чтобы разобраться в нюансах.

ПРИМЕЧАНИЕ

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

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

Где все​началось​

Итак, Вы хотите создать ончейн-игру? Учитывая, что Redstone - это Ethereum L2, мы будем считать, что Вы уже настроились на использование Ethereum.

Итак, почему Вы не можете развернуть свою игру на Ethereum напрямую? Возможно, Вы знаете, что это потому, что она стоит слишком дорого (на момент написания этой статьи более >$1 за игровой ход), но знаете ли Вы, почему она стоит слишком дорого? Оказывается, есть две основные статьи расходов: стоимость выполнения и стоимость хранения данных - обе они непомерно дороги для игры. Однако точно так же, как процессоры стоят дороже жестких дисков, стоимость выполнения значительно выше стоимости хранения данных. Так что, если бы мы могли придумать способ преобразовать стоимость выполнения в стоимость хранения? Хорошие новости: роллапы делают именно это.

Рулоны как​решение для​масштабирования

Ролл-апы бывают разных форм, каждая из которых по-своему преобразует затраты на исполнение в затраты на хранение:

1. Оптимистичные сворачивания: выполните вычисление вне цепочки, затем сохраните все данные, необходимые для выполнения функции (только данные, без выполнения), вместе с локально вычисленным значением результата. Запускайте выполнение только в том случае, если кто-то считает, что результат, который Вы опубликовали, неверен ("доказательство мошенничества"). \
   Популярные примеры: Арбитрум, Оптимизм
2. ZK-ролики: выполните вычисление вне цепочки, затем сохраните все данные, необходимые для выполнения функции (только данные, без выполнения), вместе с локально вычисленным ZK-доказательством результата. \
   Популярные примеры: ZK Sync, Starknet, Polygon zkEVM
3. Суверенное сворачивание: запустите вычисление вне цепочки, затем сохраните все данные, необходимые для выполнения функции (только данные, без выполнения). \
   Популярные примеры: Rollkit, Paima Engine

Использование этих решений снижает стоимость транзакции в Вашей игре примерно до $0,05 (см. l2fees для получения актуальных значений), что, безусловно, является большим шагом в правильном направлении.

Снижение стоимости​L2​

Очевидно, что снижение стоимости этих L2 является ключевым фактором успеха игр. Хотя ролловеры определенно становятся дешевле (компьютеры становятся лучше, технология ZK совершенствуется и т.д.), основные затраты связаны не с вычислениями вне цепочки, а с размещением данных на L1.

Чтобы решить эту проблему, Ethereum вводит новый способ хранения данных, который гораздо дешевле (он называется EIP4844), где данные хранятся только временно (на практике ~2 недели, так что этого времени достаточно для того, чтобы были опубликованы все доказательства мошенничества и чтобы данные были реплицированы узлами по всему миру).

Однако EIP4844 имеет и некоторые недостатки:

• Данные носят временный характер (впоследствии Вам придется найти другое решение для хранения данных).
• Объем данных ограничен и составляет около 2 Мбайт на блок (распределяется между всеми роллапами на Ethereum).

Итак, как Вы видите, хотя усилия по снижению стоимости предпринимаются, их будет недостаточно, чтобы сделать ончейн-игры осуществимыми на L2, учитывая продолжающийся рост интереса к блокчейн-пространству (скорость принятия быстрее, чем скорость технических инноваций).

Альтернатива №1: Храните данные на централизованном сервере (или на множестве серверов).

Один из вариантов снижения стоимости - просто хранить данные на централизованном сервере, который люди доверяют Вам, и размещать на нем только хэш данных. Вариант этой идеи - использовать группу независимо работающих машин, объединенных в мультисигму. Такая схема называется "Комитет по доступности данных" (DAC), и именно она используется в Arbitrum Nova, Arbitrum Orbit и Polygon CDK.

Эти схемы намного дешевле ($0,001 / tx для Arbitrum Nova, если Вы не учитываете рынок комиссионных) в обмен на то, что сеть более централизована. Основной риск заключается в том, что если DAC каждый раз перестает размещать данные (например, публикует хэш и никогда не делится данными для этого хэша), сеть останавливается.

Особое примечание об​Arbitrum​

Вам может быть интересно, почему Arbitrum дважды появляется в этом списке. На данный момент Arbitrum предоставляет 3 основных предложения:

• Arbitrum One (основная сеть Arbitrum, которая представляет собой полный ролл-ап с данными на Ethereum)
• Arbitrum Nova (L2, использующий ЦАП)
• Arbitrum Orbit (стек для создания L3 для Arbitrum One)

Как Вы видите, проблема Nova заключается в том, что нет хорошего способа использовать DeFi для Вашей игры (пользователям пришлось бы идти в (Nova -> ETH L1 -> One) и тратить много бензина, чтобы просто перекинуть мост), тогда как новый стек Orbit позволяет Вам легко идти в (Orbit -> One). Кроме того, поскольку Orbit - это стек для создания L3, Вы можете использовать уже существующий L3, например, Xai Games, который работает с собственным ЦАП, или создать свой собственный L3 (хотя если у Вас игровой L3, единственная связь которого с Ethereum заключается в периодическом размещении хэшей, Вам, возможно, будет лучше с web2.5).

Альтернатива №2: Храните данные в другой децентрализованной​сети​

Вместо того, чтобы ждать, пока EIP4844 будет реализован с ограниченной пропускной способностью в mainnet, другие проекты, такие как Celestia, Avail и EigenDA, решили реализовать аналогичную концепцию в виде отдельной цепочки (так называемый уровень Data Availability ("DA")), и, сосредоточившись исключительно на этом сценарии использования, они предлагают более высокие лимиты данных, чем планирует поддерживать Ethereum mainnet. Эти платформы не поддерживают смарт-контракты и предназначены исключительно для использования в качестве уровня данных для L2.

Примечательно, что можно создать OP Stack с данными о Селестии, а также Arbitrum Orbit с данными о Селестии. Однако это имеет некоторые недостатки:

1. Доверие. Теперь Ваш роллап зависит от уровня DA, обеспечивающего безопасность поверх Ethereum (но, возможно, лучше, чем DAC).
2. Стоимость. Теперь Ваш роллап должен заплатить сети DA за свою безопасность (которую Вы должны оплатить собственным токеном уровня DA).
3. Скорость. Время блока Celestia составляет 15 с, а время блока Avail - 20 с. Например, данные должны быть обработаны в Celestia, прежде чем их можно будет соединить с EVM с помощью контракта Celestia blobstream. Однако не стоит относиться к этому с долей соли, поскольку все L2 в целом эмулируют более быстрое время блокировки, чем может реально обеспечить Ethereum (учитывая, что время блокировки Ethereum составляет всего 15 с, хотя Arbitrum использует время блокировки быстрее).

Подобная настройка, в частности, используется в Mantle (OP Stack + EigenLayer DA) и Manta Pacific (OP Stack + Celestia). Стоимость этих операций еще предстоит выяснить, но команда Celestia утверждает, что она составляет примерно $0,001, что означает, что стоимость хранения на уровне DA (по сравнению со стоимостью исполнения на рынке комиссий на стороне EVM) минимальна.

Альтернатива #3: Храните данные в ЦАП, которые могут быть​оспорены​

Наконец, мы можем поговорить о том, что предлагает Redstone. Если Вам не нравятся компромиссы, связанные с хранением данных на уровне DA, но не нравится централизация DAC, Вы можете вместо этого создать DAC, где Вы можете финансово наказать комитет, если он не сделает данные доступными.

Чтобы помочь понять, что это значит, давайте рассмотрим, как работает протокол DAC:

Как записывать​данные​

1. Sequencer for Redstone получает Вашу транзакцию
2. Секвенсор отправляет данные на ЦАП для сохранения
3. DAC возвращает подтверждение того, что данные сохранены
4. Секвенсор отправляет хэш данных на L1

Как читать​данные​

1. Синхронизируйте цепочку Ethereum в поисках хэшей, которые были переданы контракту на сворачивание.
2. Запросите данные для хэша у ЦАПа
3. Вычислите состояние L2 на основе этих данных

Итак, что​изменит​Redstone.

При чтении данных, если данные недоступны, Вы можете оспорить решение DAC, заявив, что он не сделал данные доступными (т.е. данные нельзя загрузить с его сервера).

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

1. Если претендент нечестен (данные действительно были доступны), он выбывает из игры (в противном случае, Вы могли бы финансово атаковать сеть, оспаривая каждый блок).
2. Если DCA нечестен (данные недоступны), их сокращают.

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

1. Секвенсор публикует хэш без предоставления реальных данных
2. Кто-то бросает вызов секвенсору
3. Секвенсор, видя проблему, делает данные доступными

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

Если Ваше решение этой проблемы заключается в предположении, что секвенсор никогда не будет врать только для игры, то почему бы вместо него не использовать стандартный ЦАП. Кроме того, предположение о честности секвенсора не очень хорошо сочетается с концепцией "суперцепочки" с общим секвенсором, что означает, что активы не могут использовать общий секвенсор для передачи между цепочками OP Stack (поэтому Вы столкнетесь с той же проблемой, что и Arbitrum Nova, если только Redstone не развернут как L3).

То, как команда Lattice планирует решать эту проблему, будет ключевым моментом, на который следует обратить внимание по мере появления дополнительной документации и информации о дорожной карте.

Альтернатива #4: Используйте​ZK​

Обратите внимание, что проблема с нераспространением данных (атаки утаивания данных), которая затрагивает Redstone, не является исключительной для оптимистичных рулонов. ZK Rollups, чьи данные хранятся вне цепочки (так называемые "валидиумы"), страдают от той же проблемы, поэтому люди обычно больше заинтересованы в rollups (которые публикуют все данные в цепочке).

Поэтому сворачивание ZK, в общем, не поможет Вам надежно снизить стоимость данных в Вашей игре. Они определенно могут помочь масштабировать Вашу игру многими другими способами (перенести больше вычислений на локальную машину пользователя, использовать рекурсивные доказательства для объединения множества взаимодействий в рулонном стиле или в стиле канала состояния и т.д.), но это тема для будущего поста.

Как я могу сделать стоимость моей игры еще ниже, если проблема в самой Solidity?

В этом блоге мы рассказывали о том, как справиться с расходами на хранение. Однако некоторые игры могут быть ограничены процессором (даже если они работают в централизованной сети EVM). Если это так, то Вас может заинтересовать использование сворачивания Sovereign, которое позволит Вам масштабировать свою игру за пределы EVM с помощью Paima Engine.

Paima Engine позволяет создавать специфические для приложений машины состояний на Javascript, которые Вы можете развернуть в любой EVM-цепочке по Вашему выбору (включая Redstone!). Эти суверенные ролики могут получить доступ к информации EVM (включая данные движка MUD), а значит, могут стать отличным способом заставить любую часть Вашей игры работать намного быстрее и дешевле.

Заключени​е​

В заключение хочу сказать, что снижение стоимости данных - это самый важный шаг к снижению затрат на ончейн-игры. На сегодняшний день существует множество различных решений с различными компромиссами, и Redstone позиционирует себя как более безопасный, чем стандартный ЦАП, но пока неясно, действительно ли он безопаснее, и достаточно ли существенна разница, чтобы стать жизнеспособной альтернативой решениям на уровне DA. Для проектов, которым необходимо масштабировать вычисления поверх данных, существуют такие решения, как Paima Engine, позволяющие решить эту проблему.

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

Paima​Studios​

Paima Studios, основанная в апреле 2022 года, является основным разработчиком движка Paima Engine: движка Web3, созданного с использованием новой технологии второго уровня, которая позволяет создавать ончейн-игры, геймификацию и автономные миры. Paima Engine - это безопасный и простой способ войти в Web3, поскольку его можно использовать с навыками Web2, и он не подвергает пользователей и разработчиков обычным рискам и взломам Web3.

• Кодовая база Paima Engine: https://github.com/PaimaStudios/paima-engine
• Документация Paima: https://docs.paimastudios.com/
• Шаблон Paima: https://github.com/PaimaStudios/paima-game-templates
• Пакет Paima NPM: <a href="https://www.npmjs.com/package/@paima/sdk"" > https://www.npmjs.com/package/@paima/sdk

Вы также можете узнать больше из наших социальных сетей:

• Youtube: <a href="https://www.youtube.com/@paimastudios"" > https://www.youtube.com/@paimastudios
• Discord: http://discord.gg/jZ59ArVaxv
• Reddit: https://reddit.com/r/paima
• Twitter: https://twitter.com/PaimaStudios

Хотите работать вместе? Не стесняйтесь связаться с нами через нашу контактную страницу: https://paimastudios.com/contact/.

Отказ от ответственности：

1. Эта статья перепечатана с сайта[blog.paimastudios]. Все авторские права принадлежат оригинальному автору[paimastudios]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.