Звіт про глибоке дослідження паралельних обчислень 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-планувальника".

А віртуальна машина рівня паралельності вбудовує можливості паралельного виконання безпосередньо в логіку розподілу інструкцій на базі ВМ, прагнучи повністю подолати обмеження послідовного виконання 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 або