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

I. Введение: Масштабирование — это вечная тема, а параллелизм — окончательная битва

С момента рождения биткоина система блокчейн всегда сталкивалась с неизбежной основной проблемой: масштабированием. Биткоин обрабатывает менее 10 транзакций в секунду, а Ethereum изо всех сил пытается преодолеть узкое место производительности в десятки TPS (транзакций в секунду), что особенно громоздко по сравнению с десятками тысяч TPS в традиционном мире Web2. Что еще более важно, это не простая проблема, которую можно решить путем «добавления серверов», а системное ограничение, глубоко укоренившееся в базовом консенсусе и структурном дизайне блокчейна — то есть в невозможном треугольнике блокчейна, где «децентрализация, безопасность и масштабируемость» не могут быть объединены.

За последнее десятилетие мы стали свидетелями бесчисленных попыток расширения. От войны за масштабирование биткоина до видения шардинга Ethereum, от каналов состояний и плазмы до роллапов и модульных блокчейнов, от выполнения вне сети на уровне 2 до структурного рефакторинга доступности данных — вся отрасль встала на путь масштабирования, полного инженерного воображения. Будучи наиболее широко принятой парадигмой масштабирования, Rollup достиг цели значительного увеличения TPS при одновременном снижении нагрузки на основную цепочку и сохранении безопасности Ethereum. Но это не затрагивает реальных пределов базовой «одноцепочечной производительности» блокчейна, особенно на уровне исполнения, то есть пропускной способности самого блока, которая все еще ограничена древней парадигмой обработки последовательных вычислений в цепочке.

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

На самом деле, в вычислительной парадигме Web2 однопоточные вычисления уже давно устранены современными аппаратными архитектурами и заменены бесконечным потоком моделей оптимизации, таких как параллельное программирование, асинхронное планирование, пулы потоков и микросервисы. Блокчейн, будучи более примитивной и консервативной вычислительной системой с чрезвычайно высокими требованиями к определенности и проверяемости, так и не смог в полной мере использовать эти идеи параллельных вычислений. Это одновременно и ограничение, и возможность. Новые цепочки, такие как Solana, Sui и Aptos, первыми начали это исследование, внедрив параллелизм на архитектурном уровне. Новые проекты, такие как Monad и MegaETH, еще больше подняли параллелизм в цепочке до прорывов в глубоких механизмах, таких как выполнение конвейера, оптимистичный параллелизм и асинхронное управление сообщениями, демонстрируя характеристики, которые становятся все ближе и ближе к современным операционным системам.

Можно сказать, что параллельные вычисления — это не только «метод оптимизации производительности», но и поворотный момент в парадигме модели исполнения блокчейна. Он бросает вызов фундаментальным шаблонам выполнения смарт-контрактов и переопределяет базовую логику упаковки транзакций, доступа к состоянию, отношений вызовов и структуры хранилища. Если роллап — это «перенос транзакций в оффчейн-исполнение», то ончейн-параллелизм — это «построение суперкомпьютерных ядер в блокчейне», и его цель — не просто повысить пропускную способность, а обеспечить по-настоящему устойчивую инфраструктурную поддержку для будущих нативных приложений Web3 (высокочастотная торговля, игровые движки, выполнение моделей ИИ, ончейн-социальные сети и т. д.).

После того как в области Rollup стало наблюдаться стремление к однородности, параллелизм внутри цепи тихо становится решающим фактором в конкуренции Layer1 нового цикла. Производительность больше не просто "быстрее", а это возможность поддерживать целый гетерогенный мир приложений. Это не только техническая гонка, но и борьба за парадигму. Следующая генерация суверенных платформ исполнения в мире Web3, вероятно, родится из этой борьбы параллелизма внутри цепи.

II. Панорама парадигмы масштабирования: пять типов маршрутов, каждый с акцентом на что-то свое

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

