Полный обзор параллельных вычислений в Web3: лучшее решение для нативного масштабирования?
«Невозможный треугольник» блокчейна (Blockchain Trilemma) — «безопасность», «децентрализация», «масштабируемость» — раскрывает сущностные компромиссы в проектировании блокчейн-систем, а именно, что блокчейн-проектам трудно одновременно добиться «максимальной безопасности, доступности для всех, высокой скорости обработки». Что касается «масштабируемости», этой вечной темы, на данный момент основные решения по масштабированию блокчейна на рынке можно классифицировать по парадигмам, включая:
Выполнение улучшенного масштабирования: повышение вычислительных возможностей на месте, например, параллельная обработка, GPU, многопроцессорность.
Изоляция состояния для увеличения масштабируемости: горизонтальное разделение состояния / Shard, например, шардирование, UTXO, многоподсеть
Внешняя аутсорсинговая масштабируемость: выполнение вне цепочки, например Rollup, Копрцессор, DA
Декуплированное расширение структуры: модульная архитектура, совместная работа, например, модульная цепь, общий сортировщик, Rollup Mesh
Асинхронное конкурентное масштабирование: модель Акторов, изоляция процессов, управление сообщениями, например, агенты, многопоточное асинхронное соединение
Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, DA модули, модульную структуру, систему Actor, сжатие zk-доказательств, безсостояние архитектуры и т.д., охватывающие несколько уровней исполнения, состояния, данных и структуры, представляя собой «многослойную координацию, модульное сочетание» полную систему масштабирования. В данной статье уделяется особое внимание масштабированию, основанному на параллельных вычислениях.
Внутренняя параллельная обработка (intra-chain parallelism), сосредоточенная на параллельном выполнении транзакций / инструкций внутри блока. По механизмам параллелизма способы увеличения пропускной способности можно разделить на пять основных категорий, каждая из которых представляет собой разные цели производительности, модели разработки и архитектурные философии, с каждым разом параллельный уровень становится все более детализированным, интенсивность параллелизма возрастает, сложность планирования также увеличивается, а сложность программирования и реализации становится все выше.
Уровень аккаунта параллельно (Account-level): представляет проект Solana
Уровень объектов параллельно (Object-level): представляет проект Sui
Уровень транзакций (Transaction-level): представляет проект Monad, Aptos
Уровень вызова / Параллельная микро-ВМ (Call-level / MicroVM): представляет проект MegaETH
Параллелизм на уровне инструкций (Instruction-level): представляет проект GatlingX
Внецепочечная асинхронная конкурентная модель, представляемая системой интеллектуальных агентов (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), реализуя оптимизацию от конца до конца.
Параллельное выполнение многоступенчатого конвейера
Пайплайнинг является основной идеей параллельного выполнения монады, и его核心思想 заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обработать эти этапы параллельно, создавая трехмерную архитектуру конвейера. Каждый этап работает в независимом потоке или ядре, обеспечивая параллельную обработку между блоками и в конечном итоге достигая повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (Propose), достижение консенсуса (Consensus), выполнение транзакции (Execution) и подтверждение блока (Commit).
Асинхронное выполнение: Консенсус - Асинхронное разъединение выполнения
В традиционных блокчейнах согласование транзакций и их выполнение обычно являются синхронными процессами, и такая последовательная модель серьезно ограничивает возможности масштабирования производительности. Monad реализует асинхронность на уровне согласования, асинхронность на уровне выполнения и асинхронность в хранении через «асинхронное выполнение». Это значительно снижает время блока (block time) и задержку подтверждения, делает систему более устойчивой, процесс обработки более детализированным и более эффективным использованием ресурсов.
Ядро дизайна:
Процесс консенсуса (уровень консенсуса) отвечает только за сортировку транзакций, не выполняя логику контрактов.
Процесс выполнения (уровень выполнения) асинхронно запускается после завершения консенсуса.
После завершения консенсуса сразу же переходит к процессу консенсуса следующего блока, не дожидаясь завершения исполнения.
Оптимистичное параллельное выполнение：乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию «оптимистичного параллельного выполнения», значительно увеличивая скорость обработки транзакций.
Механизм выполнения:
Monad будет оптимистично параллельно выполнять все транзакции, предполагая, что между большинством транзакций нет конфликтов состояния.
Запустить «Детектор конфликтов (Conflict Detector))», чтобы отслеживать, обращались ли транзакции к одному и тому же состоянию (например, конфликты чтения/записи).
Если обнаружен конфликт, конфликтные транзакции будут сериализованы и выполнены повторно, чтобы обеспечить корректность состояния.
Monad выбрал совместимый путь: минимально изменяя правила EVM, он реализует параллелизм за счет отложенной записи состояния и динамического обнаружения конфликтов, больше похож на производительную версию Ethereum, с хорошей зрелостью, что облегчает миграцию экосистемы EVM, являясь параллельным ускорителем мира EVM.
Анализ механизма параллельных вычислений MegaETH
В отличие от позиционирования L1, основанного на Monad, MegaETH позиционируется как модульный высокопроизводительный уровень параллельного выполнения, совместимый с EVM, который может функционировать как независимая L1 публичная цепочка, так и как уровень улучшенного исполнения (Execution Layer) на Ethereum или модульный компонент. Его основной дизайн-цель заключается в разбиении логики аккаунтов, окружения исполнения и состояния на изолированные минимальные единицы, которые могут независимо планироваться, чтобы обеспечить высокую параллельную обработку и низкую задержку отклика внутри цепи. Ключевое новшество, предложенное MegaETH, заключается в архитектуре Micro-VM + DAG зависимостей состояния (Directed Acyclic Graph) и модульном механизме синхронизации, которые вместе создают параллельную систему исполнения, ориентированную на "потоковую обработку внутри цепи".
Архитектура Micro-VM (микровиртуальная машина): учетная запись как поток
MegaETH внедряет модель выполнения «один микро-виртуальный машина (Micro-VM) на каждую учетную запись», что делает исполняемую среду «поточной», предоставляя минимальную единицу изоляции для параллельного планирования. Эти ВМ общаются друг с другом через асинхронные сообщения (Asynchronous Messaging), а не через синхронные вызовы, что позволяет множеству ВМ выполнять задачи независимо и хранить данные независимо, что обеспечивает естественную параллельность.
Зависимость состояния DAG: механизм планирования на основе графа зависимостей
MegaETH создала систему планирования DAG, основанную на отношениях доступа к состояниям аккаунтов, которая в реальном времени поддерживает глобальный граф зависимостей (Dependency Graph). Каждая транзакция моделируется как зависимость, указывая, какие аккаунты были изменены и какие аккаунты были прочитаны. Нес конфликтные транзакции могут выполняться параллельно, в то время как транзакции с зависимостями будут упорядочены и запланированы последовательно или отложены по топологическому порядку. Граф зависимостей обеспечивает согласованность состояния и недублируемую запись в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратных вызовов
MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контракта являются асинхронными (нерекурсивное выполнение), и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В общем, MegaETH нарушает традиционную модель однопоточной машины состояний EVM, реализуя упаковку микро-виртуальных машин на уровне учетных записей, выполняя планирование транзакций через графы зависимостей состояний и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, заново спроектированная по всем параметрам от «структуры учетной записи → архитектуры планирования → процесса выполнения», предлагающая парадигмально новый подход к созданию систем следующего поколения с высокой производительностью на цепочке.
MegaETH выбрал путь реконструкции: полностью абстрагировать аккаунты и контракты в независимую VM, используя асинхронное выполнение для раскрытия предельного параллельного потенциала. Теоретически, параллельный предел MegaETH выше, но также сложнее контролировать сложность, больше напоминает суперраспределённую операционную систему в духе Эфириума.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разбивает блокчейн на несколько независимых дочерних цепочек (шарды Shards), каждая из которых отвечает за часть транзакций и состояния, преодолевая ограничения одиночной цепи на уровне сети; в то время как Monad и MegaETH сохраняют целостность одиночной цепи, только на уровне исполнения происходит горизонтальное масштабирование, что позволяет оптимизировать параллальное выполнение внутри одиночной цепи для повышения производительности. Оба представляют собой вертикальное усиление и горизонтальное масштабирование в путях расширения блокчейна.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности с целью повышения TPS внутри цепочки. Это достигается через отложенное выполнение (Deferred Execution) и архитектуру микро-виртуальной машины (Micro-VM), позволяющую осуществлять параллельную обработку на уровне транзакций или аккаунтов. Pharos Network, в свою очередь, является модульной, полнофункциональной параллельной L1 блокчейн-сетью, и ее основная параллельная вычислительная механика называется «Rollup Mesh». Эта архитектура поддерживает совместную работу основной сети и специальных сетей обработки (SPNs), поддерживает многовиртуальную среду (EVM и Wasm) и интегрирует передовые технологии, такие как нулевые знания (ZK) и доверенная вычислительная среда (TEE).
Анализ механизма параллельных вычислений Rollup Mesh:
Полный жизненный цикл асинхронной конвейерной обработки (Full Lifecycle Asynchronous Pipelining): Pharos декомпозирует различные этапы транзакции (такие как консенсус, выполнение, хранение) и использует асинхронный способ обработки, позволяя каждому этапу выполняться независимо и параллельно, что повышает общую эффективность обработки.
Параллельное выполнение двух виртуальных машин (Dual VM Parallel Execution): Pharos поддерживает две среды виртуальных машин EVM и WASM, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от требований. Эта архитектура с двумя ВМ не только повышает гибкость системы, но и увеличивает способность обработки транзакций за счет параллельного выполнения.
Специальные сети (SPN): SPN являются ключевыми компонентами архитектуры Pharos, похожими на модульные подсети, специально предназначенные для обработки определенных типов задач или приложений. С помощью SPN Pharos может реализовать динамическое распределение ресурсов и параллельную обработку задач, что дополнительно повышает масштабируемость и производительность системы.
Модульный консенсус и механизм повторной ставки (Modular Consensus & Restaking): Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса (такие как PBFT, PoS, PoA), и через протокол повторной ставки (
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
20 Лайков
Награда
20
8
Репост
Поделиться
комментарий
0/400
GweiTooHigh
· 08-18 06:19
Уже 3.0, а этот tps все еще вызывает головную боль.
Посмотреть ОригиналОтветить0
GateUser-9ad11037
· 08-17 19:08
Мошенничество GPU
Посмотреть ОригиналОтветить0
OvertimeSquid
· 08-17 03:00
Треугольник можно выбрать только два, и нужно, чтобы лошадь бегала, и чтобы лошадь не ела траву.
Посмотреть ОригиналОтветить0
AirdropHunter
· 08-16 13:23
Чёрное и белое всегда нужно выбирать одну сторону, разве это не жертва Децентрализации?
Посмотреть ОригиналОтветить0
PretendingSerious
· 08-15 14:29
Никто не может взломать треугольник, этот путь зависит от того, кто побежит первым.
Посмотреть ОригиналОтветить0
Ser_APY_2000
· 08-15 14:29
в блокчейне tps целый день кричат, в чем смысл
Посмотреть ОригиналОтветить0
0xOverleveraged
· 08-15 14:10
Слишком много специализированных терминов, каждый день новые концепции.
Посмотреть ОригиналОтветить0
TokenToaster
· 08-15 14:09
Не все проблемы можно решить с помощью Rollup. Розничным инвесторам лучше не думать слишком много.
Полный анализ параллельных вычислений Web3: от масштабирования EVM до Rollup Mesh
Полный обзор параллельных вычислений в Web3: лучшее решение для нативного масштабирования?
«Невозможный треугольник» блокчейна (Blockchain Trilemma) — «безопасность», «децентрализация», «масштабируемость» — раскрывает сущностные компромиссы в проектировании блокчейн-систем, а именно, что блокчейн-проектам трудно одновременно добиться «максимальной безопасности, доступности для всех, высокой скорости обработки». Что касается «масштабируемости», этой вечной темы, на данный момент основные решения по масштабированию блокчейна на рынке можно классифицировать по парадигмам, включая:
Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, DA модули, модульную структуру, систему Actor, сжатие zk-доказательств, безсостояние архитектуры и т.д., охватывающие несколько уровней исполнения, состояния, данных и структуры, представляя собой «многослойную координацию, модульное сочетание» полную систему масштабирования. В данной статье уделяется особое внимание масштабированию, основанному на параллельных вычислениях.
Внутренняя параллельная обработка (intra-chain parallelism), сосредоточенная на параллельном выполнении транзакций / инструкций внутри блока. По механизмам параллелизма способы увеличения пропускной способности можно разделить на пять основных категорий, каждая из которых представляет собой разные цели производительности, модели разработки и архитектурные философии, с каждым разом параллельный уровень становится все более детализированным, интенсивность параллелизма возрастает, сложность планирования также увеличивается, а сложность программирования и реализации становится все выше.
Внецепочечная асинхронная конкурентная модель, представляемая системой интеллектуальных агентов (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), реализуя оптимизацию от конца до конца.
Параллельное выполнение многоступенчатого конвейера
Пайплайнинг является основной идеей параллельного выполнения монады, и его核心思想 заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обработать эти этапы параллельно, создавая трехмерную архитектуру конвейера. Каждый этап работает в независимом потоке или ядре, обеспечивая параллельную обработку между блоками и в конечном итоге достигая повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (Propose), достижение консенсуса (Consensus), выполнение транзакции (Execution) и подтверждение блока (Commit).
Асинхронное выполнение: Консенсус - Асинхронное разъединение выполнения
В традиционных блокчейнах согласование транзакций и их выполнение обычно являются синхронными процессами, и такая последовательная модель серьезно ограничивает возможности масштабирования производительности. Monad реализует асинхронность на уровне согласования, асинхронность на уровне выполнения и асинхронность в хранении через «асинхронное выполнение». Это значительно снижает время блока (block time) и задержку подтверждения, делает систему более устойчивой, процесс обработки более детализированным и более эффективным использованием ресурсов.
Ядро дизайна:
Оптимистичное параллельное выполнение：乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию «оптимистичного параллельного выполнения», значительно увеличивая скорость обработки транзакций.
Механизм выполнения:
Monad выбрал совместимый путь: минимально изменяя правила EVM, он реализует параллелизм за счет отложенной записи состояния и динамического обнаружения конфликтов, больше похож на производительную версию Ethereum, с хорошей зрелостью, что облегчает миграцию экосистемы EVM, являясь параллельным ускорителем мира EVM.
Анализ механизма параллельных вычислений MegaETH
В отличие от позиционирования L1, основанного на Monad, MegaETH позиционируется как модульный высокопроизводительный уровень параллельного выполнения, совместимый с EVM, который может функционировать как независимая L1 публичная цепочка, так и как уровень улучшенного исполнения (Execution Layer) на Ethereum или модульный компонент. Его основной дизайн-цель заключается в разбиении логики аккаунтов, окружения исполнения и состояния на изолированные минимальные единицы, которые могут независимо планироваться, чтобы обеспечить высокую параллельную обработку и низкую задержку отклика внутри цепи. Ключевое новшество, предложенное MegaETH, заключается в архитектуре Micro-VM + DAG зависимостей состояния (Directed Acyclic Graph) и модульном механизме синхронизации, которые вместе создают параллельную систему исполнения, ориентированную на "потоковую обработку внутри цепи".
Архитектура Micro-VM (микровиртуальная машина): учетная запись как поток
MegaETH внедряет модель выполнения «один микро-виртуальный машина (Micro-VM) на каждую учетную запись», что делает исполняемую среду «поточной», предоставляя минимальную единицу изоляции для параллельного планирования. Эти ВМ общаются друг с другом через асинхронные сообщения (Asynchronous Messaging), а не через синхронные вызовы, что позволяет множеству ВМ выполнять задачи независимо и хранить данные независимо, что обеспечивает естественную параллельность.
Зависимость состояния DAG: механизм планирования на основе графа зависимостей
MegaETH создала систему планирования DAG, основанную на отношениях доступа к состояниям аккаунтов, которая в реальном времени поддерживает глобальный граф зависимостей (Dependency Graph). Каждая транзакция моделируется как зависимость, указывая, какие аккаунты были изменены и какие аккаунты были прочитаны. Нес конфликтные транзакции могут выполняться параллельно, в то время как транзакции с зависимостями будут упорядочены и запланированы последовательно или отложены по топологическому порядку. Граф зависимостей обеспечивает согласованность состояния и недублируемую запись в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратных вызовов
MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контракта являются асинхронными (нерекурсивное выполнение), и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В общем, MegaETH нарушает традиционную модель однопоточной машины состояний EVM, реализуя упаковку микро-виртуальных машин на уровне учетных записей, выполняя планирование транзакций через графы зависимостей состояний и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, заново спроектированная по всем параметрам от «структуры учетной записи → архитектуры планирования → процесса выполнения», предлагающая парадигмально новый подход к созданию систем следующего поколения с высокой производительностью на цепочке.
MegaETH выбрал путь реконструкции: полностью абстрагировать аккаунты и контракты в независимую VM, используя асинхронное выполнение для раскрытия предельного параллельного потенциала. Теоретически, параллельный предел MegaETH выше, но также сложнее контролировать сложность, больше напоминает суперраспределённую операционную систему в духе Эфириума.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разбивает блокчейн на несколько независимых дочерних цепочек (шарды Shards), каждая из которых отвечает за часть транзакций и состояния, преодолевая ограничения одиночной цепи на уровне сети; в то время как Monad и MegaETH сохраняют целостность одиночной цепи, только на уровне исполнения происходит горизонтальное масштабирование, что позволяет оптимизировать параллальное выполнение внутри одиночной цепи для повышения производительности. Оба представляют собой вертикальное усиление и горизонтальное масштабирование в путях расширения блокчейна.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности с целью повышения TPS внутри цепочки. Это достигается через отложенное выполнение (Deferred Execution) и архитектуру микро-виртуальной машины (Micro-VM), позволяющую осуществлять параллельную обработку на уровне транзакций или аккаунтов. Pharos Network, в свою очередь, является модульной, полнофункциональной параллельной L1 блокчейн-сетью, и ее основная параллельная вычислительная механика называется «Rollup Mesh». Эта архитектура поддерживает совместную работу основной сети и специальных сетей обработки (SPNs), поддерживает многовиртуальную среду (EVM и Wasm) и интегрирует передовые технологии, такие как нулевые знания (ZK) и доверенная вычислительная среда (TEE).
Анализ механизма параллельных вычислений Rollup Mesh: