Shoal фреймворк: оптимізація затримки консенсусу Bullshark на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно зменшивши затримку і вперше усунувши потребу в тайм-аутах у детерминистичному фактичному протоколі. Загалом, в умовах безвідмовної роботи затримка 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)
Фон та мотивація
У процесі досягнення високої продуктивності блокчейн-мереж зменшення складності зв'язку завжди було в центрі уваги. Проте, цей підхід не приніс значного підвищення пропускної спроможності. Наприклад, ранні версії Diem, в яких реалізовано Hotstuff, досягли лише 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. Нажаль, порівняно з Jolteon, DAG-структура, що підтримує високу пропускну здатність Bullshark, має 50% затримку.
! [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 як консенсусний протокол, де вершини представляють пропозиції, а ребра представляють голосування.
Хоча логіка групового перетину в структурі DAG різна, усі існуючі протоколи консенсусу на основі Narwhal мають таку структуру:
Заброньовані опорні точки: через кілька раундів (, наприклад, у Bullshark через два раунди ) буде обрано попередньо визначеного лідера, вершина якого називається опорною точкою.
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки сортування використовувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по одному обробляють упорядкований список якорів, для кожного якоря, за допомогою детермінованих правил сортують усі попередні невпорядковані вершини в його причинно-наслідковій історії.
Ключем для забезпечення безпеки є забезпечення того, щоб на етапі 2 всі чесні вузли-верифікатори створили впорядкований список якорів, щоб усі списки ділилися тим самим префіксом. У Shoal зроблено такі спостереження щодо вищезгаданих усіх протоколів: всі верифікатори погоджуються з першим впорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча найбільш практична частина синхронізованої версії Bullshark має кращу затримку, ніж асинхронна версія, вона все ще далека від оптимальної.
Основні проблеми:
Середня затримка блоку: у Bullshark кожен парний раунд має анкор, а вершини кожного непарного раунду інтерпретуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб відсортувати анкор, однак вершини в причинно-наслідковій історії анкора потребують більше раундів для очікування сортування анкора. У звичайних випадках вершини в непарних раундах потребують три раунди, а вершини, що не є анкорами, в парних раундах потребують чотири раунди.
Випадки затримки: якщо лідер раунду не зміг достатньо швидко транслювати анкорні точки, то неможливо відсортувати анкорні точки (, тому їх пропускають ), всі не відсортовані вершини з попередніх раундів повинні чекати, поки наступна анкорна точка буде відсортована. Це суттєво знижує продуктивність географічної реплікаційної мережі, особливо тому, що 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 це може призвести до зовсім іншого порядку. Це піднімає суть питання, що динамічний і детермінований вибір обертового якоря є необхідним для досягнення консенсусу, а валідатори повинні досягти згоди щодо упорядкованої історії для вибору майбутніх якорів.
Протокол
Незважаючи на вищезгадані виклики, рішення приховано в простоті. У 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 з детермінаційною частковою синхронізацією на основі лідера. Однак, складність, яку вони вводять, збільшує кількість внутрішніх станів, які потрібно управляти і спостерігати, що ускладнює процес налагодження і потребує більше технік спостереження.
Час затримки також суттєво збільшить затримку, оскільки важливо правильно їх налаштувати, і часто потрібно динамічно коригувати, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повний штраф за затримку через несправного лідера. Тому налаштування часу затримки не повинні бути занадто консервативними, але якщо час затримки занадто короткий, протокол може пропустити хорошого лідера.
На жаль, протоколи, засновані на лідерах (, такі як Hotstuff і Jolteon ), в основному потребують затримки, щоб забезпечити прогрес протоколу щоразу, коли лідер зазнає збою. Якщо немає затримки, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити зламаного лідера від повільного лідера, затримка може призвести до того, що вузли перевірки переглянуть зміну всіх лідерів без активності консенсусу.
У Bullshark затримка використовується для побудови DAG, щоб забезпечити, що під час синхронізації чесні лідери додадуть анкер до DA
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
10 лайків
Нагородити
10
6
Поділіться
Прокоментувати
0/400
LiquidatedNotStirred
· 16год тому
Зайшов в акаунт. Ця технологія має великий потенціал.
Aptos інноваційна рамка Shoal: приносить 40-80% затримки оптимізації для Консенсус Bullshark
Shoal фреймворк: оптимізація затримки консенсусу Bullshark на Aptos
Aptos Labs нещодавно вирішила дві важливі відкриті проблеми в DAG BFT, значно зменшивши затримку і вперше усунувши потребу в тайм-аутах у детерминистичному фактичному протоколі. Загалом, в умовах безвідмовної роботи затримка 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)
Фон та мотивація
У процесі досягнення високої продуктивності блокчейн-мереж зменшення складності зв'язку завжди було в центрі уваги. Проте, цей підхід не приніс значного підвищення пропускної спроможності. Наприклад, ранні версії Diem, в яких реалізовано Hotstuff, досягли лише 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. Нажаль, порівняно з Jolteon, DAG-структура, що підтримує високу пропускну здатність Bullshark, має 50% затримку.
! [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 як консенсусний протокол, де вершини представляють пропозиції, а ребра представляють голосування.
Хоча логіка групового перетину в структурі DAG різна, усі існуючі протоколи консенсусу на основі Narwhal мають таку структуру:
Заброньовані опорні точки: через кілька раундів (, наприклад, у Bullshark через два раунди ) буде обрано попередньо визначеного лідера, вершина якого називається опорною точкою.
Точки сортування: валідатори незалежно, але детерміновано вирішують, які точки сортування використовувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по одному обробляють упорядкований список якорів, для кожного якоря, за допомогою детермінованих правил сортують усі попередні невпорядковані вершини в його причинно-наслідковій історії.
Ключем для забезпечення безпеки є забезпечення того, щоб на етапі 2 всі чесні вузли-верифікатори створили впорядкований список якорів, щоб усі списки ділилися тим самим префіксом. У Shoal зроблено такі спостереження щодо вищезгаданих усіх протоколів: всі верифікатори погоджуються з першим впорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості раундів між впорядкованими якорями в DAG. Хоча найбільш практична частина синхронізованої версії Bullshark має кращу затримку, ніж асинхронна версія, вона все ще далека від оптимальної.
Основні проблеми:
Середня затримка блоку: у Bullshark кожен парний раунд має анкор, а вершини кожного непарного раунду інтерпретуються як голосування. У звичайних випадках потрібно два раунди DAG, щоб відсортувати анкор, однак вершини в причинно-наслідковій історії анкора потребують більше раундів для очікування сортування анкора. У звичайних випадках вершини в непарних раундах потребують три раунди, а вершини, що не є анкорами, в парних раундах потребують чотири раунди.
Випадки затримки: якщо лідер раунду не зміг достатньо швидко транслювати анкорні точки, то неможливо відсортувати анкорні точки (, тому їх пропускають ), всі не відсортовані вершини з попередніх раундів повинні чекати, поки наступна анкорна точка буде відсортована. Це суттєво знижує продуктивність географічної реплікаційної мережі, особливо тому, що 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 це може призвести до зовсім іншого порядку. Це піднімає суть питання, що динамічний і детермінований вибір обертового якоря є необхідним для досягнення консенсусу, а валідатори повинні досягти згоди щодо упорядкованої історії для вибору майбутніх якорів.
Протокол
Незважаючи на вищезгадані виклики, рішення приховано в простоті. У 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 з детермінаційною частковою синхронізацією на основі лідера. Однак, складність, яку вони вводять, збільшує кількість внутрішніх станів, які потрібно управляти і спостерігати, що ускладнює процес налагодження і потребує більше технік спостереження.
Час затримки також суттєво збільшить затримку, оскільки важливо правильно їх налаштувати, і часто потрібно динамічно коригувати, оскільки це сильно залежить від середовища ( мережі ). Перед переходом до наступного лідера протокол сплачує повний штраф за затримку через несправного лідера. Тому налаштування часу затримки не повинні бути занадто консервативними, але якщо час затримки занадто короткий, протокол може пропустити хорошого лідера.
На жаль, протоколи, засновані на лідерах (, такі як Hotstuff і Jolteon ), в основному потребують затримки, щоб забезпечити прогрес протоколу щоразу, коли лідер зазнає збою. Якщо немає затримки, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити зламаного лідера від повільного лідера, затримка може призвести до того, що вузли перевірки переглянуть зміну всіх лідерів без активності консенсусу.
У Bullshark затримка використовується для побудови DAG, щоб забезпечити, що під час синхронізації чесні лідери додадуть анкер до DA