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.
В результаті було вирішено розгорнути Bullshark поверх Narwhal DAG, консенсусного протоколу з нульовими витратами на зв'язок. На жаль, структура DAG, яка підтримує високу пропускну здатність Bullshark, має 50% затримку порівняно з Jolteon.
У цій статті описується, як 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 є невизначеність: якщо два верифікаційні вузли мають однакову вершину v у локальному вигляді DAG, то вони мають абсолютно однакову каузальну історію v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Повний порядок
Можна досягти загальної згоди щодо всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk та Bullshark інтерпретують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра—голосування.
Усі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Забезпечення якоря: через кілька раундів є попередньо визначений лідер, вершина лідера називається якорем.
Сортування якорів: валідатори незалежно, але детерміновано вирішують, які якорі замовляти, а які пропускати.
Сортування причинно-наслідкової історії: валідатори обробляють список впорядкованих анкерних точок один за іншим, сортують усі попередні невпорядковані вершини в причинно-наслідковій історії кожної анкерної точки за детермінованими правилами.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) всі добросовісні вузли-верифікатори створювали впорядкований список якорів, що ділять один і той же префікс. Shoal робить такі спостереження щодо всіх цих протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між упорядкованими якорями в DAG. Хоча деякі версії синхронізації мають кращу затримку, ніж асинхронні версії, це все ще далеко від найкращого.
Питання 1: середнє падіння блоку. У Bullshark в кожному парному раунді є якорна точка, а в кожному непарному раунді вершинка інтерпретується як голос. У звичайних випадках потрібно два раунди DAG, щоб замовити якорні точки, однак вершини в причинно-історичному контексті якорної точки потребують більше раундів для очікування сортування якорних точок. Зазвичай непарні вершини потребують три раунди, парні не-якорні вершини потребують чотири раунди.
Проблема 2: затримка випадків збою. Якщо раундовий лідер не в змозі достатньо швидко транслювати якорі, то неможливо відсортувати якорі (, які пропускаються ), всі не відсортовані вершини з попередніх раундів повинні чекати, поки наступний якорь не буде відсортовано. Це значно Падіння продуктивності географічної реплікації мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Shoal фрейм
Shoal через конвеєр посилює Bullshark( або будь-який інший протокол BFT на основі Narwhal), дозволяючи мати прив'язки в кожному раунді, зменшуючи затримку всіх непривабливих вершин у DAG до трьох раундів. Shoal також вводить механізм репутації лідера без витрат у DAG, надаючи перевагу вибору швидкого лідера.
Виклик
У контексті протоколу DAG, проблеми з конвеєром і репутацією лідера вважаються складними з наступних причин:
Попередні спроби змінити основну логіку Bullshark у конвеєрі, але, здається, це по суті неможливо.
Репутація лідера вводиться в DiemBFT та формалізується в Carousel, динамічно обираючи майбутніх лідерів на основі минулих виступів валідаторів (якір в Bullshark ). Хоча розбіжності в ідентичності лідера не порушують безпеки цих протоколів, в Bullshark це може призвести до абсолютно іншого порядку, що піднімає основне питання: динамічно визначене вибіркове коло якорів є необхідним для вирішення консенсусу, а валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутніх якорів.
Як доказ складності проблеми, реалізація Bullshark ( не підтримує ці функції в поточному виробничому середовищі ).
Протокол
Shoal покладається на здатність виконувати локальні обчислення на DAG, щоб реалізувати можливість зберігати та повторно інтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно поєднує кілька екземплярів Bullshark для конвеєрної обробки, що робить ( перше впорядковане якорем точкою перемикання екземплярів, ) причинна історія якоря використовується для обчислення репутації лідера.
( конвеєр
V, що відображає раунд на лідера. Shoal по одному запускає екземпляри Bullshark, кожен екземпляр якоря визначається заздалегідь відношенням F. Кожен екземпляр замовляє один якор, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював до визначення першої впорядкованої опори, наприклад, у раунді r. Усі валідатори погодилися з цією опорою. Отже, всі валідатори можуть з упевненістю погодитися на повторне тлумачення DAG з раунду r+1. Shoal просто запускає новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal замовляти один якір кожного раунду. Перший якірний пункт упорядковується першим екземпляром. Потім Shoal починає новий екземпляр на другому раунді, у якого є власний якірний пункт, цей якір упорядковується цим екземпляром, а потім інший новий екземпляр замовляє якірний пункт у третьому раунді, процес продовжується.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp###
( Репутація лідера
Коли під час сортування Bullshark пропускається якірна точка, затримка збільшується. У цьому випадку конвеєр безсилий, оскільки новий екземпляр не може бути запущено до того, як буде замовлено попередній екземпляр якірної точки. Shoal забезпечує, щоб у майбутньому відповідний лідер навряд чи буде обрано для обробки втрачених якірних точок, використовуючи механізм репутації для розподілу балів на основі недавньої активності кожного вузла перевірки. Валідатори, які відповідають та беруть участь у протоколі, отримують високі бали, в іншому випадку розподіляються низькі бали, оскільки вони можуть бути нестабільними, повільними або зловмисними.
Її концепція полягає в тому, щоб при кожному оновленні рахунку детерміновано перераховувати попередньо визначене відображення F від раунду до лідера, віддаючи перевагу лідерам з вищими балами. Щоб валідатори досягли консенсусу щодо нового відображення, вони повинні досягти консенсусу щодо балів, таким чином досягнувши консенсусу щодо історії, яка використовується для похідних балів.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують одну й ту ж основну технологію, а саме повторне тлумачення DAG після досягнення згоди щодо першої впорядкованої анкери.
Єдина відмінність полягає в тому, що після сортування опорних точок на етапі r, валідатору потрібно лише на основі причинно-історичної інформації упорядкованих опорних точок на етапі r розрахувати нову відображення F' з етапу r+1. Потім вузли валідації з етапу r+1 починають виконувати новий екземпляр Bullshark, використовуючи оновлену функцію вибору опорних точок F'.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Без затримки
Час вичерпання відіграє ключову роль у всіх реалізаціях BFT на основі лідера з детермінованою частковою синхронізацією. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що підвищує складність налагодження і вимагає більше технологій спостереження.
Час вичерпання також суттєво збільшить затримку, оскільки важливо правильно їх налаштувати, зазвичай це вимагає динамічної корекції, сильно залежить від середовища ) мережі ###. Перед переходом до наступного лідера протокол повинен виплатити повне покарання за затримку для несправного лідера. Тому налаштування часу вичерпання не можуть бути занадто обережними, але якщо вони занадто короткі, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що за високого навантаження лідери в Jolteon/Hotstuff перевантажені, і час вичерпання закінчився до того, як було досягнуто прогресу.
На жаль, протокол, оснований на лідерах (, таких як Hotstuff та Jolteon ), по суті вимагає затримки, щоб забезпечити прогрес протоколу кожного разу, коли лідер зазнає краху. Без затримки навіть лідер, що зазнав краху, може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити лідера, що зазнав краху, і повільного лідера, затримка може призвести до зміни всіх лідерів без активності консенсусу на підтверджуючих вузлах.
У Bullshark затримка використовується для побудови DAG, щоб забезпечити достатню швидкість чесних лідерів у додаванні анкерів до DAG для сортування під час синхронізації.
Ми спостерігали, що конструкція DAG забезпечує "годинник" для оцінки швидкості мережі. У разі безперервної роботи, поки n-f чесних валідаторів продовжують додавати вершини до DAG, раунд продовжує просуватися. Хоча Bullshark, можливо, не зможе впорядковувати ( за швидкістю мережі через проблеми з лідерами ), проте DAG все ще зростає зі швидкістю мережі, незважаючи на те, що деякі лідери мають проблеми або мережа є асинхронною. Врешті-решт, коли безпомилкові лідери достатньо швидко транслюють якорі, вся каузальна історія якорів буде впорядкована.
У нашій оцінці порівняли Bullshark у випадках наявності або відсутності затримки:
Швидкий лідер: принаймні швидший за інших валідаторів. Обидва методи забезпечують однакову затримку, оскільки анкор впорядкований і не використовує тайм-аут.
Помилковий лідер: без тайм-ауту Bullshark забезпечує краще падіння, оскільки вузли верифікації негайно пропускають його
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
4
Репост
Поділіться
Прокоментувати
0/400
HashRateHermit
· 21год тому
затримка покращення на 80%? Це ж бик!
Переглянути оригіналвідповісти на0
SelfRugger
· 21год тому
80% затримка зменшена, Ма Де дивився і кричав бик
Переглянути оригіналвідповісти на0
CommunitySlacker
· 21год тому
бик пиво затримка вже оптимізована на 80%
Переглянути оригіналвідповісти на0
Hash_Bandit
· 21год тому
чорт, це як коли ми оптимізували складність майнінгу біткоїнів у 2013 році... значні виграші в хешрейті
Shoal框架：Оптимізація затримки Bullshark на Aptos
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.
В результаті було вирішено розгорнути Bullshark поверх Narwhal DAG, консенсусного протоколу з нульовими витратами на зв'язок. На жаль, структура DAG, яка підтримує високу пропускну здатність Bullshark, має 50% затримку порівняно з Jolteon.
У цій статті описується, як 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 є невизначеність: якщо два верифікаційні вузли мають однакову вершину v у локальному вигляді DAG, то вони мають абсолютно однакову каузальну історію v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Повний порядок
Можна досягти загальної згоди щодо всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk та Bullshark інтерпретують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра—голосування.
Усі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Забезпечення якоря: через кілька раундів є попередньо визначений лідер, вершина лідера називається якорем.
Сортування якорів: валідатори незалежно, але детерміновано вирішують, які якорі замовляти, а які пропускати.
Сортування причинно-наслідкової історії: валідатори обробляють список впорядкованих анкерних точок один за іншим, сортують усі попередні невпорядковані вершини в причинно-наслідковій історії кожної анкерної точки за детермінованими правилами.
Ключем досягнення безпеки є забезпечення того, щоб у кроці (2) всі добросовісні вузли-верифікатори створювали впорядкований список якорів, що ділять один і той же префікс. Shoal робить такі спостереження щодо всіх цих протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між упорядкованими якорями в DAG. Хоча деякі версії синхронізації мають кращу затримку, ніж асинхронні версії, це все ще далеко від найкращого.
Питання 1: середнє падіння блоку. У Bullshark в кожному парному раунді є якорна точка, а в кожному непарному раунді вершинка інтерпретується як голос. У звичайних випадках потрібно два раунди DAG, щоб замовити якорні точки, однак вершини в причинно-історичному контексті якорної точки потребують більше раундів для очікування сортування якорних точок. Зазвичай непарні вершини потребують три раунди, парні не-якорні вершини потребують чотири раунди.
Проблема 2: затримка випадків збою. Якщо раундовий лідер не в змозі достатньо швидко транслювати якорі, то неможливо відсортувати якорі (, які пропускаються ), всі не відсортовані вершини з попередніх раундів повинні чекати, поки наступний якорь не буде відсортовано. Це значно Падіння продуктивності географічної реплікації мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Shoal фрейм
Shoal через конвеєр посилює Bullshark( або будь-який інший протокол BFT на основі Narwhal), дозволяючи мати прив'язки в кожному раунді, зменшуючи затримку всіх непривабливих вершин у DAG до трьох раундів. Shoal також вводить механізм репутації лідера без витрат у DAG, надаючи перевагу вибору швидкого лідера.
Виклик
У контексті протоколу DAG, проблеми з конвеєром і репутацією лідера вважаються складними з наступних причин:
Попередні спроби змінити основну логіку Bullshark у конвеєрі, але, здається, це по суті неможливо.
Репутація лідера вводиться в DiemBFT та формалізується в Carousel, динамічно обираючи майбутніх лідерів на основі минулих виступів валідаторів (якір в Bullshark ). Хоча розбіжності в ідентичності лідера не порушують безпеки цих протоколів, в Bullshark це може призвести до абсолютно іншого порядку, що піднімає основне питання: динамічно визначене вибіркове коло якорів є необхідним для вирішення консенсусу, а валідатори повинні досягти згоди щодо впорядкованої історії для вибору майбутніх якорів.
Як доказ складності проблеми, реалізація Bullshark ( не підтримує ці функції в поточному виробничому середовищі ).
Протокол
Shoal покладається на здатність виконувати локальні обчислення на DAG, щоб реалізувати можливість зберігати та повторно інтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з першим впорядкованим якорем, Shoal послідовно поєднує кілька екземплярів Bullshark для конвеєрної обробки, що робить ( перше впорядковане якорем точкою перемикання екземплярів, ) причинна історія якоря використовується для обчислення репутації лідера.
( конвеєр
V, що відображає раунд на лідера. Shoal по одному запускає екземпляри Bullshark, кожен екземпляр якоря визначається заздалегідь відношенням F. Кожен екземпляр замовляє один якор, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював до визначення першої впорядкованої опори, наприклад, у раунді r. Усі валідатори погодилися з цією опорою. Отже, всі валідатори можуть з упевненістю погодитися на повторне тлумачення DAG з раунду r+1. Shoal просто запускає новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal замовляти один якір кожного раунду. Перший якірний пункт упорядковується першим екземпляром. Потім Shoal починає новий екземпляр на другому раунді, у якого є власний якірний пункт, цей якір упорядковується цим екземпляром, а потім інший новий екземпляр замовляє якірний пункт у третьому раунді, процес продовжується.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp###
( Репутація лідера
Коли під час сортування Bullshark пропускається якірна точка, затримка збільшується. У цьому випадку конвеєр безсилий, оскільки новий екземпляр не може бути запущено до того, як буде замовлено попередній екземпляр якірної точки. Shoal забезпечує, щоб у майбутньому відповідний лідер навряд чи буде обрано для обробки втрачених якірних точок, використовуючи механізм репутації для розподілу балів на основі недавньої активності кожного вузла перевірки. Валідатори, які відповідають та беруть участь у протоколі, отримують високі бали, в іншому випадку розподіляються низькі бали, оскільки вони можуть бути нестабільними, повільними або зловмисними.
Її концепція полягає в тому, щоб при кожному оновленні рахунку детерміновано перераховувати попередньо визначене відображення F від раунду до лідера, віддаючи перевагу лідерам з вищими балами. Щоб валідатори досягли консенсусу щодо нового відображення, вони повинні досягти консенсусу щодо балів, таким чином досягнувши консенсусу щодо історії, яка використовується для похідних балів.
У Shoal, конвеєри та репутація лідерів можуть природно поєднуватися, оскільки вони обидва використовують одну й ту ж основну технологію, а саме повторне тлумачення DAG після досягнення згоди щодо першої впорядкованої анкери.
Єдина відмінність полягає в тому, що після сортування опорних точок на етапі r, валідатору потрібно лише на основі причинно-історичної інформації упорядкованих опорних точок на етапі r розрахувати нову відображення F' з етапу r+1. Потім вузли валідації з етапу r+1 починають виконувати новий екземпляр Bullshark, використовуючи оновлену функцію вибору опорних точок F'.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Без затримки
Час вичерпання відіграє ключову роль у всіх реалізаціях BFT на основі лідера з детермінованою частковою синхронізацією. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що підвищує складність налагодження і вимагає більше технологій спостереження.
Час вичерпання також суттєво збільшить затримку, оскільки важливо правильно їх налаштувати, зазвичай це вимагає динамічної корекції, сильно залежить від середовища ) мережі ###. Перед переходом до наступного лідера протокол повинен виплатити повне покарання за затримку для несправного лідера. Тому налаштування часу вичерпання не можуть бути занадто обережними, але якщо вони занадто короткі, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що за високого навантаження лідери в Jolteon/Hotstuff перевантажені, і час вичерпання закінчився до того, як було досягнуто прогресу.
На жаль, протокол, оснований на лідерах (, таких як Hotstuff та Jolteon ), по суті вимагає затримки, щоб забезпечити прогрес протоколу кожного разу, коли лідер зазнає краху. Без затримки навіть лідер, що зазнав краху, може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити лідера, що зазнав краху, і повільного лідера, затримка може призвести до зміни всіх лідерів без активності консенсусу на підтверджуючих вузлах.
У Bullshark затримка використовується для побудови DAG, щоб забезпечити достатню швидкість чесних лідерів у додаванні анкерів до DAG для сортування під час синхронізації.
Ми спостерігали, що конструкція DAG забезпечує "годинник" для оцінки швидкості мережі. У разі безперервної роботи, поки n-f чесних валідаторів продовжують додавати вершини до DAG, раунд продовжує просуватися. Хоча Bullshark, можливо, не зможе впорядковувати ( за швидкістю мережі через проблеми з лідерами ), проте DAG все ще зростає зі швидкістю мережі, незважаючи на те, що деякі лідери мають проблеми або мережа є асинхронною. Врешті-решт, коли безпомилкові лідери достатньо швидко транслюють якорі, вся каузальна історія якорів буде впорядкована.
У нашій оцінці порівняли Bullshark у випадках наявності або відсутності затримки:
Швидкий лідер: принаймні швидший за інших валідаторів. Обидва методи забезпечують однакову затримку, оскільки анкор впорядкований і не використовує тайм-аут.
Помилковий лідер: без тайм-ауту Bullshark забезпечує краще падіння, оскільки вузли верифікації негайно пропускають його