Панорама параллельных вычислений Web3: пять парадигм, которые преодолевают границы производительности EVM-цепей

Полная карта параллельных вычислений Web3: лучший вариант для нативного масштабирования?

«Невозможный треугольник» блокчейна, «безопасность», «децентрализация», «масштабируемость», раскрывает сущностные компромиссы в дизайне блокчейн-систем, а именно, что блокчейн-проекты трудно одновременно достичь «максимальной безопасности, доступности для всех, высокой скорости обработки». Что касается «масштабируемости», этой вечной темы, текущие основные решения по расширению блокчейна на рынке различаются по парадигмам, включая:

  • Выполнение улучшенного масштабирования: повышение производительности выполнения на месте, например, параллельная обработка, GPU, многопроцессорность.
  • Изоляция состояния для масштабирования: горизонтальное разделение состояния / Шард, например, шардирование, UTXO, много подсетей
  • Внецепочечное расширение: выполнение происходит вне цепочки, например Rollup, сопроцессор, DA
  • Структурно разъединенное расширение: модульная архитектура, совместная работа, например, модульные цепи, общий сортировщик, Rollup Mesh
  • Асинхронное параллельное масштабирование: Модель акторов, изоляция процессов, управление сообщениями, например, агенты, многопоточное асинхронное соединение

Решения по масштабированию блокчейна включают: параллельные вычисления внутри цепочки, Rollup, шардирование, DA-модуль, модульную структуру, систему Actor, сжатие zk-доказательства, Stateless архитектуру и т.д., охватывая несколько уровней исполнения, состояния, данных и структуры, представляя собой «многослойную координацию и модульную комбинацию» полную систему масштабирования. В данной статье акцентируется внимание на масштабировании, основанном на параллельных вычислениях.

Веб3 Параллельные вычисления: лучший вариант нативного расширения?

Параллельные вычисления внутри цепочки, сосредоточьтесь на параллельном выполнении транзакций/инструкций внутри блока. В зависимости от механизма параллелизма, способы масштабирования можно разделить на пять основных категорий, каждая из которых представляет собой различные стремления к производительности, модели разработки и архитектурную философию, при этом степень параллелизма становится все более тонкой, интенсивность параллелизма увеличивается, сложность планирования также возрастает, а сложность программирования и трудности реализации становятся все выше.

  • Уровень аккаунта параллелизм (Account-level): представляет проект Solana
  • Объектный уровень параллелизма (Object-level): представляет проект Sui
  • Уровень транзакций (Transaction-level): представляет проект Monad, Aptos
  • Уровень вызова / Микро VM параллельно (Call-level / MicroVM): представляет проект MegaETH
  • Параллелизм на уровне инструкций (Instruction-level): представляет проект GatlingX

Внецепочечная асинхронная параллельная модель, представленная системой умных агентов Actor, относится к другому парадигме параллельных вычислений. В качестве межцепочечных/асинхронных систем сообщений каждый агент работает как независимый «умный процесс», осуществляя асинхронные сообщения в параллельном режиме, основанные на событиях, без необходимости синхронного планирования. Представленные проекты включают AO, ICP, Cartesi и другие.

А такие известные нам решения, как Rollup или шардирование, относятся к механизмам параллельной обработки на системном уровне и не являются параллельными вычислениями внутри цепочки. Они достигают масштабируемости за счет «параллельного выполнения нескольких цепочек/исполнительных доменов», а не за счет повышения параллелизма внутри одного блока/виртуальной машины. Эти решения по масштабированию не являются основной темой данной статьи, но мы все равно будем использовать их для сравнения архитектурных концепций.

Веб3 параллельные вычисления: лучший вариант для нативного расширения?

II. EVM-система параллельного усовершенствования цепи: прорыв в производительности через совместимость

Архитектура последовательной обработки Ethereum с тех пор, как она развивалась, прошла несколько раундов попыток масштабирования, включая шардирование, Rollup, модульную архитектуру и т. д., но узкие места пропускной способности на уровне выполнения все еще не были fundamentally преодолены. В то же время EVM и Solidity по-прежнему являются самыми популярными платформами для смарт-контрактов с самой широкой базой разработчиков и экосистемным потенциалом. Таким образом, EVM-параллельная усиленная цепочка, которая учитывает совместимость экосистемы и повышение производительности выполнения, становится важным направлением нового этапа масштабирования. Monad и MegaETH являются наиболее представительными проектами в этом направлении, которые строят архитектуру параллельной обработки EVM, ориентированную на высокую конкуренцию и высокую пропускную способность, исходя из задержки выполнения и декомпозиции состояния.

Анализ механизма параллельных вычислений Monad

Monad является высокопроизводительной Layer1 блокчейном, переработанным для виртуальной машины Ethereum, основанным на основной параллельной концепции конвейерной обработки (Pipelining), с асинхронным выполнением на уровне консенсуса (Asynchronous Execution) и оптимистическим параллельным выполнением (Optimistic Parallel Execution) на уровне исполнения. Кроме того, на уровне консенсуса и хранения Monad соответственно внедрил высокопроизводительный BFT протокол (MonadBFT) и специализированную базу данных (MonadDB), обеспечивая оптимизацию от конца до конца.