! gWKKeSi6ZBFDEQwDsMiIpivEzVzn7V4B5ZRrMw9M.jpeg

Первый путь — это наиболее прямое масштабирование в цепочке, что означает увеличение размера блока, сокращение времени блока или повышение вычислительной мощности за счет оптимизации структуры данных и механизма консенсуса. Этот подход был в центре внимания дебатов о масштабировании биткоина, что привело к форкам фракций «больших блоков», таких как BCH и BSV, а также повлияло на идеи дизайна ранних высокопроизводительных публичных сетей, таких как EOS и NEO. Преимущество такого рода маршрута заключается в том, что он сохраняет простоту одноцепочечной согласованности, которую легко понять и развернуть, но также очень легко коснуться системных верхних пределов, таких как риски централизации, растущие эксплуатационные расходы узла и повышенные трудности синхронизации, поэтому он больше не является основным основным решением в сегодняшнем дизайне, а стал скорее вспомогательным сочетанием других механизмов.

Второй тип маршрута — это off-chain scaling, который представлен каналами состояния и сайдчейнами. Основная идея этого типа пути заключается в том, чтобы переместить большую часть транзакционной активности за пределы цепи и записать только конечный результат в основную цепочку, которая выступает в качестве конечного расчетного уровня. С точки зрения технической философии он близок к асинхронной архитектуре Web2 — постарайтесь оставить тяжелую обработку транзакций на периферии, а основная цепочка будет выполнять минимальную доверенную проверку. Хотя теоретически эта идея может быть бесконечно масштабируемой, модель доверия, безопасность средств и сложность взаимодействия транзакций вне сети ограничивают ее применение. Например, несмотря на то, что Lightning Network имеет четкое позиционирование финансовых сценариев, масштабы экосистемы никогда не взрывались. Тем не менее, несколько конструкций на основе сайдчейна, таких как Polygon POS, не только имеют высокую пропускную способность, но и обнажают недостатки сложного наследования безопасности основной цепи.

Третий тип маршрута является наиболее популярным и широко используемым сверточным маршрутом уровня 2. Этот метод напрямую не изменяет саму основную цепочку, а масштабируется за счет механизма выполнения off-chain и on-chain верификации. Optimistic Rollup и ZK Rollup имеют свои преимущества: первый быстро внедряется и хорошо совместим, но у него есть проблемы с задержкой периода вызова и механизмом защиты от мошенничества; Последний обладает высокой безопасностью и хорошими возможностями сжатия данных, но сложен в разработке и не совместим с EVM. Независимо от типа роллапа, его суть заключается в том, чтобы передать мощности выполнения на аутсорсинг, сохранив данные и верификацию на основной цепочке, чтобы достичь относительного баланса между децентрализацией и высокой производительностью. Быстрый рост таких проектов, как Arbitrum, Optimism, zkSync и StarkNet, доказывает целесообразность этого пути, но он также обнажает среднесрочные узкие места, такие как чрезмерная зависимость от доступности данных (DA), высокие затраты и фрагментированный опыт разработки.

Четвертый тип маршрута — это модульная архитектура блокчейна, появившаяся в последние годы, такая как Celestia, Avail, EigenLayer и т.д. Модульная парадигма выступает за полное разъединение основных функций блокчейна — исполнения, консенсуса, доступности данных и расчетов — несколькими специализированными цепочками для выполнения различных функций, а затем их объединение в масштабируемую сеть с кроссчейн-протоколом. На это направление сильно влияет модульная архитектура операционной системы и концепция компонуемости облачных вычислений, преимущество которой заключается в возможности гибкой замены компонентов системы и значительном повышении эффективности в конкретных областях, таких как DA. Тем не менее, проблемы также очень очевидны: стоимость синхронизации, верификации и взаимного доверия между системами после разделения модулей чрезвычайно высока, экосистема разработчиков крайне фрагментирована, а требования к средне- и долгосрочным стандартам протоколов и кроссчейн-безопасности намного выше, чем при традиционном проектировании цепей. По сути, эта модель больше не строит «цепь», а строит «цепную сеть», которая выдвигает беспрецедентный порог для общего понимания архитектуры, эксплуатации и обслуживания.

