Shoal фрейм: значно зменшує затримку Bullshark на Aptos
Огляд
Aptos labs вирішила дві важливі відкриті проблеми в DAG BFT, суттєво зменшивши затримку та вперше усунувши потребу в тайм-аутах у детерміністських реальних протоколах. Загалом, у безвідмовному режимі затримка Bullshark покращилася на 40%, а у випадку збоїв - на 80%.
Shoal є фреймворком, який підсилює будь-який консенсусний протокол, оснований на Narwhal, за допомогою конвеєра та репутації лідера. Конвеєр зменшує затримку сортування 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. На жаль, у порівнянні з 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 ми робимо наступні спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між упорядкованими якорями в DAG. Хоча найбільш практична частина Bullshark синхронної версії має кращу затримку, ніж асинхронна версія, вона все ще далека від оптимальної.
Питання 1: середня затримка блоків. У Bullshark кожен парний раунд має опорну точку, а кожен непарний раунд вершини інтерпретуються як голосування. У звичайних випадках для упорядкування опорних точок потрібні два раунди DAG, однак вершини в каузальній історії опорних точок потребують більше раундів, щоб дочекатися упорядкування опорних точок. У звичайних випадках вершини в непарних раундах потребують трьох раундів, тоді як не опорні вершини в парних раундах потребують чотирьох раундів.
Проблема 2: затримка випадків збоїв, наведений аналіз затримки застосовується до безвідмовних ситуацій, з іншого боку, якщо лідер раунду не в змозі достатньо швидко транслювати якорі, то неможливо відсортувати якорі (, тому вони пропускаються ), отже, всі несортовані вершини з попередніх раундів повинні чекати, поки наступний якор буде відсортований. Це суттєво знижує продуктивність географічної мережі реплікації, особливо оскільки тайм-аут Bullshark використовується для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.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-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.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/social/moments-9f789cb669fcc244ea7ff7648e48b4)
Немає більше тайм-аутів
Часовий інтервал відіграє вкрай важливу роль у всіх реалізаціях BFT з детермінацією на основі лідера. Однак, їхня складність збільшує кількість внутрішніх станів, які потрібно керувати і спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Час затримки також значно збільшить затримку, оскільки важливо правильно їх налаштувати, і зазвичай це вимагає динамічної корекції, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повний штраф за затримку для несправного лідера. Тому налаштування часу затримки не можуть бути надто обережними, але якщо час затримки занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff перевантажені, і їх час затримки спливає до того, як вони зможуть просунутися.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
7 лайків
Нагородити
7
5
Поділіться
Прокоментувати
0/400
SchrodingersFOMO
· 08-05 13:55
затримка знизилась так сильно бік бік
Переглянути оригіналвідповісти на0
SchroedingerMiner
· 08-05 12:20
Ця швидкість зростає швидше, ніж температура моєї установки для майнінгу.
Переглянути оригіналвідповісти на0
MEVSandwich
· 08-03 18:14
затримка降这么多 感觉要До місяця
Переглянути оригіналвідповісти на0
MetaMisfit
· 08-03 17:54
Сиджу і чекаю, коли aptos переверне світ... чекаю з нетерпінням
Shoal фрейм значно покращує продуктивність Bullshark на Aptos, затримка зменшилась на 40%-80%
Shoal фрейм: значно зменшує затримку Bullshark на Aptos
Огляд
Aptos labs вирішила дві важливі відкриті проблеми в DAG BFT, суттєво зменшивши затримку та вперше усунувши потребу в тайм-аутах у детерміністських реальних протоколах. Загалом, у безвідмовному режимі затримка Bullshark покращилася на 40%, а у випадку збоїв - на 80%.
Shoal є фреймворком, який підсилює будь-який консенсусний протокол, оснований на Narwhal, за допомогою конвеєра та репутації лідера. Конвеєр зменшує затримку сортування 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. На жаль, у порівнянні з 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 ми робимо наступні спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між упорядкованими якорями в DAG. Хоча найбільш практична частина Bullshark синхронної версії має кращу затримку, ніж асинхронна версія, вона все ще далека від оптимальної.
Питання 1: середня затримка блоків. У Bullshark кожен парний раунд має опорну точку, а кожен непарний раунд вершини інтерпретуються як голосування. У звичайних випадках для упорядкування опорних точок потрібні два раунди DAG, однак вершини в каузальній історії опорних точок потребують більше раундів, щоб дочекатися упорядкування опорних точок. У звичайних випадках вершини в непарних раундах потребують трьох раундів, тоді як не опорні вершини в парних раундах потребують чотирьох раундів.
Проблема 2: затримка випадків збоїв, наведений аналіз затримки застосовується до безвідмовних ситуацій, з іншого боку, якщо лідер раунду не в змозі достатньо швидко транслювати якорі, то неможливо відсортувати якорі (, тому вони пропускаються ), отже, всі несортовані вершини з попередніх раундів повинні чекати, поки наступний якор буде відсортований. Це суттєво знижує продуктивність географічної мережі реплікації, особливо оскільки тайм-аут Bullshark використовується для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.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-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.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/social/moments-9f789cb669fcc244ea7ff7648e48b4)
Немає більше тайм-аутів
Часовий інтервал відіграє вкрай важливу роль у всіх реалізаціях BFT з детермінацією на основі лідера. Однак, їхня складність збільшує кількість внутрішніх станів, які потрібно керувати і спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Час затримки також значно збільшить затримку, оскільки важливо правильно їх налаштувати, і зазвичай це вимагає динамічної корекції, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повний штраф за затримку для несправного лідера. Тому налаштування часу затримки не можуть бути надто обережними, але якщо час затримки занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff перевантажені, і їх час затримки спливає до того, як вони зможуть просунутися.
нещасний