Ядро Блокчейн полягає в досягненні строгої глобальної консенсусу: іншими словами, незалежно від того, в якій країні чи в якому часовому поясі розташовані мережеві ноди, всі учасники в кінцевому підсумку повинні дійти згоди щодо набору об'єктивних результатів.
Але розподілена мережа в реальності не є ідеальною: є випадки, коли ноди втрачають з'єднання, ноди брешуть, а деякі навіть навмисно шкодять. У такому випадку, як система може "зберігати одностайність"?
Це проблема, яку має вирішити протокол консенсусу. Він по суті є набором правил, що керують групою незалежних, навіть не зовсім надійних нод, як досягти єдиного рішення щодо порядку та змісту кожної транзакції.
А як тільки цей "строгий консенсус" буде встановлено, блокчейн зможе розблокувати багато ключових особливостей, таких як захист цифрової власності, інфляційна стійка валютна модель та масштабована соціальна структура співпраці. Але при цьому консенсус-протокол повинен одночасно гарантувати два основні аспекти:
Не можуть бути підтверджені два конфліктуючі Блоки.
Мережа повинна постійно розвиватися, не може застрягати або зупинятися.
MonadBFT є останнім технологічним проривом у цьому напрямку.
Короткий огляд еволюції протоколу консенсусу
У цій галузі механізмів консенсусу насправді досліджувалися десятиліттями. Найперші протоколи, такі як PBFT (практична байєрська стійкість), вже можуть вирішувати одну дуже реальну ситуацію: навіть якщо в мережі є частина нод, які випадають з ланцюга, чинять зло, або базікають безглуздя, система все ще може досягти згоди, якщо їх не більше 1/3 від загальної кількості.
Ці ранні протоколи були спроектовані досить «традиційно»: кожного раунду обирається один лідер, який ініціює пропозицію, а інші верифікатори проводять кілька раундів голосування, поетапно підтверджуючи порядок транзакцій.
Увесь процес голосування зазвичай проходить кілька етапів, таких як pre-prepare, prepare, commit, reply. На кожному етапі всі валідатори повинні спілкуватися один з одним. Іншими словами, кожен повинен сказати кожному, обсяг повідомлень зростає експоненційно в "мережевій" формі.
Складність цієї комунікаційної структури дорівнює n² — тобто, якщо в мережі є 100 валідаторів, то за кожен раунд консенсусу може бути передано майже 10 тисяч повідомлень.
Це не є великою проблемою в малих мережах, але як тільки кількість валідаторів зросте, комунікаційне навантаження системи швидко стане нестерпним, а ефективність різко впаде.
Ця структура «кожен повинен спілкуватися з кожним» насправді є дуже неефективною. Наприклад, в мережі з 100 валідаторами кожен раунд консенсусу може потребувати обробки тисяч повідомлень.
Це ще можливо в невеликому колі, але якщо це буде на глобальному, відкритому мережевому ланцюгу, навантаження на комунікацію відразу стане неприпустимим. Тому такі ранні BFT протоколи, як PBFT і Tendermint, зазвичай використовуються лише в сценаріях з дозволом (permissioned network) або в системах з дуже малою кількістю валідаторів, щоб ледве працювати.
Для того, щоб протокол BFT міг адаптуватися до бездозвільного, публічного середовища, деякі нові покоління дизайнів почали переходити на більш легкі способи комунікації: дозволити кожному валідатору спілкуватися лише з лідером, а не з усіма.
Це зменшило складність повідомлень з n² до n — суттєво зменшивши навантаження на систему.
Протокол HotStuff був представлений у 2018 році саме для вирішення цієї проблеми масштабованості. Його дизайн має дуже чітку концепцію: замінити складний процес голосування PBFT на більш просту, керовану лідером комунікаційну структуру.
Головною характеристикою HotStuff є так звана лінійна комунікація (linear communication). У його механізмі кожен валідатор повинен надіслати своє голосування лише поточному лідеру, а лідер потім упаковує ці голосування, створюючи Quorum Certificate (QC, законне більшість підтвердження).
Цей QC в основному є колективним підписом, що доводить всій мережі: "Більшість нод погодилася з цією пропозицією."
У порівнянні, комунікаційна модель PBFT є "всезагальним мовленням", кожен говорить у групі, і ситуація стає дуже заплутаною. Модель HotStuff більше схожа на "одна людина збирає, один раз пакує", незалежно від кількості людей у мережі, вона все ще може підтримувати ефективну роботу.
Окрім лінійного зв'язку, HotStuff може бути додатково оновлений до версії з конвеєром (pipelined HotStuff), щоб підвищити ефективність.
У первісному HotStuff один і той же валідатор продовжує виконувати роль лідера протягом декількох раундів, поки блок не буде повністю підтверджено. Цей процес є "один раунд обробки одного блоку", вся увага зосереджена на просуванні поточного.
А в конвеєрі HotStuff механізм став ще більш гнучким: на кожному етапі обирається новий лідер, а завдання кожного лідера складається з двох частин:
Одна сторона упаковує голосування попереднього раунду в Quorum Certificate (QC) та транслює його по всій мережі;
Одна сторона пропонує новий Блок, готуючись до наступного раунду.
Тобто, більше не «підтверджуємо один і обробляємо наступний», а як на конвеєрі, різні лідери чергуються, відповідаючи за кожен етап. Попередній пропонує Блок, наступний підтверджує його і продовжує пропонувати нові блоки, консенсус у ланцюзі передається як естафета.
Це і є походження метафори "конвеєр": поточний Блок ще проходить процес підтвердження, наступний вже готується, багато етапів паралельно, що підвищує пропускну здатність.
Підсумовуючи, протоколи на кшталт HotStuff досягли значного покращення в двох вимірах у порівнянні з традиційним BFT:
По-перше, зв'язок став легшим, кожен валідатор спілкується лише з лідером;
По-друге, ефективність обробки є вищою, кілька процесів підтвердження блоків можуть виконуватись паралельно.
Це зробило HotStuff дизайном шаблону для багатьох сучасних PoS Блокчейн механізмів Консенсусу. Але як і в усьому, є плюси і мінуси — хоча конвеєрна структура має потужну продуктивність, вона також непомітно вводить структурний ризик, який важко виявити.
Далі ми повинні поглиблено обговорити це ключове питання: хвостове розгалуження (Tail Forking).
Проблема хвостового розгалуження (Tail-Forking)
Хоча HotStuff — особливо його конвеєрна версія — вирішує проблему масштабованості консенсусних протоколів, він також вводить деякі нові виклики. Найважливішою та найпростішою для ігнорування є так звана проблема «хвостового розгалуження» (Tail Forking).
Що таке хвостова розгалуження? Це можна просто зрозуміти як: Блокчейн зазнав несподіваного ребалансування блоку на "кінці ланцюга" (reorg).
Конкретно кажучи, є один Блок, який є дійсним, і вже успішно розповсюджений між більшістю валідаторів, і отримав достатню кількість голосів на підтримку, за логікою, він має бути підтверджений і записаний у головний ланцюг. Але врешті-решт, він був "пропущений", був відкинутий (orphaned), замість нього з'явився інший новий Блок на тій же висоті.
Це не баг і не атака, а через те, що в самій структурі дизайну протоколу існує можливість так званого «випадання з блокчейну». Це звучить трохи несправедливо, чи не так? Отже, як це відбувається?
Ми вже говорили, що кожен лідер у конвеєрі HotStuff має два завдання:
A. Запропонувати новий блок (наприклад, Bₙ₊₁)
B. Збирати голоси за блок попереднього лідера, генеруючи QC (наприклад, завершити остаточне підтвердження для Bₙ)
Ці два завдання виконуються паралельно, по черзі. Але проблема полягає саме в цьому.
Приклад: припустимо, що Аліса є лідером, вона на висоті n запропонувала блок Bₙ, цей блок отримав супербільшість голосів і вже "майже підтверджений". Наступним має стати Боб, який продовжить просувати наступний блок Bₙ₊₁, також він повинен упакувати QC (доказ законної більшості) для Bₙ у свою пропозицію, щоб завершити остаточне підтвердження Bₙ.
Але якщо Боб у цей час офлайн або навмисно не надає QC для Bₙ, то виникають проблеми.
Оскільки ніхто не завершив QC пакування блоку Alice, запис голосування Bₙ не зміг поширитися, цей блок, який мав бути підтвердженим, був "холодно оброблений" і в кінцевому підсумку був ігнорований усією мережею.
Це і є сутність хвостового розгалуження: блок попереднього лідера пропускається через недбалість або зловмисність наступного лідера.
Чому серйозно відбувається розгалуження в кінці?
Проблеми з відгалуженням в основному зосереджені на двох аспектах: 1) знищення механізму стимулювання, 2) загроза активності системи.
Спочатку відбувається ковтання винагороди: якщо блок відкинуто, лідер, який його запропонував, не отримає жодної винагороди. Будь то винагороди за блок або комісії за транзакції. Наприклад, Аліса запропонувала законний блок і отримала більшість голосів, але через помилки або зловмисні дії Боба блок не був підтверджений, і Аліса в підсумку не отримала ні копійки. Це призводить до неправильної структури стимулювання: шкідливі вузли, такі як Боб, можуть «упорядкувати» своє джерело винагороди, пропустивши блок опонента. Така поведінка не вимагає технічної атаки, а лише навмисного «неспівробітництва» для послаблення заробітку конкурента. Якщо такі речі повторюються, з часом це зменшить участь і справедливість всієї системи, і навіть спровокує змову між вузлами.
По-перше, простір для атак MEV розширюється: кінець часткового розподілу також призводить до ще більш прихованої, але серйозної проблеми: простір для зловмисного маніпулювання MEV (максимальною витягуваною вартістю) збільшується. Наприклад, припустимо, що в блоці Аліси є надзвичайно цінна арбітражна угода. Якщо Bob має намір щось зіпсувати, він може змовитися з наступним лідером Carol, навмисно не поширюючи блок Аліси. Потім Carol може на тому ж рівні відтворити новий блок, "вкрасти" цю арбітражну угоду Аліси — перетворивши прибуток MEV на свій власний. Така практика "перемикання голови ланцюга + змова про привласнення" на перший погляд все ще дотримується правил створення блоків, але насправді є ретельно спланованим грабунком. Ще гірше, це може спонукати лідерів встановлювати "змовницькі відносини", перетворюючи підтвердження блоків на гру розподілу вигод, а не на публічну службу.
По-перше, порушення гарантії остаточності впливає на досвід користувачів: порівняно з протоколами типу Nakamoto, великою перевагою BFT є детермінована остаточність: як тільки Блок був поданий, його неможливо відкликати. Але кінцеве розгалуження порушує цю гарантію, особливо щодо тих Блоків, які «отримали голоси, але ще не були офіційно підтверджені». Деякі високопродуктивні dapp зазвичай сподіваються на те, що можуть негайно зчитувати дані після того, як Блок пройшов голосування, щоб зменшити затримку, а якщо цей Блок раптово буде скинутий, це може призвести до відкату стану користувача — наприклад, аномалії в залишку рахунку, раптове зникнення недавно завершеної високоплечової угоди, раптове скидання стану гри тощо.
По-перше, це може викликати ланцюгову несправність: Як правило, хвостовий розгалуження може лише затримати підтвердження певного блоку на один раунд, вплив незначний. Але в деяких крайніх випадках, якщо кілька поспіль лідерів вирішать пропустити попередній блок, система може потрапити в затримку, і ніхто не захоче "прийняти" попередній блок. Просування всієї ланцюга таким чином зупиняється, поки нарешті не з'явиться "лідер, готовий взяти на себе відповідальність", мережа зможе продовжити рух.
Хоча раніше вже існували деякі рішення, такі як механізм уникнення кінцевих розгалужень, запропонований протоколом BeeGees, але зазвичай це потребує жертвування продуктивністю, наприклад, повторного введення складності вторинного зв'язку, що не виправдовує витрат.
Що таке MonadBFT?
MonadBFT - це нове покоління консенсусного протоколу, спеціально розроблене для вирішення проблеми остаточного розгалуження. Його потужність полягає в тому, що при вирішенні структурних загроз не жертвує перевагами продуктивності, які надає конвеєр HotStuff. Іншими словами, MonadBFT не є повною переробкою, а продовженням оптимізації на основі основної структури HotStuff. Він зберігає три ключові характеристики:
Ротація лідерів (rotating leader): кожен раунд обирається новий лідер для просування Блоку.
Покрокове відправлення (pipelined commits): кілька процесів підтвердження блоків можуть виконуватись паралельно;
Лінійна комунікація (linear messaging): кожен валідатор повинен спілкуватися лише з лідером, що заощаджує значну частину мережевих витрат.
Але лише цих трьох пунктів недостатньо для безпеки. Щоб закрити структурну уразливість, пов'язану з відгалуженнями, MonadBFT додала дві ключові механізми:
Механізм примусового повторного пропозиції (Re-Proposal)
У протоколі BFT час ділиться на раунди (називається view), у кожному раунді є один лідер, відповідальний за пропозицію нового блоку. Якщо лідер зазнає невдачі (наприклад, не встигає запропонувати блок або пропозиція недійсна), система переходить до наступного раунду і обирає нового лідера.
MonadBFT додала механізм, який забезпечує, що під час перемикання view жоден чесно запропонований Блок не буде "випадати" через ротацію лідерів.
Коли лідер поточного раунду виходить з ладу, валідатори надсилають підписане повідомлення про зміну раунду (view change), яке вказує на те, що поточний раунд вичерпав свій час.
Особливістю є те, що це повідомлення не лише означає «вичерпано час», але й повинно містити інформацію про блок, у якому останній раз голосував цей валідатор, що еквівалентно: «Я не отримав законну пропозицію, це останній блок, який я бачу зараз.»
Новий раунд лідерів збиратиме ці повідомлення про тайм-аут від валідаторів супербільшості (2f+1) і об'єднає їх у сертифікат тайм-ауту (TC). Цей ТК представляє: уніфікований когнітивний знімок «блоку головки ланцюга» по всій мережі, коли попередній раунд не вдався. Новий лідер вибирає блок з найбільшою висотою (або останнім номером виду), так званим високим_tip.
MonadBFT вимоги: пропозиція нового лідера повинна містити законний TC, і необхідно повторно запропонувати найвищий підвішений Блок з TC, щоб цей Блок знову отримав можливість бути підтвердженим.
Чому? Як ми вже згадували раніше: ми не хочемо, щоб блок, близький до підтвердження, просто зник.
Наприклад: припустимо, що Аліса є лідером ноди 5, запропонувала дійсний блок і отримала більшість голосів. Наступного, лідер ноди 6 Боб офлайн і не зміг просунути процес ланцюга. Коли Кароліна стане лідером ноди 7, відповідно до правил MonadBFT, вона повинна включити TC і знову запропонувати блок Аліси. Таким чином, чесна праця Аліси не буде марною.
Якщо у Керол немає блоку Аліси, вона може запитати його в інших нод. Ноди можуть:
Надати цей Блок, або
Повернути підписане "повідомлення без підтвердження" (No-Endorsement, NE), яке вказує на те, що у вас немає цього блоку (далі буде представлено його механізм). (Не більше f можливих байєрських нод можуть вибрати проігнорувати запит і не відповідати.)
Якщо Керол знову запропонує блок Аліси, вона отримає додаткову можливість для пропозиції, що забезпечить її захист від "колективного покарання" через невдачу попереднього лідера.
Ця механіка повторного пропонування має чітку мету: забезпечити справедливий прогрес Блокчейну, щоб будь-яка ефективна робота не була тихо відкинута через невдачу або чиїсь неправомірні дії.
Безпідставний сертифікат (NEC)
Продовжуючи попередній приклад: після того, як термін Bob вичерпався, Carol запитує інших валідаторів надати high_tip блок (тобто блок Alice). У цей момент щонайменше 2f+1 валідаторів дадуть відповідь:
Або надайте блок Alice
Або надіслати підписане NE повідомлення, яке підтверджує, що ви не отримали блок від Аліси.
Якщо Carol отримала Блок Alice, вона повинна запропонувати його знову відповідно до правил. Carol може пропустити цей Блок і запропонувати новий лише в тому випадку, якщо принаймні f+1 валідаторів підписали повідомлення NE.
Чому f+1? У системі BFT, що складається з 3f+1 валідаторів, може бути не більше f зловмисників. Якщо блок Аліси дійсно отримав супербільшість голосів, то щонайменше 2f+1 чесних нод отримали його.
Отже, якщо Керол стверджує, що «я не можу отримати Блок Аліси», то вона повинна надати f+1 підписів валідаторів, щоб довести, що ці люди не отримали. Це утворює сертифікат без підтримки (No-Endorsement Certificate, NEC).
NEC є лідером у «звільненні» від відповідальності: це перевірний доказ, який свідчить про те, що попередній блок ще не готовий до підтвердження, він не є злим наміром пропустити, а обґрунтовано «відмовляється».
Повторна пропозиція + Безпідставний сертифікат = Вирішення кінцевого розгалуження
MonadBFT впроваджує механізм повторного запропонування (Re-Proposal) та сертифікат без підтвердження (NEC, No-Endorsement Certificate), встановлюючи суворі та чіткі правила обробки заголовка блоку:
Або завершити остаточну відправку для блоку "близький до підтвердження"; або надати достатньо доказів, щоб підтвердити, що цей блок ще не відповідає умовам для підтвердження, інакше не дозволяється пропустити або замінити попередній блок.
Цей механізм забезпечує: жоден блок, який отримав законну більшість голосів, не буде відхилено через помилку лідера або навмисне уникнення. Структурний ризик від відгалуження в кінці систематично вирішується, протокол може накладати чіткі обмеження на неналежні дії зі стрибками.
Якщо якийсь лідер намагається без причини пропустити попередній блок, але не може надати підтвердження NEC, протокол миттєво виявить і відмовить у цій дії. Пропуск без криптографічних доказів буде вважатися незаконним і не отримає підтримки мережевого консенсусу.
З точки зору економічних стимулів, цей дизайн забезпечує чіткий захист для валідаторів:
Лише ті блоки, які були чесно запропоновані та отримали підтримку голосування, не будуть позбавлені винагороди через збої на наступних етапах;
Навіть у крайніх ситуаціях, наприклад, якщо певна нода навмисно пропускає свій раунд пропозицій, намагаючись допомогти іншим захопити MEV попереднього блоку, протокол також зобов'язує наступного лідера спочатку знову запропонувати оригінальний блок, щоб зловмисники не могли отримати економічну вигоду, пропускаючи процес.
Більш важливо, що MonadBFT не жертвує продуктивністю протоколу заради підвищення безпеки.
Раніше деякі дизайни для боротьби з кінцевими розгалуженнями (наприклад, протокол BeeGees) хоч і мають певну захисну здатність, але часто покладаються на високу складність комунікації (n²) або активують повторні комунікаційні процеси в кожному раунді, що на практиці значно збільшує навантаження на систему.
Стратегія дизайну MonadBFT є більш витонченою:
Тільки у випадку невдачі перегляду або наявності аномалій запускається додаткова комунікація (наприклад, повідомлення про тайм-аут, повторна пропозиція блоку). У більшості випадків, коли чесні лідери продовжують створювати блоки, протокол все ще підтримує легкий і ефективний режим роботи.
Ця динамічна рівновага між продуктивністю та безпекою є однією з основних переваг MonadBFT у порівнянні з попередніми протоколами.
Підсумок
Ця стаття оглядає основні механізми традиційного консенсусу PBFT, описує шлях розвитку протоколу HotStuff і детально пояснює, як MonadBFT вирішує проблему кінцевих розгалужень, що виникає в результаті конструкту HotStuff.
Кінцеве розгалуження може спотворити економічні стимули пропозицій блоків, а також становити потенційну загрозу для активності мережі. MonadBFT запроваджує механізм повторного внесення пропозицій та сертифікати без підтвердження (NEC), щоб забезпечити, що будь-який блок, запропонований чесними лідерами і отримавший законну більшість голосів, не буде відкинутий або пропущений.
У наступній статті ми продовжимо досліджувати ще дві основні характеристики MonadBFT:
Спекулятивна остаточність
Оптимістична чутливість
і подальший аналіз цих механізмів щодо їхньої фактичної значимості для валідаторів і розробників.
Продовження слідує.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
MonadBFT аналіз (частина перша): як вирішити проблему кінцевого форку
Ядро Блокчейн полягає в досягненні строгої глобальної консенсусу: іншими словами, незалежно від того, в якій країні чи в якому часовому поясі розташовані мережеві ноди, всі учасники в кінцевому підсумку повинні дійти згоди щодо набору об'єктивних результатів.
Але розподілена мережа в реальності не є ідеальною: є випадки, коли ноди втрачають з'єднання, ноди брешуть, а деякі навіть навмисно шкодять. У такому випадку, як система може "зберігати одностайність"?
Це проблема, яку має вирішити протокол консенсусу. Він по суті є набором правил, що керують групою незалежних, навіть не зовсім надійних нод, як досягти єдиного рішення щодо порядку та змісту кожної транзакції.
А як тільки цей "строгий консенсус" буде встановлено, блокчейн зможе розблокувати багато ключових особливостей, таких як захист цифрової власності, інфляційна стійка валютна модель та масштабована соціальна структура співпраці. Але при цьому консенсус-протокол повинен одночасно гарантувати два основні аспекти:
Не можуть бути підтверджені два конфліктуючі Блоки.
Мережа повинна постійно розвиватися, не може застрягати або зупинятися.
MonadBFT є останнім технологічним проривом у цьому напрямку.
Короткий огляд еволюції протоколу консенсусу
У цій галузі механізмів консенсусу насправді досліджувалися десятиліттями. Найперші протоколи, такі як PBFT (практична байєрська стійкість), вже можуть вирішувати одну дуже реальну ситуацію: навіть якщо в мережі є частина нод, які випадають з ланцюга, чинять зло, або базікають безглуздя, система все ще може досягти згоди, якщо їх не більше 1/3 від загальної кількості.
Ці ранні протоколи були спроектовані досить «традиційно»: кожного раунду обирається один лідер, який ініціює пропозицію, а інші верифікатори проводять кілька раундів голосування, поетапно підтверджуючи порядок транзакцій.
Увесь процес голосування зазвичай проходить кілька етапів, таких як pre-prepare, prepare, commit, reply. На кожному етапі всі валідатори повинні спілкуватися один з одним. Іншими словами, кожен повинен сказати кожному, обсяг повідомлень зростає експоненційно в "мережевій" формі.
Складність цієї комунікаційної структури дорівнює n² — тобто, якщо в мережі є 100 валідаторів, то за кожен раунд консенсусу може бути передано майже 10 тисяч повідомлень.
Це не є великою проблемою в малих мережах, але як тільки кількість валідаторів зросте, комунікаційне навантаження системи швидко стане нестерпним, а ефективність різко впаде.
Ця структура «кожен повинен спілкуватися з кожним» насправді є дуже неефективною. Наприклад, в мережі з 100 валідаторами кожен раунд консенсусу може потребувати обробки тисяч повідомлень.
Це ще можливо в невеликому колі, але якщо це буде на глобальному, відкритому мережевому ланцюгу, навантаження на комунікацію відразу стане неприпустимим. Тому такі ранні BFT протоколи, як PBFT і Tendermint, зазвичай використовуються лише в сценаріях з дозволом (permissioned network) або в системах з дуже малою кількістю валідаторів, щоб ледве працювати.
Для того, щоб протокол BFT міг адаптуватися до бездозвільного, публічного середовища, деякі нові покоління дизайнів почали переходити на більш легкі способи комунікації: дозволити кожному валідатору спілкуватися лише з лідером, а не з усіма.
Це зменшило складність повідомлень з n² до n — суттєво зменшивши навантаження на систему.
Протокол HotStuff був представлений у 2018 році саме для вирішення цієї проблеми масштабованості. Його дизайн має дуже чітку концепцію: замінити складний процес голосування PBFT на більш просту, керовану лідером комунікаційну структуру.
Головною характеристикою HotStuff є так звана лінійна комунікація (linear communication). У його механізмі кожен валідатор повинен надіслати своє голосування лише поточному лідеру, а лідер потім упаковує ці голосування, створюючи Quorum Certificate (QC, законне більшість підтвердження).
Цей QC в основному є колективним підписом, що доводить всій мережі: "Більшість нод погодилася з цією пропозицією."
У порівнянні, комунікаційна модель PBFT є "всезагальним мовленням", кожен говорить у групі, і ситуація стає дуже заплутаною. Модель HotStuff більше схожа на "одна людина збирає, один раз пакує", незалежно від кількості людей у мережі, вона все ще може підтримувати ефективну роботу.
Окрім лінійного зв'язку, HotStuff може бути додатково оновлений до версії з конвеєром (pipelined HotStuff), щоб підвищити ефективність.
У первісному HotStuff один і той же валідатор продовжує виконувати роль лідера протягом декількох раундів, поки блок не буде повністю підтверджено. Цей процес є "один раунд обробки одного блоку", вся увага зосереджена на просуванні поточного.
А в конвеєрі HotStuff механізм став ще більш гнучким: на кожному етапі обирається новий лідер, а завдання кожного лідера складається з двох частин:
Одна сторона упаковує голосування попереднього раунду в Quorum Certificate (QC) та транслює його по всій мережі;
Одна сторона пропонує новий Блок, готуючись до наступного раунду.
Тобто, більше не «підтверджуємо один і обробляємо наступний», а як на конвеєрі, різні лідери чергуються, відповідаючи за кожен етап. Попередній пропонує Блок, наступний підтверджує його і продовжує пропонувати нові блоки, консенсус у ланцюзі передається як естафета.
Це і є походження метафори "конвеєр": поточний Блок ще проходить процес підтвердження, наступний вже готується, багато етапів паралельно, що підвищує пропускну здатність.
Підсумовуючи, протоколи на кшталт HotStuff досягли значного покращення в двох вимірах у порівнянні з традиційним BFT:
По-перше, зв'язок став легшим, кожен валідатор спілкується лише з лідером;
По-друге, ефективність обробки є вищою, кілька процесів підтвердження блоків можуть виконуватись паралельно.
Це зробило HotStuff дизайном шаблону для багатьох сучасних PoS Блокчейн механізмів Консенсусу. Але як і в усьому, є плюси і мінуси — хоча конвеєрна структура має потужну продуктивність, вона також непомітно вводить структурний ризик, який важко виявити.
Далі ми повинні поглиблено обговорити це ключове питання: хвостове розгалуження (Tail Forking).
Проблема хвостового розгалуження (Tail-Forking)
Хоча HotStuff — особливо його конвеєрна версія — вирішує проблему масштабованості консенсусних протоколів, він також вводить деякі нові виклики. Найважливішою та найпростішою для ігнорування є так звана проблема «хвостового розгалуження» (Tail Forking).
Що таке хвостова розгалуження? Це можна просто зрозуміти як: Блокчейн зазнав несподіваного ребалансування блоку на "кінці ланцюга" (reorg).
Конкретно кажучи, є один Блок, який є дійсним, і вже успішно розповсюджений між більшістю валідаторів, і отримав достатню кількість голосів на підтримку, за логікою, він має бути підтверджений і записаний у головний ланцюг. Але врешті-решт, він був "пропущений", був відкинутий (orphaned), замість нього з'явився інший новий Блок на тій же висоті.
Це не баг і не атака, а через те, що в самій структурі дизайну протоколу існує можливість так званого «випадання з блокчейну». Це звучить трохи несправедливо, чи не так? Отже, як це відбувається?
Ми вже говорили, що кожен лідер у конвеєрі HotStuff має два завдання:
A. Запропонувати новий блок (наприклад, Bₙ₊₁)
B. Збирати голоси за блок попереднього лідера, генеруючи QC (наприклад, завершити остаточне підтвердження для Bₙ)
Ці два завдання виконуються паралельно, по черзі. Але проблема полягає саме в цьому.
Приклад: припустимо, що Аліса є лідером, вона на висоті n запропонувала блок Bₙ, цей блок отримав супербільшість голосів і вже "майже підтверджений". Наступним має стати Боб, який продовжить просувати наступний блок Bₙ₊₁, також він повинен упакувати QC (доказ законної більшості) для Bₙ у свою пропозицію, щоб завершити остаточне підтвердження Bₙ.
Але якщо Боб у цей час офлайн або навмисно не надає QC для Bₙ, то виникають проблеми.
Оскільки ніхто не завершив QC пакування блоку Alice, запис голосування Bₙ не зміг поширитися, цей блок, який мав бути підтвердженим, був "холодно оброблений" і в кінцевому підсумку був ігнорований усією мережею.
Це і є сутність хвостового розгалуження: блок попереднього лідера пропускається через недбалість або зловмисність наступного лідера.
Чому серйозно відбувається розгалуження в кінці?
Проблеми з відгалуженням в основному зосереджені на двох аспектах: 1) знищення механізму стимулювання, 2) загроза активності системи.
Спочатку відбувається ковтання винагороди: якщо блок відкинуто, лідер, який його запропонував, не отримає жодної винагороди. Будь то винагороди за блок або комісії за транзакції. Наприклад, Аліса запропонувала законний блок і отримала більшість голосів, але через помилки або зловмисні дії Боба блок не був підтверджений, і Аліса в підсумку не отримала ні копійки. Це призводить до неправильної структури стимулювання: шкідливі вузли, такі як Боб, можуть «упорядкувати» своє джерело винагороди, пропустивши блок опонента. Така поведінка не вимагає технічної атаки, а лише навмисного «неспівробітництва» для послаблення заробітку конкурента. Якщо такі речі повторюються, з часом це зменшить участь і справедливість всієї системи, і навіть спровокує змову між вузлами.
По-перше, простір для атак MEV розширюється: кінець часткового розподілу також призводить до ще більш прихованої, але серйозної проблеми: простір для зловмисного маніпулювання MEV (максимальною витягуваною вартістю) збільшується. Наприклад, припустимо, що в блоці Аліси є надзвичайно цінна арбітражна угода. Якщо Bob має намір щось зіпсувати, він може змовитися з наступним лідером Carol, навмисно не поширюючи блок Аліси. Потім Carol може на тому ж рівні відтворити новий блок, "вкрасти" цю арбітражну угоду Аліси — перетворивши прибуток MEV на свій власний. Така практика "перемикання голови ланцюга + змова про привласнення" на перший погляд все ще дотримується правил створення блоків, але насправді є ретельно спланованим грабунком. Ще гірше, це може спонукати лідерів встановлювати "змовницькі відносини", перетворюючи підтвердження блоків на гру розподілу вигод, а не на публічну службу.
По-перше, порушення гарантії остаточності впливає на досвід користувачів: порівняно з протоколами типу Nakamoto, великою перевагою BFT є детермінована остаточність: як тільки Блок був поданий, його неможливо відкликати. Але кінцеве розгалуження порушує цю гарантію, особливо щодо тих Блоків, які «отримали голоси, але ще не були офіційно підтверджені». Деякі високопродуктивні dapp зазвичай сподіваються на те, що можуть негайно зчитувати дані після того, як Блок пройшов голосування, щоб зменшити затримку, а якщо цей Блок раптово буде скинутий, це може призвести до відкату стану користувача — наприклад, аномалії в залишку рахунку, раптове зникнення недавно завершеної високоплечової угоди, раптове скидання стану гри тощо.
По-перше, це може викликати ланцюгову несправність: Як правило, хвостовий розгалуження може лише затримати підтвердження певного блоку на один раунд, вплив незначний. Але в деяких крайніх випадках, якщо кілька поспіль лідерів вирішать пропустити попередній блок, система може потрапити в затримку, і ніхто не захоче "прийняти" попередній блок. Просування всієї ланцюга таким чином зупиняється, поки нарешті не з'явиться "лідер, готовий взяти на себе відповідальність", мережа зможе продовжити рух.
Хоча раніше вже існували деякі рішення, такі як механізм уникнення кінцевих розгалужень, запропонований протоколом BeeGees, але зазвичай це потребує жертвування продуктивністю, наприклад, повторного введення складності вторинного зв'язку, що не виправдовує витрат.
Що таке MonadBFT?
MonadBFT - це нове покоління консенсусного протоколу, спеціально розроблене для вирішення проблеми остаточного розгалуження. Його потужність полягає в тому, що при вирішенні структурних загроз не жертвує перевагами продуктивності, які надає конвеєр HotStuff. Іншими словами, MonadBFT не є повною переробкою, а продовженням оптимізації на основі основної структури HotStuff. Він зберігає три ключові характеристики:
Ротація лідерів (rotating leader): кожен раунд обирається новий лідер для просування Блоку.
Покрокове відправлення (pipelined commits): кілька процесів підтвердження блоків можуть виконуватись паралельно;
Лінійна комунікація (linear messaging): кожен валідатор повинен спілкуватися лише з лідером, що заощаджує значну частину мережевих витрат.
Але лише цих трьох пунктів недостатньо для безпеки. Щоб закрити структурну уразливість, пов'язану з відгалуженнями, MonadBFT додала дві ключові механізми:
Механізм примусового повторного пропозиції (Re-Proposal)
Безпідставний сертифікат (NEC, No-Endorsement Certificate)
Механізм повторного пропозиції (Re-Proposal)
У протоколі BFT час ділиться на раунди (називається view), у кожному раунді є один лідер, відповідальний за пропозицію нового блоку. Якщо лідер зазнає невдачі (наприклад, не встигає запропонувати блок або пропозиція недійсна), система переходить до наступного раунду і обирає нового лідера.
MonadBFT додала механізм, який забезпечує, що під час перемикання view жоден чесно запропонований Блок не буде "випадати" через ротацію лідерів.
Коли лідер поточного раунду виходить з ладу, валідатори надсилають підписане повідомлення про зміну раунду (view change), яке вказує на те, що поточний раунд вичерпав свій час.
Особливістю є те, що це повідомлення не лише означає «вичерпано час», але й повинно містити інформацію про блок, у якому останній раз голосував цей валідатор, що еквівалентно: «Я не отримав законну пропозицію, це останній блок, який я бачу зараз.»
Новий раунд лідерів збиратиме ці повідомлення про тайм-аут від валідаторів супербільшості (2f+1) і об'єднає їх у сертифікат тайм-ауту (TC). Цей ТК представляє: уніфікований когнітивний знімок «блоку головки ланцюга» по всій мережі, коли попередній раунд не вдався. Новий лідер вибирає блок з найбільшою висотою (або останнім номером виду), так званим високим_tip.
MonadBFT вимоги: пропозиція нового лідера повинна містити законний TC, і необхідно повторно запропонувати найвищий підвішений Блок з TC, щоб цей Блок знову отримав можливість бути підтвердженим.
Чому? Як ми вже згадували раніше: ми не хочемо, щоб блок, близький до підтвердження, просто зник.
Наприклад: припустимо, що Аліса є лідером ноди 5, запропонувала дійсний блок і отримала більшість голосів. Наступного, лідер ноди 6 Боб офлайн і не зміг просунути процес ланцюга. Коли Кароліна стане лідером ноди 7, відповідно до правил MonadBFT, вона повинна включити TC і знову запропонувати блок Аліси. Таким чином, чесна праця Аліси не буде марною.
Якщо у Керол немає блоку Аліси, вона може запитати його в інших нод. Ноди можуть:
Надати цей Блок, або
Повернути підписане "повідомлення без підтвердження" (No-Endorsement, NE), яке вказує на те, що у вас немає цього блоку (далі буде представлено його механізм). (Не більше f можливих байєрських нод можуть вибрати проігнорувати запит і не відповідати.)
Якщо Керол знову запропонує блок Аліси, вона отримає додаткову можливість для пропозиції, що забезпечить її захист від "колективного покарання" через невдачу попереднього лідера.
Ця механіка повторного пропонування має чітку мету: забезпечити справедливий прогрес Блокчейну, щоб будь-яка ефективна робота не була тихо відкинута через невдачу або чиїсь неправомірні дії.
Безпідставний сертифікат (NEC)
Продовжуючи попередній приклад: після того, як термін Bob вичерпався, Carol запитує інших валідаторів надати high_tip блок (тобто блок Alice). У цей момент щонайменше 2f+1 валідаторів дадуть відповідь:
Або надайте блок Alice
Або надіслати підписане NE повідомлення, яке підтверджує, що ви не отримали блок від Аліси.
Якщо Carol отримала Блок Alice, вона повинна запропонувати його знову відповідно до правил. Carol може пропустити цей Блок і запропонувати новий лише в тому випадку, якщо принаймні f+1 валідаторів підписали повідомлення NE.
Чому f+1? У системі BFT, що складається з 3f+1 валідаторів, може бути не більше f зловмисників. Якщо блок Аліси дійсно отримав супербільшість голосів, то щонайменше 2f+1 чесних нод отримали його.
Отже, якщо Керол стверджує, що «я не можу отримати Блок Аліси», то вона повинна надати f+1 підписів валідаторів, щоб довести, що ці люди не отримали. Це утворює сертифікат без підтримки (No-Endorsement Certificate, NEC).
NEC є лідером у «звільненні» від відповідальності: це перевірний доказ, який свідчить про те, що попередній блок ще не готовий до підтвердження, він не є злим наміром пропустити, а обґрунтовано «відмовляється».
Повторна пропозиція + Безпідставний сертифікат = Вирішення кінцевого розгалуження
MonadBFT впроваджує механізм повторного запропонування (Re-Proposal) та сертифікат без підтвердження (NEC, No-Endorsement Certificate), встановлюючи суворі та чіткі правила обробки заголовка блоку:
Або завершити остаточну відправку для блоку "близький до підтвердження"; або надати достатньо доказів, щоб підтвердити, що цей блок ще не відповідає умовам для підтвердження, інакше не дозволяється пропустити або замінити попередній блок.
Цей механізм забезпечує: жоден блок, який отримав законну більшість голосів, не буде відхилено через помилку лідера або навмисне уникнення. Структурний ризик від відгалуження в кінці систематично вирішується, протокол може накладати чіткі обмеження на неналежні дії зі стрибками.
Якщо якийсь лідер намагається без причини пропустити попередній блок, але не може надати підтвердження NEC, протокол миттєво виявить і відмовить у цій дії. Пропуск без криптографічних доказів буде вважатися незаконним і не отримає підтримки мережевого консенсусу.
З точки зору економічних стимулів, цей дизайн забезпечує чіткий захист для валідаторів:
Лише ті блоки, які були чесно запропоновані та отримали підтримку голосування, не будуть позбавлені винагороди через збої на наступних етапах;
Навіть у крайніх ситуаціях, наприклад, якщо певна нода навмисно пропускає свій раунд пропозицій, намагаючись допомогти іншим захопити MEV попереднього блоку, протокол також зобов'язує наступного лідера спочатку знову запропонувати оригінальний блок, щоб зловмисники не могли отримати економічну вигоду, пропускаючи процес.
Більш важливо, що MonadBFT не жертвує продуктивністю протоколу заради підвищення безпеки.
Раніше деякі дизайни для боротьби з кінцевими розгалуженнями (наприклад, протокол BeeGees) хоч і мають певну захисну здатність, але часто покладаються на високу складність комунікації (n²) або активують повторні комунікаційні процеси в кожному раунді, що на практиці значно збільшує навантаження на систему.
Стратегія дизайну MonadBFT є більш витонченою:
Тільки у випадку невдачі перегляду або наявності аномалій запускається додаткова комунікація (наприклад, повідомлення про тайм-аут, повторна пропозиція блоку). У більшості випадків, коли чесні лідери продовжують створювати блоки, протокол все ще підтримує легкий і ефективний режим роботи.
Ця динамічна рівновага між продуктивністю та безпекою є однією з основних переваг MonadBFT у порівнянні з попередніми протоколами.
Підсумок
Ця стаття оглядає основні механізми традиційного консенсусу PBFT, описує шлях розвитку протоколу HotStuff і детально пояснює, як MonadBFT вирішує проблему кінцевих розгалужень, що виникає в результаті конструкту HotStuff.
Кінцеве розгалуження може спотворити економічні стимули пропозицій блоків, а також становити потенційну загрозу для активності мережі. MonadBFT запроваджує механізм повторного внесення пропозицій та сертифікати без підтвердження (NEC), щоб забезпечити, що будь-який блок, запропонований чесними лідерами і отримавший законну більшість голосів, не буде відкинутий або пропущений.
У наступній статті ми продовжимо досліджувати ще дві основні характеристики MonadBFT:
Спекулятивна остаточність
Оптимістична чутливість
і подальший аналіз цих механізмів щодо їхньої фактичної значимості для валідаторів і розробників.
Продовження слідує.