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

На перехресті еволюції блокчейну синхронна композиція стала модним словом, оскільки здається, що вона пропонує рішення для об'єднання фрагментованих rollup layer 2s в мережі Ethereum. Цей підхід вирішує питання жахливого UX та DevEx, де навіть простий переказ між layer 2s може коштувати долар і займати до 7 днів.Участь Віталікау цих дебатах відзначається, що універсальна синхронізація не є обов’язковою умовою для вирішення цих питань. Ми погоджуємося, що ефективне виконання перекладу не обов’язково пов'язане з синхронізацією, і є реальні витрати на побудову та підтримку синхронної інфраструктури. Ми вважаємо, що це не є бінарний вибір між усім, що є синхронним, або асинхронним. Обидва можуть існувати на ад-гок основі, з ймовірним зсувом у бік останнього.

1. Асинхронний розкладний

У пошуку масштабованої продуктивності в технології блокчейну отримала значну увагу паралельне виконання окремих розумних контрактів. Зазвичай продуктивність кожного розумного контракту обмежується можливостями одного віртуального комп’ютера (EVM), навіть з появою багатоланцюжкових або Layer-2 систем. Паралельні віртуальні машини пропонують перспективне рішення, яке дозволяє виконувати транзакції одного розумного контракту одночасно, використовуючи більше ядер CPU для поліпшення продуктивності.

Parallel Relay-Execution Distributed Architecture (PREDA) - це розподілена, функціональна, спрямована на область та високорівнева модель програмування, призначена для вбудованого паралельного виконання загальних смарт-контрактів на розподілених багато-EVM блокчейн-системах. З системної точки зору PREDA робить паралельні EVM розкладними та асинхронними, забезпечуючи повну паралелизацію функції контракту та максимізацію паралельності набору транзакцій. Це забезпечує оптимальну продуктивність та масштабованість, оскільки всі екземпляри EVM можуть бути майже повністю використані.

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

Tx1= Транзакція 1

Tx2= Транзакція 2

Ми припускаємо,

Виконання Tx1 потребує зміни стану A, стану B, стану C

Виконання Tx2 потребує зміни стану A, стану D, стану E

Сучасні методи розпаралелювання для EVM¹, подібні до тих, що реалізовані Sei, Aptos і Sui, намагаються виконувати всі кроки в кожній транзакції синхронно. Уявіть, що масштаб однієї сцени транзакції в цих системах виконується в межах однієї висоти блоку, незалежно від природи розрізнених залежностей даних (тобто доступу до різних частин станів контракту). В результаті, якщо будь-який крок станів контракту, до яких здійснюється доступ, розподіляється або оновлюється між двома транзакціями, вони ідентифікуються як конфлікти читання-запису або запису-запису і не можуть бути виконані паралельно, що перешкоджає загальній пропускній здатності та масштабованості системи. Ця ситуація значно погіршується, коли активність у мережі раптово різко зростає.

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

2. Оцінка продуктивності

Історичні транзакції переказу токенів ETH відтворюються для оцінки Sei (V2), Aptos, Sui та PREDA за пропускною здатністю та масштабованістю. Зверніть увагу, що наша оцінка використовує реальні історичні транзакції переказу токенів ETH замість створення набору транзакцій між випадковими парами адрес. Випадкові транзакції приведуть до експериментального результату, який надмірно перевищить ефективність у реальних випадках, оскільки реальні транзакції включають адреси, які у будь-який спосіб пов'язані між собою, що вводить велику кількість залежностей даних.

Експериментальні налаштування такі:

Порівняння на рисунку 1 підкреслює необхідність прийняття моделі програмування PREDA для досягнення значних покращень продуктивності. PREDA демонструє 3,3-28,2 рази більшу продуктивність, ніж Aptos для реальних історичних трансферних транзакцій в мережі Ethereum.

Оскільки ці системи реалізовані різними мовами (включаючи Go, Rust і C++) і різними віртуальними машинами, ми оцінюємо масштабованість різних систем на основі відносного прискорення в порівнянні з базовим рівнем використання одного EVM, щоб виключити вплив різних системних реалізацій.

Рисунок 1. Абсолютні значення пропускної здатності в TPS еквівалентних розумних контрактів з передачі токенів, виконаних на Sei, Aptos, Sui та PREDA

Рисунок 2. Відносні прискорення для Aptos, Sui, Sei та PREDA порівняно з їх власними базовими значеннями

3. Модель програмування

Для полегшення розуміння PREDA для кожного, хто знайомий з паралельним EVM, існує два типових механізми паралелізації в сучасних паралельних блокчейн-системах EVM¹.

