Ядро блокчейну полягає в досягненні строгого глобального консенсусу: незалежно від того, де розподілені вузли мережі в якій країні або часовому поясі, всі учасники в кінцевому підсумку повинні досягти консенсусу щодо набору об'єктивних результатів.

Але реальність розподілених мереж не є ідеальною: вузли виходять з ладу, вузли неправдиві, а деякі навіть намагаються умисно завдати шкоди. У цьому випадку, як система може "говорити однією мовою" та підтримувати послідовність?

Це проблема, яку має вирішити протокол консенсусу. Це в суті є набір правил, щоб керувати групою незалежних і навіть частково ненадійних вузлів щодо досягнення єдиної думки щодо порядку та змісту кожної транзакції.

І як тільки ця 'жорстка згода' встановлюється, блокчейн може розблокувати багато ключових функцій, таких як захист цифрових прав власності, антиінфляційні моделі валют та масштабовані соціальні структури співпраці. Але передумовою є те, що сам протокол згоди повинен забезпечити два фундаментальні аспекти одночасно:

• Два суперечливих блоки не можуть бути підтверджені;
• Мережі повинні продовжувати рухатися вперед і не можуть застрягти або зупинятися.

MonadBFT є останнім технологічним проривом в цьому напрямку.

Короткий огляд еволюції протоколів консенсусу

У сфері механізмів консенсусу вона фактично вивчалася десятиліттями. Найраніша партія протоколів, таких як PBFT (Practical Byzantine Fault Tolerance), вже може обробляти дуже реалістичну ситуацію: навіть якщо деякі вузли в мережі випадково відпадуть від ланцюжка, будуть діяти зловісно або говоритимуть дурниці, поки їх кількість не перевищить третину від загальної кількості, система все ще може досягти консенсусу.

Дизайн цих ранніх протоколів більш "традиційний": кожному раунді обирається лідер для ініціювання пропозиції, а інші валідатори голосують за цю пропозицію у кількох раундах, щоб поступово підтвердити порядок транзакцій.

Весь процес голосування зазвичай проходить кілька етапів, таких як підготовка, підготовка, зобов'язання та відповідь. На кожному етапі всі перевіряючі повинні спілкуватися один з одним. Іншими словами, кожен повинен розповісти кожному, і обсяг повідомлень вибухово зростає в 'мережевому' шаблоні.

Складність цієї структури комунікації становить n² - це означає, що якщо в мережі є 100 перевіряючих, кожне коло консенсусу може вимагати передачі майже 10 000 повідомлень.

У невеликій мережі це не проблема, але якщо кількість валідаторів зросте, комунікаційне навантаження системи швидко стане невитримуваним і безпосередньо вплине на ефективність.

Джерело інформації:https://medium.com/coinmonks/pbft-розуміння-алгоритму-b7a7869650ae

Друга структура вторинного спілкування «кожен розмовляє з кожним» насправді дуже неефективна. Наприклад, в мережі з 100 валідаторами кожне коло консенсусу може потребувати обробки десятків тисяч повідомлень.

Це все ще можна керувати в невеликому колі, але коли воно розміщується в глобальній, відкритій ланцюговій мережі, навантаження на комунікацію одразу стає неприйнятним. Такі ранні протоколи BFT, як PBFT і Tendermint, зазвичай використовуються тільки в мережах з дозволом або системах з дуже небагатьма перевіряючими, щоб ледь функціонувати.

Щоб дозволити протоколу BFT адаптуватися до недозволених, громадських ланцюгів, деякі дизайни наступного покоління рухаються в бік легших методів комунікації: дозволяючи кожному перевіряючому спілкуватися лише з лідером, а не з усіма учасниками.

Це оптимізує складність повідомлення з початкових n² до n, значно зменшуючи системне навантаження.

Протокол HotStuff був запропонований у 2018 році для вирішення цієї проблеми масштабованості. Його філософія дизайну дуже чітка: замінити складний процес голосування PBFT більш стислою комунікаційною структурою, орієнтованою на лідера.

Однією з ключових особливостей HotStuff є так звана лінійна комунікація. У своєму механізмі кожен валідатор повинен надіслати свій голос поточному лідеру, який потім упаковує ці голоси для генерації Свідоцтва Кворуму (QC).

