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

• Виконати підвищену масштабованість: Покращити можливості виконання на місці, такі як паралелізм, GPU та багатоядерність.
• Розширення ізольованої держави: горизонтальне розподілення стану / Шард, таке як шардінг, UTXO, багато підмереж
• Масштабування зовнішнього аутсорсингу: виконання поза ланцюгом, такі як Rollup, Копрограміст, DA
• Розширення декомпованої структури: модульна архітектура, спільна операція, такі як модульні ланцюги, спільні сортувальники, Rollup Mesh.
• Асинхронне паралельне масштабування: модель актора, ізоляція процесів, керування повідомленнями, такі як агенти, багатопотокові асинхронні ланцюги.

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

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

• Рівень облікового запису: представляє проект Solana
• Паралелізм на об'єктному рівні: представляє проект Sui
• Рівень транзакцій: представляє проекти Monad, Aptos
• Рівень виклику / MicroVM: представляє проект MegaETH
• Інструкційний рівень паралелізму: представляє проект GatlingX

Модель асинхронного паралельного оброблення поза ланцюгом, представлена системою Акторів (модель Агента/Акторів), належить до іншої парадигми паралельних обчислень. Як крос-ланцюгова/асинхронна система обміну повідомленнями (модель несинхронізованого блокування), кожен Актор працює як незалежно запущений "процес агента", асинхронно обмінюючись повідомленнями в паралельному режимі, керуючись подіями та без необхідності в синхронізованому плануванні. Серед відомих проектів можна згадати AO, ICP, Cartesi тощо.

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

2. Ланцюг з паралельним покращенням на основі EVM: подолання меж продуктивності через сумісність

Серійна архітектура обробки Ethereum розвивалася через кілька раундів спроб розширення, включаючи шардінг, Rollup та модульну архітектуру. Проте, вузьке місце пропускної здатності виконавчого шару досі не було принципово подолано. Тим часом, EVM та Solidity залишаються найбільш дружніми до розробників та екологічно потужними платформами для смарт-контрактів сьогодні. Тому ланцюги, посилені паралельною обробкою на базі EVM, стають важливим напрямком для наступного раунду еволюції масштабованості, балансуючи екологічну сумісність та підвищення продуктивності виконання. Monad та MegaETH є найрепрезентативнішими проектами в цьому напрямку, які відповідно будують архітектури паралельної обробки EVM, спрямовані на сценарії з високою паралельністю та високою пропускною здатністю, починаючи з затриманої обробки та декомпозиції стану.

Аналіз механізму паралельних обчислень Monad

Monad є високопродуктивним блокчейном рівня 1, переробленим для віртуальної машини Ethereum (EVM), що базується на основному паралельному концепті конвеєризації, з асинхронним виконанням на рівні консенсусу та оптимістичним паралельним виконанням на рівні виконання. Крім того, Monad вводить високопродуктивний BFT протокол (MonadBFT) та спеціалізовану систему бази даних (MonadDB) на рівнях консенсусу та зберігання, досягаючи оптимізації від початку до кінця.

Пайплайнинг: механізм паралельного виконання з багатоступеневим конвеєром
Пайплайнинг — це фундаментальна концепція паралельного виконання Monad. Його основна ідея полягає в розподілі процесу виконання блокчейну на кілька незалежних етапів і обробці цих етапів паралельно, формуючи тривимірну архітектуру конвеєра. Кожен етап виконується на незалежних потоках або ядрах, досягаючи паралельної обробки між блоками, що в кінцевому підсумку покращує пропускну здатність і знижує затримку. Ці етапи включають: пропозиція транзакції (Propose), досягнення консенсусу (Consensus), виконання транзакції (Execution) та підтвердження блоку (Commit).

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

Основний дизайн:

• Процес консенсусу (шар консенсусу) відповідає лише за впорядкування транзакцій і не виконує логіку контракту.
• Процес виконання (виконавчий шар) запускається асинхронно після завершення консенсусу.
• Після завершення консенсусу негайно розпочніть процес консенсусу для наступного блоку, не чекаючи закінчення виконання.

Оптимістичне паралельне виконання
Традиційний Ethereum використовує строгий послідовний модель для виконання транзакцій, щоб уникнути конфліктів стану. На відміну від цього, Monad використовує стратегію "оптимістичного паралельного виконання", що суттєво підвищує швидкість обробки транзакцій.