• Оптимістична паралелізація, включаючи Aptos, Sei (V2) та Monad, ігнорує залежності від стану між транзакціями, одночасно виконує та підтверджує транзакції, та відкочує транзакцію для повторного виконання у випадку конфлікту.
• Песимістична паралелізація, включаючи Solana (Sealevel), Sui та Sei (V1), перед виконанням перевіряє залежності від стану для кожної транзакції, аналізує їх залежності від стану та одночасно виконує лише ті транзакції, які не конфліктують.

Обидва методи використовують архітектуру Shared-everything та розглядають транзакцію як ціле в контролі конкурентності; всі кроки (наприклад, доступ до різних станів контрактів) не розкладні і повинні виконуватися синхронно. Модель PREDA пропонує @devteam_48518/crystality-the-parallel-evm-model-implementing-shared-nothing-architecture-8d82fc0a836a">Спільна архітектура, яка розриває залежності від стану та забезпечує, що різні екземпляри EVM ніколи не матимуть доступу до того ж самого шматка стану контракту, повністю уникнувши конфлікту запису.

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

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

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

4. Мова

Ми реалізували модель програмування PREDA як мову на кшталт Algo, подібну до C/C++ і Javascript. Наведена нижче спрощена функція передачі токенів як у мові Solidity, так і в мові PREDA.

Код Solidity на малюнку (a) містить стан контракту (баланси), що представляють баланси адрес, та функцію переказу для переказу вказаної кількості токенів від відправника транзакції (msg.sender) до отримувача (payee).

У реалізації PREDA, показаній на рис. (б), ключове слово @address визначає програмовані обсяги контрактів, де стани контракту, що належать змінній контракту (балансу), розбиваються за адресою, а розкидані та управляються EVM. Ключове слово реле позначає асинхронне функціональне реле.

Реалізація PREDA складається з трьох частин. У частині (1) ключове слово @address визначає баланси користувачів, надаючи точний, відокремлюваний опис стану. Баланс змінної області адреси має унікальний екземпляр для кожної адреси користувача. Екземпляри різних адрес користувачів доступні та підтримуються різними EVM, які не перетинаються. Функція передачі визначається в тій самій області адрес у частині (2), що викликається наданням адреси платника як цільової області під час ініціалізації транзакції переказу користувачем. У частині (3), щоб продовжити депозит одержувачу платежу після успішного зняття, ініціюється ретрансляція з адресою одержувача платежу як цільовою областю, додає кошти на баланс одержувача платежу та виконується EVM, який містить екземпляр балансу адреси одержувача платежу.

Процес виконання транзакції переказу токенів у PREDA

Вище наведена фігура показує хід виконання транзакції з переказу токенів у паралельній системі EVM PREDA. Боб ініціює транзакцію для виклику функції переказу, яка буде спрямована до EVM, що містить баланс Боба, і знімання здійснюється там. Після цього випускається релейна транзакція і спрямовується до EVM, що містить баланс Еліси, і здійснюється внесок. Паралелізація відбувається двома способами:

1. Між транзакціями, ініційованими користувачем: Оскільки стани, розділені за адресою, не перекриваються, транзакції, ініційовані користувачем, можуть виконуватися одночасно без конфліктів. Наприклад, у контракті на передачу токенів, який оновлює стан платника на адресу, різні транзакції, ініційовані користувачем, можуть бути паралельні між EVM.
2. З ретрансляційними транзакціями: У сценарії, де Боб переказує токени Еліс та Керол, можна одночасно виконувати ретрансляційну транзакцію для депозиту до Еліс (з переказу Боб до Еліс) разом з транзакцією, ініційованою користувачем, для зняття з Боба (переказ до Керол) та депозиту до Керол. Тільки за допомогою розкладання моделі PREDA можна виявити вбудовану паралелізацію в розумних контрактах для базової системи блокчейну, що дозволяє обробляти транзакції, ініційовані користувачем та ретрансляційні транзакції паралельно, сприяючи паралельному виконанню.

Наступне і далі

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

Загальність PREDA виходить за межі використання @address для розбиття станів контракту за адресою. Він дозволяє налаштовувати типи розділів з такими ключовими словами, як @тип, де тип може бути будь-яким базовим іменем типу Solidity, таким як @uint. Крім того, PREDA підтримує незапартіційні стани контрактів з @global, забезпечуючи, що кожен EVM зберігає консистентні значення для таких станів. Ця гнучкість у розподілі стану покращує пристосованість і ефективність моделі у різноманітних смарт-контрактах.

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

Відмова від відповідальності:

1. Ця стаття є перепостом з [ Середній]. Авторські права належать оригінальному автору, [PREDA Parallel VMs]. Якщо ви маєте будь-які зауваження щодо цього репосту, будь ласка, зв'яжітьсяgate Навчальна команда. Команда негайно вирішить ваші проблеми відповідно до відповідних процедур.
2. Відмова відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Команда Gate Learn переклала статтю на інші мови. Копіювання, поширення або плагіат перекладених статей заборонено, якщо не зазначено.