Последний тип маршрута, который является предметом последующего анализа в данной статье, — это путь оптимизации внутрицепочечных параллельных вычислений. В отличие от первых четырех типов «горизонтального дробления», которые в основном осуществляют «горизонтальное расщепление» со структурного уровня, параллельные вычисления делают акцент на «вертикальном апгрейде», то есть параллельная обработка атомарных транзакций реализуется путем изменения архитектуры исполняющего движка в рамках единой цепочки. Это требует переписывания логики планирования виртуальных машин и внедрения полного набора современных механизмов планирования компьютерных систем, таких как анализ зависимостей транзакций, прогнозирование конфликтов состояний, управление параллелизмом и асинхронные вызовы. Solana — первый проект, в котором концепция параллельной виртуальной машины реализована в системе на уровне цепочки, которая реализует многоядерное параллельное выполнение через суждение о конфликте транзакций на основе модели учетной записи. Новое поколение проектов, таких как Monad, Sei, Fuel, MegaETH и т. д., еще больше пытается внедрить передовые идеи, такие как выполнение конвейера, оптимистичный параллелизм, разделение хранилища и параллельное разделение для создания высокопроизводительных исполнительных ядер, подобных современным процессорам. Основное преимущество этого направления заключается в том, что ему не нужно полагаться на многоцепочечную архитектуру для достижения прорыва в лимите пропускной способности, и в то же время обеспечивается достаточная вычислительная гибкость для выполнения сложных смарт-контрактов, что является важной технической предпосылкой для будущих сценариев применения, таких как AI Agent, крупномасштабные сетевые игры и высокочастотные деривативы.

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

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

Три. Классификационная карта параллельных вычислений: пять основных путей от аккаунта к инструкции

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

! ymDdJOgxNJpF3CHw4pG2f3dKrLmjctVWnJuIrXkb.jpeg

Самый ранний случай параллелизма на уровне счетов — это парадигма, представленная Solana. Эта модель основана на схеме разделения между счетом и состоянием и определяет наличие конфликтующих отношений с помощью статического анализа набора счетов, участвующих в транзакции. Если набор счетов, к которым обращаются две транзакции, не перекрывается друг с другом, они могут выполняться одновременно на нескольких ядрах. Этот механизм идеально подходит для работы с хорошо структурированными транзакциями с четкими входами и выходами, особенно для программ с предсказуемыми путями, таких как DeFi. Тем не менее, его естественное предположение заключается в том, что доступ к учетной записи предсказуем, а зависимость от состояния может быть статически выведена, что делает его склонным к консервативному исполнению и снижению параллелизма перед лицом сложных смарт-контрактов (таких как динамическое поведение, такое как цепные игры и агенты искусственного интеллекта). Кроме того, перекрестная зависимость между счетами также значительно ослабляет параллельную доходность в некоторых сценариях высокочастотной торговли. В этом отношении среда выполнения Solana высоко оптимизирована, но ее основная стратегия планирования по-прежнему ограничена детализацией учетных записей.

Дальнейшая доработка на основе модели аккаунта, мы выходим на технический уровень объектного параллелизма. Параллелизм на уровне объектов вводит семантическую абстракцию ресурсов и модулей с параллельным планированием в единицах более мелких «объектов состояния». Aptos и Sui являются важными исследователями в этом направлении, особенно последний, который определяет владение и вариативность ресурсов во время компиляции с помощью системы линейных типов языка Move, что позволяет среде выполнения точно контролировать конфликты доступа к ресурсам. По сравнению с параллелизмом на уровне учетных записей, этот метод является более универсальным и масштабируемым, может охватывать более сложную логику чтения и записи состояний и, естественно, обслуживает крайне разнородные сценарии, такие как игры, социальные сети и искусственный интеллект. Однако параллелизм на уровне объектов также приводит к более высокому порогу языка и сложности разработки, и Move не является прямой заменой Solidity, а высокая стоимость экологического переключения ограничивает популяризацию его параллельной парадигмы.

