Коротше кажучи: цей дослідницький матеріал надає огляд паралельних архітектур дизайну для блокчейнів, використовуючи три відповідні приклади: Solana, Sei та Monad. Він висвітлює різницю між оптимістичною та детермінованою паралелізацією та досліджує відтінки доступу до стану та пам'яті на цих ланцюгах.

Вступ

У 1837 році комп'ютерний вчений і математик Чарльз Беббідж розробив “Аналітичний Двигун,” яка заклала теоретичну основу для паралельних обчислень. Сьогодні паралелізація є ключовою темою у світі криптовалют, оскільки блокчейни намагаються розширити межі обробки, ефективності та пропускної здатності.

Паралельний Всесвіт

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

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

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

Оптимістична паралелізація не вимагає вказівки коду для оголошення доступу до стану наперед, і обробляє транзакції паралельно так, ніби конфліктів не буде. Якщо конфлікт все-таки виникає, оптимістична паралелізація або повторно виконає, переробить або виконає конфліктні транзакції послідовно. Хоча оптимістична паралелізація надає більше гнучкості розробникам, для вирішення конфліктів потрібно повторне виконання, що робить цей метод найбільш ефективним, коли транзакції не конфліктують. Немає однозначної відповіді на питання, який з цих підходів краще. Вони просто два різні (і життєздатні) підходи до паралелізації.

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

1. Огляд криптовалютних паралельних систем
2. Підходи до доступу до пам'яті та стану
3. Можливості паралельного дизайну

Non-Crypto Паралельні системи

Беручи до уваги те, що ми щойно прочитали про те, що дозволяє паралельне обчислення та переваги паралельних систем, легко зрозуміти, чому у останні роки прийняття паралельних обчислень набуло популярності. Збільшене використання паралельних обчислень дало змогу зробити багато проривів лише за останні кілька десятиліть.

1. Медичне зображення: Паралельна обробка фундаментально перетворила медичне зображення, призводячи до значного збільшення швидкості та роздільної здатності в різних модальностях, таких як МРТ, КТ, рентген та оптична томографія. Nvidia є на передньому краї цих досягнень, надаючи радіологам покращені можливості штучного інтелекту через свій набір засобів для паралельної обробки, який дозволяє зображувальним системам ефективніше впоратися з збільшеним обсягом даних та обчислювальними навантаженнями.
2. Астрономія: Деякі нові явища, такі як розуміння чорних дір, стали можливими лише завдяки паралельним суперкомп'ютерам.
3. Ігровий рушій Unity: Рушій Unity використовує можливості GPU, які спеціально розроблені для величезних графічних завдань, щоб допомогти з продуктивністю та швидкістю. Рушій обладнаний функціями багатопотокової та паралельної обробки, що забезпечує безперервний геймплей та створює складні, деталізовані ігрові середовища.

Давайте розглянемо три блокчейни, які реалізували паралельні середовища виконання. Спочатку ми розглянемо Solana, а потім два ланцюги на основі EVM, Monad і Sei.

Огляд паралельного дизайну - Solana

На високому рівні філософія дизайну Solana полягає в тому, що інновації в галузі блокчейну повинні розвиватися разом з апаратними досягненнями. Оскільки апаратне забезпечення покращується з часом завдяки закону Мура, Solana розроблена таким чином, щоб користуватися збільшенням продуктивності та масштабованості. Співзасновник SolanaАнатолій Яковенкоспочатку розробленийАрхітектура паралелізації Solanaбільше п'ять років тому, і сьогодні паралелізм як принцип проектування блокчейну поширюється швидко.

Solana використовує детерміновану паралелізацію, яка випливає з досвіду Анатолія у роботі з вбудованими системами, де зазвичай ви декларуєте всі стани заздалегідь. Це дозволяє ЦП знати всі залежності, що дозволяє йому попередньо витягти необхідні частини пам'яті. Результатом є оптимізоване виконання системи, але знову ж таки, це вимагає від розробників додаткової роботи заздалегідь. На Solana всі залежності від пам'яті для програми є обов'язковими і вказані в побудованій транзакції (тобто Списки Доступу), що дозволяє робочому часу планувати та виконувати кілька транзакцій паралельно ефективно.

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

