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, це консенсусний протокол з нульовими витратами на комунікацію. На жаль, у порівнянні з 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 мають таку ж структуру:
Запланована точка якоря: кожні кілька раундів (, наприклад, у Bullshark через два раунди ) буде попередньо визначений лідер, вершина якого називається точкою якоря;
Точки прив'язки: валідатори незалежно, але з визначеністю вирішують, які точки прив'язки замовити, а які пропустити;
Сортування причинно-наслідкової історії: валідатори по одному обробляють свій впорядкований список якорів, і для кожного якоря, за допомогою деяких детермінованих правил, сортують усі попередні невпорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапах (2) усі чесні вузли верифікації створювали впорядкований список якорів, щоб усі списки ділилися одним і тим же префіксом. У Shoal ми робимо такі спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються на першу впорядковану анкерну точку.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є практичнішою і має кращу затримку, ніж асинхронна версія, вона все ще далекий від оптимального.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має якорну точку, а кожен непарний раунд вершин інтерпретується як голосування. У звичайних випадках потрібно два раунди DAG, щоб упорядкувати якорні точки, однак, вершини в причинно-історичному контексті якорної точки потребують більше раундів, щоб дочекатися упорядкування якорної точки. У звичайних випадках вершини в непарних раундах потребують трьох раундів, а вершини, які не є якорними точками, в парних раундах потребують чотирьох раундів.
Питання 2: Затримка випадків збоїв, наведеного вище аналізу затримки підлягає застосуванню у беззбиткових ситуаціях, з іншого боку, якщо лідер раунду не встигне достатньо швидко розповсюдити анкери, то анкери не можуть бути впорядковані (, тому пропускаються ), і всі невпорядковані вершини з попередніх раундів повинні чекати, поки наступний анкер буде впорядкований. Це значно знижує продуктивність географічної реплікаційної мережі, особливо оскільки таймаут Bullshark використовується для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.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-46d37add0d9e81b2f295edf8eddd907f.webp)
Конвеєр
V, яке відображає раунди на лідерів. Shoal по одному запускає екземпляри Bullshark, так що для кожного екземпляра якорі попередньо визначені відображенням F. Кожен екземпляр замовляє якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював з ним до визначення першої впорядкованої прив'язки, наприклад, у раунді r. Усі валідатори погодилися з цією прив'язкою. Тому всі валідатори можуть з упевненістю погодитися на повторну інтерпретацію DAG, починаючи з раунду r+1. Shoal просто запустив новий екземпляр Bullshark у раунді r+1.
В найкращому випадку це дозволяє Shoal замовити якорі в кожному раунді. Якірні точки першого раунду впорядковуються за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який сам має якорну точку, що впорядковується за цим екземпляром, після чого ще один новий екземпляр замовляє якорну точку в третьому раунді, і цей процес триває.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутація лідерів
Під час пропуску анкерних точок у періоді сортування Bullshark, затримка зростає. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не може бути запущений до того, як анкерна точка попереднього екземпляра буде замовлена. Shoal забезпечує те, що відповідного лідера, який обробляє втрачені анкерні точки, буде менш імовірно обрано в майбутньому, використовуючи механізм репутації, щоб призначити кожному валідатору бал на основі історії останньої активності кожного валідатора. Валідатори, які реагують і беруть участь у протоколі, отримають високі бали, інакше валідатору буде призначено низький бал, оскільки він може аварійно зупинитися, бути повільним або чинити зло.
Його концепція полягає в тому, щоб під час кожного оновлення рахунку детерміновано пересчитувати попередньо визначене відображення F від раунду до лідера, орієнтуючись на лідера з вищим рахунком. Щоб валідатори змогли досягти згоди щодо нового відображення, вони повинні досягти згоди щодо рахунку, таким чином досягнувши згоди щодо історії, що використовується для похідного рахунку.
У Shoal лінійні процеси та репутація лідерів можуть природно поєднуватися, оскільки вони використовують одну й ту ж основну технологію, а саме переінтерпретацію DAG після досягнення згоди щодо першої упорядкованої якорної точки.
Насправді, єдина різниця полягає в тому, що після сортування якорів у r-му раунді, валідатори повинні просто на основі причинно-історичної інформації впорядкованих якорів у r-му раунді обчислити нову мапу F' починаючи з r+1 раунду. Потім, з r+1 раунду, валідаторські вузли використовують оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Немає більше затримок
Тайм-аут відіграє вирішальну роль у всіх реалізаціях BFT з частковою синхронізацією на основі лідера. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Тайм-аут також суттєво збільшить затримку, оскільки їх належна конфігурація є надзвичайно важливою, і зазвичай вимагає динамічного коригування, оскільки вона сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол виплатить повний штраф за затримку тайм-ауту для відмовленого лідера. Тому налаштування тайм-ауту не повинні бути надто консервативними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігаємо
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
6
Поділіться
Прокоментувати
0/400
FortuneTeller42
· 07-29 06:41
Це ж занадто круто, підвищення на 80%
Переглянути оригіналвідповісти на0
StableGeniusDegen
· 07-27 13:52
Жорсткий технічний PI! Зростання цін не за горами
Переглянути оригіналвідповісти на0
EthSandwichHero
· 07-26 07:15
Затримка падіння? Бик а бик а, отак до місяця.
Переглянути оригіналвідповісти на0
GasOptimizer
· 07-26 07:14
80% затримка оптимізації краще, ніж будь-які газові витрати
Шаблон Shoal значно покращує продуктивність мережі Aptos, затримка Bullshark знижена на 80%
Shoal框架:значне падіння затримки Bullshark на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно Падіння затримки та вперше усунула потребу в тайм-аутах у детермінованому фактичному протоколі. В цілому, в умовах безвідмовної роботи затримка Bullshark покращилась на 40%, а в умовах відмови - на 80%.
Shoal є фреймворком, який покращує будь-який протокол консенсусу на основі Narwhal (, такий як DAG-Rider, Tusk, Bullshark ), за допомогою конвеєра та репутації лідера. Конвеєр зменшує затримку сортування DAG, вводячи точку прив'язки в кожному раунді, а репутація лідера ще більше покращує затримку, забезпечуючи зв'язок точок прив'язки з найшвидшими вузлами перевірки. Крім того, репутація лідера дозволяє Shoal використовувати асинхронну конструкцію DAG, щоб усунути тайм-аути у всіх сценаріях. Це дозволяє Shoal надавати властивість, яку ми називаємо універсальною відповіддю, яка містить звичайно необхідну оптимістичну відповідь.
Наша технологія дуже проста, вона передбачає послідовне виконання кількох екземплярів базового протоколу. Тому, коли ми використовуємо Bullshark для інстанціювання, ми отримуємо групу "акул", які беруть участь у естафеті.
! [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 мають таку ж структуру:
Запланована точка якоря: кожні кілька раундів (, наприклад, у Bullshark через два раунди ) буде попередньо визначений лідер, вершина якого називається точкою якоря;
Точки прив'язки: валідатори незалежно, але з визначеністю вирішують, які точки прив'язки замовити, а які пропустити;
Сортування причинно-наслідкової історії: валідатори по одному обробляють свій впорядкований список якорів, і для кожного якоря, за допомогою деяких детермінованих правил, сортують усі попередні невпорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапах (2) усі чесні вузли верифікації створювали впорядкований список якорів, щоб усі списки ділилися одним і тим же префіксом. У Shoal ми робимо такі спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються на першу впорядковану анкерну точку.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між впорядкованими якорями в DAG. Хоча синхронна версія Bullshark є практичнішою і має кращу затримку, ніж асинхронна версія, вона все ще далекий від оптимального.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має якорну точку, а кожен непарний раунд вершин інтерпретується як голосування. У звичайних випадках потрібно два раунди DAG, щоб упорядкувати якорні точки, однак, вершини в причинно-історичному контексті якорної точки потребують більше раундів, щоб дочекатися упорядкування якорної точки. У звичайних випадках вершини в непарних раундах потребують трьох раундів, а вершини, які не є якорними точками, в парних раундах потребують чотирьох раундів.
Питання 2: Затримка випадків збоїв, наведеного вище аналізу затримки підлягає застосуванню у беззбиткових ситуаціях, з іншого боку, якщо лідер раунду не встигне достатньо швидко розповсюдити анкери, то анкери не можуть бути впорядковані (, тому пропускаються ), і всі невпорядковані вершини з попередніх раундів повинні чекати, поки наступний анкер буде впорядкований. Це значно знижує продуктивність географічної реплікаційної мережі, особливо оскільки таймаут Bullshark використовується для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.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-46d37add0d9e81b2f295edf8eddd907f.webp)
Конвеєр
V, яке відображає раунди на лідерів. Shoal по одному запускає екземпляри Bullshark, так що для кожного екземпляра якорі попередньо визначені відображенням F. Кожен екземпляр замовляє якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював з ним до визначення першої впорядкованої прив'язки, наприклад, у раунді r. Усі валідатори погодилися з цією прив'язкою. Тому всі валідатори можуть з упевненістю погодитися на повторну інтерпретацію DAG, починаючи з раунду r+1. Shoal просто запустив новий екземпляр Bullshark у раунді r+1.
В найкращому випадку це дозволяє Shoal замовити якорі в кожному раунді. Якірні точки першого раунду впорядковуються за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який сам має якорну точку, що впорядковується за цим екземпляром, після чого ще один новий екземпляр замовляє якорну точку в третьому раунді, і цей процес триває.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутація лідерів
Під час пропуску анкерних точок у періоді сортування Bullshark, затримка зростає. У цьому випадку технологія конвеєра безсила, оскільки новий екземпляр не може бути запущений до того, як анкерна точка попереднього екземпляра буде замовлена. Shoal забезпечує те, що відповідного лідера, який обробляє втрачені анкерні точки, буде менш імовірно обрано в майбутньому, використовуючи механізм репутації, щоб призначити кожному валідатору бал на основі історії останньої активності кожного валідатора. Валідатори, які реагують і беруть участь у протоколі, отримають високі бали, інакше валідатору буде призначено низький бал, оскільки він може аварійно зупинитися, бути повільним або чинити зло.
Його концепція полягає в тому, щоб під час кожного оновлення рахунку детерміновано пересчитувати попередньо визначене відображення F від раунду до лідера, орієнтуючись на лідера з вищим рахунком. Щоб валідатори змогли досягти згоди щодо нового відображення, вони повинні досягти згоди щодо рахунку, таким чином досягнувши згоди щодо історії, що використовується для похідного рахунку.
У Shoal лінійні процеси та репутація лідерів можуть природно поєднуватися, оскільки вони використовують одну й ту ж основну технологію, а саме переінтерпретацію DAG після досягнення згоди щодо першої упорядкованої якорної точки.
Насправді, єдина різниця полягає в тому, що після сортування якорів у r-му раунді, валідатори повинні просто на основі причинно-історичної інформації впорядкованих якорів у r-му раунді обчислити нову мапу F' починаючи з r+1 раунду. Потім, з r+1 раунду, валідаторські вузли використовують оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Немає більше затримок
Тайм-аут відіграє вирішальну роль у всіх реалізаціях BFT з частковою синхронізацією на основі лідера. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Тайм-аут також суттєво збільшить затримку, оскільки їх належна конфігурація є надзвичайно важливою, і зазвичай вимагає динамічного коригування, оскільки вона сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол виплатить повний штраф за затримку тайм-ауту для відмовленого лідера. Тому налаштування тайм-ауту не повинні бути надто консервативними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігаємо