Звіт про глибоке дослідження паралельних обчислень Web3: остаточний шлях рідної масштабованості

I. Вступ: Розширення є вічною темою, паралельність є остаточним полем бою

З моменту виникнення біткоїна, система блокчейну завжди стикалася з невідворотним основним питанням: масштабування. Біткоїн обробляє менше ніж 10 транзакцій на секунду, а ефір також важко подолати продуктивний бар'єр у кілька десятків TPS (транзакцій на секунду), що в порівнянні з традиційним світом Web2, де показники сягали тисяч TPS, виглядає особливо громіздко. Що ще важливіше, це не просто проблема «додавання серверів», а системне обмеження, глибоко закладене в основному консенсусі та структурному дизайні блокчейну — тобто неможливість одночасного досягнення «децентралізації, безпеки та масштабованості» у формі блокчейн-трикутника.

За останнє десятиліття ми спостерігали незліченну кількість спроб розширення, які то зростали, то падали. Від війни за масштабування Bitcoin до бачення шардингу Ethereum, від каналів станів і плазми до роллапів і модульних блокчейнів, від офчейн-виконання на рівні 2 до структурного рефакторингу доступності даних, вся індустрія стала на шлях масштабування, повного інженерної уяви. Як найбільш широко прийнята парадигма масштабування, Rollup досягла мети значного збільшення TPS при одночасному зниженні навантаження на виконання основного ланцюга та збереженні безпеки Ethereum. Але це не торкається реальних меж базової «одноланцюгової продуктивності» блокчейну, особливо на рівні виконання – тобто пропускної здатності самого блоку – яка все ще обмежена стародавньою парадигмою обробки послідовних обчислень у ланцюжку.

Через це внутрішньоланцюгові паралельні обчислення поступово увійшли в поле зору галузі. На відміну від офчейн-масштабування та крос-чейн розподілу, внутрішньоланцюговий паралелізм намагається повністю реконструювати двигун виконання, зберігаючи атомарність та інтегровану структуру одного ланцюга, і оновлює блокчейн з однопотокового режиму «послідовного виконання однієї транзакції за однією» до високопаралелісної обчислювальної системи «багатопоточність + конвеєр + планування залежностей» під керівництвом сучасної операційної системи та дизайну процесора. Такий шлях може не тільки досягти стократного збільшення пропускної здатності, але і стати ключовою передумовою для вибуху додатків смарт-контрактів.

Фактично, у парадигмі обчислень Web2 однопотокові обчислення вже давно витіснені сучасними апаратними архітектурами, і замінені нескінченним потоком оптимізаційних моделей, таких як паралельне програмування, асинхронне планування, пули потоків та мікросервіси. Блокчейн, як більш примітивна і консервативна обчислювальна система з надзвичайно високими вимогами до достовірності і перевірюваності, ніколи не зміг повною мірою використовувати ці ідеї паралельних обчислень. Це і обмеження, і можливість. Нові мережі, такі як Solana, Sui та Aptos, першими починають це дослідження, впроваджуючи паралелізм на архітектурному рівні. Нові проекти, такі як Monad і MegaETH, ще більше підвищили паралелізм в ланцюжку до проривів у глибоких механізмах, таких як виконання конвеєра, оптимістичний паралелізм і асинхронне управління повідомленнями, демонструючи характеристики, які стають все ближче і ближче до сучасних операційних систем.

Можна сказати, що паралельні обчислення – це не тільки «метод оптимізації продуктивності», а й поворотний момент у парадигмі моделі виконання блокчейну. Він кидає виклик фундаментальним моделям виконання смарт-контрактів і перевизначає базову логіку упаковки транзакцій, доступу до стану, відносин дзвінків і макета сховища. Якщо rollup — це «переміщення транзакцій на офчейн-виконання», то паралелізм у ланцюжку — це «створення суперкомп'ютерних ядер у ланцюжку», і його мета — не просто покращити пропускну здатність, а забезпечити справді стійку підтримку інфраструктури для майбутніх нативних додатків Web3 (високочастотна торгівля, ігрові двигуни, виконання моделей штучного інтелекту, соціальні мережі в ланцюжку тощо).

Після того, як на арені Rollup поступово стало однаковим, паралельність на ланцюгу тихо стає вирішальним змінним фактором у конкуренції Layer1 нового циклу. Продуктивність більше не є лише "швидше", а це можливість підтримувати цілий гетерогенний світ застосувань. Це не лише технічні змагання, а й боротьба за парадигми. Наступне покоління суверенних платформ для виконання в світі Web3, ймовірно, виникне саме з цієї боротьби за паралельність на ланцюгу.

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