Механізм виконання:

• Monad буде оптимістично виконувати всі транзакції паралельно, припускаючи, що більшість транзакцій не мають конфліктів стану.
• Водночас запустіть "Детектор конфліктів", щоб контролювати, чи транзакції отримують доступ до одного й того ж стану (наприклад, конфлікти читання/запису).
• Якщо виявлено конфлікт, конфліктуючі транзакції будуть серіалізовані та повторно виконані для забезпечення коректності стану.

Monad вибирає сумісний шлях: вносячи якомога менше змін до правил EVM, досягаючи паралелізму, відстрочуючи запис стану та динамічно виявляючи конфлікти під час виконання, що нагадує версію Ethereum з поліпшеною продуктивністю. Його зрілість сприяє легкій міграції екосистеми EVM і слугує паралельним прискорювачем у світі EVM.

Аналіз механізму паралельних обчислень MegaETH

На відміну від позиціонування L1 Monad, MegaETH позиціонується як модульний високопродуктивний паралельний виконавчий шар, сумісний з EVM, який може служити незалежним L1 публічним ланцюгом або як шар підвищення виконання в Ethereum, або як модульний компонент. Його основна мета дизайну полягає в ізоляції та деконструкції логіки облікового запису, виконавчого середовища та стану в незалежно плановані мінімальні одиниці, щоб досягти високої паралельної виконуваності та низької затримки реагування в ланцюзі. Ключові інновації, запропоновані MegaETH, це: архітектура Micro-VM + DAG (орієнтований ациклічний граф залежностей стану) та модульний механізм синхронізації, які разом створюють паралельну виконувану систему, орієнтовану на "ланцюгове багатопотокове виконання."

Мікро-VM архітектура: Обліковий запис є потоком
MegaETH представляє модель виконання "одна мікро віртуальна машина (Micro-VM) на рахунок", яка розділяє середовище виконання на потоки та забезпечує найменшу одиницю ізоляції для паралельного планування. Ці ВМ спілкуються через асинхронні повідомлення замість синхронних викликів, що дозволяє великій кількості ВМ виконуватись незалежно та зберігатись незалежно, забезпечуючи природний паралелізм.

Даг залежності стану: механізм планування, що керується графами залежностей
MegaETH створив систему планування DAG на основі відносин доступу до стану облікового запису. Система підтримує глобальний граф залежностей у реальному часі, моделюючи, які облікові записи змінюються і які облікові записи читаються під час кожної транзакції як залежності. Неконфліктні транзакції можуть виконуватися паралельно, тоді як транзакції з залежностями будуть заплановані у порядку або відкладені відповідно до топологічної послідовності. Граф залежностей забезпечує узгодженість стану та неповторне записування під час процесу паралельного виконання.

Асинхронне виконання та механізм зворотного виклику
MegaETH побудовано на парадигмі асинхронного програмування, подібно до асинхронної передачі повідомлень Моделі Акторів, що вирішує проблеми традиційних серійних викликів EVM. Виклики контрактів є асинхронними (не рекурсивне виконання), і коли викликається контракт A -> B -> C, кожен виклик здійснюється асинхронно без блокування; стек викликів розширюється в асинхронний граф викликів (Call Graph); обробка транзакцій = проходження асинхронного графа + вирішення залежностей + паралельне планування.

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

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

Концепції дизайну Monad і MegaETH суттєво відрізняються від шардінгу: шардінг горизонтально розділяє блокчейн на кілька незалежних підланцюгів (шардів), кожен з яких відповідає за частину транзакцій і станів, зламує обмеження єдиного ланцюга для досягнення масштабованості на мережевому рівні; в той час як Monad і MegaETH підтримують цілісність єдиного ланцюга і досягають лише горизонтальної масштабованості на рівні виконання, оптимізуючи продуктивність через екстремальне паралельне виконання в межах єдиного ланцюга. Обидва представляють два напрямки в шляху масштабованості блокчейна: вертикальне посилення і горизонтальне розширення.

