Коротше кажучи: цей дослідницький матеріал надає огляд паралельних архітектур дизайну для блокчейнів, використовуючи три відповідні приклади: Solana, Sei та Monad. Він висвітлює різницю між оптимістичною та детермінованою паралелізацією та досліджує відтінки доступу до стану та пам'яті на цих ланцюгах.
ВступУ 1837 році комп'ютерний вчений і математик Чарльз Беббідж розробив “Аналітичний Двигун,” яка заклала теоретичну основу для паралельних обчислень. Сьогодні паралелізація є ключовою темою у світі криптовалют, оскільки блокчейни намагаються розширити межі обробки, ефективності та пропускної здатності.
Паралельний Всесвіт
Паралельне обчислення дозволяє виконувати багато обчислень або процесів одночасно, на відміну від послідовних обчислень або один за одним. Паралельне обчислення відноситься до розбиття великих проблем на менші, незалежні частини, які можуть бути виконані декількома процесорами, що спілкуються через спільну пам'ять. Паралельні системи мають кілька переваг, таких як збільшення ефективності та швидкості, масштабованість, покращену надійність та стійкість до відмов, краще використання ресурсів та можливість обробки дуже великих наборів даних.
Однак важливо розуміти, що ефективність паралелізації залежить від конкретики базової архітектури та реалізації. Два основних обмеження для блокчейнів - криптографічні функції (хеш-функції, підписи, еліптичні криві тощо) та доступ до пам'яті/стану. З блокчейнами одним з ключових компонентів розробки ефективної паралельної системи є нюанси доступу до стану. Доступ до стану вказує на можливість транзакції читати та записувати в стан блокчейну, включаючи зберігання, смарт-контракти та баланси рахунків. Для того щоб паралельний блокчейн був ефективним та продуктивним, доступ до стану повинен бути оптимізованим.
Наразі існують дві школи мислення з приводу оптимізації доступу до стану для паралельних блокчейнів: детермінована паралелізація проти оптимістичної паралелізації. Детермінована паралелізація потребує, щоб код явно визначав заздалегідь, які частини стану блокчейну будуть доступними та змінюваними. Це дозволяє системі визначити, які транзакції можуть бути оброблені паралельно без конфліктів заздалегідь. Детермінована паралелізація дозволяє передбачуваність та ефективність (особливо, коли транзакції в основному незалежні). Однак це створює більшу складність для розробників.
Оптимістична паралелізація не вимагає вказівки коду для оголошення доступу до стану наперед, і обробляє транзакції паралельно так, ніби конфліктів не буде. Якщо конфлікт все-таки виникає, оптимістична паралелізація або повторно виконає, переробить або виконає конфліктні транзакції послідовно. Хоча оптимістична паралелізація надає більше гнучкості розробникам, для вирішення конфліктів потрібно повторне виконання, що робить цей метод найбільш ефективним, коли транзакції не конфліктують. Немає однозначної відповіді на питання, який з цих підходів краще. Вони просто два різні (і життєздатні) підходи до паралелізації.
У частині I цієї серії ми спочатку дослідимо деякі основи не криптопаралельних систем, а потім простір проектування для паралельного виконання для блокчейнів, зосереджуючись на трьох основних областях:
-
Огляд криптовалютних паралельних систем- Підходи до доступу до пам'яті та стану- Можливості паралельного дизайну## Non-Crypto Паралельні системиБеручи до уваги те, що ми щойно прочитали про те, що дозволяє паралельне обчислення та переваги паралельних систем, легко зрозуміти, чому у останні роки прийняття паралельних обчислень набуло популярності. Збільшене використання паралельних обчислень дало змогу зробити багато проривів лише за останні кілька десятиліть.
-
Медичне зображення: Паралельна обробка фундаментально перетворила медичне зображення, призводячи до значного збільшення швидкості та роздільної здатності в різних модальностях, таких як МРТ, КТ, рентген та оптична томографія. Nvidia є на передньому краї цих досягнень, надаючи радіологам покращені можливості штучного інтелекту через свій набір засобів для паралельної обробки, який дозволяє зображувальним системам ефективніше впоратися з збільшеним обсягом даних та обчислювальними навантаженнями.- Астрономія: Деякі нові явища, такі як розуміння чорних дір, стали можливими лише завдяки паралельним суперкомп'ютерам.- Ігровий рушій Unity: Рушій Unity використовує можливості GPU, які спеціально розроблені для величезних графічних завдань, щоб допомогти з продуктивністю та швидкістю. Рушій обладнаний функціями багатопотокової та паралельної обробки, що забезпечує безперервний геймплей та створює складні, деталізовані ігрові середовища.Давайте розглянемо три блокчейни, які реалізували паралельні середовища виконання. Спочатку ми розглянемо Solana, а потім два ланцюги на основі EVM, Monad і Sei.
Огляд паралельного дизайну - SolanaНа високому рівні філософія дизайну Solana полягає в тому, що інновації в галузі блокчейну повинні розвиватися разом з апаратними досягненнями. Оскільки апаратне забезпечення покращується з часом завдяки закону Мура, Solana розроблена таким чином, щоб користуватися збільшенням продуктивності та масштабованості. Співзасновник SolanaАнатолій Яковенкоспочатку розробленийАрхітектура паралелізації Solanaбільше п'ять років тому, і сьогодні паралелізм як принцип проектування блокчейну поширюється швидко.
Solana використовує детерміновану паралелізацію, яка випливає з досвіду Анатолія у роботі з вбудованими системами, де зазвичай ви декларуєте всі стани заздалегідь. Це дозволяє ЦП знати всі залежності, що дозволяє йому попередньо витягти необхідні частини пам'яті. Результатом є оптимізоване виконання системи, але знову ж таки, це вимагає від розробників додаткової роботи заздалегідь. На Solana всі залежності від пам'яті для програми є обов'язковими і вказані в побудованій транзакції (тобто Списки Доступу), що дозволяє робочому часу планувати та виконувати кілька транзакцій паралельно ефективно.
Наступною основною складовою архітектури Solana є віртуальна машина Sealevel, яка є паралельним рантаймом розумних контрактів Solana. Sealevel нативно підтримує обробку кількох контрактів та транзакцій паралельно на основі кількості ядер, яким володіє валідатор. Валідатор у блокчейні - це учасник мережі, відповідальний за перевірку та підтвердження транзакцій, пропозицію нових блоків та збереження цілісності та безпеки блокчейну. Оскільки транзакції вказують, які рахунки потрібно читати та блокувати для запису заздалегідь, планувальник Solana може визначити, які транзакції можна виконувати одночасно. Через це, щодо валідації «виробник блоків» або лідер може впорядкувати тисячі очікуючих транзакцій та розкладати неперекриваючіся транзакції паралельно.
Останнім елементом дизайну для Solana є "трубопроводження." Трубопроводження відбувається, коли дані потрібно обробляти в ряді кроків, і кожен з них відповідає різному обладнанню. Основна ідея полягає в тому, щоб взяти дані, які потрібно виконувати послідовно, і паралельно обробити їх за допомогою трубопроводної технології. Ці трубопроводи можуть працювати паралельно, і кожен етап трубопроводу може обробляти різні партії транзакцій.
Ці оптимізації дозволяють Sealevel одночасно організовувати та виконувати незалежні транзакції, використовуючи можливості апаратного забезпечення для обробки кількох точок даних одночасно за допомогою однієї програми. Sealevel сортує інструкції за programID та виконує ту саму інструкцію на всіх відповідних облікових записах паралельно.
З урахуванням цих інновацій ми бачимо, що Solana була спеціально розроблена для підтримки паралелізації.
Огляд паралельного дизайну - SeiSei — це блокчейн рівня 1 загального призначення з відкритим вихідним кодом, що спеціалізується на обміні цифровими активами. Sei V2 використовує оптимістичне розпаралелювання і, як наслідок, є більш зручним для розробників, ніж його детермінований аналог. В оптимістичному паралелізмі смарт-контракти можуть виконуватися більш плавно та одночасно, не вимагаючи від розробників декларувати свої ресурси наперед. Це означає, що ланцюжок оптимістично запускає всі транзакції паралельно. Тим не менш, коли виникають конфлікти (тобто кілька транзакцій мають доступ до одного стану), блокчейн відстежуватиме конкретний компонент зберігання, на який впливає кожна конфліктуюча транзакція.
Блокчейн Sei використовує підхід виконання транзакцій з використанням “Оптимістичного контролю конкурентності (OCC).” Операції обробки одночасних транзакцій відбуваються, коли кілька транзакцій одночасно активні в системі. У цьому підході до транзакцій є дві фази: виконання і валідація.
У фазі виконання транзакції оптимістично обробляються, з усіма читаннями/записами тимчасово зберігаються в окремому сховищі для транзакцій. Після цього кожна транзакція увійде до фази перевірки, де інформація у операціях тимчасового сховища перевіряється на наявність змін стану, зроблених попередніми транзакціями. Якщо транзакція є незалежною, вона виконується паралельно. Якщо транзакція зчитує дані, змінені іншою транзакцією, це призведе до конфлікту. Паралельна система Sei ідентифікує кожен конфлікт, порівнюючи набори читань транзакцій з останніми змінами стану в багатоверсійному сховищі (вони індексуються за порядком транзакцій). Sei буде повторно виконувати та перевіряти випадки, де виникають конфлікти. Це ітеративний процес, що включає виконання, перевірку і повторний запуск для виправлення конфліктів. Нижче наведено графічне зображення методики Sei у випадку виникнення конфлікту в транзакціях.
Джерело: https://blog.sei.io/sei-v2-the-first-parallelized-evm/Реалізація Sei призводить до зниження вартості газових комісій та розширення дизайн-простору для розробників EVM. Історично середовища EVM були обмежені до 
Ілюстративна діаграма ієрархії пам'ятіМасштабуючи горизонтально та розподіляючи станові дані по різних пристроях, 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：- Ця стаття перепублікована з [Взаємовигідні вентури], Усі авторські права належать оригінальному автору [Алі Шейх]. Якщо є заперечення стосовно цього перевидання, будь ласка, зв'яжіться з [Gate Блок](https://www.Gate.com/questionnaire/3967команда, і вони оперативно з цим впораються.- Відповідальність за відмову: погляди та думки, висловлені в цій статті, є виключно тими, хто їх автор і не становлять жодної інвестиційної консультації.- Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.