Розширення потужностей, як одна з найважливіших, стійких і складних тем в еволюції технології публічних ланцюгів, породило появу та еволюцію майже всіх основних технологічних шляхів за останнє десятиліття. Почавши з битви за розмір блоку Bitcoin, це технічне змагання на тему «як змусити ланцюг працювати швидше» нарешті розділилося на п'ять основних маршрутів, кожен з яких врізається в вузьке місце під різним кутом, зі своєю технічною філософією, складністю посадки, моделлю ризику і застосовними сценаріями.

! gWKKeSi6ZBFDEQwDsMiIpivEzVzn7V4B5ZRrMw9M.jpeg

Перший шлях – це найпряміше масштабування в ланцюжку, що означає збільшення розміру блоку, скорочення часу блоку або покращення обчислювальної потужності за рахунок оптимізації структури даних та механізму консенсусу. Цей підхід був у центрі уваги дебатів про масштабування Bitcoin, що призвело до появи форків фракцій «великого блоку», таких як BCH та BSV, а також вплинуло на ідеї дизайну ранніх високопродуктивних публічних ланцюгів, таких як EOS та NEO. Перевага такого роду маршруту полягає в тому, що він зберігає простоту одноланцюгової узгодженості, яку легко зрозуміти та розгорнути, але також дуже легко торкнутися системних верхніх меж, таких як ризики централізації, зростання експлуатаційних витрат вузлів та збільшення труднощів із синхронізацією, тому він більше не є основним основним основним рішенням у сучасному дизайні, а став скоріше допоміжним розташуванням інших механізмів.

Другий тип маршруту – це офчейн-масштабування, яке представлено каналами стану та сайдчейнами. Основна ідея цього типу шляху полягає в тому, щоб перенести більшу частину транзакційної активності в офчейн і записувати кінцевий результат лише в основний ланцюг, який виступає в якості кінцевого рівня розрахунків. З точки зору технічної філософії, вона близька до асинхронної архітектури Web2 — намагайтеся залишити важку обробку транзакцій на периферії, а основний ланцюг робить мінімальну довірчу верифікацію. Хоча ця ідея теоретично може бути нескінченно масштабованою, модель довіри, безпека фондів і складність взаємодії офчейн-транзакцій обмежують її застосування. Наприклад, хоча Lightning Network має чітке позиціонування фінансових сценаріїв, масштаби екосистеми ніколи не вибухали. Однак кілька конструкцій на основі сайдчейнів, таких як Polygon POS, не тільки мають високу пропускну здатність, але й викривають недоліки складного успадкування безпеки основного ланцюга.

Третій тип маршрутів є найпопулярнішим і широко розгорнутим маршрутом зведення рівня 2. Цей метод безпосередньо не змінює сам основний ланцюг, а масштабується через механізм виконання поза ланцюгом та верифікації в мережі. Optimistic Rollup і ZK Rollup мають свої переваги: перший швидкий у впровадженні та високо сумісний, але має проблеми затримки періоду виклику та механізму захисту від шахрайства; Останній має надійний захист і хороші можливості стиснення даних, але він складний у розробці та не має сумісності з EVM. Незалежно від типу роллапа, його суть полягає в тому, щоб передати на аутсорсинг повноваження виконання, зберігаючи при цьому дані та верифікацію на основному ланцюжку, для досягнення відносного балансу між децентралізацією та високою продуктивністю. Стрімке зростання таких проєктів, як Arbitrum, Optimism, zkSync і StarkNet, доводить реалістичність цього шляху, але воно також оголює середньострокові вузькі місця, такі як надмірна залежність від доступності даних (DA), високі витрати та фрагментарний досвід розробки.

Четвертий тип маршруту – це модульна архітектура блокчейну, що з'явилася в останні роки, така як Celestia, Avail, EigenLayer тощо. Модульна парадигма виступає за повне відокремлення основних функцій блокчейну - виконання, консенсусу, доступності даних і розрахунків - кількома спеціалізованими ланцюжками для виконання різних функцій, а потім об'єднання їх в масштабовану мережу з крос-чейн протоколом. На цей напрямок сильно вплинула модульна архітектура операційної системи та концепція компонування хмарних обчислень, перевагою якої є можливість гнучкої заміни компонентів системи та значного підвищення ефективності в конкретних областях, таких як DA. Однак проблеми також дуже очевидні: вартість синхронізації, верифікації та взаємної довіри між системами після розв'язки модулів надзвичайно висока, екосистема розробників надзвичайно фрагментована, а вимоги до середньострокових і довгострокових стандартів протоколів і крос-чейн безпеки набагато вищі, ніж при традиційному дизайні ланцюгів. По суті, ця модель вже не будує «ланцюжок», а будує «ланцюгову мережу», що висуває безпрецедентний поріг для загального розуміння архітектури та її експлуатації та обслуговування.