Пайплайнинг: Механизм параллельного выполнения многоступенчатого конвейера

Пайплайнинг является основной идеей параллельного выполнения монады, его основная концепция заключается в том, чтобы разбить процесс выполнения блокчейна на несколько независимых этапов и обрабатывать эти этапы параллельно, формируя трехмерную архитектуру конвейера, где каждый этап выполняется в независимом потоке или ядре, обеспечивая параллельную обработку между блоками и, в конечном итоге, достигая повышения пропускной способности и снижения задержки. Эти этапы включают: предложение транзакции (Propose), достижение консенсуса (Consensus), выполнение транзакции (Execution) и подтверждение блока (Commit).

Асинхронное выполнение: Консенсус - асинхронная декомпозиция выполнения

В традиционных блокчейнах консенсус и выполнение транзакций обычно являются синхронными процессами, и такая последовательная модель серьезно ограничивает масштабируемость производительности. Monad реализует асинхронный консенсус на уровне консенсуса, асинхронное выполнение на уровне выполнения и асинхронное хранение. Это значительно снижает время блока и задержку подтверждения, делая систему более устойчивой, процесс обработки более детализированным и более эффективным использованием ресурсов.

Основной дизайн:

  • Процесс консенсуса отвечает только за упорядочение транзакций, не выполняя логику контрактов.
  • Процесс выполнения асинхронно инициируется после завершения консенсуса.
  • После завершения консенсуса немедленно переходит к процессу консенсуса следующего блока, не дожидаясь завершения выполнения.

Оптимистичное параллельное выполнение:乐观并行执行

Традиционный Ethereum использует строгую последовательную модель для выполнения транзакций, чтобы избежать конфликтов состояния. В то время как Monad применяет стратегию «оптимистичного параллельного выполнения», что значительно увеличивает скорость обработки транзакций.

Механизм выполнения:

  • Monad будет оптимистично параллельно выполнять все транзакции, предполагая, что большинство транзакций не имеют конфликтов состояния.
  • Одновременно работает «детектор конфликтов», который следит за тем, обращаются ли транзакции к одному и тому же состоянию.
  • Если обнаружен конфликт, конфликтные транзакции будут сериализованы и выполнены повторно для обеспечения корректности состояния.

Monad выбрал совместимый путь: минимальное вмешательство в правила EVM, осуществляя параллелизм за счет отложенной записи состояния и динамического обнаружения конфликтов в процессе выполнения, больше похоже на производительную версию Ethereum, с хорошей зрелостью, что облегчает миграцию экосистемы EVM, являясь параллельным ускорителем мира EVM.

Веб3 Параллельные вычисления: лучшая схема нативного расширения?

Анализ механизма параллельных вычислений MegaETH

В отличие от L1 позиционирования Monad, MegaETH позиционируется как модульный высокопроизводительный параллельный исполняющий слой, совместимый с EVM, который может быть как независимой L1 публичной цепочкой, так и слоем повышения производительности исполнения или модульным компонентом на Ethereum. Его основной целью проектирования является изоляция и декомпозиция логики аккаунта, исполняющей среды и состояния на минимальные единицы, которые могут независимо планироваться, чтобы достичь высокой конкурентоспособности исполнения внутри цепи и низкой задержки отклика. Ключевое нововведение MegaETH заключается в архитектуре Micro-VM + State Dependency DAG (направленный ациклический граф зависимости состояния) и модульном механизме синхронизации, которые вместе создают параллельную исполняющую систему, ориентированную на «потоковую обработку внутри цепи».

Архитектура Micro-VM (микровиртуальная машина): учетная запись как поток

MegaETH внедрил модель выполнения «один микровиртуальный компьютер на каждый аккаунт», «потоковую» среду выполнения, предоставляя минимальную единицу изоляции для параллельного планирования. Эти ВМ общаются друг с другом через асинхронные сообщения, а не через синхронные вызовы, что позволяет большому количеству ВМ работать независимо и хранить данные независимо, естественно обеспечивая параллелизм.

Зависимость состояния DAG: механизм планирования, основанный на графе зависимостей

MegaETH создала систему планирования DAG, основанную на отношениях доступа к состоянию аккаунтов. Система в реальном времени поддерживает глобальную зависимую граф, где каждая транзакция моделируется как изменяющая определенные аккаунты и читающая другие аккаунты. Транзакции без конфликтов могут выполняться параллельно, в то время как транзакции с зависимостями будут планироваться и сортироваться по топологическому порядку, либо последовательно, либо с задержкой. Зависимый граф обеспечивает согласованность состояния и отсутствие повторных записей в процессе параллельного выполнения.

Асинхронное выполнение и механизм обратных вызовов

MegaETH построен на основе асинхронной программной парадигмы, аналогичной асинхронной передаче сообщений модели Actor, решая проблему последовательных вызовов традиционного EVM. Вызов контракта является асинхронным, при вызове контракта A -> B -> C каждый вызов асинхронизируется, не блокируя ожидание; стек вызовов разворачивается в асинхронную графовую структуру вызовов; обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование.

