Shoal фреймворк: інноваційне рішення для зменшення затримки Bullshark на Aptos
Aptos Labs нещодавно досягла значного прориву в області DAG BFT, вирішивши дві ключові проблеми, суттєво знизивши затримку та вперше усунувши потребу в таймаутах у детерміністських протоколах. Загалом, в умовах безвідмовної роботи затримка Bullshark зросла на 40%, а в умовах відмови - на 80%.
Shoal є системою, яка покращує будь-який консенсусний протокол на основі Narwhal (, такий як DAG-Rider, Tusk, Bullshark ), за рахунок обробки у конвеєрі та репутації лідера. Обробка у конвеєрі зменшує затримку сортування DAG, вводячи якорі в кожному раунді, а репутація лідера далі покращує затримку, забезпечуючи зв'язок якорів з найбільш швидкими верифікаційними вузлами. Крім того, репутація лідера дозволяє Shoal використовувати асинхронне побудування DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal забезпечити характеристику, яку ми називаємо "універсальною реактивністю", що містить зазвичай необхідну оптимістичну реактивність.
Наша технологія дуже проста, по суті, це кілька екземплярів основного протоколу, які виконуються послідовно. Тому, коли ми інстанціюємо Bullshark, ми отримуємо групу "акул", які бігають у естафеті.
Фон та мотивація
У процесі досягнення високої продуктивності мережі блокчейн зменшення складності зв'язку завжди було в центрі уваги, але цей підхід не призвів до значного підвищення пропускної здатності. Наприклад, ранні версії Diem реалізували Hotstuff, який досяг лише 3500 TPS, що значно нижче цільового показника в 100000+ 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.
! [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 використовує тайм-аути для очікування лідера.
Рамки косяка
Shoal через конвеєрну обробку посилив Bullshark( або будь-який інший протокол BFT на основі Narwhal), що дозволяє мати один якорь у кожному раунді та зменшує затримку всіх неякірних вершин у DAG до трьох раундів. Shoal також вводить в DAG механізм репутації лідера без витрат, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними проблемами з таких причин:
Попередні спроби модифікувати основну логіку Bullshark виявилися, в принципі, неможливими.
Репутація лідера введена в DiemBFT та формалізована в Carousel, динамічно обираючи майбутніх лідерів на основі минулої продуктивності валідаторів, ідея якого полягає у використанні якоря в (Bullshark. Хоча розбіжності в ідентичності лідера не порушують безпеку цих протоколів, в Bullshark це може призвести до зовсім іншого порядку, що підводить до суті питання: динамічний та детермінований вибір колесного якоря є необхідним для вирішення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутнього якоря.
Як доказ складності проблеми ми звертаємо увагу на реалізацію Bullshark, яка не підтримує ці функції, включаючи реалізацію, що наразі знаходиться в продуктивному середовищі.
Протокол
Незважаючи на зазначені вище виклики, рішення приховане у простоті.
У Shoal ми покладаємось на здатність виконувати локальні обчислення на DAG та реалізуємо можливість зберігати та переінтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, роблячи ) перше впорядковане якірне місце точкою переключення екземплярів, а ( причинну історію якоря використовують для обчислення репутації лідера.
![Детальний аналіз 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, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
13 лайків
Нагородити
13
6
Репост
Поділіться
Прокоментувати
0/400
SandwichDetector
· 14год тому
Покращення продуктивності справді бик, підвищення на 80% — це неймовірно.
Переглянути оригіналвідповісти на0
NFTRegretful
· 14год тому
Виглядає непогано, просто швидкість ще недостатня.
Переглянути оригіналвідповісти на0
BearMarketSurvivor
· 15год тому
затримка Падіння 80% Це вже справжня сила на полі бою, чекаємо на реальні результати
Переглянути оригіналвідповісти на0
CoinBasedThinking
· 15год тому
Надійний проект, технологічне оновлення. Сподіваюся, що це не буде половинчатим.
Shoal фреймворк підвищує ефективність консенсусу Aptos, Bullshark затримка Падіння 80%
Shoal фреймворк: інноваційне рішення для зменшення затримки Bullshark на Aptos
Aptos Labs нещодавно досягла значного прориву в області DAG BFT, вирішивши дві ключові проблеми, суттєво знизивши затримку та вперше усунувши потребу в таймаутах у детерміністських протоколах. Загалом, в умовах безвідмовної роботи затримка Bullshark зросла на 40%, а в умовах відмови - на 80%.
Shoal є системою, яка покращує будь-який консенсусний протокол на основі Narwhal (, такий як DAG-Rider, Tusk, Bullshark ), за рахунок обробки у конвеєрі та репутації лідера. Обробка у конвеєрі зменшує затримку сортування DAG, вводячи якорі в кожному раунді, а репутація лідера далі покращує затримку, забезпечуючи зв'язок якорів з найбільш швидкими верифікаційними вузлами. Крім того, репутація лідера дозволяє Shoal використовувати асинхронне побудування DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal забезпечити характеристику, яку ми називаємо "універсальною реактивністю", що містить зазвичай необхідну оптимістичну реактивність.
Наша технологія дуже проста, по суті, це кілька екземплярів основного протоколу, які виконуються послідовно. Тому, коли ми інстанціюємо Bullshark, ми отримуємо групу "акул", які бігають у естафеті.
Фон та мотивація
У процесі досягнення високої продуктивності мережі блокчейн зменшення складності зв'язку завжди було в центрі уваги, але цей підхід не призвів до значного підвищення пропускної здатності. Наприклад, ранні версії Diem реалізували Hotstuff, який досяг лише 3500 TPS, що значно нижче цільового показника в 100000+ 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.
! [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 використовує тайм-аути для очікування лідера.
Рамки косяка
Shoal через конвеєрну обробку посилив Bullshark( або будь-який інший протокол BFT на основі Narwhal), що дозволяє мати один якорь у кожному раунді та зменшує затримку всіх неякірних вершин у DAG до трьох раундів. Shoal також вводить в DAG механізм репутації лідера без витрат, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними проблемами з таких причин:
Попередні спроби модифікувати основну логіку Bullshark виявилися, в принципі, неможливими.
Репутація лідера введена в DiemBFT та формалізована в Carousel, динамічно обираючи майбутніх лідерів на основі минулої продуктивності валідаторів, ідея якого полягає у використанні якоря в (Bullshark. Хоча розбіжності в ідентичності лідера не порушують безпеку цих протоколів, в Bullshark це може призвести до зовсім іншого порядку, що підводить до суті питання: динамічний та детермінований вибір колесного якоря є необхідним для вирішення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутнього якоря.
Як доказ складності проблеми ми звертаємо увагу на реалізацію Bullshark, яка не підтримує ці функції, включаючи реалізацію, що наразі знаходиться в продуктивному середовищі.
Протокол
Незважаючи на зазначені вище виклики, рішення приховане у простоті.
У Shoal ми покладаємось на здатність виконувати локальні обчислення на DAG та реалізуємо можливість зберігати та переінтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, роблячи ) перше впорядковане якірне місце точкою переключення екземплярів, а ( причинну історію якоря використовують для обчислення репутації лідера.
![Детальний аналіз 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 (, по суті вимагає затримки, щоб забезпечити, що кожного разу, коли лідер виходить з ладу,