Останнім типом маршруту, на якому зосереджений подальший аналіз у даній роботі, є внутрішньоланцюговий шлях оптимізації паралельних обчислень. На відміну від перших чотирьох типів «горизонтального розбиття», які в основному здійснюють «горизонтальне розбиття» зі структурного рівня, паралельні обчислення роблять акцент на «вертикальному оновленні», тобто паралельна обробка атомарних транзакцій реалізується шляхом зміни архітектури механізму виконання в межах єдиного ланцюга. Для цього потрібно переписати логіку планування ВМ і впровадити повний набір сучасних механізмів планування комп'ютерних систем, таких як аналіз залежності транзакцій, прогнозування конфліктів станів, контроль паралелізму та асинхронний виклик. Solana є першим проєктом, який реалізує концепцію паралельної віртуальної машини в систему на рівні ланцюга, яка реалізує багатоядерне паралельне виконання за допомогою судження про конфлікт транзакцій на основі моделі облікового запису. Нове покоління проектів, таких як Monad, Sei, Fuel, MegaETH і т.д., також намагається впровадити передові ідеї, такі як виконання конвеєра, оптимістичний паралелізм, розділення сховища і паралельне розв'язування для створення високопродуктивних ядер виконання, схожих на сучасні процесори. Основна перевага цього напрямку полягає в тому, що йому не потрібно покладатися на багатоланцюгову архітектуру для досягнення прориву в ліміті пропускної здатності, і в той же час забезпечує достатню обчислювальну гнучкість для виконання складних смарт-контрактів, що є важливою технічною передумовою для майбутніх сценаріїв застосування, таких як AI Agent, масштабні ланцюгові ігри та високочастотні похідні.

Якщо розглядати вищезазначені п'ять типів шляхів масштабування, то поділ, що стоїть за ними, насправді є систематичним компромісом між продуктивністю, компонуванням, безпекою та складністю розробки блокчейну. Rollup сильний у консенсусному аутсорсингу та безпечному успадкуванні, модульність підкреслює структурну гнучкість та повторне використання компонентів, масштабування поза ланцюгом намагається пробити вузьке місце основного ланцюга, але вартість довіри висока, а внутрішньоланцюговий паралелізм зосереджується на фундаментальному оновленні рівня виконання, намагаючись наблизитися до межі продуктивності сучасних розподілених систем без руйнування узгодженості ланцюга. Кожен шлях не може вирішити всі проблеми, але саме ці напрямки разом формують панораму оновлення парадигми Web3 комп'ютерів, а також надають розробникам, архітекторам та інвесторам надзвичайно багаті стратегічні можливості.

Подібно до того, як операційні системи історично перейшли від одноядерних до багатоядерних, а бази даних еволюціонували від послідовних індексів до паралельних транзакцій, розширення Web3 зрештою перейде до ери високопаралельного виконання. У цю епоху продуктивність – це вже не просто гонка за швидкістю ланцюга, а всеосяжне втілення філософії, що лежить в основі дизайну, глибини розуміння архітектури, спільної роботи програмного та апаратного забезпечення, а також управління системою. Внутрішньоланцюговий паралелізм може стати кінцевим полем бою цієї довготривалої війни.

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

У контексті безперервної еволюції технології масштабування блокчейну, паралельні обчислення поступово стали основним шляхом для проривів у продуктивності. На відміну від горизонтального розв'язання рівня структури, мережевого рівня або рівня доступності даних, паралельні обчислення є глибоким видобутком на рівні виконання, який пов'язаний з найнижчою логікою ефективності роботи блокчейну та визначає швидкість реакції та обчислювальну здатність системи блокчейну в умовах високого паралелізму та багатотипових складних транзакцій. Відштовхуючись від моделі виконання та розглядаючи розвиток цієї технологічної лінії, ми можемо скласти чітку класифікаційну карту паралельних обчислень, яку можна умовно розділити на п'ять технічних шляхів: паралелізм на рівні облікового запису, паралелізм на рівні об'єкта, паралелізм на рівні транзакцій, паралелізм на рівні віртуальної машини та паралелізм на рівні інструкцій. Ці п'ять типів шляхів, від грубозернистих до дрібнозернистих, є не тільки безперервним процесом уточнення паралельної логіки, але й шляхом зростання складності системи та складності планування.

! ymDdJOgxNJpF3CHw4pG2f3dKrLmjctVWnJuIrXkb.jpeg