В общем, MegaETH ломает традиционную модель однопоточной машины состояния EVM, реализуя упаковку микро-виртуальной машины на уровне аккаунта, осуществляя планирование транзакций с помощью графа зависимостей состояния и заменяя синхронный стек вызовов асинхронным механизмом сообщений. Это параллельная вычислительная платформа, которая была полностью перепроектирована с «структуры аккаунта → архитектуры планирования → процесса выполнения», предоставляя новый парадигмальный подход для создания систем следующего поколения с высокой производительностью на блокчейне.

MegaETH выбрал путь реконструкции: полностью абстрагируя аккаунты и контракты в независимую VM, используя асинхронное выполнение для освобождения предельного параллельного потенциала. Теоретически, параллельный предел MegaETH выше, но также сложнее контролировать сложность, больше похож на суперраспределённую операционную систему в духе Ethereum.

Панорамная карта параллельных вычислений Web3: лучшее решение для нативного масштабирования?

Дизайнерские концепции Monad и MegaETH значительно отличаются от шардирования (Sharding): шардирование разделяет блокчейн на несколько независимых подсетей, каждая из которых отвечает за часть транзакций и состояния, разрушая ограничения единой цепочки для расширения на уровне сети; в то время как Monad и MegaETH сохраняют целостность единой цепочки, горизонтально расширяясь только на уровне выполнения, достигая оптимизации предельного параллельного выполнения внутри единой цепочки для повышения производительности. Оба представляют собой две направления в пути расширения блокчейна: вертикальное усиление и горизонтальное расширение.

Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на оптимизации пропускной способности с целью повышения TPS в цепочке, реализуя параллельную обработку на уровне транзакций или аккаунтов через отложенное выполнение и архитектуру микро-виртуальных машин. Pharos Network, являющаяся модульной, полнофункциональной параллельной L1 блокчейн-сетью, имеет в своей основе механизм параллельных вычислений, называемый «Rollup Mesh». Эта архитектура поддерживает совместную работу основной сети и специальных обработчиков сетей (SPNs), поддерживает многовиртуальную среду (EVM и Wasm) и интегрирует передовые технологии, такие как доказательства с нулевым раскрытием (ZK) и защищенные среды выполнения (TEE).

Анализ механизма параллельных вычислений Rollup Mesh:

  1. Обработка асинхронного потока на протяжении всего жизненного цикла: Pharos декомпозирует различные этапы транзакции и использует асинхронный способ обработки, что позволяет каждому этапу выполняться независимо и параллельно, тем самым повышая общую эффективность обработки.
  2. Параллельное выполнение двух виртуальных машин: Pharos поддерживает две среды виртуальных машин: EVM и WASM, что позволяет разработчикам выбирать подходящую среду выполнения в зависимости от потребностей. Эта архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и улучшает пропускную способность обработки транзакций за счет параллельного выполнения.
  3. Специальные сети обработки (SPN): SPN являются ключевыми компонентами архитектуры Pharos, аналогичными модульным подсетям, специально предназначенным для обработки определенных типов задач или приложений. С помощью SPN Pharos может реализовать динамическое распределение ресурсов и параллельную обработку задач, что дополнительно повышает масштабируемость и производительность системы.
  4. Модульный консенсус и механизм повторного залога: Pharos ввел гибкий механизм консенсуса, поддерживающий различные модели консенсуса, и реализовал безопасное совместное использование и интеграцию ресурсов между основной сетью и SPNs через протокол повторного залога.

Кроме того, Pharos реформировал модель выполнения на основе хранилища, используя многоверсионные деревья Меркла, дельта-кодирование, адресацию версий и технологии ADS-погружения, выпустив высокопроизводительный хранилище на основе блокчейна Pharos Store, обеспечивающее высокую пропускную способность, низкую задержку и сильную проверяемость данных на цепочке.

Посмотреть Оригинал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Награда
  • 7
  • Поделиться
комментарий
0/400
probably_nothing_anonvip
· 07-08 13:22
Почему увеличение емкости всегда вызывает восторг у каждого?
Посмотреть ОригиналОтветить0
OnChainSleuthvip
· 07-08 02:59
Эта штука слишком сложная, никто не понимает.
Посмотреть ОригиналОтветить0
ruggedNotShruggedvip
· 07-06 13:56
Все бесполезно, лучше сменить на L2.
Посмотреть ОригиналОтветить0
AirdropHunterKingvip
· 07-06 13:53
Ты сразу пришел играть с ловушкой rollup? Газовые расходы просто ужасные.
Посмотреть ОригиналОтветить0
DefiPlaybookvip
· 07-06 13:51
Газ поднялся, все начинают говорить о расширении, упал — все говорят о практической ценности, каждый месяц — новый круговорот.
Посмотреть ОригиналОтветить0
OnchainUndercovervip
· 07-06 13:41
вне блокчейна о чем речь? Давай сразу действовать!
Посмотреть ОригиналОтветить0
CountdownToBrokevip
· 07-06 13:37
бык皮吹ликвидирован 一点都没看懂
Посмотреть ОригиналОтветить0
  • Закрепить