Цей КС заснований на колективному підписі, який підтверджує всій мережі: 'Більшість вузлів погоджується з цим пропозицією.'

Навпаки, режим зв'язку PBFT - «розсилання всім», де кожен говорить у групі, що часом призводить до хаосу. Режим HotStuff більше схожий на «один збирає, один упаковує за раз», що дозволяє підтримувати ефективну роботу незалежно від кількості людей в мережі.

Фігура порівнює структуру комунікації виходу вентиляції HotStuff з повністю зв'язаним режимом PBFT Source:

https://www.mdpi.com/1424-8220/24/16/5417

Крім лінійного зв'язку, HotStuff може бути ще більш покращений до версії з конвеєром, що використовується для підвищення ефективності.

У початковому HotStuff той самий валідатор буде служити лідером протягом кількох раундів поспіль, поки блок не буде повністю підтверджений. Цей процес полягає у 'обробці одного блоку за раунд', з усіма зусиллями спрямованими на продвиження поточного.

У конвеєрі HotStuff механізм ще більш гнучкий: у кожному раунді вибирається новий лідер, який має дві завдання:

• Упакуйте останній раунд голосів в Свідоцтво кворуму (QC) з одного боку й розповсюдьте його по всій мережі;
• З одного боку, запропонуйте новий блок, готовий розпочати наступний раунд.

Іншими словами, це вже не 'підтверджуйте одне перед обробкою наступного', а, як на продукційній лінії, різні лідери по черзі відповідають за кожен крок. Попередній пропонує блок, наступний підтверджує його і продовжує пропонувати нові блоки, а згода на ланцюгу передається, як естафета.

Ось походження метафори «лінія зборки»: поточний блок все ще знаходиться в процесі підтвердження, тоді як наступний вже готується, декілька кроків виконуються паралельно, що збільшує продуктивність пропускної здатності.

Узагальнюючи, протоколи, такі як HotStuff, зробили значні покращення у порівнянні з традиційним BFT у двох вимірах:

• Спочатку комунікація є легшою, оскільки кожному перевіряючому потрібно спілкуватися лише з лідером;
• По-друге, ефективність обробки вища, і кілька процесів підтвердження блоків можуть працювати паралельно.

Це робить HotStuff шаблоном дизайну для багатьох сучасних механізмів консенсусу блокчейну PoS. Але у всьому є свої плюси та мінуси - хоча структура конвеєра є потужною у продуктивності, вона також тихо вводить недосяжний структурний ризик.

Наступного разу ми збираємося глибше дослідити це основне питання: Tail Forking.

Проблема хвостового вилкування в кінці

Хоча HotStuff, особливо його версія з конвеєром, вирішує проблему масштабованості протоколу консенсусу, він також вносить деякі нові виклики. Найважливішою і легко пропущеною є так звана проблема "Tail Forking".

Що таке хвістова відгалуження? Це може бути просто зрозуміло, як: блокчейн випадково переживає реорганізацію блоку на ‘хвості’ ланцюга.

Зокрема, є блок, який є дійсним, успішно поширений серед більшості валідаторів і отримав достатню кількість голосів. За ідеєю, це має бути підтверджено та записано в основний ланцюжок негайно. Однак в кінцевому підсумку його «пропускають», осирошують і замінюють іншим новим блоком на тій же висоті.

Це не помилка, не атака, але через те, що в структурі дизайну самого протоколу існує можливість так званого 'хвоста ланцюга'. Чи звучить це трохи несправедливо? Як це відбувається?

Як ми вже зазначали раніше, кожен лідер потоку HotStuff має дві задачі:

• A. Запропонуйте новий блок (наприклад, Bₙ₊₁)
• B. Збирати голоси за блок попереднього лідера для генерації QC (наприклад, щоб остаточно підтвердити Bₙ)

Ці дві задачі паралельні, по черзі передаються. Але проблема виникає тут.

Наприклад, припустимо, що Еліса є лідером, і вона запропонувала блок Bₙ на висоті n, який отримав супербільшість голосів і є «майже підтвердженим».