Найбільш раннім проявом паралелізму на рівні рахунку є парадигма, представлена Solana. Ця модель ґрунтується на дизайні розв'язки «рахунок-стан» і визначає, чи існує конфліктний зв'язок за допомогою статичного аналізу множини рахунків, що беруть участь у транзакції. Якщо набір облікових записів, доступ до яких здійснюється двома транзакціями, не перетинається один з одним, вони можуть виконуватися одночасно на кількох ядрах. Цей механізм ідеально підходить для роботи з добре структурованими транзакціями з чіткими входами та виходами, особливо для програм з передбачуваними шляхами, таких як DeFi. Однак його природне припущення полягає в тому, що доступ до облікового запису є передбачуваним, а залежність від стану може бути статично виведена, що робить його схильним до консервативного виконання та зменшення паралелізму в умовах складних смарт-контрактів (таких як динамічна поведінка, така як ланцюгові ігри та агенти штучного інтелекту). Крім того, перехресна залежність між рахунками також робить паралельну прибутковість сильно ослабленою в певних сценаріях високочастотної торгівлі. У цьому відношенні час виконання Solana дуже оптимізований, але його основна стратегія планування все ще обмежена деталізацією облікового запису.

Подальше уточнення на основі моделі рахунку ми входимо в технічний рівень об'єктного паралелізму. Паралелізм на рівні об'єкта вводить семантичну абстракцію ресурсів і модулів з одночасним плануванням в одиницях більш тонких «об'єктів стану». Aptos і Sui є важливими дослідниками в цьому напрямку, особливо останній, який визначає власність і варіативність ресурсів під час компіляції через систему лінійних типів мови Move, дозволяючи часу виконання точно контролювати конфлікти доступу до ресурсів. У порівнянні з паралелізмом на рівні облікового запису, цей метод є більш універсальним і масштабованим, може охоплювати більш складну логіку читання та запису станів і, природно, обслуговує дуже різнорідні сценарії, такі як ігри, соціальні мережі та штучний інтелект. Однак паралелізм на рівні об'єкта також вносить більш високий мовний поріг і складність розробки, а Move не є прямою заміною Solidity, а висока вартість екологічного перемикання обмежує популяризацію його паралельної парадигми.

Подальший паралелізм на рівні транзакцій - це напрямок, який досліджує нове покоління високопродуктивних ланцюгів, представлених Monad, Sei і Fuel. Path більше не розглядає стани або рахунки як найменшу одиницю паралелізму, а замість цього будує граф залежностей навколо всієї транзакції. Він розглядає транзакції як атомарні одиниці роботи, будує графіки транзакцій (Transaction DAGs) за допомогою статичного або динамічного аналізу та покладається на планувальники для одночасного виконання потоку. Така конструкція дозволяє системі максимізувати паралелізм гірничих робіт без необхідності повністю розуміти структуру, що лежить в основі. Monad особливо привертає увагу, поєднуючи сучасні технології двигуна баз даних, такі як Optimistic Concurrency Control (OCC), паралельне планування конвеєрів і виконання поза замовленням, що наближає виконання ланцюга до парадигми «планувальника GPU». На практиці цей механізм вимагає надзвичайно складних менеджерів залежностей і детекторів конфліктів, а сам планувальник також може стати вузьким місцем, але його потенційна пропускна здатність набагато вище, ніж у облікового запису або об'єктної моделі, що робить його найбільш теоретичною силою в поточному треку паралельних обчислень.

Паралелізм на рівні віртуальної машини, з іншого боку, вбудовує можливості одночасного виконання безпосередньо в базову логіку планування команд віртуальної машини, прагнучи повністю подолати обмеження, властиві виконанню послідовності EVM. В якості «експерименту з супервіртуальною машиною» в екосистемі Ethereum, MegaETH намагається переробити EVM для підтримки багатопотокового одночасного виконання коду смарт-контракту. Базовий рівень дозволяє кожному контракту працювати незалежно в різних контекстах виконання за допомогою таких механізмів, як сегментоване виконання, сегментація станів і асинхронний виклик, і забезпечує кінцеву узгодженість за допомогою рівня паралельної синхронізації. Найскладніша частина цього підходу полягає в тому, що він повинен бути повністю сумісний з існуючою семантикою поведінки EVM, і в той же час трансформувати все середовище виконання і газовий механізм, щоб плавно перенести екосистему Solidity на паралельний фреймворк. Проблема полягає не тільки в глибині технологічного стеку, але і в прийнятті значних змін протоколу в політичній структурі L1 Ethereum. Але в разі успіху MegaETH обіцяє стати «революцією багатоядерних процесорів» у просторі EVM.

Останнім типом шляху є паралелізм на рівні інструкцій, який є найбільш точним і має найвищий технічний поріг. Ідея походить від конвеєрів Out-of-Order Execution та Instruction Pipelines у сучасному дизайні процесорів. Ця парадигма стверджує, що оскільки кожен смарт-контракт в кінцевому підсумку компілюється в інструкції байт-коду, цілком можливо планувати і переставляти кожну операцію так само, як процесор виконує набір інструкцій x86. Команда Fuel спочатку представила модель впорядкованого виконання на рівні інструкцій у своєму FuelVM, і в довгостроковій перспективі, як тільки механізм виконання блокчейну реалізує прогнозоване виконання та динамічну перестановку залежних від інструкцій, його паралелізм досягне теоретичної межі. Цей підхід може навіть вивести спільне проектування блокчейну та апаратного забезпечення на абсолютно новий рівень, зробивши ланцюг справжнім «децентралізованим комп'ютером», а не просто «розподіленим реєстром». Звичайно, цей шлях все ще знаходиться на теоретичній та експериментальній стадії, а відповідні планувальники та механізми перевірки безпеки ще не дозріли, але це вказує на кінцеву межу майбутнього паралельних обчислень.

