Shoal фреймворк: як зменшити затримку Bullshark на Aptos?
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно знизивши затримку, і вперше усунула потребу в таймаутах у детерминированому реальному протоколі. Загалом, у безвідмовному режимі затримка Bullshark була покращена на 40%, а в умовах відмови — на 80%.
Shoal є фреймворком, який посилює консенсусний протокол на основі Narwhal за допомогою обробки з конвеєром і механізму репутації лідера (, такого як DAG-Rider, Tusk, Bullshark ). Обробка з конвеєром зменшує затримку сортування DAG, вводячи в кожному раунді опорну точку, а механізм репутації лідера далі покращує проблему затримки, забезпечуючи зв'язок опорної точки з найшвидшими вузлами валідації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну побудову DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal забезпечити характеристики універсальної реакції, включаючи зазвичай необхідну оптимістичну реакцію.
Ця технологія дуже проста, вона передбачає послідовний запуск кількох екземплярів підлягаючого протоколу. Тому, коли ми використовуємо Bullshark для інстанціювання, ми отримуємо групу "акул", які беруть участь у естафеті.
Фон
У процесі досягнення високої продуктивності блокчейн-мережі люди завжди звертали увагу на зменшення складності зв'язку. Однак цей підхід не призвів до значного підвищення пропускної спроможності. Наприклад, реалізація Hotstuff у ранніх версіях Diem досягла лише 3500 TPS, що значно нижче цільового показника 100000+ TPS.
Недавній прорив зумовлений усвідомленням того, що поширення даних є основною перешкодою, яка базується на угодах лідерів, і може отримати вигоду від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно поширюють дані, тоді як компонент консенсусу лише сортує невелику кількість метаданих. У статті Narwhal повідомляється про пропускну здатність 160000 TPS.
Aptos раніше представив Quorum Store, тобто реалізацію Narwhal, яка відокремлює розповсюдження даних від консенсусу, а також те, як його можна використати для розширення нинішнього консенсусного протоколу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint і зміни вигляду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Однак очевидно, що протоколи консенсусу на основі лідера не можуть повністю використати потенціал пропускної спроможності Narwhal. Незважаючи на те, що розповсюдження даних розділено з консенсусом, лідери Hotstuff/Jolteon все ще обмежені з ростом пропускної спроможності.
Отже, Aptos вирішив розгорнути 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 мають таку структуру:
Запланована точка якоря: кожні кілька раундів (, наприклад, у Bullshark через два раунди ) буде заздалегідь визначений лідер, вершина якого називається точкою якоря.
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки сортувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по одному обробляють свої упорядковані списки якорів, і для кожного якоря за допомогою деяких детермінованих правил сортують всі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) всі чесні вузли перевірки створили впорядкований список якорів, щоб усі списки ділилися однаковим префіксом. У Shoal зроблено такі спостереження щодо всіх наведених вище протоколів:
Усі валідатори погоджуються на першу впорядковану опору.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є більш практичною та має кращу затримку в порівнянні з асинхронною версією, вона все ще далекий від оптимального.
Проблема 1: середня затримка блоку. У Bullshark, у кожному парному раунді є анкерна точка, а вершини непарного раунду інтерпретуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб впорядкувати анкерні точки, однак вершини в причинно-історичному контексті анкерних точок потребують більшої кількості раундів для очікування впорядкування анкерних точок. У звичайних випадках вершини в непарному раунді потребують трьох раундів, а ненав'язані вершини в парному раунді потребують чотирьох раундів.
Проблема 2: затримка випадків несправності. Вищезазначений аналіз затримки застосовний до безвідмовного стану, з іншого боку, якщо лідер раунду не зможе достатньо швидко транслювати анкорні точки, то неможливо буде впорядкувати анкорні точки (, тому їх пропускають ), тому всі невпорядковані вершини з попередніх раундів повинні чекати, поки наступна анкорна точка буде впорядкована. Це суттєво знижує продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує таймаути для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Рамки косяка
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 не витримують навантаження, і тайм-аут закінчується до того, як вони зможуть просунутися.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
9 лайків
Нагородити
9
5
Поділіться
Прокоментувати
0/400
ChainSpy
· 10год тому
Зелений сигнал APT до місяця
Переглянути оригіналвідповісти на0
AirdropHunter007
· 21год тому
затримка降40%？Ця хвиля До місяця！
Переглянути оригіналвідповісти на0
BTCBeliefStation
· 21год тому
дивовижний ця оптимізація вразила мене
Переглянути оригіналвідповісти на0
CounterIndicator
· 22год тому
бик啊 затримка зменшилась більше ніж вдвічі
Переглянути оригіналвідповісти на0
MoonRocketTeam
· 22год тому
Ай-йо затримка прямо Падіння на 50% це вікно запуску має До місяця
Оптимізація рамки Shoal для протоколу консенсусу Aptos. Затримка Bullshark значно зменшена.
Shoal фреймворк: як зменшити затримку Bullshark на Aptos?
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно знизивши затримку, і вперше усунула потребу в таймаутах у детерминированому реальному протоколі. Загалом, у безвідмовному режимі затримка Bullshark була покращена на 40%, а в умовах відмови — на 80%.
Shoal є фреймворком, який посилює консенсусний протокол на основі Narwhal за допомогою обробки з конвеєром і механізму репутації лідера (, такого як DAG-Rider, Tusk, Bullshark ). Обробка з конвеєром зменшує затримку сортування DAG, вводячи в кожному раунді опорну точку, а механізм репутації лідера далі покращує проблему затримки, забезпечуючи зв'язок опорної точки з найшвидшими вузлами валідації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну побудову DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal забезпечити характеристики універсальної реакції, включаючи зазвичай необхідну оптимістичну реакцію.
Ця технологія дуже проста, вона передбачає послідовний запуск кількох екземплярів підлягаючого протоколу. Тому, коли ми використовуємо Bullshark для інстанціювання, ми отримуємо групу "акул", які беруть участь у естафеті.
Фон
У процесі досягнення високої продуктивності блокчейн-мережі люди завжди звертали увагу на зменшення складності зв'язку. Однак цей підхід не призвів до значного підвищення пропускної спроможності. Наприклад, реалізація Hotstuff у ранніх версіях Diem досягла лише 3500 TPS, що значно нижче цільового показника 100000+ TPS.
Недавній прорив зумовлений усвідомленням того, що поширення даних є основною перешкодою, яка базується на угодах лідерів, і може отримати вигоду від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно поширюють дані, тоді як компонент консенсусу лише сортує невелику кількість метаданих. У статті Narwhal повідомляється про пропускну здатність 160000 TPS.
Aptos раніше представив Quorum Store, тобто реалізацію Narwhal, яка відокремлює розповсюдження даних від консенсусу, а також те, як його можна використати для розширення нинішнього консенсусного протоколу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint і зміни вигляду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Однак очевидно, що протоколи консенсусу на основі лідера не можуть повністю використати потенціал пропускної спроможності Narwhal. Незважаючи на те, що розповсюдження даних розділено з консенсусом, лідери Hotstuff/Jolteon все ще обмежені з ростом пропускної спроможності.
Отже, Aptos вирішив розгорнути 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 мають таку структуру:
Запланована точка якоря: кожні кілька раундів (, наприклад, у Bullshark через два раунди ) буде заздалегідь визначений лідер, вершина якого називається точкою якоря.
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки сортувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по одному обробляють свої упорядковані списки якорів, і для кожного якоря за допомогою деяких детермінованих правил сортують всі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) всі чесні вузли перевірки створили впорядкований список якорів, щоб усі списки ділилися однаковим префіксом. У Shoal зроблено такі спостереження щодо всіх наведених вище протоколів:
Усі валідатори погоджуються на першу впорядковану опору.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є більш практичною та має кращу затримку в порівнянні з асинхронною версією, вона все ще далекий від оптимального.
Проблема 1: середня затримка блоку. У Bullshark, у кожному парному раунді є анкерна точка, а вершини непарного раунду інтерпретуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб впорядкувати анкерні точки, однак вершини в причинно-історичному контексті анкерних точок потребують більшої кількості раундів для очікування впорядкування анкерних точок. У звичайних випадках вершини в непарному раунді потребують трьох раундів, а ненав'язані вершини в парному раунді потребують чотирьох раундів.
Проблема 2: затримка випадків несправності. Вищезазначений аналіз затримки застосовний до безвідмовного стану, з іншого боку, якщо лідер раунду не зможе достатньо швидко транслювати анкорні точки, то неможливо буде впорядкувати анкорні точки (, тому їх пропускають ), тому всі невпорядковані вершини з попередніх раундів повинні чекати, поки наступна анкорна точка буде впорядкована. Це суттєво знижує продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує таймаути для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Рамки косяка
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 не витримують навантаження, і тайм-аут закінчується до того, як вони зможуть просунутися.
На жаль, на основі угоди лідера ( як