Sui документація
  • Про Sui
    • Sui Глосарій
    • Чому Move?
    • Чим Sui Move відрізняється від Core Move
    • Зрозумійте Sui Security
    • Sui Whitepaper
  • Як працює Sui?
    • Чим Sui відрізняється від інших блокчейнів
  • Sui Токеноміка
    • Токен Sui
    • Фонд зберігання Sui
    • Proof-of-Stake
    • Токеноміка Whitepaper
Powered by GitBook
On this page
  • Традиційні блокчейни
  • Підхід Sui до перевірки нових транзакцій
  • Спільний підхід до подання транзакцій
  • Інший підхід до стану
  • Причинно-наслідковий порядок проти загального порядку
  • Де Sui виділяється
  • Інженерні компроміси
  • Висновок
  1. Як працює Sui?

Чим Sui відрізняється від інших блокчейнів

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

Ось ключові особливості Sui:

  • Причинно-наслідковий порядок проти тотального порядку дозволяє масово паралельне виконання

  • Варіант Move від Sui та його об’єктно-орієнтована модель даних роблять можливими складові об’єкти/NFT

  • Мова програмування Move, орієнтована на блокчейн, полегшує роботу розробника

Традиційні блокчейни

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

Цей метод підтримки спільного стану протягом тривалого часу мав практичний успіх протягом останніх 14 років або близько того, використовуючи велику кількість теорії за останні 50 років досліджень у сфері візантійських розподілених систем, стійких до відмов.

Але це за своєю суттю послідовне: кроки до ланцюжка додаються по одному, як перлини на нитці. На практиці цей підхід призупиняє приплив транзакцій (часто зберігаються в "пам'ятній пулі"), поки поточний блок знаходиться на розгляді.

Підхід Sui до перевірки нових транзакцій

Багато транзакцій не мають складних взаємозалежностей з іншими довільними частинами стану блокчейну. Часто фінансові користувачі просто хочуть надіслати актив одержувачу, і єдині дані, необхідні для того, щоб оцінити, чи ця проста транзакція прийнятна, — це новий перегляд облікового запису відправника. Таким чином, Sui використовує підхід лише для блокування – або «зупинки світу» – для відповідної частини даних, а не для всього ланцюжка – у цьому випадку обліковий запис відправника, який може надсилати лише одну транзакцію за раз.

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

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

Спільний підхід до подання транзакцій

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

Але процес подання транзакції дещо складніший. Трохи більше роботи відбувається в мережі. (Оскільки пропускна здатність стає дешевшою, це не викликає занепокоєння.) У той час як звичайний блокчейн може прийняти купу транзакцій від одного автора в режимі «запусти і забудь», подання транзакцій Sui виконується за такими кроками:

  • Відправник транслює трансакцію всім валідаторам Sui.

  • Валідатори Sui надсилають індивідуальні голоси за цю транзакцію відправнику.

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

  • За бажанням відправник отримує сертифікат із детальним описом наслідків транзакції.

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

Інший підхід до стану

Оскільки Sui зосереджується на управлінні окремими об’єктами, а не на одному сукупному стані, він також звітує про них унікальним способом:

  • Кожен об’єкт у Sui має унікальний номер версії.

  • Кожна нова версія створюється з транзакції, яка може включати кілька залежностей, які самі є версійними об’єктами.

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

Причинно-наслідковий порядок проти загального порядку

На відміну від більшості існуючих блокчейн-систем (і, як читач міг здогадатися з опису запитів на запис вище), Sui не завжди накладає загальний порядок на транзакції, подані клієнтами, винятком є спільні об’єкти. Натомість багато транзакцій упорядковуються причинно – якщо транзакція T1 створює вихідні об’єкти O1, які використовуються як вхідні об’єкти в транзакції T2, валідатор повинен виконати T1 перед виконанням T2. Зауважте, що T2 не обов’язково використовувати ці об’єкти безпосередньо для існування причинно-наслідкового зв’язку – наприклад, T1 може створювати вихідні об’єкти, які потім використовує T3, а T2 може використовувати вихідні об’єкти T3. Однак транзакції без причинно-наслідкового зв’язку можуть оброблятися валідаторами Sui у будь-якому порядку.

