Отчет о глубоких исследованиях параллельных вычислений Web3: крайний путь нативного масштабирования
Один. Введение: Масштабирование — это вечная тема, параллельность — это конечное поле битвы
Блокчейн-системы с момента своего возникновения сталкиваются с ключевой проблемой масштабируемости. Производственные ограничения Bitcoin и Ethereum трудно преодолеть, что резко контрастирует с традиционным миром Web2. Это не простая задача увеличения числа серверов, а системное ограничение в базовом проектировании блокчейна.
За последние десять лет мы стали свидетелями бесчисленных попыток масштабирования. От споров о масштабировании биткойна до видения шардирования эфириума, от каналов состояния, Plasma до Rollup и модульных блокчейнов, от Layer 2 до реконструкции доступности данных, индустрия прошла путь, полный инноваций в масштабировании. Rollup, как текущее основное решение для масштабирования, значительно увеличивает TPS, одновременно уменьшая нагрузку на основную цепочку и сохраняя безопасность. Однако он не затрагивает истинные пределы "одиночной цепной производительности" на уровне блокчейна, особенно в части исполнения, которое по-прежнему ограничивается традиционной моделью последовательных вычислений внутри цепи.
Внутренние параллельные вычисления постепенно становятся новой точкой фокуса. В отличие от других решений по масштабированию, оно пытается полностью реконструировать движок выполнения, сохраняя при этом структуру единой цепочки. Опираясь на современные операционные системы и идеи проектирования ЦП, блокчейн модернизируется с "однопоточной" модели до "многопоточной + конвейерной + зависимой планировки" высокопроизводительной системы. Это не только может привести к сотням раз увеличению пропускной способности, но и стать ключевым фактором для взрывного роста сложных приложений смарт-контрактов.
На самом деле, однопоточные вычисления в мире Web2 уже устарели, их место заняли параллельное программирование, асинхронное планирование и другие оптимизационные модели. Блокчейн, как более консервативная вычислительная система, по-прежнему не смог в полной мере воспользоваться этими параллельными идеями. Это и ограничение, и возможность. Новые публичные блокчейны, такие как Solana, Sui, Aptos, вводят параллелизм на уровне архитектуры, открывая это исследование; в то время как проекты, такие как Monad и MegaETH, далее пробиваются к механикам конвейерного выполнения, оптимистической параллельности и т.д., демонстрируя все более близкие к современным операционным системам характеристики.
Параллельные вычисления — это не только оптимизация производительности, но и парадигмальный сдвиг в модели выполнения блокчейна. Они ставят под сомнение основную модель выполнения смарт-контрактов, переопределяя базовую логику обработки транзакций. Если Rollup — это "перенос транзакций за пределы цепи", то параллельные вычисления внутри цепи — это "создание ядра суперкомпьютера на цепи", целью которого является предоставление действительно устойчивой инфраструктуры для будущих нативных приложений Web3.
После того как в сфере Rollup произошла конвергенция, параллельность внутри цепи становится решающим фактором нового раунда конкуренции Layer1. Производительность больше не является просто скоростью, а тем, может ли она поддерживать гетерогенный мир приложений. Это не только технологическая гонка, но и борьба парадигм. Следующее поколение суверенной исполняющей платформы Web3, вероятно, появится из этой борьбы за параллельность внутри цепи.
Два, Панорама парадигмы масштабирования: пять категорий маршрутов, каждая с акцентом
Масштабирование, как одна из самых важных, самых устойчивых и самых сложных тем в эволюции технологий публичных цепей, стало причиной появления и эволюции почти всех основных технологических путей за последние десять лет. Начиная с спора о размере блока биткойна, эта техническая гонка о "том, как заставить цепь работать быстрее" в конечном итоге разделилась на пять основных направлений, каждое из которых по-разному подходит к узким местам, имея свою собственную технологическую философию, сложность внедрения, модели рисков и подходящие сценарии использования.
Первый тип маршрута — это самое прямое расширение цепочки, к которому относятся такие меры, как увеличение размера блока, сокращение времени создания блока или повышение производительности за счет оптимизации структуры данных и механизмов консенсуса. Этот подход стал центром внимания в争论 о расширении Bitcoin, породив форки "больших блоков", такие как BCH и BSV, а также повлиял на проектирование ранних высокопроизводительных публичных цепей, таких как EOS и NEO. Преимущества этого типа маршрута заключаются в том, что он сохраняет простоту согласованности отдельной цепи, что делает его легким для понимания и внедрения, но также он очень подвержен рискам централизации, увеличению затрат на запуск узлов и повышению сложности синхронизации, что создает системные ограничения. Поэтому он больше не является основным решением в сегодняшнем проектировании, а скорее стал вспомогательным элементом для других механизмов.
Второй тип маршрута — это оффлейн масштабирование, его представителями являются каналы состояния и сайдчейны. Основная идея этого пути заключается в том, чтобы переместить большую часть торговой активности в оффлейн, записывая только конечный результат в основную цепь, а основная цепь выполняет роль окончательного уровня расчета. С точки зрения технической философии, это приближается к концепции асинхронной архитектуры Web2. Хотя эта идея теоретически может бесконечно расширять пропускную способность, проблемы, такие как модель доверия к оффлейн-транзакциям, безопасность средств и сложность взаимодействия, ограничивают ее применение. Ярким примером является Lightning Network, которая имеет четкое финансовое позиционирование, но экосистема так и не смогла разразиться; в то время как несколько дизайнов, основанных на сайдчейнах, таких как Polygon POS, при высокой пропускной способности также выявляют недостатки в наследовании безопасности основной цепи.
Третий тип маршрута — это наиболее популярный и широко внедренный маршрут Layer2 Rollup. Этот подход не меняет саму основную цепочку, а реализует масштабирование с помощью механизма выполнения вне цепочки и проверки внутри цепочки. Optimistic Rollup и ZK Rollup имеют свои преимущества: первый обеспечивает быструю реализацию и высокую совместимость, но сталкивается с проблемами задержки в периоде вызова и механизма доказательства мошенничества; второй обладает высокой безопасностью и хорошей способностью к сжатию данных, но его разработка сложна и не хватает совместимости с EVM. Независимо от того, какой тип Rollup используется, его суть заключается в том, чтобы аутсорсить права на выполнение, одновременно сохраняя данные и проверки на основной цепочке, что позволяет достичь относительного баланса между децентрализацией и высокой производительностью. Быстрый рост таких проектов, как Arbitrum, Optimism, zkSync, StarkNet, доказал жизнеспособность этого пути, но также выявил среднесрочные узкие места, такие как чрезмерная зависимость от доступности данных (DA), все еще высокие расходы и разрозненный опыт разработки.
Четвертый тип маршрута – это модульная архитектура блокчейна, которая возникла в последние годы и представлена такими проектами, как Celestia, Avail, EigenLayer и др. Модульная парадигма предполагает разделение основных функций блокчейна, которые выполняются несколькими специализированными цепочками, а затем объединяются в расширяемую сеть с помощью межцепочечных протоколов. Это направление сильно повлияно модульной архитектурой операционных систем и концепцией компоновки облачных вычислений. Его преимущество заключается в возможности гибкой замены компонентов системы и значительном увеличении эффективности на определенных этапах (например, DA). Однако его вызовы также весьма очевидны: после декомпозиции модулей стоимость синхронизации, верификации и взаимного доверия между системами становится чрезвычайно высокой, экосистема разработчиков крайне разрозненная, а требования к стандартам протоколов на средне- и долгосрочную перспективу и безопасности межцепочечных взаимодействий значительно выше, чем в традиционном дизайне цепочек. Эта модель по сути больше не строит "цепь", а создает "цепную сеть", что ставит перед пониманием общей архитектуры и операционным обслуживанием беспрецедентные барьеры.
Последний тип маршрута — это оптимизация параллельных вычислений внутри цепи. В отличие от первых четырех типов, которые в основном сосредоточены на "горизонтальном разбиении" с точки зрения структуры, параллельные вычисления акцентируют внимание на "вертикальном обновлении", то есть внутри одной цепи за счет изменения архитектуры исполняющего движка достигается конкурентная обработка атомарных транзакций. Это требует переписывания логики планирования виртуальной машины (VM), введения анализа зависимостей транзакций, предсказания конфликтов состояния, контроля параллелизма, асинхронных вызовов и целого ряда современных механизмов планирования компьютерных систем. Solana — один из первых проектов, реализовавших концепцию параллельной VM на уровне цепи, который достигает многопоточного параллельного выполнения за счет определения конфликтов транзакций на основе модели аккаунтов. Новое поколение проектов, таких как 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.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
4
Репост
Поделиться
комментарий
0/400
screenshot_gains
· 14ч назад
Блокчейн не просто цепочка? Почему всё так сложно?
Посмотреть ОригиналОтветить0
LiquidityNinja
· 14ч назад
Что делать, L2 не спасает от узких мест в производительности. Продолжать бороться?
Посмотреть ОригиналОтветить0
ser_we_are_ngmi
· 14ч назад
Все еще изучают расширение, эй, кажется, этот путь слишком дальний.
Посмотреть ОригиналОтветить0
GasDevourer
· 14ч назад
Газ хочет съесть людей～Копите деньги, мечтая о подключении к цепочке～
Исследование параллельных вычислений в Web3: будущее расширения внутри цепи
Отчет о глубоких исследованиях параллельных вычислений Web3: крайний путь нативного масштабирования
Один. Введение: Масштабирование — это вечная тема, параллельность — это конечное поле битвы
Блокчейн-системы с момента своего возникновения сталкиваются с ключевой проблемой масштабируемости. Производственные ограничения Bitcoin и Ethereum трудно преодолеть, что резко контрастирует с традиционным миром Web2. Это не простая задача увеличения числа серверов, а системное ограничение в базовом проектировании блокчейна.
За последние десять лет мы стали свидетелями бесчисленных попыток масштабирования. От споров о масштабировании биткойна до видения шардирования эфириума, от каналов состояния, Plasma до Rollup и модульных блокчейнов, от Layer 2 до реконструкции доступности данных, индустрия прошла путь, полный инноваций в масштабировании. Rollup, как текущее основное решение для масштабирования, значительно увеличивает TPS, одновременно уменьшая нагрузку на основную цепочку и сохраняя безопасность. Однако он не затрагивает истинные пределы "одиночной цепной производительности" на уровне блокчейна, особенно в части исполнения, которое по-прежнему ограничивается традиционной моделью последовательных вычислений внутри цепи.
Внутренние параллельные вычисления постепенно становятся новой точкой фокуса. В отличие от других решений по масштабированию, оно пытается полностью реконструировать движок выполнения, сохраняя при этом структуру единой цепочки. Опираясь на современные операционные системы и идеи проектирования ЦП, блокчейн модернизируется с "однопоточной" модели до "многопоточной + конвейерной + зависимой планировки" высокопроизводительной системы. Это не только может привести к сотням раз увеличению пропускной способности, но и стать ключевым фактором для взрывного роста сложных приложений смарт-контрактов.
На самом деле, однопоточные вычисления в мире Web2 уже устарели, их место заняли параллельное программирование, асинхронное планирование и другие оптимизационные модели. Блокчейн, как более консервативная вычислительная система, по-прежнему не смог в полной мере воспользоваться этими параллельными идеями. Это и ограничение, и возможность. Новые публичные блокчейны, такие как Solana, Sui, Aptos, вводят параллелизм на уровне архитектуры, открывая это исследование; в то время как проекты, такие как Monad и MegaETH, далее пробиваются к механикам конвейерного выполнения, оптимистической параллельности и т.д., демонстрируя все более близкие к современным операционным системам характеристики.
Параллельные вычисления — это не только оптимизация производительности, но и парадигмальный сдвиг в модели выполнения блокчейна. Они ставят под сомнение основную модель выполнения смарт-контрактов, переопределяя базовую логику обработки транзакций. Если Rollup — это "перенос транзакций за пределы цепи", то параллельные вычисления внутри цепи — это "создание ядра суперкомпьютера на цепи", целью которого является предоставление действительно устойчивой инфраструктуры для будущих нативных приложений Web3.
После того как в сфере Rollup произошла конвергенция, параллельность внутри цепи становится решающим фактором нового раунда конкуренции Layer1. Производительность больше не является просто скоростью, а тем, может ли она поддерживать гетерогенный мир приложений. Это не только технологическая гонка, но и борьба парадигм. Следующее поколение суверенной исполняющей платформы Web3, вероятно, появится из этой борьбы за параллельность внутри цепи.
Два, Панорама парадигмы масштабирования: пять категорий маршрутов, каждая с акцентом
Масштабирование, как одна из самых важных, самых устойчивых и самых сложных тем в эволюции технологий публичных цепей, стало причиной появления и эволюции почти всех основных технологических путей за последние десять лет. Начиная с спора о размере блока биткойна, эта техническая гонка о "том, как заставить цепь работать быстрее" в конечном итоге разделилась на пять основных направлений, каждое из которых по-разному подходит к узким местам, имея свою собственную технологическую философию, сложность внедрения, модели рисков и подходящие сценарии использования.
Первый тип маршрута — это самое прямое расширение цепочки, к которому относятся такие меры, как увеличение размера блока, сокращение времени создания блока или повышение производительности за счет оптимизации структуры данных и механизмов консенсуса. Этот подход стал центром внимания в争论 о расширении Bitcoin, породив форки "больших блоков", такие как BCH и BSV, а также повлиял на проектирование ранних высокопроизводительных публичных цепей, таких как EOS и NEO. Преимущества этого типа маршрута заключаются в том, что он сохраняет простоту согласованности отдельной цепи, что делает его легким для понимания и внедрения, но также он очень подвержен рискам централизации, увеличению затрат на запуск узлов и повышению сложности синхронизации, что создает системные ограничения. Поэтому он больше не является основным решением в сегодняшнем проектировании, а скорее стал вспомогательным элементом для других механизмов.
Второй тип маршрута — это оффлейн масштабирование, его представителями являются каналы состояния и сайдчейны. Основная идея этого пути заключается в том, чтобы переместить большую часть торговой активности в оффлейн, записывая только конечный результат в основную цепь, а основная цепь выполняет роль окончательного уровня расчета. С точки зрения технической философии, это приближается к концепции асинхронной архитектуры Web2. Хотя эта идея теоретически может бесконечно расширять пропускную способность, проблемы, такие как модель доверия к оффлейн-транзакциям, безопасность средств и сложность взаимодействия, ограничивают ее применение. Ярким примером является Lightning Network, которая имеет четкое финансовое позиционирование, но экосистема так и не смогла разразиться; в то время как несколько дизайнов, основанных на сайдчейнах, таких как Polygon POS, при высокой пропускной способности также выявляют недостатки в наследовании безопасности основной цепи.
Третий тип маршрута — это наиболее популярный и широко внедренный маршрут Layer2 Rollup. Этот подход не меняет саму основную цепочку, а реализует масштабирование с помощью механизма выполнения вне цепочки и проверки внутри цепочки. Optimistic Rollup и ZK Rollup имеют свои преимущества: первый обеспечивает быструю реализацию и высокую совместимость, но сталкивается с проблемами задержки в периоде вызова и механизма доказательства мошенничества; второй обладает высокой безопасностью и хорошей способностью к сжатию данных, но его разработка сложна и не хватает совместимости с EVM. Независимо от того, какой тип Rollup используется, его суть заключается в том, чтобы аутсорсить права на выполнение, одновременно сохраняя данные и проверки на основной цепочке, что позволяет достичь относительного баланса между децентрализацией и высокой производительностью. Быстрый рост таких проектов, как Arbitrum, Optimism, zkSync, StarkNet, доказал жизнеспособность этого пути, но также выявил среднесрочные узкие места, такие как чрезмерная зависимость от доступности данных (DA), все еще высокие расходы и разрозненный опыт разработки.
Четвертый тип маршрута – это модульная архитектура блокчейна, которая возникла в последние годы и представлена такими проектами, как Celestia, Avail, EigenLayer и др. Модульная парадигма предполагает разделение основных функций блокчейна, которые выполняются несколькими специализированными цепочками, а затем объединяются в расширяемую сеть с помощью межцепочечных протоколов. Это направление сильно повлияно модульной архитектурой операционных систем и концепцией компоновки облачных вычислений. Его преимущество заключается в возможности гибкой замены компонентов системы и значительном увеличении эффективности на определенных этапах (например, DA). Однако его вызовы также весьма очевидны: после декомпозиции модулей стоимость синхронизации, верификации и взаимного доверия между системами становится чрезвычайно высокой, экосистема разработчиков крайне разрозненная, а требования к стандартам протоколов на средне- и долгосрочную перспективу и безопасности межцепочечных взаимодействий значительно выше, чем в традиционном дизайне цепочек. Эта модель по сути больше не строит "цепь", а создает "цепную сеть", что ставит перед пониманием общей архитектуры и операционным обслуживанием беспрецедентные барьеры.
Последний тип маршрута — это оптимизация параллельных вычислений внутри цепи. В отличие от первых четырех типов, которые в основном сосредоточены на "горизонтальном разбиении" с точки зрения структуры, параллельные вычисления акцентируют внимание на "вертикальном обновлении", то есть внутри одной цепи за счет изменения архитектуры исполняющего движка достигается конкурентная обработка атомарных транзакций. Это требует переписывания логики планирования виртуальной машины (VM), введения анализа зависимостей транзакций, предсказания конфликтов состояния, контроля параллелизма, асинхронных вызовов и целого ряда современных механизмов планирования компьютерных систем. Solana — один из первых проектов, реализовавших концепцию параллельной VM на уровне цепи, который достигает многопоточного параллельного выполнения за счет определения конфликтов транзакций на основе модели аккаунтов. Новое поколение проектов, таких как 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.