Таким чином, п'ять шляхів облікового запису, об'єкта, транзакції, віртуальної машини та інструкції складають спектр розвитку внутрішньоланцюгових паралельних обчислень, від статичної структури даних до динамічного механізму планування, від прогнозування доступу до стану до перестановки на рівні інструкцій, кожен крок паралельної технології означає значне збільшення складності системи та порогу розвитку. Але в той же час вони також знаменують зміну парадигми в моделях обчислень на блокчейні, від традиційного реєстру консенсусу з повною послідовністю до високопродуктивного, передбачуваного та диспетчеризованого розподіленого середовища виконання. Це не лише наздоганяння ефективності хмарних обчислень Web2, а й глибоке розуміння кінцевої форми «блокчейн-комп'ютера». Вибір паралельних шляхів для різних публічних ланцюгів також визначить ліміт на пред'явника їхніх майбутніх екосистем додатків, а також їхню основну конкурентоспроможність у таких сценаріях, як AI Agent, ланцюгові ігри та високочастотна торгівля в мережі.

Чотири, глибокий аналіз двох основних напрямків: Monad проти MegaETH

Серед численних шляхів еволюції паралельних обчислень, двома основними технічними маршрутами з найбільшою увагою, найвищим голосом і найповнішим наративом на сучасному ринку, безсумнівно, є «побудова паралельного обчислювального ланцюжка з нуля», представлена Monad, і «паралельна революція в EVM», представлена MegaETH. Ці два напрямки є не тільки найінтенсивнішими напрямками досліджень і розробок для нинішніх криптографічних примітивних інженерів, але й найбільш визначальними полярними символами в поточній гонці продуктивності комп'ютерів Web3. Різниця між ними полягає не тільки в відправній точці та стилі технічної архітектури, але й в екологічних об'єктах, які вони обслуговують, вартості міграції, філософії виконання та майбутньому стратегічному шляху, що стоїть за ними. Вони являють собою паралельну парадигму конкуренції між «реконструкціонізмом» і «сумісністю» і глибоко вплинули на уявлення ринку про кінцеву форму високопродуктивних ланцюгів.

«Обчислювальний фундаменталіст» наскрізь, філософія дизайну Monad розроблена не для того, щоб бути сумісною з існуючими EVM, а скоріше для того, щоб переосмислити спосіб, яким механізми виконання блокчейну працюють під капотом, черпаючи натхнення з сучасних баз даних і високопродуктивних багатоядерних систем. Його основна технологічна система спирається на зрілі механізми в області баз даних, такі як оптимістичний контроль паралелізму, планування транзакцій DAG, виконання поза замовленням і виконання конвеєра, спрямовані на підвищення продуктивності обробки транзакцій ланцюга до порядку мільйонів TPS. В архітектурі Monad виконання і впорядкування транзакцій повністю розв'язані, і система спочатку будує граф залежності транзакцій, а потім передає його планувальнику для паралельного виконання. Всі транзакції розглядаються як атомарні одиниці транзакцій, з явними наборами читань і записів і знімками стану, а планувальники оптимістично виконують їх на основі графіків залежностей, відкатів і повторного виконання при виникненні конфліктів. Цей механізм є надзвичайно складним з точки зору технічної реалізації, вимагаючи побудови стека виконання, аналогічного сучасному менеджеру транзакцій баз даних, а також впровадження таких механізмів, як багаторівневе кешування, попередня вибірка, паралельна перевірка і т.д., для стиснення затримки коміту кінцевого стану, але він теоретично може підняти межу пропускної здатності до висот, які не уявляються поточним ланцюжком.

Що ще важливіше, Monad не відмовилася від сумісності з EVM. Через проміжний рівень, схожий на "Solidity-Compatible Intermediate Language", він підтримує розробників у написанні контрактів на синтаксисі Solidity, і в той же час виконує оптимізацію проміжної мови та планування розпаралелювання в движку виконання. Ця стратегія дизайну «поверхневої сумісності та рефакторингу дна» не тільки зберігає свою дружелюбність до екологічних розробників Ethereum, але й найбільшою мірою вивільняє базовий потенціал виконання, що є типовою технічною стратегією «ковтання EVM, а потім його деконструкції». Це також означає, що як тільки Monad буде запущено, він не тільки стане суверенним ланцюгом з надзвичайною продуктивністю, але й ідеальним рівнем виконання для зведених мереж рівня 2, і навіть «високопродуктивним ядром, що підключається» для інших модулів виконання ланцюга в довгостроковій перспективі. З цієї точки зору, Monad - це не тільки технічний шлях, але і нова логіка проектування суверенітету системи, яка пропагує "модульність-продуктивність-повторне використання" виконавчого рівня, щоб створити новий стандарт для міжланцюгових спільних обчислень.