Проекти, такі як Monad та MegaETH, зосереджені на оптимізації пропускної здатності, основною метою якої є підвищення TPS в ланцюзі. Вони досягають паралельної обробки на рівні транзакцій або облікових записів за допомогою архітектур Deferred Execution та Micro-VM. Pharos Network, як модульна, повнофункціональна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, відомий як "Rollup Mesh". Ця архітектура підтримує багатовіртуальні середовища (EVM та Wasm) завдяки спільній роботі основної мережі та Спеціальних Обробних Мереж (SPN), інтегруючи передові технології, такі як Докази з Нульовим Знанням (ZK) та Надійні Виконавчі Середовища (TEE).

Аналіз механізму паралельних обчислень Rollup Mesh:

• Повний життєвий цикл асинхронного пайплайнингу: Pharos розділяє різні етапи транзакції (такі як консенсус, виконання, зберігання) і використовує асинхронний підхід до обробки, що дозволяє кожному етапу проходити незалежно і паралельно, тим самим покращуючи загальну ефективність обробки.
• Паралельне виконання в двох віртуальних машинах: Pharos підтримує два віртуальні середовища, EVM та WASM, що дозволяє розробникам вибрати відповідне середовище виконання відповідно до їхніх потреб. Ця архітектура з двома віртуальними машинами не лише підвищує гнучкість системи, але й покращує можливості обробки транзакцій через паралельне виконання.
• Спеціалізовані обробні мережі (SPN): SPN є ключовими компонентами архітектури Pharos, подібно до модульних підмереж, які спеціально розроблені для виконання конкретних типів завдань або додатків. За допомогою SPN Pharos може досягти динамічного розподілу ресурсів та паралельної обробки завдань, що додатково підвищує масштабованість і продуктивність системи.
• Модульний консенсус та повторне ставлення: Pharos впроваджує гнучкий механізм консенсусу, який підтримує кілька моделей консенсусу (таких як PBFT, PoS, PoA) та досягає безпечного обміну та інтеграції ресурсів між основною мережею та SPN через протокол повторного ставлення.

Крім того, Pharos перебудував модель виконання з основного механізму зберігання, використовуючи багатоверсійні дерева Меркла, кодування дельти, версійне адресування та технології ADS Pushdown, запустивши рідний блокчейн високопродуктивний механізм зберігання Pharos Store, досягнувши високої пропускної здатності, низької затримки та потужних перевіряємих можливостей обробки в ланцюгу.

В цілому, архітектура Rollup Mesh від Pharos досягає високоефективних можливостей паралельних обчислень завдяки модульному дизайну та асинхронному механізму обробки. Pharos виступає в ролі координатора планування для крос-Rollup паралелізму, а не як оптимізатор виконання для "он-лінійного паралелізму", а скоріше виконує гетерогенні кастомізовані завдання через SPN.

Окрім паралельної архітектури виконання Monad, MegaETH та Pharos, ми також спостерігаємо, що на ринку є деякі проекти, які досліджують шляхи застосування прискорення за допомогою GPU в паралельних обчисленнях EVM, що є важливим доповненням та передовим експериментом для паралельної екосистеми EVM. Серед них Reddio та GatlingX є двома представницькими напрямками:

• Reddio є високопродуктивною платформою, яка поєднує zkRollup та архітектуру паралельного виконання на базі GPU. Її суть полягає в реконструкції процесу виконання EVM, досягаючи нативної паралелізації на рівні виконання через багатопоточне планування, асинхронне зберігання стану та прискорене виконання пакетів транзакцій за допомогою GPU. Вона належить до паралельної градації на рівні транзакцій + операцій (багатопотокове виконання opcodes). Її дизайн впроваджує багатопотокове пакетне виконання, асинхронне завантаження стану та паралельну обробку логіки транзакцій за допомогою GPU (CUDA-сумісний паралельний EVM). Як і Monad / MegaETH, Reddio також зосереджується на паралельній обробці на рівні виконання, але відрізняється реконструкцією виконавчого механізму за допомогою паралельної архітектури GPU, спеціально розробленої для високої пропускної здатності та обчислювально інтенсивних сценаріїв (таких як AI-інференція). SDK вже запущено, надаючи модуль виконання, що може бути інтегровано.
• GatlingX стверджує, що є "GPU-EVM" і пропонує більш радикальну архітектуру, яка намагається мігрувати модель "послідовного виконання на рівні інструкцій" традиційної EVM в середовище паралельного виконання, яке підтримується GPU. Його основний механізм полягає в динамічній компіляції байт-коду EVM у паралельні завдання CUDA, виконуючи потоки інструкцій через багатоядерний GPU, тим самим ламаючи послідовне вузьке місце EVM на найнижчому рівні. Він належить до паралельної гранулярності на рівні інструкцій (Instruction-Level Parallelism, ILP). У порівнянні з "гранулярністю на рівні транзакцій/рахунків" Monad / MegaETH, паралельний механізм GatlingX ближчий до шляхів оптимізації на рівні інструкцій, більше нагадуючи підґрунтову реконструкцію віртуального машинного двигуна. Наразі він знаходиться на концептуальному етапі, випущено білу книгу та архітектурні ескізи, але SDK або основна мережа ще немає.