Дальнейший параллелизм на уровне транзакций — это направление, которое исследуется в новом поколении высокопроизводительных цепочек, представленных Monad, Sei и Fuel. Path больше не рассматривает состояния или учетные записи как наименьшую единицу параллелизма, а вместо этого строит граф зависимостей вокруг всей транзакции. Он рассматривает транзакции как атомарные единицы операции, строит графы транзакций (Transaction DAGs) с помощью статического или динамического анализа и полагается на планировщики для параллельного выполнения потока. Такая конструкция позволяет системе максимально эффективно использовать параллелизм интеллектуального анализа данных без необходимости полного понимания базовой структуры состояния. Monad особенно привлекателен тем, что сочетает в себе современные технологии ядра СУБД, такие как оптимистичное управление параллелизмом (OCC), планирование параллельных конвейеров и внеочередное выполнение, приближая выполнение цепочки к парадигме «планировщика графических процессоров». На практике этот механизм требует чрезвычайно сложных менеджеров зависимостей и детекторов конфликтов, а сам планировщик также может стать узким местом, но его потенциальная пропускная способность намного выше, чем у учетной записи или объектной модели, что делает его наиболее теоретической силой в текущем треке параллельных вычислений.

С другой стороны, параллелизм на уровне виртуальной машины встраивает возможности параллельного выполнения непосредственно в базовую логику планирования инструкций виртуальной машины, стремясь полностью преодолеть ограничения, присущие выполнению последовательностей EVM. В качестве «эксперимента с супервиртуальными машинами» в экосистеме Ethereum MegaETH пытается перепроектировать EVM для поддержки многопоточного параллельного выполнения кода смарт-контракта. Базовый уровень позволяет каждому контракту выполняться независимо друг от друга в различных контекстах выполнения с помощью таких механизмов, как сегментированное выполнение, сегментация состояния и асинхронный вызов, и обеспечивает возможную согласованность с помощью параллельного уровня синхронизации. Самая сложная часть этого подхода заключается в том, что он должен быть полностью совместим с существующей семантикой поведения EVM, и в то же время трансформировать всю среду выполнения и газовый механизм, чтобы плавно перенести экосистему Solidity на параллельный фреймворк. Проблема заключается не только в глубине технологического стека, но и в принятии значительных изменений протокола в политической структуре L1 Ethereum. Но в случае успеха MegaETH обещает стать «революцией многоядерных процессоров» в пространстве EVM.

Последний тип пути — это параллелизм на уровне инструкций, который является наиболее детальным и имеет самый высокий технический порог. Идея позаимствована из конвейеров внеочередного выполнения и инструкций в современных процессорах. Эта парадигма утверждает, что, поскольку каждый смарт-контракт в конечном итоге компилируется в инструкции байт-кода, вполне возможно запланировать и переупорядочить каждую операцию таким же образом, как процессор выполняет набор инструкций x86. Команда Fuel изначально внедрила в свою FuelVM переупорядочиваемую модель выполнения на уровне инструкций, и в долгосрочной перспективе, как только механизм выполнения блокчейна реализует предиктивное выполнение и динамическую перестановку зависимых от инструкций, его параллелизм достигнет теоретического предела. Такой подход может даже вывести совместное проектирование блокчейна и аппаратного обеспечения на совершенно новый уровень, сделав цепочку настоящим «децентрализованным компьютером», а не просто «распределенным реестром». Конечно, этот путь все еще находится в теоретической и экспериментальной стадии, а соответствующие планировщики и механизмы проверки безопасности еще не созрели, но он указывает на конечную границу будущего параллельных вычислений.