Останнім елементом дизайну для Solana є "трубопроводження." Трубопроводження відбувається, коли дані потрібно обробляти в ряді кроків, і кожен з них відповідає різному обладнанню. Основна ідея полягає в тому, щоб взяти дані, які потрібно виконувати послідовно, і паралельно обробити їх за допомогою трубопроводної технології. Ці трубопроводи можуть працювати паралельно, і кожен етап трубопроводу може обробляти різні партії транзакцій.

Ці оптимізації дозволяють Sealevel одночасно організовувати та виконувати незалежні транзакції, використовуючи можливості апаратного забезпечення для обробки кількох точок даних одночасно за допомогою однієї програми. Sealevel сортує інструкції за programID та виконує ту саму інструкцію на всіх відповідних облікових записах паралельно.

З урахуванням цих інновацій ми бачимо, що Solana була спеціально розроблена для підтримки паралелізації.

Огляд паралельного дизайну - Sei

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

Блокчейн Sei використовує підхід виконання транзакцій з використанням “Оптимістичного контролю конкурентності (OCC).” Операції обробки одночасних транзакцій відбуваються, коли кілька транзакцій одночасно активні в системі. У цьому підході до транзакцій є дві фази: виконання і валідація.

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

Джерело: https://blog.sei.io/sei-v2-the-first-parallelized-evm/

Реалізація Sei призводить до зниження вартості газових комісій та розширення дизайн-простору для розробників EVM. Історично середовища EVM були обмежені до <50 TPS, що змушувало розробників створювати програми, які слідували анти-шаблонам. Sei V2 дозволяє розробникам підходити до секторів, які зазвичай вимагають високої продуктивності та низьких витрат, таких як DeFi, DePIN та геймінг.

Огляд паралельного дизайну - Монада

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

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

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

Монада також покращує продуктивність шляхом розділення виконання та консенсусу, подібно до Solana та Sei, крім відкладеного виконання. Ідея полягає в тому, що якщо ви послабите умову завершення виконання до завершення консенсусу, ви можете запустити обидва паралельно, що призводить до додаткового часу для обох. Звісно, Monad використовує детермінований алгоритм для обробки цієї умови, щоб забезпечити, що одне з цих не рухається занадто далеко без можливості догнати.

Унікальні підходи до доступу до стану та пам'яті

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

Доступ до стану Solana: AccountsDB / Cloudbreak

Solana використовує горизонтальне масштабування для розподілу та управління даними стану по різних пристроях SSD. Багато блокчейнів сьогодні використовують загальні бази даних (тобто LevelDB) з обмеженнями щодо обробки великої кількості одночасних читань та записів даних стану. Щоб уникнути цього, Solana побудувала власну власну базу даних облікових записів, використовуючиCloudbreak.

Cloudbreak розроблений для паралельного доступу між операціями вводу/виводу, а не покладається виключно на оперативну пам'ять, яка за своєю суттю є швидкою. Операції вводу/виводу (введення/виведення) означають зчитування даних із зовнішнього джерела, наприклад диска, мережі або периферійного пристрою, або запис даних на нього. Спочатку Cloudbreak використовував індекс оперативної пам'яті для зіставлення відкритих ключів з обліковими записами, що містять баланси та дані. Однак на момент написання цієї статті та версії 1.9 індекс був перенесений з оперативної пам'яті на SSD. Цей зсув дозволяє Cloudbreak одночасно обробляти 32 операції (введення-виведення) у своїй черзі, підвищуючи пропускну здатність на кількох твердотільних накопичувачах. Отже, до даних блокчейну, таких як рахунки та транзакції, можна отримати ефективний доступ, ніби вони знаходяться в оперативній пам'яті за допомогою файлів, відображених у пам'яті. На малюнку нижче представлена ілюстративна ієрархія пам'яті. Хоча оперативна пам'ять швидша, вона має меншу ємність, ніж SSD, і, як правило, дорожча:

Ілюстративна діаграма ієрархії пам'яті

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

Доступ до стану: SeiDB

