Shoal фреймворк: значно зменшує затримку Bullshark на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно знизивши затримку, та вперше усунула потребу в таймаутах у детерміністичному практичному протоколі. Загалом, у безвідмовному режимі затримка Bullshark покращилася на 40%, у випадку відмови – на 80%.
Shoal є фреймворком, який посилює консенсусний протокол на основі Narwhal (, як-от DAG-Rider, Tusk, Bullshark ), за допомогою конвеєра та механізму репутації лідера. Конвеєр зменшує затримку сортування DAG, вводячи опорну точку в кожному раунді, а репутація лідера ще більше покращує проблему затримки, забезпечуючи зв'язок опорної точки з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронне побудування DAG, щоб усунути тайм-аути в усіх сценаріях. Це дозволяє Shoal забезпечувати властивість універсальної реакції, яка містить зазвичай необхідну оптимістичну реакцію.
Ця технологія є дуже простою, вона передбачає послідовне виконання кількох екземплярів базового протоколу. Таким чином, коли ми використовуємо Bullshark для інстанціювання, ми отримуємо групу "акул", що здійснює естафету.
Фон
У процесі досягнення високої продуктивності мережі блокчейн, люди завжди зосереджувалися на зниженні складності зв'язку. Однак цей підхід не призвів до значного збільшення пропускної здатності. Наприклад, Hotstuff, реалізований у ранніх версіях Diem, досяг лише 3500 TPS, що значно нижче цільового показника в 100000+ TPS.
Нещодавні прориви пов'язані з усвідомленням того, що розповсюдження даних є основною затримкою, що базується на протоколі лідерства, і може виграти від паралелізації. Система Narwhal відокремлює розповсюдження даних від основної логіки консенсусу, пропонуючи архітектуру, в якій усі валідатори одночасно розповсюджують дані, а компонент консенсусу лише впорядковує невелику кількість метаданих. У статті Narwhal повідомляється про пропускну спроможність 160000 TPS.
Раніше ми представили Quorum Store, тобто нашу реалізацію Narwhal, яка відокремлює поширення даних від консенсусу, а також як використовувати це для розширення поточного протоколу консенсусу Jolteon. Jolteon - це протокол, заснований на лідері, який поєднує лінійний швидкий шлях Tendermint і зміни перегляду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Проте очевидно, що протоколи консенсусу, засновані на лідері, не можуть повністю використати потенціал пропускної здатності Narwhal. Незважаючи на те, що поширення даних відокремлено від консенсусу, з підвищенням пропускної здатності лідер Hotstuff/Jolteon все ще залишається обмеженим.
Отже, ми вирішили розгорнути Bullshark на Narwhal DAG, протокол консенсусу з нульовими витратами на зв'язок. На жаль, у порівнянні з Jolteon, структура DAG, що підтримує високу пропускну здатність Bullshark, має 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 як протокол консенсусу, де вершини представляють пропозиції, а ребра - голоси.
Хоча логіка групового перетину в структурі DAG відрізняється, усі існуючі консенсусні протоколи на базі Narwhal мають таку структуру:
Запланована точка якоря: кожні кілька раундів (, як у Bullshark, через два раунди ) є заздалегідь визначений лідер, вершина якого називається точкою якоря.
Точки сортування: валідатор незалежно, але детерміновано вирішує, які точки сортувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори обробляють впорядкований список анкорів по одному, для кожного анкора, сортують усі попередні невпорядковані вершини в його причинно-наслідковій історії за певними детермінованими правилами.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) всі чесні верифікаційні вузли створювали впорядкований список якорів, що має однаковий префікс. У Shoal ми робимо такі спостереження щодо всіх цих протоколів:
Усі валідатори погоджуються з першим упорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча частково синхронна версія Bullshark має кращу затримку в порівнянні з асинхронною версією, вона далекий від оптимальної.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має анкерну точку, а вершини непарного раунду тлумачаться як голосування. У звичайних випадках потрібно два раунди DAG для впорядкування анкерних точок, однак вершини в причинно-історичному контексті анкерних точок потребують більше раундів, щоб дочекатися впорядкування анкерних точок. У звичайних випадках вершини в непарному раунді потребують трьох раундів, а вершини, що не є анкерними, в парному раунді потребують чотирьох раундів.
Питання 2: ситуація з відмовою затримка. Вищевказаний аналіз затримки стосується випадків без відмов, з іншого боку, якщо лідер певного раунду не встигає достатньо швидко транслювати анкери, то неможливо відсортувати цей анкери (, тому він пропускається ), отже, всі не відсортовані вершини з попередніх раундів повинні чекати, поки наступний анкери не буде відсортований. Це значно знижує продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує тайм-аути для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Рамки косяка
Shoal вирішив ці дві затримки, він посилив Bullshark( або будь-який інший протокол BFT на базі Narwhal) через конвеєр, що дозволяє мати один якорний елемент на кожному раунді та зменшує затримку всіх неякорних вершин у DAG до трьох раундів. Shoal також впровадив у DAG механізм репутації лідера з нульовими витратами, що дозволяє обирати швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєри та репутація лідерів вважаються складними проблемами, з наступних причин:
Попередні спроби модернізувати основну логіку Bullshark у ланцюгах постачання, здається, були неможливими за своєю суттю.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel, базуючись на динамічному виборі майбутніх лідерів відповідно до минулих досягнень валідаторів у (Bullshark, ідеї якоря ). Хоча розбіжності у статусі лідера не порушують безпеки цих протоколів, у Bullshark це може призвести до зовсім іншого порядку, що піднімає основне питання: динамічний і детермінований вибір обертового якоря необхідний для вирішення консенсусу, і валідатори повинні досягти згоди щодо упорядкованої історії для вибору майбутнього якоря.
Як доказ складності проблеми, ми звертаємо увагу на реалізацію Bullshark, яка, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці особливості.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Протокол
Хоча існують вищезгадані виклики, але насправді рішення приховане в простоті.
У Shoal ми покладаємося на можливості виконання локальних обчислень на DAG та реалізуємо можливість збереження та повторної інтерпретації інформації з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ( перше впорядковане якірним точкою екземпляра, а ) причинну історію якоря використовують для обчислення репутації лідера.
Конвеєр
V, яке відображає раунди на лідерів. Shoal по одному запускає екземпляри Bullshark, так що для кожного екземпляра якір попередньо визначається відображенням F. Кожен екземпляр впорядковує якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark на першому раунді DAG і працював над ним, поки не було визначено першу впорядковану опору, наприклад, на раунді r. Усі валідатори погодились з цією опорою. Таким чином, усі валідатори можуть з упевненістю погодитися на повторну інтерпретацію DAG, починаючи з раунду r+1. Shoal лише в раунді r+1 запустив новий екземпляр Bullshark.
У найкращому випадку це дозволяє Shoal у кожному раунді сортувати якір. Якір першого раунду сортується за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який сам має якір, що сортується за цим екземпляром, потім інший новий екземпляр у третьому раунді сортує якір, і цей процес продовжується.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/social/moments-9f789cb669fcc244ea7ff7648e48b4)
Репутація лідера
Під час пропуску анкерних точок під час сортування Bullshark затримка зростає. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не може бути запущено до сортування анкерної точки попереднього екземпляра. Shoal забезпечує меншу ймовірність обрання відповідного лідера для обробки втрачених анкерів у майбутньому, присвоюючи кожному валідатору бал на основі історії нещодавньої активності кожного валідатора за допомогою механізму репутації. Валідатори, які реагують і беруть участь у протоколі, отримають високий бал, інакше валідатору буде присвоєно низький бал, оскільки він може впасти, працювати повільно або діяти зловмисно.
Його концепція полягає в тому, щоб при кожному оновленні балів детерміністично перераховувати попередньо визначене відображення F від раундів до лідера, надаючи перевагу лідерам з вищими балами. Щоб валідатори досягли консенсусу на новому відображенні, вони повинні досягти консенсусу з балами, тим самим досягнувши консенсусу в історії, що використовується для похідних балів.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують однакову основну технологію, а саме, повторну інтерпретацію DAG після досягнення консенсусу щодо першої упорядкованої анкери.
Насправді, єдина різниця полягає в тому, що після сортування якорів у r-му раунді, валідатору потрібно лише на основі причинно-історії впорядкованих якорів у r-му раунді обчислити нову відображення F' з r+1 раунду. Потім вузли валідації починають використовувати оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark з r+1 раунду.
Немає більше тайм-аутів
Час вичерпання відіграє вирішальну роль у всіх реалізаціях детерміністичного BFT на основі лідера. Проте, їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Час вичерпання також значно збільшить затримку, оскільки важливо правильно їх налаштувати, і зазвичай потрібно динамічно коригувати, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повну затримку за час вичерпання для несправного лідера.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
6
Поділіться
Прокоментувати
0/400
CryptoSurvivor
· 18год тому
бик вау ця хвиля оновлень прискорила aptos
Переглянути оригіналвідповісти на0
SelfSovereignSteve
· 18год тому
Це оновлення бик 40% підвищення занадто жорстке
Переглянути оригіналвідповісти на0
GasFeeCrier
· 18год тому
Парування, тепер проблема затримки вирішена.
Переглянути оригіналвідповісти на0
MissedTheBoat
· 18год тому
Торгівля криптовалютою невдахи нарешті отримала прибуток
Shoal рамка значно знизила затримку Bullshark Aptos Блокчейн
Shoal фреймворк: значно зменшує затримку Bullshark на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно знизивши затримку, та вперше усунула потребу в таймаутах у детерміністичному практичному протоколі. Загалом, у безвідмовному режимі затримка Bullshark покращилася на 40%, у випадку відмови – на 80%.
Shoal є фреймворком, який посилює консенсусний протокол на основі Narwhal (, як-от DAG-Rider, Tusk, Bullshark ), за допомогою конвеєра та механізму репутації лідера. Конвеєр зменшує затримку сортування DAG, вводячи опорну точку в кожному раунді, а репутація лідера ще більше покращує проблему затримки, забезпечуючи зв'язок опорної точки з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронне побудування DAG, щоб усунути тайм-аути в усіх сценаріях. Це дозволяє Shoal забезпечувати властивість універсальної реакції, яка містить зазвичай необхідну оптимістичну реакцію.
Ця технологія є дуже простою, вона передбачає послідовне виконання кількох екземплярів базового протоколу. Таким чином, коли ми використовуємо Bullshark для інстанціювання, ми отримуємо групу "акул", що здійснює естафету.
Фон
У процесі досягнення високої продуктивності мережі блокчейн, люди завжди зосереджувалися на зниженні складності зв'язку. Однак цей підхід не призвів до значного збільшення пропускної здатності. Наприклад, Hotstuff, реалізований у ранніх версіях Diem, досяг лише 3500 TPS, що значно нижче цільового показника в 100000+ TPS.
Нещодавні прориви пов'язані з усвідомленням того, що розповсюдження даних є основною затримкою, що базується на протоколі лідерства, і може виграти від паралелізації. Система Narwhal відокремлює розповсюдження даних від основної логіки консенсусу, пропонуючи архітектуру, в якій усі валідатори одночасно розповсюджують дані, а компонент консенсусу лише впорядковує невелику кількість метаданих. У статті Narwhal повідомляється про пропускну спроможність 160000 TPS.
Раніше ми представили Quorum Store, тобто нашу реалізацію Narwhal, яка відокремлює поширення даних від консенсусу, а також як використовувати це для розширення поточного протоколу консенсусу Jolteon. Jolteon - це протокол, заснований на лідері, який поєднує лінійний швидкий шлях Tendermint і зміни перегляду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Проте очевидно, що протоколи консенсусу, засновані на лідері, не можуть повністю використати потенціал пропускної здатності Narwhal. Незважаючи на те, що поширення даних відокремлено від консенсусу, з підвищенням пропускної здатності лідер Hotstuff/Jolteon все ще залишається обмеженим.
Отже, ми вирішили розгорнути Bullshark на Narwhal DAG, протокол консенсусу з нульовими витратами на зв'язок. На жаль, у порівнянні з Jolteon, структура DAG, що підтримує високу пропускну здатність Bullshark, має 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 як протокол консенсусу, де вершини представляють пропозиції, а ребра - голоси.
Хоча логіка групового перетину в структурі DAG відрізняється, усі існуючі консенсусні протоколи на базі Narwhal мають таку структуру:
Запланована точка якоря: кожні кілька раундів (, як у Bullshark, через два раунди ) є заздалегідь визначений лідер, вершина якого називається точкою якоря.
Точки сортування: валідатор незалежно, але детерміновано вирішує, які точки сортувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори обробляють впорядкований список анкорів по одному, для кожного анкора, сортують усі попередні невпорядковані вершини в його причинно-наслідковій історії за певними детермінованими правилами.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) всі чесні верифікаційні вузли створювали впорядкований список якорів, що має однаковий префікс. У Shoal ми робимо такі спостереження щодо всіх цих протоколів:
Усі валідатори погоджуються з першим упорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча частково синхронна версія Bullshark має кращу затримку в порівнянні з асинхронною версією, вона далекий від оптимальної.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має анкерну точку, а вершини непарного раунду тлумачаться як голосування. У звичайних випадках потрібно два раунди DAG для впорядкування анкерних точок, однак вершини в причинно-історичному контексті анкерних точок потребують більше раундів, щоб дочекатися впорядкування анкерних точок. У звичайних випадках вершини в непарному раунді потребують трьох раундів, а вершини, що не є анкерними, в парному раунді потребують чотирьох раундів.
Питання 2: ситуація з відмовою затримка. Вищевказаний аналіз затримки стосується випадків без відмов, з іншого боку, якщо лідер певного раунду не встигає достатньо швидко транслювати анкери, то неможливо відсортувати цей анкери (, тому він пропускається ), отже, всі не відсортовані вершини з попередніх раундів повинні чекати, поки наступний анкери не буде відсортований. Це значно знижує продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує тайм-аути для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Рамки косяка
Shoal вирішив ці дві затримки, він посилив Bullshark( або будь-який інший протокол BFT на базі Narwhal) через конвеєр, що дозволяє мати один якорний елемент на кожному раунді та зменшує затримку всіх неякорних вершин у DAG до трьох раундів. Shoal також впровадив у DAG механізм репутації лідера з нульовими витратами, що дозволяє обирати швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєри та репутація лідерів вважаються складними проблемами, з наступних причин:
Попередні спроби модернізувати основну логіку Bullshark у ланцюгах постачання, здається, були неможливими за своєю суттю.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel, базуючись на динамічному виборі майбутніх лідерів відповідно до минулих досягнень валідаторів у (Bullshark, ідеї якоря ). Хоча розбіжності у статусі лідера не порушують безпеки цих протоколів, у Bullshark це може призвести до зовсім іншого порядку, що піднімає основне питання: динамічний і детермінований вибір обертового якоря необхідний для вирішення консенсусу, і валідатори повинні досягти згоди щодо упорядкованої історії для вибору майбутнього якоря.
Як доказ складності проблеми, ми звертаємо увагу на реалізацію Bullshark, яка, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці особливості.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Протокол
Хоча існують вищезгадані виклики, але насправді рішення приховане в простоті.
У Shoal ми покладаємося на можливості виконання локальних обчислень на DAG та реалізуємо можливість збереження та повторної інтерпретації інформації з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ( перше впорядковане якірним точкою екземпляра, а ) причинну історію якоря використовують для обчислення репутації лідера.
Конвеєр
V, яке відображає раунди на лідерів. Shoal по одному запускає екземпляри Bullshark, так що для кожного екземпляра якір попередньо визначається відображенням F. Кожен екземпляр впорядковує якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark на першому раунді DAG і працював над ним, поки не було визначено першу впорядковану опору, наприклад, на раунді r. Усі валідатори погодились з цією опорою. Таким чином, усі валідатори можуть з упевненістю погодитися на повторну інтерпретацію DAG, починаючи з раунду r+1. Shoal лише в раунді r+1 запустив новий екземпляр Bullshark.
У найкращому випадку це дозволяє Shoal у кожному раунді сортувати якір. Якір першого раунду сортується за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який сам має якір, що сортується за цим екземпляром, потім інший новий екземпляр у третьому раунді сортує якір, і цей процес продовжується.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/social/moments-9f789cb669fcc244ea7ff7648e48b4)
Репутація лідера
Під час пропуску анкерних точок під час сортування Bullshark затримка зростає. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не може бути запущено до сортування анкерної точки попереднього екземпляра. Shoal забезпечує меншу ймовірність обрання відповідного лідера для обробки втрачених анкерів у майбутньому, присвоюючи кожному валідатору бал на основі історії нещодавньої активності кожного валідатора за допомогою механізму репутації. Валідатори, які реагують і беруть участь у протоколі, отримають високий бал, інакше валідатору буде присвоєно низький бал, оскільки він може впасти, працювати повільно або діяти зловмисно.
Його концепція полягає в тому, щоб при кожному оновленні балів детерміністично перераховувати попередньо визначене відображення F від раундів до лідера, надаючи перевагу лідерам з вищими балами. Щоб валідатори досягли консенсусу на новому відображенні, вони повинні досягти консенсусу з балами, тим самим досягнувши консенсусу в історії, що використовується для похідних балів.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують однакову основну технологію, а саме, повторну інтерпретацію DAG після досягнення консенсусу щодо першої упорядкованої анкери.
Насправді, єдина різниця полягає в тому, що після сортування якорів у r-му раунді, валідатору потрібно лише на основі причинно-історії впорядкованих якорів у r-му раунді обчислити нову відображення F' з r+1 раунду. Потім вузли валідації починають використовувати оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark з r+1 раунду.
Немає більше тайм-аутів
Час вичерпання відіграє вирішальну роль у всіх реалізаціях детерміністичного BFT на основі лідера. Проте, їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Час вичерпання також значно збільшить затримку, оскільки важливо правильно їх налаштувати, і зазвичай потрібно динамічно коригувати, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повну затримку за час вичерпання для несправного лідера.