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

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

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

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

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

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

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

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

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

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

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

Другий тип маршруту – це масштабування поза ланцюгом, його представниками є канали стану та бічні ланцюги. Основна ідея цього шляху полягає в тому, щоб перенести більшість торговельних активностей поза ланцюг, лише остаточні результати записувати в основний ланцюг, де основний ланцюг виступає як фінальний рівень розрахунків. У технічній філософії це близько до асинхронної архітектури 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 агенти тощо з динамічною поведінкою). Крім того, перехресна залежність між обліковими записами серйозно зменшує паралельні вигоди в деяких сценаріях високочастотної торгівлі. Runtime Solana в цій сфері вже досяг високої оптимізації, але її основна стратегія планування все ще підпорядковується обмеженням за гранулярністю облікових записів.

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

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