Shoal фреймворк: інноваційне рішення для підвищення продуктивності Aptos Блокчейн
Aptos Labs нещодавно представила фреймворк Shoal, метою якого є вирішення двох ключових проблем у DAG BFT консенсусі, значно знижуючи затримки та вперше усуваючи залежність від тайм-аутів у детермінаційних асинхронних протоколах. Загалом, Shoal підвищує затримку Bullshark на 40% у безвідмовному режимі та на 80% у випадку відмови.
Shoal через конвеєрну та механізм репутації лідера покращує протокол консенсусу на базі Narwhal (, такий як DAG-Rider, Tusk, Bullshark тощо ). Технологія конвеєра зменшує затримки сортування DAG, вводячи анкерну точку в кожному раунді, а механізм репутації лідера ще більше покращує затримки, забезпечуючи зв'язок анкерної точки з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронне побудування DAG для усунення тайм-аутів у всіх сценаріях, забезпечуючи тим самим загальну чутливість.
Основна ідея Shoal полягає в послідовному виконанні кількох екземплярів базового протоколу. Наприклад, Bullshark можна уявити як групу "акул", які беруть участь у естафеті.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Мотивація
Блокчейн мережа завжди прагнула до вищої продуктивності, на початкових етапах основна увага приділялася зниженню складності зв'язку. Проте, цей підхід не приніс значного підвищення пропускної здатності. Наприклад, реалізація Hotstuff в ранніх версіях Diem досягла лише 3500 TPS, що значно нижче цільових 100000+ TPS.
Недавній прорив зумовлений усвідомленням того, що поширення даних є основним вузьким місцем, яке базується на протоколі лідерства, і його можна поліпшити за рахунок паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій усі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих, досягаючи пропускної спроможності 160000 TPS.
Aptos раніше представив Quorum Store, тобто реалізацію Narwhal, яка розділяє поширення даних і консенсус, і використовується для розширення поточного консенсусного протоколу Jolteon. Jolteon поєднує лінійний швидкий шлях Tendermint і зміни візу PBFT, зменшуючи затримку Hotstuff на 33%. Проте, консенсусний протокол на основі лідера не може повною мірою використовувати потенціал пропускної спроможності Narwhal.
Отже, Aptos вирішив розгорнути Bullshark на Narwhal DAG, протокол консенсусу з нульовими витратами на зв'язок. Але підтримка Bullshark високопродуктивної структури DAG призводить до 50% затримки. Мета框架 Shoal полягає в значному зменшенні затримки Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Фон DAG-BFT
Кожна вершина в Narwhal DAG пов'язана з певним колом. Для входу в r-те коло потрібно спочатку отримати n-f вершин з r-1 кола. Кожен валідатор може транслювати одну вершину за коло, кожна вершина принаймні посилається на n-f вершин з попереднього кола. Через асинхронність мережі різні валідатори можуть спостерігати різні локальні види DAG.
Ключовою особливістю DAG є ненамагання: якщо два вузли верифікації мають однакову вершину v у локальному вигляді DAG, то вони мають абсолютно однакову причинно-історичну інформацію про v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Повний порядок
Можна досягти узгодженості загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Протоколи, такі як DAG-Rider, Tusk і Bullshark, тлумачать структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра - голосування.
Хоча конкретна логіка різна, всі протоколи консенсусу на базі Narwhal мають таку структуру:
Попередньо визначений якорний пункт: кожні кілька раундів є заздалегідь визначений лідер, чий пік називається якорем.
Точки прив'язки: валідатори незалежно, але детерміновано вирішують, які точки прив'язки сортувати або пропустити.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють впорядкований список якорів, сортують невпорядковані вершини в причинно-наслідковій історії кожного якоря.
Ключем досягнення безпеки є забезпечення того, щоб усі чесні вузли-верифікатори створювали спільний список впорядкованих якорів з однаковим префіксом. Shoal робить важливе спостереження щодо всіх цих протоколів: всі верифікатори погоджуються з першим впорядкованим якорем.
Проблема затримки Bullshark
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча деякі версії синхронізації мають нижчу затримку, ніж асинхронні версії, вони все ще далекі від оптимальних.
Основних існує дві проблеми:
Середня затримка блоку: в звичайних випадках непарні вершини потребують трьох раундів для сортування, парні неносійні вершини потребують чотирьох раундів.
Затримка в ситуації збоїв: якщо лідер раунду не встиг своєчасно транслювати опорну точку, ця опорна точка буде пропущена, а всі невідсортовані вершини з попередніх раундів повинні чекати на наступне сортування опорної точки. Це значно знижує ефективність географічно розподілених мереж, особливо враховуючи, що Bullshark використовує таймаут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Shoal фрейм
Shoal через конвеєр посилює Bullshark( або будь-який протокол BFT на основі Narwhal), дозволяючи мати один якорний вузол в кожному раунді, зменшуючи затримку всіх не-якорних вершин до трьох раундів. Shoal також вводить у DAG механізм репутації лідерів без витрат, схиляючись до вибору швидких лідерів.
виклик
Впровадження конвеєра та репутації лідера в протоколі DAG вважається складним:
Попередні спроби змінити основну логіку Bullshark, здається, не вдалися.
Репутація лідерів може призвести до різних порядків, а валідатори повинні домовитися про впорядковану історію для вибору майбутніх якорів.
Як підтвердження складності питань, в даний час реалізації Bullshark у виробничому середовищі не підтримують ці функції.
Протокол
Рішення Shoal відносно просте. Воно використовує можливість виконання локальних обчислень на DAG, реалізуючи функцію збереження та повторної інтерпретації інформації з попередніх раундів. На базі усіх валідаторів, які погоджуються з першим впорядкованим якорем, Shoal послідовно комбінує кілька екземплярів Bullshark для конвеєрної обробки, що дозволяє:
Першою впорядкованою якорем є точка переключення екземпляра
Історія причинно-наслідкових зв'язків якоря використовується для обчислення репутації лідера
Лінія
V, яка відображає раунд на лідера. Shoal послідовно виконує екземпляри Bullshark, кожен екземпляр сортує один якір і запускає перехід до наступного екземпляра.
Shoal запускає перший екземпляр Bullshark з першого раунду DAG до визначення першої впорядкованої прив'язки (, припустимо, в раунді r ). Усі валідатори погоджуються з цією прив'язкою, тому можуть з упевненістю погодитися на повторну інтерпретацію DAG з раунду r+1. Shoal запускає новий екземпляр Bullshark у раунді r+1.
В ідеальних умовах це дозволяє Shoal сортувати одну анкерну точку за раунд. Перша анкерна точка сортується першим екземпляром, а потім на другому раунді новий екземпляр сортує цю анкерну точку, і так далі.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутація лідера
Коли Bullshark пропускає якорну точку, затримка збільшується. Технологія конвеєра в цьому випадку безсила, оскільки потрібно дочекатися, поки попередній екземпляр відсортує якорну точку, перш ніж можна буде запустити новий екземпляр. Shoal призначає бали для кожного вузла перевірки за допомогою механізму репутації, на основі його нещодавньої історії активності. Швидкісні валідатори отримують високі бали, в іншому випадку отримують низькі.
Ідея полягає в тому, щоб під час кожного оновлення оцінки детерміновано повторно розраховувати відображення F від раунду до лідера, орієнтуючись на лідерів з високими оцінками. Щоб валідатори змогли досягти консенсусу щодо нового відображення, їм потрібно досягти консенсусу щодо оцінок, а отже, досягти консенсусу щодо історії, яка використовується для похідних оцінок.
У Shoal, лінійні та репутаційні лідери можуть природно поєднуватися, оскільки вони обидва базуються на повторному тлумаченні DAG після досягнення згоди на першій впорядкованій якорній точці. Єдина різниця полягає в тому, що після r-ї впорядкованої якорної точки, валідатори починають обчислювати нову мапу F' з r+1-го раунду на основі каузальної історії цієї якорної точки. Потім з r+1-го раунду починають виконувати нові інстанси Bullshark з оновленою F'.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Видалити тайм-аут
Час вичерпано є критичним у всіх реалізаціях часткової синхронізації BFT на основі лідерства. Однак вони підвищують складність, вимагаючи більше управління внутрішнім станом та спостереження, що ускладнює налагодження.
Час вичерпання також суттєво збільшує затримку, оскільки правильна конфігурація є важливою і зазвичай потребує динамічної настройки. Перед переходом до наступного лідера протокол має сплатити повний штраф за затримку часу вичерпання для несправного лідера. Отже, налаштування часу вичерпання не повинні бути занадто обережними, але якщо вони занадто короткі, це може призвести до пропуску доброго лідера.
На жаль, протоколи, засновані на лідерах, такі як Hotstuff та Jolteon(, суттєво потребують тайм-ауту, щоб забезпечити прогрес у разі збою лідера. Якщо немає тайм-ауту, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити збій від повільного лідера, тайм-аут може призвести до того, що вузли верифікації замінять всіх лідерів без активності консенсусу.
У Bullshark тайм-аут використовується для побудови DAG, щоб забезпечити достатньо швидке додавання опорних точок до DAG чесними лідерами під час синхронізації для впорядкування.
Ми спостерігаємо, що побудова DAG забезпечує "годинник" для оцінки швидкості мережі. Як тільки n-f чесних валідаторів продовжують додавати вершини до DAG, раунд буде просуватися. Хоча Bullshark, можливо, не зможе сортувати з швидкістю мережі, DAG все ще зростає з швидкістю мережі. Врешті-решт, коли безвідмовний лідер достатньо швидко транслює анкерні точки, вся причинно-наслідкова історія анкерних точок буде відсортована.
У процесі оцінювання ми порівняли Bullshark без тайм-ауту та з тайм-аутом:
Швидкі лідери: два методи затримки однакові, оскільки анкери впорядковані і не використовують тайм-аут.
Помилковий лідер: без тайм-ауту Bullshark затримка нижча, оскільки вузли перевірки негайно пропускають свою опору.
Повільні лідери: мають кращу продуктивність, ніж Bullshark з тайм-аутом, оскільки валідатори будуть чекати на опорну точку, тоді як без тайм-ауту можуть пропустити опорну точку.
У Shoal уникнення тайм-аутів тісно пов'язане з репутацією лідера. Повторне очікування повільних лідерів збільшує затримку, а механізм репутації виключає повільних валідаторів з виборів на посаду лідера. Таким чином, система може працювати з мережею швидкості в усіх реальних сценаріях.
Слід звернути увагу на те, що результати FLP про неможливість показують, що немає детермінованого протоколу консенсусу, який міг би повністю уникнути тайм-ауту. Shoal не може обійти цей результат, оскільки теоретично існують протистоять події, які можуть перешкодити сортуванню всіх якорів. Навпаки, після конфігурованої кількості безперервного пропуску якорів Shoal повернеться до тайм-ауту. Але на практиці така ситуація є вкрай малоймовірною.
) Загальна реактивність
Стаття Hotstuff популяризувала концепцію оптимістичних відповідей, що інтуїтивно означає, що протокол може в хороших умовах ### включати швидких лідерів і синхронізовану мережу (, щоб працювати на швидкості мережі.
Shoal надає кращу функцію, яка називається універсальною чутливістю. Конкретно, на відміну від Hotstuff, навіть якщо лідер зазнає невдачі протягом налаштовуваної кількості послідовних раундів або мережа переживає асинхронні періоди, Shoal продовжить працювати з швидкістю мережі.
Загальна реактивність забезпечує строгіші гарантії прогресу під час асинхронного періоду та при збої лідера. Під час синхронізації з повільним лідером ці характеристики не можуть бути безпосередньо порівняні, оскільки залежать від швидкості лідера. Але враховуючи механізм репутації лідера, повільні лідери в Shoal повинні з'являтися рідко.
Shoal фреймворк: підвищення затримки на 40% для ланцюга Aptos та усунення залежності від тайм-аутів
Shoal фреймворк: інноваційне рішення для підвищення продуктивності Aptos Блокчейн
Aptos Labs нещодавно представила фреймворк Shoal, метою якого є вирішення двох ключових проблем у DAG BFT консенсусі, значно знижуючи затримки та вперше усуваючи залежність від тайм-аутів у детермінаційних асинхронних протоколах. Загалом, Shoal підвищує затримку Bullshark на 40% у безвідмовному режимі та на 80% у випадку відмови.
Shoal через конвеєрну та механізм репутації лідера покращує протокол консенсусу на базі Narwhal (, такий як DAG-Rider, Tusk, Bullshark тощо ). Технологія конвеєра зменшує затримки сортування DAG, вводячи анкерну точку в кожному раунді, а механізм репутації лідера ще більше покращує затримки, забезпечуючи зв'язок анкерної точки з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронне побудування DAG для усунення тайм-аутів у всіх сценаріях, забезпечуючи тим самим загальну чутливість.
Основна ідея Shoal полягає в послідовному виконанні кількох екземплярів базового протоколу. Наприклад, Bullshark можна уявити як групу "акул", які беруть участь у естафеті.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Мотивація
Блокчейн мережа завжди прагнула до вищої продуктивності, на початкових етапах основна увага приділялася зниженню складності зв'язку. Проте, цей підхід не приніс значного підвищення пропускної здатності. Наприклад, реалізація Hotstuff в ранніх версіях Diem досягла лише 3500 TPS, що значно нижче цільових 100000+ TPS.
Недавній прорив зумовлений усвідомленням того, що поширення даних є основним вузьким місцем, яке базується на протоколі лідерства, і його можна поліпшити за рахунок паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій усі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих, досягаючи пропускної спроможності 160000 TPS.
Aptos раніше представив Quorum Store, тобто реалізацію Narwhal, яка розділяє поширення даних і консенсус, і використовується для розширення поточного консенсусного протоколу Jolteon. Jolteon поєднує лінійний швидкий шлях Tendermint і зміни візу PBFT, зменшуючи затримку Hotstuff на 33%. Проте, консенсусний протокол на основі лідера не може повною мірою використовувати потенціал пропускної спроможності Narwhal.
Отже, Aptos вирішив розгорнути Bullshark на Narwhal DAG, протокол консенсусу з нульовими витратами на зв'язок. Але підтримка Bullshark високопродуктивної структури DAG призводить до 50% затримки. Мета框架 Shoal полягає в значному зменшенні затримки Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Фон DAG-BFT
Кожна вершина в Narwhal DAG пов'язана з певним колом. Для входу в r-те коло потрібно спочатку отримати n-f вершин з r-1 кола. Кожен валідатор може транслювати одну вершину за коло, кожна вершина принаймні посилається на n-f вершин з попереднього кола. Через асинхронність мережі різні валідатори можуть спостерігати різні локальні види DAG.
Ключовою особливістю DAG є ненамагання: якщо два вузли верифікації мають однакову вершину v у локальному вигляді DAG, то вони мають абсолютно однакову причинно-історичну інформацію про v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Повний порядок
Можна досягти узгодженості загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Протоколи, такі як DAG-Rider, Tusk і Bullshark, тлумачать структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра - голосування.
Хоча конкретна логіка різна, всі протоколи консенсусу на базі Narwhal мають таку структуру:
Попередньо визначений якорний пункт: кожні кілька раундів є заздалегідь визначений лідер, чий пік називається якорем.
Точки прив'язки: валідатори незалежно, але детерміновано вирішують, які точки прив'язки сортувати або пропустити.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють впорядкований список якорів, сортують невпорядковані вершини в причинно-наслідковій історії кожного якоря.
Ключем досягнення безпеки є забезпечення того, щоб усі чесні вузли-верифікатори створювали спільний список впорядкованих якорів з однаковим префіксом. Shoal робить важливе спостереження щодо всіх цих протоколів: всі верифікатори погоджуються з першим впорядкованим якорем.
Проблема затримки Bullshark
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча деякі версії синхронізації мають нижчу затримку, ніж асинхронні версії, вони все ще далекі від оптимальних.
Основних існує дві проблеми:
Середня затримка блоку: в звичайних випадках непарні вершини потребують трьох раундів для сортування, парні неносійні вершини потребують чотирьох раундів.
Затримка в ситуації збоїв: якщо лідер раунду не встиг своєчасно транслювати опорну точку, ця опорна точка буде пропущена, а всі невідсортовані вершини з попередніх раундів повинні чекати на наступне сортування опорної точки. Це значно знижує ефективність географічно розподілених мереж, особливо враховуючи, що Bullshark використовує таймаут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Shoal фрейм
Shoal через конвеєр посилює Bullshark( або будь-який протокол BFT на основі Narwhal), дозволяючи мати один якорний вузол в кожному раунді, зменшуючи затримку всіх не-якорних вершин до трьох раундів. Shoal також вводить у DAG механізм репутації лідерів без витрат, схиляючись до вибору швидких лідерів.
виклик
Впровадження конвеєра та репутації лідера в протоколі DAG вважається складним:
Попередні спроби змінити основну логіку Bullshark, здається, не вдалися.
Репутація лідерів може призвести до різних порядків, а валідатори повинні домовитися про впорядковану історію для вибору майбутніх якорів.
Як підтвердження складності питань, в даний час реалізації Bullshark у виробничому середовищі не підтримують ці функції.
Протокол
Рішення Shoal відносно просте. Воно використовує можливість виконання локальних обчислень на DAG, реалізуючи функцію збереження та повторної інтерпретації інформації з попередніх раундів. На базі усіх валідаторів, які погоджуються з першим впорядкованим якорем, Shoal послідовно комбінує кілька екземплярів Bullshark для конвеєрної обробки, що дозволяє:
Лінія
V, яка відображає раунд на лідера. Shoal послідовно виконує екземпляри Bullshark, кожен екземпляр сортує один якір і запускає перехід до наступного екземпляра.
Shoal запускає перший екземпляр Bullshark з першого раунду DAG до визначення першої впорядкованої прив'язки (, припустимо, в раунді r ). Усі валідатори погоджуються з цією прив'язкою, тому можуть з упевненістю погодитися на повторну інтерпретацію DAG з раунду r+1. Shoal запускає новий екземпляр Bullshark у раунді r+1.
В ідеальних умовах це дозволяє Shoal сортувати одну анкерну точку за раунд. Перша анкерна точка сортується першим екземпляром, а потім на другому раунді новий екземпляр сортує цю анкерну точку, і так далі.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутація лідера
Коли Bullshark пропускає якорну точку, затримка збільшується. Технологія конвеєра в цьому випадку безсила, оскільки потрібно дочекатися, поки попередній екземпляр відсортує якорну точку, перш ніж можна буде запустити новий екземпляр. Shoal призначає бали для кожного вузла перевірки за допомогою механізму репутації, на основі його нещодавньої історії активності. Швидкісні валідатори отримують високі бали, в іншому випадку отримують низькі.
Ідея полягає в тому, щоб під час кожного оновлення оцінки детерміновано повторно розраховувати відображення F від раунду до лідера, орієнтуючись на лідерів з високими оцінками. Щоб валідатори змогли досягти консенсусу щодо нового відображення, їм потрібно досягти консенсусу щодо оцінок, а отже, досягти консенсусу щодо історії, яка використовується для похідних оцінок.
У Shoal, лінійні та репутаційні лідери можуть природно поєднуватися, оскільки вони обидва базуються на повторному тлумаченні DAG після досягнення згоди на першій впорядкованій якорній точці. Єдина різниця полягає в тому, що після r-ї впорядкованої якорної точки, валідатори починають обчислювати нову мапу F' з r+1-го раунду на основі каузальної історії цієї якорної точки. Потім з r+1-го раунду починають виконувати нові інстанси Bullshark з оновленою F'.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Видалити тайм-аут
Час вичерпано є критичним у всіх реалізаціях часткової синхронізації BFT на основі лідерства. Однак вони підвищують складність, вимагаючи більше управління внутрішнім станом та спостереження, що ускладнює налагодження.
Час вичерпання також суттєво збільшує затримку, оскільки правильна конфігурація є важливою і зазвичай потребує динамічної настройки. Перед переходом до наступного лідера протокол має сплатити повний штраф за затримку часу вичерпання для несправного лідера. Отже, налаштування часу вичерпання не повинні бути занадто обережними, але якщо вони занадто короткі, це може призвести до пропуску доброго лідера.
На жаль, протоколи, засновані на лідерах, такі як Hotstuff та Jolteon(, суттєво потребують тайм-ауту, щоб забезпечити прогрес у разі збою лідера. Якщо немає тайм-ауту, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити збій від повільного лідера, тайм-аут може призвести до того, що вузли верифікації замінять всіх лідерів без активності консенсусу.
У Bullshark тайм-аут використовується для побудови DAG, щоб забезпечити достатньо швидке додавання опорних точок до DAG чесними лідерами під час синхронізації для впорядкування.
Ми спостерігаємо, що побудова DAG забезпечує "годинник" для оцінки швидкості мережі. Як тільки n-f чесних валідаторів продовжують додавати вершини до DAG, раунд буде просуватися. Хоча Bullshark, можливо, не зможе сортувати з швидкістю мережі, DAG все ще зростає з швидкістю мережі. Врешті-решт, коли безвідмовний лідер достатньо швидко транслює анкерні точки, вся причинно-наслідкова історія анкерних точок буде відсортована.
У процесі оцінювання ми порівняли Bullshark без тайм-ауту та з тайм-аутом:
Швидкі лідери: два методи затримки однакові, оскільки анкери впорядковані і не використовують тайм-аут.
Помилковий лідер: без тайм-ауту Bullshark затримка нижча, оскільки вузли перевірки негайно пропускають свою опору.
Повільні лідери: мають кращу продуктивність, ніж Bullshark з тайм-аутом, оскільки валідатори будуть чекати на опорну точку, тоді як без тайм-ауту можуть пропустити опорну точку.
У Shoal уникнення тайм-аутів тісно пов'язане з репутацією лідера. Повторне очікування повільних лідерів збільшує затримку, а механізм репутації виключає повільних валідаторів з виборів на посаду лідера. Таким чином, система може працювати з мережею швидкості в усіх реальних сценаріях.
Слід звернути увагу на те, що результати FLP про неможливість показують, що немає детермінованого протоколу консенсусу, який міг би повністю уникнути тайм-ауту. Shoal не може обійти цей результат, оскільки теоретично існують протистоять події, які можуть перешкодити сортуванню всіх якорів. Навпаки, після конфігурованої кількості безперервного пропуску якорів Shoal повернеться до тайм-ауту. Але на практиці така ситуація є вкрай малоймовірною.
) Загальна реактивність
Стаття Hotstuff популяризувала концепцію оптимістичних відповідей, що інтуїтивно означає, що протокол може в хороших умовах ### включати швидких лідерів і синхронізовану мережу (, щоб працювати на швидкості мережі.
Shoal надає кращу функцію, яка називається універсальною чутливістю. Конкретно, на відміну від Hotstuff, навіть якщо лідер зазнає невдачі протягом налаштовуваної кількості послідовних раундів або мережа переживає асинхронні періоди, Shoal продовжить працювати з швидкістю мережі.
Загальна реактивність забезпечує строгіші гарантії прогресу під час асинхронного періоду та при збої лідера. Під час синхронізації з повільним лідером ці характеристики не можуть бути безпосередньо порівняні, оскільки залежать від швидкості лідера. Але враховуючи механізм репутації лідера, повільні лідери в Shoal повинні з'являтися рідко.
![Тисячослівний роз'яснення фреймворку Shoal: як зменшити