Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно знизивши затримки, і вперше в детермінаційному реальному протоколі усунула потребу в паузах. Загалом, затримка Bullshark покращилася на 40% у безвідмовному режимі та на 80% у випадку з відмовами.
Shoal є фреймворком, який покращує будь-який протокол консенсусу на основі Narwhal ( через конвеєр і репутацію лідера, такі як DAG-Rider, Tusk, Bullshark ). Конвеєр зменшує затримки сортування DAG, вводячи анкор в кожному раунді, а репутація лідера додатково покращує затримки, забезпечуючи зв'язок анкорів з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну конструкцію DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal надавати властивість, яку ми називаємо загальною реакцією, яка містить зазвичай необхідну оптимістичну відповідь.
Технічно, 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, протокол консенсусу з нульовими витратами на зв'язок. На жаль, структура DAG, яка підтримує високий обсяг даних Bullshark, приносить витрати затримки в розмірі 50% у порівнянні з Jolteon.
Ця стаття описує, як 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 мають таку структуру:
Запланована опора: кожні кілька раундів (, як у Bullshark, через два раунди ) буде попередньо визначений лідер, верхня точка лідера називається опорою;
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки сортування враховувати, а які пропускати;
Сортировка причинно-наслідкової історії: валідатори по одному обробляють упорядкований список якорів, для кожного якоря, за допомогою детермінованих правил сортують усі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) всі чесні вузли перевірки створили впорядкований список якорів, що має спільний префікс. У Shoal ми робимо такі спостереження щодо всіх наведених вище протоколів:
Усі валідатори погоджуються з першим упорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є більш практичною і має кращу затримку, ніж асинхронна версія, вона все ще далека від оптимальної.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має анкерну точку, а вершини непарного раунду інтерпретуються як голосування. У звичайних випадках для сортування анкерних точок потрібно два раунди DAG, однак вершини з причинно-історії анкерів потребують більше раундів, щоб дочекатися сортування анкерів. У звичайних випадках вершини в непарному раунді потребують трьох раундів, а вершини, що не є анкерними, в парному раунді потребують чотирьох раундів.
Проблема 2: Затримка у випадках збоїв. Вищезгаданий аналіз затримки стосується випадків без збоїв, з іншого боку, якщо лідер раунду не встигне досить швидко передати контрольну точку, то неможливо буде відсортувати контрольну точку (, тому її пропускають ), внаслідок чого всі несортовані вершини з попередніх раундів повинні чекати, поки наступна контрольна точка буде відсортована. Це значно знижує продуктивність географічної реплікації мережі, особливо враховуючи, що Bullshark використовує тайм-аути для очікування лідера.
Косяки
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. Потім валідаційні вузли починають використовувати оновлену функцію вибору анкерів F' для виконання нової інстанції Bullshark з раунду r+1.
![Детальний аналіз рамки Shoal: як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Немає більше тайм-аутів
Тайм-аут відіграє життєво важливу роль у всіх реалізаціях BFT з частковою синхронізацією, основаних на лідерах. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження та вимагає більше технік спостереження.
Тайм-аут також значно збільшує затримку, оскільки дуже важливо правильно їх налаштувати, і зазвичай їх потрібно динамічно коригувати, оскільки вони сильно залежать від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку тайм-ауту для несправного лідера. Таким чином, налаштування тайм-ауту не може бути занадто обережним, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не справлялися з навантаженням, і тайм-аут спливав до того, як вони змогли просунутися.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
20 лайків
Нагородити
20
4
Поділіться
Прокоментувати
0/400
DeFiChef
· 07-03 15:05
Це підвищення продуктивності на 40% привабливе!
Переглянути оригіналвідповісти на0
TokenEconomist
· 07-02 09:36
насправді, архітектура shoal є шедевром теорії ігор. уявіть, що це як рівновага Неша, де валідатори оптимізують репутацію = f(швидкість, надійність)...
Переглянути оригіналвідповісти на0
WhaleSurfer
· 07-02 09:33
бик бик бик Перевищено ліміт!
Переглянути оригіналвідповісти на0
TokenSleuth
· 07-02 09:24
Aptos ця оптимізація бик а затримка знизилась так сильно
Shoal структура значно знизила затримку Bullshark на Aptos, потік та репутаційний механізм суттєво підвищили продуктивність.
Shoal框架: покращений Bullshark затримка на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно знизивши затримки, і вперше в детермінаційному реальному протоколі усунула потребу в паузах. Загалом, затримка Bullshark покращилася на 40% у безвідмовному режимі та на 80% у випадку з відмовами.
Shoal є фреймворком, який покращує будь-який протокол консенсусу на основі Narwhal ( через конвеєр і репутацію лідера, такі як DAG-Rider, Tusk, Bullshark ). Конвеєр зменшує затримки сортування DAG, вводячи анкор в кожному раунді, а репутація лідера додатково покращує затримки, забезпечуючи зв'язок анкорів з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну конструкцію DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal надавати властивість, яку ми називаємо загальною реакцією, яка містить зазвичай необхідну оптимістичну відповідь.
Технічно, 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, протокол консенсусу з нульовими витратами на зв'язок. На жаль, структура DAG, яка підтримує високий обсяг даних Bullshark, приносить витрати затримки в розмірі 50% у порівнянні з Jolteon.
Ця стаття описує, як 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 мають таку структуру:
Запланована опора: кожні кілька раундів (, як у Bullshark, через два раунди ) буде попередньо визначений лідер, верхня точка лідера називається опорою;
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки сортування враховувати, а які пропускати;
Сортировка причинно-наслідкової історії: валідатори по одному обробляють упорядкований список якорів, для кожного якоря, за допомогою детермінованих правил сортують усі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) всі чесні вузли перевірки створили впорядкований список якорів, що має спільний префікс. У Shoal ми робимо такі спостереження щодо всіх наведених вище протоколів:
Усі валідатори погоджуються з першим упорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є більш практичною і має кращу затримку, ніж асинхронна версія, вона все ще далека від оптимальної.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має анкерну точку, а вершини непарного раунду інтерпретуються як голосування. У звичайних випадках для сортування анкерних точок потрібно два раунди DAG, однак вершини з причинно-історії анкерів потребують більше раундів, щоб дочекатися сортування анкерів. У звичайних випадках вершини в непарному раунді потребують трьох раундів, а вершини, що не є анкерними, в парному раунді потребують чотирьох раундів.
Проблема 2: Затримка у випадках збоїв. Вищезгаданий аналіз затримки стосується випадків без збоїв, з іншого боку, якщо лідер раунду не встигне досить швидко передати контрольну точку, то неможливо буде відсортувати контрольну точку (, тому її пропускають ), внаслідок чого всі несортовані вершини з попередніх раундів повинні чекати, поки наступна контрольна точка буде відсортована. Це значно знижує продуктивність географічної реплікації мережі, особливо враховуючи, що Bullshark використовує тайм-аути для очікування лідера.
Косяки
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. Потім валідаційні вузли починають використовувати оновлену функцію вибору анкерів F' для виконання нової інстанції Bullshark з раунду r+1.
![Детальний аналіз рамки Shoal: як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Немає більше тайм-аутів
Тайм-аут відіграє життєво важливу роль у всіх реалізаціях BFT з частковою синхронізацією, основаних на лідерах. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження та вимагає більше технік спостереження.
Тайм-аут також значно збільшує затримку, оскільки дуже важливо правильно їх налаштувати, і зазвичай їх потрібно динамічно коригувати, оскільки вони сильно залежать від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку тайм-ауту для несправного лідера. Таким чином, налаштування тайм-ауту не може бути занадто обережним, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не справлялися з навантаженням, і тайм-аут спливав до того, як вони змогли просунутися.
На жаль, на основі лідерства