Artela пропонує концепцію диференційованого паралельного дизайну. Впроваджуючи архітектуру EVM++ з віртуальною машиною WebAssembly (WASM), вона дозволяє розробникам динамічно додавати та виконувати розширення в блокчейні, підтримуючи сумісність з EVM, використовуючи модель програмування Aspect. Вона бере гранулярність викликів контрактів (Функція / Розширення) як мінімальну паралельну одиницю, підтримуючи ін'єкцію модулів Розширення (схожих на "плагінне посередництво") під час виконання контрактів EVM, досягаючи логічного розділення, асинхронних викликів та паралельного виконання на рівні модулів. Вона більше зосереджується на композиційності та модульній архітектурі виконувального шару. Ця концепція пропонує нові ідеї для майбутніх складних мульти-модульних застосунків.

3. Нативна паралельна архітектура ланцюга: реконструкція виконавчої сутності віртуальної машини

Модель виконання EVM Ethereum з моменту свого дизайну прийняла архітектуру «загальний порядок транзакцій + послідовне виконання» в одному потоці, що спрямоване на забезпечення детермінізму та узгодженості змін стану на всіх вузлах мережі. Однак ця архітектура має вроджені обмеження продуктивності, які обмежують пропускну здатність системи та масштабованість. На відміну від цього, рідні архітектури паралельних обчислень, такі як Solana (SVM), MoveVM (Sui, Aptos) та Sei v2, побудовані на Cosmos SDK, спроектовані для паралельного виконання з нуля, пропонуючи такі переваги:

• Модель стану природно розділяє: Solana впроваджує механізм оголошення блокування рахунків, MoveVM вводить модель володіння об'єктами, а Sei v2 класифікує на основі типів транзакцій для досягнення статичного визначення конфліктів, підтримуючи конкурентне планування на рівні транзакцій.
• Оптимізація паралелізму віртуальної машини: двигун Sealevel Solana нatively підтримує багатопоточне виконання; MoveVM може виконувати статичний аналіз графа паралелізму; Sei v2 інтегрує багатопоточний механізм відповідності та паралельний модуль ВМ.

Звичайно, цей тип рідної паралельної ланцюга також стикається з проблемами екологічної сумісності. Не-EVM архітектури часто вимагають зовсім нових мов програмування (таких як Move, Rust) та інструментів, що створює певні витрати на міграцію для розробників; крім того, розробники також повинні оволодіти низкою нових концепцій, таких як моделі доступу до стану, обмеження паралельності та життєвий цикл об'єктів, що все це підвищує поріг для розуміння та накладає вищі вимоги до парадигм розробки.

3.1 Принцип Солани та паралельний двигун Sealevel SVM

Модель виконання Sealevel у Solana є механізмом паралельного планування на основі облікових записів, який є основним двигуном, що використовується Solana для досягнення паралельного виконання транзакцій в ланцюгу. Завдяки механізму "декларація облікових записів + статичне планування + багатопотокове виконання" він реалізує високу продуктивність паралелізму на рівні смарт-контрактів. Sealevel є першою моделлю виконання в області блокчейну, яка успішно реалізувала паралельне планування в ланцюзі в виробничому середовищі, а її архітектурні ідеї вплинули на багато наступних проектів паралельних обчислень, слугуючи еталоном для високопродуктивного паралельного дизайну Layer 1.

Основний механізм:

1. Явна декларація доступу до рахунку (Списки доступу до рахунків): Кожна транзакція повинна оголошувати рахунки, що беруть участь (читання/запис) під час подання, що дозволяє системі визначити, чи є конфлікти стану між транзакціями.

2. Виявлення конфліктів та планування багатопотоковості

