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.
Aptos раніше представив Quorum Store, це їх реалізація Narwhal, яка розділяє поширення даних і консенсус та використовується для розширення поточного консенсусного протоколу Jolteon. Jolteon - це протокол на основі лідера, який поєднує лінійний швидкий шлях Tendermint та зміни виду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Однак протоколи консенсусу на основі лідера не можуть повністю використовувати потенціал пропускної здатності Narwhal. Незважаючи на розділення поширення даних і консенсусу, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще залишається обмеженим.
Отже, Aptos вирішив розгорнути Bullshark, протокол консенсусу з нульовими витратами на зв'язок, на Narwhal DAG. На жаль, структура DAG, що підтримує високий пропускну здатність Bullshark, призвела до падіння на 50% у порівнянні з Jolteon.
Ця стаття описує, як 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 наведено такі спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються з першим упорядкованим якорем.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між упорядкованими якорями в DAG. Хоча у Bullshark найпрактичніша частина синхронної версії має кращу затримку, ніж асинхронна версія, це далеко не оптимально.
Питання 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, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці функції.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Протокол
Незважаючи на вищезазначені виклики, як кажуть, рішення насправді приховане за простотою.
У Shoal ми спираємося на можливість виконання локальних обчислень на DAG і реалізуємо можливість зберігати та повторно інтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним розумінням першої впорядкованої точки якоря, Shoal послідовно поєднує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ( першу впорядковану точку якоря точкою перемикання екземплярів, а також ) причинно-наслідкову історію точок якоря для обчислення репутації лідера.
( конвеєр
V, яке відображає раунд на лідера. Shoal по одному запускає екземпляри Bullshark, так що для кожного екземпляра якір попередньо визначається відображенням F. Кожен екземпляр впорядковує якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював над ним до визначення першої впорядкованої точки якоря, наприклад, у раунді r. Усі валідатори погодилися з цією точкою якоря. Таким чином, усі валідатори можуть з упевненістю погодитися на переінтерпретацію DAG, починаючи з раунду r+1. Shoal просто запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal відсортувати якорі в кожному раунді. Якірні точки першого раунду сортуються за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який має свою власну якорну точку, що сортирується за цим екземпляром, після чого в третьому раунді сортується ще один новий екземпляр з якорем, і процес продовжується.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.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/social/moments-9f789cb669fcc244ea7ff7648e48b4###
( Немає більше затримок
Тайм-аут відіграє вирішальну роль у всіх реалізаціях детерміністичного часткового синхронного BFT, що базуються на лідерах. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження і вимагає більше технік спостереження.
Тайм-аут також значно збільшує затримку, оскільки їх правильна конфігурація є дуже важливою, і зазвичай потрібно динамічно коригувати, оскільки вона сильно залежить від середовища ) мережі ###. Перед переходом до наступного лідера протокол виплачує повне покарання за затримку тайм-ауту для несправного лідера. Тому налаштування тайм-ауту не можуть бути надто консервативними, але якщо час тайм-ауту занадто короткий, протокол може.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
7
Поділіться
Прокоментувати
0/400
just_here_for_vibes
· 07-27 18:20
Так багато підвищення продуктивності? Давай!
Переглянути оригіналвідповісти на0
BridgeNomad
· 07-26 20:35
гм... покращена затримка виглядає добре, але все ще потрібно перевірити ці вектори довіри, чесно кажучи
Переглянути оригіналвідповісти на0
BearMarketHustler
· 07-26 20:30
Ого, Aptos досить вмілий!
Переглянути оригіналвідповісти на0
Whale_Whisperer
· 07-26 20:28
Це вдосконалення просто неймовірне, спершу накопичимо трохи apt.
Переглянути оригіналвідповісти на0
CryptoMotivator
· 07-26 20:17
Aptos gogo～затримка 80% справді вражаюча
Переглянути оригіналвідповісти на0
StakeHouseDirector
· 07-26 20:17
про а ця оптимізація продуктивності справді потужна
Переглянути оригіналвідповісти на0
Layer2Observer
· 07-26 20:08
Затримка підвищення на 80% трохи хардкорна. Чекаю тестових даних.
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, що значно нижче цільових 100k+ TPS.
Нещодавнє досягнення зумовлене усвідомленням того, що поширення даних є основним вузьким місцем, що базується на протоколах лідерів, і що можна отримати вигоду від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій усі валідатори одночасно поширюють дані, тоді як компоненти консенсусу лише сортують невелику кількість метаданих. У статті Narwhal повідомляється про пропускну спроможність 160 000 TPS.
Aptos раніше представив Quorum Store, це їх реалізація Narwhal, яка розділяє поширення даних і консенсус та використовується для розширення поточного консенсусного протоколу Jolteon. Jolteon - це протокол на основі лідера, який поєднує лінійний швидкий шлях Tendermint та зміни виду в стилі PBFT, що дозволяє зменшити затримку Hotstuff на 33%. Однак протоколи консенсусу на основі лідера не можуть повністю використовувати потенціал пропускної здатності Narwhal. Незважаючи на розділення поширення даних і консенсусу, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще залишається обмеженим.
Отже, Aptos вирішив розгорнути Bullshark, протокол консенсусу з нульовими витратами на зв'язок, на Narwhal DAG. На жаль, структура DAG, що підтримує високий пропускну здатність Bullshark, призвела до падіння на 50% у порівнянні з Jolteon.
Ця стаття описує, як 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 наведено такі спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються з першим упорядкованим якорем.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між упорядкованими якорями в DAG. Хоча у Bullshark найпрактичніша частина синхронної версії має кращу затримку, ніж асинхронна версія, це далеко не оптимально.
Питання 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, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці функції.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Протокол
Незважаючи на вищезазначені виклики, як кажуть, рішення насправді приховане за простотою.
У Shoal ми спираємося на можливість виконання локальних обчислень на DAG і реалізуємо можливість зберігати та повторно інтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним розумінням першої впорядкованої точки якоря, Shoal послідовно поєднує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ( першу впорядковану точку якоря точкою перемикання екземплярів, а також ) причинно-наслідкову історію точок якоря для обчислення репутації лідера.
( конвеєр
V, яке відображає раунд на лідера. Shoal по одному запускає екземпляри Bullshark, так що для кожного екземпляра якір попередньо визначається відображенням F. Кожен екземпляр впорядковує якір, що викликає перехід до наступного екземпляра.
Спочатку Shoal запустив перший екземпляр Bullshark у першому раунді DAG і працював над ним до визначення першої впорядкованої точки якоря, наприклад, у раунді r. Усі валідатори погодилися з цією точкою якоря. Таким чином, усі валідатори можуть з упевненістю погодитися на переінтерпретацію DAG, починаючи з раунду r+1. Shoal просто запустив новий екземпляр Bullshark у раунді r+1.
У найкращому випадку це дозволяє Shoal відсортувати якорі в кожному раунді. Якірні точки першого раунду сортуються за першим екземпляром. Потім Shoal у другому раунді починає новий екземпляр, який має свою власну якорну точку, що сортирується за цим екземпляром, після чого в третьому раунді сортується ще один новий екземпляр з якорем, і процес продовжується.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.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/social/moments-9f789cb669fcc244ea7ff7648e48b4###
( Немає більше затримок
Тайм-аут відіграє вирішальну роль у всіх реалізаціях детерміністичного часткового синхронного BFT, що базуються на лідерах. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження і вимагає більше технік спостереження.
Тайм-аут також значно збільшує затримку, оскільки їх правильна конфігурація є дуже важливою, і зазвичай потрібно динамічно коригувати, оскільки вона сильно залежить від середовища ) мережі ###. Перед переходом до наступного лідера протокол виплачує повне покарання за затримку тайм-ауту для несправного лідера. Тому налаштування тайм-ауту не можуть бути надто консервативними, але якщо час тайм-ауту занадто короткий, протокол може.