Паралельні обчислення в Web3: найкраще рішення для рідного масштабування?

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

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

• Виконання розширеної масштабованості: підвищення виконавчої здатності на місці, наприклад, паралельна обробка, GPU, багатоядерність
• Ізольоване розширення статусу: горизонтальне поділення статусу/Shard, наприклад, шардінг, UTXO, багато підмереж
• Оффчейн аутсорсинг розширення: виконання відбувається поза ланцюгом, наприклад, Rollup, Coprocessor, DA
• Декуплінгова розширювальна структура: модульна архітектура, спільна робота, наприклад, модульний ланцюг, спільний сортувальник, Rollup Mesh
• Асинхронне паралельне масштабування: Модель актора, ізоляція процесів, керування повідомленнями, наприклад, агенти, багатопоточна асинхронна ланцюгова обробка.

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

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

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

Зовнішня асинхронна паралельна модель, представлена системою агентів Actor, належить до іншої парадигми паралельних обчислень. Як міжланцюгова/асинхронна система повідомлень, кожен агент діє як незалежно працюючий «агентний процес», асинхронно обробляючи повідомлення в паралельному режимі, подіями, без необхідності синхронізації. Представлені проекти: AO, ICP, Cartesi та ін.

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

Два, EVM-сумісний паралельний посилений ланцюг: прорив у межах продуктивності через сумісність

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

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

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

Пайплайнінг: багатоступенева паралельна виконавча механіка

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

Асинхронне виконання: консенсус - асинхронне розділення виконання

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

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

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

Оптимістичне паралельне виконання:乐观并行执行

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

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

• Monad оптимістично виконує всі транзакції паралельно, припускаючи, що більшість транзакцій не мають стану конфлікту.
• Одночасно запустіть «детектор конфліктів», щоб контролювати, чи звертаються транзакції до одного й того ж стану.
• Якщо виявлено конфлікт, конфліктні транзакції будуть серіалізовані та повторно виконані, щоб забезпечити коректність стану.

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

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

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

Micro-VM архітектура: обліковий запис як потік

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

Залежність від стану DAG: механізм планування на основі графів залежностей

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

Асинхронне виконання та механізм зворотного виклику

MegaETH побудований на основі парадигми асинхронного програмування, аналогічно асинхронному обміну повідомленнями моделі актора, яка вирішує проблему традиційних послідовних викликів EVM. Виклики за контрактом є асинхронними, і при виклику контракту A -> B -> C кожен дзвінок є асинхронним без блокування очікування; Стек викликів розгортається в асинхронний графік дзвінків; Обробка транзакцій = обхід асинхронного графіка + дозвіл залежностей + паралельне планування.

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

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

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

Проекти паралельних обчислень, такі як Monad та MegaETH, в основному зосереджені на оптимізації пропускної спроможності, з метою підвищення TPS в ланцюзі як основною метою, реалізуючи паралельну обробку на рівні транзакцій або облікових записів за допомогою відкладеного виконання та мікровіртуальної архітектури. Pharos Network, як модульна, повноцінна паралельна L1 блокчейн-мережа, має основний механізм паралельних обчислень, відомий як «Rollup Mesh». Ця архітектура підтримує багатовіртуальне середовище завдяки співпраці між основною мережею та спеціальною обробною мережею, а також інтегрує такі передові технології, як нульові знання, середовище надійного виконання тощо.

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

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

2. Паралельне виконання двох віртуальних машин: Pharos підтримує дві віртуальні машини EVM та WASM, дозволяючи розробникам обирати відповідне середовище виконання відповідно до потреб. Ця архітектура з двома віртуальними машинами не лише підвищує гнучкість системи, але й покращує здатність обробки транзакцій завдяки паралельному виконанню.

3. Спеціалізовані мережі: SPNs є ключовими компонентами архітектури Pharos, подібно до модульних підмереж, спеціально призначених для обробки певних типів завдань або застосувань. Завдяки SPNs Pharos може здійснювати динамічний розподіл ресурсів та паралельну обробку завдань, що додатково підвищує масштабованість та продуктивність системи.

4. Модульна консенсусна модель і механізм повторного стейкингу: Pharos впроваджує гнучку консенсусну модель, підтримує різні моделі консенсусу та забезпечує безпечний обмін і інтеграцію ресурсів між основною мережею та SPNs за допомогою протоколу повторного стейкингу.

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

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

Крім Monad, MegaETH та Pharos, паралельне виконання