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, що значно нижче мети у 100000+ TPS.
Недавній прорив зумовлений усвідомленням того, що розповсюдження даних є основною перешкодою, що базується на протоколі лідерів, і може принести вигоду за рахунок паралелізації. Система Narwhal розділяє розповсюдження даних і основну логіку консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно розповсюджують дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У роботі Narwhal повідомляється про пропускну здатність 160000 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, через два раунди ) буде запланований лідер, вершинa лідера називається точкою якоря.
Точки прив'язки: валідатори незалежно, але детерміновано вирішують, які точки прив'язки впорядковувати, а які пропускати.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють упорядкований список якорів, для кожного якоря, за допомогою детермінованих правил сортують усі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (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, заснованих на лідерах. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно контролювати та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Час вичерпання також значно збільшує затримку, оскільки важливо їх належним чином налаштувати, і вони зазвичай потребують динамічного коригування, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку до часу вичерпання для несправного лідера. Тому налаштування часу вичерпання не можуть бути занадто обережними, але якщо час вичерпання занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не витримують навантаження, і час вичерпання спливав до того, як вони здійснювали прогрес.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
10
Репост
Поділіться
Прокоментувати
0/400
TokenomicsTrapper
· 07-16 23:24
класичний венчурний капітал дим і дзеркала... 40% нічого не означає, якщо базова затримка була жахливою, чесно кажучи
Shoal фреймворк значно знижує затримку Bullshark на Aptos, реалізуючи безперервну детерміновану консенсус.
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, що значно нижче мети у 100000+ TPS.
Недавній прорив зумовлений усвідомленням того, що розповсюдження даних є основною перешкодою, що базується на протоколі лідерів, і може принести вигоду за рахунок паралелізації. Система Narwhal розділяє розповсюдження даних і основну логіку консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно розповсюджують дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У роботі Narwhal повідомляється про пропускну здатність 160000 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, через два раунди ) буде запланований лідер, вершинa лідера називається точкою якоря.
Точки прив'язки: валідатори незалежно, але детерміновано вирішують, які точки прив'язки впорядковувати, а які пропускати.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють упорядкований список якорів, для кожного якоря, за допомогою детермінованих правил сортують усі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (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, заснованих на лідерах. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно контролювати та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Час вичерпання також значно збільшує затримку, оскільки важливо їх належним чином налаштувати, і вони зазвичай потребують динамічного коригування, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку до часу вичерпання для несправного лідера. Тому налаштування часу вичерпання не можуть бути занадто обережними, але якщо час вичерпання занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не витримують навантаження, і час вичерпання спливав до того, як вони здійснювали прогрес.
На жаль, на основі протоколу лідера ) як Hotstuff