Шаблон Shoal: поліпшення затримки консенсусу Bullshark на Aptos
Aptos Labs недавно вирішила дві важливі відкриті проблеми в DAG BFT, значно зменшивши затримку, і вперше в детермінованому асинхронному протоколі усунула потребу в тайм-аутах. Загалом, в умовах безвідмовної роботи затримку Bullshark поліпшено на 40%, а в умовах відмови – на 80%.
Shoal є платформою, яка покращує консенсусний протокол на основі Narwhal ( за допомогою конвеєрної обробки та механізму репутації лідера, наприклад, у рамках DAG-Rider, Tusk, Bullshark ). Конвеєрна обробка зменшує затримку сортування DAG, вводячи анкер у кожному раунді, а механізм репутації лідера додатково покращує затримку, забезпечуючи зв'язок анкера з найшвидшими вузлами верифікації. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну конструкцію DAG для усунення тайм-аутів у всіх сценаріях. Це дозволяє Shoal забезпечити властивість, відому як універсальна реакція, яка містить звичайно необхідні оптимістичні відповіді.
Технологія 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, це протокол консенсусу з нульовими витратами на зв'язок. На жаль, у порівнянні з 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 для їх конвеєрної обробки, що робить ( перше упорядковане якорем точкою переключення екземплярів, а також ) причинно-історичним зв'язком якоря, який використовується для обчислення репутації лідера.
( Обробка конвеєром
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
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
9 лайків
Нагородити
9
6
Репост
Поділіться
Прокоментувати
0/400
SchrodingerProfit
· 41хв. тому
Це тепер aptos знову до місяця.
Переглянути оригіналвідповісти на0
CodeAuditQueen
· 7год тому
Складна оптимізація алгоритму також має ризик повторного входу в обчислювальну потужність. Сподіваюсь, що не буде проблем.
Переглянути оригіналвідповісти на0
metaverse_hermit
· 7год тому
aptos ще живий tql
Переглянути оригіналвідповісти на0
ReverseTradingGuru
· 7год тому
Знову оновлено, бик!
Переглянути оригіналвідповісти на0
DeadTrades_Walking
· 7год тому
Підвищення ефективності непогане, не забудьте надіслати результати.
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 забезпечити властивість, відому як універсальна реакція, яка містить звичайно необхідні оптимістичні відповіді.
Технологія 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, це протокол консенсусу з нульовими витратами на зв'язок. На жаль, у порівнянні з 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 для їх конвеєрної обробки, що робить ( перше упорядковане якорем точкою переключення екземплярів, а також ) причинно-історичним зв'язком якоря, який використовується для обчислення репутації лідера.
( Обробка конвеєром
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