Параллельные вычисления в Web3: лучший вариант для нативного масштабирования?
«Невозможный треугольник» блокчейна — «безопасность», «децентрализация», «масштабируемость» — раскрывает сущностную компромиссу в проектировании блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достигнуть «максимальной безопасности, всеобщего участия, быстрой обработки». Что касается «масштабируемости», этой вечной темы, в настоящее время основные решения по масштабированию блокчейна на рынке разделяются по парадигмам, включая:
Выполнение расширенного масштабирования: повышение исполнительной способности на месте, например, параллельная работа, GPU, многопоточность.
Изолированное расширение состояния: горизонтальное разделение состояния / Shard, например, шардирование, UTXO, многоподсети
Внешнее масштабирование с использованием аутсорсинга: выполнение вне цепи, например Rollup, Копроцессор, DA
Декуплинг структуры расширения: модульная архитектура, совместная работа, например, модульная цепь, общий сортировщик, Rollup Mesh
Асинхронное масштабирование с параллелизмом: модель акторов, изоляция процессов, управление сообщениями, например, агенты, многопоточные асинхронные цепочки
Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, DA-модули, модульную структуру, систему Actor, сжатие zk-доказательств, архитектуру без состояния и т.д., охватывая несколько уровней исполнения, состояния, данных и структуры, представляя собой «многослойную координацию и модульную комбинацию» полную систему масштабирования. В этой статье основное внимание уделяется масштабированию, основанному на параллельных вычислениях.
Внутреннее параллельное вычисление (intra-chain parallelism), внимание к параллельному выполнению транзакций / инструкций внутри блока. По параллельным механизмам можно разделить на пять категорий, каждая из которых представляет собой разные требования к производительности, модели разработки и архитектурную философию, где параллельная гранулярность становится все тоньше, параллельная сила растет, сложность планирования также возрастает, а сложность программирования и реализации становится все выше.
Уровень аккаунта параллельно: представляет проект Solana
Объектный уровень параллелизма: представляет проект Sui
Торговый уровень параллелизм: представляет проект Monad, Aptos
Уровень вызова / Параллельная микро-ВМ: представляет проект MegaETH
Инструктивный уровень параллелизма: представляет проект GatlingX
Внецепочечная асинхронная параллельная модель, представленная системой умных агентов Actor, относится к другой парадигме параллельных вычислений. В качестве кроссцепочечного / асинхронного сообщения каждая Агента функционирует как независимый «умный процесс», осуществляя асинхронные сообщения в параллельном режиме, основанные на событиях, без необходимости синхронного планирования. Представленные проекты: AO, ICP, Cartesi и др.
Известные нам решения по расширению, такие как Rollup или шarding, относятся к системным механизмам параллелизма и не являются параллельными вычислениями внутри цепочки. Они достигают масштабируемости за счет «параллельного запуска нескольких цепочек / исполняемых областей», а не за счет повышения степени параллелизма внутри одного блока / виртуальной машины. Такие решения по расширению не являются основной темой этой статьи, но мы все же будем использовать их для сравнительного анализа архитектурных концепций.
2. EVM-система параллельного повышения цепи: прорыв производственных границ в совместимости
Архитектура последовательной обработки Ethereum развивалась до настоящего времени, пройдя несколько этапов расширения, таких как шардирование, Rollup, модульная архитектура и так далее, но узкое место пропускной способности на уровне выполнения по-прежнему не было решено кардинальным образом. В то же время, EVM и Solidity по-прежнему являются наиболее развитыми платформами смарт-контрактов с точки зрения разработчиков и экосистемы. Поэтому параллельные улучшенные цепочки EVM становятся ключевым направлением для повышения совместимости экосистемы и улучшения производительности выполнения, и это направление становится важным в новой волне эволюции масштабирования. Monad и MegaETH являются наиболее представительными проектами в этом направлении, которые строят архитектуру параллельной обработки EVM, ориентированную на высокую конкурентность и высокую пропускную способность, начиная с задержки выполнения и разложения состояния.
Анализ механизма параллельных вычислений Monad
Monad - это высокопроизводительная Layer1 блокчейн, переработанная для виртуальной машины Ethereum, основанная на базовом параллельном принципе конвейерной обработки, с асинхронным выполнением на уровне консенсуса и оптимистичной конкуренцией на уровне исполнения. Кроме того, на уровнях консенсуса и хранения Monad соответственно внедряет высокопроизводительный BFT протокол и специализированную систему баз данных, обеспечивая оптимизацию от конца до конца.
Пайплайнинг: Механизм параллельного выполнения многоступенчатого конвейера
Пайплайнинг является основной идеей параллельного выполнения монады, его 핵심思想 заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обрабатывать эти этапы параллельно, формируя многослойную архитектуру конвейера, где каждый этап работает на независимом потоке или ядре, достигая параллельной обработки между блоками и в конечном итоге повышая пропускную способность и снижая задержку. Эти этапы включают: предложение транзакции, достижение консенсуса, выполнение транзакции и подтверждение блока.
Асинхронное выполнение: Консенсус - Асинхронное разъединение выполнения
В традиционных блокчейнах консенсус и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает масштабируемость производительности. Monad реализует асинхронность на уровне консенсуса, асинхронность на уровне выполнения и асинхронность в хранении через «асинхронное выполнение». Это значительно снижает время блокировки и задержку подтверждения, делая систему более устойчивой, процессы более детализированными и эффективность использования ресурсов выше.
Основной дизайн:
Процесс консенсуса отвечает только за упорядочение транзакций, а не за выполнение логики контрактов.
Процесс выполнения асинхронно запускается после завершения консенсуса.
После завершения консенсуса немедленно переходите к процессу консенсуса следующего блока, не дожидаясь завершения выполнения.
Оптимистичное параллельное выполнение:乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию «оптимистичного параллельного выполнения», значительно увеличивая скорость обработки транзакций.
Исполнительный механизм:
Monad будет оптимистично параллельно выполнять все транзакции, предполагая, что между большинством транзакций нет конфликтов состояния.
Запустить «детектор конфликтов», чтобы отслеживать, обращаются ли транзакции к одному и тому же состоянию.
Если обнаружен конфликт, конфликтующие транзакции будут сериализованы и повторно выполнены, чтобы обеспечить корректность состояния.
Monad выбрал совместимый путь: минимально изменяя правила EVM, реализуя параллельность в процессе выполнения за счет отложения записи состояния и динамического обнаружения конфликтов, что больше похоже на производительную версию Ethereum. Высокая степень зрелости облегчает миграцию экосистемы EVM, являясь ускорителем параллельной обработки в мире EVM.
Анализ механизма параллельных вычислений MegaETH
В отличие от L1-ориентации Monad, MegaETH позиционируется как совместимый с EVM модульный высокопроизводительный параллельный уровень выполнения, который может использоваться как независимая L1 публичная цепь, так и как уровень повышения выполнения или модульный компонент на Ethereum. Его основной проектировочной целью является деконструкция логики аккаунта, среды выполнения и состояния в независимые единицы для обеспечения высокой параллельной обработки и низкой задержки отклика внутри цепи. Ключевое новшество, предложенное MegaETH, заключается в архитектуре Micro-VM + State Dependency DAG и модульном механизме синхронизации, которые вместе создают параллельную систему выполнения, ориентированную на "потоковую обработку внутри цепи".
Архитектура Micro-VM: учетная запись как поток
MegaETH вводит модель выполнения «один микро-виртуальный компьютер на каждый аккаунт», которая «потокизирует» среду выполнения и предоставляет минимальную единицу изоляции для параллельного планирования. Эти ВМ общаются друг с другом через асинхронные сообщения, а не синхронные вызовы, что позволяет множеству ВМ выполнять операции независимо и хранить данные отдельно, обеспечивая естественную параллельность.
Зависимый DAG: механизм планирования на основе графа зависимостей
MegaETH создала систему планирования DAG на основе доступа к состоянию счетов, которая в реальном времени поддерживает глобальный граф зависимостей. Каждая транзакция моделируется как зависимость, включая изменения в счетах и считывание из счетов. Транзакции без конфликтов могут выполняться параллельно, в то время как транзакции с зависимостями будут планироваться и сортироваться по топологическому порядку. Граф зависимостей обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратного вызова
MegaETH построен на основе асинхронной парадигмы программирования, аналогичной асинхронной передаче сообщений в модели акторов, решая проблемы последовательных вызовов традиционного EVM. Вызовы контрактов являются асинхронными, при вызове контракта A -\u003e B -\u003e C каждый вызов асинхронизируется, не блокируя ожидание; стек вызовов разворачивается в асинхронный граф вызовов; обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В общем, MegaETH разрушает традиционную модель однопоточной машины состояний EVM, реализуя упаковку микровиртуальных машин на уровне учетной записи, осуществляя планирование транзакций через граф зависимости состояний и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, полностью переработанная по всем уровням — от «структуры аккаунта → архитектуры планирования → процесса выполнения», которая предлагает парадигматически новые идеи для построения систем следующего поколения с высокой производительностью.
MegaETH выбрала путь реконструкции: полностью абстрагировав учетные записи и контракты в независимую VM, с помощью асинхронного выполнения для освобождения предельного параллельного потенциала. Теоретически, параллельный лимит MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему в духе Ethereum.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования: шардирование горизонтально разделяет блокчейн на несколько независимых подсетей, каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения единой цепи на уровне сети; в то время как Monad и MegaETH сохраняют целостность единой цепи, лишь горизонтально расширяясь на уровне выполнения, достигая оптимизации предельного параллельного выполнения внутри единой цепи для повышения производительности. Оба представляют собой направления вертикального усиления и горизонтального расширения в пути масштабирования блокчейна.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, с целью повышения TPS в цепочке, реализуя параллельную обработку на уровне транзакций или аккаунтов через отложенное выполнение и микроархитектуру виртуальных машин. Pharos Network, будучи модульной, полностековой параллельной сетью L1 блокчейна, имеет свою основную параллельную вычислительную механику, называемую «Rollup Mesh». Эта архитектура поддерживает работу главной сети и специальной сети обработки, обеспечивая многовиртуальную среду и интегрируя такие передовые технологии, как нулевое доказательство и доверенная среда выполнения.
Анализ механизма параллельных вычислений Rollup Mesh:
Обработка асинхронных конвейеров на протяжении всего жизненного цикла: Pharos декомпозирует различные этапы транзакции и использует асинхронный подход, что позволяет каждому этапу выполняться независимо и параллельно, тем самым повышая общую эффективность обработки.
Параллельное выполнение двух виртуальных машин: Pharos поддерживает две виртуальные среды виртуальных машин EVM и WASM, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от потребностей. Эта архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и улучшает способность обработки транзакций за счет параллельного выполнения.
Специальная обработка сети: SPN являются ключевыми компонентами архитектуры Pharos, аналогичными модульным подсетям, специально предназначенными для обработки определенных типов задач или приложений. Через SPN Pharos может реализовать динамическое распределение ресурсов и параллельную обработку задач, что дополнительно усиливает масштабируемость и производительность системы.
Модульный консенсус и механизмы повторного залога: Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса, и реализует безопасное совместное использование и интеграцию ресурсов между основной сетью и SPNs через протокол повторного залога.
Кроме того, Pharos с помощью многоверсионного дерева Меркла, дельта-кодирования, адресации версий и технологии ADS-снижения реконструировал модель выполнения на уровне хранилища, выпустив высокопроизводительный хранилище на основе оригинальной блокчейн-технологии Pharos Store, обеспечивающее высокую пропускную способность, низкую задержку и высокую степень проверяемости обработки на цепочке.
В общем, архитектура Rollup Mesh от Pharos, благодаря модульному дизайну и механизму асинхронной обработки, обеспечивает высокопроизводительные параллельные вычислительные возможности. Pharos, как координатор параллельных процессов между Rollup, не является оптимизатором выполнения для «внутренней параллели» блокчейна, а использует SPN для выполнения нестандартных задач.
 и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
