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

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

С момента своего появления блокчейн-системы сталкиваются с основной проблемой масштабируемости. Количество транзакций в секунду у Биткойна и Эфириума (TPS) очень низкое и далеко от традиционных Web2 систем. Это не простая задача, которую можно решить просто увеличив количество серверов, а системное ограничение в базовом проектировании блокчейна, то есть “декцентрализация, безопасность, масштабируемость” – триада трудностей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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