Таким образом, пять путей — учетная запись, объект, транзакция, виртуальная машина и инструкция — составляют спектр развития внутрицепочечных параллельных вычислений, от статической структуры данных до механизма динамического планирования, от прогнозирования доступа к состоянию до перегруппировки на уровне инструкций, каждый шаг параллельной технологии означает значительное увеличение сложности системы и порога разработки. Но в то же время они также знаменуют собой смену парадигмы в вычислительных моделях блокчейна, от традиционного консенсусного реестра полной последовательности к высокопроизводительной, предсказуемой и диспетчеризируемой среде распределенного выполнения. Это не только догоняющее достижение эффективности облачных вычислений Web2, но и глубокая концепция конечной формы «компьютера на блокчейне». Выбор параллельных путей для различных публичных цепочек также определит предел носителя их будущих прикладных экосистем, а также их основную конкурентоспособность в таких сценариях, как AI Agent, сетевые игры и высокочастотная торговля в сети.

Четыре, глубокое понимание двух основных направлений: Monad против MegaETH

Среди множества путей эволюции параллельных вычислений двумя основными техническими путями с наибольшей направленностью, самым высоким голосом и наиболее полным повествованием на текущем рынке, несомненно, являются «построение параллельной вычислительной цепочки с нуля», представленное Monad, и «параллельная революция внутри EVM», представленная MegaETH. Эти два направления являются не только наиболее интенсивными направлениями исследований и разработок для современных инженеров криптографических примитивов, но и наиболее определенными полярными символами в текущей гонке производительности компьютеров Web3. Разница между ними заключается не только в исходной точке и стиле технической архитектуры, но и в экологических объектах, которые они обслуживают, стоимости миграции, философии реализации и будущем стратегическом пути, стоящем за ними. Они представляют собой параллельную парадигмальную конкуренцию между «реконструктивизмом» и «совместимостью» и оказали глубокое влияние на представление рынка об окончательной форме высокопроизводительных цепей.

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

Что еще более важно, Monad не отказалась от совместимости с EVM. Через промежуточный уровень, аналогичный "Solidity-Compatible Intermediate Language", он помогает разработчикам писать контракты в синтаксисе Solidity, и в то же время выполняет промежуточную оптимизацию языка и планирование распараллеливания в механизме выполнения. Эта стратегия проектирования «поверхностной совместимости и нижнего рефакторинга» не только сохраняет свою дружественность к экологическим разработчикам Ethereum, но и в наибольшей степени высвобождает базовый потенциал исполнения, что является типичной технической стратегией «проглатывания EVM и последующей его деконструкции». Это также означает, что как только Monad будет запущена, она станет не только суверенной цепью с экстремальной производительностью, но и идеальным уровнем исполнения для свертываемых сетей уровня 2, и даже «подключаемым высокопроизводительным ядром» для других модулей выполнения цепочки в долгосрочной перспективе. С этой точки зрения, Monad — это не только технический путь, но и новая логика проектирования системного суверенитета, которая выступает за «модульность-производительность-повторное использование» уровня выполнения, чтобы создать новый стандарт для межцепочечных совместных вычислений.

В отличие от позиции Monad как «нового строителя мира», MegaETH — это совершенно противоположный тип проекта, который решает начать с существующего мира Ethereum и достичь значительного повышения эффективности исполнения с минимальными затратами на изменения. Вместо того, чтобы отменять спецификацию EVM, MegaETH стремится встроить мощь параллельных вычислений в исполнительный движок существующей EVM, чтобы создать будущую версию «многоядерного EVM». Обоснование заключается в полном рефакторинге текущей модели выполнения инструкций EVM с такими возможностями, как изоляция на уровне потока, асинхронное выполнение на уровне контракта и обнаружение конфликтов доступа к состоянию, что позволяет нескольким смарт-контрактам одновременно выполняться в одном блоке и в конечном итоге объединять изменения состояния. Эта модель требует, чтобы разработчики добились значительного прироста производительности от одного и того же контракта, развернутого в цепочке MegaETH, без изменения существующих контрактов Solidity, использования новых языков или наборов инструментов. Этот путь «консервативной революции» чрезвычайно привлекателен, особенно для экосистемы Ethereum L2, поскольку он обеспечивает идеальный путь к безболезненному повышению производительности без необходимости миграции синтаксиса.