• Якщо множина рахунків, до яких звертаються дві транзакції, не має перетинів → їх можна виконувати паралельно;
• Конфлікт існує → Виконувати послідовно в порядку залежності;
• Планувальник розподіляє транзакції між різними потоками на основі графа залежностей.

3. Незалежний контекст виконання (Контекст виклику програми): Кожен виклик контракту працює в ізольованому контексті, без спільного стеку, що перешкоджає перехресному втручанню.

Sealevel - це движок планування паралельного виконання Solana, в той час як SVM - це середовище виконання смарт-контрактів, побудоване на Sealevel (використовуючи віртуальну машину BPF). Разом вони становлять технічну основу високопродуктивної паралельної системи виконання Solana.

Eclipse — це проект, який розгортає Solana VM на модульних ланцюгах (таких як Ethereum L2 або Celestia), використовуючи паралельний виконавчий механізм Solana як шар виконання Rollup. Eclipse є одним з перших проектів, які пропонують відокремити шар виконання Solana (Sealevel + SVM) від основної мережі Solana і мігрувати його до модульної архітектури, модулюючи «суперсильну модель паралельного виконання» Solana у вигляді Execution Layer-as-a-Service. Тому Eclipse також підпадає під категорію паралельних обчислень.

Підхід Neon є іншим; він впроваджує EVM для роботи в середовищі SVM / Sealevel. Він створює шар виконання, сумісний з EVM, що дозволяє розробникам використовувати Solidity для розробки контрактів, які працюють у середовищі SVM, але планування виконання використовує SVM + Sealevel. Neon більше схиляється до категорії Модульного Блокчейну, а не акцентує увагу на інноваціях у паралельних обчисленнях.

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

3.2 Архітектура MoveVM: Ресурсно-об'єктно орієнтована

MoveVM — це віртуальна машина смарт-контрактів, розроблена для безпеки ресурсів на ланцюзі та паралельного виконання. Її основна мова, Move, була спочатку розроблена компанією Meta (раніше Facebook) для проєкту Libra, підкреслюючи концепцію "ресурс як об'єкт". Усі стани на ланцюзі існують як об'єкти з чіткою власністю та життєвим циклом. Це дозволяє MoveVM аналізувати, чи є конфлікти станів між транзакціями на етапі компіляції, що забезпечує статичне паралельне планування на рівні об'єктів, і вона широко використовується в рідних паралельних публічних ланцюгах, таких як Sui та Aptos.

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

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

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

