Ціна AO

$AO схожий на $ICP без венчурних капіталістів з 39-кратним розривом в оцінці. Минулого місяця ми зробили довгий звіт про це на @dyorcryptoapp.

Автори: 0xjacobzhao та ChatGPT 4o «Безпека», «децентралізація» та «масштабованість» блокчейну «Трилема блокчейну» розкривають суттєвий компроміс у дизайні блокчейн-систем, тобто для блокчейн-проектів важко досягти «надзвичайної безпеки, кожен може брати участь, і високошвидкісної обробки» одночасно. У відповідь на вічну тему «масштабованості», основні рішення для масштабування блокчейну на ринку розділені за парадигмами, серед яких: Масштабування з покращеним виконанням: покращує можливості виконання, такі як паралелізм, графічний процесор та багатоядерність, на місці Масштабування з ізоляцією стану: горизонтально розділяє стан/сегменти, такі як сегменти, UTXO та кілька підмереж Масштабування офчейн-аутсорсингу: перенесення виконання поза ланцюгом, наприклад, роллапи, співпроцесори та DA Розширення пропускної спроможності структурного розв'язання: Архітектура є модульною та працює разом, наприклад, ланцюги модулів, спільні секвенсори та зведені сітки Асинхронне паралельне масштабування: модель актора, ізоляція процесів, керована повідомленнями, такі як агенти та багатопотокові асинхронні ланцюги Рішення для масштабування блокчейну включає: паралельні обчислення в ланцюжку, зведення, шардинг, модуль DA, модульну структуру, систему акторів, стиснення zk proof, архітектуру без стану тощо, що охоплює кілька рівнів виконання, стану, даних і структури, і є повною системою масштабування «багаторівневої співпраці та комбінації модулів». Ця стаття присвячена методам масштабування, які є основою паралельних обчислень. Внутрішньоланцюговий паралелізм, який фокусується на паралельному виконанні внутрішньоблокових транзакцій/інструкцій. Відповідно до паралельного механізму, його методи масштабування можна розділити на п'ять категорій, кожна з яких представляє різне прагнення до продуктивності, модель розробки та філософію архітектури, а паралельна деталізація стає все тоншою і тоншою, інтенсивність паралелізму стає все вищою і вищою, складність планування стає все вищою і вищою, а складність програмування та складність реалізації також стають все вищими і вищими. На рівні облікового запису: представляє проект Solana Паралелізм на рівні об'єкта: представляє проект Sui Рівень транзакції: Представляє проект Monad, Aptos Call-level / MicroVM: представляє проект MegaETH Рівень навчання: Представляє проект GatlingX Офчейн асинхронна паралельна модель, представлена моделлю Actor / Actor, належить до іншої парадигми паралельних обчислень, як крос-чейн/асинхронна система повідомлень (модель неблокової синхронізації), кожен агент працює незалежно як «агентський процес», асинхронні повідомлення в паралельному режимі, керовані подіями, без синхронного планування, репрезентативні проекти, такі як AO, ICP, Cartesi тощо. Добре відома схема масштабування зведення або шарду належить до механізму паралелізму на системному рівні, а не до внутрішньоланцюгових паралельних обчислень. Вони досягають масштабування шляхом «паралельного запуску кількох ланцюгів/доменів виконання», а не збільшення паралелізму в межах одного блоку/віртуальної машини. Цей тип масштабного рішення не є предметом цієї статті, але ми все одно будемо використовувати його для порівняння подібностей та відмінностей в архітектурних концепціях. 2. Ланцюжок паралельного вдосконалення EVM: подолання межі продуктивності в сумісності З моменту розробки архітектури послідовної обробки Ethereum вона зазнала кілька раундів спроб масштабування, таких як шардинг, ролап і модульна архітектура, але вузьке місце пропускної здатності виконавчого рівня все ще не було принципово порушено. Але в той же час EVM і Solidity все ще залишаються платформами смарт-контрактів з найбільшою базою розробників і екологічним потенціалом. Таким чином, ланцюжок паралельного вдосконалення EVM стає важливим напрямком для нового витка масштабування та еволюції як ключовий шлях, що враховує екологічну сумісність та підвищення продуктивності виконання. Monad і MegaETH є найбільш представницькими проектами в цьому напрямку, починаючи від відкладеного виконання і декомпозиції станів відповідно, для побудови архітектури паралельної обробки EVM для сценаріїв з високою паралелізмом і високою пропускною здатністю. Аналіз паралельних обчислювальних механізмів Monad Monad — це високопродуктивний блокчейн рівня 1, перероблений для віртуальної машини Ethereum (EVM), заснований на базовій паралельній концепції конвеєра, з асинхронним виконанням на рівні консенсусу та оптимістичним паралельним виконанням на рівні виконання. Крім того, на рівнях консенсусу та зберігання Monad представила високопродуктивний протокол BFT (MonadBFT) та виділену систему баз даних (MonadDB) відповідно для досягнення наскрізної оптимізації. Pipelining: механізм паралельного виконання для багатоступінчастих трубопроводів Конвеєр є основною концепцією паралельного виконання Monad, і його основна ідея полягає в тому, щоб розділити процес виконання блокчейну на кілька незалежних етапів і обробляти ці етапи паралельно, щоб сформувати тривимірну архітектуру конвеєра, кожен етап виконується на незалежних потоках або ядрах для досягнення одночасної обробки між блоками та в кінцевому підсумку досягнення ефекту покращення пропускної здатності та зменшення затримки. Ці етапи включають: Пропозиція, Консенсус, Виконання та Коміт. Асинхронне виконання: Консенсус - Виконує асинхронне розв'язування У традиційних ланцюгах консенсус транзакцій і виконання зазвичай є синхронними процесами, і ця послідовна модель серйозно обмежує масштабування продуктивності. Monad реалізує рівень консенсусу асинхронний, рівень виконання асинхронний, а зберігання асинхронне через «асинхронне виконання». Значно скоротити час блоку та затримку підтвердження, роблячи систему більш стійкою, обробку більш сегментованою, а також використання ресурсів. Основна конструкція: Процес консенсусу (рівень консенсусу) відповідає лише за впорядкування транзакцій і не виконує логіку контракту. Процес виконання (рівень виконання) запускається асинхронно після завершення досягнення консенсусу. Після того, як консенсус буде завершено, він негайно увійде в процес консенсусу наступного блоку, не чекаючи завершення виконання. Оптимістичне паралельне виконання: Оптимістичне паралельне виконання Традиційний Ethereum використовує строго послідовну модель для виконання транзакцій, щоб уникнути конфліктів станів. 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: Повний життєвий цикл асинхронної конвеєрної обробки: Pharos відокремлює різні етапи транзакції (наприклад, консенсус, виконання, зберігання) і використовує асинхронну обробку, щоб кожен етап міг виконуватися незалежно і паралельно, тим самим підвищуючи загальну ефективність обробки. Паралельне виконання двох віртуальних машин: Pharos підтримує як середовища віртуальних машин EVM, так і WASM, що дозволяє розробникам вибрати правильне середовище виконання для своїх потреб. Ця архітектура з двома віртуальними машинами не тільки підвищує гнучкість системи, але й збільшує обробку транзакцій за рахунок паралельного виконання. Спеціальні мережі обробки (SPN): SPN є ключовими компонентами в архітектурі Pharos, подібно до модульних підмереж, призначених для обробки конкретних типів завдань або додатків. За допомогою SPN Pharos забезпечує динамічний розподіл ресурсів і паралельну обробку завдань, ще більше підвищуючи масштабованість і продуктивність системи. Модульний консенсус і стейкінг: 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. В даний час SDK запущений, і передбачений інтегрований модуль виконання Називаючи себе «GPU-EVM», GatlingX пропонує більш радикальну архітектуру, яка намагається перенести модель «послідовного виконання на рівні інструкцій» традиційних віртуальних машин 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 від Aptos Aptos — це високопродуктивний блокчейн рівня 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 Sei V2 — це високопродуктивний транзакційний публічний ланцюг, створений на основі Cosmos SDK, і його здатність паралелізму в основному відображається у двох аспектах: багатопотоковому механізмі узгодження (Parallel Matching Engine) та оптимізації паралельного виконання рівня віртуальної машини, спрямованому на обслуговування високочастотних сценаріїв транзакцій у ланцюжку з низькою затримкою, таких як DEX книги замовлень, інфраструктура обміну в ланцюжку тощо. Основний паралельний механізм: Механізм паралельного зіставлення: SEI V2 вводить багатопотоковий шлях виконання в логіку відповідності ордерів, розділяючи відкладену книгу ордерів і логіку відповідності на рівні потоків, щоб завдання зіставлення між кількома торговими парами можна було обробляти паралельно та уникати однопотокових вузьких місць. Оптимізація паралелізму на рівні віртуальної машини: Sei V2 створює середовище виконання CosmWasm з можливостями одночасного виконання, що дозволяє деяким викликам контрактів працювати паралельно без конфліктів станів, і співпрацює з механізмом класифікації типів транзакцій для досягнення більш високого контролю пропускної здатності. Паралельний консенсус і планування на рівні виконання: Так званий механізм консенсусу "Twin-Turbo" вводиться для посилення пропускної здатності та розв'язки між рівнем консенсусу та рівнем виконання, а також для підвищення загальної ефективності обробки блоків. 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, які керують еволюцією блокчейну від механізму виконання до «операційної системи в ланцюжку», забезпечуючи рідну інфраструктуру для агентів штучного інтелекту, багатозадачної взаємодії та складної логічної оркестрації. У той час як дизайн моделі актора схожий на шардінг з точки зору поверхневих характеристик (наприклад, паралелізму, ізоляції станів і асинхронної обробки), ці два по суті представляють абсолютно різні технічні шляхи і філософію системи. Модель актора наголошує на «багатопроцесних асинхронних обчисленнях», де кожен агент працює незалежно, підтримує стан незалежно та взаємодіє за допомогою повідомлень. Шардинг, з іншого боку, — це механізм «горизонтального шардингу стану та консенсусу», який ділить весь блокчейн на кілька підсистем (шардів), які обробляють транзакції незалежно один від одного. 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) безпосередньо реконструюють модель виконання і досягають нативного паралелізму в ланцюжку або на системному рівні. Перший покращує внутрішньоланцюгову пропускну здатність за рахунок багатопотокових віртуальних машин, об'єктних моделей, аналізу конфліктів транзакцій тощо; Останній бере процес/агент як базову одиницю та використовує керовані повідомленнями та асинхронні режими виконання для досягнення одночасної роботи кількох агентів. На противагу цьому, шардинг і ролапи більше схожі на «розподіл навантаження на кілька ланцюгів» або «аутсорсинг поза ланцюгом», тоді як модель паралельного ланцюга та актора «розкриває потенціал продуктивності від самого механізму виконання», відображаючи більш ґрунтовну архітектурну еволюцію. Порівняння паралельних обчислень та архітектури шардингу та масштабування зведення: порівняння шляхів масштабування, орієнтованого на акторів Слід зазначити, що більшість ланцюжків нативної паралельної архітектури вступили в стадію запуску основної мережі, хоча загальну екосистему розробників все ще складно порівнювати з системою Solidity системи EVM, але проекти, представлені Solana і Sui, з їх високопродуктивною архітектурою виконання і поступовим процвітанням екологічних додатків, стали основними публічними ланцюгами, яким ринок приділяє велику увагу. На противагу цьому, хоча екосистема Ethereum Rollup (L2) вступила в стадію «10 000 ланцюгів одночасно» або навіть «надлишку потужності», поточний основний ланцюжок паралельного вдосконалення EVM все ще в цілому знаходиться на стадії тестової мережі і ще не був перевірений фактичним середовищем основної мережі, а його здатність масштабування та стабільність системи все ще потребують подальшого тестування. Залишається з'ясувати, чи зможуть ці проєкти значно покращити продуктивність EVM і здійснити екологічний стрибок без шкоди для сумісності, чи вони зможуть ще більше диференціювати ліквідність Ethereum і ресурси розробки.

