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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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