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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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