Панорама параллельных вычислений в Web3: лучшее решение для нативного масштабирования?
Один. Фон: Треугольник невозможного блокчейна и пути расширения
"Невозможный треугольник" блокчейна ( "безопасность", "децентрализация", "масштабируемость" ) раскрывает основные компромиссы в дизайне блокчейн-систем, а именно, что блокчейн-проекты сложно одновременно реализовать "максимальную безопасность, участие всех, высокую скорость обработки". Что касается вечной темы "масштабируемости", на текущий момент основные решения по расширению блокчейна на рынке классифицируются по парадигмам, включая:
Выполнение расширенной масштабируемости: повышение исполнительной способности на месте, например, параллельная работа, GPU, многопоточность
Изолированное расширение состояния: горизонтальное разделение состояния/Shard, например, шардинг, UTXO, много подсетей
Внешняя масштабируемость с использованием аутсорсинга: выполнение вне цепочки, например Rollup, сопроцессор, DA
Декуплированное расширение структуры: модульная архитектура, совместная работа, например, модульные цепи, общий сортировщик, Rollup Mesh
Асинхронное масштабирование с параллельным выполнением: модель актора, изоляция процессов, управление сообщениями, например, агенты, многопоточное асинхронное соединение
Решения по масштабированию блокчейна включают: параллельные вычисления в цепочке, Rollup, шarding, DA-модули, модульную структуру, системы Actor, сжатие zk-доказательства, архитектуру Stateless и другие, охватывающие несколько уровней: выполнение, состояние, данные и структуру. Это полная система масштабирования, основанная на "многослойном сотрудничестве и модульной комбинации". В данной статье основное внимание уделяется масштабированию, основанному на параллельных вычислениях.
Внутренняя параллельная обработка ( intra-chain parallelism ), сосредоточенная на параллельном выполнении транзакций/инструкций внутри блока. В зависимости от механизма параллелизма способы масштабирования можно разделить на пять основных категорий, каждая из которых представляет собой различные цели производительности, модели разработки и архитектурную философию, с постепенно уменьшающейся гранулярностью параллелизма, увеличением интенсивности параллелизма, а также усложнением планирования, сложности программирования и трудности реализации.
Уровень аккаунта (Account-level): представляет проект Solana
Объектный уровень(Object-level): представляет проект Sui
Уровень транзакций (: представляет проект Monad, Aptos
Уровень вызова / Параллельный MicroVM): представляет проект MegaETH
Инструкционно-уровневая параллельность ( Instruction-level ): представляет проект GatlingX
Внецепочечная асинхронная модель параллелизма, представляемая системой агентов Actor (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), обеспечивая оптимизацию от конца до конца.
Конвейеризация: Механизм параллельного выполнения многоступенчатых конвейеров
Пайплайнинг — это основная концепция параллельного выполнения Monad, ее ядро заключается в разделении процесса выполнения блокчейна на несколько независимых этапов и параллельной обработке этих этапов, что формирует трехмерную архитектуру конвейера, где каждый этап выполняется в независимых потоках или ядрах, достигая конкурентной обработки между блоками и, в конечном итоге, повышая пропускную способность и снижая задержку. Эти этапы включают: предложение транзакции (Propose) достижение консенсуса (Consensus) выполнение транзакции (Execution) и подтверждение блока (Commit).
Асинхронное выполнение: декомпозиция согласования и исполнения
В традиционных блокчейнах согласование и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает масштабируемость производительности. Monad реализует асинхронный уровень согласования, асинхронный уровень выполнения и асинхронное хранилище через "асинхронное выполнение". Это значительно снижает время блока ( и задержку подтверждения, делая систему более устойчивой, процесс обработки более детализированным и более эффективным использованием ресурсов.
Основной дизайн:
Процесс консенсуса ) уровень консенсуса ( отвечает только за упорядочение транзакций, не выполняя логику контрактов.
Процесс выполнения ) уровень выполнения ( асинхронно запускается после завершения консенсуса.
После завершения консенсуса немедленно переходит к процессу консенсуса следующего блока, не дожидаясь завершения выполнения.
Оптимистичное параллельное выполнение:乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad использует стратегию "оптимистичного параллельного исполнения", значительно увеличивая скорость обработки транзакций.
Механизм исполнения:
Monad будет оптимистично параллельно выполнять все транзакции, предполагая, что большинство транзакций не имеют конфликтов состояния.
Запустить "Конфликтный детектор)Conflict Detector(" для мониторинга того, обращаются ли транзакции к одному и тому же состоянию), например, конфликты чтения/записи(.
Если обнаружен конфликт, то конфликтные транзакции будут сериализованы и повторно выполнены для обеспечения корректности состояния.
Monad выбрал совместимый путь: минимально изменяя правила EVM, реализуя параллелизм в процессе выполнения за счет отложенной записи состояния и динамического обнаружения конфликтов, больше похоже на производительную версию Ethereum, с хорошей зрелостью, что облегчает миграцию экосистемы EVM, являясь параллельным ускорителем мира EVM.
![Web3 параллельные вычисления: лучший вариант для нативного масштабирования?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) Анализ параллельного вычислительного механизма MegaETH
В отличие от L1, ориентированного на Monad, MegaETH позиционируется как модульный высокопроизводительный параллельный слой выполнения, совместимый с EVM, который может использоваться как независимая L1 публичная цепочка, так и как слой усиления выполнения на Ethereum (Execution Layer) или модульный компонент. Его основной целью является изоляция логики учетной записи, среды выполнения и состояния, разлагая их на минимальные единицы, которые можно независимо планировать, чтобы обеспечить высокую параллельную обработку и низкую задержку отклика внутри цепочки. Ключевое новшество, предложенное MegaETH, заключается в: архитектуре Micro-VM + State Dependency DAG###ориентированный ациклический граф зависимости состояния( и модульном механизме синхронизации, которые совместно создают параллельную систему выполнения, ориентированную на "потоковую обработку внутри цепочки".
MegaETH внедрил модель выполнения "микровиртуальная машина для каждого аккаунта )Micro-VM(", которая "потокизирует" среду выполнения, предоставляя минимальную единицу изоляции для параллельного планирования. Эти ВМ взаимодействуют через асинхронную передачу сообщений )Asynchronous Messaging(, а не через синхронные вызовы, позволяя множеству ВМ работать независимо и хранить данные отдельно, что обеспечивает естественную параллельность.
Зависимость состояния DAG: механизм планирования, основанный на графе зависимостей
MegaETH построила систему планирования DAG, основанную на отношениях доступа к состоянию аккаунта, которая в реальном времени поддерживает глобальный граф зависимостей ) Dependency Graph (. Каждая транзакция моделирует, какие аккаунты изменяются и какие аккаунты считываются, все это представлено в виде зависимостей. Транзакции без конфликтов могут выполняться параллельно, тогда как транзакции с зависимостями будут упорядочены по топологическому порядку для последовательного или отложенного выполнения. Граф зависимостей обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратных вызовов
MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контрактов являются асинхронными ) нерекурсивными ( выполнения, и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов )Call Graph(; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В заключение, MegaETH нарушает традиционную модель однопоточной машины состояний EVM, реализуя микро-виртуальные машины в упаковке на уровне аккаунтов, осуществляя планирование транзакций через графы зависимостей состояний и заменяя синхронные вызовы стека асинхронным механизмом сообщений. Это параллельная вычислительная платформа, заново спроектированная по всем измерениям от "структуры аккаунтов → архитектуры планирования → процесса выполнения", предоставляющая парадигмальный новый подход для построения систем следующего поколения с высокой производительностью на блокчейне.
MegaETH выбрала путь реконструкции: полностью абстрагировав аккаунты и контракты в независимую ВМ, с помощью асинхронного выполнения и планирования для раскрытия предельного потенциала параллелизма. Теоретически, параллельный предел MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему в духе идей Ethereum.
![Web3 параллельные вычисления: лучший вариант нативного масштабирования?])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
Дизайнерские концепции 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(: SPN - это ключевой компонент архитектуры Pharos, подобный модульным подсетям, специально предназначенным для обработки определенных типов задач или приложений. С помощью SPNs Pharos может осуществлять динамическое распределение ресурсов и параллельную обработку задач, что дополнительно усиливает масштабируемость и производительность системы.
Модульная консенсусная система и механизм повторного стекинга ) Modular Consensus & Restaking (: Pharos вводит гибкую консенсусную систему, поддерживающую различные модели консенсуса ), такие как PBFT, PoS, PoA (, и обеспечивает безопасное совместное использование и интеграцию ресурсов между основной сетью и SPN через протокол повторного стекинга ) Restaking (.
Кроме того, Pharos с помощью многоверсионного дерева Меркла, дельта-кодирования)Delta Encoding(, адресации версий)Versioned Addressing( и технологии ADS Pushdown), реконструировал модель выполнения на уровне хранилища, выпустив нативный блокчейн с высокой производительностью хранилище Pharos Store, обеспечивающее высокую пропускную способность, низкую задержку и сильную проверяемость в цепочке.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Web3 параллельные вычисления: пять моделей, ведущих к новым парадигмам масштабирования Блокчейна
Панорама параллельных вычислений в Web3: лучшее решение для нативного масштабирования?
Один. Фон: Треугольник невозможного блокчейна и пути расширения
"Невозможный треугольник" блокчейна ( "безопасность", "децентрализация", "масштабируемость" ) раскрывает основные компромиссы в дизайне блокчейн-систем, а именно, что блокчейн-проекты сложно одновременно реализовать "максимальную безопасность, участие всех, высокую скорость обработки". Что касается вечной темы "масштабируемости", на текущий момент основные решения по расширению блокчейна на рынке классифицируются по парадигмам, включая:
Решения по масштабированию блокчейна включают: параллельные вычисления в цепочке, Rollup, шarding, DA-модули, модульную структуру, системы Actor, сжатие zk-доказательства, архитектуру Stateless и другие, охватывающие несколько уровней: выполнение, состояние, данные и структуру. Это полная система масштабирования, основанная на "многослойном сотрудничестве и модульной комбинации". В данной статье основное внимание уделяется масштабированию, основанному на параллельных вычислениях.
Внутренняя параллельная обработка ( intra-chain parallelism ), сосредоточенная на параллельном выполнении транзакций/инструкций внутри блока. В зависимости от механизма параллелизма способы масштабирования можно разделить на пять основных категорий, каждая из которых представляет собой различные цели производительности, модели разработки и архитектурную философию, с постепенно уменьшающейся гранулярностью параллелизма, увеличением интенсивности параллелизма, а также усложнением планирования, сложности программирования и трудности реализации.
Внецепочечная асинхронная модель параллелизма, представляемая системой агентов Actor (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), обеспечивая оптимизацию от конца до конца.
Конвейеризация: Механизм параллельного выполнения многоступенчатых конвейеров
Пайплайнинг — это основная концепция параллельного выполнения Monad, ее ядро заключается в разделении процесса выполнения блокчейна на несколько независимых этапов и параллельной обработке этих этапов, что формирует трехмерную архитектуру конвейера, где каждый этап выполняется в независимых потоках или ядрах, достигая конкурентной обработки между блоками и, в конечном итоге, повышая пропускную способность и снижая задержку. Эти этапы включают: предложение транзакции (Propose) достижение консенсуса (Consensus) выполнение транзакции (Execution) и подтверждение блока (Commit).
Асинхронное выполнение: декомпозиция согласования и исполнения
В традиционных блокчейнах согласование и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает масштабируемость производительности. Monad реализует асинхронный уровень согласования, асинхронный уровень выполнения и асинхронное хранилище через "асинхронное выполнение". Это значительно снижает время блока ( и задержку подтверждения, делая систему более устойчивой, процесс обработки более детализированным и более эффективным использованием ресурсов.
Основной дизайн:
Оптимистичное параллельное выполнение:乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad использует стратегию "оптимистичного параллельного исполнения", значительно увеличивая скорость обработки транзакций.
Механизм исполнения:
Monad выбрал совместимый путь: минимально изменяя правила EVM, реализуя параллелизм в процессе выполнения за счет отложенной записи состояния и динамического обнаружения конфликтов, больше похоже на производительную версию Ethereum, с хорошей зрелостью, что облегчает миграцию экосистемы EVM, являясь параллельным ускорителем мира EVM.
![Web3 параллельные вычисления: лучший вариант для нативного масштабирования?])https://img-cdn.gateio.im/webp-social/moments-dc016502755a30d5a95a8134f7586162.webp(
) Анализ параллельного вычислительного механизма 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.
![Web3 параллельные вычисления: лучший вариант нативного масштабирования?])https://img-cdn.gateio.im/webp-social/moments-9c4a4c4309574e45f679b2585d42ea16.webp(
Дизайнерские концепции 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:
Кроме того, Pharos с помощью многоверсионного дерева Меркла, дельта-кодирования)Delta Encoding(, адресации версий)Versioned Addressing( и технологии ADS Pushdown), реконструировал модель выполнения на уровне хранилища, выпустив нативный блокчейн с высокой производительностью хранилище Pharos Store, обеспечивающее высокую пропускную способность, низкую задержку и сильную проверяемость в цепочке.