Курс AO

Авторы: 0xjacobzhao и ChatGPT 4o «Безопасность», «децентрализация» и «масштабируемость» блокчейна «Трилемма блокчейна» раскрывают существенный компромисс при проектировании блокчейн-систем, то есть блокчейн-проектам трудно достичь «крайней безопасности, в которой каждый может участвовать, и высокой скорости обработки» одновременно. В ответ на вечную тему «масштабируемости», основные решения для масштабирования блокчейна на рынке делятся по парадигмам, среди которых: Масштабирование с улучшением выполнения: улучшает возможности выполнения, такие как параллелизм, графический процессор и многоядерность, in situ Масштабирование с изолированным состоянием: горизонтальное разделение состояний и сегментов, таких как сегменты, UTXO и мультиподсети. Масштабирование аутсорсинга вне сети: перенос выполнения за пределы сети, например свертки, сопроцессоры и DA Расширение возможностей структурного разделения: архитектура является модульной и работает вместе, например, цепочки модулей, общие секвенсоры и свертывающие сетки Асинхронное параллельное масштабирование: модель субъектов, изоляция процессов, управляемая сообщениями, например агенты и многопоточные асинхронные цепочки Решение для масштабирования блокчейна включает в себя: параллельные вычисления в цепочке, свертку, шардинг, модуль DA, модульную структуру, систему акторов, сжатие zk proof, архитектуру без сохранения состояния и т. д., охватывающие несколько уровней выполнения, состояния, данных и структуры, и представляет собой полную систему масштабирования «многоуровневой совместной работы и комбинации модулей». В этой статье основное внимание уделяется методам масштабирования, которые являются основными для параллельных вычислений. Внутрицепочечный параллелизм, который фокусируется на параллельном выполнении внутриблочных транзакций/инструкций. В соответствии с параллельным механизмом, его методы масштабирования можно разделить на пять категорий, каждая из которых представляет собой различные стремления к производительности, модели разработки и философии архитектуры, причем параллельная гранулярность становится все тоньше и тоньше, интенсивность параллелизма становится все выше и выше, сложность планирования становится все выше и выше, а сложность программирования и реализация также становятся все выше и выше. Account-level: Представляет проект Solana Параллелизм на уровне объектов: представляет проект Sui Уровень транзакции: представляет проект Monad, Aptos Call-level / MicroVM: Представляет проект MegaETH Уровень инструкций: Представляет проект GatlingX Модель асинхронного параллелизма вне цепочки, представленная моделью Actor / Actor Model, относится к другой парадигме параллельных вычислений, как кроссчейн/асинхронная система сообщений (модель синхронизации без блоков), каждый агент выполняется независимо как «агентский процесс», асинхронные сообщения в параллельном режиме, управляемые событиями, без синхронного планирования, репрезентативные проекты, такие как AO, ICP, Cartesi и т.д. Хорошо известная схема свертки или масштабирования шардов относится к механизму параллелизма на системном уровне, а не к внутрицепочечным параллельным вычислениям. Они достигают масштабирования за счет «параллельного запуска нескольких цепочек/доменов выполнения», а не увеличения параллелизма в пределах одного блока/виртуальной машины. Этот тип решения для масштабирования не является предметом обсуждения в этой статье, но мы все же будем использовать его для сравнения сходств и различий в архитектурных концепциях. 2. Цепочка параллельных улучшений EVM: преодоление границы производительности в совместимости С момента разработки архитектуры последовательной обработки Ethereum он претерпел несколько раундов попыток масштабирования, таких как шардинг, свертывание и модульная архитектура, но узкое место пропускной способности уровня исполнения до сих пор фундаментально не преодолено. Но в то же время EVM и Solidity по-прежнему являются платформами смарт-контрактов с наибольшей базой разработчиков и экологическим потенциалом. Таким образом, параллельная цепочка усовершенствования EVM становится важным направлением для нового витка масштабирования и эволюции в качестве ключевого пути, учитывающего экологическую совместимость и повышение производительности исполнения. Monad и MegaETH являются наиболее репрезентативными проектами в этом направлении, начиная с отложенного выполнения и декомпозиции состояния соответственно, и заканчивая построением архитектуры параллельной обработки EVM для сценариев с высоким параллелизмом и высокой пропускной способностью. Анализ параллельного вычислительного механизма монады Monad — это высокопроизводительный блокчейн уровня 1, переработанный для виртуальной машины Ethereum (EVM) и основанный на базовой параллельной концепции конвейеризации, с асинхронным выполнением на уровне консенсуса и оптимистичным параллельным выполнением на уровне исполнения. Кроме того, на уровне консенсуса и хранения Monad представила высокопроизводительный протокол BFT (MonadBFT) и выделенную систему баз данных (MonadDB) соответственно для достижения сквозной оптимизации. Конвейерная обработка: механизм параллельного выполнения для многоступенчатых конвейеров Конвейерная обработка является основной концепцией параллельного выполнения Monad, и ее основная идея заключается в том, чтобы разделить процесс выполнения блокчейна на несколько независимых этапов и обрабатывать эти этапы параллельно, чтобы сформировать трехмерную архитектуру конвейера, каждый этап выполняется на независимых потоках или ядрах для достижения параллельной обработки между блоками и, в конечном итоге, достижения эффекта повышения пропускной способности и уменьшения задержки. Эти этапы включают в себя: Предложение, Консенсус, Исполнение и Фиксация. Асинхронное выполнение: консенсус — выполняет асинхронное разъединение В традиционных цепочках консенсус и выполнение транзакций обычно являются синхронными процессами, и эта последовательная модель серьезно ограничивает масштабирование производительности. 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 представляет модель выполнения «одна микро-виртуальная машина на учетную запись», которая «связывает» среду выполнения и предоставляет минимальную единицу изоляции для параллельного планирования. Эти виртуальные машины взаимодействуют друг с другом с помощью асинхронного обмена сообщениями, а не синхронных вызовов, и большое количество виртуальных машин может выполняться независимо, храниться независимо и естественно работать параллельно. Группа обеспечения доступности баз данных о зависимостях состояния: механизм планирования, управляемый графами MegaETH создала систему планирования DAG на основе отношений доступа к состоянию учетной записи, и система поддерживает глобальный граф зависимостей в режиме реального времени, а какие учетные записи изменяются и какие учетные записи считываются для каждой транзакции, моделируются в зависимости друг от друга. Бесконфликтные транзакции могут выполняться непосредственно параллельно, а зависимые транзакции будут планироваться и сортироваться последовательно или откладываться в топологическом порядке. Графы зависимостей обеспечивают согласованность состояний и отсутствие дубликатов записи во время параллельного выполнения. Механизмы асинхронного выполнения и обратного вызова MegaETH построен на основе парадигмы асинхронного программирования, аналогичной асинхронному обмену сообщениями в модели акторов, которая решает проблему традиционных последовательных вызовов EVM. Вызовы контракта являются асинхронными (нерекурсивное выполнение), и когда вызывается контракт A -> B -> C, каждый вызов является асинхронным без блокировки ожидания; Стек вызовов разворачивается в асинхронный граф вызовов; Обработка транзакций = обход асинхронного графа + разрешение зависимостей + параллельное планирование. В целом, MegaETH ломает традиционную однопоточную модель конечного автомата EVM, реализует инкапсуляцию микро-виртуальных машин для каждой учетной записи, выполняет планирование транзакций с помощью графов, зависящих от состояния, и заменяет синхронный стек вызовов на асинхронный механизм обмена сообщениями. Это платформа параллельных вычислений, которая полностью переработана с учетом «структуры учетной записи→ архитектуры планирования → процесса выполнения», обеспечивая новую идею на уровне парадигмы для создания высокопроизводительной ончейн-системы следующего поколения. MegaETH выбрал путь рефакторинга: он полностью абстрагирует учетные записи и контракты в независимые виртуальные машины и раскрывает потенциал параллелизма с помощью асинхронного планирования выполнения. Теоретически MegaETH имеет более высокую кап параллельности, но и сложность контролировать сложнее, и он больше похож на сверхраспределенную операционную систему под концепцию Ethereum. Концепции дизайна как Monad, так и MegaETH довольно сильно отличаются от шардинга: шардинг горизонтально делит блокчейн на несколько независимых сабчейнов (шардов), и каждый сабчейн отвечает за часть транзакций и состояний, преодолевая лимит одной цепи и масштабируясь на сетевом уровне; С другой стороны, и Monad, и MegaETH сохраняют целостность одной цепи, масштабируясь горизонтально только на уровне исполнения и выполняя прорывы оптимизации параллельно на пределе одной цепи. Эти два направления представляют два направления: вертикальное усиление и горизонтальное расширение на пути расширения блокчейна. Проекты параллельных вычислений, такие как Monad и MegaETH, в основном сосредоточены на пути оптимизации пропускной способности с основной целью улучшения TPS в цепочке и достигают параллельной обработки на уровне транзакций или учетной записи за счет отложенного выполнения и архитектур микро-виртуальных машин. Pharos Network — это модульная параллельная блокчейн-сеть L1 с полным стеком, а ее основная система параллельных вычислений называется «Rollup Mesh». Эта архитектура поддерживает среды с несколькими виртуальными машинами (EVM и Wasm) за счет синергии основной сети и специальных сетей обработки (SPN), а также интегрирует передовые технологии, такие как доказательства с нулевым разглашением (ZK) и доверенные среды выполнения (TEE). Анализ параллельных вычислений с помощью сверточной сетки: Асинхронная конвейеризация полного жизненного цикла: Pharos разделяет различные этапы транзакции (например, консенсус, выполнение, хранение) и использует асинхронную обработку, так что каждый этап может выполняться независимо и параллельно, тем самым повышая общую эффективность обработки. Параллельное выполнение двух виртуальных машин: Pharos поддерживает виртуальные машины EVM и WASM, что позволяет разработчикам выбирать правильную среду выполнения для своих нужд. Такая архитектура с двумя виртуальными машинами не только повышает гибкость системы, но и ускоряет обработку транзакций за счет параллельного выполнения. Специальные вычислительные сети (SPN): SPN являются ключевыми компонентами архитектуры Pharos, аналогичными модульным подсетям, предназначенным для обработки определенных типов задач или приложений. С помощью SPN Pharos обеспечивает динамическое распределение ресурсов и параллельную обработку задач, что еще больше повышает масштабируемость и производительность системы. Модульный консенсус и рестейкинг: Pharos представляет гибкий механизм консенсуса, который поддерживает несколько моделей консенсуса (таких как PBFT, PoS, PoA) и обеспечивает безопасное совместное использование и интеграцию ресурсов между основной сетью и SPN через протокол повторного стейкинга. Кроме того, Pharos реконструирует модель выполнения из нижнего слоя движка хранилища с помощью многоверсионного дерева Меркла, Delta Encoding, Versioned Addressing и технологии ADS Pushdown, а также запускает Pharos Store, высокопроизводительный движок хранения для нативного блокчейна, чтобы достичь высокой пропускной способности, низкой задержки и надежных проверяемых возможностей обработки в цепочке. В целом, архитектура Rollup Mesh от Pharos обеспечивает высокопроизводительные возможности параллельных вычислений благодаря модульной конструкции и механизму асинхронной обработки. В дополнение к архитектурам параллельного выполнения Monad, MegaETH и Pharos, мы также наблюдаем, что на рынке есть некоторые проекты, которые исследуют путь применения ускорения GPU в параллельных вычислениях EVM в качестве важного дополнения и передового эксперимента для параллельной экосистемы EVM. Среди них Reddio и GatlingX являются двумя репрезентативными направлениями: Reddio — это высокопроизводительная платформа, которая сочетает в себе zkRollup с архитектурой параллельного выполнения GPU, а ее ядром является рефакторинг процесса выполнения EVM для достижения нативного распараллеливания уровня выполнения с помощью многопоточного планирования, асинхронного хранения состояний и ускорения пакетов транзакций с помощью GPU. Параллельная гранулярность на уровне транзакций + операций (опкод многопоточного выполнения). Он предназначен для внедрения многопоточного пакетного выполнения, асинхронной загрузки состояний и логики транзакций параллельной обработки GPU (CUDA-совместимая параллельная EVM). Как и Monad / MegaETH, Reddio также фокусируется на параллельной обработке на уровне выполнения, с той разницей, что механизм выполнения реконструируется с помощью параллельной архитектуры GPU, предназначенной для сценариев с высокой пропускной способностью и интенсивными вычислениями, таких как вывод искусственного интеллекта. В настоящее время SDK запущен, а также предоставлен интегрированный модуль исполнения Называя себя «GPU-EVM», GatlingX предлагает более радикальную архитектуру, которая пытается перенести модель «последовательного выполнения на уровне инструкций» традиционных виртуальных машин EVM в нативные среды параллельного выполнения на GPU. Основной механизм заключается в динамической компиляции байт-кода EVM в параллельные задачи CUDA и выполнении потока инструкций через многоядерный графический процессор, чтобы преодолеть последовательное узкое место EVM на самом низком уровне. Параллельная гранулярность, относящаяся к параллелизму на уровне инструкций (ILP). По сравнению с гранулярностью параллельного подхода «на уровне транзакций/учетной записи» в Monad / MegaETH, механизм параллелизма GatlingX относится к пути оптимизации на уровне инструкций, который ближе к базовому рефакторингу ядра виртуальной машины. В настоящее время он находится на стадии разработки концепции, опубликованы технический документ и архитектурный эскиз, а SDK или основной сети еще нет. Artela предлагает дифференцированную, параллельную концепцию дизайна. С внедрением виртуальной машины WebAssembly (WASM) с архитектурой EVM++ разработчикам разрешено динамически добавлять и выполнять расширения в блокчейне, используя модель программирования Aspect, сохраняя при этом совместимость с EVM. Он использует гранулярность вызова контракта (Function / Extension) в качестве минимальной параллельной единицы и поддерживает внедрение модулей Extension (аналогично «подключаемому промежуточному программному обеспечению») во время выполнения контракта EVM, чтобы достичь логической развязки, асинхронного вызова и параллельного выполнения на уровне модуля. Больше внимания уделяется компонуемости и модульной архитектуре слоя выполнения. Концепция дает новые идеи для сложных многомодульных приложений в будущем. 3. Собственная цепочка параллельной архитектуры: реконструкция онтологии выполнения виртуальных машин Модель исполнения EVM Ethereum с самого начала разработки приняла однопоточную архитектуру «полный порядок транзакций + серийное выполнение», направленную на обеспечение определенности и согласованности изменений состояния для всех узлов в сети. Однако эта архитектура имеет естественное узкое место в производительности, ограничивающее пропускную способность системы и масштабируемость. В отличие от них, собственные цепочки параллельных вычислений, такие как Solana (SVM), MoveVM (Sui, Aptos) и Sei v2, построенные на основе Cosmos SDK, предназначены для параллельного выполнения с нижнего уровня и имеют следующие преимущества: Естественное разделение моделей состояний: Solana использует механизм объявления блокировки учетной записи, MoveVM представляет модель владения объектами, а Sei v2 реализует статическое суждение о конфликтах на основе классификации типов транзакций и поддерживает параллельное планирование на уровне транзакций. Виртуальные машины оптимизированы для параллелизма: движок Sealevel от Solana изначально поддерживает многопоточное выполнение; MoveVM может выполнять статический анализ графов параллелизма; Sei v2 интегрирует многопоточный механизм согласования с модулем параллельной виртуальной машины. Конечно, этот вид нативной параллельной цепи также сталкивается с проблемой экологической совместимости. Архитектуры, отличные от EVM, обычно требуют новых языков разработки (таких как Move и Rust) и наборов инструментов, которые требуют определенных затрат на миграцию для разработчиков. Кроме того, разработчикам необходимо освоить ряд новых концепций, таких как модели доступа с отслеживанием состояния, ограничения параллелизма, жизненные циклы объектов и т. д., которые выдвигают более высокие требования к пониманию пороговых значений и парадигм разработки. 3.1 Принцип параллельного двигателя на уровне моря в Solana и SVM Модель выполнения Sealevel от Solana представляет собой механизм параллельного планирования учетных записей, который является основным механизмом, используемым Solana для реализации выполнения параллельных транзакций в цепочке, и обеспечивает высокопроизводительный параллелизм на уровне смарт-контракта с помощью механизма «объявление учетной записи + статическое планирование + многопоточное выполнение». Sealevel — это первая модель исполнения в области блокчейна, которая успешно реализовала параллельное планирование внутри сети в производственной среде, а ее архитектурные идеи повлияли на многие последующие проекты параллельных вычислений, а также является эталонной парадигмой для высокопроизводительного параллельного проектирования уровня 1. Основная механика: 1. Явные списки доступа к учетным записям: Каждая транзакция должна объявлять задействованную учетную запись (чтение/запись) при отправке, чтобы система могла определить, существует ли конфликт статусов между транзакциями. 2. Обнаружение конфликтов и многопоточное планирование Если наборы счетов, к которым обращаются две транзакции, не перекрываются→ они могут выполняться параллельно; Возникает конфликт→ выполняется последовательно в зависимом порядке; Планировщик распределяет транзакции по различным потокам на основе графа зависимостей. 3. Контекст вызова программы: Каждый вызов контракта выполняется в изолированном контексте без общего стека, чтобы избежать перекрестных помех вызовам. Sealevel — это механизм параллельного планирования выполнения Solana, в то время как SVM — это среда выполнения смарт-контрактов, построенная на основе Sealevel (с использованием виртуальной машины BPF). Вместе они образуют техническую основу высокопроизводительной системы параллельного выполнения Solana. Eclipse — это проект, который развертывает виртуальные машины Solana в модульных цепочках, таких как Ethereum L2 или Celestia, используя механизм параллельного выполнения Solana в качестве уровня выполнения свертывания. Eclipse является одним из первых проектов, предлагающих отделить уровень исполнения Solana (Sealevel + SVM) от основной сети Solana и перевести его на модульную архитектуру, а модульным выходом «суперпараллельной модели выполнения» Solana является Execution Layer-as-a-Service, поэтому Eclipse также относится к категории параллельных вычислений. Путь Neon отличается, он вводит EVM для работы в среде SVM / Sealevel. Создайте EVM-совместимый уровень времени выполнения, разработчики могут использовать Solidity для разработки контрактов и запуска в среде SVM, но для выполнения расписания используется SVM + Sealeve. Neon больше склоняется к категории модульного блокчейна, чем к инновациям в области параллельных вычислений. В целом, Solana и SVM полагаются на механизм выполнения Sealevel, а философия планирования на основе ОС Solana похожа на планировщик ядра, который быстрый, но относительно негибкий. Это нативная высокопроизводительная публичная цепочка параллельных вычислений. 3.2 Архитектура MoveVM: управляемая ресурсами и объектами MoveVM — это виртуальная машина со смарт-контрактами, предназначенная для безопасности ресурсов в цепочке и параллельного выполнения, а ее основной язык, Move, изначально был разработан компанией Meta (ранее Facebook) для проекта Libra, подчеркивая концепцию «ресурсы — это объекты», а все ончейн-состояния существуют как объекты, с четким владением и жизненными циклами. Это позволяет MoveVM анализировать, есть ли конфликты состояний между транзакциями во время компиляции, и реализовывать статическое параллельное планирование на уровне объектов, которое широко используется в нативных параллельных открытых цепочках, таких как Sui и Aptos. Модель владения объектами Sui Возможности параллельных вычислений Sui проистекают из уникального подхода к моделированию состояний и статическому анализу на уровне языка. В отличие от традиционных блокчейнов, которые используют глобальные деревья состояний, Sui построил объектно-ориентированную модель на основе «объекта», которая работает с системой линейных типов MoveVM, чтобы сделать параллельное планирование детерминированным процессом, который может быть завершен во время компиляции. Объектная модель является основой параллельной архитектуры Sui. Sui абстрагирует все состояние в цепочке в отдельные объекты, каждый из которых имеет уникальный идентификатор, четкого владельца (учетную запись или контракт) и определение типа. Эти объекты не имеют общего состояния друг с другом и по своей сути изолированы. Контракт должен явно объявлять коллекцию задействованных объектов при его вызове, что позволяет избежать проблемы связывания состояний в традиционном ончейн-«глобальном дереве состояний». Такая конструкция разделяет состояние в цепочке на несколько независимых блоков, что делает параллельное выполнение структурно осуществимой предпосылкой планирования. Статический анализ владения — это механизм анализа во время компиляции, реализованный с помощью системы линейных типов языка Move. Это позволяет системе планировать параллельное выполнение транзакций, определяя, какие транзакции не имеют конфликтов состояний через владение объектом, прежде чем они будут выполнены. По сравнению с обнаружением конфликтов и откатом традиционных сред выполнения, механизм статического анализа Sui значительно снижает сложность планирования при одновременном повышении эффективности выполнения, что является ключом к достижению высокой пропускной способности и возможностей детерминированной параллельной обработки. Sui делит пространство состояний по принципу «объект» в сочетании с анализом владения во время компиляции для достижения недорогого параллельного выполнения на объектном уровне без отката. По сравнению с последовательным выполнением или обнаружением во время выполнения традиционных цепочек, Sui добилась значительного повышения эффективности выполнения, системного детерминизма и использования ресурсов. Механизм принудительного применения Block-STM от Aptos Aptos — это высокопроизводительный блокчейн уровня 1, основанный на языке Move, а его возможности параллельного выполнения в основном основаны на самостоятельно разработанной инфраструктуре Block-STM (Block-level Software Transactional Memory). В отличие от стратегии Суи «статического параллелизма во время компиляции», Block-STM относится к механизму динамического планирования «оптимистичный параллелизм во время выполнения + откат конфликта», который подходит для работы с наборами транзакций со сложными зависимостями. Block-STM делит выполнение транзакций в блоке на три этапа: Спекулятивное выполнение: Все транзакции по умолчанию бесконфликтны перед выполнением, и система планирует транзакции в несколько потоков для параллельных попыток выполнения, а также записывает статус учетной записи (чтение набора/запись набора), к которому они обращаются. Фаза валидации: система проверяет результат выполнения: если между двумя транзакциями возникает конфликт чтения и записи (например, Tx1 считывает состояние, которое записывается Tx2), одна из них откатывается. Фаза повтора: конфликтующие транзакции будут перенесены до тех пор, пока их зависимости не будут разрешены, и в конечном итоге все транзакции сформируют допустимую детерминированную последовательность отправки состояний. Block-STM — это динамическая модель выполнения «оптимистичный параллелизм + откат и повторные попытки», которая подходит для сценариев пакетной обработки транзакций с интенсивным состоянием и логически сложной в цепочке, а также является ядром параллельных вычислений для Aptos для создания высокоуниверсальной и высокопроизводительной публичной цепочки. Solana — это инженерная школа планирования, больше похожая на «ядро операционной системы», подходящая для четких границ состояния, контролируемой высокочастотной торговли, и представляет собой стиль инженера по аппаратному обеспечению, который должен запускать цепочку как аппаратное обеспечение (Hardware-grade parallel execution); Aptos — это отказоустойчивая система, больше похожая на «движок параллелизма баз данных», подходящая для контрактных систем с сильной связью состояний и сложными цепочками вызовов. Aptos и Sui похожи на инженеров по языкам программирования, а безопасность ресурсов программного уровня представляет собой путь технической реализации параллельных вычислений Web3 в соответствии с различными философиями. 3.3 Параллельное расширение Cosmos SDK Sei V2 — это высокопроизводительная транзакционная публичная цепочка, построенная на основе Cosmos SDK, и ее возможности параллелизма в основном отражаются в двух аспектах: многопоточном механизме сопоставления (Parallel Matching Engine) и оптимизации параллельного выполнения на уровне виртуальной машины, направленной на обслуживание сценариев транзакций с высокой частотой и низкой задержкой, таких как DEX в книге заказов, инфраструктура обмена в цепочке и т. д. Основной параллельный механизм: Parallel Matching Engine: SEI V2 вводит многопоточный путь исполнения в логику сопоставления ордеров, разделяя отложенную книгу ордеров и логику сопоставления на уровне потоков, чтобы задачи сопоставления между несколькими торговыми парами могли обрабатываться параллельно и избегать узких мест в однопоточном режиме. Оптимизация параллелизма на уровне виртуальной машины: Sei V2 создает среду выполнения CosmWasm с возможностями параллельного выполнения, которая позволяет некоторым вызовам контрактов выполняться параллельно без конфликтов состояний и взаимодействует с механизмом классификации типов транзакций для достижения более высокого контроля пропускной способности. Параллельное планирование консенсуса и уровня выполнения: Так называемый механизм консенсуса «Twin-Turbo» введен для усиления пропускной способности и разъединения между уровнем консенсуса и уровнем выполнения, а также для повышения общей эффективности обработки блоков. 3.4 Топливо для системы риформинга модели UTXO Fuel — это высокопроизводительный уровень исполнения, разработанный на основе модульной архитектуры Ethereum, а его основной параллелизм выведен из улучшенной модели UTXO (Unspent Transaction Output). В отличие от модели учетных записей Ethereum, Fuel использует структуру UTXO для представления активов и состояний, которая по своей сути изолирована от состояния, что позволяет легко определить, какие транзакции могут быть безопасно выполнены параллельно. Кроме того, Fuel представляет самостоятельно разработанный язык смарт-контрактов Sway (похожий на Rust) в сочетании с инструментами статического анализа для определения конфликтов ввода до выполнения транзакций, чтобы достичь эффективного и безопасного параллельного планирования на уровне транзакций. Это альтернативный уровень выполнения EVM, который сочетает в себе производительность и модульность. 4. Акторная модель: новая парадигма параллельного выполнения агентов Акторная модель — это парадигма параллельного выполнения, основанная на агенте или процессе, которая отличается от традиционного синхронного вычисления глобального состояния в цепочке (Solana/Sui/Monad и другие сценарии «параллельных вычислений в цепочке»), в котором подчеркивается, что каждый агент имеет независимое состояние и поведение, а также взаимодействует и планирует через асинхронные сообщения. В рамках этой архитектуры ончейн-система может одновременно запускаться большим количеством процессов, которые отделены друг от друга, и обладает высокой масштабируемостью и асинхронной отказоустойчивостью. Среди репрезентативных проектов — AO (Arweave AO), ICP (Internet Computer) и Cartesi, которые управляют эволюцией блокчейна от механизма исполнения до «ончейн-операционной системы», обеспечивая нативную инфраструктуру для агентов ИИ, многозадачных взаимодействий и сложной логической оркестровки. Несмотря на то, что структура акторной модели похожа на шардинг с точки зрения поверхностных характеристик (например, параллелизма, изоляции состояния и асинхронной обработки), по сути, они представляют совершенно разные технические пути и системные философии. Акторная модель делает акцент на «многопроцессных асинхронных вычислениях», где каждый агент работает независимо, поддерживает состояние независимо и взаимодействует на основе сообщений. Шардинг, с другой стороны, — это механизм «горизонтального шардинга состояния и консенсуса», который делит весь блокчейн на несколько подсистем (шардов), которые обрабатывают транзакции независимо. Модели акторов больше похожи на «распределенную операционную систему агента» в мире Web3, в то время как шардинг — это решение для структурного масштабирования для возможностей обработки транзакций в сети. Оба обеспечивают параллелизм, но имеют разные начальные точки, цели и архитектуры выполнения. 4.1 AO (Arweave), суперпараллельный компьютер поверх уровня хранилища AO — это децентрализованная вычислительная платформа, работающая на уровне постоянного хранения Arweave, основной целью которой является создание операционной системы в цепочке, поддерживающей крупномасштабную асинхронную работу агентов. Основные особенности архитектуры: Архитектура процесса: Каждый агент называется процессом с независимым состоянием, независимым планировщиком и логикой выполнения. Нет структуры блокчейна: AO — это не цепочка, а децентрализованный слой хранения + мультиагентный движок выполнения на основе сообщений на основе Arweave; Асинхронная система планирования сообщений: процессы взаимодействуют друг с другом с помощью сообщений, используют асинхронную операционную модель без блокировок и, естественно, поддерживают параллельное расширение. Постоянное хранение состояния: Все состояния агентов, записи сообщений и инструкции постоянно записываются в Arweave, что обеспечивает полную проверяемость и децентрализованную прозрачность. Agent-native: подходит для развертывания сложных многошаговых задач (таких как агенты AI, контроллеры протокола DePIN, автоматические оркестраторы задач и т. д.) и может создать «сопроцессор искусственного интеллекта в цепочке». AO идет по пути «нативный агент + драйвер хранилища + бесцепная архитектура», подчеркивая гибкость и разделение модулей, и представляет собой «микроядерный фреймворк в цепочке, построенной поверх уровня хранения», с намеренно сужающейся границей системы, подчеркивая облегченные вычисления + компонуемую структуру управления. 4.2 ICP (Internet Computer) — полнофункциональная хостинговая платформа Web3 ICP — это нативная полнофункциональная платформа приложений Web3, запущенная DFINITY с целью расширения вычислительной мощности в цепочке до возможностей, подобных Web2, и поддержки полного хостинга услуг, привязки доменных имен и бессерверной архитектуры. Основные особенности архитектуры: Архитектура контейнера (контейнеры в качестве агентов): каждый контейнер — это агент, работающий на виртуальной машине Wasm с независимым состоянием, кодом и возможностями асинхронного планирования. Распределенная система консенсуса (подсеть): Вся сеть состоит из нескольких подсетей, каждая из которых поддерживает набор канистр и достигает консенсуса с помощью механизма подписи BLS. Модель асинхронного вызова: Canister взаимодействует с Canister через асинхронные сообщения, поддерживает неблокирующее выполнение и имеет естественный параллелизм. Ончейн-хостинг: поддерживает смарт-контракты для прямого размещения фронтенд-страниц, нативное сопоставление DNS и является первой блокчейн-платформой, которая поддерживает браузеры для прямого доступа к dApps; Система обладает полным набором функций: у нее есть системные API, такие как горячее обновление в цепочке, аутентификация личности, распределенная случайность и таймер, который подходит для сложного развертывания ончейн-сервисов. ICP выбирает парадигму операционной системы с тяжелой платформой, интегрированным пакетом и сильным контролем платформы, а также имеет «операционную систему блокчейна», которая объединяет консенсус, выполнение, хранение и доступ, подчеркивая полные возможности хостинга услуг и расширяя границы системы до полнофункциональной хостинговой платформы Web3. Кроме того, проекты параллельных вычислений для других парадигм модели акторов можно найти в следующей таблице: 5. Резюме и перспективы Основываясь на различиях между архитектурой виртуальной машины и языковой системой, решения для параллельных вычислений на блокчейне можно условно разделить на две категории: цепочка параллельных улучшений EVM и собственная цепочка параллельной архитектуры (без EVM). На основе сохранения совместимости экосистемы EVM/Solidity, первый обеспечивает более высокую пропускную способность и возможности параллельной обработки за счет глубокой оптимизации уровня исполнения, что подходит для сценариев, которые хотят унаследовать активы Ethereum и инструменты разработки и в то же время добиться прорыва в производительности. К наиболее представительным проектам относятся: Monad: Реализуйте оптимистичную модель параллельного выполнения, совместимую с EVM, с помощью отложенной записи и обнаружения конфликтов во время выполнения, создавайте графы зависимостей после достижения консенсуса и планируйте выполнение в нескольких потоках. MegaETH: Абстрагирует каждую учетную запись/контракт в независимую микро-виртуальную машину и реализует сильно развязанное параллельное планирование на уровне учетной записи на основе асинхронного обмена сообщениями и графов, зависящих от состояния. Pharos: Создание архитектуры свертной сетки для достижения параллельной обработки процессов на системном уровне с помощью асинхронных конвейеров и модулей SPN. Reddio: использует архитектуру zkRollup + GPU для ускорения процесса проверки zkEVM вне сети за счет пакетной генерации SNARK и повышения пропускной способности проверки. Последний полностью избавляет от ограничений совместимости Ethereum и пересматривает парадигму выполнения виртуальной машины, модели состояния и механизма планирования для достижения нативного высокопроизводительного параллелизма. Типичные подклассы включают: Solana (SVM): основанная на утверждениях о доступе к учетным записям и статическом графе конфликтов, она представляет собой модель параллельного выполнения на уровне учетной записи. Sui / Aptos (система MoveVM): Основанный на объектной модели ресурсов и системе типов, он поддерживает статический анализ во время компиляции и реализует параллелизм на объектном уровне. Sei V2 (маршрут Cosmos SDK): представляет многопоточный механизм сопоставления и оптимизацию параллелизма виртуальных машин в архитектуре Cosmos, которая подходит для транзакционных высокочастотных приложений. Топливо (архитектура UTXO + Sway): параллелизм на уровне транзакций за счет статического анализа входного набора UTXO, сочетающий модульный уровень исполнения с настраиваемым языком смарт-контрактов Sway; Кроме того, будучи более обобщенной параллельной системой, модель акторов создает парадигму выполнения в цепочке «независимая от нескольких агентов операция + совместная работа на основе сообщений» с помощью механизма асинхронного планирования процессов на основе Wasm или пользовательских виртуальных машин. К наиболее представительным проектам относятся: AO (Arweave AO): создает ончейн-асинхронную систему микроядра на основе среды выполнения агента, управляемой постоянным хранилищем. ICP (Internet Computer): использует контейнерный агент (Canister) в качестве наименьшей единицы для достижения асинхронного и масштабируемого выполнения за счет координации подсети. Cartesi: представляет операционную систему Linux в качестве автономной вычислительной среды для обеспечения пути проверки доверенных вычислительных результатов в сети, подходящей для сложных или ресурсоемких сценариев приложений. Основываясь на приведенной выше логике, мы можем обобщить текущую схему публичной цепочки параллельных вычислений в структуру классификации, как показано на следующем рисунке: С более широкой точки зрения, шардинг и свертывание (L2) сосредоточены на горизонтальном масштабировании за счет сегментирования состояния или выполнения вне цепочки, в то время как параллельные вычислительные цепочки (например, Monad, Sui, Solana) и системы, ориентированные на акторов (например, AO, ICP), напрямую реконструируют модель выполнения и достигают собственного параллелизма внутри цепочки или на системном уровне. Первый повышает пропускную способность внутри сети за счет многопоточных виртуальных машин, объектных моделей, анализа конфликтов транзакций и т. д.; Последний принимает процесс/агента в качестве базовой единицы и использует режимы управляемого сообщениями и асинхронного выполнения для достижения многоагентной параллельной работы. В отличие от этого, шардинг и роллапы больше похожи на «разделение нагрузки на несколько цепочек» или «аутсорсинг вне цепочки», в то время как модель параллельной цепочки и акторов «высвобождает потенциал производительности из самого механизма выполнения», что отражает более тщательную эволюцию архитектуры. Параллельные вычисления, архитектура сегментирования, свертное масштабирование и сравнение путей масштабирования, ориентированного на акторов Следует отметить, что большинство цепочек нативной параллельной архитектуры вступили в стадию запуска основной сети, хотя общую экосистему разработчиков все еще сложно сравнить с системой Solidity системы EVM, но проекты в лице Solana и Sui, с их высокопроизводительной архитектурой исполнения и постепенным процветанием экологических приложений, стали ядром публичных цепочек, на которые рынок обращает большое внимание. Напротив, хотя экосистема Ethereum Rollup (L2) вступила в стадию «10 000 цепочек одновременно» или даже «избыточных мощностей», текущая основная параллельная цепочка улучшения EVM все еще в целом находится на стадии тестовой сети и еще не была проверена фактической средой основной сети, а ее масштабируемость и стабильность системы все еще нуждаются в дальнейших испытаниях. Еще неизвестно, смогут ли эти проекты значительно повысить производительность EVM и совершить экологический скачок без ущерба для совместимости, или же они могут еще больше дифференцировать ликвидность и ресурсы разработки Ethereum.

Рад видеть, как растут встречи сообщества Permabites!