Ядро блокчейну полягає в реалізації суворого глобального консенсусу: іншими словами, незалежно від того, в якій країні чи часовій зоні розташовані мережеві вузли, всі учасники в кінцевому підсумку повинні дійти згоди щодо набору об'єктивних результатів.
Але розподілені мережі в реальному житті не є ідеальними: є вузли, які виходять з ладу, є вузли, які брешуть, а є й ті, хто навмисно шкодить. У такій ситуації, як система може "говорити в один голос" і зберігати узгодженість?
Це проблема, яку має вирішити консенсусний протокол. Він по суті є набором правил, які надають вказівки групі незалежних, навіть не зовсім надійних вузлів, як досягти одностайного рішення щодо порядку та змісту кожної транзакції.
А як тільки цей "суворий консенсус" буде встановлено, блокчейн зможе розблокувати багато ключових характеристик, таких як захист цифрової власності, інфляційна модель валюти та масштабована соціальна структура співпраці. Але передумовою є те, що сам консенсусний протокол повинен одночасно гарантувати два основні аспекти:
Не можуть бути підтверджені два конфліктуючі блоки.
Мережа повинна постійно просуватися, не може застрягти або зупинитися.
MonadBFT є останнім технологічним проривом у цьому напрямку.
Короткий огляд еволюції консенсусного протоколу
У цій області механізмів консенсусу насправді досліджували вже десятки років. Найперші протоколи, такі як PBFT (практична байєсова стійкість), вже можуть справлятися з дуже реалістичною ситуацією: навіть якщо частина вузлів у мережі виходить з ладу, чинить зло або говорить нісенітницю, поки їх не більше 1/3 від загальної кількості, система все ще може досягати консенсусу.
Ці ранні протоколи спроектовані більш "традиційно": кожен раунд обирається один лідер, який ініціює пропозицію, а інші валідатори проводять багато раундів голосування, крок за кроком підтверджуючи порядок транзакцій.
Процес голосування зазвичай проходить кілька етапів, таких як попередня підготовка, підготовка, зобов'язання та відповідь. На кожному етапі всі валідатори спілкуються між собою. Іншими словами, всі повинні всім розповідати, а обсяг повідомлень вибухово зростає в «мережі».
Складність цієї комунікаційної структури дорівнює n², тобто, якщо в мережі 100 валідаторів, кожен раунд консенсусу може передати майже 10 000 повідомлень.
Це не є великою проблемою в невеликих мережах, але як тільки кількість валідаторів зросте, навантаження на зв'язок системи швидко стане нестерпним, а ефективність різко знизиться.
Джерело інформації:
Структура «кожен повинен спілкуватися з кожним» у другорядній комунікації насправді є дуже неефективною. Наприклад, у мережі з 100 валідаторами кожен раунд консенсусу може обробляти тисячі повідомлень.
Це можна зробити по вузькому колу, але в глобальній, відкритій ончейн-мережі навантаження на зв'язок відразу стає неприйнятною. Як наслідок, ранні протоколи BFT, такі як PBFT і Tendermint, зазвичай використовуються лише в дозволених мережах або системах з невеликою кількістю валідаторів.
Для того, щоб адаптувати протокол BFT до інклюзивного середовища публічного ланцюга, деякі дизайни наступного покоління почали рухатися до більш легкого способу комунікації: кожен валідатор спілкується лише з лідером, а не з усіма членами команди.
Це зменшило складність повідомлень з n² до n — значно полегшивши навантаження на систему.
Протокол HotStuff був представлений у 2018 році для вирішення цієї проблеми масштабованості. Він був розроблений з чіткою ідеєю: замінити складний процес голосування PBFT простішою, керованою лідерами комунікаційною структурою.
Ключовою особливістю HotStuff є так званий лінійний зв'язок. У його механізмі кожному валідатору потрібно лише надіслати свої голоси поточному лідеру, який потім упаковує ці голоси для створення сертифіката кворуму (QC).
Цей QC в основному є колективним підписом, що доводить всій мережі: "Більшість вузлів погодилася з цією пропозицією."
На відміну від цього, комунікаційна модель PBFT є "всеобхідним мовленням", де всі спілкуються в групі, що призводить до великого безладу. Модель HotStuff більше нагадує "одна особа збирає, один раз пакує", незалежно від кількості людей у мережі, вона все ще може підтримувати ефективну роботу.
На малюнку порівнюється розгалужена комунікаційна структура HotStuff із повнозв'язною моделлю PBFT.
Джерело інформації:
На додаток до лінійного зв'язку, HotStuff може бути додатково оновлений до конвеєрної версії (pipelineed HotStuff) для підвищення ефективності.
В оригінальному HotStuff один і той же валідатор служив лідером протягом декількох раундів поспіль, поки блок не був повністю підтверджений. Процес відбувається «один блок за раз», і всі зусилля зосереджені на просуванні поточного.
А в конвеєрі HotStuff механізм став ще гнучкішим: в кожному раунді обирається новий лідер, а завдання кожного лідера складається з двох частин:
Одна сторона упаковує голосування попереднього раунду в Quorum Certificate (QC) та транслює його всій мережі;
Пропонуючи новий блок, готуючись до наступного раунду.
Тобто, більше не буде "підтверджувати один блок, а потім обробляти наступний", а скоріше, як на виробничій лінії, різні лідери по черзі відповідатимуть за кожен етап. Попередній пропонує блок, наступний підтверджує його і продовжує пропонувати нові блоки, консенсус в мережі передається як естафета.
Ось звідки походить метафора "конвеєр": поточний блок все ще проходить процес підтвердження, наступний вже готується, багато етапів паралельно, що підвищує пропускну здатність.
Підсумовуючи, протоколи на кшталт HotStuff зробили суттєві покращення в двох вимірах в порівнянні з традиційними BFT:
По-перше, зв'язок став легшим, кожен валідатор повинен спілкуватися лише з лідером;
По-друге, ефективність обробки вища, кілька процесів підтвердження блоків можуть виконуватись паралельно.
Це зробило HotStuff дизайном шаблону для багатьох сучасних механізмів консенсусу PoS блокчейнів. Але в кожній справі є свої плюси і мінуси — хоча конвеєрна структура має потужну продуктивність, вона також тихо вводить структурний ризик, який важко виявити.
Далі ми будемо детально обговорювати це ключове питання: хвостове розгалуження (Tail Forking).
Проблема розгалуження хвоста (Tail-Forking)
Хоча HotStuff — особливо його версія з конвеєром — вирішує проблему масштабованості консенсусного протоколу, він також вводить деякі нові виклики. Найважливішою та найчастіше ігнорованою є проблема так званих «хвостових розгалужень» (Tail Forking).
Що таке кінцеве розгалуження? Можна просто зрозуміти як: на "кінці ланцюга" в блокчейні сталася несподівана переробка блоку (reorg).
Зокрема, є блок, який є дійсним, успішно поширився на більшість валідаторів і отримав достатню кількість голосів, щоб його ось-ось підтвердити та записати в основний ланцюжок. Але врешті-решт його «пропустили», осиротіли і замінили новим блоком на тій же висоті.
Це не помилка і не атака, а пов'язано з тим, що в структурі самого протоколу існує можливість "випадіння з ланцюга". Чи не звучить це трохи несправедливо? Тож як це взагалі сталося?
Ми вже говорили, що кожен лідер у лінії HotStuff має дві задачі:
A. Запропонувати новий блок (наприклад, Bₙ₊₁)
B. Збирати голоси за блок попереднього лідера, генеруючи QC (наприклад, завершуючи остаточне підтвердження для Bₙ)
Ці два завдання виконуються паралельно, по черзі. Але проблема в цьому.
Наприклад: припустимо, що Аліса є лідером, вона на висоті n представила блок Bₙ, цей блок отримав супербільшість голосів і вже "майже підтверджено".
Далі лідером має стати Боб, щоб продовжити просування наступного блоку ланцюга Bₙ₊₁, при цьому йому також слід упакувати QC (доказ законної більшості) блоку Bₙ у свою пропозицію, щоб завершити остаточне підтвердження Bₙ.
Але якщо Боб у цей час офлайн або навмисно не подає QC Bₙ, то виникнуть проблеми.
Оскільки ніхто не завершив QC-пакет для блоку Alice, голосування Bₙ не змогло поширитися, і цей блок, який повинен був бути підтверджений, просто залишився "в холодному зберіганні" і в кінцевому підсумку був проігнорований усією мережею.
Це суть кінцевого розгалуження: блок попереднього лідера пропускається через невиконання обов'язків або умисел наступного лідера.
Чому хвостова розвилка серйозна?
Проблема розгалуження в кінці зосереджена на двох аспектах: 1) порушення механізму стимулювання, 2) загроза активності системи.
По-перше, винагорода була поглинута:
Якщо блок відкидається, лідер, який його запропонував, не отримує винагороди. Будь то винагорода за блок або комісія за транзакції. Наприклад, Аліса запропонувала легітимний блок і отримала переважну більшість голосів, але через помилки або зловмисні дії Боба блок не був підтверджений, і Аліса в підсумку не отримала ні копійки. Це призводить до неправильної структури стимулювання: шкідливі вузли, такі як Боб, можуть «впорядкувати» своє джерело винагороди, пропустивши блок опонента. Така поведінка не вимагає технічної атаки, лише навмисного «неспівпраця» для послаблення заробітку конкурента. Якщо подібні речі повторюватимуться повторювано, з часом це зменшить участь і справедливість усієї системи і навіть спровокує змову між вузлами.
По-друге, розширення простору атак MEV:
Хвостові вилки також створюють більш підступну, але серйозну проблему: з'являється більше простору для зловмисного маніпулювання MEV (максимальною видобувною цінністю). Ось приклад: Припустимо, Аліса має цінну арбітражну угоду у своєму блоці. Якщо Боб хоче наробити неприємностей, він може вступити в змову з наступним лідером, Керол, і навмисно не поширювати блок Аліси. Потім Керол реконструює новий блок на тій самій висоті, «крадучи» оригінальну арбітражну угоду Аліси, змушуючи MEV отримати свій власний. Ця практика «перестановка головки ланцюга + змова та привласнення» все ще є блоком за правилами на поверхні, але насправді це добре сплановане грабунок. Ще гірше те, що це провокує «змову» між лідерами, перетворюючи підтвердження блоків на гру з розподілом вигод, а не на державну послугу.
По-третє, порушення фінальної гарантії вплине на досвід користувачів:
У порівнянні з протоколами типу Nakamoto, однією з основних переваг BFT є детерміноване завершення: як тільки блок був поданий, його не можна скасувати. Але кінцеве розгалуження порушує цю гарантію, особливо в тих випадках, коли блоки "отримали голоси, але ще не були офіційно підтверджені". Деякі dapp з високою пропускною здатністю зазвичай хочуть мати можливість негайно зчитувати дані після підтвердження голосування по блоку, щоб зменшити затримки, а якщо цей блок буде раптово скасовано, це може призвести до відкату стану користувача - наприклад, аномалії в балансі облікового запису, раптова зникнення щойно завершеної високоплечої угоди, раптове скидання стану гри тощо.
По-четверте, може викликати каскадні збої:
Загалом, розгалуження в кінці може лише на деякий час затримати підтвердження блоку, і вплив незначний. Але в деяких крайніх ситуаціях, якщо кілька лідерів підряд вирішать пропустити попередній блок, система може потрапити в стан стагнації, і ніхто не захоче "взяти на себе" попередній блок. Прогрес всього ланцюга зупиниться, поки не з'явиться "лідер, готовий взяти на себе відповідальність", і мережа зможе продовжити рух.
Хоча раніше були деякі рішення, такі як механізм уникнення відгалужень, запропонований протоколом BeeGees, вони часто потребують жертвування продуктивністю, наприклад, повторного введення складності вторинного зв'язку, що не виправдовує витрат.
Що таке MonadBFT?
MonadBFT - це нове покоління консенсусного протоколу, спеціально розроблене для вирішення проблеми кінцевих розгалужень. Його перевага полягає в тому, що воно вирішує структурні ризики, не жертвуючи перевагами продуктивності, які надає конвеєр HotStuff. Іншими словами, MonadBFT не є повним перезавантаженням, а продовжує оптимізацію на основі основної структури HotStuff. Воно зберігає три ключові характеристики:
1）Ротація лідерів (rotating leader): кожного раунду обирається новий лідер для просування ланцюга;
Пайплайнові коміти (pipelined commits): кілька процесів підтвердження блоків можуть перехрещуватися.
Лінійний обмін повідомленнями (linear messaging): кожен валідатор повинен спілкуватися лише з лідером, що дозволяє зекономити значну кількість мережевих витрат.
Але лише цих трьох пунктів недостатньо для забезпечення безпеки. Щоб закрити структурну уразливість, пов'язану з відгалуженнями, MonadBFT додала дві ключові механізми:
Механізм примусового повторного запропонування (Re-Proposal)
У BFT-протоколі час ділиться на раунди (називаються view), в кожному раунді є лідер, відповідальний за пропозицію нового блоку. Якщо лідер зазнає невдачі (наприклад, не встигає запропонувати блок або пропозиція недійсна), система переходить до наступного раунду і обирає нового лідера.
MonadBFT додала механізм, який забезпечує, що під час зміни виду жоден чесно запропонований блок не буде «втрачений» через зміну лідера.
Коли лідер поточної раунду втрачає життєздатність, валідатори надсилають підписане повідомлення про зміну раунду (view change), що вказує на те, що поточний раунд вийшов за межі часу.
Особливість полягає в тому, що це повідомлення не лише вказує на те, що "вийшов термін", але також повинно містити інформацію про блок, за який останній раз голосував цей валідатор, що рівнозначно тому, щоб сказати: "Я не отримав дійсну пропозицію, ось останній блок, який я бачу."
Нова хвиля лідерів збирає ці повідомлення про таймаут від супербільшості (2f+1) валідаторів і об'єднує їх в сертифікат таймауту (Timeout Certificate, TC). Цей TC представляє: коли попередній раунд зазнав невдачі, вся мережа має єдине усвідомлення «головного блоку ланцюга». Новий лідер вибирає з цього найвищий блок (або останній номер перегляду), так званий high_tip.
MonadBFT вимоги: пропозиція нового лідера повинна містити законний TC, а також повинна повторно запропонувати найбільший завислий блок у TC, щоб цей блок знову отримав шанс на підтвердження.
Чому? Як ми згадували раніше: ми не хочемо, щоб блок, який наближається до підтвердження, просто зник.
Наприклад: припустимо, що Аліса є лідером вью 5, представила дійсний блок і отримала більшість голосів. Далі лідер вью 6 Боб оффлайн, не зміг просунути процес ланцюга. Коли Кароліна стає лідером вью 7, за правилами MonadBFT їй потрібно включити TC і знову запропонувати блок Аліси. Таким чином, чесна праця Аліси не буде марною.
Якщо Карол не має блоку Аліси, вона може запросити його у інших вузлів. Вузли можуть:
надати цю ділянку, або
Повернути підписане "повідомлення без підтвердження" (No-Endorsement, NE), що вказує на те, що у вас немає цього блоку (далі буде представлено його механізм). (Максимум f візантійських вузлів можуть вирішити проігнорувати запит і не відповідати.)
Якщо Керол повторно запропонує блок Аліси, вона отримає додаткову можливість для пропозиції, щоб переконатися, що її не «покарають» через невдачу попереднього лідера.
Функція цього механізму повторної пропозиції є чіткою: забезпечити справедливий прогрес ланцюга, щоб жодна ефективна робота не була тихо відкинута через нещасливу випадковість або через втручання когось.
Безгарантійне свідоцтво (NEC)
Продовжуючи попередній приклад: після того, як тайм-аут раунду Боба настав, Карол запитує інших валідаторів надати блок high_tip (тобто блок Аліси). У цей момент принаймні 2f+1 валідаторів дадуть відповідь:
або надайте блок Аліси
Надішліть підписане NE повідомлення, що свідчить про те, що ви не отримали блок Аліси.
Якщо Карол отримала блок від Аліси, вона повинна повторно запропонувати його відповідно до правил. Лише у випадку, якщо принаймні 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: переосмислення безпеки консенсусу Блокчейн, прощавай, ризику хвостового форку
Автор: michaellwy
Ядро блокчейну полягає в реалізації суворого глобального консенсусу: іншими словами, незалежно від того, в якій країні чи часовій зоні розташовані мережеві вузли, всі учасники в кінцевому підсумку повинні дійти згоди щодо набору об'єктивних результатів.
Але розподілені мережі в реальному житті не є ідеальними: є вузли, які виходять з ладу, є вузли, які брешуть, а є й ті, хто навмисно шкодить. У такій ситуації, як система може "говорити в один голос" і зберігати узгодженість?
Це проблема, яку має вирішити консенсусний протокол. Він по суті є набором правил, які надають вказівки групі незалежних, навіть не зовсім надійних вузлів, як досягти одностайного рішення щодо порядку та змісту кожної транзакції.
А як тільки цей "суворий консенсус" буде встановлено, блокчейн зможе розблокувати багато ключових характеристик, таких як захист цифрової власності, інфляційна модель валюти та масштабована соціальна структура співпраці. Але передумовою є те, що сам консенсусний протокол повинен одночасно гарантувати два основні аспекти:
Не можуть бути підтверджені два конфліктуючі блоки.
Мережа повинна постійно просуватися, не може застрягти або зупинитися.
MonadBFT є останнім технологічним проривом у цьому напрямку.
Короткий огляд еволюції консенсусного протоколу
У цій області механізмів консенсусу насправді досліджували вже десятки років. Найперші протоколи, такі як PBFT (практична байєсова стійкість), вже можуть справлятися з дуже реалістичною ситуацією: навіть якщо частина вузлів у мережі виходить з ладу, чинить зло або говорить нісенітницю, поки їх не більше 1/3 від загальної кількості, система все ще може досягати консенсусу.
Ці ранні протоколи спроектовані більш "традиційно": кожен раунд обирається один лідер, який ініціює пропозицію, а інші валідатори проводять багато раундів голосування, крок за кроком підтверджуючи порядок транзакцій.
Процес голосування зазвичай проходить кілька етапів, таких як попередня підготовка, підготовка, зобов'язання та відповідь. На кожному етапі всі валідатори спілкуються між собою. Іншими словами, всі повинні всім розповідати, а обсяг повідомлень вибухово зростає в «мережі».
Складність цієї комунікаційної структури дорівнює n², тобто, якщо в мережі 100 валідаторів, кожен раунд консенсусу може передати майже 10 000 повідомлень.
Це не є великою проблемою в невеликих мережах, але як тільки кількість валідаторів зросте, навантаження на зв'язок системи швидко стане нестерпним, а ефективність різко знизиться.
Джерело інформації:
Структура «кожен повинен спілкуватися з кожним» у другорядній комунікації насправді є дуже неефективною. Наприклад, у мережі з 100 валідаторами кожен раунд консенсусу може обробляти тисячі повідомлень.
Це можна зробити по вузькому колу, але в глобальній, відкритій ончейн-мережі навантаження на зв'язок відразу стає неприйнятною. Як наслідок, ранні протоколи BFT, такі як PBFT і Tendermint, зазвичай використовуються лише в дозволених мережах або системах з невеликою кількістю валідаторів.
Для того, щоб адаптувати протокол BFT до інклюзивного середовища публічного ланцюга, деякі дизайни наступного покоління почали рухатися до більш легкого способу комунікації: кожен валідатор спілкується лише з лідером, а не з усіма членами команди.
Це зменшило складність повідомлень з n² до n — значно полегшивши навантаження на систему.
Протокол HotStuff був представлений у 2018 році для вирішення цієї проблеми масштабованості. Він був розроблений з чіткою ідеєю: замінити складний процес голосування PBFT простішою, керованою лідерами комунікаційною структурою.
Ключовою особливістю HotStuff є так званий лінійний зв'язок. У його механізмі кожному валідатору потрібно лише надіслати свої голоси поточному лідеру, який потім упаковує ці голоси для створення сертифіката кворуму (QC).
Цей QC в основному є колективним підписом, що доводить всій мережі: "Більшість вузлів погодилася з цією пропозицією."
На відміну від цього, комунікаційна модель PBFT є "всеобхідним мовленням", де всі спілкуються в групі, що призводить до великого безладу. Модель HotStuff більше нагадує "одна особа збирає, один раз пакує", незалежно від кількості людей у мережі, вона все ще може підтримувати ефективну роботу.
На малюнку порівнюється розгалужена комунікаційна структура HotStuff із повнозв'язною моделлю PBFT.
Джерело інформації:
На додаток до лінійного зв'язку, HotStuff може бути додатково оновлений до конвеєрної версії (pipelineed HotStuff) для підвищення ефективності.
В оригінальному HotStuff один і той же валідатор служив лідером протягом декількох раундів поспіль, поки блок не був повністю підтверджений. Процес відбувається «один блок за раз», і всі зусилля зосереджені на просуванні поточного.
А в конвеєрі HotStuff механізм став ще гнучкішим: в кожному раунді обирається новий лідер, а завдання кожного лідера складається з двох частин:
Одна сторона упаковує голосування попереднього раунду в Quorum Certificate (QC) та транслює його всій мережі;
Пропонуючи новий блок, готуючись до наступного раунду.
Тобто, більше не буде "підтверджувати один блок, а потім обробляти наступний", а скоріше, як на виробничій лінії, різні лідери по черзі відповідатимуть за кожен етап. Попередній пропонує блок, наступний підтверджує його і продовжує пропонувати нові блоки, консенсус в мережі передається як естафета.
Ось звідки походить метафора "конвеєр": поточний блок все ще проходить процес підтвердження, наступний вже готується, багато етапів паралельно, що підвищує пропускну здатність.
Підсумовуючи, протоколи на кшталт HotStuff зробили суттєві покращення в двох вимірах в порівнянні з традиційними BFT:
По-перше, зв'язок став легшим, кожен валідатор повинен спілкуватися лише з лідером;
По-друге, ефективність обробки вища, кілька процесів підтвердження блоків можуть виконуватись паралельно.
Це зробило HotStuff дизайном шаблону для багатьох сучасних механізмів консенсусу PoS блокчейнів. Але в кожній справі є свої плюси і мінуси — хоча конвеєрна структура має потужну продуктивність, вона також тихо вводить структурний ризик, який важко виявити.
Далі ми будемо детально обговорювати це ключове питання: хвостове розгалуження (Tail Forking).
Проблема розгалуження хвоста (Tail-Forking)
Хоча HotStuff — особливо його версія з конвеєром — вирішує проблему масштабованості консенсусного протоколу, він також вводить деякі нові виклики. Найважливішою та найчастіше ігнорованою є проблема так званих «хвостових розгалужень» (Tail Forking).
Що таке кінцеве розгалуження? Можна просто зрозуміти як: на "кінці ланцюга" в блокчейні сталася несподівана переробка блоку (reorg).
Зокрема, є блок, який є дійсним, успішно поширився на більшість валідаторів і отримав достатню кількість голосів, щоб його ось-ось підтвердити та записати в основний ланцюжок. Але врешті-решт його «пропустили», осиротіли і замінили новим блоком на тій же висоті.
Це не помилка і не атака, а пов'язано з тим, що в структурі самого протоколу існує можливість "випадіння з ланцюга". Чи не звучить це трохи несправедливо? Тож як це взагалі сталося?
Ми вже говорили, що кожен лідер у лінії HotStuff має дві задачі:
A. Запропонувати новий блок (наприклад, Bₙ₊₁)
B. Збирати голоси за блок попереднього лідера, генеруючи QC (наприклад, завершуючи остаточне підтвердження для Bₙ)
Ці два завдання виконуються паралельно, по черзі. Але проблема в цьому.
Наприклад: припустимо, що Аліса є лідером, вона на висоті n представила блок Bₙ, цей блок отримав супербільшість голосів і вже "майже підтверджено".
Далі лідером має стати Боб, щоб продовжити просування наступного блоку ланцюга Bₙ₊₁, при цьому йому також слід упакувати QC (доказ законної більшості) блоку Bₙ у свою пропозицію, щоб завершити остаточне підтвердження Bₙ.
Але якщо Боб у цей час офлайн або навмисно не подає QC Bₙ, то виникнуть проблеми.
Оскільки ніхто не завершив QC-пакет для блоку Alice, голосування Bₙ не змогло поширитися, і цей блок, який повинен був бути підтверджений, просто залишився "в холодному зберіганні" і в кінцевому підсумку був проігнорований усією мережею.
Це суть кінцевого розгалуження: блок попереднього лідера пропускається через невиконання обов'язків або умисел наступного лідера.
Чому хвостова розвилка серйозна?
Проблема розгалуження в кінці зосереджена на двох аспектах: 1) порушення механізму стимулювання, 2) загроза активності системи.
По-перше, винагорода була поглинута:
Якщо блок відкидається, лідер, який його запропонував, не отримує винагороди. Будь то винагорода за блок або комісія за транзакції. Наприклад, Аліса запропонувала легітимний блок і отримала переважну більшість голосів, але через помилки або зловмисні дії Боба блок не був підтверджений, і Аліса в підсумку не отримала ні копійки. Це призводить до неправильної структури стимулювання: шкідливі вузли, такі як Боб, можуть «впорядкувати» своє джерело винагороди, пропустивши блок опонента. Така поведінка не вимагає технічної атаки, лише навмисного «неспівпраця» для послаблення заробітку конкурента. Якщо подібні речі повторюватимуться повторювано, з часом це зменшить участь і справедливість усієї системи і навіть спровокує змову між вузлами.
По-друге, розширення простору атак MEV:
Хвостові вилки також створюють більш підступну, але серйозну проблему: з'являється більше простору для зловмисного маніпулювання MEV (максимальною видобувною цінністю). Ось приклад: Припустимо, Аліса має цінну арбітражну угоду у своєму блоці. Якщо Боб хоче наробити неприємностей, він може вступити в змову з наступним лідером, Керол, і навмисно не поширювати блок Аліси. Потім Керол реконструює новий блок на тій самій висоті, «крадучи» оригінальну арбітражну угоду Аліси, змушуючи MEV отримати свій власний. Ця практика «перестановка головки ланцюга + змова та привласнення» все ще є блоком за правилами на поверхні, але насправді це добре сплановане грабунок. Ще гірше те, що це провокує «змову» між лідерами, перетворюючи підтвердження блоків на гру з розподілом вигод, а не на державну послугу.
По-третє, порушення фінальної гарантії вплине на досвід користувачів:
У порівнянні з протоколами типу Nakamoto, однією з основних переваг BFT є детерміноване завершення: як тільки блок був поданий, його не можна скасувати. Але кінцеве розгалуження порушує цю гарантію, особливо в тих випадках, коли блоки "отримали голоси, але ще не були офіційно підтверджені". Деякі dapp з високою пропускною здатністю зазвичай хочуть мати можливість негайно зчитувати дані після підтвердження голосування по блоку, щоб зменшити затримки, а якщо цей блок буде раптово скасовано, це може призвести до відкату стану користувача - наприклад, аномалії в балансі облікового запису, раптова зникнення щойно завершеної високоплечої угоди, раптове скидання стану гри тощо.
По-четверте, може викликати каскадні збої:
Загалом, розгалуження в кінці може лише на деякий час затримати підтвердження блоку, і вплив незначний. Але в деяких крайніх ситуаціях, якщо кілька лідерів підряд вирішать пропустити попередній блок, система може потрапити в стан стагнації, і ніхто не захоче "взяти на себе" попередній блок. Прогрес всього ланцюга зупиниться, поки не з'явиться "лідер, готовий взяти на себе відповідальність", і мережа зможе продовжити рух.
Хоча раніше були деякі рішення, такі як механізм уникнення відгалужень, запропонований протоколом BeeGees, вони часто потребують жертвування продуктивністю, наприклад, повторного введення складності вторинного зв'язку, що не виправдовує витрат.
Що таке MonadBFT?
MonadBFT - це нове покоління консенсусного протоколу, спеціально розроблене для вирішення проблеми кінцевих розгалужень. Його перевага полягає в тому, що воно вирішує структурні ризики, не жертвуючи перевагами продуктивності, які надає конвеєр HotStuff. Іншими словами, MonadBFT не є повним перезавантаженням, а продовжує оптимізацію на основі основної структури HotStuff. Воно зберігає три ключові характеристики:
1）Ротація лідерів (rotating leader): кожного раунду обирається новий лідер для просування ланцюга;
Пайплайнові коміти (pipelined commits): кілька процесів підтвердження блоків можуть перехрещуватися.
Лінійний обмін повідомленнями (linear messaging): кожен валідатор повинен спілкуватися лише з лідером, що дозволяє зекономити значну кількість мережевих витрат.
Але лише цих трьох пунктів недостатньо для забезпечення безпеки. Щоб закрити структурну уразливість, пов'язану з відгалуженнями, MonadBFT додала дві ключові механізми:
Механізм примусового повторного запропонування (Re-Proposal)
Безпідписний сертифікат (NEC, No-Endorsement Certificate)
Механізм повторної пропозиції (Re-Proposal)
У BFT-протоколі час ділиться на раунди (називаються view), в кожному раунді є лідер, відповідальний за пропозицію нового блоку. Якщо лідер зазнає невдачі (наприклад, не встигає запропонувати блок або пропозиція недійсна), система переходить до наступного раунду і обирає нового лідера.
MonadBFT додала механізм, який забезпечує, що під час зміни виду жоден чесно запропонований блок не буде «втрачений» через зміну лідера.
Коли лідер поточної раунду втрачає життєздатність, валідатори надсилають підписане повідомлення про зміну раунду (view change), що вказує на те, що поточний раунд вийшов за межі часу.
Особливість полягає в тому, що це повідомлення не лише вказує на те, що "вийшов термін", але також повинно містити інформацію про блок, за який останній раз голосував цей валідатор, що рівнозначно тому, щоб сказати: "Я не отримав дійсну пропозицію, ось останній блок, який я бачу."
Нова хвиля лідерів збирає ці повідомлення про таймаут від супербільшості (2f+1) валідаторів і об'єднує їх в сертифікат таймауту (Timeout Certificate, TC). Цей TC представляє: коли попередній раунд зазнав невдачі, вся мережа має єдине усвідомлення «головного блоку ланцюга». Новий лідер вибирає з цього найвищий блок (або останній номер перегляду), так званий high_tip.
MonadBFT вимоги: пропозиція нового лідера повинна містити законний TC, а також повинна повторно запропонувати найбільший завислий блок у TC, щоб цей блок знову отримав шанс на підтвердження.
Чому? Як ми згадували раніше: ми не хочемо, щоб блок, який наближається до підтвердження, просто зник.
Наприклад: припустимо, що Аліса є лідером вью 5, представила дійсний блок і отримала більшість голосів. Далі лідер вью 6 Боб оффлайн, не зміг просунути процес ланцюга. Коли Кароліна стає лідером вью 7, за правилами MonadBFT їй потрібно включити TC і знову запропонувати блок Аліси. Таким чином, чесна праця Аліси не буде марною.
Якщо Карол не має блоку Аліси, вона може запросити його у інших вузлів. Вузли можуть:
надати цю ділянку, або
Повернути підписане "повідомлення без підтвердження" (No-Endorsement, NE), що вказує на те, що у вас немає цього блоку (далі буде представлено його механізм). (Максимум f візантійських вузлів можуть вирішити проігнорувати запит і не відповідати.)
Якщо Керол повторно запропонує блок Аліси, вона отримає додаткову можливість для пропозиції, щоб переконатися, що її не «покарають» через невдачу попереднього лідера.
Функція цього механізму повторної пропозиції є чіткою: забезпечити справедливий прогрес ланцюга, щоб жодна ефективна робота не була тихо відкинута через нещасливу випадковість або через втручання когось.
Безгарантійне свідоцтво (NEC)
Продовжуючи попередній приклад: після того, як тайм-аут раунду Боба настав, Карол запитує інших валідаторів надати блок high_tip (тобто блок Аліси). У цей момент принаймні 2f+1 валідаторів дадуть відповідь:
або надайте блок Аліси
Надішліть підписане NE повідомлення, що свідчить про те, що ви не отримали блок Аліси.
Якщо Карол отримала блок від Аліси, вона повинна повторно запропонувати його відповідно до правил. Лише у випадку, якщо принаймні 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:
Спекулятивна остаточність (Speculative Finality)
Оптимістична реакційність (Optimistic Responsiveness)
і далі проаналізувати практичне значення цих механізмів для валідаторів та розробників.
Продовження слідує.