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, що розділяє поширення даних та консенсус, а також як його використовувати для розширення поточного консенсусного протоколу Jolteon. Jolteon є протоколом на основі лідера, що поєднує лінійний швидкий шлях Tendermint та зміни зору в стилі PBFT, що дозволяє знизити затримку Hotstuff на 33%. Проте, протоколи консенсусу на основі лідера не можуть в повній мірі використовувати потенціал пропускної здатності Narwhal. Незважаючи на розділення поширення даних та консенсусу, з ростом пропускної здатності, лідер Hotstuff/Jolteon все ще зазнає обмежень.
Тому було вирішено розгорнути Bullshark на основі Narwhal DAG, протоколу консенсусу з нульовими витратами на комунікацію. На жаль, у порівнянні з Jolteon, структура DAG, що підтримує високу пропускну здатність Bullshark, має 50% Падіння.
Ця стаття описує, як 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 як протокол консенсусу, де вершини представляють пропозиції, а ребра — голосування.
Хоча логіка групових перетинів у структурі DAG відрізняється, але всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована точка: кожні кілька раундів (, як у Bullshark, кожні два раунди ) є заздалегідь визначений лідер, його вершина називається точка прив'язки.
Точки прив'язки: валідатори незалежно, але з певністю вирішують, які точки прив'язки замовити, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють упорядкований список анкерів, для кожного анкеру, за допомогою детерміністичних правил, сортують всі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) усі чесні вузли перевірки створили впорядкований список якорів, щоб всі списки мали спільний префікс. У Shoal зроблено такі спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
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, включаючи реалізацію в поточному виробничому середовищі, не підтримує ці особливості.
Протокол
Хоча існують зазначені вище виклики, але рішення приховане за простотою.
У Shoal ми покладаємося на можливість виконувати локальні обчислення на DAG і реалізуємо здатність зберігати та повторно інтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним інсайтом першої впорядкованої якоря, Shoal по черзі комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ) перший впорядкований якорь точкою перемикання екземпляра, а також ( причинно-історичним контекстом якоря для обчислення репутації лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.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-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 з детермінованим підходом, що базуються на лідерах. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Час вичерпання також суттєво збільшує затримку, оскільки важливо правильно їх налаштувати, і їх зазвичай потрібно динамічно налаштовувати, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку часу вичерпання для лідера з помилкою. Тому налаштування часу вичерпання не можуть бути занадто обережними, але якщо час вичерпання занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не витримують навантаження, і час вичерпання закінчується до того, як вони зможуть просунутися вперед.
На жаль, протокол, заснований на лідерах ), таких як Hotstuff та Jolteon (, в основному потребує затримки, щоб забезпечити прогрес протоколу щоразу, коли лідер зазнає збою. Якщо немає затримки, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити, чи є у проблем.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
23 лайків
Нагородити
23
6
Поділіться
Прокоментувати
0/400
VirtualRichDream
· 07-25 11:15
затримка降这么多 aptos要До місяця了
Переглянути оригіналвідповісти на0
CoffeeNFTs
· 07-22 19:02
Ця затримка Падіння трохи приваблива, га?
Переглянути оригіналвідповісти на0
RugDocDetective
· 07-22 19:01
Який бик! Нарешті вийшов план Aptos, якого я так довго чекав!
Переглянути оригіналвідповісти на0
RuntimeError
· 07-22 19:00
чи справді працює цей новий трюк aptos?
Переглянути оригіналвідповісти на0
UnluckyValidator
· 07-22 18:58
Затримка високих днів нарешті закінчилася, відчуваю себе мляво вже півроку.
Shoal фрейм значно зменшив затримку Bullshark у блокчейні Aptos на 40-80%
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, що розділяє поширення даних та консенсус, а також як його використовувати для розширення поточного консенсусного протоколу Jolteon. Jolteon є протоколом на основі лідера, що поєднує лінійний швидкий шлях Tendermint та зміни зору в стилі PBFT, що дозволяє знизити затримку Hotstuff на 33%. Проте, протоколи консенсусу на основі лідера не можуть в повній мірі використовувати потенціал пропускної здатності Narwhal. Незважаючи на розділення поширення даних та консенсусу, з ростом пропускної здатності, лідер Hotstuff/Jolteon все ще зазнає обмежень.
Тому було вирішено розгорнути Bullshark на основі Narwhal DAG, протоколу консенсусу з нульовими витратами на комунікацію. На жаль, у порівнянні з Jolteon, структура DAG, що підтримує високу пропускну здатність Bullshark, має 50% Падіння.
Ця стаття описує, як 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 як протокол консенсусу, де вершини представляють пропозиції, а ребра — голосування.
Хоча логіка групових перетинів у структурі DAG відрізняється, але всі існуючі консенсусні протоколи на основі Narwhal мають таку структуру:
Запланована точка: кожні кілька раундів (, як у Bullshark, кожні два раунди ) є заздалегідь визначений лідер, його вершина називається точка прив'язки.
Точки прив'язки: валідатори незалежно, але з певністю вирішують, які точки прив'язки замовити, а які пропустити.
Сортування причинно-наслідкової історії: валідатори по черзі обробляють упорядкований список анкерів, для кожного анкеру, за допомогою детерміністичних правил, сортують всі попередні неупорядковані вершини в його причинно-наслідковій історії.
Ключем досягнення безпеки є забезпечення того, щоб на етапі (2) усі чесні вузли перевірки створили впорядкований список якорів, щоб всі списки мали спільний префікс. У Shoal зроблено такі спостереження щодо всіх вищезазначених протоколів:
Усі валідатори погоджуються з першим впорядкованим якорем.
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, включаючи реалізацію в поточному виробничому середовищі, не підтримує ці особливості.
Протокол
Хоча існують зазначені вище виклики, але рішення приховане за простотою.
У Shoal ми покладаємося на можливість виконувати локальні обчислення на DAG і реалізуємо здатність зберігати та повторно інтерпретувати інформацію з попередніх раундів. Завдяки тому, що всі валідатори погоджуються з основним інсайтом першої впорядкованої якоря, Shoal по черзі комбінує кілька екземплярів Bullshark для їх конвеєрної обробки, що робить ) перший впорядкований якорь точкою перемикання екземпляра, а також ( причинно-історичним контекстом якоря для обчислення репутації лідера.
! [10 000 слів, що пояснюють рамки Shoal: як зменшити затримку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.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-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 з детермінованим підходом, що базуються на лідерах. Однак, їхня складність призводить до збільшення кількості внутрішніх станів, які потрібно управляти та спостерігати, що ускладнює процес налагодження та вимагає більше технологій спостереження.
Час вичерпання також суттєво збільшує затримку, оскільки важливо правильно їх налаштувати, і їх зазвичай потрібно динамічно налаштовувати, оскільки це сильно залежить від середовища ) мережі (. Перед переходом до наступного лідера протокол сплачує повний штраф за затримку часу вичерпання для лідера з помилкою. Тому налаштування часу вичерпання не можуть бути занадто обережними, але якщо час вичерпання занадто короткий, протокол може пропустити хорошого лідера. Наприклад, ми спостерігали, що в умовах високого навантаження лідери в Jolteon/Hotstuff не витримують навантаження, і час вичерпання закінчується до того, як вони зможуть просунутися вперед.
На жаль, протокол, заснований на лідерах ), таких як Hotstuff та Jolteon (, в основному потребує затримки, щоб забезпечити прогрес протоколу щоразу, коли лідер зазнає збою. Якщо немає затримки, навіть зламаний лідер може назавжди зупинити протокол. Оскільки під час асинхронного періоду неможливо відрізнити, чи є у проблем.