Основной прорыв MegaETH заключается в многопоточном механизме планирования виртуальных машин. Традиционные EVM используют многоуровневую однопоточную модель выполнения, в которой каждая инструкция выполняется линейно, а обновления состояния должны происходить синхронно. MegaETH нарушает этот шаблон и вводит асинхронный стек вызовов и механизм изоляции контекста выполнения, чтобы добиться одновременного выполнения «параллельных контекстов EVM». Каждый контракт может вызывать свою собственную логику в отдельном потоке, и все потоки будут одинаково обнаруживать и конвергировать состояние через уровень параллельной фиксации, когда состояние будет окончательно отправлено. Этот механизм очень похож на многопоточную модель JavaScript современных браузеров (Web Workers + Shared Memory + Lock-Free Data), которая сохраняет детерминированность поведения основного потока и вводит высокопроизводительный механизм планирования, который является асинхронным в фоновом режиме. На практике эта конструкция также чрезвычайно удобна для сборщиков блоков и поисковиков и может оптимизировать сортировку Mempool и пути захвата MEV в соответствии с параллельными стратегиями, формируя замкнутый цикл экономических преимуществ на уровне выполнения.

Более того, MegaETH предпочитает быть глубоко привязанным к экосистеме Ethereum, и его основным местоположением в будущем, вероятно, будет сеть EVM L2 Rollup, такая как Optimism, Base или цепочка Arbitrum Orbit. После внедрения в больших масштабах он может достичь почти 100-кратного повышения производительности на вершине существующего технологического стека Ethereum без изменения семантики контрактов, модели состояния, газовой логики, методов вызова и т. д., что делает его привлекательным направлением технологического обновления для консерваторов EVM. Парадигма MegaETH такова: пока вы все еще делаете что-то на Ethereum, я позволю вашей вычислительной производительности взлететь. С точки зрения реализма и инженерии его легче реализовать, чем Monad, и он больше соответствует итеративному пути основных проектов DeFi и NFT, что делает его кандидатом на экологическую поддержку в краткосрочной перспективе.

В каком-то смысле два пути Monad и MegaETH — это не только две реализации параллельных технологических путей, но и классическое противостояние между «рефакторингом» и «совместимостью» в пути разработки блокчейна: первый стремится к прорыву парадигмы и реконструирует всю логику от виртуальных машин до управления базовым состоянием для достижения максимальной производительности и архитектурной пластичности; Последний преследует постепенную оптимизацию, доводя традиционные системы до предела, соблюдая при этом существующие экологические ограничения, тем самым минимизируя затраты на миграцию. Между ними нет абсолютных преимуществ или недостатков, но они служат разным группам разработчиков и экологическим взглядам. Monad больше подходит для создания новых систем с нуля, цепных игр, стремящихся к экстремальной пропускной способности, агентов ИИ и модульных цепочек выполнения. MegaETH, с другой стороны, больше подходит для L2-проектов, DeFi-проектов и инфраструктурных протоколов, которые хотят добиться повышения производительности с минимальными изменениями в разработке.

