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

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

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

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

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

Солана, Суй, Аптос и другие новые цепочки первыми внедрили параллельность на уровне архитектуры. В то время как проекты, такие как Монада и МегаЭФ, далее продвигают параллельность внутри цепочки к механическим прорывам, таким как конвейерное выполнение, оптимистическая конкурентность и асинхронное управление сообщениями, что все больше приближает их к характеристикам современных операционных систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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