! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f8bb1f8b126f9f3317749e6564bff7e7.jpg)
Накопительный пакет приложения становится явным победителем в масштабировании определенного набора приложений Ethereum. Эти приложения пользуются надежными гарантиями владения, не требующими разрешений, но не требуют одновременного взаимодействия между всеми пользователями приложения. Полностью ончейн-игры — лучший тому пример. Ончейн-игры выигрывают от сильного владения игровыми активами, что позволяет анонимно участвовать в игре и позволяет анонимно модифицировать игру. Тем не менее, большинство игр не требуют, чтобы все игроки взаимодействовали одновременно. Другие приложения, которые могут извлечь выгоду из стратегии масштабирования Rollup, включают торговые площадки NFT, бессрочные биржи и ончейн-инференс ИИ.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f20241526a9e4945c106e2f36e2dc54b.jpg)
Накопительный пакет приложений уже является предпочтительной реализацией для многих из этих вариантов использования. Однако стандартная реализация Rollup, EVMRollup, по-прежнему имеет важные ограничения масштабируемости. Они могут достигать пропускной способности около 100 транзакций в секунду. Эта пропускная способность может быть достаточной для некоторых ончейн-игр, в зависимости от типа игры. Однако большинству игр требуется более высокая пропускная способность для поддержки большого количества одновременных игроков (более 1000). В этой статье рассказывается о том, как свертка приложения масштабируется для охвата сотен тысяч одновременных участников. Для каждого подхода я обсуждаю подходящий тип приложения/игры и проблемы, с которыми он сталкивается.
Масштабирование по горизонтали
Горизонтальная масштабируемость — это самый простой способ масштабирования накопительного пакета приложения. Однако эта простота достигается за счет компонуемости, что делает их пригодными только для небольшого подмножества приложений, таких как однопользовательские игры.
Горизонтальная масштабируемость означает простое развертывание нескольких накопительных пакетов приложений (Optimistic или ZK) и развертывание одного и того же смарт-контракта на всех накопительных пакетах. Клиентская часть приложения легко направляет пользователя к одному из накопительных пакетов в зависимости от емкости, местоположения или конкретных параметров приложения. Alt Layer недавно продемонстрировал эту концепцию, запустив масштабируемую игру 2048 FOCG. Во внешнем интерфейсе игры пользователи могут выбрать, к какому роллапу присоединиться, в зависимости от своего географического положения. Из-за простоты и доступности поставщиков роллапов как услуги, таких как Caldera, которые берут на себя всю инфраструктурную работу, связанную с вращением и управлением этими роллапами, этот подход может быть легко принят разработчиками игр.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/b872ea4023eb627e81fc61022f05f2bc.jpg)
Тем не менее, существуют некоторые проблемы с подходом к расширению с несколькими свертками. Первая проблема — это коммутатор сети Rollup. Текущие кошельки, такие как Metamask, требуют ручного одобрения для подключения к новой сети, экземпляру Rollup. Это создает сложный и запутанный пользовательский опыт для игроков, поскольку игрокам необходимо вручную подключаться к нескольким «сетям», чтобы играть в одну и ту же игру. К счастью, эту сложность можно устранить с помощью решения Account Abstraction (AA). В качестве примера можно привести EIP 4337 и встроенные кошельки, такие как Privy и 0xPass.
Еще одной проблемой является управление состоянием плеера во время переходов между роллапами. В некоторых случаях, например при падении емкости, приложению может потребоваться консолидировать несколько экземпляров объединения в один экземпляр для экономии ресурсов. В этом случае состояние всех активных игроков нужно перенести в новый инстанс. Современные мостовые решения, особенно мосты ZK, могут сыграть ключевую роль в решении этой проблемы. Используя эти решения, вы можете соединить состояние игры игрока с новым экземпляром накопительного пакета, сохраняя при этом доказательство допустимости этого состояния. Однако задержка существующих мостовых решений может быть неоптимальной для игровых сценариев использования.
Канал статуса ZK
Еще одним расширением накопительного пакета приложения, которое больше подходит для многопользовательских игр, таких как покер, является канал состояния ZK. В этих играх взаимодействие между игроками происходит между небольшим количеством игроков, например, от 2 до 10 человек. Игровой процесс между этими игроками важен только во время игры. Однако окончательный результат игры более важен, так как он влияет на баланс активов каждого игрока. Поэтому важно хранить результаты на общем уровне сохраняемости.
В этом случае накопительный пакет приложения представляет собой общий информационный слой, где хранятся результаты игры и где также существуют игровые активы. Для каждой игры на Rollup вы можете запустить канал состояния ZK для обслуживания игры. Во время игрового процесса каждый игрок генерирует транзакции и создает ZKP, доказывая, что он следовал правилам игры. Доказательства взаимодействия с другими игроками агрегируют предыдущее доказательство с помощью рекурсивных доказательств. Когда игра заканчивается, окончательный ZKP отправляется в приложение Rollup, чтобы доказать валидность игрового процесса и окончательный результат. Изменение состояния, вызванное игрой, изменяет состояние игрока на накопительном пакете приложения.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/279d2bd0b1395674a145b42e73523ce3.jpg)
Канал состояний ZK перемещает игровые взаимодействия за пределы блокчейна. Таким образом, внутриигровые действия и транзакции не учитываются в пропускной способности накопительного пакета приложения. Используя этот подход, приложение Rollup может масштабироваться в широких масштабах для поддержки тысяч одновременных проигрывателей. Транзакция для объединения приложения будет проверять только сгенерированные транзакции ZKP и обновления состояния с коэффициентом масштабирования 100–1000x. Разработкой технологии занимались несколько команд, в том числе Ontropy.
Одним из недостатков этого подхода является то, что он требует, чтобы игроки запускали игровую логику на своих собственных устройствах и генерировали ZKP. Часто эти пробы имеют небольшой вес и могут быть выполнены за считанные секунды с помощью передовых систем проверки, таких как Halo2. Тем не менее, это все равно может привести к снижению игрового опыта на устройствах с ограниченными ресурсами.
Одним из способов устранения этой проблемы является назначение одного из участников канала состояния zk в качестве временного секвенсора. Секвенсор будет получать транзакцию каждого игрока и генерировать соответствующий ZKP, делясь ZKP со всеми участниками канала. Эту модификацию можно рассматривать как кратковременное урегулирование ZK L3 в Rollup приложения. Команда Cartridge реализовала эту архитектуру, разработав специальный секвенсор под названием Katana.
Подход zk state channel имеет большой потенциал. Тем не менее, есть несколько открытых вопросов, связанных со средой выполнения в канале состояний zk и с тем, как оптимизировать рекурсивное доказательство. Текущие среды zkEVM неэффективны, и большинство из них в настоящее время не поддерживают рекурсию доказательства. В качестве альтернативы можно использовать легковесные zkVM или даже использовать специализированные схемы zk для управления взаимодействием с игроком, если у игрока ограниченное количество возможных ходов.
Изменение среды выполнения
Третий способ расширения накопительного пакета приложения заключается в изменении среды выполнения накопительного пакета. Несмотря на свою зрелость и обилие инструментов разработки EVM, они не подходят для высокопроизводительных приложений, таких как игры. Кроме того, однопоточная модель выполнения и хранения EVM приводит к снижению пропускной способности, которая может быть улучшена за счет улучшений.
Основное преимущество этого подхода заключается в том, что увеличение пропускной способности свертки не требует жертвования компонуемостью или ограничения количества вариантов использования. Этот подход можно использовать для любого приложения Web 3, если среда выполнения может достичь пропускной способности, требуемой приложением. Это делает их единственным жизнеспособным решением для приложений, которым требуется доступ к общему состоянию, таких как AMM, протоколы кредитования и другие приложения DeFi.
Расширение функциональности EVM с помощью предварительной компиляции
Во-первых, Rollup обеспечивает соответствие EVM и накладывает некоторые ограничения на пропускную способность предварительно скомпилированных адресов. Идея здесь проста. Предварительная компиляция — это нисходящее перемещение операций EVM с интенсивными вычислениями на уровень узла. Операция, требующая сотен или тысяч кодов операций EVM и потребляющая 100 000+ газа, может быть упрощена до одной операции с 100-кратным снижением затрат на газ. Предварительную компиляцию, расширяющую среду Rollup, часто называют EVM+. Примерами такого подхода являются поддержка конфиденциальности в сети и поддержка более эффективных схем подписи, таких как подписи BLS. Например, zkHoldem poker использует специальные операции FHE и zk для обеспечения приватной раздачи карт и презентации. Разработка этих специализированных предварительных компиляций обычно осуществляется совместными усилиями разработчика накопительного пакета приложения и поставщика Raas, который управляет развертыванием и обслуживанием инфраструктуры объединения приложений.
Использование среды выполнения, отличной от EVM
Еще один способ улучшить среду выполнения свертки — избавиться от EVM. Такой подход набирает популярность среди новых разработчиков в экосистеме Ethereum, а также среди разработчиков, которые считают, что Solidity — не лучший язык для разработки сложных приложений.
Сегодня у нас есть накопительные приложения, работающие в средах выполнения WASM, SVM, Cairo и даже Linux. Большинство из этих методов позволяют разработчикам писать смарт-контракты, используя языки высокого уровня, такие как Rust или C. Недостатком является то, что взаимодействие с существующими контрактами Solidity часто теряется. Тем не менее, совместимость с EVM все еще может быть создана. Например, стилус Aributrum использует сопроцессор, чтобы сделать контракт Stylus совместимым с EVM. Такая конструкция приближает стилус к архитектуре EVM+, чем к архитектуре без EVM.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/be666ff84c513ab1de2a247236a723a2.jpg)
Смешанная среда выполнения
Третий подход, который особенно популярен среди FOG, является лучшей функцией, сочетающей в себе первые два. Этот подход сочетает в себе совместимость EVM с выделенной средой выполнения, отличной от EVM. Среды, отличные от EVM, ориентированы на высокопроизводительное выполнение основных игровых примитивов. Управление игровыми активами, такими как внутриигровые транзакции NFT, может осуществляться стандартными контрактами Solidity.
Преимущество этого подхода заключается в том, что совместимость с EVM обеспечивает согласованность с более крупной экосистемой разработчиков и существующими продуктами. Кроме того, он обеспечивает компонуемость без разрешений. Разработчики могут модифицировать и расширять игровую логику, добавляя смарт-контракты EVM/Solidity. В то же время специализированные игровые движки, не поддерживающие EVM, обеспечивают высокую пропускную способность, недоступную EVM.
Примерами такого подхода являются World Engine от Argus и Keystone от Curio. World Engine выделяет выполнение игровой логики в отдельный слой, называемый Game Shard, который работает поверх EVM-совместимого слоя. Game Shard также обеспечивает горизонтальное масштабирование для регулировки общей пропускной способности накопительного пакета в зависимости от спроса. Аналогичным образом, архитектура Keystone от Curio объединяет высокопроизводительный игровой движок с EVM в качестве среды выполнения Rollup. Задача состоит в том, чтобы обеспечить бесшовную совместимость между движками EVM и игровыми движками.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/246295e5b8867825147e0129ef32c4d9.jpg)
Рекомендации по доступности данных
В предыдущем обсуждении основное внимание уделялось увеличению пропускной способности транзакций накопительного пакета, что является основным аспектом масштабирования накопительного пакета приложения. Другие темы, связанные с этим повышением пропускной способности, включают доступность данных (DA), децентрализацию службы упорядочения и скорость расчетов. Для накопительных пакетов приложений с высокой пропускной способностью доступность данных является наиболее актуальной из этих проблем.
Один накопительный пакет приложения может иметь пропускную способность более 10 000 транзакций в секунду. Использовать Ethereum в качестве уровня доступности данных для этих транзакций невозможно. Во-первых, средняя стоимость публикации простых данных о переводе L2 ETH на L2 может превышать $0,1. Эти затраты слишком высоки для большинства накопительных пакетов приложений. Более того, L1 Ethereum в настоящее время не может поддерживать роллапы, которые используют преимущества L1 для доступности данных с примерно 8 000 транзакций в секунду.
Накопительные пакеты приложений будут опираться в основном на внешние решения DA. Celestia и EigenDA в настоящее время позиционируются как наиболее жизнеспособные варианты для приложения Rollup. Например, Eclipse планирует использовать Celestia в качестве уровня доступности данных для своего базового накопителя SVM с высокой пропускной способностью. Также планируется, что Argus и высокопроизводительные игровые движки будут использовать Celestia. Аналогичным образом, EigenDA обещает пропускную способность данных до 10 МБ в секунду, а также может предоставить жизнеспособное решение для объединения нескольких приложений.
Однако основным недостатком интеграции Celestia или EigneDA является утечка экономической ценности. Роллапы приложений должны оплачивать комиссию за уровень DA, а также комиссию за расчеты на Ethereum L1. Комиссия за расчет является ключевым для Rollup приложения, потому что она связывает безопасность Rollup с безопасностью Ethereum. Гарантии DA менее важны в контексте FOG, где стоимость транзакции намного меньше, чем в этих сетях. Кроме того, Celestia и EigenDA обещают низкие комиссии, потому что эти сети только работают, и их использование будет низким на начальном этапе. Когда эти сети DA достигают высокой загрузки, плата за DA также может стать непомерно высокой. По моему мнению, для подтверждения доступности данных накопительного пакета приложения должна использоваться простая плата Data Availability Board (DAC).
В заключение, я думаю, что роллапы приложений являются лучшим существующим решением для масштабирования приложений с высокой пропускной способностью, особенно полностью ончейн-игр. Расширение этих приложений с помощью Rollup является ключом к достижению массового внедрения за пределами нативных пользователей криптовалюты.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Интерпретация технологии Dapp-роллапа: как сделать приложение с высокой пропускной способностью мейнстримом?
Автор: Mohamed Fouda
Составитель: DeepTide TechFlow
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f8bb1f8b126f9f3317749e6564bff7e7.jpg)
Накопительный пакет приложения становится явным победителем в масштабировании определенного набора приложений Ethereum. Эти приложения пользуются надежными гарантиями владения, не требующими разрешений, но не требуют одновременного взаимодействия между всеми пользователями приложения. Полностью ончейн-игры — лучший тому пример. Ончейн-игры выигрывают от сильного владения игровыми активами, что позволяет анонимно участвовать в игре и позволяет анонимно модифицировать игру. Тем не менее, большинство игр не требуют, чтобы все игроки взаимодействовали одновременно. Другие приложения, которые могут извлечь выгоду из стратегии масштабирования Rollup, включают торговые площадки NFT, бессрочные биржи и ончейн-инференс ИИ.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/f20241526a9e4945c106e2f36e2dc54b.jpg)
Накопительный пакет приложений уже является предпочтительной реализацией для многих из этих вариантов использования. Однако стандартная реализация Rollup, EVMRollup, по-прежнему имеет важные ограничения масштабируемости. Они могут достигать пропускной способности около 100 транзакций в секунду. Эта пропускная способность может быть достаточной для некоторых ончейн-игр, в зависимости от типа игры. Однако большинству игр требуется более высокая пропускная способность для поддержки большого количества одновременных игроков (более 1000). В этой статье рассказывается о том, как свертка приложения масштабируется для охвата сотен тысяч одновременных участников. Для каждого подхода я обсуждаю подходящий тип приложения/игры и проблемы, с которыми он сталкивается.
Масштабирование по горизонтали
Горизонтальная масштабируемость — это самый простой способ масштабирования накопительного пакета приложения. Однако эта простота достигается за счет компонуемости, что делает их пригодными только для небольшого подмножества приложений, таких как однопользовательские игры.
Горизонтальная масштабируемость означает простое развертывание нескольких накопительных пакетов приложений (Optimistic или ZK) и развертывание одного и того же смарт-контракта на всех накопительных пакетах. Клиентская часть приложения легко направляет пользователя к одному из накопительных пакетов в зависимости от емкости, местоположения или конкретных параметров приложения. Alt Layer недавно продемонстрировал эту концепцию, запустив масштабируемую игру 2048 FOCG. Во внешнем интерфейсе игры пользователи могут выбрать, к какому роллапу присоединиться, в зависимости от своего географического положения. Из-за простоты и доступности поставщиков роллапов как услуги, таких как Caldera, которые берут на себя всю инфраструктурную работу, связанную с вращением и управлением этими роллапами, этот подход может быть легко принят разработчиками игр.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/b872ea4023eb627e81fc61022f05f2bc.jpg)
Тем не менее, существуют некоторые проблемы с подходом к расширению с несколькими свертками. Первая проблема — это коммутатор сети Rollup. Текущие кошельки, такие как Metamask, требуют ручного одобрения для подключения к новой сети, экземпляру Rollup. Это создает сложный и запутанный пользовательский опыт для игроков, поскольку игрокам необходимо вручную подключаться к нескольким «сетям», чтобы играть в одну и ту же игру. К счастью, эту сложность можно устранить с помощью решения Account Abstraction (AA). В качестве примера можно привести EIP 4337 и встроенные кошельки, такие как Privy и 0xPass.
Еще одной проблемой является управление состоянием плеера во время переходов между роллапами. В некоторых случаях, например при падении емкости, приложению может потребоваться консолидировать несколько экземпляров объединения в один экземпляр для экономии ресурсов. В этом случае состояние всех активных игроков нужно перенести в новый инстанс. Современные мостовые решения, особенно мосты ZK, могут сыграть ключевую роль в решении этой проблемы. Используя эти решения, вы можете соединить состояние игры игрока с новым экземпляром накопительного пакета, сохраняя при этом доказательство допустимости этого состояния. Однако задержка существующих мостовых решений может быть неоптимальной для игровых сценариев использования.
Канал статуса ZK
Еще одним расширением накопительного пакета приложения, которое больше подходит для многопользовательских игр, таких как покер, является канал состояния ZK. В этих играх взаимодействие между игроками происходит между небольшим количеством игроков, например, от 2 до 10 человек. Игровой процесс между этими игроками важен только во время игры. Однако окончательный результат игры более важен, так как он влияет на баланс активов каждого игрока. Поэтому важно хранить результаты на общем уровне сохраняемости.
В этом случае накопительный пакет приложения представляет собой общий информационный слой, где хранятся результаты игры и где также существуют игровые активы. Для каждой игры на Rollup вы можете запустить канал состояния ZK для обслуживания игры. Во время игрового процесса каждый игрок генерирует транзакции и создает ZKP, доказывая, что он следовал правилам игры. Доказательства взаимодействия с другими игроками агрегируют предыдущее доказательство с помощью рекурсивных доказательств. Когда игра заканчивается, окончательный ZKP отправляется в приложение Rollup, чтобы доказать валидность игрового процесса и окончательный результат. Изменение состояния, вызванное игрой, изменяет состояние игрока на накопительном пакете приложения.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/279d2bd0b1395674a145b42e73523ce3.jpg)
Канал состояний ZK перемещает игровые взаимодействия за пределы блокчейна. Таким образом, внутриигровые действия и транзакции не учитываются в пропускной способности накопительного пакета приложения. Используя этот подход, приложение Rollup может масштабироваться в широких масштабах для поддержки тысяч одновременных проигрывателей. Транзакция для объединения приложения будет проверять только сгенерированные транзакции ZKP и обновления состояния с коэффициентом масштабирования 100–1000x. Разработкой технологии занимались несколько команд, в том числе Ontropy.
Одним из недостатков этого подхода является то, что он требует, чтобы игроки запускали игровую логику на своих собственных устройствах и генерировали ZKP. Часто эти пробы имеют небольшой вес и могут быть выполнены за считанные секунды с помощью передовых систем проверки, таких как Halo2. Тем не менее, это все равно может привести к снижению игрового опыта на устройствах с ограниченными ресурсами.
Одним из способов устранения этой проблемы является назначение одного из участников канала состояния zk в качестве временного секвенсора. Секвенсор будет получать транзакцию каждого игрока и генерировать соответствующий ZKP, делясь ZKP со всеми участниками канала. Эту модификацию можно рассматривать как кратковременное урегулирование ZK L3 в Rollup приложения. Команда Cartridge реализовала эту архитектуру, разработав специальный секвенсор под названием Katana.
Подход zk state channel имеет большой потенциал. Тем не менее, есть несколько открытых вопросов, связанных со средой выполнения в канале состояний zk и с тем, как оптимизировать рекурсивное доказательство. Текущие среды zkEVM неэффективны, и большинство из них в настоящее время не поддерживают рекурсию доказательства. В качестве альтернативы можно использовать легковесные zkVM или даже использовать специализированные схемы zk для управления взаимодействием с игроком, если у игрока ограниченное количество возможных ходов.
Изменение среды выполнения
Третий способ расширения накопительного пакета приложения заключается в изменении среды выполнения накопительного пакета. Несмотря на свою зрелость и обилие инструментов разработки EVM, они не подходят для высокопроизводительных приложений, таких как игры. Кроме того, однопоточная модель выполнения и хранения EVM приводит к снижению пропускной способности, которая может быть улучшена за счет улучшений.
Основное преимущество этого подхода заключается в том, что увеличение пропускной способности свертки не требует жертвования компонуемостью или ограничения количества вариантов использования. Этот подход можно использовать для любого приложения Web 3, если среда выполнения может достичь пропускной способности, требуемой приложением. Это делает их единственным жизнеспособным решением для приложений, которым требуется доступ к общему состоянию, таких как AMM, протоколы кредитования и другие приложения DeFi.
Расширение функциональности EVM с помощью предварительной компиляции
Во-первых, Rollup обеспечивает соответствие EVM и накладывает некоторые ограничения на пропускную способность предварительно скомпилированных адресов. Идея здесь проста. Предварительная компиляция — это нисходящее перемещение операций EVM с интенсивными вычислениями на уровень узла. Операция, требующая сотен или тысяч кодов операций EVM и потребляющая 100 000+ газа, может быть упрощена до одной операции с 100-кратным снижением затрат на газ. Предварительную компиляцию, расширяющую среду Rollup, часто называют EVM+. Примерами такого подхода являются поддержка конфиденциальности в сети и поддержка более эффективных схем подписи, таких как подписи BLS. Например, zkHoldem poker использует специальные операции FHE и zk для обеспечения приватной раздачи карт и презентации. Разработка этих специализированных предварительных компиляций обычно осуществляется совместными усилиями разработчика накопительного пакета приложения и поставщика Raas, который управляет развертыванием и обслуживанием инфраструктуры объединения приложений.
Использование среды выполнения, отличной от EVM
Еще один способ улучшить среду выполнения свертки — избавиться от EVM. Такой подход набирает популярность среди новых разработчиков в экосистеме Ethereum, а также среди разработчиков, которые считают, что Solidity — не лучший язык для разработки сложных приложений.
Сегодня у нас есть накопительные приложения, работающие в средах выполнения WASM, SVM, Cairo и даже Linux. Большинство из этих методов позволяют разработчикам писать смарт-контракты, используя языки высокого уровня, такие как Rust или C. Недостатком является то, что взаимодействие с существующими контрактами Solidity часто теряется. Тем не менее, совместимость с EVM все еще может быть создана. Например, стилус Aributrum использует сопроцессор, чтобы сделать контракт Stylus совместимым с EVM. Такая конструкция приближает стилус к архитектуре EVM+, чем к архитектуре без EVM.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/be666ff84c513ab1de2a247236a723a2.jpg)
Смешанная среда выполнения
Третий подход, который особенно популярен среди FOG, является лучшей функцией, сочетающей в себе первые два. Этот подход сочетает в себе совместимость EVM с выделенной средой выполнения, отличной от EVM. Среды, отличные от EVM, ориентированы на высокопроизводительное выполнение основных игровых примитивов. Управление игровыми активами, такими как внутриигровые транзакции NFT, может осуществляться стандартными контрактами Solidity.
Преимущество этого подхода заключается в том, что совместимость с EVM обеспечивает согласованность с более крупной экосистемой разработчиков и существующими продуктами. Кроме того, он обеспечивает компонуемость без разрешений. Разработчики могут модифицировать и расширять игровую логику, добавляя смарт-контракты EVM/Solidity. В то же время специализированные игровые движки, не поддерживающие EVM, обеспечивают высокую пропускную способность, недоступную EVM.
Примерами такого подхода являются World Engine от Argus и Keystone от Curio. World Engine выделяет выполнение игровой логики в отдельный слой, называемый Game Shard, который работает поверх EVM-совместимого слоя. Game Shard также обеспечивает горизонтальное масштабирование для регулировки общей пропускной способности накопительного пакета в зависимости от спроса. Аналогичным образом, архитектура Keystone от Curio объединяет высокопроизводительный игровой движок с EVM в качестве среды выполнения Rollup. Задача состоит в том, чтобы обеспечить бесшовную совместимость между движками EVM и игровыми движками.
! [Интерпретация технологии объединения децентрализованных приложений: как сделать приложение с высокой пропускной способностью мейнстримом?] ](https://cdn-img.panewslab.com//panews/2022/10/20/images/246295e5b8867825147e0129ef32c4d9.jpg)
Рекомендации по доступности данных
В предыдущем обсуждении основное внимание уделялось увеличению пропускной способности транзакций накопительного пакета, что является основным аспектом масштабирования накопительного пакета приложения. Другие темы, связанные с этим повышением пропускной способности, включают доступность данных (DA), децентрализацию службы упорядочения и скорость расчетов. Для накопительных пакетов приложений с высокой пропускной способностью доступность данных является наиболее актуальной из этих проблем.
Один накопительный пакет приложения может иметь пропускную способность более 10 000 транзакций в секунду. Использовать Ethereum в качестве уровня доступности данных для этих транзакций невозможно. Во-первых, средняя стоимость публикации простых данных о переводе L2 ETH на L2 может превышать $0,1. Эти затраты слишком высоки для большинства накопительных пакетов приложений. Более того, L1 Ethereum в настоящее время не может поддерживать роллапы, которые используют преимущества L1 для доступности данных с примерно 8 000 транзакций в секунду.
Накопительные пакеты приложений будут опираться в основном на внешние решения DA. Celestia и EigenDA в настоящее время позиционируются как наиболее жизнеспособные варианты для приложения Rollup. Например, Eclipse планирует использовать Celestia в качестве уровня доступности данных для своего базового накопителя SVM с высокой пропускной способностью. Также планируется, что Argus и высокопроизводительные игровые движки будут использовать Celestia. Аналогичным образом, EigenDA обещает пропускную способность данных до 10 МБ в секунду, а также может предоставить жизнеспособное решение для объединения нескольких приложений.
Однако основным недостатком интеграции Celestia или EigneDA является утечка экономической ценности. Роллапы приложений должны оплачивать комиссию за уровень DA, а также комиссию за расчеты на Ethereum L1. Комиссия за расчет является ключевым для Rollup приложения, потому что она связывает безопасность Rollup с безопасностью Ethereum. Гарантии DA менее важны в контексте FOG, где стоимость транзакции намного меньше, чем в этих сетях. Кроме того, Celestia и EigenDA обещают низкие комиссии, потому что эти сети только работают, и их использование будет низким на начальном этапе. Когда эти сети DA достигают высокой загрузки, плата за DA также может стать непомерно высокой. По моему мнению, для подтверждения доступности данных накопительного пакета приложения должна использоваться простая плата Data Availability Board (DAC).
В заключение, я думаю, что роллапы приложений являются лучшим существующим решением для масштабирования приложений с высокой пропускной способностью, особенно полностью ончейн-игр. Расширение этих приложений с помощью Rollup является ключом к достижению массового внедрения за пределами нативных пользователей криптовалюты.