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

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

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

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

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

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

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

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

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

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

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

Третій тип маршруту - це нині найпопулярніший і найбільш широко впроваджений маршрут Layer2 Rollup. Цей підхід реалізує масштабування через механізм виконання поза ланцюгом та верифікації на ланцюзі. Optimistic Rollup і ZK Rollup мають свої переваги, але обидва стикаються з середньостроковими перешкодами, такими як надмірна залежність від доступності даних, все ще високі витрати та розрив у досвіді розробки.

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

Останній тип маршруту – це оптимізований шлях для паралельних обчислень всередині ланцюга. Паралельні обчислення підкреслюють "вертикальне оновлення", тобто в межах одного ланцюга шляхом зміни архітектури виконавчого движка досягати паралельної обробки атомарних транзакцій. Це вимагає переписати логіку планування VM, впровадити аналіз залежностей транзакцій, прогнозування конфліктів станів, контроль паралелізму, асинхронні виклики та цілий ряд сучасних механізмів планування комп'ютерних систем. Основна перевага цього напрямку полягає в тому, що не потрібно покладатися на багатоланцюгову архітектуру, щоб досягти突破 межі пропускної спроможності, водночас забезпечуючи достатню обчислювальну гнучкість для виконання складних смарт-контрактів, що є важливою технічною передумовою для майбутніх застосувань таких як AI Agent, великі ланцюгові ігри, високочастотні похідні.

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

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

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

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

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

А віртуалізація на рівні машин, фактично, вбудовує можливість паралельного виконання безпосередньо в логіку диспетчеризації інструкцій на базовому рівні VM, прагнучи повністю подолати фіксовані обмеження послідовного виконання EVM. Деякі проекти, як "супер віртуальна машина експеримент" в екосистемі Ethereum, намагаються шляхом повторного дизайну EVM, щоб вона підтримувала багатопотокове паралельне виконання коду смарт-контрактів. На базовому рівні через сегментацію виконання, розподіл стану, асинхронні виклики та інші механізми, дозволяється кожному контракту незалежно працювати в різних контекстах виконання, і завдяки паралельному синхронізаційному шару забезпечується остаточна узгодженість. Найскладніше в цьому підході полягає в тому, що він повинен повністю відповідати існуючій семантиці поведінки EVM, одночасно модифікуючи все середовище виконання та механізм Gas, щоб екосистема могла плавно перейти на паралельну структуру. Його виклик не тільки в глибокій технологічній стеку, але й у питанні прийнятності політичної структури Ethereum L1 до суттєвих змін протоколу. Але, якщо це вдасться, це може стати "революцією багатоядерних процесорів" в області EVM.

Останній тип шляху — це найдрібніший, з найвищим технологічним бар'єром, паралелізм на рівні інструкцій. Його ідея походить з сучасного дизайну ЦПУ, з його неупорядкованим виконанням та конвеєризацією інструкцій. Ця парадигма вважає, що оскільки кожен смарт-контракт в кінцевому підсумку компілюється в байтовий код інструкцій, то цілком можливо, як ЦПУ виконує набір інструкцій x86, проводити аналіз розкладу та паралельну переупорядкування для кожної операції. Деякі проекти вже попередньо впровадили модель виконання на рівні інструкцій у своїх ВМ, а в довгостроковій перспективі, як тільки блокчейн-двигун виконання реалізує прогнозне виконання та динамічне переупорядкування залежностей інструкцій, його паралельність досягне теоретичного максимуму. Цей підхід може навіть підняти співпрацю блокчейну з апаратним забезпеченням на абсолютно новий рівень, перетворивши ланцюг на справжній "децентралізований комп'ютер", а не просто "розподілений реєстр". Звісно, цей шлях наразі все ще перебуває на теоретичному та експериментальному етапі, відповідні планувальники та механізми безпеки ще не досягли зрілості, але він вказує на остаточні межі паралельних обчислень у майбутньому.

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

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

Monad є справжнім "обчислювальним ортодоксом", його дизайн не має на меті сумісність з існуючим EVM, а натомість черпає натхнення з сучасних баз даних та високопродуктивних багатоядерних систем, щоб переосмислити способи виконання блокчейн-двигунів. Його основна технологічна система спирається на зрілу механіку з області баз даних, таку як оптимістичний контроль паралелізму, планування транзакцій DAG, виконання в випадковому порядку, пакетна обробка тощо, з метою підвищення продуктивності обробки транзакцій у мережі до мільйонів TPS. У архітектурі Monad виконання та сортування транзакцій повністю декомпоновані, система спочатку будує граф залежностей транзакцій, а потім передає його планувальнику для паралельного виконання. Усі транзакції розглядаються як атомарні одиниці транзакції,