Де Sui виділяється

У цьому розділі підсумовано основні переваги Sui порівняно з традиційними блокчейнами.

Висока продуктивність

Основною перевагою Sui є його безпрецедентна продуктивність. Наступні пункти підсумовують основні переваги продуктивності Sui щодо традиційних блокчейнів:

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

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

  • Sui працює на швидкості мережі, не чекаючи системних тайм-аутів між кроками протоколу. Це значно зменшує затримку, коли мережа справна і не піддається атаці. Навпаки, безпека ряду традиційних блокчейнів (включно з більшістю блокчейнів на основі підтвердження роботи) потребує очікування попередньо визначених тайм-аутів перед здійсненням транзакцій.

  • Sui може використовувати більше машин на валідатор, щоб підвищити його продуктивність. Традиційні блокчейни часто розроблені для роботи на одній машині на валідатор (або навіть на одному ЦП).

Продуктивність при помилках

Припущення безпеки

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

Ефективні локальні операції читання

Простіший досвід розробника

Sui надає розробникам такі переваги:

  • Переміщення та об’єктоцентрична модель даних (дозволяє складати об’єкти/NFT)

  • Модель програмування, орієнтована на активи

  • Простіший досвід розробника

Інженерні компроміси

У цьому розділі представлені основні недоліки Sui щодо традиційних блокчейнів.

Складність конструкції

У той час як традиційні блокчейни вимагають реалізації лише одного консенсусного протоколу, Sui вимагає двох протоколів: (i) протокол на основі Byzantine Consistent Broadcast для обробки простих транзакцій і (ii) консенсусний протокол для обробки транзакцій зі спільними об’єктами. Це означає, що команда Sui повинна підтримувати набагато більшу кодову базу.

Транзакції, пов’язані зі спільними об’єктами, вимагають невеликих накладних витрат (додаючи дві додаткові передачі – 200 мс для добре підключених клієнтів, які використовують службу Sui Gateway), перш ніж передати їх у протокол консенсусу. Ці накладні витрати необхідні для безпечного створення двох описаних вище протоколів. Натомість інші блокчейни можуть безпосередньо передати транзакцію консенсусному протоколу. Зауважте, що остаточність для транзакцій спільного об’єкта все ще знаходиться в діапазоні 2-3 секунд навіть із цими накладними витратами.

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

Послідовний запис у простому випадку

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

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

Недоліком дозволу на блокування відправника для цих простих транзакцій є те, що відправник може надсилати лише одну транзакцію за раз. У зв’язку з цим транзакції необхідно швидко завершити.

Складні сумарні запити

Sui може ускладнити загальні запити, ніж у традиційних блокчейнах, оскільки він не завжди нав’язує загальний порядок транзакцій. Загальні запити досить рідкісні щодо локальних читань (див. вище), але корисні в деяких сценаріях. Наприклад, новий валідатор приєднується до мережі та має завантажити загальний стан на диск, або аудитор бажає перевірити весь блокчейн.

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

Висновок

PreviousЯк працює Sui?NextSui Токеноміка

Last updated 2 years ago

Кожен голос має певну вагу, оскільки кожен валідатор має вагу на основі правил .

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

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

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

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

Таким чином, Sui пропонує багато переваг у продуктивності та зручності використання ціною певної складності в менш простих випадках використання. Транзакції прямого відправника чудові в Sui. А мемпул на основі DAG і ефективний консенсус Byzantine Fault Tolerant (BFT) безперешкодно підтримують складніші сценарії використання.

Proof of Stake
найсучасніший консенсус-протокол
генезису
SSD-накопичувачів
журналу попереднього запису,
Narwhal і Tusk