Web3 Parallel Computing Track Panorama: найкраще рішення для нативного масштабування?

Автор: 0xjacobzhao та ChatGPT 4o«

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

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

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

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

  • Account-level: представляє проект
  • Object-level: представляє проект Sui
  • Transaction-level: представляє проект Monad, Aptos
  • Call-level / MicroVM : MegaETH на рівні інструкцій
  :
  • GatlingX

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

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

  

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

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

  Monad's Parallel Computing

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

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

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

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

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

  Дизайн ядра:

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

  Оптимістичне паралельне виконання: оптимістичне паралельне виконанняТрадиційний

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

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

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

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

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

  відрізняється від позиціонування Monad на L1, і MegaETH позиціонується як EVM-сумісний модульний високопродуктивний рівень паралельного виконання, який можна використовувати як незалежний публічний ланцюг L1, як рівень покращення виконання або модульний компонент на Ethereum. Його основна мета дизайну полягає в тому, щоб деконструювати логіку облікового запису, середовище виконання та ізоляцію станів у найменшу одиницю, яку можна незалежно запланувати для досягнення виконання з високим паралелізмом і можливості реагування з низькою затримкою в ланцюжку. Ключове нововведення, запропоноване MegaETH, полягає в тому, що архітектура Micro-VM + State Dependency DAG (directioned and acyclic state dependency graph) і модульний механізм синхронізації спільно будують паралельну систему виконання для «внутрішньоланцюгового потоку».

  Архітектура мікро-ВМ: облікові записи є потоками

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

  State Dependency DAG: механізм

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

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

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

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

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

  

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

  Проєкти паралельних обчислень, такі як Monad і MegaETH, в основному зосереджені на шляху оптимізації пропускної здатності, з основною метою покращення TPS у ланцюжку та досягнення паралельної обробки на рівні транзакцій або на рівні облікового запису за допомогою відкладеного виконання та архітектури мікро-віртуальних машин. Pharos Network - це модульна, повностекова паралельна блокчейн-мережа L1, і її основна система паралельних обчислень називається "Rollup Mesh". Ця архітектура підтримує середовища з кількома віртуальними машинами (EVM і Wasm) завдяки синергії основної мережі та спеціальних мереж обробки (SPN) та інтегрує передові технології, такі як докази з нульовим розголошенням (ZK) та довірені середовища виконання (TEE).

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

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

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

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

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

  • Reddio — це високопродуктивна платформа, яка поєднує в собі архітектуру паралельного виконання zkRollup та GPU, і її суть полягає в реконструкції процесу виконання EVM та реалізації рідного розпаралелювання виконавчого рівня за допомогою багатопотокового планування, асинхронного зберігання станів та прискореного виконанням пакетів транзакцій за допомогою GPU. Паралельна деталізація на рівні транзакції + рівень операції (багатопотокове виконання, код операції). Він призначений для впровадження багатопотокового пакетного виконання, асинхронного завантаження стану та логіки транзакцій паралельної обробки GPU (CUDA-Compatible Parallel EVM). Як і Monad / MegaETH, Reddio також зосереджується на паралельній обробці на рівні виконання, з тією різницею, що механізм виконання реконструюється за допомогою паралельної архітектури GPU, розробленої для сценаріїв з високою пропускною здатністю та інтенсивними обчисленнями, таких як висновок AI. GatlingX,
  • яка називає себе «GPU-EVM», пропонує більш радикальну архітектуру, яка намагається перенести модель «послідовного виконання на рівні команд» традиційних віртуальних машин EVM у власне для GPU паралельне середовище виконання. Основний механізм полягає в динамічній компіляції байт-коду EVM у паралельні завдання CUDA та виконанні потоку команд через багатоядерний графічний процесор, щоб розірвати послідовне вузьке місце EVM на найнижчому рівні. Паралельна деталізація, яка належить до паралелізму на рівні інструкцій (ILP). У порівнянні з паралельною деталізацією «рівень транзакцій / на рівні облікового запису» Monad / MegaETH, механізм паралелізму GatlingX відноситься до шляху оптимізації на рівні інструкцій, який ближче до базового рефакторингу движка віртуальної машини. В даний час він знаходиться на стадії концепції, з опублікованими технічним документом та архітектурним ескізом, але ще немає SDK або основної мережі.

  Artela пропонує диференційовану, паралельну концепцію дизайну. Завдяки впровадженню віртуальної машини WebAssembly (WASM) з архітектурою EVM++ розробникам дозволено динамічно додавати та виконувати розширення в ланцюжку за допомогою моделі програмування Aspect зі збереженням сумісності з EVM. Він використовує деталізацію виклику контракту (Function / Extension) як мінімальну паралельну одиницю та підтримує впровадження модулів Extension (подібно до "pluggable middleware") під час виконання контракту EVM, щоб досягти логічного розв'язання, асинхронного виклику та паралельного виконання на рівні модуля. Більше уваги приділено компонуванню та модульній архітектурі виконавчого шару. Концепція передбачає нові ідеї для складних багатомодульних додатків у майбутньому.

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

  ,

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

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

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

  3.1 Принцип паралельного двигуна Sealevel Solana і SVM

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

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

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

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

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

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

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

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

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

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

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

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

  Модель власності на об'єкт SuiМожливості

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

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

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

  Механізм виконання Block-STM від AptosAptos

  — це високопродуктивний блокчейн рівня 1, заснований на мові Move, і його можливість паралельного виконання в основному походить від самостійно розробленої структури Block-STM (Block-level Software Transactional Memory). На відміну від стратегії Sui про «статичний паралелізм під час компіляції», Block-STM належить до динамічного механізму планування «оптимістичний паралелізм при виконанні + відкат конфлікту», який підходить для роботи з наборами транзакцій зі складними залежностями.

  Block-STM ділить виконання транзакції блоку на три етапи:

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

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

  

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

  3.3 Cosmos SDK Parallel Scaling

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

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

  1. Механізм паралельного зіставлення: SEI V2 вводить багатопотоковий шлях виконання в логіку узгодження ордерів, розділяючи відкладену книгу ордерів і логіку відповідності на рівні потоків, щоб завдання зіставлення між кількома торговими парами можна обробляти паралельно та уникнути однопотокового вузького місця.
  2. Оптимізація паралелізму на рівні віртуальної машини: Sei V2 створює середовище виконання CosmWasm з можливостями одночасного виконання, що дозволяє деяким викликам контрактів працювати паралельно без конфліктів станів, і співпрацює з механізмом класифікації типів транзакцій для досягнення більш високого контролю пропускної здатності.
  3. Паралельний консенсус і планування на рівні виконання: Так званий механізм консенсусу "Twin-Turbo" вводиться для посилення пропускної здатності та розв'язки між рівнем консенсусу та рівнем виконання, а також для підвищення загальної ефективності обробки блоків.

  3.4 UTXO Model Rereform Fuel —

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

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

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

  У той час як дизайн моделі актора схожий на шардінг з точки зору поверхневих характеристик (наприклад, паралелізму, ізоляції станів і асинхронної обробки), ці два по суті представляють абсолютно різні технічні шляхи і філософію системи. Модель актора наголошує на «багатопроцесних асинхронних обчисленнях», де кожен агент працює незалежно, підтримує стан незалежно та взаємодіє за допомогою повідомлень. Шардинг, з іншого боку, — це механізм «горизонтального шардингу стану та консенсусу», який ділить весь блокчейн на кілька підсистем (шардів), які обробляють транзакції незалежно один від одного. Actor Models більше схожі на «операційну систему розподіленого агента» у світі Web3, тоді як шардинг — це структурне рішення для масштабування для можливостей обробки транзакцій у ланцюжку. Обидва досягають паралелізму, але мають різні відправні точки, цілі та архітектуру виконання.

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

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

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

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

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

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

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

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

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

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

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

  

  5. Резюме та перспективиВиходячи

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

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

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

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

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

  Крім того, як більш узагальнена паралельна система, Actor Model будує парадигму виконання в ланцюжку «незалежна робота кількох агентів + співпраця, керована повідомленнями» за допомогою асинхронного механізму планування процесів на основі Wasm або користувальницьких віртуальних машин. Репрезентативні проекти включають:

  • AO (Arweave AO): Побудова системи асинхронного мікроядра в ланцюжку на основі постійного середовища виконання агента, керованого сховищем;
  • ICP (Internet Computer): використовує контейнеризований агент (Canister) як найменшу одиницю для досягнення асинхронного та високомасштабованого виконання за допомогою координації підмережі.
  • Cartesi: представляє операційну систему Linux як позаланцюгове обчислювальне середовище, щоб забезпечити шлях перевірки в ланцюжку для надійних результатів обчислень, що підходить для складних або ресурсомістких сценаріїв додатків.

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

  

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

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

  ,

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

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