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, протокол консенсусу з нульовими витратами на комунікацію. На жаль, підтримка структури DAG з високою пропускною здатністю для Bullshark призвела до 50% затримки у порівнянні з Jolteon.
У цій статті описується, як 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.
Загальний порядок
Можна досягти узгодженості загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk та Bullshark інтерпретують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра представляють голосування.
Хоча логіка групових перетинів у структурі DAG різна, усі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована опорна точка: кожні кілька раундів буде заздалегідь визначений лідер, вершина лідера називається опорною точкою;
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки замовити, а які пропустити;
Сортування причинно-наслідкової історії: валідатори по черзі обробляють свої впорядковані списки анкорів і сортують всі попередні неупорядковані вершини в причинно-наслідковій історії кожного анкору.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (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 фрейм
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 просто запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє 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 раунду.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
Немає більше затримок
Час затримки відіграє вирішальну роль у всіх реалізаціях BFT з частковою синхронізацією на основі лідера. Проте, їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження і вимагає більше технік спостереження.
Час затримки також значно збільшить затримку, оскільки важливо правильно їх налаштувати, і зазвичай потрібна динамічна корекція, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку для несправного лідера. Тому налаштування тайм-аутів не повинні бути надто обережними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігаємо
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Shoal фреймворк значно знизив затримку консенсусу Bullshark на Aptos на 40%-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, протокол консенсусу з нульовими витратами на комунікацію. На жаль, підтримка структури DAG з високою пропускною здатністю для Bullshark призвела до 50% затримки у порівнянні з Jolteon.
У цій статті описується, як 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.
Загальний порядок
Можна досягти узгодженості загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk та Bullshark інтерпретують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра представляють голосування.
Хоча логіка групових перетинів у структурі DAG різна, усі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована опорна точка: кожні кілька раундів буде заздалегідь визначений лідер, вершина лідера називається опорною точкою;
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки замовити, а які пропустити;
Сортування причинно-наслідкової історії: валідатори по черзі обробляють свої впорядковані списки анкорів і сортують всі попередні неупорядковані вершини в причинно-наслідковій історії кожного анкору.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (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 фрейм
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 просто запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє 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 раунду.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
Немає більше затримок
Час затримки відіграє вирішальну роль у всіх реалізаціях BFT з частковою синхронізацією на основі лідера. Проте, їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження і вимагає більше технік спостереження.
Час затримки також значно збільшить затримку, оскільки важливо правильно їх налаштувати, і зазвичай потрібна динамічна корекція, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку для несправного лідера. Тому налаштування тайм-аутів не повинні бути надто обережними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігаємо