Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно зменшивши затримку та вперше усунувши потребу в тайм-ауті в детерміністському фактичному протоколі. Загалом, в умовах безвідмовної роботи затримка Bullshark поліпшилась на 40%, а в умовах відмови - на 80%.
Shoal є фреймворком, який через конвеєр і репутацію лідера покращує будь-який протокол консенсусу на основі Narwhal (, такий як DAG-Rider, Tusk, Bullshark ). Конвеєр зменшує затримку сортування DAG, вводячи один анкер на кожному раунді, а репутація лідера додатково покращує затримку, забезпечуючи зв'язок анкера з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну конструкцію DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal забезпечити атрибут, відомий як універсальна відповідь, який містить оптимістичну відповідь, яка зазвичай потрібна.
Ця технологія дуже проста, вона передбачає послідовне виконання кількох екземплярів основного протоколу один за одним. Таким чином, при інстанціюванні Bullshark ми отримуємо групу "акул", які беруть участь у естафеті.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Фон
У процесі досягнення високої продуктивності блокчейн-мережі люди завжди концентрувалися на Падіння складності зв'язку. Однак цей підхід не призвів до значного збільшення пропускної спроможності. Наприклад, у ранніх версіях Diem реалізований Hotstuff забезпечував лише 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.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Загальна послідовність
Можна досягти згоди щодо загального порядку всіх вершин в 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-b7ed8888da112bae8d34c0fdb338b138.webp)
Shoal фрейм
Shoal вирішив ці дві проблеми затримки, він покращив Bullshark( або будь-який інший протокол BFT на базі Narwhal) через конвеєр, дозволяючи мати опорну точку в кожному раунді та зменшуючи затримку всіх не опорних вершин у DAG до трьох раундів. Shoal також впровадив механізм репутації лідера з нульовими витратами в DAG, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, проблеми з конвеєром і репутацією лідера вважаються складними з наступних причин:
Попередні конвеєри намагалися змінити основну логіку Bullshark, але це, по суті, здається неможливим.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel на основі динамічного вибору майбутніх лідерів відповідно до минулих показників валідаторів ( ідея якоря в Bullshark ). Хоча розбіжності в ідентичності лідера не порушують безпеку цих протоколів, у Bullshark це може призвести до зовсім іншого порядку, що піднімає основне питання: динамічний і детермінований вибір колесного якоря є необхідним для вирішення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутніх якорів.
Як доказ складності питання, реалізація Bullshark, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці функції.
Протокол
Попри вказані виклики, виявляється, що рішення приховане за простотою.
У Shoal, спираючись на можливість виконання локальних обчислень на основі DAG, реалізовано можливість зберігати та переінтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним спостереженням про першу впорядковану опору, Shoal послідовно комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ( першу впорядковану опору точкою перемикання екземплярів, а також ) причинно-історичні зв'язки опори використовуються для обчислення репутації лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Конвеєр
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/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутація лідерів
Під час пропуску анкера під час сортування Bullshark, затримка зростає. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не можна запустити, поки не буде замовлено анкер попереднього екземпляра. Shoal забезпечує, щоб у майбутньому навряд чи було обрано відповідного лідера для обробки втрачених анкерів, використовуючи механізм репутації для призначення кожному вузлу перевірки оцінки на основі історії нещодавньої активності кожного вузла перевірки. Верифікатори, які реагують на протокол і беруть участь у ньому, отримають високу оцінку, в іншому випадку вузли перевірки отримають низьку оцінку, оскільки вони можуть зазнати краху, бути повільними або чинити злочини.
Його концепція полягає в тому, щоб під час кожного оновлення балів детерміновано перераховувати попередньо визначене відображення F від раунду до лідера, віддаючи перевагу лідерам з вищими балами. Щоб валідатори досягли згоди щодо нового відображення, вони повинні досягти згоди щодо балів, таким чином досягнувши згоди щодо історії, що використовується для похідних балів.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують одну й ту ж основну технологію, а саме, повторне тлумачення DAG після досягнення згоди щодо першої впорядкованої опорної точки.
Насправді, єдина різниця полягає в тому, що після сортування анкерних точок на етапі r, валідаторам потрібно лише на основі причинно-історичної інформації впорядкованих анкерних точок на етапі r обчислити нове відображення F' починаючи з етапу r+1. Потім, з етапу r+1, вузли-валідатори використовують оновлену функцію вибору анкерних точок F' для виконання нової інстанції Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Немає більше затримок
Тайм-аут відіграє вирішальну роль у всіх реалізаціях синхронізації BFT з визначеністю на основі лідера. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно керувати і спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Час затримки також суттєво збільшує затримку, оскільки важливо належним чином їх налаштувати, і зазвичай їх потрібно динамічно налаштовувати, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повний штраф за затримку часу для несправного лідера. Тому налаштування часу затримки не повинні бути занадто обережними, але якщо час затримки занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff виявилися перевантаженими, і час затримки сплив ще до того, як вони змогли просунутися вперед.
На жаль, протоколи лідерів (, такі як Hotstuff та Jolteon ), по суті потребують затримки, щоб забезпечити кожного разу лідера.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією 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 ми отримуємо групу "акул", які беруть участь у естафеті.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Фон
У процесі досягнення високої продуктивності блокчейн-мережі люди завжди концентрувалися на Падіння складності зв'язку. Однак цей підхід не призвів до значного збільшення пропускної спроможності. Наприклад, у ранніх версіях Diem реалізований Hotstuff забезпечував лише 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.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Загальна послідовність
Можна досягти згоди щодо загального порядку всіх вершин в 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-b7ed8888da112bae8d34c0fdb338b138.webp)
Shoal фрейм
Shoal вирішив ці дві проблеми затримки, він покращив Bullshark( або будь-який інший протокол BFT на базі Narwhal) через конвеєр, дозволяючи мати опорну точку в кожному раунді та зменшуючи затримку всіх не опорних вершин у DAG до трьох раундів. Shoal також впровадив механізм репутації лідера з нульовими витратами в DAG, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, проблеми з конвеєром і репутацією лідера вважаються складними з наступних причин:
Попередні конвеєри намагалися змінити основну логіку Bullshark, але це, по суті, здається неможливим.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel на основі динамічного вибору майбутніх лідерів відповідно до минулих показників валідаторів ( ідея якоря в Bullshark ). Хоча розбіжності в ідентичності лідера не порушують безпеку цих протоколів, у Bullshark це може призвести до зовсім іншого порядку, що піднімає основне питання: динамічний і детермінований вибір колесного якоря є необхідним для вирішення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутніх якорів.
Як доказ складності питання, реалізація Bullshark, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці функції.
Протокол
Попри вказані виклики, виявляється, що рішення приховане за простотою.
У Shoal, спираючись на можливість виконання локальних обчислень на основі DAG, реалізовано можливість зберігати та переінтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним спостереженням про першу впорядковану опору, Shoal послідовно комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ( першу впорядковану опору точкою перемикання екземплярів, а також ) причинно-історичні зв'язки опори використовуються для обчислення репутації лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Конвеєр
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/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутація лідерів
Під час пропуску анкера під час сортування Bullshark, затримка зростає. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не можна запустити, поки не буде замовлено анкер попереднього екземпляра. Shoal забезпечує, щоб у майбутньому навряд чи було обрано відповідного лідера для обробки втрачених анкерів, використовуючи механізм репутації для призначення кожному вузлу перевірки оцінки на основі історії нещодавньої активності кожного вузла перевірки. Верифікатори, які реагують на протокол і беруть участь у ньому, отримають високу оцінку, в іншому випадку вузли перевірки отримають низьку оцінку, оскільки вони можуть зазнати краху, бути повільними або чинити злочини.
Його концепція полягає в тому, щоб під час кожного оновлення балів детерміновано перераховувати попередньо визначене відображення F від раунду до лідера, віддаючи перевагу лідерам з вищими балами. Щоб валідатори досягли згоди щодо нового відображення, вони повинні досягти згоди щодо балів, таким чином досягнувши згоди щодо історії, що використовується для похідних балів.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують одну й ту ж основну технологію, а саме, повторне тлумачення DAG після досягнення згоди щодо першої впорядкованої опорної точки.
Насправді, єдина різниця полягає в тому, що після сортування анкерних точок на етапі r, валідаторам потрібно лише на основі причинно-історичної інформації впорядкованих анкерних точок на етапі r обчислити нове відображення F' починаючи з етапу r+1. Потім, з етапу r+1, вузли-валідатори використовують оновлену функцію вибору анкерних точок F' для виконання нової інстанції Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Немає більше затримок
Тайм-аут відіграє вирішальну роль у всіх реалізаціях синхронізації BFT з визначеністю на основі лідера. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно керувати і спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Час затримки також суттєво збільшує затримку, оскільки важливо належним чином їх налаштувати, і зазвичай їх потрібно динамічно налаштовувати, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повний штраф за затримку часу для несправного лідера. Тому налаштування часу затримки не повинні бути занадто обережними, але якщо час затримки занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff виявилися перевантаженими, і час затримки сплив ще до того, як вони змогли просунутися вперед.
На жаль, протоколи лідерів (, такі як Hotstuff та Jolteon ), по суті потребують затримки, щоб забезпечити кожного разу лідера.