На відміну від позиції Monad «нового творця світу», MegaETH є абсолютно протилежним типом проектів, які вважають за краще відштовхуватися від існуючого світу Ethereum і досягати значного підвищення ефективності виконання з мінімальними витратами на зміни. Замість того, щоб скасувати специфікацію EVM, MegaETH прагне вбудувати потужність паралельних обчислень у механізм виконання існуючого EVM для створення майбутньої версії «багатоядерного EVM». Обґрунтування полягає в повному рефакторингу поточної моделі виконання інструкцій EVM з такими можливостями, як ізоляція на рівні потоків, асинхронне виконання на рівні контракту та виявлення конфлікту доступу до стану, що дозволяє декільком смарт-контрактам працювати одночасно в одному блоці та в кінцевому підсумку об'єднувати зміни станів. Ця модель вимагає від розробників досягнення значного приросту продуктивності від одного і того ж контракту, розгорнутого в ланцюжку MegaETH, без зміни існуючих контрактів Solidity, використання нових мов або ланцюжків інструментів. Цей шлях «консервативної революції» надзвичайно привабливий, особливо для екосистеми Ethereum L2, оскільки він забезпечує ідеальний шлях до безболісного оновлення продуктивності без необхідності перенесення синтаксису.

Основний прорив MegaETH полягає в його багатопотоковому механізмі планування віртуальних машин. Традиційні EVM використовують складену, однопотокову модель виконання, де кожна інструкція виконується лінійно, а оновлення стану має відбуватися синхронно. MegaETH порушує цю схему і вводить асинхронний стек викликів і механізм ізоляції контексту виконання, щоб досягти одночасного виконання «паралельних контекстів EVM». Кожен контракт може викликати свою власну логіку в окремому потоці, і всі потоки будуть рівномірно виявляти та конвертувати стан через шар Parallel Commit Layer, коли стан нарешті буде відправлено. Цей механізм дуже схожий на модель багатопоточності JavaScript сучасних браузерів (Web Workers + Shared Memory + Lock-Free Data), яка зберігає детермінованість поведінки основного потоку і вводить високопродуктивний механізм планування, який є асинхронним у фоновому режимі. На практиці цей дизайн також надзвичайно дружній до розробників блоків і пошукачів, і може оптимізувати сортування Mempool і шляхи захоплення MEV відповідно до паралельних стратегій, формуючи замкнутий цикл економічних переваг на рівні виконання.

Більше того, MegaETH вирішує бути глибоко пов'язаною з екосистемою Ethereum, і її основним місцем розташування в майбутньому, ймовірно, буде мережа EVM L2 Rollup, така як Optimism, Base або Arbitrum Orbit chain. Після прийняття у великих масштабах він може досягти майже 100-кратного підвищення продуктивності поверх існуючого стека технологій Ethereum без зміни семантики контрактів, моделі стану, логіки газу, методів виклику тощо, що робить його привабливим напрямком оновлення технології для консерваторів EVM. Парадигма MegaETH така: поки ви все ще робите речі на Ethereum, я дозволю вашій обчислювальній продуктивності різко зрости. З точки зору реалізму та інженерії, його легше впровадити, ніж Monad, і він більше відповідає ітеративному шляху основних проєктів DeFi та NFT, що робить його кандидатом на екологічну підтримку в короткостроковій перспективі.

У певному сенсі два маршрути Monad і MegaETH - це не тільки дві реалізації паралельних технологічних шляхів, але і класичне протистояння між «рефакторингом» і «сумісністю» на шляху розробки блокчейна: перший переслідує прорив парадигми і реконструює всю логіку від віртуальних машин до базового управління станами для досягнення кінцевої продуктивності і архітектурної пластичності; Остання проводить поступову оптимізацію, доводячи традиційні системи до межі, дотримуючись існуючих екологічних обмежень, тим самим мінімізуючи витрати на міграцію. Між ними немає абсолютних переваг чи недоліків, але вони служать різним групам розробників та екологічним баченням. Monad більше підходить для створення нових систем з нуля, ланцюгових ігор, які переслідують екстремальну пропускну здатність, агентів штучного інтелекту та модульних ланцюжків виконання. MegaETH, з іншого боку, більше підходить для проєктів L2, проєктів DeFi та протоколів інфраструктури, які хочуть досягти підвищення продуктивності з мінімальними змінами в розробці.

Вони схожі на швидкісні поїзди на новій колії, перевизначені з колії, від електромережі до кузова автомобіля, лише для досягнення безпрецедентної швидкості та досвіду; Іншим прикладом є встановлення турбін на існуючих автомагістралях, покращення планування смуги руху та конструкції двигуна, що дозволяє транспортним засобам їхати швидше, не виїжджаючи за межі знайомої дорожньої мережі. На наступному етапі модульних архітектур блокчейну Monad може стати модулем «виконання як послуга» для Rollups, а MegaETH може стати плагіном для прискорення продуктивності для основних L2. Вони можуть в кінцевому підсумку зійтися, щоб сформувати резонанс двох крил високопродуктивного розподіленого механізму виконання в майбутньому світі Web3.

П'ять. Майбутні можливості та виклики паралельних обчислень

У міру того, як паралельні обчислення переходять від паперового дизайну до реалізації в ланцюжку, потенціал, який вони розкривають, стає все більш конкретним і вимірюваним. З одного боку, ми побачили, що нові парадигми розробки та бізнес-моделі почали перевизначати «високу продуктивність у мережі»: складніша логіка ланцюгової гри, більш реалістичний життєвий цикл агента штучного інтелекту, більше протоколу обміну даними в реальному часі, більш захоплюючий інтерактивний досвід і навіть спільна операційна система Super App у ланцюжку змінюються від «чи можна це зробити» до «наскільки добре це можна зробити». З іншого боку, те, що дійсно є рушійною силою переходу до паралельних обчислень, — це не лише лінійне покращення продуктивності системи, а й структурна зміна когнітивних кордонів розробників та витрат на екологічну міграцію. Подібно до того, як впровадження Ethereum механізму повного контракту Тюрінга породило багатовимірний вибух DeFi, NFT і DAO, «асинхронна реконструкція між станом та інструкціями», спричинена паралельними обчисленнями, також породжує нову модель світу в ланцюжку, яка є не лише революцією в ефективності виконання, але й розсадником інновацій поділу в структурі продукту.

! DOJfWkUvdgXyrZl6ZRNhsiGukJExCYzDIvn6DNC3.jpeg

Перш за все, з точки зору можливостей, найбільш прямою вигодою є «підняття стелі застосування». Більшість поточних DeFi, ігрових та соціальних додатків обмежені вузькими місцями штату, вартістю газу та затримкою, і не можуть по-справжньому здійснювати високочастотні взаємодії в ланцюжку у великих масштабах. Якщо взяти для прикладу ланцюгові ігри, то GameFi з реальним зворотним зв'язком руху, синхронізацією високочастотної поведінки та логікою бою в реальному часі майже не існує, тому що лінійне виконання традиційного EVM не може підтримувати підтвердження трансляції десятків змін станів на секунду. За допомогою паралельних обчислень, за допомогою таких механізмів, як DAG транзакцій та асинхронні контексти на рівні контрактів, можна створювати ланцюги з високим рівнем паралелізму, а детерміновані результати виконання можуть бути гарантовані завдяки узгодженості знімків, щоб досягти структурного прориву в «ігровому движку на ланцюжку». Аналогічним чином, розгортання та експлуатація агентів штучного інтелекту також будуть значно покращені за допомогою паралельних обчислень. У минулому ми мали тенденцію запускати AI-агентів поза ланцюгом і завантажувати результати їхньої поведінки лише в ончейн-контракти, але в майбутньому ончейн може підтримувати асинхронну співпрацю та обмін станами між кількома сутностями штучного інтелекту за допомогою паралельного планування транзакцій, щоб справді реалізувати автономну логіку агента в ланцюжку в реальному часі. Паралельні обчислення стануть інфраструктурою для цього «контракту, керованого поведінкою», що перетворить Web3 з «транзакцій як активів» у новий світ «взаємодії як агентів».

По-друге, ланцюжок інструментів розробника та рівень абстракції віртуальних машин також були структурно змінені завдяки паралелізації. Традиційна парадигма розробки Solidity базується на моделі послідовного мислення, де розробники звикли проектувати логіку як однопотокову зміну станів, але в архітектурах паралельних обчислень розробники будуть змушені думати про конфлікти наборів читання/запису, політики ізоляції станів, атомарність транзакцій і навіть впроваджувати архітектурні шаблони на основі черг повідомлень або конвеєрів станів. Цей стрибок у когнітивній структурі також породив швидке зростання нового покоління ланцюжків інструментів. Наприклад, фреймворк паралельних смарт-контрактів, який підтримує оголошення залежності транзакцій, оптимізаційний компілятор на основі IR і паралельний налагоджувач, який підтримує моделювання знімків транзакцій, стануть розсадником вибуху інфраструктури в новому циклі. У той же час, безперервна еволюція модульних блокчейнів також принесла відмінний шлях приземлення для паралельних обчислень: Monad може бути вставлена в L2 Rollup як модуль виконання, MegaETH може бути розгорнута як заміна EVM для основних ланцюгів, Celestia забезпечує підтримку рівня доступності даних, а EigenLayer надає децентралізовану мережу валідаторів, формуючи таким чином високопродуктивну інтегровану архітектуру від базових даних до логіки виконання.

