Що таке паралельне виконання
З листопада 2023 року до січня 2024-го вартість токена SEI збільшилася в 5,7 раза. Однією з причин такого зростання міг стати революційний підхід до обробки транзакцій, що використовується у Sei, — паралельне виконання.
Паралельне виконання — це одночасне оброблення кількох транзакцій або операцій замість того, щоб обробляти їх почергово. Такий підхід нагадує оплату товарів у продуктовому магазині, де замість однієї каси працюють декілька. Це дає змогу обслуговувати більшу кількість відвідувачів, зменшуючи час очікування кожного з них.
Паралельне виконання використовується для одночасної обробки непов'язаних транзакцій, тобто подій, які не впливають одна на одну. Наприклад, якщо двоє користувачів торгують токенами на різних торгових платформах, їхні транзакції можуть оброблятися одночасно. Але якщо вони торгують на одному майданчику — цей процес відбувається послідовно.
Складність реалізації паралельного виконання полягає у визначенні незалежних транзакцій. Це передбачає розуміння того, як кожна операція впливає на стан блокчейну. За наявності великої кількості взаємопов’язаних застосунків визначити такі транзакції стає важче.
Прикладами блокчейнів, які використовують модель доступу до стану, є Solana, Sei v1 і Sui, а прикладами оптимістичної моделі — Aptos, Monad і Sei v2.
Кожна транзакція вказує ту частину блокчейну, до якої планує отримати доступ. Ця вимога включена до моделі виконання транзакцій Sealevel, яка разом з алгоритмом консенсусу Proof of History (PoH) забезпечує паралельне виконання у блокчейні Solana.
Для забезпечення паралельного виконання транзакцій Sei використовує налаштовуваність Cosmos, поліпшуючи можливості стандартного Cosmos SDK. Особливості Sei: консенсус Twin-Turbo та механізм розпаралелювання.
Інтелектуальне розподілення блоків. Уявіть ситуацію, де Анна та Алекс мають власні домашні бібліотеки. Коли Анна надсилає Алексу книжку для читання, здебільшого така сама книжка вже є в його бібліотеці. Цей підхід є трудомістким та обтяжливим.
Валідатори аналогічно відправляють блоки, що містять інформацію про транзакції. Оскільки учасники консенсусу постійно обмінюються операційними даними, більшість із них вже має необхідну інформацію про транзакції. Це означає, що валідатори втрачають час, очікуючи отримання транзакцій, які вже є в їхньому мемпулі.
Аналогічно валідатори надсилають пропозицію, яка містить лише хеш транзакцій. Коли інші учасники мережі отримують таку пропозицію, вони використовують транзакції з мемпулу, щоб відновити блок у своєму стані блокчейну (подібно до перевірки бібліотеки на наявність книжок).
Оптимістична обробка блоків. Після того як блок був запропонований і поширений серед валідаторів, вони надсилають один одному повідомлення prevote та precommit. Такий підхід допомагає погодити саме той блок, який вони хочуть додати у блокчейн.
Після precommit валідатори перевіряють кожну транзакцію всередині блоку. Однак за великої кількості даних цей етап потребує багато часу та ресурсів.
DeliverTx. Традиційно під час DeliverTx транзакції обробляються послідовно. Sei змінює цей підхід, забезпечуючи паралельне виконання.
Щоб уникнути невизначеності (сценаріїв, за яких результат певних процесів не бажаний для одночасного виконання), Sei фільтрує транзакції на ті, які можуть виконуватися паралельно, і ті, що відбуваються послідовно. Для цього він сегментує операції за типом і даними, які вони виконують.
EndBlock. Sei надає послуги у фінансовому секторі, тому транзакції всередині блокчейну можна поділити на купівлю та продаж, а платформи для їх виконання — на ринки.
На етапі EndBlock Sei об'єднує ордери на купівлю та продаж активу. Замість послідовної обробки цих замовлень Sei фільтрує незалежні транзакції та перевіряє їх паралельно наприкінці блоку.
Ордери вважаються незалежними, якщо вони не впливають на той самий ринок всередині одного блоку.
Лише друге оновлення вплинуло на паралельне виконання транзакцій у Sei. Тому замість вивчення кожного з трьох поліпшень сконцентруємося тільки на оптимістичній паралелізації.
Цей процес повторюється, доки не будуть розв'язані усі конфлікти. Тільки тоді Sei зможе продовжити обробляти наступні транзакції.
Aptos. Aptos використовує принцип оптимістичного виконання. Однак, на відміну від Sei v2, цей блокчейн автоматично визначає залежність транзакцій у разі конфліктів. Водночас не вимагає від транзакцій вказувати, на яку частину стану блокчейну вони впливають.
Monad. Орієнтований на продуктивність блокчейн першого рівня, який сумісний з Ethereum. Аналогічно до Aptos, Monad використовує принцип оптимістичного виконання, припускаючи, що транзакції не пов'язані між собою, та розглядає залежності в міру їх виникнення.
Паралельне виконання транзакцій: одна каса проти трьох. Джерело: medium.com
Традиційно блокчейн обробляє транзакції послідовно. Проте такий підхід призводить до затримок, а також обмежує масштабованість мережі. Подібно до того, як покупці чекають у черзі на касу, щоб оплатити свої товари, так учасники мережі очікують, доки їхня транзакція буде оброблена з мемпулу.
Паралельне виконання використовується для одночасної обробки непов'язаних транзакцій, тобто подій, які не впливають одна на одну. Наприклад, якщо двоє користувачів торгують токенами на різних торгових платформах, їхні транзакції можуть оброблятися одночасно. Але якщо вони торгують на одному майданчику — цей процес відбувається послідовно.
Складність реалізації паралельного виконання полягає у визначенні незалежних транзакцій. Це передбачає розуміння того, як кожна операція впливає на стан блокчейну. За наявності великої кількості взаємопов’язаних застосунків визначити такі транзакції стає важче.
Моделі паралельного виконання
Більшість блокчейнів з паралельним виконанням ґрунтується на таких моделях:
- Модель доступу до стану — підхід, за якого транзакції, що мають доступ до тієї чи іншої частини стану блокчейну, визначаються заздалегідь. Це дає змогу розрізняти незалежні та залежні операції.
- Оптимістична модель — підхід, який передбачає, що всі транзакції у блокчейні є незалежними. Коригування залежностей відбувається вже після їх виявлення.
Прикладами блокчейнів, які використовують модель доступу до стану, є Solana, Sei v1 і Sui, а прикладами оптимістичної моделі — Aptos, Monad і Sei v2.
Незважаючи на те, що головний принцип паралельного виконання — це одночасна обробка транзакцій, існує декілька способів реалізації цього підходу. Ми не занурюватимемося в деталі роботи кожного, натомість розповімо лише про найефективніші з них на прикладі проєктів, які їх використовують.
Solana
Solana — це перший блокчейн, який використав паралельний метод обробки транзакцій. Його підхід полягає у визначенні залежностей між даними та доступом операцій до тих чи інших частин блокчейну.
Уявіть систему зберігання даних, в якій кожна транзакція запитує доступ до певного файлу:
- якщо запити не переплітаються, транзакції обробляються незалежно одна від одної;
- якщо транзакції вимагають доступ до одного файлу, вони потребують координації.
Кожна транзакція вказує ту частину блокчейну, до якої планує отримати доступ. Ця вимога включена до моделі виконання транзакцій Sealevel, яка разом з алгоритмом консенсусу Proof of History (PoH) забезпечує паралельне виконання у блокчейні Solana.
Sei
Sei — це блокчейн першого рівня, побудований на базі Cosmos SDK (комплект для розробки ПЗ) та платформи смартконтрактів CosmWasm. Він використовує делеговану архітектуру, розподіляючи функції блокчейну за трьома рівнями:
- Рівень програм — виконання логіки застосунків та обробка транзакцій.
- Рівень консенсусу — дозволяє всім учасникам мережі дійти згоди щодо стану блокчейну.
- Мережевий рівень — відповідає за розподіл транзакцій всередині блокчейну.
Для забезпечення паралельного виконання транзакцій Sei використовує налаштовуваність Cosmos, поліпшуючи можливості стандартного Cosmos SDK. Особливості Sei: консенсус Twin-Turbo та механізм розпаралелювання.
Консенсус Twin-Turbo
Консенсус Twin-Turbo визначається двома елементами: інтелектуальним розподіленням та оптимістичною обробкою блоків. Ці функції працюють спільно, спрощуючи виконання транзакцій і підтвердження блоків.
Інтелектуальне розподілення блоків. Уявіть ситуацію, де Анна та Алекс мають власні домашні бібліотеки. Коли Анна надсилає Алексу книжку для читання, здебільшого така сама книжка вже є в його бібліотеці. Цей підхід є трудомістким та обтяжливим.
Валідатори аналогічно відправляють блоки, що містять інформацію про транзакції. Оскільки учасники консенсусу постійно обмінюються операційними даними, більшість із них вже має необхідну інформацію про транзакції. Це означає, що валідатори втрачають час, очікуючи отримання транзакцій, які вже є в їхньому мемпулі.
Пропозиція блоків без інтелектуального розподілення. Джерело: twitter.com
Тепер Анна надсилає Алексу лише назву книжки, яку читає. Хлопець перевіряє, чи має її у своїй бібліотеці, та, якщо не має, робить запит до Анни та отримує примірник твору.
Аналогічно валідатори надсилають пропозицію, яка містить лише хеш транзакцій. Коли інші учасники мережі отримують таку пропозицію, вони використовують транзакції з мемпулу, щоб відновити блок у своєму стані блокчейну (подібно до перевірки бібліотеки на наявність книжок).
Інтелектуальне розподілення блоків. Джерело: twitter.com
Якщо валідатори не мають інформації про всі транзакції у своєму локальному мемпулі, вони очікують публікації вмісту блоку.
Оптимістична обробка блоків. Після того як блок був запропонований і поширений серед валідаторів, вони надсилають один одному повідомлення prevote та precommit. Такий підхід допомагає погодити саме той блок, який вони хочуть додати у блокчейн.
Після precommit валідатори перевіряють кожну транзакцію всередині блоку. Однак за великої кількості даних цей етап потребує багато часу та ресурсів.
Звичайна обробка блоків проти оптимістичної. Джерело: github.com
Натомість валідатори продовжують обробляти інші операції в блокчейні, застосовуючи їх до стану-кандидата. Якщо запропонований блок буде погоджений, стан-кандидат також буде прийнятий. Інакше — він відкидається.
Механізм розпаралелювання v1
Sei використовує Cosmos SDK — «операційну систему» для блокчейнів усередині екосистеми Cosmos. Коли вузли отримують блок транзакцій, вони починають процес їх валідації, що складається з трьох частин: BeginBlock, DeliverTx і EndBlock. Останні дві частини Sei адаптував для паралельного виконання.
DeliverTx. Традиційно під час DeliverTx транзакції обробляються послідовно. Sei змінює цей підхід, забезпечуючи паралельне виконання.
Щоб уникнути невизначеності (сценаріїв, за яких результат певних процесів не бажаний для одночасного виконання), Sei фільтрує транзакції на ті, які можуть виконуватися паралельно, і ті, що відбуваються послідовно. Для цього він сегментує операції за типом і даними, які вони виконують.
EndBlock. Sei надає послуги у фінансовому секторі, тому транзакції всередині блокчейну можна поділити на купівлю та продаж, а платформи для їх виконання — на ринки.
На етапі EndBlock Sei об'єднує ордери на купівлю та продаж активу. Замість послідовної обробки цих замовлень Sei фільтрує незалежні транзакції та перевіряє їх паралельно наприкінці блоку.
Ордери вважаються незалежними, якщо вони не впливають на той самий ринок всередині одного блоку.
Обробка блоків у Sei з розпаралелюванням і без нього. Джерело: github.com
Механізм розпаралелювання v2
29 листопада 2023 року команда проєкту анонсувала вихід Sei v2, першого паралельного EVM, який поєднує найкраще від Solana та Ethereum. До нової версії були додані:
- EVM-сумісність.
- Оптимістична паралелізація.
- SeiDB.
Лише друге оновлення вплинуло на паралельне виконання транзакцій у Sei. Тому замість вивчення кожного з трьох поліпшень сконцентруємося тільки на оптимістичній паралелізації.
У першій версії Sei розробникам доводилося самостійно знаходити залежність транзакцій, що зменшувало продуктивність мережі. У Sei v2 використовується оптимістичний підхід, який передбачає, що всі транзакції є незалежними та обробляються паралельно.
Принцип роботи оптимістичної паралелізації у Sei v2. Джерело: twitter.com
Коли з'являються транзакції, що конфліктують, Sei виконує такі дії:
- виявляє конфлікт — система визначає, до яких частин сховища та чи інша транзакція намагається отримати доступ;
- обробляє транзакції — після виявлення операцій, що конфліктують, починається їх послідовне виконання.
Цей процес повторюється, доки не будуть розв'язані усі конфлікти. Тільки тоді Sei зможе продовжити обробляти наступні транзакції.
Інші блокчейни з паралельним виконанням
Sui. Транзакції Sui змінюють атрибути об'єктів, які можуть бути активами чи смартконтрактами. Якщо транзакція визначена як незалежна (тобто жодна інша транзакція не взаємодіє з цільовим об'єктом), вона обходить механізм консенсусу.
Aptos. Aptos використовує принцип оптимістичного виконання. Однак, на відміну від Sei v2, цей блокчейн автоматично визначає залежність транзакцій у разі конфліктів. Водночас не вимагає від транзакцій вказувати, на яку частину стану блокчейну вони впливають.
Monad. Орієнтований на продуктивність блокчейн першого рівня, який сумісний з Ethereum. Аналогічно до Aptos, Monad використовує принцип оптимістичного виконання, припускаючи, що транзакції не пов'язані між собою, та розглядає залежності в міру їх виникнення.