Автор: 0xjacobzhao та ChatGPT 4o «Безпека», «децентралізація» та «масштабованість» блокчейну «Трилема блокчейну» розкривають суттєвий компроміс у дизайні блокчейн-систем, тобто для блокчейн-проектів важко досягти «надзвичайної безпеки, кожен може брати участь, і високошвидкісної обробки» одночасно. У відповідь на вічну тему «масштабованості», основні рішення для масштабування блокчейну на ринку розділені за парадигмами, серед яких: Масштабування з покращеним виконанням: покращує можливості виконання, такі як паралелізм, графічний процесор та багатоядерність, на місці Масштабування з ізоляцією стану: горизонтально розділяє стан/сегменти, такі як сегменти, UTXO та кілька підмереж Масштабування офчейн-аутсорсингу: перенесення виконання поза ланцюгом, наприклад, роллапи, співпроцесори та DA Розширення пропускної спроможності структурного розв'язання: Архітектура є модульною та працює разом, наприклад, ланцюги модулів, спільні секвенсори та зведені сітки Асинхронне паралельне масштабування: модель актора, ізоляція процесів, керована повідомленнями, такі як агенти та багатопотокові асинхронні ланцюги Рішення для масштабування блокчейну включає: паралельні обчислення в ланцюжку, зведення, шардинг, модуль DA, модульну структуру, систему акторів, стиснення zk proof, архітектуру без стану тощо, що охоплює кілька рівнів виконання, стану, даних і структури, і є повною системою масштабування «багаторівневої співпраці та комбінації модулів». Ця стаття присвячена методам масштабування, які є основою паралельних обчислень. Внутрішньоланцюговий паралелізм, який фокусується на паралельному виконанні внутрішньоблокових транзакцій/інструкцій. Відповідно до паралельного механізму, його методи масштабування можна розділити на п'ять категорій, кожна з яких представляє різне прагнення до продуктивності, модель розробки та філософію архітектури, а паралельна деталізація стає все тоншою і тоншою, інтенсивність паралелізму стає все вищою і вищою, складність планування стає все вищою і вищою, а складність програмування та складність реалізації також стають все вищими і вищими. На рівні облікового запису: представляє проект Solana Паралелізм на рівні об'єкта: представляє проект Sui Рівень транзакції: Представляє проект Monad, Aptos Call-level / MicroVM: представляє проект MegaETH Рівень навчання: Представляє проект GatlingX Офчейн асинхронна паралельна модель, представлена моделлю Actor / Actor, належить до іншої парадигми паралельних обчислень, як крос-чейн/асинхронна система повідомлень (модель неблокової синхронізації), кожен агент працює незалежно як «агентський процес», асинхронні повідомлення в паралельному режимі, керовані подіями, без синхронного планування, репрезентативні проекти, такі як AO, ICP, Cartesi тощо. Добре відома схема масштабування зведення або шарду належить до механізму паралелізму на системному рівні, а не до внутрішньоланцюгових паралельних обчислень. Вони досягають масштабування шляхом «паралельного запуску кількох ланцюгів/доменів виконання», а не збільшення паралелізму в межах одного блоку/віртуальної машини. Цей тип масштабного рішення не є предметом цієї статті, але ми все одно будемо використовувати його для порівняння подібностей та відмінностей в архітектурних концепціях. 2. Ланцюжок паралельного вдосконалення EVM: подолання межі продуктивності в сумісності З моменту розробки архітектури послідовної обробки Ethereum вона зазнала кілька раундів спроб масштабування, таких як шардинг, ролап і модульна архітектура, але вузьке місце пропускної здатності виконавчого рівня все ще не було принципово порушено. Але в той же час EVM і Solidity все ще залишаються платформами смарт-контрактів з найбільшою базою розробників і екологічним потенціалом. Таким чином, ланцюжок паралельного вдосконалення EVM стає важливим напрямком для нового витка масштабування та еволюції як ключовий шлях, що враховує екологічну сумісність та підвищення продуктивності виконання. Monad і MegaETH є найбільш представницькими проектами в цьому напрямку, починаючи від відкладеного виконання і декомпозиції станів відповідно, для побудови архітектури паралельної обробки EVM для сценаріїв з високою паралелізмом і високою пропускною здатністю. Аналіз паралельних обчислювальних механізмів Monad Monad — це високопродуктивний блокчейн рівня 1, перероблений для віртуальної машини Ethereum (EVM), заснований на базовій паралельній концепції конвеєра, з асинхронним виконанням на рівні консенсусу та оптимістичним паралельним виконанням на рівні виконання. Крім того, на рівнях консенсусу та зберігання Monad представила високопродуктивний протокол BFT (MonadBFT) та виділену систему баз даних (MonadDB) відповідно для досягнення наскрізної оптимізації. Pipelining: механізм паралельного виконання для багатоступінчастих трубопроводів Конвеєр є основною концепцією паралельного виконання Monad, і його основна ідея полягає в тому, щоб розділити процес виконання блокчейну на кілька незалежних етапів і обробляти ці етапи паралельно, щоб сформувати тривимірну архітектуру конвеєра, кожен етап виконується на незалежних потоках або ядрах для досягнення одночасної обробки між блоками та в кінцевому підсумку досягнення ефекту покращення пропускної здатності та зменшення затримки. Ці етапи включають: Пропозиція, Консенсус, Виконання та Коміт. Асинхронне виконання: Консенсус - Виконує асинхронне розв'язування У традиційних ланцюгах консенсус транзакцій і виконання зазвичай є синхронними процесами, і ця послідовна модель серйозно обмежує масштабування продуктивності. Monad реалізує рівень консенсусу асинхронний, рівень виконання асинхронний, а зберігання асинхронне через «асинхронне виконання». Значно скоротити час блоку та затримку підтвердження, роблячи систему більш стійкою, обробку більш сегментованою, а також використання ресурсів. Основна конструкція: Процес консенсусу (рівень консенсусу) відповідає лише за впорядкування транзакцій і не виконує логіку контракту. Процес виконання (рівень виконання) запускається асинхронно після завершення досягнення консенсусу. Після того, як консенсус буде завершено, він негайно увійде в процес консенсусу наступного блоку, не чекаючи завершення виконання. Оптимістичне паралельне виконання: Оптимістичне паралельне виконання Традиційний Ethereum використовує строго послідовну модель для виконання транзакцій, щоб уникнути конфліктів станів. 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: Повний життєвий цикл асинхронної конвеєрної обробки: Pharos відокремлює різні етапи транзакції (наприклад, консенсус, виконання, зберігання) і використовує асинхронну обробку, щоб кожен етап міг виконуватися незалежно і паралельно, тим самим підвищуючи загальну ефективність обробки. Паралельне виконання двох віртуальних машин: Pharos підтримує як середовища віртуальних машин EVM, так і WASM, що дозволяє розробникам вибрати правильне середовище виконання для своїх потреб. Ця архітектура з двома віртуальними машинами не тільки підвищує гнучкість системи, але й збільшує обробку транзакцій за рахунок паралельного виконання. Спеціальні мережі обробки (SPN): SPN є ключовими компонентами в архітектурі Pharos, подібно до модульних підмереж, призначених для обробки конкретних типів завдань або додатків. За допомогою SPN Pharos забезпечує динамічний розподіл ресурсів і паралельну обробку завдань, ще більше підвищуючи масштабованість і продуктивність системи. Модульний консенсус і стейкінг: 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. В даний час SDK запущений, і передбачений інтегрований модуль виконання Називаючи себе «GPU-EVM», GatlingX пропонує більш радикальну архітектуру, яка намагається перенести модель «послідовного виконання на рівні інструкцій» традиційних віртуальних машин 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 від Aptos Aptos — це високопродуктивний блокчейн рівня 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 Sei V2 — це високопродуктивний транзакційний публічний ланцюг, створений на основі Cosmos SDK, і його здатність паралелізму в основному відображається у двох аспектах: багатопотоковому механізмі узгодження (Parallel Matching Engine) та оптимізації паралельного виконання рівня віртуальної машини, спрямованому на обслуговування високочастотних сценаріїв транзакцій у ланцюжку з низькою затримкою, таких як DEX книги замовлень, інфраструктура обміну в ланцюжку тощо. Основний паралельний механізм: Механізм паралельного зіставлення: SEI V2 вводить багатопотоковий шлях виконання в логіку відповідності ордерів, розділяючи відкладену книгу ордерів і логіку відповідності на рівні потоків, щоб завдання зіставлення між кількома торговими парами можна було обробляти паралельно та уникати однопотокових вузьких місць. Оптимізація паралелізму на рівні віртуальної машини: Sei V2 створює середовище виконання CosmWasm з можливостями одночасного виконання, що дозволяє деяким викликам контрактів працювати паралельно без конфліктів станів, і співпрацює з механізмом класифікації типів транзакцій для досягнення більш високого контролю пропускної здатності. Паралельний консенсус і планування на рівні виконання: Так званий механізм консенсусу "Twin-Turbo" вводиться для посилення пропускної здатності та розв'язки між рівнем консенсусу та рівнем виконання, а також для підвищення загальної ефективності обробки блоків. 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, які керують еволюцією блокчейну від механізму виконання до «операційної системи в ланцюжку», забезпечуючи рідну інфраструктуру для агентів штучного інтелекту, багатозадачної взаємодії та складної логічної оркестрації. У той час як дизайн моделі актора схожий на шардінг з точки зору поверхневих характеристик (наприклад, паралелізму, ізоляції станів і асинхронної обробки), ці два по суті представляють абсолютно різні технічні шляхи і філософію системи. Модель актора наголошує на «багатопроцесних асинхронних обчисленнях», де кожен агент працює незалежно, підтримує стан незалежно та взаємодіє за допомогою повідомлень. Шардинг, з іншого боку, — це механізм «горизонтального шардингу стану та консенсусу», який ділить весь блокчейн на кілька підсистем (шардів), які обробляють транзакції незалежно один від одного. 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) безпосередньо реконструюють модель виконання і досягають нативного паралелізму в ланцюжку або на системному рівні. Перший покращує внутрішньоланцюгову пропускну здатність за рахунок багатопотокових віртуальних машин, об'єктних моделей, аналізу конфліктів транзакцій тощо; Останній бере процес/агент як базову одиницю та використовує керовані повідомленнями та асинхронні режими виконання для досягнення одночасної роботи кількох агентів. На противагу цьому, шардинг і ролапи більше схожі на «розподіл навантаження на кілька ланцюгів» або «аутсорсинг поза ланцюгом», тоді як модель паралельного ланцюга та актора «розкриває потенціал продуктивності від самого механізму виконання», відображаючи більш ґрунтовну архітектурну еволюцію. Порівняння паралельних обчислень та архітектури шардингу та масштабування зведення: порівняння шляхів масштабування, орієнтованого на акторів Слід зазначити, що більшість ланцюжків нативної паралельної архітектури вступили в стадію запуску основної мережі, хоча загальну екосистему розробників все ще складно порівнювати з системою Solidity системи EVM, але проекти, представлені Solana і Sui, з їх високопродуктивною архітектурою виконання і поступовим процвітанням екологічних додатків, стали основними публічними ланцюгами, яким ринок приділяє велику увагу. На противагу цьому, хоча екосистема Ethereum Rollup (L2) вступила в стадію «10 000 ланцюгів одночасно» або навіть «надлишку потужності», поточний основний ланцюжок паралельного вдосконалення EVM все ще в цілому знаходиться на стадії тестової мережі і ще не був перевірений фактичним середовищем основної мережі, а його здатність масштабування та стабільність системи все ще потребують подальшого тестування. Залишається з'ясувати, чи зможуть ці проєкти значно покращити продуктивність EVM і здійснити екологічний стрибок без шкоди для сумісності, чи вони зможуть ще більше диференціювати ліквідність Ethereum і ресурси розробки.

Люблю бачити, як зростають зустрічі спільноти Permabites!

The Daily Degen - П'ятниця, 18 квітня 2025 р. Тренди, Pegs, TGE's, Tech, Macro, Videos, + Нові проекти! Звертайтеся до згаданих проектів і тікерів: $DOLO, $ATOM, $sUSD, $BTC, $OL, $WZRD, $AERGO, $T, $EVER, $AO, @GammaSwapLabs, @TradeNeutral, @Lighter_xyz, @jigsawdefi, @PeerlessAI, @VertigoDex, @clickerxyz, @getoro_xyz І звертайтеся до акаунтів gigabrain, які згадуються з >10 тисячами підписників (обов'язково підпишіться на них!): @leviathan_news, @robbiepetersen_, @0xlykt, @AresLabs_xyz, @CryptoISFreedom І, будь ласка, RT/etc для підтримки! Посилання в наступному твіті 👇