Обзор параллельных вычислений Web3: лучшее решение для нативного масштабирования?
Блокчейн "Треугольник невозможного" (Blockchain Trilemma) "безопасность", "децентрализация", "масштабируемость" раскрывает сущность компромиссов в дизайне блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достигать "максимальной безопасности, всеобъемлющего участия и высокой скорости обработки". Что касается вечной темы "масштабируемости", то на текущий момент основные решения для масштабирования блокчейна на рынке различаются по парадигмам, включая:
Выполнение улучшенного масштабирования: повышение исполнительной способности на месте, например, параллельно, с использованием GPU, многоядерных процессоров.
Изоляция состояния для масштабирования: горизонтальное разделение состояния/Shard, например, шардирование, UTXO, многоподсети
Внешняя масштабируемость типа аутсорсинга: выполнение вне цепи, например, Rollup, сопроцессор, DA
Структурно-рассогласованное расширение: модульная архитектура, совместная работа, например, модульные цепочки, общий сортировщик, Rollup Mesh
Асинхронное параллельное масштабирование: модель актора, изоляция процессов, управление сообщениями, например, агенты, многопоточная асинхронная цепочка
Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, модуль DA, модульную структуру, систему Actor, сжатие zk-доказательств, Stateless архитектуру и т.д., охватывая несколько уровней, таких как выполнение, состояние, данные и структура. Это полная система масштабирования, основанная на "многослойной кооперации и комбинации модулей". В данной статье основное внимание уделяется масштабированию с использованием параллельных вычислений как основного метода.
Внутренняя параллельная обработка ( intra-chain parallelism ), фокусирующаяся на параллельном выполнении транзакций/инструкций внутри блока. В зависимости от механизма параллелизма, способы масштабирования можно разделить на пять основных категорий, каждая из которых представляет собой разные стремления к производительности, модели разработки и архитектурные философии, при этом параллельная гранулярность становится все более тонкой, параллельная интенсивность становится все выше, сложность планирования также увеличивается, а программная сложность и сложность реализации становятся также все выше.
Уровень аккаунта (Account-level): представляет проект Solana
Объектный уровень (Object-level): представляет проект Sui
Уровень транзакций (Transaction-level): представляет проект Monad, Aptos
Вызов уровня / Микро ВМ параллельно(Call-level / MicroVM): представляет проект MegaETH
Инструктивный уровень параллелизма ( Instruction-level ): представляет проект GatlingX
Внецепочечная асинхронная конкурентная модель, представляемая системой интеллектуальных агентов Actor (Agent / Actor Model), относится к другой парадигме параллельных вычислений, как кросс-цепочечная/асинхронная система сообщений (неблокирующая синхронная модель), каждый агент выступает в роли независимого "интеллектуального процесса", асинхронно обрабатывающего сообщения и события, без необходимости в синхронном расписании, среди представленных проектов AO, ICP, Cartesi и др.
А известные нам решения по масштабированию, такие как Rollup или шардирование, относятся к механизмам системной параллельности и не являются параллельными вычислениями внутри цепи. Они достигают масштабирования за счет "параллельного выполнения нескольких цепей/исполнительных доменов", а не за счет повышения параллелизма внутри одного блока/виртуальной машины. Эти решения по масштабированию не являются основной темой данной статьи, но мы все же будем использовать их для сравнительного анализа архитектурных концепций.
II. EVM-система параллельного улучшения цепи: прорыв в производительности в условиях совместимости
Архитектура последовательной обработки Ethereum развивалась с момента своего создания, пройдя много этапов масштабирования, таких как шардирование, Rollup и модульная архитектура, но瓶颈 в пропускной способности уровня исполнения по-прежнему не был преодолен. В то же время EVM и Solidity продолжают оставаться самыми популярными платформами для смарт-контрактов с наибольшей базой разработчиков и экосистемным потенциалом. Поэтому параллельная цепь EVM, как ключевое направление, которое учитывает совместимость экосистемы и повышение производительности исполнения, становится важным направлением для следующего этапа масштабирования. Monad и MegaETH являются наиболее представительными проектами в этом направлении, которые, исходя из задержки исполнения и декомпозиции состояния, строят архитектуру параллельной обработки EVM, ориентированную на сценарии высокой конкурентности и высокой пропускной способности.
Анализ механизма параллельных вычислений Monad
Monad - это высокопроизводительная Layer1 блокчейн, заново спроектированная для виртуальной машины Ethereum (EVM), основанная на концепции параллельной обработки (Pipelining). Она использует асинхронное выполнение на уровне консенсуса (Asynchronous Execution) и оптимистичное параллельное выполнение на уровне исполнения (Optimistic Parallel Execution). Кроме того, на уровнях консенсуса и хранения Monad внедряет высокопроизводительный BFT протокол (MonadBFT) и специализированную систему баз данных (MonadDB), обеспечивая оптимизацию от конца до конца.
Пайплайн: Механизм параллельного выполнения многоступенчатого конвейера
Пайплайнинг является основным принципом параллельного выполнения Monad. Его основная идея заключается в том, чтобы разбить процесс выполнения в блокчейне на несколько независимых этапов и обрабатывать эти этапы параллельно, формируя многослойную архитектуру конвейера, где каждый этап работает в независимых потоках или ядрах, обеспечивая параллельную обработку между блоками и, в конечном итоге, достигая увеличения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (Propose), достижение консенсуса (Consensus), выполнение транзакции (Execution) и подтверждение блока (Commit).
Асинхронное выполнение: Консенсус - Асинхронная декомпозиция выполнения
В традиционных блокчейнах консенсус и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает расширяемость производительности. Monad реализует асинхронный консенсусный уровень, асинхронный уровень выполнения и асинхронное хранилище через "асинхронное выполнение". Это значительно уменьшает время блока (block time) и задержку подтверждения, делая систему более устойчивой, процессы более детализированными и использование ресурсов более эффективным.
Основной дизайн:
Процесс консенсуса ( уровень консенсуса ) отвечает только за упорядочение транзакций, не выполняя логики контрактов.
Процесс выполнения ( уровень выполнения ) будет асинхронно инициирован после завершения консенсуса.
После завершения консенсуса сразу же переходите к процессу консенсуса следующего блока, не дожидаясь завершения выполнения.
Оптимистичное параллельное выполнение:乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию "оптимистичного параллельного выполнения", значительно увеличивая скорость обработки транзакций.
Исполнительный механизм:
Monad будет оптимистично выполнять все транзакции параллельно, предполагая, что большинство транзакций не имеют конфликтов по состоянию.
Одновременно запустить "Конфликтный детектор(Conflict Detector)" для мониторинга того, обращались ли транзакции к одному и тому же состоянию(, как чтение/запись конфликты).
Если обнаружен конфликт, конфликтные транзакции будут сериализованы и повторно выполнены, чтобы обеспечить правильность состояния.
Monad выбрал совместимый путь: минимально изменяя правила EVM, достигать параллелизма в процессе выполнения за счет отложенной записи состояния и динамического обнаружения конфликтов, больше похоже на производительную версию Эфириума, с хорошей зрелостью и легкостью реализации миграции экосистемы EVM, является параллельным ускорителем мира EVM.
Механизм параллельных вычислений MegaETH
В отличие от L1 позиционирования Monad, MegaETH позиционируется как модульный высокопроизводительный параллельный уровень выполнения, совместимый с EVM, который может функционировать как независимая L1 публичная цепочка или как уровень улучшения выполнения на Ethereum (Execution Layer) или модульный компонент. Основная цель его проектирования заключается в том, чтобы изолировать и декомпозировать логику учетной записи, среду выполнения и состояние в минимальные единицы, которые могут независимо планироваться, чтобы достичь высокой конкурентной обработки и низкой задержки отклика в цепочке. Ключевое новшество, предложенное MegaETH, заключается в архитектуре Micro-VM + State Dependency DAG(направленный ациклический граф зависимостей состояния) и модульном механизме синхронизации, которые вместе создают параллельную систему выполнения, ориентированную на "потоковую обработку внутри цепочки".
Micro-VM(микровиртуальная машина)архитектура: аккаунт это поток
MegaETH вводит модель исполнения "микро-виртуальная машина для каждого аккаунта (Micro-VM)", которая "потокизирует" исполняющую среду, предоставляя минимальную единицу изоляции для параллельного планирования. Эти виртуальные машины общаются друг с другом через асинхронную передачу сообщений (Asynchronous Messaging), а не через синхронные вызовы, что позволяет множеству виртуальных машин независимо выполнять задачи и хранить данные, что обеспечивает естественную параллельность.
Зависимость состояния DAG: механизм планирования на основе графа зависимостей
MegaETH построила систему планирования DAG, основанную на доступе к состояниям аккаунтов. Система в реальном времени поддерживает глобальный граф зависимостей ( Dependency Graph ), каждая транзакция моделирует, какие аккаунты были изменены и какие аккаунты были прочитаны, все это строится в виде зависимостей. Транзакции без конфликтов могут выполняться параллельно, транзакции с зависимостями будут последовательно или отложенно упорядочены в соответствии с топологическим порядком. Граф зависимостей обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратных вызовов
MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контрактов являются асинхронными ( нерекурсивными ) выполнения, и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов (Call Graph); Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В общем, MegaETH ломает традиционную модель однопоточной машины состояний EVM, реализуя упаковку микро-виртуальных машин на уровне аккаунтов, выполняя планирование транзакций через графы зависимостей состояний и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это платформа параллельных вычислений, которая была полностью переработана от "структуры аккаунтов → архитектуры планирования → процесса выполнения", предлагая парадигмально новый подход к построению систем следующего поколения с высокой производительностью на блокчейне.
MegaETH выбрал путь реконструкции: полностью абстрагировал учетные записи и контракты в независимую виртуальную машину, используя асинхронное выполнение для раскрытия предельного параллелизма. Теоретически, параллельный предел MegaETH выше, но также труднее контролировать сложность, что больше похоже на суперраспределенную операционную систему в духе Ethereum.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разделяет блокчейн на несколько независимых подсетей (шарды Shards), каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения единой цепочки для масштабирования на сетевом уровне; в то время как Monad и MegaETH сохраняют целостность единой цепочки, лишь горизонтально масштабируя на уровне выполнения, оптимизируя производительность за счет предельного параллельного выполнения внутри единой цепочки. Оба представляют собой две направления в пути масштабирования блокчейна: вертикальное усиление и горизонтальное расширение.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, с основной целью повышения TPS в цепочке, реализуя параллельную обработку на уровне транзакций или учетных записей через отложенное выполнение (Deferred Execution) и архитектуру микровиртуальных машин (Micro-VM). Pharos Network, как модульная, полностековая параллельная сеть L1 блокчейна, имеет основную параллельную вычислительную механику, называемую "Rollup Mesh". Эта архитектура поддерживает многовиртуальную среду (EVM и Wasm) благодаря слаженной работе основной сети и специализированной сети обработки (SPNs) и интегрирует такие передовые технологии, как нулевые знания (ZK) и доверенные среды выполнения (TEE).
Анализ механизма параллельных вычислений Rollup Mesh:
Полный жизненный цикл асинхронной конвейерной обработки (Full Lifecycle Asynchronous Pipelining): Pharos разъединяет различные этапы сделки (, такие как консенсус, выполнение и хранение ), и использует асинхронный метод обработки, что позволяет каждому этапу выполняться независимо и параллельно, тем самым повышая общую эффективность обработки.
Двойное параллельное выполнение виртуальных машин (Dual VM Parallel Execution): Pharos поддерживает две среды виртуальных машин EVM и WASM, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от потребностей. Эта архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и улучшает способность обработки транзакций за счет параллельного выполнения.
Специальная обработка сети ( SPNs ): SPNs являются ключевыми компонентами архитектуры Pharos, подобными модульным подсетям, специально предназначенными для обработки определенных типов задач или приложений. С помощью SPNs Pharos может осуществлять динамическое распределение ресурсов и параллельную обработку задач, что еще больше увеличивает масштабируемость и производительность системы.
Модульный консенсус и механизм повторного стекинга(Modular Consensus & Restaking): Pharos вводит гибкий консенсус
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
7
Поделиться
комментарий
0/400
DarkPoolWatcher
· 23ч назад
Снова целая куча решений по масштабированию, стало весело.
Посмотреть ОригиналОтветить0
TokenBeginner'sGuide
· 07-27 10:48
Вежливое напоминание: так называемое увеличение емкости, изменения в базовой архитектуре несут 90% риска, рекомендуется трижды подумать.
Посмотреть ОригиналОтветить0
OnchainDetective
· 07-25 08:02
Этот план почти завершен.
Посмотреть ОригиналОтветить0
AirdropHarvester
· 07-25 08:02
Подождите, как вы смогли увеличить объем?
Посмотреть ОригиналОтветить0
ContractSurrender
· 07-25 08:01
Технология действительно не может решить проблемы с опытом.
Панорама параллельных вычислений Web3: Эволюция масштабирования от выполнения на цепочке до многосетевого сотрудничества
Обзор параллельных вычислений Web3: лучшее решение для нативного масштабирования?
Блокчейн "Треугольник невозможного" (Blockchain Trilemma) "безопасность", "децентрализация", "масштабируемость" раскрывает сущность компромиссов в дизайне блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достигать "максимальной безопасности, всеобъемлющего участия и высокой скорости обработки". Что касается вечной темы "масштабируемости", то на текущий момент основные решения для масштабирования блокчейна на рынке различаются по парадигмам, включая:
Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, модуль DA, модульную структуру, систему Actor, сжатие zk-доказательств, Stateless архитектуру и т.д., охватывая несколько уровней, таких как выполнение, состояние, данные и структура. Это полная система масштабирования, основанная на "многослойной кооперации и комбинации модулей". В данной статье основное внимание уделяется масштабированию с использованием параллельных вычислений как основного метода.
Внутренняя параллельная обработка ( intra-chain parallelism ), фокусирующаяся на параллельном выполнении транзакций/инструкций внутри блока. В зависимости от механизма параллелизма, способы масштабирования можно разделить на пять основных категорий, каждая из которых представляет собой разные стремления к производительности, модели разработки и архитектурные философии, при этом параллельная гранулярность становится все более тонкой, параллельная интенсивность становится все выше, сложность планирования также увеличивается, а программная сложность и сложность реализации становятся также все выше.
Внецепочечная асинхронная конкурентная модель, представляемая системой интеллектуальных агентов Actor (Agent / Actor Model), относится к другой парадигме параллельных вычислений, как кросс-цепочечная/асинхронная система сообщений (неблокирующая синхронная модель), каждый агент выступает в роли независимого "интеллектуального процесса", асинхронно обрабатывающего сообщения и события, без необходимости в синхронном расписании, среди представленных проектов AO, ICP, Cartesi и др.
А известные нам решения по масштабированию, такие как Rollup или шардирование, относятся к механизмам системной параллельности и не являются параллельными вычислениями внутри цепи. Они достигают масштабирования за счет "параллельного выполнения нескольких цепей/исполнительных доменов", а не за счет повышения параллелизма внутри одного блока/виртуальной машины. Эти решения по масштабированию не являются основной темой данной статьи, но мы все же будем использовать их для сравнительного анализа архитектурных концепций.
II. EVM-система параллельного улучшения цепи: прорыв в производительности в условиях совместимости
Архитектура последовательной обработки Ethereum развивалась с момента своего создания, пройдя много этапов масштабирования, таких как шардирование, Rollup и модульная архитектура, но瓶颈 в пропускной способности уровня исполнения по-прежнему не был преодолен. В то же время EVM и Solidity продолжают оставаться самыми популярными платформами для смарт-контрактов с наибольшей базой разработчиков и экосистемным потенциалом. Поэтому параллельная цепь EVM, как ключевое направление, которое учитывает совместимость экосистемы и повышение производительности исполнения, становится важным направлением для следующего этапа масштабирования. Monad и MegaETH являются наиболее представительными проектами в этом направлении, которые, исходя из задержки исполнения и декомпозиции состояния, строят архитектуру параллельной обработки EVM, ориентированную на сценарии высокой конкурентности и высокой пропускной способности.
Анализ механизма параллельных вычислений Monad
Monad - это высокопроизводительная Layer1 блокчейн, заново спроектированная для виртуальной машины Ethereum (EVM), основанная на концепции параллельной обработки (Pipelining). Она использует асинхронное выполнение на уровне консенсуса (Asynchronous Execution) и оптимистичное параллельное выполнение на уровне исполнения (Optimistic Parallel Execution). Кроме того, на уровнях консенсуса и хранения Monad внедряет высокопроизводительный BFT протокол (MonadBFT) и специализированную систему баз данных (MonadDB), обеспечивая оптимизацию от конца до конца.
Пайплайн: Механизм параллельного выполнения многоступенчатого конвейера
Пайплайнинг является основным принципом параллельного выполнения Monad. Его основная идея заключается в том, чтобы разбить процесс выполнения в блокчейне на несколько независимых этапов и обрабатывать эти этапы параллельно, формируя многослойную архитектуру конвейера, где каждый этап работает в независимых потоках или ядрах, обеспечивая параллельную обработку между блоками и, в конечном итоге, достигая увеличения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (Propose), достижение консенсуса (Consensus), выполнение транзакции (Execution) и подтверждение блока (Commit).
Асинхронное выполнение: Консенсус - Асинхронная декомпозиция выполнения
В традиционных блокчейнах консенсус и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает расширяемость производительности. Monad реализует асинхронный консенсусный уровень, асинхронный уровень выполнения и асинхронное хранилище через "асинхронное выполнение". Это значительно уменьшает время блока (block time) и задержку подтверждения, делая систему более устойчивой, процессы более детализированными и использование ресурсов более эффективным.
Основной дизайн:
Оптимистичное параллельное выполнение:乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию "оптимистичного параллельного выполнения", значительно увеличивая скорость обработки транзакций.
Исполнительный механизм:
Monad выбрал совместимый путь: минимально изменяя правила EVM, достигать параллелизма в процессе выполнения за счет отложенной записи состояния и динамического обнаружения конфликтов, больше похоже на производительную версию Эфириума, с хорошей зрелостью и легкостью реализации миграции экосистемы EVM, является параллельным ускорителем мира EVM.
Механизм параллельных вычислений MegaETH
В отличие от L1 позиционирования Monad, MegaETH позиционируется как модульный высокопроизводительный параллельный уровень выполнения, совместимый с EVM, который может функционировать как независимая L1 публичная цепочка или как уровень улучшения выполнения на Ethereum (Execution Layer) или модульный компонент. Основная цель его проектирования заключается в том, чтобы изолировать и декомпозировать логику учетной записи, среду выполнения и состояние в минимальные единицы, которые могут независимо планироваться, чтобы достичь высокой конкурентной обработки и низкой задержки отклика в цепочке. Ключевое новшество, предложенное MegaETH, заключается в архитектуре Micro-VM + State Dependency DAG(направленный ациклический граф зависимостей состояния) и модульном механизме синхронизации, которые вместе создают параллельную систему выполнения, ориентированную на "потоковую обработку внутри цепочки".
Micro-VM(микровиртуальная машина)архитектура: аккаунт это поток
MegaETH вводит модель исполнения "микро-виртуальная машина для каждого аккаунта (Micro-VM)", которая "потокизирует" исполняющую среду, предоставляя минимальную единицу изоляции для параллельного планирования. Эти виртуальные машины общаются друг с другом через асинхронную передачу сообщений (Asynchronous Messaging), а не через синхронные вызовы, что позволяет множеству виртуальных машин независимо выполнять задачи и хранить данные, что обеспечивает естественную параллельность.
Зависимость состояния DAG: механизм планирования на основе графа зависимостей
MegaETH построила систему планирования DAG, основанную на доступе к состояниям аккаунтов. Система в реальном времени поддерживает глобальный граф зависимостей ( Dependency Graph ), каждая транзакция моделирует, какие аккаунты были изменены и какие аккаунты были прочитаны, все это строится в виде зависимостей. Транзакции без конфликтов могут выполняться параллельно, транзакции с зависимостями будут последовательно или отложенно упорядочены в соответствии с топологическим порядком. Граф зависимостей обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратных вызовов
MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контрактов являются асинхронными ( нерекурсивными ) выполнения, и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов (Call Graph); Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В общем, MegaETH ломает традиционную модель однопоточной машины состояний EVM, реализуя упаковку микро-виртуальных машин на уровне аккаунтов, выполняя планирование транзакций через графы зависимостей состояний и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это платформа параллельных вычислений, которая была полностью переработана от "структуры аккаунтов → архитектуры планирования → процесса выполнения", предлагая парадигмально новый подход к построению систем следующего поколения с высокой производительностью на блокчейне.
MegaETH выбрал путь реконструкции: полностью абстрагировал учетные записи и контракты в независимую виртуальную машину, используя асинхронное выполнение для раскрытия предельного параллелизма. Теоретически, параллельный предел MegaETH выше, но также труднее контролировать сложность, что больше похоже на суперраспределенную операционную систему в духе Ethereum.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разделяет блокчейн на несколько независимых подсетей (шарды Shards), каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения единой цепочки для масштабирования на сетевом уровне; в то время как Monad и MegaETH сохраняют целостность единой цепочки, лишь горизонтально масштабируя на уровне выполнения, оптимизируя производительность за счет предельного параллельного выполнения внутри единой цепочки. Оба представляют собой две направления в пути масштабирования блокчейна: вертикальное усиление и горизонтальное расширение.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, с основной целью повышения TPS в цепочке, реализуя параллельную обработку на уровне транзакций или учетных записей через отложенное выполнение (Deferred Execution) и архитектуру микровиртуальных машин (Micro-VM). Pharos Network, как модульная, полностековая параллельная сеть L1 блокчейна, имеет основную параллельную вычислительную механику, называемую "Rollup Mesh". Эта архитектура поддерживает многовиртуальную среду (EVM и Wasm) благодаря слаженной работе основной сети и специализированной сети обработки (SPNs) и интегрирует такие передовые технологии, как нулевые знания (ZK) и доверенные среды выполнения (TEE).
Анализ механизма параллельных вычислений Rollup Mesh: