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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А віртуальна машина рівня паралельності безпосередньо вбудовує можливості паралельного виконання в логіку планування інструкцій на базі VM, прагнучи повністю подолати обмеження послідовного виконання EVM. MegaETH, як "супер віртуальний експеримент" в екосистемі Ethereum, намагається через повторний дизайн EVM забезпечити підтримку багатопоточності для паралельного виконання коду смарт-контрактів. Його основа через сегментне виконання, розділення станів, асинхронні виклики та інші механізми дозволяє кожному контракту незалежно працювати в різних виконавчих контекстах і завдяки паралельному синхронізаційному рівню забезпечити остаточну узгодженість. Найскладнішим у цьому підході є те, що він повинен бути повністю сумісним з існуючою семантикою поведінки EVM, водночас модифікуючи все середовище виконання та механізм Gas, щоб забезпечити плавний перехід екосистеми Solidity на паралельну платформу. Його виклики не тільки глибоко технологічні, але й стосуються питання прийнятності великих змін у протоколі з боку політичної структури Ethereum L1. Але якщо це вдасться, MegaETH має шанс стати "революцією багатоядерних процесорів" у сфері EVM.

Останній тип шляху, а саме, найбільш детальний і з найвищим технічним порогом - це паралелізм на рівні інструкцій. Його ідея походить з сучасного дизайну ЦП, де застосовують поза чергове виконання та конвеєризацію інструкцій. Ця парадигма вважає, що оскільки кожен смарт-контракт в кінцевому підсумку компілюється в байт-код інструкцій, то цілком можливо, як і при виконанні набору інструкцій x86, проводити аналіз розкладання та паралельну переробку для кожної операції. Команда Fuel вже на початковому етапі впровадила модель виконання з можливістю переробки інструкцій у своєму FuelVM, а в далекій перспективі, як тільки блокчейн-двигун реалізує прогнозоване виконання та динамічну переробку залежностей інструкцій, його паралельність досягне теоретичного максимуму. Цей підхід навіть може підняти співпрацю блокчейну з апаратним забезпеченням на абсолютно новий рівень, перетворивши ланцюг на справжній "децентралізований комп'ютер", а не просто "розподілений реєстр". Звичайно, цей шлях має