Они похожи на высокоскоростные поезда на новом пути, переосмысленные с рельсов, электросети на кузов автомобиля, только чтобы достичь беспрецедентной скорости и впечатлений; Другой пример — установка турбин на существующих автомагистралях, улучшение планирования полос движения и конструкции двигателя, что позволяет транспортным средствам двигаться быстрее, не выезжая за пределы привычной дорожной сети. На следующем этапе модульной архитектуры блокчейна Monad может стать модулем «исполнение как услуга» для Rollups, а MegaETH может стать плагином для ускорения производительности для основных L2. В конечном итоге они могут сойтись, чтобы сформировать резонанс двух крыльев высокопроизводительного движка распределенного исполнения в будущем мире Web3.

Пять. Будущие возможности и вызовы параллельных вычислений

По мере того, как параллельные вычисления переходят от бумажного проектирования к реализации в блокчейне, потенциал, который они раскрывают, становится все более конкретным и измеримым. С одной стороны, мы видим, что новые парадигмы разработки и бизнес-модели начали пересматривать «высокую производительность в цепочке»: более сложная логика цепочки игр, более реалистичный жизненный цикл агента ИИ, больше протокола обмена данными в реальном времени, более захватывающий интерактивный опыт и даже операционная система для совместной работы в цепочке Super App — все это меняется от «можно ли это сделать» к «насколько хорошо это можно сделать». С другой стороны, то, что действительно стимулирует переход к параллельным вычислениям, — это не только линейное повышение производительности системы, но и структурное изменение когнитивных границ разработчиков и затраты на экологическую миграцию. Подобно тому, как внедрение в Ethereum механизма полного контракта по Тьюрингу привело к многомерному взрыву DeFi, NFT и DAO, «асинхронная реконструкция между состоянием и инструкцией», вызванная параллельными вычислениями, также порождает новую модель мира в блокчейне, которая является не только революцией в эффективности выполнения, но и очагом инноваций в структуре продукта.

! DOJfWkUvdgXyrZl6ZRNhsiGukJExCYzDIvn6DNC3.jpeg

Прежде всего, с точки зрения возможностей, самая прямая выгода – это «поднятие потолка заявок». Большинство текущих приложений DeFi, игр и социальных приложений ограничены узкими местами состояния, затратами на газ и задержкой и не могут по-настоящему обеспечить высокочастотные взаимодействия в цепочке в больших масштабах. Если взять в качестве примера цепные игры, то GameFi с обратной связью по реальному движению, высокочастотной синхронизацией поведения и логикой боя в реальном времени практически отсутствует, потому что линейное выполнение традиционной EVM не может поддерживать широковещательное подтверждение десятков изменений состояния в секунду. С помощью параллельных вычислений с помощью таких механизмов, как DAG транзакций и асинхронные контексты на уровне контрактов, можно создавать цепочки с высоким уровнем параллелизма, а также гарантировать детерминированные результаты выполнения за счет согласованности моментальных снимков, чтобы достичь структурного прорыва в «игровом движке на цепочке». Аналогичным образом, развертывание и работа агентов ИИ также будут значительно улучшены за счет параллельных вычислений. В прошлом мы, как правило, запускали агентов ИИ вне сети и загружали результаты их поведения только в ончейн-контракты, но в будущем ончейн может поддерживать асинхронное сотрудничество и обмен состоянием между несколькими объектами ИИ за счет параллельного планирования транзакций, чтобы по-настоящему реализовать автономную логику агента в реальном времени. Параллельные вычисления станут инфраструктурой для этого «контракта, управляемого поведением», что приведет Web3 от «транзакций как активов» к новому миру «взаимодействий в качестве агентов».

