Оптимізація DAG Консенсусу: Як структура Shoal знижує затримку Bullshark на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно Падіння затримки, і вперше усунула потребу в тайм-аутах у детермінованому асинхронному протоколі. Загалом, рамки Shoal покращили затримку 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 ми робимо такі спостереження щодо всіх цих протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
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 у першому раунді DAG запустив перший екземпляр Bullshark і працював до визначення першої впорядкованої опори, наприклад, у раунді 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 раунду. Потім вузли перевірки починають виконувати новий екземпляр Bullshark, використовуючи оновлену функцію вибору опорних точок F' починаючи з r+1 раунду.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Немає більше тайм-аутів
Час вичерпання відіграє вирішальну роль у всіх реалізаціях детерміністичного BFT, що базуються на лідерах. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та потребує більше технологій спостереження.
Час вичерпання також значно збільшує затримку, оскільки важливо правильно їх налаштувати, і це часто потребує динамічної корекції, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повну пеню за затримку часу вичерпання для лідера з помилкою. Тому налаштування часу вичерпання не повинні бути надто консервативними, але якщо час вичерпання занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що за умов високого навантаження лідери у Jolteon/Hotstuff були перевантажені, і їхній час вичерпання сплив до того, як вони змогли просунутися.
На жаль, протоколи, основані на лідерах (, такі як Hotstuff та Jolteon ), по суті вимагають затримки, щоб забезпечити прогрес протоколу щоразу, коли лідер виходить з ладу. Якщо немає затримки, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронної роботи неможливо відрізнити зламаного лідера від повільного, затримка може призвести до того, що верифікаційні вузли без активності консенсусу будуть переглядати зміну всіх лідерів.
У Bullshark затримка використовується для побудови DAG, щоб забезпечити додавання якорів чесними лідерами під час синхронізації
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
11 лайків
Нагородити
11
6
Репост
Поділіться
Прокоментувати
0/400
GateUser-c799715c
· 23год тому
Покращення продуктивності непогане~
Переглянути оригіналвідповісти на0
AllInAlice
· 08-09 05:29
Це жорстка людина, 40% зниження затримки
Переглянути оригіналвідповісти на0
0xSherlock
· 08-09 05:28
затримка ця хвиля може обробити трохи класно
Переглянути оригіналвідповісти на0
BrokenYield
· 08-09 05:27
мех, ще одна "оптимізація", яка, напевно, створить більше системних ризиків, ніж вирішить... розумні гроші вже хеджують проти цього
Оптимізація Shoal фреймворку DAG консенсусу значно знижує затримку Bullshark на Aptos.
Оптимізація DAG Консенсусу: Як структура Shoal знижує затримку Bullshark на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно Падіння затримки, і вперше усунула потребу в тайм-аутах у детермінованому асинхронному протоколі. Загалом, рамки Shoal покращили затримку 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 ми робимо такі спостереження щодо всіх цих протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
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 у першому раунді DAG запустив перший екземпляр Bullshark і працював до визначення першої впорядкованої опори, наприклад, у раунді 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 раунду. Потім вузли перевірки починають виконувати новий екземпляр Bullshark, використовуючи оновлену функцію вибору опорних точок F' починаючи з r+1 раунду.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Немає більше тайм-аутів
Час вичерпання відіграє вирішальну роль у всіх реалізаціях детерміністичного BFT, що базуються на лідерах. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та потребує більше технологій спостереження.
Час вичерпання також значно збільшує затримку, оскільки важливо правильно їх налаштувати, і це часто потребує динамічної корекції, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повну пеню за затримку часу вичерпання для лідера з помилкою. Тому налаштування часу вичерпання не повинні бути надто консервативними, але якщо час вичерпання занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що за умов високого навантаження лідери у Jolteon/Hotstuff були перевантажені, і їхній час вичерпання сплив до того, як вони змогли просунутися.
На жаль, протоколи, основані на лідерах (, такі як Hotstuff та Jolteon ), по суті вимагають затримки, щоб забезпечити прогрес протоколу щоразу, коли лідер виходить з ладу. Якщо немає затримки, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронної роботи неможливо відрізнити зламаного лідера від повільного, затримка може призвести до того, що верифікаційні вузли без активності консенсусу будуть переглядати зміну всіх лідерів.
У Bullshark затримка використовується для побудови DAG, щоб забезпечити додавання якорів чесними лідерами під час синхронізації