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

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

Блокчейн-системи з моменту свого виникнення стикаються з основною проблемою масштабування. Кількість транзакцій на секунду (TPS) біткойна та ефіріума все ще низька в порівнянні з традиційними системами Web2. Це не просто проблема, яку можна вирішити простим збільшенням кількості серверів, адже вона обмежена трьома труднощами, закладеними в базовому дизайні блокчейну: "децентралізація, безпека, масштабованість".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подальша паралельність на рівні транзакцій є напрямком, який досліджують нові покоління високопродуктивних ланцюгів, таких як Monad, Sei, Fuel. Цей шлях більше не розглядає стан або обліковий запис як мінімальні паралельні одиниці, а фокусується на побудові графа залежностей навколо самої транзакції. Транзакція розглядається як атомарна одиниця операцій, граф транзакцій будується за допомогою статичного або динамічного аналізу, і для паралельного конвеєрного виконання покладається на планувальник. Цей дизайн дозволяє системі максимізувати паралельність, не вимагаючи повного розуміння структури підлеглого стану. Monad особливо вражає, оскільки поєднує оптимістичний контроль паралельності (OCC), паралельне конвеєрне планування, виконання в неналежному порядку та інші сучасні технології бази даних, що робить виконання ланцюга ближчим до парадигми "планувальника GPU". На практиці цей механізм вимагає надзвичайно складного менеджера залежностей і детектора конфліктів, сам планувальник також може стати вузьким місцем, але його потенційна пропускна спроможність набагато перевищує облікові моделі або моделі об'єктів, що робить його однією з найбільш теоретично потужних сил у сучасній сфері паралельних обчислень.

А віртуальна машина високого рівня паралельність вбудовує можливості паралельного виконання безпосередньо в логіку розкладання інструкцій на базовому рівні ВМ, прагнучи повністю подолати обмеження послідовного виконання EVM. MegaETH, як "супер віртуальна машина експеримент" в екосистемі Ethereum, намагається шляхом повторного проектування EVM забезпечити підтримку багатопоточного паралельного виконання коду смарт-контрактів. Його основа через сегментне виконання, розділення станів, асинхронні виклики та інші механізми дозволяє кожному контракту незалежно працювати в різних контекстах виконання та використовувати паралельний синхронний рівень для забезпечення.