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

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

С момента своего появления блокчейн-системы сталкиваются с основной проблемой масштабируемости. Производительность Биткойна и Эфириума трудно преодолеть традиционные возможности обработки Web2. Это не просто вопрос увеличения серверов, а связано с системными ограничениями в базовом проектировании блокчейна — невозможным треугольником, в котором не могут сосуществовать "децентрализация, безопасность и масштабируемость".

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

Параллельные вычисления в цепочке постепенно попадают в поле зрения отрасли. Они пытаются полностью переработать исполнительный движок, сохраняя атомарность и интегрированную структуру единой цепочки, обновляя блокчейн из однонитевого режима "последовательного выполнения транзакций" в высокопроизводительную вычислительную систему "многопоточность + конвейер + планирование зависимостей". Это не только может привести к многократному увеличению пропускной способности, но и стать ключевым условием для взрыва применения смарт-контрактов.

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

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

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

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

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

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

Третий тип маршрута — это в настоящее время самый популярный и широко развернутый маршрут Layer2 Rollup. Этот метод не изменяет саму основную цепь, а реализует масштабируемость через механизм выполнения вне цепи и верификации на цепи. Optimistic Rollup и ZK Rollup имеют свои преимущества: первый обеспечивает быструю реализацию и высокую совместимость, но сталкивается с проблемами задержки в периоде вызова и механизмом доказательства мошенничества; второй обладает высокой безопасностью и хорошими возможностями сжатия данных, но имеет сложную разработку и недостаточную совместимость с EVM. Независимо от типа Rollup, его суть заключается в аутсорсинге прав на выполнение, при этом данные и верификация остаются на основной цепи, достигая относительного баланса между децентрализацией и высокой производительностью. Быстрый рост некоторых проектов Layer2 доказал жизнеспособность этого пути, но также выявил сильную зависимость от доступности данных (DA), все еще высокие затраты и разрозненный опыт разработки как среднесрочные проблемы.

Четвертый тип маршрута - это модульная архитектура блокчейна, возникшая в последние годы, такие как Celestia, Avail, EigenLayer и др. Модульная парадигма утверждает, что основные функции блокчейна - выполнение, консенсус, доступность данных, расчет - должны быть полностью декомпозированы, и разные специализированные цепочки выполняют различные функции, а затем объединяются в масштабируемую сеть с помощью межцепочных протоколов. Это направление сильно влияет на модульные архитектуры операционных систем и концепции облачных вычислений. Его преимущество заключается в том, что можно гибко заменять компоненты системы и значительно повышать эффективность на определенных этапах (, таких как DA). Однако его вызовы также весьма очевидны: после декомпозирования модулей затраты на синхронизацию, верификацию и доверие между системами крайне высоки, экосистема разработчиков чрезвычайно децентрализована, а требования к долгосрочным стандартам протоколов и межцепочной безопасности значительно превышают требования традиционного проектирования цепей. Эта модель по сути больше не строит "цепь", а создает "цепочную сеть", что ставит перед пониманием общей архитектуры и эксплуатацией невиданные ранее барьеры.

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

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

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

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

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

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

На основе модели учетной записи мы далее уточняем и переходим на уровень технологий, ориентированный на объектное параллельное выполнение. Объектное параллельное выполнение вводит семантическую абстракцию ресурсов и модулей, проводя конкурентное распределение по более мелким "объектам состояния". Некоторые проекты нового поколения Layer1 являются важными исследователями в этом направлении, особенно последние, которые через линейную типовую систему языка Move определяют владение ресурсами и изменяемость на этапе компиляции, что позволяет точно контролировать конфликты доступа к ресурсам во время выполнения. Этот подход более универсален и масштабируем по сравнению с параллельным выполнением на уровне учетной записи, может покрывать более сложную логику чтения и записи состояния и естественным образом служит для высокогетерогенных сценариев, таких как игры, социальные сети, ИИ и т. д. Однако объектное параллельное выполнение также вводит более высокие языковые барьеры и сложность разработки, Move не является прямой заменой Solidity, затраты на переход экосистемы высоки, что ограничивает скорость распространения его параллельной парадигмы.

Дальнейшая параллельность на уровне транзакций является направлением, исследуемым новым поколением высокопроизводительных цепей, представленным Monad, Sei и Fuel. Этот путь больше не рассматривает состояние или учетную запись как минимальные параллельные единицы, а вместо этого строит граф зависимостей вокруг самой транзакции. Транзакция рассматривается как атомная операция, и граф транзакций (Transaction DAG) строится с помощью статического или динамического анализа, полагаясь на диспетчер для выполнения параллельного потока. Этот дизайн позволяет системе максимально использовать параллельность, не требуя полного понимания структуры базового состояния. Monad особенно примечателен, поскольку он сочетает оптимистичное управление параллелизмом (OCC), параллельное конвейерное планирование, выполнение вне порядка и другие современные технологии баз данных, позволяя исполнению цепи стать ближе к парадигме "диспетчера GPU". На практике этот механизм требует чрезвычайно сложного менеджера зависимостей и детектора конфликтов, сам диспетчер также может стать узким местом, но его потенциальная пропускная способность значительно превышает модели учетных записей или объектов, что делает его одной из самых мощных сил с теоретическим потолком в текущей области параллельных вычислений.

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