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, що значно нижче цільового показника 100k+ TPS.
Останній прорив зумовлений усвідомленням того, що розповсюдження даних є основним вузьким місцем, яке базується на протоколі лідерів, і може отримати вигоду від паралелізації. Система Narwhal відокремлює розповсюдження даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно розповсюджують дані, а компоненти консенсусу лише замовляють невелику кількість метаданих. У статті Narwhal повідомляється про пропускну спроможність 160 000 TPS.
Раніше представлений Quorum Store є реалізацією Narwhal, яка відокремлює поширення даних від консенсусу, щоб розширити поточний протокол консенсусу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint з зміною виду в стилі PBFT, що може знизити затримку Hotstuff на 33%. Однак протоколи консенсусу на основі лідера не можуть повністю використовувати потенціал пропускної здатності Narwhal. Незважаючи на те, що поширення даних відокремлено від консенсусу, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще залишається обмеженим.
Отже, було вирішено впровадити Bullshark на базі Narwhal DAG, що є консенсусним протоколом з нульовими витратами на комунікацію. На жаль, на відміну від Jolteon, структура 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. Хоча найбільш практична частина Bullshark має кращу затримку в синхронізованій версії, ніж в асинхронній, вона все ще далека від оптимальної.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має опорну точку, а вершини непарних раундів інтерпретуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб замовити опорні точки, однак вершини в причинній історії опорної точки потребують більше раундів, щоб дочекатися, поки опорні точки будуть відсортовані. У звичайних випадках вершини в непарних раундах потребують трьох раундів, а вершини непарних раундів - чотирьох раундів.
Питання 2: Затримка випадків збоїв. Наведений аналіз затримок стосується безвідмовного стану, з іншого боку, якщо лідер раунду не встигає достатньо швидко транслювати якорі, неможливо впорядкувати якорі (, тому вони пропускаються ), отже, всі невпорядковані вершин у перших раундах повинні чекати, поки наступний якір не буде впорядкований. Це значно знижує продуктивність географічно розподілених мереж, особливо тому, що Bullshark використовує тайм-аути для очікування лідера.
Shoal фрейм
Shoal підвищив обробку Bullshark( або будь-якого іншого BFT протоколу на основі Narwhal) через конвеєр, дозволяючи мати одну опору в кожному раунді і зменшуючи затримку всіх неопорних вершин у DAG до трьох раундів. Shoal також впровадив механізм репутації лідера з нульовими витратами в DAG, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними проблемами з наступних причин:
Попередні спроби обробки конвеєра змінити основну логіку Bullshark, але це, по суті, здається неможливим.
Репутація лідера впроваджується в DiemBFT і формалізується в Carousel, вона базується на динамічному виборі майбутніх лідерів на основі минулих досягнень валідаторів, ідея яких закладена в якорях Bullshark (. Хоча розбіжності в ідентичності лідера не порушують безпеки цих протоколів, в Bullshark це може призвести до зовсім інших порядків, що піднімає основне питання: динамічний і детермінований вибір обертових якорів є необхідним для досягнення консенсусу, і валідатори повинні дійти згоди щодо впорядкованої історії, щоб вибрати майбутні якорі.
Як доказ складності проблеми, ми зауважили, що реалізація Bullshark, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці функції.
![Детальний аналіз рамки Shoal: як зменшити затримки Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Протокол
Незважаючи на вищезазначені виклики, рішення приховане в простоті.
У Shoal ми покладаємося на можливість виконання локальних обчислень на DAG, а також реалізуємо здатність зберігати та переосмислювати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно поєднує кілька екземплярів Bullshark для їх потокового оброблення, що робить ) першим впорядкованим якорем і ( причинною історією якоря, використаною для обчислення репутації лідера.
Обробка конвеєра
V, що відображає раунди на лідерів. Shoal запускає екземпляри Bullshark один за одним, таким чином для кожного екземпляра якір заздалегідь визначається відображенням F. Кожен екземпляр замовляє якір, що ініціює перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював з ним до визначення першої впорядкованої точки якоря, наприклад, у раунді r. Усі валідатори погодилися з цією точкою якоря. Таким чином, усі валідатори можуть впевнено погодитися на перезапуск DAG, починаючи з раунду r+1. Shoal просто запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal замовляти одну якірну точку в кожному раунді. Якірні точки першого раунду впорядковані за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який сам має якірну точку, що впорядкована за цим екземпляром, після чого в третьому раунді замовляється ще один новий екземпляр з якірною точкою, і цей процес триває далі.
![Детальний огляд рамки Shoal: Як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Репутація лідера
Під час пропуску опорних точок під час сортування Bullshark затримка зростає. У такому випадку технологія конвеєрної обробки стає безсильною, оскільки новий екземпляр не може бути запущений до того, як буде замовлено попередній екземпляр опорної точки. Shoal забезпечує малоймовірність вибору відповідного лідера для обробки втрачених опорних точок у майбутньому, використовуючи механізм репутації, щоб призначити кожному валідатору бал на основі недавньої активності кожного вузла валідації. Валідаційні учасники, які відповідають і беруть участь у протоколі, отримають високі бали, в іншому випадку вузли валідації отримають низькі бали, оскільки вони можуть бути зламані, повільні або діяти шкідливо.
Його концепція полягає в тому, щоб при кожному оновленні балів визначити детерміноване перерахування передвстановленого відображення F від раундів до лідера, надаючи перевагу лідерам з високими балами. Щоб валідатори дійшли згоди щодо нового відображення, вони повинні досягти згоди щодо балів, таким чином досягнувши згоди в історії, що використовується для похідних балів.
У Shoal обробка конвеєра та репутація лідера можуть природно поєднуватися, оскільки вони використовують одну й ту ж основну технологію, а саме переосмислення DAG після досягнення згоди про першу впорядковану анкерну точку.
Насправді єдина різниця полягає в тому, що після сортування анкерів на етапі r, валідаторам потрібно лише на основі причинно-наслідкового історії упорядкованих анкерів на етапі r обчислити нову відображення F' з етапу r+1. Потім валідаторні вузли з етапу r+1 починають виконувати новий екземпляр Bullshark, використовуючи оновлену функцію вибору анкерів F'.
![Детальний аналіз рамки Shoal: Як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Немає більше тайм-аутів
Час вичерпання відіграє вирішальну роль у всіх реалізаціях детерміністичного часткового синхронного BFT, заснованих на лідерах. Однак, їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Часове перевищення також значно збільшує затримку, оскільки їх належна конфігурація є дуже важливою і зазвичай вимагає динамічного налаштування, оскільки вона сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол виплачує повний штраф за затримку через часове перевищення для несправного лідера. Тому налаштування часу перевищення не можуть бути занадто обережними, але якщо час перевищення занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff зазнають перевантаження, і перш ніж вони просунуться вперед, відбувається перевищення часу.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
21 лайків
Нагородити
21
9
Поділіться
Прокоментувати
0/400
RektCoaster
· 08-03 07:00
затримка знизилася так сильно? бик啊
Переглянути оригіналвідповісти на0
Degen4Breakfast
· 08-02 20:25
Забудь про це, коли якорь, то навіщо так ускладнювати?
Переглянути оригіналвідповісти на0
SatoshiLegend
· 08-02 17:14
Оптимізація DAG хоча й хороша, але не змінюючи своїх принципів, можна досягти мети. Під кодом немає таємниць.
Переглянути оригіналвідповісти на0
NonFungibleDegen
· 08-01 16:37
бичачий af на aptos rn... 80% швидше? напевно нічого сер
Framework Shoal значно підвищує продуктивність Bullshark на ланцюзі Aptos, затримка зменшена на 80%.
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, що значно нижче цільового показника 100k+ TPS.
Останній прорив зумовлений усвідомленням того, що розповсюдження даних є основним вузьким місцем, яке базується на протоколі лідерів, і може отримати вигоду від паралелізації. Система Narwhal відокремлює розповсюдження даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно розповсюджують дані, а компоненти консенсусу лише замовляють невелику кількість метаданих. У статті Narwhal повідомляється про пропускну спроможність 160 000 TPS.
Раніше представлений Quorum Store є реалізацією Narwhal, яка відокремлює поширення даних від консенсусу, щоб розширити поточний протокол консенсусу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint з зміною виду в стилі PBFT, що може знизити затримку Hotstuff на 33%. Однак протоколи консенсусу на основі лідера не можуть повністю використовувати потенціал пропускної здатності Narwhal. Незважаючи на те, що поширення даних відокремлено від консенсусу, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще залишається обмеженим.
Отже, було вирішено впровадити Bullshark на базі Narwhal DAG, що є консенсусним протоколом з нульовими витратами на комунікацію. На жаль, на відміну від Jolteon, структура 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. Хоча найбільш практична частина Bullshark має кращу затримку в синхронізованій версії, ніж в асинхронній, вона все ще далека від оптимальної.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має опорну точку, а вершини непарних раундів інтерпретуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб замовити опорні точки, однак вершини в причинній історії опорної точки потребують більше раундів, щоб дочекатися, поки опорні точки будуть відсортовані. У звичайних випадках вершини в непарних раундах потребують трьох раундів, а вершини непарних раундів - чотирьох раундів.
Питання 2: Затримка випадків збоїв. Наведений аналіз затримок стосується безвідмовного стану, з іншого боку, якщо лідер раунду не встигає достатньо швидко транслювати якорі, неможливо впорядкувати якорі (, тому вони пропускаються ), отже, всі невпорядковані вершин у перших раундах повинні чекати, поки наступний якір не буде впорядкований. Це значно знижує продуктивність географічно розподілених мереж, особливо тому, що Bullshark використовує тайм-аути для очікування лідера.
Shoal фрейм
Shoal підвищив обробку Bullshark( або будь-якого іншого BFT протоколу на основі Narwhal) через конвеєр, дозволяючи мати одну опору в кожному раунді і зменшуючи затримку всіх неопорних вершин у DAG до трьох раундів. Shoal також впровадив механізм репутації лідера з нульовими витратами в DAG, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними проблемами з наступних причин:
Попередні спроби обробки конвеєра змінити основну логіку Bullshark, але це, по суті, здається неможливим.
Репутація лідера впроваджується в DiemBFT і формалізується в Carousel, вона базується на динамічному виборі майбутніх лідерів на основі минулих досягнень валідаторів, ідея яких закладена в якорях Bullshark (. Хоча розбіжності в ідентичності лідера не порушують безпеки цих протоколів, в Bullshark це може призвести до зовсім інших порядків, що піднімає основне питання: динамічний і детермінований вибір обертових якорів є необхідним для досягнення консенсусу, і валідатори повинні дійти згоди щодо впорядкованої історії, щоб вибрати майбутні якорі.
Як доказ складності проблеми, ми зауважили, що реалізація Bullshark, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці функції.
![Детальний аналіз рамки Shoal: як зменшити затримки Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Протокол
Незважаючи на вищезазначені виклики, рішення приховане в простоті.
У Shoal ми покладаємося на можливість виконання локальних обчислень на DAG, а також реалізуємо здатність зберігати та переосмислювати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно поєднує кілька екземплярів Bullshark для їх потокового оброблення, що робить ) першим впорядкованим якорем і ( причинною історією якоря, використаною для обчислення репутації лідера.
Обробка конвеєра
V, що відображає раунди на лідерів. Shoal запускає екземпляри Bullshark один за одним, таким чином для кожного екземпляра якір заздалегідь визначається відображенням F. Кожен екземпляр замовляє якір, що ініціює перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював з ним до визначення першої впорядкованої точки якоря, наприклад, у раунді r. Усі валідатори погодилися з цією точкою якоря. Таким чином, усі валідатори можуть впевнено погодитися на перезапуск DAG, починаючи з раунду r+1. Shoal просто запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal замовляти одну якірну точку в кожному раунді. Якірні точки першого раунду впорядковані за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який сам має якірну точку, що впорядкована за цим екземпляром, після чого в третьому раунді замовляється ще один новий екземпляр з якірною точкою, і цей процес триває далі.
![Детальний огляд рамки Shoal: Як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Репутація лідера
Під час пропуску опорних точок під час сортування Bullshark затримка зростає. У такому випадку технологія конвеєрної обробки стає безсильною, оскільки новий екземпляр не може бути запущений до того, як буде замовлено попередній екземпляр опорної точки. Shoal забезпечує малоймовірність вибору відповідного лідера для обробки втрачених опорних точок у майбутньому, використовуючи механізм репутації, щоб призначити кожному валідатору бал на основі недавньої активності кожного вузла валідації. Валідаційні учасники, які відповідають і беруть участь у протоколі, отримають високі бали, в іншому випадку вузли валідації отримають низькі бали, оскільки вони можуть бути зламані, повільні або діяти шкідливо.
Його концепція полягає в тому, щоб при кожному оновленні балів визначити детерміноване перерахування передвстановленого відображення F від раундів до лідера, надаючи перевагу лідерам з високими балами. Щоб валідатори дійшли згоди щодо нового відображення, вони повинні досягти згоди щодо балів, таким чином досягнувши згоди в історії, що використовується для похідних балів.
У Shoal обробка конвеєра та репутація лідера можуть природно поєднуватися, оскільки вони використовують одну й ту ж основну технологію, а саме переосмислення DAG після досягнення згоди про першу впорядковану анкерну точку.
Насправді єдина різниця полягає в тому, що після сортування анкерів на етапі r, валідаторам потрібно лише на основі причинно-наслідкового історії упорядкованих анкерів на етапі r обчислити нову відображення F' з етапу r+1. Потім валідаторні вузли з етапу r+1 починають виконувати новий екземпляр Bullshark, використовуючи оновлену функцію вибору анкерів F'.
![Детальний аналіз рамки Shoal: Як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Немає більше тайм-аутів
Час вичерпання відіграє вирішальну роль у всіх реалізаціях детерміністичного часткового синхронного BFT, заснованих на лідерах. Однак, їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Часове перевищення також значно збільшує затримку, оскільки їх належна конфігурація є дуже важливою і зазвичай вимагає динамічного налаштування, оскільки вона сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол виплачує повний штраф за затримку через часове перевищення для несправного лідера. Тому налаштування часу перевищення не можуть бути занадто обережними, але якщо час перевищення занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff зазнають перевантаження, і перш ніж вони просунуться вперед, відбувається перевищення часу.