Панорамная карта сектора параллельных вычислений 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
Уровень вызова / МикроVM (Call-level / MicroVM): представляет проект MegaETH
Инструкционно-уровневое параллелизм (Instruction-level): представляет проект GatlingX
Внецепочечная асинхронная параллельная модель, представленная системой агентов (Agent / Actor Model), принадлежит к другой парадигме параллельных вычислений, выступая в качестве межцепочечных/асинхронных сообщений (не блокирующая синхронная модель). Каждый агент функционирует как независимый "агентный процесс", работающий в асинхронном режиме, основанном на сообщениях и управляемом событиями, без необходимости синхронного планирования. Представленные проекты включают AO, ICP, Cartesi и другие.
А широко известные нам решения по масштабированию, такие как Rollup или шардирование, относятся к механизмам системной параллельности, а не к параллельным вычислениям внутри цепи. Они достигают масштабирования за счет "параллельного выполнения нескольких цепочек/исполнительных доменов", а не за счет повышения параллелизма внутри одного блока/виртуальной машины. Данные решения по масштабированию не являются основной темой данной статьи, однако мы все же будем использовать их для сравнительного анализа архитектурных концепций.
Два, EVM-система параллельного улучшения цепочки: прорыв границ производительности в совместимости
Архитектура последовательной обработки Ethereum с тех пор, как она развивалась, пережила множество попыток масштабирования, включая шардирование, Rollup и модульные архитектуры, но узкое место в пропускной способности слоя исполнения по-прежнему не преодолеваемо. В то же время EVM и Solidity по-прежнему являются наиболее развитыми платформами для смарт-контрактов с точки зрения базы разработчиков и экосистемного потенциала. Таким образом, параллельные улучшенные цепочки на основе EVM, которые учитывают как совместимость экосистемы, так и повышение производительности исполнения, становятся важным направлением новой волны масштабирования. Monad и MegaETH — это наиболее репрезентативные проекты в этом направлении, которые, начиная с отложенного исполнения и разложения состояния, строят архитектуру параллельной обработки EVM, ориентированную на сценарии с высокой параллельностью и высокой пропускной способностью.
Анализ механизма параллельных вычислений Monad
Monad — это высокопроизводительная блокчейн-сеть Layer1, переработанная для виртуальной машины Ethereum (EVM), основанная на основной параллельной концепции конвейерной обработки (Pipelining), с асинхронным исполнением на уровне консенсуса (Asynchronous Execution) и оптимистическим параллельным исполнением (Optimistic Parallel Execution) на уровне исполнения. Кроме того, на уровне консенсуса и хранения Monad вводит высокопроизводительный BFT-протокол (MonadBFT) и специализированную систему баз данных (MonadDB), что обеспечивает оптимизацию от конца до конца.
Пайплайнинг: механизм параллельного выполнения многоступенчатого конвейера
Пайплайн (Pipelining) является основной идеей параллельного выполнения монад, которая заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обрабатывать эти этапы параллельно, создавая многослойную архитектуру конвейера. Каждый этап работает в независимом потоке или ядре, что позволяет осуществлять параллельную обработку между блоками и, в конечном итоге, достигает повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (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 + направленном ациклическом графе зависимостей состояния (State Dependency DAG) и модульном механизме синхронизации, которые вместе создают параллельную систему выполнения, ориентированную на "потоковость внутри цепи".
Архитектура Micro-VM (микровиртуальная машина): аккаунт - это поток
MegaETH вводит модель выполнения "микровиртуальной машины (Micro-VM) для каждого аккаунта", которая "параллелизует" среду выполнения и предоставляет минимальную единицу изоляции для параллельного планирования. Эти VM общаются друг с другом через асинхронное сообщение (Asynchronous Messaging), а не синхронные вызовы, что позволяет множеству VM выполнять задачи независимо и хранить данные отдельно, обеспечивая естественную параллельность.
Зависимость состояния DAG: механизм планирования на основе графа зависимостей
MegaETH построила DAG-систему планирования, основанную на доступе к состоянию аккаунтов, которая в реальном времени поддерживает глобальный граф зависимостей (Dependency Graph). Каждая транзакция моделирует, какие аккаунты изменяются, какие считываются, все это представляется в виде зависимостей. Транзакции без конфликтов могут выполняться параллельно, а транзакции с зависимостями будут последовательно или с задержкой упорядочены по топологическому порядку. Граф зависимостей обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратных вызовов
MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контракта являются асинхронными (нерекурсивное выполнение), и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В заключение, MegaETH разрушает традиционную модель однопоточной машины состояний EVM, реализуя микро-виртуальную машину в упаковке на уровне аккаунта, используя граф зависимости состояния для планирования транзакций и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, которая была полностью переработана в измерениях "структура аккаунта → архитектура планирования → процесс выполнения", предоставляя парадигмальный новый подход для создания систем следующего поколения с высокой производительностью на блокчейне.
MegaETH выбрал путь реконструкции: полностью абстрагируя аккаунты и контракты в независимую виртуальную машину, с помощью асинхронного выполнения задач для освобождения предельного потенциала параллелизма. Теоретически, параллельный предел MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему по принципам Ethereum.
Дизайны Monad и MegaETH значительно отличаются от концепции шардирования (Sharding): шардирование разбивает блокчейн на несколько независимых подсетей (шарды), каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения одноцепочечной архитектуры на уровне сети; тогда как 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, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от их потребностей. Эта архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и улучшает способность обработки транзакций за счет параллельного выполнения.
Специальные сетевые обработки (SPNs): SPNs являются ключевыми компонентами архитектуры Pharos, аналогичными модульным подсетям, специально предназначенным для обработки определенных типов задач или приложений. С помощью SPNs Pharos может реализовать динамическое распределение ресурсов и параллельную обработку задач, что дополнительно повышает масштабируемость и производительность системы.
Модульный консенсус и механизм повторного залога (Modular Consensus & Restaking): Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса (такие как PBFT, PoS, PoA), и реализует безопасное совместное использование и интеграцию ресурсов между основной сетью и SPN через протокол повторного залога (Restaking).
Кроме того, Pharos с помощью технологий многоверсионного дерева Меркла, дельта-кодирования, адресации версий и ADS-подсистемы (ADS Pushdown) реконструировал модель выполнения на основе хранилища, выпустив высокопроизводительный нативный блокчейн-хранилище Pharos Store, обеспечивающее высокую пропускную способность, низкую задержку и сильную проверяемость способности обработки на цепочке.
В общем, Phar
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
7
Поделиться
комментарий
0/400
TrustlessMaximalist
· 8ч назад
Снова говорят о масштабировании, о чем тут можно говорить?
Посмотреть ОригиналОтветить0
SolidityStruggler
· 8ч назад
Снова речь идет о масштабировании, все L1 используют параллелизм для спасения.
Посмотреть ОригиналОтветить0
SchrodingerProfit
· 8ч назад
Блокчейн到底是想多快?四种方案看懵了...
Посмотреть ОригиналОтветить0
DisillusiionOracle
· 8ч назад
Нет денег, нет масштабов.
Посмотреть ОригиналОтветить0
TokenomicsTherapist
· 8ч назад
Снова играем в теорию.
Посмотреть ОригиналОтветить0
HalfIsEmpty
· 8ч назад
Чья-то семья решила треугольную невозможность, я прямо в все!
Web3 параллельные вычисления: пять основных парадигм масштабирования и сравнение с высокопроизводительными цепочками на EVM
Панорамная карта сектора параллельных вычислений Web3: лучшее решение для нативного масштабирования?
«Невозможный треугольник» блокчейна (Blockchain Trilemma) «безопасность», «децентрализация», «масштабируемость» раскрывает сущностную компромиссу в проектировании блокчейн-систем, а именно, что блокчейн-проектам сложно одновременно достичь «максимальной безопасности, доступности для всех, высокой скорости обработки». Что касается вечной темы «масштабируемости», то на текущем рынке основные решения для масштабирования блокчейна различаются по парадигмам, включая:
Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепочки, Rollup, шардирование, DA-модули, модульную структуру, систему Actor, сжатие zk-доказательств, архитектуру без состояния и т.д., охватывающие несколько уровней: исполнение, состояние, данные, структуру, что представляет собой "многоуровневую координацию и модульную комбинацию" полноценной системы масштабирования. В данной статье основное внимание уделяется масштабированию, основанному на параллельных вычислениях.
Внутренняя параллельная обработка ( intra-chain parallelism ), сосредоточенная на параллельном выполнении транзакций/инструкций внутри блока. В зависимости от механизма параллелизма, способы масштабирования можно разделить на пять основных категорий, каждая из которых представляет собой разные цели производительности, модели разработки и архитектурные философии, при этом степень параллелизма становится все более тонкой, интенсивность параллелизма возрастает, сложность планирования также увеличивается, а сложность программирования и трудность реализации также возрастают.
Внецепочечная асинхронная параллельная модель, представленная системой агентов (Agent / Actor Model), принадлежит к другой парадигме параллельных вычислений, выступая в качестве межцепочечных/асинхронных сообщений (не блокирующая синхронная модель). Каждый агент функционирует как независимый "агентный процесс", работающий в асинхронном режиме, основанном на сообщениях и управляемом событиями, без необходимости синхронного планирования. Представленные проекты включают AO, ICP, Cartesi и другие.
А широко известные нам решения по масштабированию, такие как Rollup или шардирование, относятся к механизмам системной параллельности, а не к параллельным вычислениям внутри цепи. Они достигают масштабирования за счет "параллельного выполнения нескольких цепочек/исполнительных доменов", а не за счет повышения параллелизма внутри одного блока/виртуальной машины. Данные решения по масштабированию не являются основной темой данной статьи, однако мы все же будем использовать их для сравнительного анализа архитектурных концепций.
Два, EVM-система параллельного улучшения цепочки: прорыв границ производительности в совместимости
Архитектура последовательной обработки Ethereum с тех пор, как она развивалась, пережила множество попыток масштабирования, включая шардирование, Rollup и модульные архитектуры, но узкое место в пропускной способности слоя исполнения по-прежнему не преодолеваемо. В то же время EVM и Solidity по-прежнему являются наиболее развитыми платформами для смарт-контрактов с точки зрения базы разработчиков и экосистемного потенциала. Таким образом, параллельные улучшенные цепочки на основе EVM, которые учитывают как совместимость экосистемы, так и повышение производительности исполнения, становятся важным направлением новой волны масштабирования. Monad и MegaETH — это наиболее репрезентативные проекты в этом направлении, которые, начиная с отложенного исполнения и разложения состояния, строят архитектуру параллельной обработки EVM, ориентированную на сценарии с высокой параллельностью и высокой пропускной способностью.
Анализ механизма параллельных вычислений Monad
Monad — это высокопроизводительная блокчейн-сеть Layer1, переработанная для виртуальной машины Ethereum (EVM), основанная на основной параллельной концепции конвейерной обработки (Pipelining), с асинхронным исполнением на уровне консенсуса (Asynchronous Execution) и оптимистическим параллельным исполнением (Optimistic Parallel Execution) на уровне исполнения. Кроме того, на уровне консенсуса и хранения Monad вводит высокопроизводительный BFT-протокол (MonadBFT) и специализированную систему баз данных (MonadDB), что обеспечивает оптимизацию от конца до конца.
Пайплайнинг: механизм параллельного выполнения многоступенчатого конвейера
Пайплайн (Pipelining) является основной идеей параллельного выполнения монад, которая заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обрабатывать эти этапы параллельно, создавая многослойную архитектуру конвейера. Каждый этап работает в независимом потоке или ядре, что позволяет осуществлять параллельную обработку между блоками и, в конечном итоге, достигает повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (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 + направленном ациклическом графе зависимостей состояния (State Dependency DAG) и модульном механизме синхронизации, которые вместе создают параллельную систему выполнения, ориентированную на "потоковость внутри цепи".
Архитектура Micro-VM (микровиртуальная машина): аккаунт - это поток
MegaETH вводит модель выполнения "микровиртуальной машины (Micro-VM) для каждого аккаунта", которая "параллелизует" среду выполнения и предоставляет минимальную единицу изоляции для параллельного планирования. Эти VM общаются друг с другом через асинхронное сообщение (Asynchronous Messaging), а не синхронные вызовы, что позволяет множеству VM выполнять задачи независимо и хранить данные отдельно, обеспечивая естественную параллельность.
Зависимость состояния DAG: механизм планирования на основе графа зависимостей
MegaETH построила DAG-систему планирования, основанную на доступе к состоянию аккаунтов, которая в реальном времени поддерживает глобальный граф зависимостей (Dependency Graph). Каждая транзакция моделирует, какие аккаунты изменяются, какие считываются, все это представляется в виде зависимостей. Транзакции без конфликтов могут выполняться параллельно, а транзакции с зависимостями будут последовательно или с задержкой упорядочены по топологическому порядку. Граф зависимостей обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратных вызовов
MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контракта являются асинхронными (нерекурсивное выполнение), и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В заключение, MegaETH разрушает традиционную модель однопоточной машины состояний EVM, реализуя микро-виртуальную машину в упаковке на уровне аккаунта, используя граф зависимости состояния для планирования транзакций и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, которая была полностью переработана в измерениях "структура аккаунта → архитектура планирования → процесс выполнения", предоставляя парадигмальный новый подход для создания систем следующего поколения с высокой производительностью на блокчейне.
MegaETH выбрал путь реконструкции: полностью абстрагируя аккаунты и контракты в независимую виртуальную машину, с помощью асинхронного выполнения задач для освобождения предельного потенциала параллелизма. Теоретически, параллельный предел MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему по принципам Ethereum.
Дизайны Monad и MegaETH значительно отличаются от концепции шардирования (Sharding): шардирование разбивает блокчейн на несколько независимых подсетей (шарды), каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения одноцепочечной архитектуры на уровне сети; тогда как Monad и MegaETH сохраняют целостность одноцепочечной структуры, осуществляя горизонтальное расширение только на уровне выполнения, оптимизируя и достигая предельной параллельной обработки внутри одноцепочечной структуры для повышения производительности. Оба подхода представляют собой два направления в пути расширения блокчейна: вертикальное усиление и горизонтальное расширение.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, с основной целью повышения TPS внутри цепи, реализуя параллельную обработку на уровне транзакций или учетных записей через отложенное выполнение (Deferred Execution) и архитектуру микровиртуальной машины (Micro-VM). Pharos Network, будучи модульной, полнофункциональной параллельной L1 блокчейн-сетью, имеет основную параллельную вычислительную механику, известную как "Rollup Mesh". Эта архитектура поддерживает совместную работу основной сети и специализированных обработчиков сети (SPNs), поддерживает многовиртуальную среду (EVM и Wasm) и интегрирует такие передовые технологии, как нулевые знания (ZK) и доверенная вычислительная среда (TEE).
Анализ механизма параллельных вычислений Rollup Mesh:
Кроме того, Pharos с помощью технологий многоверсионного дерева Меркла, дельта-кодирования, адресации версий и ADS-подсистемы (ADS Pushdown) реконструировал модель выполнения на основе хранилища, выпустив высокопроизводительный нативный блокчейн-хранилище Pharos Store, обеспечивающее высокую пропускную способность, низкую задержку и сильную проверяемость способности обработки на цепочке.
В общем, Phar