Однак прогрес паралельних обчислень не є легким шляхом, а виклики навіть структурніші та складніші, ніж можливості. З одного боку, основні технічні труднощі полягають у «гарантії узгодженості державного паралелізму» та «стратегії врегулювання конфліктів транзакцій». На відміну від офчейн баз даних, ончейн не може терпіти довільний ступінь відкату транзакцій або відкликання стану, і будь-які конфлікти виконання потрібно моделювати заздалегідь або точно контролювати під час події. Це означає, що паралельний планувальник повинен мати сильні можливості побудови графа залежностей і прогнозування конфліктів, і в той же час він також повинен проектувати ефективний механізм відмовостійкості оптимістичного виконання, інакше система схильна до «одночасного шторму повторних спроб відмови» при високому навантаженні, яке не тільки збільшується, але і зменшується, і навіть викликає нестабільність ланцюга. Більше того, поточна модель безпеки багатопотокового середовища виконання ще не повністю встановлена, наприклад, точність механізму ізоляції станів між потоками, нове використання атак повторного входу в асинхронних контекстах і газовий вибух перехресно-потокових викликів контрактів, які є новими проблемами, які потребують вирішення.

Більш підступні виклики виникають з екологічних та психологічних аспектів. Чи готові розробники перейти на нову парадигму, чи зможуть вони освоїти методи проектування паралельних моделей і чи готові вони відмовитися від певної читабельності та контрактного аудиту заради вигоди від продуктивності, є ключем до визначення того, чи можуть паралельні обчислення формувати енергію екологічного потенціалу. За останні кілька років ми бачили, що низка ланцюгів із чудовою продуктивністю, але без підтримки розробників поступово замовкають, такі як NEAR, Avalanche і навіть деякі ланцюги Cosmos SDK з набагато кращою продуктивністю, ніж EVM, і їхній досвід нагадує нам, що без розробників немає екосистеми; Без екології, якою б гарною не була вистава, це просто повітряний замок. Таким чином, проекти паралельних обчислень повинні не тільки створити найпотужніший двигун, але й зробити найбільш м'який екологічний шлях переходу, щоб «продуктивність була нестандартною», а не «продуктивність була когнітивним порогом».

Зрештою, майбутнє паралельних обчислень – це одночасно і тріумф системної інженерії, і випробування для екодизайну. Це змусить нас переглянути питання про те, «в чому суть ланцюга»: це децентралізована розрахункова машина чи глобально розподілений оркестратор станів у реальному часі? Якщо це так, то можливості пропускної здатності стану, паралелізму транзакцій і реагування на контракти, які раніше розглядалися як «технічні деталі ланцюга», в кінцевому підсумку стануть основними показниками, що визначають вартість ланцюга. Парадигма паралельних обчислень, яка дійсно завершує цей перехід, також стане найбільш основними та найбільш складними примітивами інфраструктури в цьому новому циклі, а її вплив вийде далеко за межі технічного модуля і може стати поворотним моментом у загальній парадигмі обчислень Web3.

Шість, висновок: Чи є паралельні обчислення найкращим шляхом для нативного масштабування Web3?

З усіх шляхів дослідження меж продуктивності Web3 паралельні обчислення не найпростіші в реалізації, але вони можуть бути найбільш близькими до суті блокчейну. Він не мігрує поза ланцюгом і не жертвує децентралізацією в обмін на пропускну здатність, а намагається реконструювати саму модель виконання в атомарності та детермінованості ланцюга, від рівня транзакцій, рівня контрактів та рівня віртуальної машини до кореня вузького місця продуктивності. Цей «рідний для ланцюга» метод масштабування не тільки зберігає основну модель довіри блокчейну, але й резервує стійкий ґрунт продуктивності для більш складних ончейн-додатків у майбутньому. Його складність полягає в будові, а його принадність полягає в структурі. Якщо модульна реконструкція – це «архітектура ланцюга», то реконструкція паралельних обчислень – це «душа ланцюга». Можливо, це не найкоротший шлях до митного оформлення, але, ймовірно, це буде єдиним стійким позитивним рішенням у довгостроковій еволюції Web3. Ми є свідками подібного архітектурного переходу від одноядерних процесорів до багатоядерних/потокових ОС, і зовнішній вигляд операційних систем, нативних для Web3, може ховатися в цих паралельних експериментах у ланцюжку.