Механізм виконання Block-STM Aptos
Aptos є високо продуктивним блокчейном першого рівня, заснованим на мові Move, чия здатність до паралельного виконання в основному походить з самої розробленої системи Block-STM (блокова програмна транзакційна пам'ять). На відміну від Sui, яка схильна приймати стратегію "статичної паралельності на етапі компіляції", Block-STM належить до механізму динамічного планування "оптимістична конкурентність у реальному часі + відкат конфліктів", придатного для обробки наборів транзакцій з складними залежностями.

Block-STM розділяє виконання транзакцій блоку на три фази:

• Спекулятивне виконання: всі транзакції вважаються безконфліктними перед виконанням, і система планує транзакції на кількох потоках для паралельного виконання, записуючи стани рахунків, до яких вони звертаються (набір читання / набір запису).
• Фаза виявлення конфліктів та валідації: Система перевіряє результати виконання: якщо дві транзакції мають конфлікт читання-запису (наприклад, Tx1 читає стан, записаний Tx2), одна з них буде скасована.
• Операція скасування конфліктної транзакції (Фаза повторної спроби): Конфліктні транзакції будуть перенесені для виконання, поки їх залежності не будуть вирішені, врешті-решт формуючи дійсну та детерміновану послідовність комітів стану для всіх транзакцій.

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

Solana – це фракція інженерного планування, більше схожа на "ядро операційної системи". Вона підходить для чітких меж стану та контрольованої високообхідної торгівлі, втілюючи стиль апаратного інженера, і розроблена для роботи з ланцюгом, як з апаратним забезпеченням (паралельне виконання апаратного класу). Aptos – це фракція системної стійкості до збоїв, більше схожа на "движок конкурентності бази даних". Вона підходить для контрактів з сильною прив'язкою стану та складними ланцюгами викликів. Sui – це фракція безпеки під час компіляції, більше схожа на "платформу смарт-мов, орієнтовану на ресурси". Вона підходить для застосувань в межах ланцюга з розділенням активів та чіткими комбінаціями. Aptos і Sui призначені для роботи з ланцюгом як інженери мов програмування, забезпечуючи безпеку ресурсів на рівні програмного забезпечення. Усі троє представляють різні філософські шляхи для технічної реалізації паралельних обчислень у Web3.

3.3 Тип паралельного масштабування Cosmos SDK

Sei V2 - це високопродуктивна публічна торгова мережа, побудована на Cosmos SDK. Її паралельні можливості в основному відображаються в двох аспектах: багатопотоковому механізмі відповідності та оптимізації паралельного виконання на рівні віртуальної машини, що спрямоване на обслуговування сценаріїв торгівлі на ланцюгу з високою частотою та низькою затримкою, таких як DEX з книжками ордерів та інфраструктура обміну на ланцюгу.

Основний паралельний механізм:

• Паралельний двигун зіставлення: Sei V2 впроваджує багатопотоковий виконувальний шлях у логіці зіставлення замовлень, відокремлюючи книгу замовлень від логіки зіставлення на рівні потоків, що дозволяє обробляти завдання зіставлення між кількома ринками (торговими парами) паралельно, уникаючи тим самим вузьких місць у однопоточному режимі.
• Оптимізація паралелізму на рівні віртуальної машини: Sei V2 створила середовище виконання CosmWasm з можливостями паралельного виконання, що дозволяє деяким викликам контрактів виконуватись паралельно за умови, що їхні стани не конфліктують, і досягати вищого контролю пропускної здатності у поєднанні з механізмом класифікації типів транзакцій.
• Паралельний консенсус у поєднанні з плануванням виконувального шару: Представляємо так званий механізм консенсусу "Твін-Турбо", щоб зміцнити розділення пропускної здатності між шаром консенсусу та виконувальним шаром, покращуючи загальну ефективність обробки блоків.

3.4 Перезапуск моделі UTXO

Fuel є високопродуктивним шаром виконання, розробленим на основі модульної архітектури Ethereum, з його основним паралельним механізмом, що походить від вдосконаленої моделі UTXO (Unspent Transaction Output). На відміну від облікової моделі Ethereum, Fuel використовує структуру UTXO для представлення активів і станів, що за своєю суттю має ізоляцію стану, що полегшує визначення, які транзакції можуть бути безпечно виконані паралельно. Додатково, Fuel представляє самостійно розроблену мову смарт-контрактів під назвою Sway (схожа на Rust) і поєднує її з інструментами статичного аналізу для виявлення конфліктів вхідних даних перед виконанням транзакцій, досягаючи таким чином ефективного та безпечного паралельного планування на рівні транзакцій. Він слугує альтернативним шаром виконання EVM, який балансує продуктивність і модульність.

4. Модель актора: нова парадигма для конкурентного виконання агентів

Модель актора є паралельною парадигмою виконання, яка використовує агентні процеси (Агент або Процес) як одиниці, на відміну від традиційних синхронних обчислень з глобальним станом в блокчейні (сценарії, такі як "паралельні обчислення в блокчейні", такі як Solana/Sui/Monad), оскільки підкреслює, що кожен агент має свій власний незалежний стан і поведінку, спілкуючись і плануючи через асинхронні повідомлення. У цій архітектурі системи на блокчейні можуть одночасно виконувати велику кількість декупльованих процесів, забезпечуючи високу масштабованість та асинхронну стійкість до збоїв. Представницькі проекти включають AO (Arweave AO), ICP (Internet Computer) та Cartesi, які сприяють еволюції блокчейну від двигуна виконання до "операційної системи на блокчейні", надаючи рідну інфраструктуру для AI-агентів, багатозадачних взаємодій і складної логічної оркестрації.

Хоча дизайн Моделі Акторів має певні поверхневі схожості з Шардінгом (такі як паралелізм, ізоляція стану та асинхронна обробка), вони в основному представляють абсолютно різні технічні шляхи та системні філософії. Модель Акторів підкреслює "багатопроцесорні асинхронні обчислення", де кожен агент (Актор) працює незалежно та підтримує свій власний стан, взаємодіючи через підхід, орієнтований на повідомлення; тоді як Шардінг є механізмом "горизонтального розподілу стану та консенсусу", що ділить всю блокчейн-мережу на кілька незалежних підсистем (Шарди), які обробляють транзакції. Модель Акторів більше схожа на "розподілену агентську операційну систему" у світі Web3, тоді як Шардінг є структурним рішенням для масштабування можливостей обробки транзакцій в ончейн-мережі. Обидва досягають паралелізму, але їх початкові точки, цілі та архітектури виконання різні.

4.1 AO (Arweave), суперпаралельний комп'ютер над шаром зберігання

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

Основні архітектурні особливості:

• Архітектура процесів: Кожен агент називається Процесом, має незалежний стан, незалежний планувальник і логіку виконання.
• Немає структури блокчейну: AO не є ланцюгом, а децентралізованим шаром зберігання на основі Arweave + багатокористувацьким двигуном виконання на основі повідомлень.
• Асинхронна система планування повідомлень: Процеси спілкуються через повідомлення, приймаючи безблокувальну асинхронну модель роботи, яка за своєю суттю підтримує паралельне масштабування;
• Постійне зберігання станів: Усі стани агентів, записи повідомлень та інструкції постійно фіксуються на Arweave, забезпечуючи повну перевірку та децентралізовану прозорість.
• Агент-натив: Підходить для розгортання складних багатоступеневих завдань (таких як AI-агенти, контролери протоколу DePIN, автоматизовані оркестратори завдань тощо), може створити "он-チェйн AI копротесор."

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

4.2 ICP (Internet Computer), повноцінна платформа хостингу Web3

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

Основні архітектурні особливості:

• Архітектура контейнерів (контейнери як розумні агенти): Кожен контейнер є розумним агентом, що працює на Wasm VM, має незалежний стан, код та можливості асинхронного планування;
• Система розподіленого консенсусу підмереж: Вся мережа складається з кількох підмереж, кожна з яких підтримує групу каністр і досягає консенсусу за допомогою механізму підпису BLS.
• Асинхронна модель виклику: Контейнери спілкуються між собою через асинхронне повідомлення, підтримуючи неблокуюче виконання та маючи вроджену паралельність;
• Ончейн веб-хостинг: Підтримує смарт-контракти для прямого хостингу фронт-енд сторінок з рідним DNS-мапінгом, що робить його першою блокчейн-платформою, яка підтримує прямий доступ браузера до dApp.
• Комплексні функції системи: Оснащена ончейн-гарячими оновленнями, автентифікацією особистості, розподіленою випадковістю, таймерами та іншими системними API, підходить для складного розгортання ончейн-сервісів.

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

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

V. Резюме та перспективи

Виходячи з різниць в архітектурі віртуальних машин та мовних системах, рішення для паралельних обчислень у блокчейні можна приблизно розділити на дві категорії: ланцюги з паралельним посиленням на основі EVM та ланцюги з рідною паралельною архітектурою (не EVM).

Перший досягає вищої пропускної здатності та можливостей паралельної обробки завдяки глибокій оптимізації виконавчого шару, при цьому зберігаючи сумісність з екосистемою EVM/Solidity. Він підходить для сценаріїв, де є бажання успадкувати активи Ethereum та інструменти розробки, одночасно досягаючи проривів у продуктивності. Представницькі проекти включають:

• Monad: Досягає оптимістичної моделі паралельного виконання, сумісної з EVM, через затримані записи та виявлення конфліктів під час виконання, створюючи граф залежностей та плануючи виконання з багатопоточністю після досягнення консенсусу.
• MegaETH: Абстрагує кожен обліковий запис/контракт як незалежну мікро-ВМ, досягаючи високого ступеня декомпозиції паралельного планування на рівні облікових записів на основі асинхронного обміну повідомленнями та графів залежностей стану.
• Pharos: Створення архітектури Rollup Mesh, яка співпрацює з модулем SPN через асинхронні конвеєри для досягнення паралельної обробки на системному рівні між процесами.
• Reddio: Приймає архітектуру zkRollup + GPU, зосереджуючи увагу на прискоренні процесу офлайн-верифікації zkEVM шляхом масового створення SNARK, підвищуючи пропускну здатність верифікації.

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

• Solana (SVM система): Базується на деклараціях доступу до облікових записів та статичному графікові конфліктів, що представляє модель паралельного виконання на рівні облікового запису;
• Sui / Aptos (MoveVM система): Заснована на моделі об'єктів ресурсу та системі типів, вона підтримує статичний аналіз під час компіляції та досягає об'єктного паралелізму.
• Sei V2 (Cosmos SDK Route): Впроваджує багатопотоковий механізм відповідності та оптимізацію конкурентності віртуальної машини в архітектурі Cosmos, що підходить для застосувань високочастотної торгівлі.
• Паливо (UTXO + архітектура Sway): досягнення паралелізму на рівні транзакцій через статичний аналіз наборів вхідних UTXO, в поєднанні з модульним виконувальним шаром і спеціалізованою мовою смарт-контрактів Sway.

Крім того, Модель Акторів, як більш широка паралельна система, створює парадигму виконання в ланцюгу "незалежна робота багатьох агентів + співпраця на основі повідомлень" через асинхронний механізм планування процесів на основі Wasm або кастомних ВМ. Представницькі проекти включають:

• AO (Arweave AO): Агента, який працює на основі постійного зберігання, що будує асинхронну мікроядерну систему на блокчейні.
• ICP (Інтернет-Комп'ютер): Досягає асинхронного високого масштабування виконання через координацію підмереж з контейнеризованим агентом (Canister) як найменшою одиницею.
• Cartesi: Впроваджує операційну систему Linux як зовнішнє середовище для обчислень, надаючи шлях верифікації в ланцюзі для надійних результатів обчислень, що підходить для складних або ресурсомістких сценаріїв застосування.

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

З більш широкої перспективи масштабування, шардінг і роллап (L2) зосереджуються на досягненні горизонтального масштабування системи через розподіл стану або виконання поза ланцюгом, тоді як паралельні обчислювальні ланцюги (наприклад, Monad, Sui, Solana) та системи, орієнтовані на акторів (наприклад, AO, ICP), безпосередньо реконструюють модель виконання для досягнення рідного паралелізму на рівні ланцюга або системи. Перші підвищують пропускну здатність на ланцюзі за допомогою методів, таких як багатопотокові віртуальні машини, об'єктні моделі та аналіз конфліктів транзакцій; останні використовують процеси/агенти як основні одиниці та приймають методи виконання, керовані повідомленнями та асинхронні, щоб забезпечити паралельну роботу кількох агентів. У порівнянні, шардінг і роллап більше схожі на 'розподіл навантаження між кількома ланцюгами' або 'виконання поза ланцюгом', тоді як паралельні ланцюги та модель актора орієнтовані на 'вивільнення потенціалу продуктивності від самого механізму виконання', що відображає більш глибокий напрямок архітектурної еволюції.

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

Варто зазначити, що більшість нативних паралельних архітектурних ланцюгів зараз перейшли до етапу запуску основної мережі. Хоча загальна екосистема розробників все ще важко порівнювати з системою Solidity на основі EVM, проекти, представлені Solana та Sui, з їхньою архітектурою виконання високої продуктивності та поступовим процвітанням екологічних застосувань, стали основними публічними ланцюгами, які привертають значну увагу ринку.

На відміну від цього, хоча екосистема Ethereum Rollup (L2) увійшла в стадію "багато ланцюгів, що поспішають до запуску" або навіть "переповненість", в даний час основні сумісні з EVM паралельні підсилювальні ланцюги все ще загалом знаходяться на стадії тестування і ще не проходили фактичну перевірку в середовищі основної мережі. Їхні можливості масштабування та стабільність системи ще потребують подальшого вивчення. Щодо того, чи можуть ці проекти суттєво покращити продуктивність EVM та сприяти еволюції екосистеми без жертвування сумісністю, або чи вони натомість погіршать подальшу диференціацію ліквідності та ресурсів розвитку на Ethereum, залишається питанням.

Заява:

1. Ця стаття відтворена з [TechFlow] Авторське право належить оригінальному автору [0xjacobzhao та ChatGPT 4o] Якщо у вас є заперечення до повторного друку, будь ласка, зв'яжіться Команда Gate LearnКоманда обробить це якомога швидше відповідно до відповідних процедур.
2. Застереження: Думки та погляди, висловлені в цій статті, є виключно думками автора і не є інвестиційною порадою.
3. Інші мовні версії статті перекладені командою Gate Learn, якщо не вказано інше.ГейтЗа жодних обставин не можна копіювати, поширювати або плагіатити перекладені статті.