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)
Мотивація
У прагненні до високої продуктивності мережі блокчейн, люди завжди зосереджувалися на Падіння складності зв'язку. Проте цей підхід не призвів до суттєвого підвищення пропускної здатності. Наприклад, Hotstuff, реалізований у ранніх версіях Diem, забезпечував лише 3500 TPS, що значно нижче нашої мети досягнення 100k+ TPS.
Нещодавній прорив зумовлений усвідомленням того, що поширення даних є основним вузьким місцем, яке базується на протоколі лідерів, і може отримати вигоду від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, де всі валідатори одночасно поширюють дані, а компоненти консенсусу лише упорядковують невелику кількість метаданих. У документі Narwhal повідомляється про пропускну спроможність 160 000 TPS.
У попередніх статтях ми представили Quorum Store. Наша реалізація Narwhal відокремлює розповсюдження даних від консенсусу і показує, як використовувати це для розширення поточного протоколу консенсусу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint і зміни виду в стилі PBFT, що може знизити затримку Hotstuff на 33%. Однак очевидно, що протоколи консенсусу на основі лідера не можуть у повній мірі використовувати потенціал пропускної здатності Narwhal. Незважаючи на те, що розповсюдження даних відокремлене від консенсусу, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще обмежений.
В результаті ми вирішили розгорнути Bullshark, протокол консенсусу з нульовими витратами на зв'язок, поверх Narwhal DAG. На жаль, структура DAG, яка підтримує високу пропускну здатність Bullshark, має 50% затримку порівняно з Jolteon.
Ця стаття описує, як Shoal досяг значного Падіння затримки Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Фонові дані DAG-BFT
Кожна вершина в Narwhal DAG асоціюється з певним раундом. Щоб увійти в раунд r, валідатор спочатку повинен отримати n-f вершин, що належать до раунду r-1. Кожен валідатор може транслювати одну вершину за раунд, причому кожна вершина посилається принаймні на n-f вершин з попереднього раунду. Через асинхронність мережі різні валідатори можуть в будь-який момент часу спостерігати різні локальні уявлення DAG.
Ключовою властивістю DAG є те, що вона не є неясною: якщо два вузли перевірки мають однакову вершину v у своїх локальних уявленнях DAG, то вони мають абсолютно однакову причинно-історичну історію v.
Загальний вступ
Можна домовитися про загальний порядок всіх вершин в DAG без додаткових накладних витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk і Bullshark інтерпретують структуру DAG як протокол консенсусу, де вершини представляють пропозиції, а ребра – голоси.
Хоча логіка групових перетинів у структурі DAG відрізняється, але всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована опорна точка: кожні кілька раундів (, наприклад, у Bullshark через два раунди ) є заздалегідь визначений лідер, вершина лідера називається опорною точкою;
Точки прив'язки: валідатори незалежно, але з визначеністю вирішують, які точки прив'язки замовити, а які пропустити;
Сортування причинно-наслідкової історії: валідатори по одному обробляють впорядкований список анкерів, для кожного анкера, за допомогою деяких детермінованих правил сортують всі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) всі чесні вузли верифікації створили впорядкований список якорів, щоб всі списки мали спільний префікс. У Shoal ми робимо такі спостереження щодо всіх згаданих вище протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості циклів між впорядкованими якорями в DAG. Хоча частково синхронна версія Bullshark має кращу затримку, ніж асинхронна, вона все ще далека від оптимальної.
Питання 1: середня затримка блоку. У Bullshark, кожен парний раунд має анкерну точку, кожна непарна вершина інтерпретується як голос. В звичайних випадках, потрібно два раунди DAG, щоб замовити анкерні точки, однак, вершини в причинно-історичному контексті анкерів потребують більше раундів, щоб дочекатися сортування анкерів. В звичайних випадках, вершини в непарних раундах потребують трьох раундів, а вершини неанкерні в парних раундах потребують чотирьох раундів.
Питання 2: випадки збою затримка. Вищезазначений аналіз затримки стосується безвідмовних ситуацій, з іншого боку, якщо лідер раунду не зможе достатньо швидко транслювати анкери, то анкери не можуть бути відсортовані ( тому пропускаються ), тому всі невідсортовані вершини з попередніх раундів повинні чекати, поки наступний анкери буде відсортований. Це суттєво знизить продуктивність географічної реплікаційної мережі, особливо оскільки Bullshark використовує тайм-аути для очікування лідера.
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 починає новий екземпляр на другому раунді, який сам має точку якоря, що впорядкована за цим екземпляром, після цього ще один новий екземпляр замовляє точки якоря на третьому раунді, і процес продовжується.
![Детальний аналіз рамки Shoal: як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Репутація лідера
Під час пропуску якорів під час сортування Bullshark затримка збільшується. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не може бути запущений до того, як буде замовлено попередній екземпляр якоря. Shoal забезпечує, щоб у майбутньому відповідного лідера, який обробляє втрачені якорі, було малоймовірно вибрати, використовуючи механізм репутації, який призначає кожному вузлу перевірки оцінку на основі історії недавньої активності кожного вузла перевірки. Верифікатори, які відповідають та беруть участь у протоколі, отримають високу оцінку, інакше вузли перевірки отримають низьку оцінку, оскільки вони можуть зазнавати краху, бути повільними або діяти зловмисно.
Її концепція полягає в тому, щоб під час кожного оновлення рахунку детерміновано повторно обчислювати попередньо визначене відображення F від раунду до лідера, орієнтуючись на лідера з вищим рахунком. Щоб валідатори досягли консенсусу щодо нового відображення, їм слід досягти консенсусу щодо рахунку, щоб досягти консенсусу щодо історії, що використовується для похідного рахунку.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують однакову основну технологію, а саме переосмислення DAG після досягнення згоди щодо першої впорядкованої опорної точки.
Насправді, єдина відмінність полягає в тому, що після сортування якорів у раунді r, валідаторам потрібно лише на основі причинно-історичної інформації упорядкованих якорів у раунді r розрахувати нову відображення F' починаючи з раунду r+1. Потім валідаторські вузли починають використовувати оновлену функцію вибору якорів F' для виконання нових екземплярів Bullshark з раунду r+1.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/social/moments-9f789cb669fcc244ea7ff7648e48b4(
Немає більше затримок
Часове перевищення відіграє вирішальну роль у всіх реалізаціях BFT, що базуються на лідері, з детермінованою частковою синхронізацією. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Timeout також значно збільшує затримку, оскільки важливо правильно їх налаштувати, і зазвичай потрібно динамічно регулювати, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол виплачує повний штраф за затримку тайм-ауту для несправного лідера. Тому налаштування тайм-ауту не можуть бути занадто обережними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження, Jolteon/
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
22 лайків
Нагородити
22
5
Репост
Поділіться
Прокоментувати
0/400
BlockchainFries
· 07-21 02:44
Почекайте, 40% ще 80%. Це точно не малюють мрію?
Переглянути оригіналвідповісти на0
YouMustMakeBigMoneyEvery
· 07-20 12:23
Ще не зроблено сильного поштовху. Занадто погано. Пер突破 6 юанів збільшити позицію.
Переглянути оригіналвідповісти на0
HalfBuddhaMoney
· 07-20 09:59
затримка знизилася так сильно, aptos варто очікувати!
Переглянути оригіналвідповісти на0
SleepyArbCat
· 07-20 09:58
Цього дня вже майже світало, aptos нарешті зробив сильний поштовх... затримка ще нижче, і можна буде підкріпитися.
Shoal фрейм Падіння Aptos Bullshark затримка 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)
Мотивація
У прагненні до високої продуктивності мережі блокчейн, люди завжди зосереджувалися на Падіння складності зв'язку. Проте цей підхід не призвів до суттєвого підвищення пропускної здатності. Наприклад, Hotstuff, реалізований у ранніх версіях Diem, забезпечував лише 3500 TPS, що значно нижче нашої мети досягнення 100k+ TPS.
Нещодавній прорив зумовлений усвідомленням того, що поширення даних є основним вузьким місцем, яке базується на протоколі лідерів, і може отримати вигоду від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, де всі валідатори одночасно поширюють дані, а компоненти консенсусу лише упорядковують невелику кількість метаданих. У документі Narwhal повідомляється про пропускну спроможність 160 000 TPS.
У попередніх статтях ми представили Quorum Store. Наша реалізація Narwhal відокремлює розповсюдження даних від консенсусу і показує, як використовувати це для розширення поточного протоколу консенсусу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint і зміни виду в стилі PBFT, що може знизити затримку Hotstuff на 33%. Однак очевидно, що протоколи консенсусу на основі лідера не можуть у повній мірі використовувати потенціал пропускної здатності Narwhal. Незважаючи на те, що розповсюдження даних відокремлене від консенсусу, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще обмежений.
В результаті ми вирішили розгорнути Bullshark, протокол консенсусу з нульовими витратами на зв'язок, поверх Narwhal DAG. На жаль, структура DAG, яка підтримує високу пропускну здатність Bullshark, має 50% затримку порівняно з Jolteon.
Ця стаття описує, як Shoal досяг значного Падіння затримки Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Фонові дані DAG-BFT
Кожна вершина в Narwhal DAG асоціюється з певним раундом. Щоб увійти в раунд r, валідатор спочатку повинен отримати n-f вершин, що належать до раунду r-1. Кожен валідатор може транслювати одну вершину за раунд, причому кожна вершина посилається принаймні на n-f вершин з попереднього раунду. Через асинхронність мережі різні валідатори можуть в будь-який момент часу спостерігати різні локальні уявлення DAG.
Ключовою властивістю DAG є те, що вона не є неясною: якщо два вузли перевірки мають однакову вершину v у своїх локальних уявленнях DAG, то вони мають абсолютно однакову причинно-історичну історію v.
Загальний вступ
Можна домовитися про загальний порядок всіх вершин в DAG без додаткових накладних витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk і Bullshark інтерпретують структуру DAG як протокол консенсусу, де вершини представляють пропозиції, а ребра – голоси.
Хоча логіка групових перетинів у структурі DAG відрізняється, але всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована опорна точка: кожні кілька раундів (, наприклад, у Bullshark через два раунди ) є заздалегідь визначений лідер, вершина лідера називається опорною точкою;
Точки прив'язки: валідатори незалежно, але з визначеністю вирішують, які точки прив'язки замовити, а які пропустити;
Сортування причинно-наслідкової історії: валідатори по одному обробляють впорядкований список анкерів, для кожного анкера, за допомогою деяких детермінованих правил сортують всі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) всі чесні вузли верифікації створили впорядкований список якорів, щоб всі списки мали спільний префікс. У Shoal ми робимо такі спостереження щодо всіх згаданих вище протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості циклів між впорядкованими якорями в DAG. Хоча частково синхронна версія Bullshark має кращу затримку, ніж асинхронна, вона все ще далека від оптимальної.
Питання 1: середня затримка блоку. У Bullshark, кожен парний раунд має анкерну точку, кожна непарна вершина інтерпретується як голос. В звичайних випадках, потрібно два раунди DAG, щоб замовити анкерні точки, однак, вершини в причинно-історичному контексті анкерів потребують більше раундів, щоб дочекатися сортування анкерів. В звичайних випадках, вершини в непарних раундах потребують трьох раундів, а вершини неанкерні в парних раундах потребують чотирьох раундів.
Питання 2: випадки збою затримка. Вищезазначений аналіз затримки стосується безвідмовних ситуацій, з іншого боку, якщо лідер раунду не зможе достатньо швидко транслювати анкери, то анкери не можуть бути відсортовані ( тому пропускаються ), тому всі невідсортовані вершини з попередніх раундів повинні чекати, поки наступний анкери буде відсортований. Це суттєво знизить продуктивність географічної реплікаційної мережі, особливо оскільки Bullshark використовує тайм-аути для очікування лідера.
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 починає новий екземпляр на другому раунді, який сам має точку якоря, що впорядкована за цим екземпляром, після цього ще один новий екземпляр замовляє точки якоря на третьому раунді, і процес продовжується.
![Детальний аналіз рамки Shoal: як зменшити затримку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Репутація лідера
Під час пропуску якорів під час сортування Bullshark затримка збільшується. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не може бути запущений до того, як буде замовлено попередній екземпляр якоря. Shoal забезпечує, щоб у майбутньому відповідного лідера, який обробляє втрачені якорі, було малоймовірно вибрати, використовуючи механізм репутації, який призначає кожному вузлу перевірки оцінку на основі історії недавньої активності кожного вузла перевірки. Верифікатори, які відповідають та беруть участь у протоколі, отримають високу оцінку, інакше вузли перевірки отримають низьку оцінку, оскільки вони можуть зазнавати краху, бути повільними або діяти зловмисно.
Її концепція полягає в тому, щоб під час кожного оновлення рахунку детерміновано повторно обчислювати попередньо визначене відображення F від раунду до лідера, орієнтуючись на лідера з вищим рахунком. Щоб валідатори досягли консенсусу щодо нового відображення, їм слід досягти консенсусу щодо рахунку, щоб досягти консенсусу щодо історії, що використовується для похідного рахунку.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують однакову основну технологію, а саме переосмислення DAG після досягнення згоди щодо першої впорядкованої опорної точки.
Насправді, єдина відмінність полягає в тому, що після сортування якорів у раунді r, валідаторам потрібно лише на основі причинно-історичної інформації упорядкованих якорів у раунді r розрахувати нову відображення F' починаючи з раунду r+1. Потім валідаторські вузли починають використовувати оновлену функцію вибору якорів F' для виконання нових екземплярів Bullshark з раунду r+1.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/social/moments-9f789cb669fcc244ea7ff7648e48b4(
Немає більше затримок
Часове перевищення відіграє вирішальну роль у всіх реалізаціях BFT, що базуються на лідері, з детермінованою частковою синхронізацією. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження і вимагає більше технологій спостереження.
Timeout також значно збільшує затримку, оскільки важливо правильно їх налаштувати, і зазвичай потрібно динамічно регулювати, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол виплачує повний штраф за затримку тайм-ауту для несправного лідера. Тому налаштування тайм-ауту не можуть бути занадто обережними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження, Jolteon/