Далі Боб повинен взяти на себе роль лідера, продовжити рух до наступного блоку Bₙ₊₁ ланцюжка, а також включити QC (Якісне Зобов'язання) Bₙ у свою пропозицію для завершення остаточного підтвердження Bₙ.

Але якщо Боб зараз не в мережі, або свідомо не надсилає КС Bₙ, то виникає проблема.

Оскільки ніхто не упакував блок Еліс з КС, запис голосування Bₙ не поширювався. Цей блок, який повинен був бути підтверджений, отже, був 'холодно оброблений' і в кінцевому рахунку ігнорувався усією мережею.

Ось суть хвостового вілка: блок попереднього лідера пропускається через недбалість або злоупорядкованість наступного лідера.

Чому така сувора вилиця хвоста?

Проблема хвостової вилки в основному зосереджується на двох аспектах: 1) порушується механізм стимулювання, 2) загрожується активність системи.

Спочатку винагороди ковтнуті:

Якщо блок відкинуто, лідер, який його запропонував, також не отримає жодних винагород, або блокових винагород або комісійних винагород. Наприклад, якщо Еліс запропонувала дійсний блок і отримала потужну підтримку на голосуванні, але через помилку або зловісну дію Боба блок не міг бути підтвердженим, Еліс в кінцевому підсумку не отримає ні копійки. Це призведе до недоліків у стимулювальній структурі: злоякісні вузли, подібні до Боба, можуть «відрізати» свої джерела винагород, пропускаючи блоки своїх опонентів. Ця поведінка не потребує технічних атак, лише умисного «неспівпраці» для ослаблення прибутків конкурентів. Якщо це станеться знову й знову, з часом участь та справедливість всієї системи зменшаться, навіть спровокуючи злиття між вузлами.

Друге, поверхня атаки MEV розширюється:

Вилки хвоста також створюють більш підступну, але серйозну проблему: є більше місця для МВП (Максимально видобута вартість), яку можна зловживати. Ось приклад: скажемо, у блоку Еліс є цінна арбітражна угода. Якщо Боб хоче зібрати лихо, він може узгодитися з наступним лідером, Карол, і навмисно не поширювати блок Еліс. Потім Карол конструює новий блок на тій самій висоті, «крадучи» початкову арбітражну угоду Еліс - збільшуючи власний МВП. Ця практика «перестановки верхнього блоку + узгодженого відведення» все ще є блоком згідно з правилами на поверхні, але це фактично добре спланований розбій. Ще гірше, це спонукає до «узгодження» між лідерами, перетворюючи підтвердження блоку на гру розподілу користів, а не на громадське обслуговування.

Третє, підриває гарантію остаточності, впливаючи на досвід користувача:

Порівняно з протоколами типу Накамото, однією з основних переваг BFT є детермінована завершеність: як тільки блок зафіксований, його не можна відкотити. Однак хвістова відгалуженість порушує цю гарантію, особливо на блоках, які «попередньо зафіксовані, але офіційно не підтверджені». Деякі високопродуктивні додатки часто хочуть читати дані негайно після голосування за блок, щоб зменшити затримку, і якщо блок раптово скасовується, це може призвести до відкату стану користувача – таких як аномальні баланси рахунків, великі сделки з великим кредитним плечем, що тільки що були завершені, зникають без причини, або раптові скидання стану гри.

Четверте, може спричинити ланцюжкову реакцію відмови:

Загалом хвістова вилка може лише затримати підтвердження блоку на одне коло, що не має великого впливу. Однак у деяких випадках, якщо кілька лідерів поспіль вирішать пропустити попередній блок, система може застрягти, і ніхто не бажає «перехопити» попередній блок. Вся ланцюг застрягає, поки не з'явиться лідер, який готовий взяти на себе відповідальність, і мережа продовжить рухатися вперед.

Хоча існували деякі рішення раніше, наприклад, механізм уникнення викидання хвоста, запропонований протоколом BeeGees, вони часто потребують жертвування продуктивністю, такі як повторне введення другорядної складності комунікації, що не варто втрат.

Що таке MonadBFT?

MonadBFT - це нове покоління протоколу консенсусу, спеціально розроблене для вирішення проблеми хвостової вилки. Його сила полягає в тому, що, вирішуючи структурні вразливості, він не жертвує перевагами продуктивності, які надає конвеєр HotStuff. Іншими словами, MonadBFT не починає все спочатку, а продовжує оптимізацію на основі основного каркасу HotStuff. Він зберігає три ключові характеристики:

