У першій частині ми вивчили, як працює класичний PBFT (практична візантійська відмовостійкість) консенсус та як працювали ранні версії HotStuff. Ми також дізналися, як MonadBFT вирішує проблему кінцевих форків HotStuff, тобто проблему, коли дійсні блоки в конвеєрних системах іноді можуть бути відкинуті.
Ця проблема з форком викликає дві основні проблеми: 1) вона порушує винагороду чесних будівельників блоків, 2) може призвести до затримки в мережі.
MonadBFT впроваджує правила повторного пропозиції та механізм голосування без бекінгу для усунення проблеми хвостового форку, забезпечуючи, що будь-який належно затверджений блок від чесного пропонувальника може потрапити в ланцюг.
У другій частині ми розглянемо ще дві характеристики MonadBFT: 1) спекулятивна остаточність та 2) оптимістична реактивність. Ми також розглянемо вплив MonadBFT на розробників.
Однократна спекуляція остаточність
Окрім опору хвостовому форку, ще однією основною характеристикою MonadBFT є одноразова спекулятивна остаточність.
У практичному застосуванні це означає, що клієнт і користувач можуть отримати підтвердження транзакції відразу після того, як блок отримав більшість голосів, навіть до завершення наступного раунду.
Згадайте, що в базовому протоколі HotStuff блок зазвичай проходить щонайменше два етапи (як-от Fast-Hotstuff і Diem-BFT), перш ніж вважатися остаточно затвердженим (незворотним): перший етап отримання сертифіката кваліфікованої більшості (QC) (для блокування блоку з ≥2f+1 голосами), другий етап — це побудова та подання блоку наступним лідером на основі цього сертифіката кваліфікованої більшості (QC).
Цей двохетапний комітет є необхідним для забезпечення безпеки: як тільки достатня кількість чесних вузлів заблокують блок, блоки, які з ним конфліктують, не можуть отримати кворум, а наступний раунд подання зробить його постійним. Тому клієнту зазвичай може знадобитися почекати наступний блок або наступний раунд, щоб дізнатися, чи була попередня транзакція остаточною.
MonadBFT в основному дозволяє вважати транзакції достатніми (можна безпечно виконувати) після одного раунду голосування. Це так звана спекулятивна остаточність.
Коли лідер пропонує блок, а валідатори голосують, щоб сформувати QC цього блоку, блок знаходиться в стані голосування (заблокований кворумом). У MonadBFT, як тільки валідатор формує QC, транзакція для цього блоку виконується, і навіть клієнту надсилається попереднє підтвердження про те, що блок (спекулятивно) прийнятий. Це все одно, що сказати: «У нас переважна більшість людей згодна з цим блоком». Якщо не станеться чогось дуже несподіваного, блокування можна вважати підтвердженим. ”
Це миттєве підтвердження є оптимістичним. Блок ще не був поданий у реєстр. Це відбудеться, коли з'явиться наступна пропозиція і підтвердить його (QC-on QC), але в нормальних умовах нічого не зможе його скасувати. Єдиним випадком, коли можна скасувати спекулятивне виконання блоку, є атака еквівалентності лідера (тобто коли на одній і тій же висоті пропонуються два різні блоки для розподілу голосів).
Ви можете думати про спекулятивну завершеність як про хороший побічний продукт опору хвостовим вилам. Опір хвостовій вилці гарантує, що поточна пропозиція не буде відкинута, навіть якщо наступний лідер зазнає краху (завдяки повторній пропозиції та правилу NEC). Єдиний випадок, коли спекулятивно виконаний блок відкидається, це коли відбувається атака еквівалентності з боку оригінального ініціатора (доказово шкідлива помилка подвійного підпису), де: 1) вона може бути виявлена конфліктним QC; 2) карається; 3) Вкрай рідко.
У попередньому протоколі вони не гарантували, що наступний лідер повторно запропонує попередній Блок, тому можливою є хвостова форк, що руйнує спекулятивне припущення.
оптимістичний відгук
У більшості протоколів консенсусу після кожного раунду є вбудоване очікування, наприклад, буферний період або тайм-аут. Це робиться для того, щоб забезпечити прибуття всіх повідомлень перед тим, як продовжити. Це механізм захисту, що призначений для обробки найгірших сценаріїв, таких як крах лідера або взагалі відсутність відправленої інформації.
Ці тайм-аути зазвичай занадто консервативні. Якщо мережа працює нормально і всі валідатори діють правильно, то фіксоване очікування стане зайвими витратами. Блоки могли б бути завершені швидше, але протокол затримав їх на всякий випадок.
MonadBFT впроваджує оптимістичну реакцію, що означає, що протокол може негайно просуватися на основі інформації з мережі, а не завжди покладатися на фіксовані таймери. Принципи дизайну тут можна узагальнити як "якщо можливо швидко, то швидко, а терпіння потрібне лише тоді, коли це необхідно".
Дизайн MonadBFT дозволяє йому у нормальних умовах, навіть під час відновлення після збоїв, не призупиняти очікування запланованого тайм-ауту, якщо це не потрібно.
На щасливому шляху (це означає, що у нас є чесний лідер): у пропозиціях або голосуваннях немає вбудованих затримок. Як тільки настає черга лідера, він пропонує блок. Як тільки валідатор отримує дійсну пропозицію, він негайно голосує. Коли лідер (або, точніше, наступний лідер, оскільки у конвеєрному HotStuff голосування надсилається наступному пропоненту) збирає 2f+1 голосів, формується QC, і його можна поширити. У дизайні з оптимістичною реакційною здатністю це негайно запускає наступну стадію.
На практиці це означає, що якщо мережеве затримання між вузлами становить 100 мілісекунд, тоді консенсус може бути досягнуто всього за кілька сотень мілісекунд (додавши витрати на обчислення та агрегацію).
Якщо не потрібно, він не буде чекати, наприклад, цілу секунду "часового інтервалу". Це відрізняється від моделі slot-and-epoch, що використовується в основній мережі Ethereum. В Ethereum інтервал часу виробництва блоків фіксований на 12 секунд. Навіть якщо всі заздалегідь підготувалися, протокол все одно чекатиме.
Метод MonadBFT усуває непотрібні затримки. Він зберігає структуру конвеєра HotStuff, але усуває жорстке правило "повинно чекати Δ секунд" в нормальних умовах. Це означає, що він може перевершувати системи з часовими обмеженнями за реактивністю, не жертвуючи безпекою.
На невеселому шляху (невдача лідера): У багатьох протоколах консенсусу, коли лідер не може запропонувати блок, інші вузли усвідомлюють це лише після тайм-ауту Δ. Наприклад, якщо Δ становить 1 секунду, то цей час фактично втрачається. MonadBFT обробляє це інакше. Коли валідатори виявляють, що пропозиція втрачена, вони негайно транслюють повідомлення про тайм-аут (TC або сертифікат тайм-ауту). Як тільки відбудеться 2f+1 тайм-аутів, новий лідер візьме на себе управління. Перехід до нової точки зору ініціюється на основі доказів, заснованих на кворумі, а не за допомогою годинника.
Порівняння з консенсусом hotstuff-family
MonadBFT побудований на основі сімейства протоколів консенсусу HotStuff, але виділяється реалізацією комбінації бажаних функцій. Раніше протоколи часто оптимізувалися для певних параметрів, таких як пропускна здатність трубопроводу або лінійний зв'язок, але доводилося жертвувати іншими. MonadBFT унікально поєднує в собі складність лінійних повідомлень, конвеєрне подання, сильний опір розколюванню хвоста, миттєву реакцію без фіксованої затримки та ефективні механізми відновлення, зберігаючи при цьому швидку доопрацювання та високі гарантії доступності. У наступній таблиці підсумовується, як MonadBFT порівнюється з іншими протоколами BFT ротаційного лідера за цими ключовими параметрами:
Що це означає для розробників та користувачів?
Для розробників MonadBFT означає кілька моментів:
Простішу модель остаточної визначеності: використовуючи MonadBFT, ви можете розглядати блоки з QC (абсолютна більшість голосів) як фактично остаточно визначені, оскільки протокол остаточно їх визначить або накладе покарання. Розробники можуть з високою впевненістю безпечно працювати з 1 підтвердженням блоку.
Поліпшення користувацького досвіду програми: Якщо ви розробляєте програму з високою пропускною здатністю (біржа, ігри тощо), низька затримка та стійкість до форків MonadBFT перетворяться на більш плавний користувацький досвід. Користувачі майже миттєво можуть бачити підтвердження своїх операцій і не стикаються з заплутаними реорганізаціями або відкатами. Таким чином, ви зможете створити додаток з остаточною визначеністю та швидкими оновленнями.
Детерміновані поведінки: більш суворі правила MonadBFT (наприклад, вимога повторного запропонування) зменшують невизначеність, пов'язану з включенням блоків. Через тонкі часові фактори, такі як те, чи голоси або тайм-аут спочатку досягають лідера, стає менше "пограничних випадків", коли блоки включаються або пропускаються. MonadBFT замінює цю часову чутливу неясність чіткими правилами та перевірними доказами. Це спрощує аргументацію правильності протоколу та тестування. Це також надає чіткі підстави для ідентифікації несправних вузлів (наприклад, якщо хтось не зміг повторно запропонувати або запропонував конфліктний блок, ви знаєте, що вони порушили протокол).
Простір для масштабування: Якщо ви розробник, який зосереджений на масштабуванні, MonadBFT надає вам більше простору до того, як ви зіштовхнетеся з вузьким місцем. На відміну від вторинних протоколів, ви можете легше збільшити розмір блоку або кількість валідаторів. А такі функції, як розподіл блоків з використанням кодування з стиранням, означають, що ви можете передавати великі обсяги даних по мережі, не перевантажуючи окремий вузол. Це робить можливим націлювання на вищу пропускну спроможність, відкриваючи простір для проектування більш амбітних децентралізованих додатків.
Для кінцевих користувачів: Звичайні користувачі не зрозуміють нічого з того, про що ми тут говоримо, але вони відчують його вплив. Завдяки MonadBFT як основі Monad Блоку, користувачі можуть очікувати всіх хороших рис без жертвування децентралізацією та опором цензурі.
Швидше підтвердження: Транзакції (наприклад, надсилання токенів, обмін активів, випуск NFT, виконання угод) будуть швидко підтверджені.
Зменшення несподіванок: Консистентність стану ланцюга вища, оскільки такі речі, як хвостовий форк, які по суті є переробкою, були усунуті.
Справедливість та прозорість: Поліпшення консенсусу непрямо означає, що робота блокчейну стає більш справедливою. Жоден окремий валідатор не може легко перевіряти транзакції або маніпулювати порядком між блоками.
Висновок
Підсумовуючи, MonadBFT на основі консолідації стилю HotStuff у конвеєрі запроваджує чотири ключові інновації:
Опір кінцевим форкам: MonadBFT є першим конвеєрним BFT протоколом, що усуває атаки кінцевих форків. Він досягає цього шляхом повторного подання останнього голосування за блок наступним лідером у випадку невдачі попереднього лідера або шляхом надання сертифікату без підтвердження (NEC), що свідчить про відсутність підтримки цього блоку. Це гарантує, що будь-який блок, який отримав абсолютну більшість підтримки, не буде відкинутий, що захищає винагороду чесних лідерів та запобігає зловмисним реорганізаціям і витягуванню MEV з міжблочних транзакцій.
Остаточність одноразової спекуляції: Валідатори можуть підтвердити блок після одноразового зв'язку (один лідер пропонує та голосує), надаючи клієнтам миттєву гарантію включення. Це спекулятивне підтвердження буде відновлено лише під час атаки рівності лідера (дії, які можуть бути доведені та покарані), що робить його в практиці безпечною гіпотезою.
Оптимістичний відгук: Протокол працює на швидкості мережі, без вроджених затримок. Лідер одразу просуває консенсус після отримання необхідних голосів, зміни в поданні відбуваються одразу після спостереження за закінченням кворуму, а не чекаючи фіксованого тайм-інтервалу. Такий дизайн оптимістичного відгуку мінімізує час очікування та максимізує пропускну здатність, при цьому залишається стійким до асинхронності та збоїв.
Лінійна комунікація: На щасливому шляху (тобто, коли лідер є чесним), складність повідомлень та верифікацій має лінійний зв'язок з кількістю верифікаторів. MonadBFT зберігає ефективну комунікаційну модель HotStuff, використовуючи агреговані підписи та просту трансляцію лідера до верифікаторів, що дозволяє протоколу масштабуватися до сотень верифікаторів без виникнення проблем з продуктивністю.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
MonadBFT аналіз (частина друга): що це означає для розробників та користувачів
У першій частині ми вивчили, як працює класичний PBFT (практична візантійська відмовостійкість) консенсус та як працювали ранні версії HotStuff. Ми також дізналися, як MonadBFT вирішує проблему кінцевих форків HotStuff, тобто проблему, коли дійсні блоки в конвеєрних системах іноді можуть бути відкинуті.
Ця проблема з форком викликає дві основні проблеми: 1) вона порушує винагороду чесних будівельників блоків, 2) може призвести до затримки в мережі.
MonadBFT впроваджує правила повторного пропозиції та механізм голосування без бекінгу для усунення проблеми хвостового форку, забезпечуючи, що будь-який належно затверджений блок від чесного пропонувальника може потрапити в ланцюг.
У другій частині ми розглянемо ще дві характеристики MonadBFT: 1) спекулятивна остаточність та 2) оптимістична реактивність. Ми також розглянемо вплив MonadBFT на розробників.
Однократна спекуляція остаточність
Окрім опору хвостовому форку, ще однією основною характеристикою MonadBFT є одноразова спекулятивна остаточність.
У практичному застосуванні це означає, що клієнт і користувач можуть отримати підтвердження транзакції відразу після того, як блок отримав більшість голосів, навіть до завершення наступного раунду.
Згадайте, що в базовому протоколі HotStuff блок зазвичай проходить щонайменше два етапи (як-от Fast-Hotstuff і Diem-BFT), перш ніж вважатися остаточно затвердженим (незворотним): перший етап отримання сертифіката кваліфікованої більшості (QC) (для блокування блоку з ≥2f+1 голосами), другий етап — це побудова та подання блоку наступним лідером на основі цього сертифіката кваліфікованої більшості (QC).
Цей двохетапний комітет є необхідним для забезпечення безпеки: як тільки достатня кількість чесних вузлів заблокують блок, блоки, які з ним конфліктують, не можуть отримати кворум, а наступний раунд подання зробить його постійним. Тому клієнту зазвичай може знадобитися почекати наступний блок або наступний раунд, щоб дізнатися, чи була попередня транзакція остаточною.
MonadBFT в основному дозволяє вважати транзакції достатніми (можна безпечно виконувати) після одного раунду голосування. Це так звана спекулятивна остаточність.
Коли лідер пропонує блок, а валідатори голосують, щоб сформувати QC цього блоку, блок знаходиться в стані голосування (заблокований кворумом). У MonadBFT, як тільки валідатор формує QC, транзакція для цього блоку виконується, і навіть клієнту надсилається попереднє підтвердження про те, що блок (спекулятивно) прийнятий. Це все одно, що сказати: «У нас переважна більшість людей згодна з цим блоком». Якщо не станеться чогось дуже несподіваного, блокування можна вважати підтвердженим. ”
Це миттєве підтвердження є оптимістичним. Блок ще не був поданий у реєстр. Це відбудеться, коли з'явиться наступна пропозиція і підтвердить його (QC-on QC), але в нормальних умовах нічого не зможе його скасувати. Єдиним випадком, коли можна скасувати спекулятивне виконання блоку, є атака еквівалентності лідера (тобто коли на одній і тій же висоті пропонуються два різні блоки для розподілу голосів).
Ви можете думати про спекулятивну завершеність як про хороший побічний продукт опору хвостовим вилам. Опір хвостовій вилці гарантує, що поточна пропозиція не буде відкинута, навіть якщо наступний лідер зазнає краху (завдяки повторній пропозиції та правилу NEC). Єдиний випадок, коли спекулятивно виконаний блок відкидається, це коли відбувається атака еквівалентності з боку оригінального ініціатора (доказово шкідлива помилка подвійного підпису), де: 1) вона може бути виявлена конфліктним QC; 2) карається; 3) Вкрай рідко.
У попередньому протоколі вони не гарантували, що наступний лідер повторно запропонує попередній Блок, тому можливою є хвостова форк, що руйнує спекулятивне припущення.
оптимістичний відгук
У більшості протоколів консенсусу після кожного раунду є вбудоване очікування, наприклад, буферний період або тайм-аут. Це робиться для того, щоб забезпечити прибуття всіх повідомлень перед тим, як продовжити. Це механізм захисту, що призначений для обробки найгірших сценаріїв, таких як крах лідера або взагалі відсутність відправленої інформації.
Ці тайм-аути зазвичай занадто консервативні. Якщо мережа працює нормально і всі валідатори діють правильно, то фіксоване очікування стане зайвими витратами. Блоки могли б бути завершені швидше, але протокол затримав їх на всякий випадок.
MonadBFT впроваджує оптимістичну реакцію, що означає, що протокол може негайно просуватися на основі інформації з мережі, а не завжди покладатися на фіксовані таймери. Принципи дизайну тут можна узагальнити як "якщо можливо швидко, то швидко, а терпіння потрібне лише тоді, коли це необхідно".
Дизайн MonadBFT дозволяє йому у нормальних умовах, навіть під час відновлення після збоїв, не призупиняти очікування запланованого тайм-ауту, якщо це не потрібно.
На щасливому шляху (це означає, що у нас є чесний лідер): у пропозиціях або голосуваннях немає вбудованих затримок. Як тільки настає черга лідера, він пропонує блок. Як тільки валідатор отримує дійсну пропозицію, він негайно голосує. Коли лідер (або, точніше, наступний лідер, оскільки у конвеєрному HotStuff голосування надсилається наступному пропоненту) збирає 2f+1 голосів, формується QC, і його можна поширити. У дизайні з оптимістичною реакційною здатністю це негайно запускає наступну стадію.
На практиці це означає, що якщо мережеве затримання між вузлами становить 100 мілісекунд, тоді консенсус може бути досягнуто всього за кілька сотень мілісекунд (додавши витрати на обчислення та агрегацію).
Якщо не потрібно, він не буде чекати, наприклад, цілу секунду "часового інтервалу". Це відрізняється від моделі slot-and-epoch, що використовується в основній мережі Ethereum. В Ethereum інтервал часу виробництва блоків фіксований на 12 секунд. Навіть якщо всі заздалегідь підготувалися, протокол все одно чекатиме.
Метод MonadBFT усуває непотрібні затримки. Він зберігає структуру конвеєра HotStuff, але усуває жорстке правило "повинно чекати Δ секунд" в нормальних умовах. Це означає, що він може перевершувати системи з часовими обмеженнями за реактивністю, не жертвуючи безпекою.
На невеселому шляху (невдача лідера): У багатьох протоколах консенсусу, коли лідер не може запропонувати блок, інші вузли усвідомлюють це лише після тайм-ауту Δ. Наприклад, якщо Δ становить 1 секунду, то цей час фактично втрачається. MonadBFT обробляє це інакше. Коли валідатори виявляють, що пропозиція втрачена, вони негайно транслюють повідомлення про тайм-аут (TC або сертифікат тайм-ауту). Як тільки відбудеться 2f+1 тайм-аутів, новий лідер візьме на себе управління. Перехід до нової точки зору ініціюється на основі доказів, заснованих на кворумі, а не за допомогою годинника.
Порівняння з консенсусом hotstuff-family
MonadBFT побудований на основі сімейства протоколів консенсусу HotStuff, але виділяється реалізацією комбінації бажаних функцій. Раніше протоколи часто оптимізувалися для певних параметрів, таких як пропускна здатність трубопроводу або лінійний зв'язок, але доводилося жертвувати іншими. MonadBFT унікально поєднує в собі складність лінійних повідомлень, конвеєрне подання, сильний опір розколюванню хвоста, миттєву реакцію без фіксованої затримки та ефективні механізми відновлення, зберігаючи при цьому швидку доопрацювання та високі гарантії доступності. У наступній таблиці підсумовується, як MonadBFT порівнюється з іншими протоколами BFT ротаційного лідера за цими ключовими параметрами:
Що це означає для розробників та користувачів?
Для розробників MonadBFT означає кілька моментів:
Простішу модель остаточної визначеності: використовуючи MonadBFT, ви можете розглядати блоки з QC (абсолютна більшість голосів) як фактично остаточно визначені, оскільки протокол остаточно їх визначить або накладе покарання. Розробники можуть з високою впевненістю безпечно працювати з 1 підтвердженням блоку.
Поліпшення користувацького досвіду програми: Якщо ви розробляєте програму з високою пропускною здатністю (біржа, ігри тощо), низька затримка та стійкість до форків MonadBFT перетворяться на більш плавний користувацький досвід. Користувачі майже миттєво можуть бачити підтвердження своїх операцій і не стикаються з заплутаними реорганізаціями або відкатами. Таким чином, ви зможете створити додаток з остаточною визначеністю та швидкими оновленнями.
Детерміновані поведінки: більш суворі правила MonadBFT (наприклад, вимога повторного запропонування) зменшують невизначеність, пов'язану з включенням блоків. Через тонкі часові фактори, такі як те, чи голоси або тайм-аут спочатку досягають лідера, стає менше "пограничних випадків", коли блоки включаються або пропускаються. MonadBFT замінює цю часову чутливу неясність чіткими правилами та перевірними доказами. Це спрощує аргументацію правильності протоколу та тестування. Це також надає чіткі підстави для ідентифікації несправних вузлів (наприклад, якщо хтось не зміг повторно запропонувати або запропонував конфліктний блок, ви знаєте, що вони порушили протокол).
Простір для масштабування: Якщо ви розробник, який зосереджений на масштабуванні, MonadBFT надає вам більше простору до того, як ви зіштовхнетеся з вузьким місцем. На відміну від вторинних протоколів, ви можете легше збільшити розмір блоку або кількість валідаторів. А такі функції, як розподіл блоків з використанням кодування з стиранням, означають, що ви можете передавати великі обсяги даних по мережі, не перевантажуючи окремий вузол. Це робить можливим націлювання на вищу пропускну спроможність, відкриваючи простір для проектування більш амбітних децентралізованих додатків.
Для кінцевих користувачів: Звичайні користувачі не зрозуміють нічого з того, про що ми тут говоримо, але вони відчують його вплив. Завдяки MonadBFT як основі Monad Блоку, користувачі можуть очікувати всіх хороших рис без жертвування децентралізацією та опором цензурі.
Швидше підтвердження: Транзакції (наприклад, надсилання токенів, обмін активів, випуск NFT, виконання угод) будуть швидко підтверджені.
Зменшення несподіванок: Консистентність стану ланцюга вища, оскільки такі речі, як хвостовий форк, які по суті є переробкою, були усунуті.
Справедливість та прозорість: Поліпшення консенсусу непрямо означає, що робота блокчейну стає більш справедливою. Жоден окремий валідатор не може легко перевіряти транзакції або маніпулювати порядком між блоками.
Висновок
Підсумовуючи, MonadBFT на основі консолідації стилю HotStuff у конвеєрі запроваджує чотири ключові інновації:
Опір кінцевим форкам: MonadBFT є першим конвеєрним BFT протоколом, що усуває атаки кінцевих форків. Він досягає цього шляхом повторного подання останнього голосування за блок наступним лідером у випадку невдачі попереднього лідера або шляхом надання сертифікату без підтвердження (NEC), що свідчить про відсутність підтримки цього блоку. Це гарантує, що будь-який блок, який отримав абсолютну більшість підтримки, не буде відкинутий, що захищає винагороду чесних лідерів та запобігає зловмисним реорганізаціям і витягуванню MEV з міжблочних транзакцій.
Остаточність одноразової спекуляції: Валідатори можуть підтвердити блок після одноразового зв'язку (один лідер пропонує та голосує), надаючи клієнтам миттєву гарантію включення. Це спекулятивне підтвердження буде відновлено лише під час атаки рівності лідера (дії, які можуть бути доведені та покарані), що робить його в практиці безпечною гіпотезою.
Оптимістичний відгук: Протокол працює на швидкості мережі, без вроджених затримок. Лідер одразу просуває консенсус після отримання необхідних голосів, зміни в поданні відбуваються одразу після спостереження за закінченням кворуму, а не чекаючи фіксованого тайм-інтервалу. Такий дизайн оптимістичного відгуку мінімізує час очікування та максимізує пропускну здатність, при цьому залишається стійким до асинхронності та збоїв.
Лінійна комунікація: На щасливому шляху (тобто, коли лідер є чесним), складність повідомлень та верифікацій має лінійний зв'язок з кількістю верифікаторів. MonadBFT зберігає ефективну комунікаційну модель HotStuff, використовуючи агреговані підписи та просту трансляцію лідера до верифікаторів, що дозволяє протоколу масштабуватися до сотень верифікаторів без виникнення проблем з продуктивністю.