20 Лайков
Награда
20
9
Репост
Поделиться
комментарий
0/400
GateUser-a606bf0c
· 08-14 19:27
Ай, это даже хуже, чем просто бросить сервер и считать мощно.
Посмотреть ОригиналОтветить0
HashRatePhilosopher
· 08-14 00:10
старый разговор о вопросе масштабируемости
Посмотреть ОригиналОтветить0
WalletDoomsDay
· 08-13 15:34
Шардинг уже делается несколько лет, а все еще на месте.
Посмотреть ОригиналОтветить0
LayerZeroHero
· 08-12 12:13
Настоящий аромат, наконец-то кто-то глубоко исследует узкие места EVM.
Посмотреть ОригиналОтветить0
SchrodingerPrivateKey
· 08-12 01:17
Скорость можно пожертвовать, безопасность основного блокчейна должна быть на максимум.
Посмотреть ОригиналОтветить0
PumpingCroissant
· 08-12 01:14
建议继续 насос ловушка呢
Посмотреть ОригиналОтветить0
FlatTax
· 08-12 01:13
в блокчейне вычисления все еще зависят от жесткой борьбы.
Посмотреть ОригиналОтветить0
SerumSqueezer
· 08-12 01:09
Кто сможет разрушить треугольник Блокчейн? Многоуровневая правда сбивает с толку ～
Полный анализ параллельных вычислений Web3: от совместимости с EVM до прорыва в производительности на гетерогенных архитектурах
Параллельные вычисления в Web3: лучший вариант для нативного масштабирования?
«Невозможный треугольник» блокчейна — «безопасность», «децентрализация», «масштабируемость» — раскрывает сущностную компромиссу в проектировании блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достигнуть «максимальной безопасности, всеобщего участия, быстрой обработки». Что касается «масштабируемости», этой вечной темы, в настоящее время основные решения по масштабированию блокчейна на рынке разделяются по парадигмам, включая:
Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепи, Rollup, шардирование, DA-модули, модульную структуру, систему Actor, сжатие zk-доказательств, архитектуру без состояния и т.д., охватывая несколько уровней исполнения, состояния, данных и структуры, представляя собой «многослойную координацию и модульную комбинацию» полную систему масштабирования. В этой статье основное внимание уделяется масштабированию, основанному на параллельных вычислениях.
Внутреннее параллельное вычисление (intra-chain parallelism), внимание к параллельному выполнению транзакций / инструкций внутри блока. По параллельным механизмам можно разделить на пять категорий, каждая из которых представляет собой разные требования к производительности, модели разработки и архитектурную философию, где параллельная гранулярность становится все тоньше, параллельная сила растет, сложность планирования также возрастает, а сложность программирования и реализации становится все выше.
Внецепочечная асинхронная параллельная модель, представленная системой умных агентов Actor, относится к другой парадигме параллельных вычислений. В качестве кроссцепочечного / асинхронного сообщения каждая Агента функционирует как независимый «умный процесс», осуществляя асинхронные сообщения в параллельном режиме, основанные на событиях, без необходимости синхронного планирования. Представленные проекты: AO, ICP, Cartesi и др.
Известные нам решения по расширению, такие как Rollup или шarding, относятся к системным механизмам параллелизма и не являются параллельными вычислениями внутри цепочки. Они достигают масштабируемости за счет «параллельного запуска нескольких цепочек / исполняемых областей», а не за счет повышения степени параллелизма внутри одного блока / виртуальной машины. Такие решения по расширению не являются основной темой этой статьи, но мы все же будем использовать их для сравнительного анализа архитектурных концепций.
2. EVM-система параллельного повышения цепи: прорыв производственных границ в совместимости
Архитектура последовательной обработки Ethereum развивалась до настоящего времени, пройдя несколько этапов расширения, таких как шардирование, Rollup, модульная архитектура и так далее, но узкое место пропускной способности на уровне выполнения по-прежнему не было решено кардинальным образом. В то же время, EVM и Solidity по-прежнему являются наиболее развитыми платформами смарт-контрактов с точки зрения разработчиков и экосистемы. Поэтому параллельные улучшенные цепочки EVM становятся ключевым направлением для повышения совместимости экосистемы и улучшения производительности выполнения, и это направление становится важным в новой волне эволюции масштабирования. Monad и MegaETH являются наиболее представительными проектами в этом направлении, которые строят архитектуру параллельной обработки EVM, ориентированную на высокую конкурентность и высокую пропускную способность, начиная с задержки выполнения и разложения состояния.
Анализ механизма параллельных вычислений Monad
Monad - это высокопроизводительная Layer1 блокчейн, переработанная для виртуальной машины Ethereum, основанная на базовом параллельном принципе конвейерной обработки, с асинхронным выполнением на уровне консенсуса и оптимистичной конкуренцией на уровне исполнения. Кроме того, на уровнях консенсуса и хранения Monad соответственно внедряет высокопроизводительный BFT протокол и специализированную систему баз данных, обеспечивая оптимизацию от конца до конца.
Пайплайнинг: Механизм параллельного выполнения многоступенчатого конвейера
Пайплайнинг является основной идеей параллельного выполнения монады, его 핵심思想 заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обрабатывать эти этапы параллельно, формируя многослойную архитектуру конвейера, где каждый этап работает на независимом потоке или ядре, достигая параллельной обработки между блоками и в конечном итоге повышая пропускную способность и снижая задержку. Эти этапы включают: предложение транзакции, достижение консенсуса, выполнение транзакции и подтверждение блока.
Асинхронное выполнение: Консенсус - Асинхронное разъединение выполнения
В традиционных блокчейнах консенсус и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает масштабируемость производительности. Monad реализует асинхронность на уровне консенсуса, асинхронность на уровне выполнения и асинхронность в хранении через «асинхронное выполнение». Это значительно снижает время блокировки и задержку подтверждения, делая систему более устойчивой, процессы более детализированными и эффективность использования ресурсов выше.
Основной дизайн:
Оптимистичное параллельное выполнение:乐观并行执行
Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию «оптимистичного параллельного выполнения», значительно увеличивая скорость обработки транзакций.
Исполнительный механизм:
Monad выбрал совместимый путь: минимально изменяя правила EVM, реализуя параллельность в процессе выполнения за счет отложения записи состояния и динамического обнаружения конфликтов, что больше похоже на производительную версию Ethereum. Высокая степень зрелости облегчает миграцию экосистемы EVM, являясь ускорителем параллельной обработки в мире EVM.
Анализ механизма параллельных вычислений MegaETH
В отличие от L1-ориентации Monad, MegaETH позиционируется как совместимый с EVM модульный высокопроизводительный параллельный уровень выполнения, который может использоваться как независимая L1 публичная цепь, так и как уровень повышения выполнения или модульный компонент на Ethereum. Его основной проектировочной целью является деконструкция логики аккаунта, среды выполнения и состояния в независимые единицы для обеспечения высокой параллельной обработки и низкой задержки отклика внутри цепи. Ключевое новшество, предложенное MegaETH, заключается в архитектуре Micro-VM + State Dependency DAG и модульном механизме синхронизации, которые вместе создают параллельную систему выполнения, ориентированную на "потоковую обработку внутри цепи".
Архитектура Micro-VM: учетная запись как поток
MegaETH вводит модель выполнения «один микро-виртуальный компьютер на каждый аккаунт», которая «потокизирует» среду выполнения и предоставляет минимальную единицу изоляции для параллельного планирования. Эти ВМ общаются друг с другом через асинхронные сообщения, а не синхронные вызовы, что позволяет множеству ВМ выполнять операции независимо и хранить данные отдельно, обеспечивая естественную параллельность.
Зависимый DAG: механизм планирования на основе графа зависимостей
MegaETH создала систему планирования DAG на основе доступа к состоянию счетов, которая в реальном времени поддерживает глобальный граф зависимостей. Каждая транзакция моделируется как зависимость, включая изменения в счетах и считывание из счетов. Транзакции без конфликтов могут выполняться параллельно, в то время как транзакции с зависимостями будут планироваться и сортироваться по топологическому порядку. Граф зависимостей обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.
Асинхронное выполнение и механизм обратного вызова
MegaETH построен на основе асинхронной парадигмы программирования, аналогичной асинхронной передаче сообщений в модели акторов, решая проблемы последовательных вызовов традиционного EVM. Вызовы контрактов являются асинхронными, при вызове контракта A -\u003e B -\u003e C каждый вызов асинхронизируется, не блокируя ожидание; стек вызовов разворачивается в асинхронный граф вызовов; обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.
В общем, MegaETH разрушает традиционную модель однопоточной машины состояний EVM, реализуя упаковку микровиртуальных машин на уровне учетной записи, осуществляя планирование транзакций через граф зависимости состояний и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, полностью переработанная по всем уровням — от «структуры аккаунта → архитектуры планирования → процесса выполнения», которая предлагает парадигматически новые идеи для построения систем следующего поколения с высокой производительностью.
MegaETH выбрала путь реконструкции: полностью абстрагировав учетные записи и контракты в независимую VM, с помощью асинхронного выполнения для освобождения предельного параллельного потенциала. Теоретически, параллельный лимит MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределенную операционную систему в духе Ethereum.
Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования: шардирование горизонтально разделяет блокчейн на несколько независимых подсетей, каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения единой цепи на уровне сети; в то время как Monad и MegaETH сохраняют целостность единой цепи, лишь горизонтально расширяясь на уровне выполнения, достигая оптимизации предельного параллельного выполнения внутри единой цепи для повышения производительности. Оба представляют собой направления вертикального усиления и горизонтального расширения в пути масштабирования блокчейна.
Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности, с целью повышения TPS в цепочке, реализуя параллельную обработку на уровне транзакций или аккаунтов через отложенное выполнение и микроархитектуру виртуальных машин. Pharos Network, будучи модульной, полностековой параллельной сетью L1 блокчейна, имеет свою основную параллельную вычислительную механику, называемую «Rollup Mesh». Эта архитектура поддерживает работу главной сети и специальной сети обработки, обеспечивая многовиртуальную среду и интегрируя такие передовые технологии, как нулевое доказательство и доверенная среда выполнения.
Анализ механизма параллельных вычислений Rollup Mesh:
Обработка асинхронных конвейеров на протяжении всего жизненного цикла: Pharos декомпозирует различные этапы транзакции и использует асинхронный подход, что позволяет каждому этапу выполняться независимо и параллельно, тем самым повышая общую эффективность обработки.
Параллельное выполнение двух виртуальных машин: Pharos поддерживает две виртуальные среды виртуальных машин EVM и WASM, позволяя разработчикам выбирать подходящую среду выполнения в зависимости от потребностей. Эта архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и улучшает способность обработки транзакций за счет параллельного выполнения.
Специальная обработка сети: SPN являются ключевыми компонентами архитектуры Pharos, аналогичными модульным подсетям, специально предназначенными для обработки определенных типов задач или приложений. Через SPN Pharos может реализовать динамическое распределение ресурсов и параллельную обработку задач, что дополнительно усиливает масштабируемость и производительность системы.
Модульный консенсус и механизмы повторного залога: Pharos вводит гибкий механизм консенсуса, поддерживающий различные модели консенсуса, и реализует безопасное совместное использование и интеграцию ресурсов между основной сетью и SPNs через протокол повторного залога.
Кроме того, Pharos с помощью многоверсионного дерева Меркла, дельта-кодирования, адресации версий и технологии ADS-снижения реконструировал модель выполнения на уровне хранилища, выпустив высокопроизводительный хранилище на основе оригинальной блокчейн-технологии Pharos Store, обеспечивающее высокую пропускную способность, низкую задержку и высокую степень проверяемости обработки на цепочке.
В общем, архитектура Rollup Mesh от Pharos, благодаря модульному дизайну и механизму асинхронной обработки, обеспечивает высокопроизводительные параллельные вычислительные возможности. Pharos, как координатор параллельных процессов между Rollup, не является оптимизатором выполнения для «внутренней параллели» блокчейна, а использует SPN для выполнения нестандартных задач.
![Веб3 параллельные вычисления: лучшая стратегия для нативного расширения?](