1) Повертаючий лідер: Оберіть нового лідера для кожного раунду, щоб просунути ланцюг вперед;
2) Послідовні коміти: Кілька процесів підтвердження блоку можуть накладатися один на одного;
3) Лінійна комунікація (лінійне повідомлення): Кожен валідатор повинен спілкуватися лише з лідером, що дозволяє зекономити значну частину мережевого навантаження.

Проте, лише покладаючись на ці три пункти, цього недостатньо безпечно. Для усунення структурної вразливості хвостової вилки MonadBFT додав два ключові механізми:

1) Обов'язковий механізм повторної пропозиції (Повторна пропозиція)
2) Свідоцтво без затвердження (NEC)

Механізм повторного запиту

У протоколі BFT час поділяється на раунди (відомі як перегляди), у кожному з яких є лідер, відповідальний за пропозицію нового блоку. Якщо лідер не виправдав очікувань (наприклад, не запропонував блок вчасно або з недійсною пропозицією), система переходить до наступного раунду та обирає нового лідера.

MonadBFT додав механізм, щоб забезпечити, що будь-які чесно запропоновані блоки під час процесу перемикання виду не 'втратять ланцюг' через обертання лідера.

Коли поточний лідер не вдається, валідатори надсилають підписане повідомлення для перемикання раунду (зміни виду), вказуючи, що поточний раунд завершився.

Зокрема, це повідомлення не лише вказує на 'вийшов час', але також повинно містити інформацію про блок останнього голосування валідатора, що еквівалентно тому, що 'я не отримав дійсну пропозицію, ось останній блок, який я зараз бачу.'

Новий раунд лідерів збере ці повідомлення про тайм-аут від супербільшості (2f+1) валідаторів та об'єднає їх в Свідоцтво про тайм-аут (TC). Це Свідоцтво про тайм-аут представляє уніфікований когнітивний знімок 'ланцюгового головного блоку' всієї мережі в разі невдачі попереднього раунду. Новий лідер вибере блок з найвищою висотою (або останнім номером перегляду), відомий як високий підказка, з нього.

MonadBFT потребує: Пропозиція нового лідера повинна включати дійсний TC та повинна знову запропонувати найвищий невиконаний блок у TC, щоб дати цьому блоку ще одну шанс на підтвердження.

Чому? Як вже згадувалося раніше: ми не хочемо, щоб блок, який майже підтверджено, зник.

Наприклад, припустимо, що Аліса є лідером перегляду 5, запропонувала дійсний блок та отримала більшість голосів. Далі, коли лідер перегляду 6, Боб, не в мережі та не може продовжити процес ланцюга, до того часу, коли Карол стає лідером перегляду 7, згідно з правилами MonadBFT, вона повинна включити TC та повторно запропонувати блок Аліси. Таким чином, чесна праця Аліси не буде марною.

Якщо у Керол немає блоку Еліс, вона може запросити його в інших вузлів. Вузли можуть:

• Надайте блок, або
• Поверніть підписане повідомлення 'Без реклами (NE)', яке вказує, що відправник не має цього блоку (його механізм пояснюється пізніше). (До f візантійських вузлів можуть вибрати ігнорувати запит і не відповідати.)

Коли Керол перевищить блок Аліси, вона отримає додаткову можливість пропозиції, щоб переконатися, що вона не є 'залученою' через невдачу попереднього лідера.

Роль цього механізму повторної пропозиції очевидна: забезпечити, що просування ланцюжка відбувається справедливо, і жодна дійсна робота не буде тихо відкинута через нещасливий випадок або саботаж когось.

Невідшкодовний сертифікат (NEC)

Продовжуючи попередній приклад: Після того, як вийшов час Боба, Керол запитує інших перевіряючих надати блок з високою підказкою (тобто блок Еліс). На цьому етапі відповість принаймні 2f+1 перевіряючих:

• Надайте блоки Еліс
• Надішліть підписане повідомлення NE, яке вказує, що ви не отримали блок Еліс.

Якщо Карол отримує блок від Еліс, вона повинна повторно запропонувати його відповідно до правил. Карол може пропустити блок та запропонувати новий лише тоді, коли щонайменше f+1 валідаторів підписали повідомлення NE.

Чому f+1? У BFT системі, що складається з 3f+1 валідаторів, може бути лише f зловмисних. Якщо блок Еліс дійсно отримав супербільшість голосів, то щонайменше 2f+1 чесних вузлів його отримали.