Sei переробила своє сховище, SeiDB, щоб вирішити кілька проблем: збільшення запису (скільки метаданих потрібно для підтримки структур даних, менше = краще), збільшення стану, повільні операції та погіршення продуктивності з часом. Новий перероблений дизайн тепер розбито на дві компоненти: збереження стану та фіксація стану. Запис та перевірка будь-яких змін у даних здійснюється за допомогою фіксації стану, тоді як база даних, яка веде облік всіх даних на будь-який момент, обробляється збереженням стану (SS).

У Sei V2 функція State Commitment використовує відображення в пам'ятіАрхітектура IAVL-дерева (MemIAVL). Зіставлене з пам'яттю дерево IAVL зберігає менше метаданих, що скорочує час зберігання стану та синхронізації станів, а також значно спрощує запуск повного вузла. Відображене в пам'яті дерево IAVL представлено у вигляді трьох файлів на диску (kv, гілка, листя); Тому потрібно відстежувати менше метаданих, що допомагає зменшити обсяг пам'яті стану більш ніж на 50%. Нова структура MemIAVL допомагає зменшити коефіцієнт посилення запису, оскільки вона зменшує метадані, необхідні для підтримки структур даних.

Оновлений SeiDB дозволяє гнучку підтримку бази даних для рівня зберігання стану. Sei вважає, що різні оператори вузлів матимуть різні вимоги та потреби в зберіганні. Тому SS було розроблено для відповідності різним базам даних, надаючи операторам свободу та гнучкість, тобто PebbleDB, RocksDB, SQLite тощо.

Доступ до стану: MonadDB

Існують деякі важливі відтінки доступу до стану Monad. По-перше, більшість клієнтів Ethereum використовують два типи баз даних: бази даних B-Tree (тобто LMDB) або бази даних злиття журналу (LSM) (тобто RocksDB, LevelDB). Обидві ці бази даних є загальними структурами даних, які не були явно розроблені для блокчейнів. Крім того, ці бази даних не використовують найсучасніші досягнення в технології Linux, особливо щодо асинхронних операцій та оптимізації введення/виведення. Нарешті, сам Ethereum керує станом за допомогою Patricia Merkle Trie, яка спеціалізується на криптографії, верифікації та доказах. Основна проблема полягає в тому, що клієнти повинні інтегрувати цей конкретний Патріція Меркле дерево в більш загальні бази даних (тобто B-Tree / LSM), із значними недоліками в продуктивності, такими як надмірний доступ до диска.

Усе вищезазначене допомагає створити підґрунтя для того, чому Monad вирішив створити власну базу даних MonadDB, спеціально розроблену для більш ефективного керування даними блокчейну та доступу до стану. Деякі ключові функції MonadDB включають паралельну базу даних доступу, власну базу даних, оптимізовану для даних Меркля Trie, ефективний доступ до стану за стандартним використанням ОЗП, а також децентралізацію та масштабованість.

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

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

Зведення порівнянь для Solana проти Sei проти Monad

Висновок

У висновку дослідження паралелізму в блокчейнах через призму Solana, Sei та Monad надає повну розуміння того, як різні архітектури та підходи можуть покращити продуктивність та масштабованість. Детермінований паралелізм Solana, з акцентом на попереднє оголошення доступу до стану, пропонує передбачуваність та ефективність, роблячи його потужним вибором для додатків, які потребують високої пропускної здатності. З іншого боку, оптимістичний підхід до паралелізму Sei надає пріоритет гнучкості розробника та ідеально підходить для середовищ, де конфлікти транзакцій відбуваються рідко. З унікальним поєднанням оптимістичного паралелізму та індивідуально розробленої MonadDB, Monad пропонує інноваційне рішення, яке використовує найновіші технологічні досягнення для оптимізації доступу до стану та продуктивності.

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

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

У частині II цієї серії ми дослідимо економічні наслідки та компроміси, пов'язані з цими паралельними системами проектування.

Disclaimer：

1. Ця стаття перепублікована з [Взаємовигідні вентури], Усі авторські права належать оригінальному автору [Алі Шейх]. Якщо є заперечення стосовно цього перевидання, будь ласка, зв'яжіться з Gate Блоккоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: погляди та думки, висловлені в цій статті, є виключно тими, хто їх автор і не становлять жодної інвестиційної консультації.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.