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

Вступ: Розширення — це вічна тема, паралельність — це остаточна арена

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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