Отже, якщо Керол стверджує: «Я не можу отримати блок Еліс», вона повинна виробити f+1 підпис валідатора, щоб довести, що ніхто з них не отримав його. Це становить Свідоцтво про відмову в рекомендації (NEC).

NEC є обліковими даними лідера: це підтверджує, що попередній блок не готовий бути підтвердженим, не було зловмисно пропущено, але "відмовлено" з певними причинами.

Повторна пропозиція + Непідтверджений сертифікат = Вирішення хвостової вилки

MonadBFT вводить набір строгих і чітких правил обробки верхньої ланцюга, представивши механізм повторної пропозиції та Свідоцтво без підтримки (NEC).

Або остаточно зобов'язатися до блоку 'наближеного до підтвердження';

Надайте достатні докази, щоб довести, що блок ще не готовий бути підтвердженим,

В іншому випадку заборонено пропускати або заміняти попередній блок.

Цей механізм забезпечує, що будь-який блок, який отримав законну більшість голосів, не буде покинутий через помилки лідера або навмисне обхід.

Структурні ризики хвостової вилиці систематично вирішуються, і протокол може чітко обмежувати неправильну поведінку пропускання.

Якщо лідер намагається пропустити попередній блок без надання доказів NEC, протокол негайно визначить і відхилить цю поведінку. Перестрибування без криптографічних доказів буде вважатися незаконним і не отримає підтримку мережевої згоди.

З економічної точки зору стимулів цей дизайн забезпечує чітку захист для валідаторів:

• Допоки блок чесно пропонується і отримує підтримку голосування, його винагорода не буде позбавлена через подальші невдачі.
• Навіть у крайніх ситуаціях, таких як коли вузол навмисно пропускає свій власний раунд пропозицій та намагається допомогти іншим у захопленні MEV з попереднього блоку, протокол змусить наступного лідера надати пріоритет повторній пропозиції оригінального блоку, запобігаючи нападнику отримати економічну вигоду від пропуску процесу.

Ще важливіше, MonadBFT не пожертвував продуктивність протоколу, щоб підвищити безпеку.

Деякі дизайни, які вирішують хвостові вилки (наприклад, протокол BeeGees) у минулому мали певні захисні можливості, але часто ґрунтуються на високій складності комунікації (n²) або дозволяють важкі процеси комунікації в кожному раунді, що значно збільшує системне навантаження на практиці.

Стратегія дизайну MonadBFT більш вдосконалена:

Додаткова комунікація (така як повідомлення про тайм-аут, повторні пропозиції блоків) ініціюється лише тоді, коли виникають відмови у перегляді або існують аномалії. На регулярному шляху, де більшість чесних лідерів постійно виробляють блоки, протокол все ще підтримує легкий та ефективний робочий стан.

Динамічний баланс між продуктивністю та безпекою є саме однією з ключових переваг MonadBFT перед його попередниками протоколами.

Огляд

Ця стаття оглядає основний механізм традиційної консенсусу PBFT, систематизує шлях розвитку протоколу HotStuff і акцентує увагу на тому, як MonadBFT вирішує вроджену проблему хвостової відгалуження в протоколі HotStuff на рівні структури.

Задні вилки можуть спотворювати економічні стимули для пропонентів блоків та становити потенційну загрозу для мережевої активності. MonadBFT забезпечує, що будь-який блок, запропонований чесними лідерами та схвалений більшістю голосів, не буде відкинутий або пропущений шляхом введення механізму повторного запропонування та Не-підтвердженого сертифікату (NEC).

У наступній статті ми продовжимо досліджувати інші дві основні функції MonadBFT:

1) Спекулятивна достовірність
2) Оптимістична відповідь

Подальший аналіз цих механізмів та їх практичне значення для валідаторів та розробників.

Заява:

1. Ця стаття перепублікована з [michael_lwy], авторські права належать оригінальному авторові [michael_lwy]，якщо у вас є які-небудь зауваження щодо репринту, будь ласка, зв'яжіться Gate Навчальна Команда) , команда якнайшвидше вирішить це відповідно до відповідного процесу.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, є виключно тими, хто їх автор і не становлять жодної інвестиційної поради.
3. Інші мовні версії статті перекладені командою Gate Learn, без згадуванняGate.ioНе копіюйте, не поширюйте або не плагіатуйте перекладені статті без дозволу.