Зменшення затримки Bullshark на Aptos: Детальний огляд рамки Shoal
Aptos labs вирішила дві важливі відкриті проблеми в DAG BFT, значно зменшивши затримку, і вперше усунула потребу в паузах у детерміністському реальному протоколі. Загалом, у разі відсутності відмов затримка Bullshark покращилася на 40%, а в разі відмови – на 80%.
Шаблон Shoal покращує консенсусний протокол на основі Narwhal ( за допомогою механізму конвеєра та репутації лідера, як-от DAG-Rider, Tusk, Bullshark ). Конвеєр у кожному раунді вводить одну анкерну точку, щоб зменшити затримки сортування DAG, а репутація лідера забезпечує зв'язок анкерних точок з найшвидшими вузлами перевірки, ще більше покращуючи затримки. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну конструкцію DAG, щоб усунути тайм-аути в усіх сценаріях, забезпечуючи таким чином властивість загальної реакції.
Технологія Shoal дуже проста: кілька екземплярів базового протоколу працюють по черзі. Коли вона ідентифікується як Bullshark, це схоже на групу «акул», які виконують естафету.
Фон
При досягненні високої продуктивності блокчейн-мережі увага завжди приділялася зниженню складності комунікацій, але це не призвело до суттєвого підвищення пропускної здатності. Наприклад, реалізація Hotstuff у ранньому Diem досягла лише 3500 TPS, що значно нижче цільового показника 100k+ TPS.
Недавній прорив виник завдяки усвідомленню того, що поширення даних є основним вузьким місцем, яке базується на узгодженні лідерів, і може отримати вигоду з паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, всі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У документі Narwhal було зафіксовано пропускну спроможність 160 000 TPS.
Aptos раніше представив Quorum Store, що є реалізацією Narwhal, яка розділяє поширення даних та консенсус і використовується для розширення поточного консенсусного протоколу Jolteon. Jolteon поєднує лінійний швидкий шлях Tendermint і зміни вигляду в стилі PBFT, зменшуючи затримку Hotstuff на 33%. Однак, консенсусний протокол на основі лідера не може повністю використовувати потенціал пропускної спроможності Narwhal.
Отже, Aptos вирішив розгорнути Bullshark, протокол консенсусу з нульовими витратами на комунікацію, на основі Narwhal DAG. На жаль, структура DAG, що підтримує високу пропускну здатність Bullshark, призвела до 50% витрат на затримку.
У цій статті розглядається, як Shoal значно зменшує затримки Bullshark.
Фон DAG-BFT
Кожна вершина в Narwhal DAG пов'язана з певним раундом. На початку раунду r, валідатор повинен отримати n-f вершин з раунду r-1. Кожен валідатор може транслювати одну вершину за раунд, кожна вершина повинна принаймні посилатися на n-f вершин з попереднього раунду. Через асинхронність мережі різні валідатори можуть спостерігати різні локальні види DAG.
Ключовою властивістю DAG є те, що вона не є неясною: якщо два вузли перевірки мають однакову вершину v у своєму локальному вигляді DAG, то вони мають абсолютно однакову причинно-історичну зв'язок для v.
Загальний порядок
Можна досягти згоди щодо загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Валідатори в DAG-Rider, Tusk і Bullshark трактують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра представляють голосування.
Хоча логіка інтерсекції груп у структурі DAG відрізняється, всі протоколи консенсусу на базі Narwhal мають таку структуру:
Забезпечена точка: кожні кілька раундів є заздалегідь визначений лідер, чий пік називається точкою прив'язки.
Точки прив'язки для сортування: валідатори незалежно, але однозначно вирішують, які точки прив'язки сортувати, а які пропускати.
Історія причинно-наслідкових зв'язків: валідатори по черзі обробляють упорядкований список анкорів, сортують попередньо невпорядковані вершини в історії причинно-наслідкових зв'язків кожного анкора.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) усі чесні вузли верифікації створювали список впорядкованих якорів, що мають однаковий префікс. У Shoal ми спостерігали:
Усі валідатори погоджуються з першим впорядкованим анкером.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між упорядкованими якорями в DAG. Затримка часткових синхронних версій краща за асинхронні версії, але все ще не є оптимальною.
Проблема 1: середній затримка блоку. У Bullshark кожна парна ітерація має опорну точку, а непарні ітерації трактуються як голосування. У звичайних випадках для сортування опорних точок потрібно дві ітерації DAG, але вершини в причинно-наслідковій історії опорної точки потребують більше ітерацій для очікування сортування опорних точок. У звичайних випадках непарні вершини потребують три ітерації, а парні не опорні вершини потребують чотири ітерації.
Питання 2: Затримка в ситуації з неполадками. Якщо лідер не в змозі вчасно надіслати маркер, неможливо його впорядкувати ( пропущено ), всі непорядковані вершини з попередніх раундів повинні чекати, поки наступний маркер не буде впорядкований. Це значно знижує продуктивність географічно розподіленої мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
Косяки
Shoal через конвеєр підсилює Bullshark( або будь-який протокол BFT, заснований на Narwhal), дозволяючи кожному раунду мати одну опорну точку, що зменшує затримку всіх неопорних вершин у DAG до трьох раундів. Shoal також вводить у DAG механізм репутації лідера з нульовими витратами, що надає перевагу вибору швидких лідерів.
Виклик
В протоколі DAG, конвеєризація та репутація лідера вважаються складними проблемами з таких причин:
Попередні спроби змінити основну логіку Bullshark в ланцюгу постачання, здається, виявилися неможливими.
Репутація лідерів вводиться в DiemBFT і формалізується в Carousel, динамічно вибираючи майбутніх лідерів на основі минулих досягнень валідаторів ( якорів у Bullshark ). Хоча розбіжність в ідентичності лідерів не порушує безпеки цих протоколів, це може призвести до абсолютно різного порядку в Bullshark, що піднімає основне питання: динамічний і детермінований вибір ротаційних якорів є необхідним для вирішення консенсусу, валідатори повинні досягти згоди щодо упорядкованої історії для вибору майбутніх якорів.
Як доказ складності питання, реалізація Bullshark ( включає ), яка наразі не підтримує ці функції в виробничому середовищі.
угода
Незважаючи на вищезгадані виклики, рішення приховане в простоті.
Shoal спирається на здатність виконувати локальні обчислення на основі DAG, реалізуючи можливість зберігати та перетворювати інформацію з попередніх раундів. Основуючись на спільному погодженні всіх валідаторів щодо першої впорядкованої якорної точки, Shoal послідовно комбінує кілька екземплярів Bullshark для конвеєрної обробки, що робить ( першою впорядкованою якорною точкою, ) причинно-історичний контекст якорної точки використовується для обчислення репутації лідера.
( конвеєр
V, яке відображає раунди на лідерів. Shoal по черзі запускає екземпляри Bullshark, кожен екземпляр якоря заздалегідь визначений за допомогою відображення F. Кожен екземпляр сортує якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark на DAG у першому раунді, який працював до визначення першої впорядкованої якорної точки ), як у раунді r ###. Усі валідатори погодилися з цією якорною точкою, отже, можна було впевнено погодитися на повторне тлумачення DAG з раунду r+1. Shoal запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal впорядковувати одну якореву точку за раунд. Перша якорева точка впорядковується першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який має свою власну якореву точку і впорядковується цим екземпляром, потім ще один новий екземпляр впорядковує якореву точку в третьому раунді, і так далі.
( Репутація лідера
Коли сортування Bullshark пропускає опорну точку, затримка збільшується. У цьому випадку конвеєр не може нічого зробити, оскільки новий екземпляр не може бути запущений до того, як завершиться сортування попередньої опорної точки. Shoal надає бали кожному вузлу перевірки за допомогою механізму репутації, щоб забезпечити менш імовірний вибір відповідного лідера для обробки втрачених опорних точок на основі їх недавньої історії активності. Валідаційники, які реагують і беруть участь у протоколі, отримують високі бали, в іншому випадку присвоюються низькі бали ) можуть зазнати краху, працювати повільно або чинити зло ###.
Ідея полягає в тому, щоб під час кожного оновлення балів детерміновано перепрограмувати попередньо визначену відображення F від раундів до лідера, з ухилом на користь лідера з високими балами. Щоб валідатори могли досягти консенсусу на новій відображенні, їм слід досягти консенсусу щодо балів, щоб досягти консенсусу в історії, що використовується для похідних балів.
У Shoal лінійні процеси та репутація лідерів природно поєднуються, оскільки вони використовують однакову основну технологію: повторне тлумачення DAG після досягнення консенсусу щодо першої впорядкованої якорної точки.
Єдина відмінність полягає в тому, що після р-го раунду сортування якорів, валідатор обчислює нову відображення F' починаючи з р+1 раунду на основі причинно-історичного контексту впорядкованих якорів р-го раунду. Потім валідатор з р+1 раунду починає використовувати оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark.
( Не потрібно більше тайм-аутів
Час очікування є критично важливим у всіх реалізаціях BFT з частковою синхронізацією, що базуються на лідерах. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, ускладнюючи процес налагодження та вимагаючи більше технологій спостереження.
Тайм-аути також значно збільшують затримку, оскільки важливо правильно їх налаштувати, що зазвичай вимагає динамічного коригування, яке сильно залежить від середовища ) мережі ###. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку за тайм-аут для лідера з помилкою. Тому налаштування тайм-аутів не повинні бути занадто консервативними, але якщо вони занадто короткі, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що за високого навантаження лідери в Jolteon/Hotstuff були перевантажені і тайм-аути спливли ще до того, як було досягнуто прогресу.
На жаль, протокол лідера (, такий як Hotstuff і Jolteon ), в основному потребує тайм-аутів, щоб забезпечити прогрес протоколу кожного разу, коли лідер виходить з ладу. Без тайм-аутів навіть зламаний лідер може назавжди зупинити протокол. Оскільки в асинхронний період неможливо відрізнити несправного та повільного лідера, тайм-аут може призвести до того, що вузли перевірки переглянуть зміни всіх лідерів без активності консенсусу.
У Bullshark тайм-аут використовується для побудови DAG, щоб забезпечити достатньо швидке додавання анкерних точок до DAG чесними лідерами під час синхронізації, щоб їх можна було впорядкувати.
Ми спостерігаємо, що конструкція DAG забезпечує "годинник" для оцінки швидкості мережі. Без затримок, поки n-f чесних валідаторів продовжують додавати вершини до DAG, раунд продовжить рухатися вперед. Хоча Bullshark може не бути в змозі впорядкувати ( з швидкістю мережі через проблеми з лідерами ), DAG все ще зростає зі швидкістю мережі, незважаючи на те, що деякі лідери мають проблеми або мережа асинхронна. Врешті-решт, коли безвідмовні лідери достатньо швидко транслюватимуть якорі, вся причинно-наслідкова історія якорів буде впорядкована.
Під час оцінки ми порівняли Bullshark у випадках з тайм-аутом та без нього:
Швидкі лідери, принаймні, швидші за інших валідаторів. У цьому випадку два методи забезпечують однакову затримку, оскільки якорі впорядковані та не використовують тайм-аути.
Помилковий лідер, у цьому випадку безперервний Bullshark забезпечує кращу затримку, оскільки верифікаційні вузли негайно пропустять свої анкери, тоді як верифікатори з паузою будуть чекати закінчення терміну до продовження.
Повільний лідер, це єдиний випадок, коли Bullshark має кращу продуктивність під час тайм-ауту. Тому що без паузі, якорі можуть бути пропущені, оскільки лідер не може досить швидко їх транслювати, а під час паузи, валідатори чекатимуть на якорі.
У Shoal уникнення тайм-ауту тісно пов'язане з репутацією лідера. Повторне очікування
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Aptos впроваджує фреймворк Shoal, що значно знижує затримку Bullshark та усуває потребу в тайм-аутах.
Зменшення затримки Bullshark на Aptos: Детальний огляд рамки Shoal
Aptos labs вирішила дві важливі відкриті проблеми в DAG BFT, значно зменшивши затримку, і вперше усунула потребу в паузах у детерміністському реальному протоколі. Загалом, у разі відсутності відмов затримка Bullshark покращилася на 40%, а в разі відмови – на 80%.
Шаблон Shoal покращує консенсусний протокол на основі Narwhal ( за допомогою механізму конвеєра та репутації лідера, як-от DAG-Rider, Tusk, Bullshark ). Конвеєр у кожному раунді вводить одну анкерну точку, щоб зменшити затримки сортування DAG, а репутація лідера забезпечує зв'язок анкерних точок з найшвидшими вузлами перевірки, ще більше покращуючи затримки. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну конструкцію DAG, щоб усунути тайм-аути в усіх сценаріях, забезпечуючи таким чином властивість загальної реакції.
Технологія Shoal дуже проста: кілька екземплярів базового протоколу працюють по черзі. Коли вона ідентифікується як Bullshark, це схоже на групу «акул», які виконують естафету.
Фон
При досягненні високої продуктивності блокчейн-мережі увага завжди приділялася зниженню складності комунікацій, але це не призвело до суттєвого підвищення пропускної здатності. Наприклад, реалізація Hotstuff у ранньому Diem досягла лише 3500 TPS, що значно нижче цільового показника 100k+ TPS.
Недавній прорив виник завдяки усвідомленню того, що поширення даних є основним вузьким місцем, яке базується на узгодженні лідерів, і може отримати вигоду з паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, всі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У документі Narwhal було зафіксовано пропускну спроможність 160 000 TPS.
Aptos раніше представив Quorum Store, що є реалізацією Narwhal, яка розділяє поширення даних та консенсус і використовується для розширення поточного консенсусного протоколу Jolteon. Jolteon поєднує лінійний швидкий шлях Tendermint і зміни вигляду в стилі PBFT, зменшуючи затримку Hotstuff на 33%. Однак, консенсусний протокол на основі лідера не може повністю використовувати потенціал пропускної спроможності Narwhal.
Отже, Aptos вирішив розгорнути Bullshark, протокол консенсусу з нульовими витратами на комунікацію, на основі Narwhal DAG. На жаль, структура DAG, що підтримує високу пропускну здатність Bullshark, призвела до 50% витрат на затримку.
У цій статті розглядається, як Shoal значно зменшує затримки Bullshark.
Фон DAG-BFT
Кожна вершина в Narwhal DAG пов'язана з певним раундом. На початку раунду r, валідатор повинен отримати n-f вершин з раунду r-1. Кожен валідатор може транслювати одну вершину за раунд, кожна вершина повинна принаймні посилатися на n-f вершин з попереднього раунду. Через асинхронність мережі різні валідатори можуть спостерігати різні локальні види DAG.
Ключовою властивістю DAG є те, що вона не є неясною: якщо два вузли перевірки мають однакову вершину v у своєму локальному вигляді DAG, то вони мають абсолютно однакову причинно-історичну зв'язок для v.
Загальний порядок
Можна досягти згоди щодо загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Валідатори в DAG-Rider, Tusk і Bullshark трактують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра представляють голосування.
Хоча логіка інтерсекції груп у структурі DAG відрізняється, всі протоколи консенсусу на базі Narwhal мають таку структуру:
Забезпечена точка: кожні кілька раундів є заздалегідь визначений лідер, чий пік називається точкою прив'язки.
Точки прив'язки для сортування: валідатори незалежно, але однозначно вирішують, які точки прив'язки сортувати, а які пропускати.
Історія причинно-наслідкових зв'язків: валідатори по черзі обробляють упорядкований список анкорів, сортують попередньо невпорядковані вершини в історії причинно-наслідкових зв'язків кожного анкора.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) усі чесні вузли верифікації створювали список впорядкованих якорів, що мають однаковий префікс. У Shoal ми спостерігали:
Усі валідатори погоджуються з першим впорядкованим анкером.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між упорядкованими якорями в DAG. Затримка часткових синхронних версій краща за асинхронні версії, але все ще не є оптимальною.
Проблема 1: середній затримка блоку. У Bullshark кожна парна ітерація має опорну точку, а непарні ітерації трактуються як голосування. У звичайних випадках для сортування опорних точок потрібно дві ітерації DAG, але вершини в причинно-наслідковій історії опорної точки потребують більше ітерацій для очікування сортування опорних точок. У звичайних випадках непарні вершини потребують три ітерації, а парні не опорні вершини потребують чотири ітерації.
Питання 2: Затримка в ситуації з неполадками. Якщо лідер не в змозі вчасно надіслати маркер, неможливо його впорядкувати ( пропущено ), всі непорядковані вершини з попередніх раундів повинні чекати, поки наступний маркер не буде впорядкований. Це значно знижує продуктивність географічно розподіленої мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
Косяки
Shoal через конвеєр підсилює Bullshark( або будь-який протокол BFT, заснований на Narwhal), дозволяючи кожному раунду мати одну опорну точку, що зменшує затримку всіх неопорних вершин у DAG до трьох раундів. Shoal також вводить у DAG механізм репутації лідера з нульовими витратами, що надає перевагу вибору швидких лідерів.
Виклик
В протоколі DAG, конвеєризація та репутація лідера вважаються складними проблемами з таких причин:
Попередні спроби змінити основну логіку Bullshark в ланцюгу постачання, здається, виявилися неможливими.
Репутація лідерів вводиться в DiemBFT і формалізується в Carousel, динамічно вибираючи майбутніх лідерів на основі минулих досягнень валідаторів ( якорів у Bullshark ). Хоча розбіжність в ідентичності лідерів не порушує безпеки цих протоколів, це може призвести до абсолютно різного порядку в Bullshark, що піднімає основне питання: динамічний і детермінований вибір ротаційних якорів є необхідним для вирішення консенсусу, валідатори повинні досягти згоди щодо упорядкованої історії для вибору майбутніх якорів.
Як доказ складності питання, реалізація Bullshark ( включає ), яка наразі не підтримує ці функції в виробничому середовищі.
угода
Незважаючи на вищезгадані виклики, рішення приховане в простоті.
Shoal спирається на здатність виконувати локальні обчислення на основі DAG, реалізуючи можливість зберігати та перетворювати інформацію з попередніх раундів. Основуючись на спільному погодженні всіх валідаторів щодо першої впорядкованої якорної точки, Shoal послідовно комбінує кілька екземплярів Bullshark для конвеєрної обробки, що робить ( першою впорядкованою якорною точкою, ) причинно-історичний контекст якорної точки використовується для обчислення репутації лідера.
( конвеєр
V, яке відображає раунди на лідерів. Shoal по черзі запускає екземпляри Bullshark, кожен екземпляр якоря заздалегідь визначений за допомогою відображення F. Кожен екземпляр сортує якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark на DAG у першому раунді, який працював до визначення першої впорядкованої якорної точки ), як у раунді r ###. Усі валідатори погодилися з цією якорною точкою, отже, можна було впевнено погодитися на повторне тлумачення DAG з раунду r+1. Shoal запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal впорядковувати одну якореву точку за раунд. Перша якорева точка впорядковується першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який має свою власну якореву точку і впорядковується цим екземпляром, потім ще один новий екземпляр впорядковує якореву точку в третьому раунді, і так далі.
( Репутація лідера
Коли сортування Bullshark пропускає опорну точку, затримка збільшується. У цьому випадку конвеєр не може нічого зробити, оскільки новий екземпляр не може бути запущений до того, як завершиться сортування попередньої опорної точки. Shoal надає бали кожному вузлу перевірки за допомогою механізму репутації, щоб забезпечити менш імовірний вибір відповідного лідера для обробки втрачених опорних точок на основі їх недавньої історії активності. Валідаційники, які реагують і беруть участь у протоколі, отримують високі бали, в іншому випадку присвоюються низькі бали ) можуть зазнати краху, працювати повільно або чинити зло ###.
Ідея полягає в тому, щоб під час кожного оновлення балів детерміновано перепрограмувати попередньо визначену відображення F від раундів до лідера, з ухилом на користь лідера з високими балами. Щоб валідатори могли досягти консенсусу на новій відображенні, їм слід досягти консенсусу щодо балів, щоб досягти консенсусу в історії, що використовується для похідних балів.
У Shoal лінійні процеси та репутація лідерів природно поєднуються, оскільки вони використовують однакову основну технологію: повторне тлумачення DAG після досягнення консенсусу щодо першої впорядкованої якорної точки.
Єдина відмінність полягає в тому, що після р-го раунду сортування якорів, валідатор обчислює нову відображення F' починаючи з р+1 раунду на основі причинно-історичного контексту впорядкованих якорів р-го раунду. Потім валідатор з р+1 раунду починає використовувати оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark.
( Не потрібно більше тайм-аутів
Час очікування є критично важливим у всіх реалізаціях BFT з частковою синхронізацією, що базуються на лідерах. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, ускладнюючи процес налагодження та вимагаючи більше технологій спостереження.
Тайм-аути також значно збільшують затримку, оскільки важливо правильно їх налаштувати, що зазвичай вимагає динамічного коригування, яке сильно залежить від середовища ) мережі ###. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку за тайм-аут для лідера з помилкою. Тому налаштування тайм-аутів не повинні бути занадто консервативними, але якщо вони занадто короткі, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що за високого навантаження лідери в Jolteon/Hotstuff були перевантажені і тайм-аути спливли ще до того, як було досягнуто прогресу.
На жаль, протокол лідера (, такий як Hotstuff і Jolteon ), в основному потребує тайм-аутів, щоб забезпечити прогрес протоколу кожного разу, коли лідер виходить з ладу. Без тайм-аутів навіть зламаний лідер може назавжди зупинити протокол. Оскільки в асинхронний період неможливо відрізнити несправного та повільного лідера, тайм-аут може призвести до того, що вузли перевірки переглянуть зміни всіх лідерів без активності консенсусу.
У Bullshark тайм-аут використовується для побудови DAG, щоб забезпечити достатньо швидке додавання анкерних точок до DAG чесними лідерами під час синхронізації, щоб їх можна було впорядкувати.
Ми спостерігаємо, що конструкція DAG забезпечує "годинник" для оцінки швидкості мережі. Без затримок, поки n-f чесних валідаторів продовжують додавати вершини до DAG, раунд продовжить рухатися вперед. Хоча Bullshark може не бути в змозі впорядкувати ( з швидкістю мережі через проблеми з лідерами ), DAG все ще зростає зі швидкістю мережі, незважаючи на те, що деякі лідери мають проблеми або мережа асинхронна. Врешті-решт, коли безвідмовні лідери достатньо швидко транслюватимуть якорі, вся причинно-наслідкова історія якорів буде впорядкована.
Під час оцінки ми порівняли Bullshark у випадках з тайм-аутом та без нього:
Швидкі лідери, принаймні, швидші за інших валідаторів. У цьому випадку два методи забезпечують однакову затримку, оскільки якорі впорядковані та не використовують тайм-аути.
Помилковий лідер, у цьому випадку безперервний Bullshark забезпечує кращу затримку, оскільки верифікаційні вузли негайно пропустять свої анкери, тоді як верифікатори з паузою будуть чекати закінчення терміну до продовження.
Повільний лідер, це єдиний випадок, коли Bullshark має кращу продуктивність під час тайм-ауту. Тому що без паузі, якорі можуть бути пропущені, оскільки лідер не може досить швидко їх транслювати, а під час паузи, валідатори чекатимуть на якорі.
У Shoal уникнення тайм-ауту тісно пов'язане з репутацією лідера. Повторне очікування