Во-вторых, набор инструментов разработчика и уровень абстракции виртуальной машины также были структурно изменены из-за распараллеливания. Традиционная парадигма разработки Solidity основана на модели серийного мышления, где разработчики привыкли проектировать логику как однопоточное изменение состояния, но в архитектурах параллельных вычислений разработчики будут вынуждены думать о конфликтах наборов чтения и записи, политиках изоляции состояний, атомарности транзакций и даже внедрять архитектурные шаблоны на основе очередей сообщений или конвейеров состояний. Этот скачок в когнитивной структуре также привел к быстрому росту нового поколения цепочек инструментов. Например, параллельная среда смарт-контрактов, поддерживающая объявления транзакционных зависимостей, компилятор оптимизации на основе IR и параллельный отладчик, поддерживающий симуляцию моментальных снимков транзакций, — все это станет очагом взрыва инфраструктуры в новом цикле. В то же время непрерывная эволюция модульных блокчейнов также привела к отличной посадке для параллельных вычислений: Monad может быть вставлен в L2 Rollup в качестве модуля исполнения, MegaETH может быть развернут в качестве замены EVM для основных цепочек, Celestia обеспечивает поддержку уровня доступности данных, а EigenLayer обеспечивает децентрализованную сеть валидаторов, тем самым формируя высокопроизводительную интегрированную архитектуру от базовых данных до логики выполнения.

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

Более коварные вызовы возникают из-за экологических и психологических аспектов. Готовы ли разработчики перейти на новую парадигму, смогут ли они освоить методы проектирования параллельных моделей и готовы ли они отказаться от некоторой удобочитаемости и проверяемости контрактов ради преимуществ производительности — вот ключ к определению того, могут ли параллельные вычисления формировать экологическую потенциальную энергию. За последние несколько лет мы видели, как ряд цепочек с превосходной производительностью, но без поддержки разработчиков, постепенно замолкали, такие как NEAR, Avalanche и даже некоторые цепочки Cosmos SDK с гораздо лучшей производительностью, чем EVM, и их опыт напоминает нам, что без разработчиков нет экосистемы; Без экологии, какими бы хорошими ни были характеристики, это просто воздушный замок. Таким образом, проекты параллельных вычислений должны не только создавать самый мощный двигатель, но и прокладывать наиболее мягкий путь экологического перехода, чтобы «производительность была нестандартной», а не «производительность была когнитивным порогом».

В конечном счете, будущее параллельных вычислений — это одновременно триумф системной инженерии и испытание для экодизайна. Это заставит нас пересмотреть вопрос о том, «в чем суть цепочки»: это децентрализованная расчетная машина или глобально распределенный государственный оркестратор в реальном времени? Если это так, то возможности пропускной способности состояния, параллелизма транзакций и отзывчивости контрактов, которые ранее рассматривались как «технические детали цепочки», в конечном итоге станут основными показателями, определяющими ценность цепочки. Парадигма параллельных вычислений, которая действительно завершает этот переход, также станет наиболее основными и наиболее сложными инфраструктурными примитивами в этом новом цикле, и ее влияние выйдет далеко за рамки технического модуля и может стать поворотным моментом в общей вычислительной парадигме Web3.

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

Из всех путей для исследования границ производительности Web3 параллельные вычисления не самые простые в реализации, но они могут быть наиболее близкими к сути блокчейна. Он не мигрирует за пределы сети и не жертвует децентрализацией в обмен на пропускную способность, но пытается реконструировать саму модель выполнения в атомарности и детерминизме цепочки, от уровня транзакций, уровня контрактов и уровня виртуальных машин до корня узкого места производительности. Этот «родной для цепочки» метод масштабирования не только сохраняет основную модель доверия блокчейна, но и сохраняет устойчивую производительность для более сложных приложений в цепочке в будущем. Его сложность заключается в структуре, а его очарование заключается в строении. Если модульная реконструкция — это «архитектура цепи», то реконструкция параллельных вычислений — это «душа цепи». Возможно, это не короткий путь к таможенному оформлению, но, вероятно, это будет единственное устойчивое положительное решение в долгосрочной эволюции Web3. Мы являемся свидетелями аналогичного архитектурного перехода от одноядерных процессоров к многоядерным/многопоточным ОС, и появление нативных операционных систем Web3 может быть скрыто в этих параллельных экспериментах в цепочке.