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, що значно нижче нашої мети у 100000+ TPS.
Недавній прорив пов'язаний з усвідомленням того, що поширення даних є головною перешкодою, яка базується на протоколах лідерів, і що воно може виграти від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У статті Narwhal повідомляється про продуктивність 160 тисяч TPS.
В попередніх статтях ми представили Quorum Store - нашу реалізацію Narwhal, яка відокремлює розповсюдження даних від консенсусу, а також те, як ми використовуємо це для розширення поточного протоколу консенсусу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint з змінами огляду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Однак, очевидно, що протоколи консенсусу на основі лідера не можуть повною мірою використовувати потенціал пропускної здатності Narwhal. Незважаючи на відокремлення розповсюдження даних від консенсусу, лідер Hotstuff/Jolteon все ще стикається з обмеженнями зростання пропускної здатності.
Отже, ми вирішили розгорнути Bullshark на основі Narwhal DAG - консенсусного протоколу з нульовими витратами на зв'язок. На жаль, на відміну від Jolteon, структура DAG, що підтримує високий пропуск, має 50% падіння.
У цій статті буде представлено, як 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 є однозначність: якщо два вузли перевірки мають у своїх локальних зображеннях DAG однакову вершину v, то вони мають абсолютно однакову причинно-історію v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Загальна послідовність
Можна досягти згоди щодо загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk і Bullshark інтерпретують структуру DAG як протокол консенсусу, де вершини представляють пропозиції, а ребра - голосування.
Хоча логіка групових перетинів у структурі DAG різна, всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована точка: кожні кілька раундів (, як у Bullshark, через два раунди ) буде попередньо визначений лідер, вершина якого називається точкою якоря.
Точки порядку: валідатори незалежно, але з визначеністю вирішують, які точки порядку включити, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють упорядкований список якорів, для кожного якоря, за допомогою певних детермінованих правил, здійснюють сортування всіх попередніх невпорядкованих вершин у його причинно-наслідковій історії.
Ключем до забезпечення безпеки є впевненість у тому, що на етапі 2 усі чесні вузли перевірки створюють впорядкований список якорів, щоб усі списки мали однаковий префікс. У Shoal ми робимо такі спостереження щодо всіх вищезазначених протоколів:
Всі валідатори погоджуються з першим упорядкованим якорем.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark затримка
Затримка Bullshark залежить від кількості кругів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є більш практичною і має кращу затримку, ніж асинхронна версія, це все ще далеко не оптимально.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має анкор, а кожен непарний раунд вершини трактуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб відсортувати анкори, однак вершини в каузальній історії анкори потребують більше раундів, щоб дочекатися сортування анкори. У звичайних випадках вершини в непарних раундах потребують трьох раундів, а вершини, що не є анкорами, в парних раундах потребують чотирьох раундів.
Питання 2: Ситуація з відмовами затримка. Вищезгаданий аналіз затримки застосовується до безвідмовної ситуації, з іншого боку, якщо лідер певного раунду не зможе достатньо швидко транслювати анкери, то неможливо буде впорядкувати анкери (, тому вони пропускаються ), що призводить до того, що всі непорядковані вершини в перших раундах повинні чекати, поки наступний анкер буде впорядкований. Це значно знижує продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Shoal рамка
Shoal вирішив ці дві затримки, посиливши Bullshark( або будь-який інший BFT протокол на основі Narwhal) шляхом конвеєрної обробки, що дозволяє мати один якорь в кожному раунді та зменшує затримку всіх неякорних вершин у DAG до трьох раундів. Shoal також впровадив у DAG механізм репутації лідера з нульовими витратами, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними проблемами з таких причин:
Попередні спроби обробки конвеєра намагалися змінити основну логіку Bullshark, але це, по суті, здається неможливим.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel, вона динамічно обирає майбутніх лідерів на основі минулих виступів валідаторів, ідея яких полягає в прив'язці до (Bullshark. Хоча розбіжності в лідерстві не порушують безпеки цих протоколів, у Bullshark це може призвести до зовсім іншого порядку, що піднімає центральне питання, а саме, що динамічний і детермінований вибір обертових анкерів є необхідним для досягнення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутніх анкерів.
Як доказ складності проблеми, ми звертаємо увагу на реалізацію Bullshark, яка, включаючи реалізацію, що наразі перебуває в експлуатації, не підтримує ці функції.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Протокол
Незважаючи на вищезазначені виклики, насправді рішення приховане в простоті.
У 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/social/moments-9f789cb669fcc244ea7ff7648e48b4)
Репутація лідера
Під час пропуску анкерних точок під час сортування Bullshark, затримка зростає. У цьому випадку технологія конвеєрної обробки безсила, оскільки новий екземпляр не може бути запущений до сортування анкерної точки попереднього екземпляра. Shoal забезпечує меншу ймовірність вибору відповідного лідера для обробки втрачених анкерних точок, використовуючи механізм репутації для призначення балу кожному валідатору на основі історії його нещодавньої активності. Валідатори, які реагують і беруть участь у протоколі, отримають високий бал, в іншому випадку, валідатору буде призначено низький бал, оскільки він може бути зламаний, повільним або діяти зловмисно.
Її концепція полягає в тому, щоб під час кожного оновлення рахунку детерміновано перераховувати попередньо визначене відображення F від раунду до лідера, надаючи перевагу лідерам з вищими балами. Щоб валідатори змогли досягти узгодженості на новому відображенні, вони повинні досягти узгодженості щодо балів, таким чином досягнувши узгодженості в історії, що використовується для похідних балів.
У Shoal обробка в конвеєрі та репутація лідера можуть природно поєднуватися, оскільки вони обидва використовують одну й ту ж основну технологію, а саме повторне тлумачення DAG після досягнення консенсусу щодо першої впорядкованої анкорної точки.
Насправді, єдина різниця полягає в тому, що після сортування анкорів на етапі r, валідатори просто повинні почати обчислення нової відображення F' з етапу r+1, спираючись на причинно-історичну інформацію впорядкованих анкорів на етапі r. Потім валідатори будуть використовувати оновлену функцію вибору анкорів F' для виконання нового екземпляра Bullshark, починаючи з етапу r+1.
Усунення затримки
Часове обмеження відіграє вирішальну роль у всіх реалізаціях BFT на основі лідера з детермінованою частковою синхронізацією. Проте, їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження і потребує більше технологій спостереження.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
4
Поділіться
Прокоментувати
0/400
ZKProofEnthusiast
· 07-21 04:12
Гм-хм, ті, що мають soal, всі ростуть досить шалено.
Переглянути оригіналвідповісти на0
SchrodingerWallet
· 07-21 04:10
Ця хвиля 3 буде до місяця?
Переглянути оригіналвідповісти на0
SmartContractPlumber
· 07-21 04:10
Консенсус шар покращення є найбільш імовірним джерелом ланцюгових ризиків. Поговоримо про нові вразливості, коли вони з'являться.
Переглянути оригіналвідповісти на0
DecentralizedElder
· 07-21 04:05
Це просто чудово, ця затримка справді може досягти 10%?
Shoal: Новий фреймворк Aptos значно знижує затримку Bullshark та усуває вимоги до тайм-ауту
Shoal框架：Падіння Aptos上 Bullshark затримка的创新方案
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, що значно нижче нашої мети у 100000+ TPS.
Недавній прорив пов'язаний з усвідомленням того, що поширення даних є головною перешкодою, яка базується на протоколах лідерів, і що воно може виграти від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У статті Narwhal повідомляється про продуктивність 160 тисяч TPS.
В попередніх статтях ми представили Quorum Store - нашу реалізацію Narwhal, яка відокремлює розповсюдження даних від консенсусу, а також те, як ми використовуємо це для розширення поточного протоколу консенсусу Jolteon. Jolteon є протоколом на основі лідера, який поєднує лінійний швидкий шлях Tendermint з змінами огляду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Однак, очевидно, що протоколи консенсусу на основі лідера не можуть повною мірою використовувати потенціал пропускної здатності Narwhal. Незважаючи на відокремлення розповсюдження даних від консенсусу, лідер Hotstuff/Jolteon все ще стикається з обмеженнями зростання пропускної здатності.
Отже, ми вирішили розгорнути Bullshark на основі Narwhal DAG - консенсусного протоколу з нульовими витратами на зв'язок. На жаль, на відміну від Jolteon, структура DAG, що підтримує високий пропуск, має 50% падіння.
У цій статті буде представлено, як 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 є однозначність: якщо два вузли перевірки мають у своїх локальних зображеннях DAG однакову вершину v, то вони мають абсолютно однакову причинно-історію v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Загальна послідовність
Можна досягти згоди щодо загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk і Bullshark інтерпретують структуру DAG як протокол консенсусу, де вершини представляють пропозиції, а ребра - голосування.
Хоча логіка групових перетинів у структурі DAG різна, всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована точка: кожні кілька раундів (, як у Bullshark, через два раунди ) буде попередньо визначений лідер, вершина якого називається точкою якоря.
Точки порядку: валідатори незалежно, але з визначеністю вирішують, які точки порядку включити, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють упорядкований список якорів, для кожного якоря, за допомогою певних детермінованих правил, здійснюють сортування всіх попередніх невпорядкованих вершин у його причинно-наслідковій історії.
Ключем до забезпечення безпеки є впевненість у тому, що на етапі 2 усі чесні вузли перевірки створюють впорядкований список якорів, щоб усі списки мали однаковий префікс. У Shoal ми робимо такі спостереження щодо всіх вищезазначених протоколів:
Всі валідатори погоджуються з першим упорядкованим якорем.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark затримка
Затримка Bullshark залежить від кількості кругів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є більш практичною і має кращу затримку, ніж асинхронна версія, це все ще далеко не оптимально.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має анкор, а кожен непарний раунд вершини трактуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб відсортувати анкори, однак вершини в каузальній історії анкори потребують більше раундів, щоб дочекатися сортування анкори. У звичайних випадках вершини в непарних раундах потребують трьох раундів, а вершини, що не є анкорами, в парних раундах потребують чотирьох раундів.
Питання 2: Ситуація з відмовами затримка. Вищезгаданий аналіз затримки застосовується до безвідмовної ситуації, з іншого боку, якщо лідер певного раунду не зможе достатньо швидко транслювати анкери, то неможливо буде впорядкувати анкери (, тому вони пропускаються ), що призводить до того, що всі непорядковані вершини в перших раундах повинні чекати, поки наступний анкер буде впорядкований. Це значно знижує продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Shoal рамка
Shoal вирішив ці дві затримки, посиливши Bullshark( або будь-який інший BFT протокол на основі Narwhal) шляхом конвеєрної обробки, що дозволяє мати один якорь в кожному раунді та зменшує затримку всіх неякорних вершин у DAG до трьох раундів. Shoal також впровадив у DAG механізм репутації лідера з нульовими витратами, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними проблемами з таких причин:
Попередні спроби обробки конвеєра намагалися змінити основну логіку Bullshark, але це, по суті, здається неможливим.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel, вона динамічно обирає майбутніх лідерів на основі минулих виступів валідаторів, ідея яких полягає в прив'язці до (Bullshark. Хоча розбіжності в лідерстві не порушують безпеки цих протоколів, у Bullshark це може призвести до зовсім іншого порядку, що піднімає центральне питання, а саме, що динамічний і детермінований вибір обертових анкерів є необхідним для досягнення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутніх анкерів.
Як доказ складності проблеми, ми звертаємо увагу на реалізацію Bullshark, яка, включаючи реалізацію, що наразі перебуває в експлуатації, не підтримує ці функції.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Протокол
Незважаючи на вищезазначені виклики, насправді рішення приховане в простоті.
У 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/social/moments-9f789cb669fcc244ea7ff7648e48b4)
Репутація лідера
Під час пропуску анкерних точок під час сортування Bullshark, затримка зростає. У цьому випадку технологія конвеєрної обробки безсила, оскільки новий екземпляр не може бути запущений до сортування анкерної точки попереднього екземпляра. Shoal забезпечує меншу ймовірність вибору відповідного лідера для обробки втрачених анкерних точок, використовуючи механізм репутації для призначення балу кожному валідатору на основі історії його нещодавньої активності. Валідатори, які реагують і беруть участь у протоколі, отримають високий бал, в іншому випадку, валідатору буде призначено низький бал, оскільки він може бути зламаний, повільним або діяти зловмисно.
Її концепція полягає в тому, щоб під час кожного оновлення рахунку детерміновано перераховувати попередньо визначене відображення F від раунду до лідера, надаючи перевагу лідерам з вищими балами. Щоб валідатори змогли досягти узгодженості на новому відображенні, вони повинні досягти узгодженості щодо балів, таким чином досягнувши узгодженості в історії, що використовується для похідних балів.
У Shoal обробка в конвеєрі та репутація лідера можуть природно поєднуватися, оскільки вони обидва використовують одну й ту ж основну технологію, а саме повторне тлумачення DAG після досягнення консенсусу щодо першої впорядкованої анкорної точки.
Насправді, єдина різниця полягає в тому, що після сортування анкорів на етапі r, валідатори просто повинні почати обчислення нової відображення F' з етапу r+1, спираючись на причинно-історичну інформацію впорядкованих анкорів на етапі r. Потім валідатори будуть використовувати оновлену функцію вибору анкорів F' для виконання нового екземпляра Bullshark, починаючи з етапу r+1.
Усунення затримки
Часове обмеження відіграє вирішальну роль у всіх реалізаціях BFT на основі лідера з детермінованою частковою синхронізацією. Проте, їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження і потребує більше технологій спостереження.
Час очікування також суттєво збільшить затримку