Web3 Параллельные вычисления Глубина Исследовательский отчет: Коренное расширение как конечный путь
Введение: Расширение — это вечная тема, параллельность — конечное поле битвы
С момента своего появления блокчейн-системы сталкиваются с основной проблемой масштабируемости. Производительность биткойна и эфира далека от традиционных систем Web2. Это не простое решение, заключающееся в добавлении серверов, а результат системных ограничений в базовом дизайне блокчейна - "тройной конфликт" между "децентрализацией, безопасностью и масштабируемостью."
За последние десять лет мы стали свидетелями множества попыток масштабирования, от споров о масштабировании биткойна до шардирования эфириума, от канала состояния до Rollup и модульных блокчейнов. Rollup, как текущая основная схема масштабирования, хотя и обеспечил значительное увеличение TPS, всё же не достиг истинного предела "однопоточной производительности" блокчейна на уровне его основ, особенно в области исполнения, которая по-прежнему ограничена последовательными вычислениями внутри цепочки.
Параллельные вычисления в цепочке становятся все более важной темой в отрасли. Они пытаются полностью перестроить исполняющий движок, сохраняя атомарность одноцепочечной обработки, переходя от "последовательного выполнения транзакций" к высокопроизводительной системе "многопоточности + конвейерной обработки + управления зависимостями". Это может не только привести к увеличению пропускной способности в сотни раз, но и стать ключевой основой для взрыва применения смарт-контрактов.
Параллельные вычисления ставят под сомнение основную модель выполнения смарт-контрактов, переопределяя базовую логику упаковки транзакций, доступа к состояниям, отношений вызова и организации хранения. Его цель не только повысить пропускную способность, но и обеспечить действительно устойчивую инфраструктурную поддержку для будущих нативных приложений Web3.
После того как в области Rollup конкуренция стала однородной, параллельность в цепочке становится решающим фактором в новом цикле конкуренции Layer1. Это не только технологическая гонка, но и борьба за парадигму. Следующая генерация суверенных платформ исполнения в мире Web3, вероятно, родится из этой борьбы за параллельность в цепочке.
Панорама парадигмы расширения: пять типов маршрутов, каждый со своим акцентом
Масштабирование, являющееся одной из самых важных, самых длительных и самых сложных тем в эволюции технологий публичных цепочек, стало причиной появления и эволюции почти всех основных технологических путей за последние десять лет. Начиная с конфликта о размере блока биткойна, эта техническая гонка о том, "как заставить цепочку работать быстрее", в конечном итоге разделилась на пять основных направлений, каждое из которых подходит к узким местам с разных углов, имеет свою технологическую философию, сложность реализации, модель рисков и области применения.
Первый тип маршрута — это самое прямое расширение цепочки, представляющее собой такие методы, как увеличение размера блока, сокращение времени создания блока или повышение производительности за счет оптимизации структуры данных и механизма консенсуса. Этот способ сохраняет простоту согласованности одноцепочечной цепи, легко понимается и внедряется, но также легко сталкивается с централизованными рисками, ростом затрат на работу узлов, увеличением сложности синхронизации и другими системными ограничениями, поэтому в сегодняшнем дизайне он больше не является основным решением, а скорее стал вспомогательным дополнением к другим механизмам.
Второй тип маршрута - это масштабирование вне цепи, его представляют каналы состояния и побочные цепи. Основная идея этого пути заключается в том, чтобы перенести большую часть торговой активности за пределы цепи, записывая только конечный результат в главную цепь, где главная цепь выступает в качестве финального уровня расчета. Хотя эта идея теоретически может бесконечно расширять пропускную способность, проблемы с моделью доверия к транзакциям вне цепи, безопасностью средств и сложностью взаимодействия ограничивают ее применение.
Третий тип маршрута — это наиболее популярный и широко развернутый маршрут Layer2 Rollup. Этот метод реализует масштабирование через механизм выполнения вне цепочки и проверки на цепочке. Optimistic Rollup и ZK Rollup имеют свои преимущества: первый обеспечивает быструю работу и высокую совместимость, но сталкивается с проблемами задержки в периоде вызова и механизмом доказательства мошенничества; второй обладает высокой безопасностью и хорошими возможностями сжатия данных, но разработка сложна и недостаточно совместима с EVM.
Четвертый тип маршрута - это модульная архитектура блокчейна, возникшая в последние годы, такие как Celestia, Avail, EigenLayer и другие. Это направление предполагает полное разъединение основных функций блокчейна - исполнения, консенсуса, доступности данных, расчета - с выполнением различных функций несколькими специализированными цепями, которые затем объединяются в масштабируемую сеть с помощью кросс-цепочных протоколов.
Последний тип маршрута - это оптимизированный путь параллельных вычислений внутри цепи. В отличие от первых четырех типов, которые в основном сосредоточены на "горизонтальном разделении" с структурной точки зрения, параллельные вычисления акцентируют внимание на "вертикальном обновлении", то есть на одновременной обработке атомарных транзакций внутри одной цепи путем изменения архитектуры исполнительного движка. Solana - один из первых проектов, который реализовал концепцию параллельной виртуальной машины на уровне цепи. Новое поколение проектов, таких как Monad, Sei, Fuel, MegaETH и другие, еще дальше пытается внедрить передовые идеи, такие как конвейерное выполнение, оптимистическая конкуренция, разбиение хранилищ и параллельная декомпозиция, создавая высокопроизводительное ядро выполнения, подобное современным ЦП.
Классификация параллельных вычислений: пять основных путей от аккаунта до инструкции
В контексте постоянной эволюции технологий масштабирования блокчейна, параллельные вычисления постепенно становятся核心ным путем для достижения производительности. Исходя из модели исполнения, прослеживая развитие этой технологической линии, мы можем составить четкую классификацию параллельных вычислений, которая может быть условно разделена на пять технологических путей: параллельные вычисления на уровне аккаунтов, параллельные вычисления на уровне объектов, параллельные вычисления на уровне транзакций, параллельные вычисления на уровне виртуальных машин и параллельные вычисления на уровне инструкций. Эти пять категорий путей варьируются от грубой до тонкой степени детализации, представляя собой как непрерывный процесс уточнения параллельной логики, так и путь, по которому постоянно растет сложность систем и сложность планирования.
Самый ранний уровень параллелизма на уровне аккаунтов представлен парадигмой Solana. Эта модель основана на декомпозиции аккаунта и состояния, через статический анализ наборов аккаунтов, вовлеченных в транзакцию, для определения наличия конфликтных отношений. Если наборы аккаунтов, которые посещают две транзакции, не пересекаются, их можно выполнять параллельно на нескольких ядрах. Этот механизм очень подходит для обработки четко структурированных транзакций с ясными входами и выходами, особенно для программ с предсказуемыми путями, таких как DeFi. Однако его естественное предположение заключается в том, что доступ к аккаунтам можно предсказать, а зависимости состояния можно статически вывести, что приводит к проблемам с консервативным выполнением и снижением параллелизма при работе со сложными смарт-контрактами.
Основываясь на модели учетной записи, мы переходим на уровень технологий объектного параллелизма. Объектный параллелизм вводит семантическую абстракцию ресурсов и модулей, позволяя выполнять параллельное планирование на более тонком уровне "объектов состояния". Aptos и Sui являются важными исследователями в этом направлении, особенно последний, который через линейную типовую систему языка Move определяет права собственности и изменяемость ресурсов на этапе компиляции, позволяя точно контролировать конфликты доступа к ресурсам во время выполнения. Этот подход более универсален и масштабируем по сравнению с параллелизмом на уровне учетных записей, он может охватывать более сложную логику чтения и записи состояния и естественным образом обслуживает сцены с высокой гетерогенностью, такие как игры, социальные сети и ИИ.
Дальнейшая параллельность на уровне транзакций является направлением, исследуемым новым поколением высокопроизводительных цепей, таких как Monad, Sei и Fuel. Этот путь больше не рассматривает состояния или счета как минимальные параллельные единицы, а строит граф зависимостей вокруг самой транзакции. Транзакция рассматривается как атомарная операция, граф транзакций строится с помощью статического или динамического анализа, и для параллельного потока выполнения полагается на планировщик. Эта конструкция позволяет системе максимизировать параллельность, не требуя полного понимания структуры базового состояния. Monad особенно выделяется, так как сочетает оптимистичный контроль параллелизма, параллельное потоковое планирование, выполнение в произвольном порядке и другие современные технологии баз данных, что делает выполнение цепи ближе к парадигме "планировщика GPU".
А параллелизм на уровне виртуальных машин встраивает возможности конкурентного выполнения непосредственно в логику планирования инструкций на уровне VM, стремясь полностью преодолеть фиксированные ограничения последовательного выполнения EVM. MegaETH, как "супер виртуальный машинный эксперимент" внутри экосистемы Ethereum, пытается переработать EVM, чтобы она поддерживала многопоточную конкурентную реализацию кода смарт-контрактов. На нижнем уровне через механизмы сегментированного выполнения, изоляции состояния, асинхронных вызовов и т.д. каждый контракт может независимо работать в разных контекстах выполнения и с помощью параллельного синхронного уровня обеспечивать конечную согласованность.
Последний класс путей, а именно уровень инструкций с самой высокой степенью детализации и технологическими барьерами. Его идея исходит из современного проектирования ЦПУ, основанного на внеочередном исполнении и конвейерной обработке инструкций. Эта парадигма предполагает, что, поскольку каждый смарт-контракт в конечном итоге компилируется в байт-кодовые инструкции, вполне возможно, как и в случае с выполнением набора инструкций x86, проводить анализ планирования и параллельное переупорядочение для каждой операции. Команда Fuel уже на начальном этапе внедрила модель исполняемости с возможностью переупорядочивания инструкций в своем FuelVM, а в долгосрочной перспективе, как только движок выполнения блокчейна реализует предсказуемое исполнение зависимостей инструкций и динамическое переупорядочение, его параллелизм достигнет теоретического предела.
Глубокий анализ двух основных направлений: Monad против MegaETH
В эволюции параллельных вычислений по множеству путей, на текущем рынке наибольшее внимание и самый высокий интерес вызывают две главные технологические линии, которые без сомнения представлены "параллельной вычислительной цепочкой, построенной с нуля на основе Monad" и "внутренней революцией параллелизма EVM на основе MegaETH". Эти два направления не только являются наиболее активно развиваемыми направлениями исследований среди инженеров криптографических примитивов, но и символизируют наиболее определенные полюса в соревновании за производительность Web3.
Monad является истинным "приверженцем вычислительного фундаментализма", его философия дизайна не направлена на совместимость с существующим EVM, а черпает вдохновение из современных баз данных и высокопроизводительных многопроцессорных систем, чтобы переопределить основы работы исполняющего движка блокчейна. Его основная технологическая система основана на зрелых механизмах из области баз данных, таких как оптимистическое конкурентное управление, планирование транзакций DAG, неупорядоченное выполнение и пакетная обработка. Цель состоит в том, чтобы повысить производительность обработки транзакций цепочки до уровня миллиона TPS. В архитектуре Monad выполнение и сортировка транзакций полностью декомпозированы; система сначала строит граф зависимостей транзакций, а затем передает его планировщику для параллельного выполнения в потоке. Все транзакции рассматриваются как атомарные единицы транзакций, обладающие четкими наборами чтения и записи, а также снимками состояния. Планировщик выполняет оптимистическое выполнение на основе графа зависимостей и выполняет откат и повторное выполнение в случае возникновения конфликта.
Но более важно то, что Monad не отказался от совместимости с EVM. Он поддерживает разработчиков в написании контрактов с использованием синтаксиса Solidity через промежуточный уровень, аналогичный "Solidity-Compatible Intermediate Language", одновременно проводя оптимизацию промежуточного языка и параллельное планирование в исполняющем движке. Эта стратегия проектирования "поверхностная совместимость, глубокая переработка" позволяет сохранить дружелюбие к разработчикам экосистемы Ethereum и в то же время максимально реализовать потенциал низкоуровневого исполнения, что является типичной технической стратегией "проглотить EVM, а затем реконструировать его".
В отличие от позиции «строителей нового мира» Monad, MegaETH представляет собой совершенно противоположный тип проекта, который выбирает исходить из существующего мира Ethereum и добиваться значительного повышения эффективности выполнения с минимальными затратами на изменения. MegaETH не отвергает спецификацию EVM, а стремится внедрить возможности параллельных вычислений в существующий движок выполнения EVM, создавая будущее «многоядерного EVM». Его основной принцип заключается в полном переработке текущей модели выполнения инструкций EVM, что позволяет обеспечить изоляцию на уровне потоков, асинхронное выполнение на уровне контрактов, обнаружение конфликтов доступа к состоянию и другие возможности, позволяющие нескольким смарт-контрактам выполняться одновременно в одном блоке и в конечном итоге объединять изменения состояния. Эта модель требует от разработчиков отсутствия необходимости изменять существующие контракты Solidity, а также не требует использования новых языков или инструментальных цепочек; они могут добиться значительных преимуществ в производительности, просто развернув те же контракты на цепочке MegaETH.
Ключевым прорывом MegaETH является его механизм многопоточной обработки VM. Традиционный EVM использует стековую однопоточную модель выполнения, где каждая инструкция выполняется линейно, а обновление состояния должно происходить синхронно. MegaETH разрушает эту модель, вводя асинхронный стек вызовов и механизм изоляции контекста выполнения, тем самым обеспечивая одновременное выполнение "конкурирующих контекстов EVM". Каждый контракт может вызывать свою логику в независимом потоке, а все потоки при окончательной подаче состояния проходят проверку конфликтов и сходимость через параллельный синхронизирующий слой. Этот механизм очень похож на многопоточную модель JavaScript в современных браузерах, сохраняя определенность поведения основного потока и одновременно вводя высокопроизводительный механизм фоновой асинхронной обработки.
Более важно, что MegaETH выбирает глубокую привязку к экосистеме Ethereum, и его основное место назначения в будущем, вероятно, будет какой-либо сети EVM L2 Rollup, такой как Optimism, Base или
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
7 Лайков
Награда
7
5
Поделиться
комментарий
0/400
TokenDustCollector
· 22ч назад
Снова ловим тренды. Вы поняли, как работает сериализация?
Посмотреть ОригиналОтветить0
OfflineNewbie
· 22ч назад
Как же расширение становится все более замысловатым.
Посмотреть ОригиналОтветить0
SnapshotLaborer
· 22ч назад
Снова, снова и снова увеличиваем容量? Создание новых колёс никогда не остановится.
Посмотреть ОригиналОтветить0
GweiTooHigh
· 22ч назад
Слишком быстро прокручивается, даже L2 не успевает следить.
Исследование пяти основных путей параллельных вычислений в Web3: окончательное решение для родного масштабирования
Web3 Параллельные вычисления Глубина Исследовательский отчет: Коренное расширение как конечный путь
Введение: Расширение — это вечная тема, параллельность — конечное поле битвы
С момента своего появления блокчейн-системы сталкиваются с основной проблемой масштабируемости. Производительность биткойна и эфира далека от традиционных систем Web2. Это не простое решение, заключающееся в добавлении серверов, а результат системных ограничений в базовом дизайне блокчейна - "тройной конфликт" между "децентрализацией, безопасностью и масштабируемостью."
За последние десять лет мы стали свидетелями множества попыток масштабирования, от споров о масштабировании биткойна до шардирования эфириума, от канала состояния до Rollup и модульных блокчейнов. Rollup, как текущая основная схема масштабирования, хотя и обеспечил значительное увеличение TPS, всё же не достиг истинного предела "однопоточной производительности" блокчейна на уровне его основ, особенно в области исполнения, которая по-прежнему ограничена последовательными вычислениями внутри цепочки.
Параллельные вычисления в цепочке становятся все более важной темой в отрасли. Они пытаются полностью перестроить исполняющий движок, сохраняя атомарность одноцепочечной обработки, переходя от "последовательного выполнения транзакций" к высокопроизводительной системе "многопоточности + конвейерной обработки + управления зависимостями". Это может не только привести к увеличению пропускной способности в сотни раз, но и стать ключевой основой для взрыва применения смарт-контрактов.
Параллельные вычисления ставят под сомнение основную модель выполнения смарт-контрактов, переопределяя базовую логику упаковки транзакций, доступа к состояниям, отношений вызова и организации хранения. Его цель не только повысить пропускную способность, но и обеспечить действительно устойчивую инфраструктурную поддержку для будущих нативных приложений Web3.
После того как в области Rollup конкуренция стала однородной, параллельность в цепочке становится решающим фактором в новом цикле конкуренции Layer1. Это не только технологическая гонка, но и борьба за парадигму. Следующая генерация суверенных платформ исполнения в мире Web3, вероятно, родится из этой борьбы за параллельность в цепочке.
Панорама парадигмы расширения: пять типов маршрутов, каждый со своим акцентом
Масштабирование, являющееся одной из самых важных, самых длительных и самых сложных тем в эволюции технологий публичных цепочек, стало причиной появления и эволюции почти всех основных технологических путей за последние десять лет. Начиная с конфликта о размере блока биткойна, эта техническая гонка о том, "как заставить цепочку работать быстрее", в конечном итоге разделилась на пять основных направлений, каждое из которых подходит к узким местам с разных углов, имеет свою технологическую философию, сложность реализации, модель рисков и области применения.
Первый тип маршрута — это самое прямое расширение цепочки, представляющее собой такие методы, как увеличение размера блока, сокращение времени создания блока или повышение производительности за счет оптимизации структуры данных и механизма консенсуса. Этот способ сохраняет простоту согласованности одноцепочечной цепи, легко понимается и внедряется, но также легко сталкивается с централизованными рисками, ростом затрат на работу узлов, увеличением сложности синхронизации и другими системными ограничениями, поэтому в сегодняшнем дизайне он больше не является основным решением, а скорее стал вспомогательным дополнением к другим механизмам.
Второй тип маршрута - это масштабирование вне цепи, его представляют каналы состояния и побочные цепи. Основная идея этого пути заключается в том, чтобы перенести большую часть торговой активности за пределы цепи, записывая только конечный результат в главную цепь, где главная цепь выступает в качестве финального уровня расчета. Хотя эта идея теоретически может бесконечно расширять пропускную способность, проблемы с моделью доверия к транзакциям вне цепи, безопасностью средств и сложностью взаимодействия ограничивают ее применение.
Третий тип маршрута — это наиболее популярный и широко развернутый маршрут Layer2 Rollup. Этот метод реализует масштабирование через механизм выполнения вне цепочки и проверки на цепочке. Optimistic Rollup и ZK Rollup имеют свои преимущества: первый обеспечивает быструю работу и высокую совместимость, но сталкивается с проблемами задержки в периоде вызова и механизмом доказательства мошенничества; второй обладает высокой безопасностью и хорошими возможностями сжатия данных, но разработка сложна и недостаточно совместима с EVM.
Четвертый тип маршрута - это модульная архитектура блокчейна, возникшая в последние годы, такие как Celestia, Avail, EigenLayer и другие. Это направление предполагает полное разъединение основных функций блокчейна - исполнения, консенсуса, доступности данных, расчета - с выполнением различных функций несколькими специализированными цепями, которые затем объединяются в масштабируемую сеть с помощью кросс-цепочных протоколов.
Последний тип маршрута - это оптимизированный путь параллельных вычислений внутри цепи. В отличие от первых четырех типов, которые в основном сосредоточены на "горизонтальном разделении" с структурной точки зрения, параллельные вычисления акцентируют внимание на "вертикальном обновлении", то есть на одновременной обработке атомарных транзакций внутри одной цепи путем изменения архитектуры исполнительного движка. Solana - один из первых проектов, который реализовал концепцию параллельной виртуальной машины на уровне цепи. Новое поколение проектов, таких как Monad, Sei, Fuel, MegaETH и другие, еще дальше пытается внедрить передовые идеи, такие как конвейерное выполнение, оптимистическая конкуренция, разбиение хранилищ и параллельная декомпозиция, создавая высокопроизводительное ядро выполнения, подобное современным ЦП.
Классификация параллельных вычислений: пять основных путей от аккаунта до инструкции
В контексте постоянной эволюции технологий масштабирования блокчейна, параллельные вычисления постепенно становятся核心ным путем для достижения производительности. Исходя из модели исполнения, прослеживая развитие этой технологической линии, мы можем составить четкую классификацию параллельных вычислений, которая может быть условно разделена на пять технологических путей: параллельные вычисления на уровне аккаунтов, параллельные вычисления на уровне объектов, параллельные вычисления на уровне транзакций, параллельные вычисления на уровне виртуальных машин и параллельные вычисления на уровне инструкций. Эти пять категорий путей варьируются от грубой до тонкой степени детализации, представляя собой как непрерывный процесс уточнения параллельной логики, так и путь, по которому постоянно растет сложность систем и сложность планирования.
Самый ранний уровень параллелизма на уровне аккаунтов представлен парадигмой Solana. Эта модель основана на декомпозиции аккаунта и состояния, через статический анализ наборов аккаунтов, вовлеченных в транзакцию, для определения наличия конфликтных отношений. Если наборы аккаунтов, которые посещают две транзакции, не пересекаются, их можно выполнять параллельно на нескольких ядрах. Этот механизм очень подходит для обработки четко структурированных транзакций с ясными входами и выходами, особенно для программ с предсказуемыми путями, таких как DeFi. Однако его естественное предположение заключается в том, что доступ к аккаунтам можно предсказать, а зависимости состояния можно статически вывести, что приводит к проблемам с консервативным выполнением и снижением параллелизма при работе со сложными смарт-контрактами.
Основываясь на модели учетной записи, мы переходим на уровень технологий объектного параллелизма. Объектный параллелизм вводит семантическую абстракцию ресурсов и модулей, позволяя выполнять параллельное планирование на более тонком уровне "объектов состояния". Aptos и Sui являются важными исследователями в этом направлении, особенно последний, который через линейную типовую систему языка Move определяет права собственности и изменяемость ресурсов на этапе компиляции, позволяя точно контролировать конфликты доступа к ресурсам во время выполнения. Этот подход более универсален и масштабируем по сравнению с параллелизмом на уровне учетных записей, он может охватывать более сложную логику чтения и записи состояния и естественным образом обслуживает сцены с высокой гетерогенностью, такие как игры, социальные сети и ИИ.
Дальнейшая параллельность на уровне транзакций является направлением, исследуемым новым поколением высокопроизводительных цепей, таких как Monad, Sei и Fuel. Этот путь больше не рассматривает состояния или счета как минимальные параллельные единицы, а строит граф зависимостей вокруг самой транзакции. Транзакция рассматривается как атомарная операция, граф транзакций строится с помощью статического или динамического анализа, и для параллельного потока выполнения полагается на планировщик. Эта конструкция позволяет системе максимизировать параллельность, не требуя полного понимания структуры базового состояния. Monad особенно выделяется, так как сочетает оптимистичный контроль параллелизма, параллельное потоковое планирование, выполнение в произвольном порядке и другие современные технологии баз данных, что делает выполнение цепи ближе к парадигме "планировщика GPU".
А параллелизм на уровне виртуальных машин встраивает возможности конкурентного выполнения непосредственно в логику планирования инструкций на уровне VM, стремясь полностью преодолеть фиксированные ограничения последовательного выполнения EVM. MegaETH, как "супер виртуальный машинный эксперимент" внутри экосистемы Ethereum, пытается переработать EVM, чтобы она поддерживала многопоточную конкурентную реализацию кода смарт-контрактов. На нижнем уровне через механизмы сегментированного выполнения, изоляции состояния, асинхронных вызовов и т.д. каждый контракт может независимо работать в разных контекстах выполнения и с помощью параллельного синхронного уровня обеспечивать конечную согласованность.
Последний класс путей, а именно уровень инструкций с самой высокой степенью детализации и технологическими барьерами. Его идея исходит из современного проектирования ЦПУ, основанного на внеочередном исполнении и конвейерной обработке инструкций. Эта парадигма предполагает, что, поскольку каждый смарт-контракт в конечном итоге компилируется в байт-кодовые инструкции, вполне возможно, как и в случае с выполнением набора инструкций x86, проводить анализ планирования и параллельное переупорядочение для каждой операции. Команда Fuel уже на начальном этапе внедрила модель исполняемости с возможностью переупорядочивания инструкций в своем FuelVM, а в долгосрочной перспективе, как только движок выполнения блокчейна реализует предсказуемое исполнение зависимостей инструкций и динамическое переупорядочение, его параллелизм достигнет теоретического предела.
Глубокий анализ двух основных направлений: Monad против MegaETH
В эволюции параллельных вычислений по множеству путей, на текущем рынке наибольшее внимание и самый высокий интерес вызывают две главные технологические линии, которые без сомнения представлены "параллельной вычислительной цепочкой, построенной с нуля на основе Monad" и "внутренней революцией параллелизма EVM на основе MegaETH". Эти два направления не только являются наиболее активно развиваемыми направлениями исследований среди инженеров криптографических примитивов, но и символизируют наиболее определенные полюса в соревновании за производительность Web3.
Monad является истинным "приверженцем вычислительного фундаментализма", его философия дизайна не направлена на совместимость с существующим EVM, а черпает вдохновение из современных баз данных и высокопроизводительных многопроцессорных систем, чтобы переопределить основы работы исполняющего движка блокчейна. Его основная технологическая система основана на зрелых механизмах из области баз данных, таких как оптимистическое конкурентное управление, планирование транзакций DAG, неупорядоченное выполнение и пакетная обработка. Цель состоит в том, чтобы повысить производительность обработки транзакций цепочки до уровня миллиона TPS. В архитектуре Monad выполнение и сортировка транзакций полностью декомпозированы; система сначала строит граф зависимостей транзакций, а затем передает его планировщику для параллельного выполнения в потоке. Все транзакции рассматриваются как атомарные единицы транзакций, обладающие четкими наборами чтения и записи, а также снимками состояния. Планировщик выполняет оптимистическое выполнение на основе графа зависимостей и выполняет откат и повторное выполнение в случае возникновения конфликта.
Но более важно то, что Monad не отказался от совместимости с EVM. Он поддерживает разработчиков в написании контрактов с использованием синтаксиса Solidity через промежуточный уровень, аналогичный "Solidity-Compatible Intermediate Language", одновременно проводя оптимизацию промежуточного языка и параллельное планирование в исполняющем движке. Эта стратегия проектирования "поверхностная совместимость, глубокая переработка" позволяет сохранить дружелюбие к разработчикам экосистемы Ethereum и в то же время максимально реализовать потенциал низкоуровневого исполнения, что является типичной технической стратегией "проглотить EVM, а затем реконструировать его".
В отличие от позиции «строителей нового мира» Monad, MegaETH представляет собой совершенно противоположный тип проекта, который выбирает исходить из существующего мира Ethereum и добиваться значительного повышения эффективности выполнения с минимальными затратами на изменения. MegaETH не отвергает спецификацию EVM, а стремится внедрить возможности параллельных вычислений в существующий движок выполнения EVM, создавая будущее «многоядерного EVM». Его основной принцип заключается в полном переработке текущей модели выполнения инструкций EVM, что позволяет обеспечить изоляцию на уровне потоков, асинхронное выполнение на уровне контрактов, обнаружение конфликтов доступа к состоянию и другие возможности, позволяющие нескольким смарт-контрактам выполняться одновременно в одном блоке и в конечном итоге объединять изменения состояния. Эта модель требует от разработчиков отсутствия необходимости изменять существующие контракты Solidity, а также не требует использования новых языков или инструментальных цепочек; они могут добиться значительных преимуществ в производительности, просто развернув те же контракты на цепочке MegaETH.
Ключевым прорывом MegaETH является его механизм многопоточной обработки VM. Традиционный EVM использует стековую однопоточную модель выполнения, где каждая инструкция выполняется линейно, а обновление состояния должно происходить синхронно. MegaETH разрушает эту модель, вводя асинхронный стек вызовов и механизм изоляции контекста выполнения, тем самым обеспечивая одновременное выполнение "конкурирующих контекстов EVM". Каждый контракт может вызывать свою логику в независимом потоке, а все потоки при окончательной подаче состояния проходят проверку конфликтов и сходимость через параллельный синхронизирующий слой. Этот механизм очень похож на многопоточную модель JavaScript в современных браузерах, сохраняя определенность поведения основного потока и одновременно вводя высокопроизводительный механизм фоновой асинхронной обработки.
Более важно, что MegaETH выбирает глубокую привязку к экосистеме Ethereum, и его основное место назначения в будущем, вероятно, будет какой-либо сети EVM L2 Rollup, такой как Optimism, Base или