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)
Фон
У процесі досягнення високої продуктивності блокчейн-мережі, люди завжди звертали увагу на Падіння складності комунікації. Проте, цей підхід не призвів до значного підвищення пропускної здатності. Наприклад, Hotstuff, реалізований у ранніх версіях Diem, забезпечував лише 3500 TPS, що значно нижче нашої цілі 100k+ TPS.
Нещодавнє прорив виник із усвідомлення того, що поширення даних є основним вузьким місцем, яке базується на протоколах лідерів, і може виграти від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У статті Narwhal повідомляється про пропускну здатність 160 000 TPS.
Наша реалізація Narwhal Quorum Store відокремлює поширення даних від консенсусу для розширення поточного протоколу консенсусу Jolteon. Jolteon — це протокол на основі лідера, який поєднує лінійний швидкий шлях Tendermint і зміну зору в стилі PBFT, що дозволяє знизити затримку Hotstuff на 33%. Однак, протоколи консенсусу на основі лідера не можуть повною мірою використовувати потенціал пропускної здатності Narwhal. Незважаючи на те, що поширення даних та консенсус відокремлені, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще обмежений.
Отже, ми вирішили розгорнути Bullshark на Narwhal DAG, нульовий витратний консенсусний протокол. На жаль, у порівнянні з Jolteon, структура DAG, що підтримує високу пропускну здатність Bullshark, призвела до 50% падіння.
Ця стаття описує, як Shoal значно зменшує затримку Bullshark.
Фон DAG-BFT
Кожна вершина в Narwhal DAG асоціюється з певним раундом. Щоб увійти в r-й раунд, валідатор спочатку повинен отримати n-f вершин, що належать до (r-1)-го раунду. Кожен валідатор може транслювати одну вершину за раунд, а кожна вершина повинна принаймні посилатися на n-f вершин з попереднього раунду. Через асинхронність мережі різні валідатори можуть в будь-який момент часу спостерігати різні локальні огляди DAG.
Ключова властивість DAG не є неоднозначною: якщо два вузли перевірки мають однакову вершину v у своїх локальних візуалізаціях DAG, то вони мають абсолютно однакову причинно-наслідкову історію v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Загальний передмови
Можна досягти згоди щодо загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk і Bullshark інтерпретують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра - голосування.
Хоча логіка групового перетину в структурі DAG відрізняється, всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована опора: через кілька раундів буде визначено попереднього лідера, вершина якого називається опорою.
Точки прив'язки: валідатори незалежно, але детерміновано вирішують, які точки прив'язки впорядковувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по одному обробляють упорядкований список прив'язок, для кожної прив'язки, за допомогою детерміністичних правил, сортують усі попередні неупорядковані вершини в її причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) всі чесні вузли верифікації створили впорядкований список якорів, щоб всі списки ділили один і той же префікс. У Shoal ми робимо такі спостереження щодо всіх вищезазначених протоколів:
Всі валідатори погоджуються з першим упорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між упорядкованими якорями в DAG. Хоча найбільш практична частина Bullshark синхронної версії має кращу затримку, ніж асинхронна версія, але вона далеко не є оптимальною.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має точку прив'язки, а вершини непарного раунду інтерпретуються як голосування. У звичайних випадках для сортування точок прив'язки потрібно два раунди DAG, однак вершини в причинно-історичному контексті точок прив'язки потребують більше раундів для очікування сортування точок прив'язки. У звичайних випадках вершини в непарному раунді потребують три раунди, а вершини, що не є точками прив'язки, у парному раунді потребують чотири раунди.
Питання 2: затримка випадків відмови, вищевказаний аналіз затримки застосовується до безвідмовної ситуації, з іншого боку, якщо лідер раунду не встигає достатньо швидко транслювати якірні точки, то неможливо впорядкувати якірні точки (, тому вони пропускаються ), тому всі невпорядковані вершини з перших декількох раундів повинні чекати, поки наступна якірна точка буде впорядкована. Це значно знизить продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Shoal фрейм
Shoal через конвеєрну обробку покращив Bullshark( або будь-який інший протокол BFT на основі Narwhal), дозволяючи мати одну точку якоря в кожному раунді та зменшуючи затримку всіх неприв'язаних вершин у DAG до трьох раундів. Shoal також впровадив механізм репутації лідера без витрат у DAG, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними питаннями, з наступних причин:
Попередня обробка конвеєра намагалася змінити основну логіку Bullshark, але це здається неможливим за своєю суттю.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel, що є динамічним вибором майбутніх лідерів на основі минулої продуктивності валідаторів, ідея якірів у Bullshark (. Хоча розбіжності в лідерстві не порушують безпеку цих протоколів, в Bullshark це може призвести до зовсім іншого порядку, що піднімає основне питання: динамічний і детермінований вибір ротаційного якоря є необхідним для досягнення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії, щоб вибрати майбутні якорі.
Як доказ складності проблеми, ми помічаємо, що реалізація Bullshark, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці особливості.
Протокол
Хоча існують вищезгадані виклики, але насправді рішення приховане в простоті.
У Shoal ми покладаємося на здатність виконувати локальні обчислення на DAG і реалізуємо можливість зберігати та переінтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним інсайтом першої впорядкованої прив'язки, Shoal послідовно поєднує кілька екземплярів Bullshark, обробляючи їх у конвеєрному режимі, що робить ) першу впорядковану прив'язку точкою переключення екземплярів, а також ( причинно-історичну прив'язку для обчислення репутації лідера.
![Тонке пояснення 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. Потім, вузли валідації починають використовувати оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark, починаючи з етапу r+1.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Немає більше тайм-аутів
Тайм-аут відіграє вирішальну роль у всіх реалізаціях часткового синхронного BFT на основі лідера. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження та вимагає більше технік спостереження.
Час очікування також суттєво збільшує затримку, оскільки дуже важливо правильно їх налаштувати, і зазвичай потрібно динамічно коригувати, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку для неефективного лідера. Отже, налаштування тайм-ауту не повинні бути надто обережними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хороших лідерів. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не витримують навантаження, і тайм-аут закінчується до того, як вони спричинять прогрес.
На жаль, протокол лідера ), як Hotstuff та Jolteon(, по суті вимагає затримки, щоб забезпечити, що кожного разу, коли лідер виходить з ладу, відбувається
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 лайків
Нагородити
14
9
Поділіться
Прокоментувати
0/400
ChainComedian
· 13год тому
затримка знизилася так сильно, відчуваю, що можна зробити щось велике
Переглянути оригіналвідповісти на0
YouMustMakeBigMoneyEvery
· 07-19 04:14
За межами SOL
Переглянути оригіналвідповісти на0
YouMustMakeBigMoneyEvery
· 07-19 04:14
Стійкий HODL💎
Переглянути оригіналвідповісти на0
VirtualRichDream
· 07-19 03:33
затримка Падіння так багато aptos пішло
Переглянути оригіналвідповісти на0
FOMOSapien
· 07-19 03:33
Зменшити затримку краще, ніж просто A з президентом
Переглянути оригіналвідповісти на0
BearEatsAll
· 07-19 03:30
aptos може бути ще швидше? бик啊
Переглянути оригіналвідповісти на0
PaperHandsCriminal
· 07-19 03:26
Хтось знає, яка користь від цієї затримки падіння, адже вона так і не змогла запобігти моєму обдурюванню людей, як лохів.
Переглянути оригіналвідповісти на0
ApeShotFirst
· 07-19 03:23
знову зростання, якщо затримка, то делістинг.
Переглянути оригіналвідповісти на0
BlockchainFries
· 07-19 03:15
Дивлячись на те, що затримка зменшилася так сильно, то спершу куплю маленьку Позицію.
Shoal фрейм значно Падіння затримка Консенсус Bullshark на Aptos
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)
Фон
У процесі досягнення високої продуктивності блокчейн-мережі, люди завжди звертали увагу на Падіння складності комунікації. Проте, цей підхід не призвів до значного підвищення пропускної здатності. Наприклад, Hotstuff, реалізований у ранніх версіях Diem, забезпечував лише 3500 TPS, що значно нижче нашої цілі 100k+ TPS.
Нещодавнє прорив виник із усвідомлення того, що поширення даних є основним вузьким місцем, яке базується на протоколах лідерів, і може виграти від паралелізації. Система Narwhal відокремлює поширення даних від основної логіки консенсусу, пропонуючи архітектуру, в якій всі валідатори одночасно поширюють дані, а компоненти консенсусу лише сортують невелику кількість метаданих. У статті Narwhal повідомляється про пропускну здатність 160 000 TPS.
Наша реалізація Narwhal Quorum Store відокремлює поширення даних від консенсусу для розширення поточного протоколу консенсусу Jolteon. Jolteon — це протокол на основі лідера, який поєднує лінійний швидкий шлях Tendermint і зміну зору в стилі PBFT, що дозволяє знизити затримку Hotstuff на 33%. Однак, протоколи консенсусу на основі лідера не можуть повною мірою використовувати потенціал пропускної здатності Narwhal. Незважаючи на те, що поширення даних та консенсус відокремлені, з ростом пропускної здатності лідер Hotstuff/Jolteon все ще обмежений.
Отже, ми вирішили розгорнути Bullshark на Narwhal DAG, нульовий витратний консенсусний протокол. На жаль, у порівнянні з Jolteon, структура DAG, що підтримує високу пропускну здатність Bullshark, призвела до 50% падіння.
Ця стаття описує, як Shoal значно зменшує затримку Bullshark.
Фон DAG-BFT
Кожна вершина в Narwhal DAG асоціюється з певним раундом. Щоб увійти в r-й раунд, валідатор спочатку повинен отримати n-f вершин, що належать до (r-1)-го раунду. Кожен валідатор може транслювати одну вершину за раунд, а кожна вершина повинна принаймні посилатися на n-f вершин з попереднього раунду. Через асинхронність мережі різні валідатори можуть в будь-який момент часу спостерігати різні локальні огляди DAG.
Ключова властивість DAG не є неоднозначною: якщо два вузли перевірки мають однакову вершину v у своїх локальних візуалізаціях DAG, то вони мають абсолютно однакову причинно-наслідкову історію v.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Загальний передмови
Можна досягти згоди щодо загального порядку всіх вершин у DAG без додаткових витрат на зв'язок. Для цього валідатори в DAG-Rider, Tusk і Bullshark інтерпретують структуру DAG як консенсусний протокол, де вершини представляють пропозиції, а ребра - голосування.
Хоча логіка групового перетину в структурі DAG відрізняється, всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована опора: через кілька раундів буде визначено попереднього лідера, вершина якого називається опорою.
Точки прив'язки: валідатори незалежно, але детерміновано вирішують, які точки прив'язки впорядковувати, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по одному обробляють упорядкований список прив'язок, для кожної прив'язки, за допомогою детерміністичних правил, сортують усі попередні неупорядковані вершини в її причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) всі чесні вузли верифікації створили впорядкований список якорів, щоб всі списки ділили один і той же префікс. У Shoal ми робимо такі спостереження щодо всіх вищезазначених протоколів:
Всі валідатори погоджуються з першим упорядкованим якорем.
Bullshark затримка
Затримка Bullshark залежить від кількості обертів між упорядкованими якорями в DAG. Хоча найбільш практична частина Bullshark синхронної версії має кращу затримку, ніж асинхронна версія, але вона далеко не є оптимальною.
Питання 1: середня затримка блоку. У Bullshark кожен парний раунд має точку прив'язки, а вершини непарного раунду інтерпретуються як голосування. У звичайних випадках для сортування точок прив'язки потрібно два раунди DAG, однак вершини в причинно-історичному контексті точок прив'язки потребують більше раундів для очікування сортування точок прив'язки. У звичайних випадках вершини в непарному раунді потребують три раунди, а вершини, що не є точками прив'язки, у парному раунді потребують чотири раунди.
Питання 2: затримка випадків відмови, вищевказаний аналіз затримки застосовується до безвідмовної ситуації, з іншого боку, якщо лідер раунду не встигає достатньо швидко транслювати якірні точки, то неможливо впорядкувати якірні точки (, тому вони пропускаються ), тому всі невпорядковані вершини з перших декількох раундів повинні чекати, поки наступна якірна точка буде впорядкована. Це значно знизить продуктивність географічної реплікаційної мережі, особливо тому, що Bullshark використовує тайм-аут для очікування лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Shoal фрейм
Shoal через конвеєрну обробку покращив Bullshark( або будь-який інший протокол BFT на основі Narwhal), дозволяючи мати одну точку якоря в кожному раунді та зменшуючи затримку всіх неприв'язаних вершин у DAG до трьох раундів. Shoal також впровадив механізм репутації лідера без витрат у DAG, що робить вибір схильним до швидких лідерів.
Виклик
У контексті протоколу DAG, конвеєрна обробка та репутація лідера вважаються складними питаннями, з наступних причин:
Попередня обробка конвеєра намагалася змінити основну логіку Bullshark, але це здається неможливим за своєю суттю.
Репутація лідера вводиться в DiemBFT і формалізується в Carousel, що є динамічним вибором майбутніх лідерів на основі минулої продуктивності валідаторів, ідея якірів у Bullshark (. Хоча розбіжності в лідерстві не порушують безпеку цих протоколів, в Bullshark це може призвести до зовсім іншого порядку, що піднімає основне питання: динамічний і детермінований вибір ротаційного якоря є необхідним для досягнення консенсусу, і валідатори повинні досягти згоди щодо впорядкованої історії, щоб вибрати майбутні якорі.
Як доказ складності проблеми, ми помічаємо, що реалізація Bullshark, включаючи поточну реалізацію в продуктивному середовищі, не підтримує ці особливості.
Протокол
Хоча існують вищезгадані виклики, але насправді рішення приховане в простоті.
У Shoal ми покладаємося на здатність виконувати локальні обчислення на DAG і реалізуємо можливість зберігати та переінтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним інсайтом першої впорядкованої прив'язки, Shoal послідовно поєднує кілька екземплярів Bullshark, обробляючи їх у конвеєрному режимі, що робить ) першу впорядковану прив'язку точкою переключення екземплярів, а також ( причинно-історичну прив'язку для обчислення репутації лідера.
![Тонке пояснення 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. Потім, вузли валідації починають використовувати оновлену функцію вибору якорів F' для виконання нового екземпляра Bullshark, починаючи з етапу r+1.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Немає більше тайм-аутів
Тайм-аут відіграє вирішальну роль у всіх реалізаціях часткового синхронного BFT на основі лідера. Однак їхня складність збільшує кількість внутрішніх станів, які потрібно керувати та спостерігати, що ускладнює процес налагодження та вимагає більше технік спостереження.
Час очікування також суттєво збільшує затримку, оскільки дуже важливо правильно їх налаштувати, і зазвичай потрібно динамічно коригувати, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку для неефективного лідера. Отже, налаштування тайм-ауту не повинні бути надто обережними, але якщо час тайм-ауту занадто короткий, протокол може пропустити хороших лідерів. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не витримують навантаження, і тайм-аут закінчується до того, як вони спричинять прогрес.
На жаль, протокол лідера ), як Hotstuff та Jolteon(, по суті вимагає затримки, щоб забезпечити, що кожного разу, коли лідер виходить з ладу, відбувається