ВЧастина 1,Ми розглянули, як працює класична консенсусна PBFT та як працюють попередні версії HotStuff. Ми також розглянули, як MonadBFT вирішує проблему tail-forking у HotStuff, коли деякі дійсні блоки іноді залишаються відстуними в канальних системах.

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

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

У частині 2 ми досліджуємо інші дві характеристики MonadBFT, які є 1) спекулятивна остаточність та 2) оптимістична відзивчивість. Ми також розглянемо наслідки MonadBFT для розробників.

Фінальність спекулятивної одноразової угоди

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

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

Нагадаємо, що в протоколах базового HotStuff блок зазвичай не вважається остаточним (незворотнім), доки він не пройшов принаймні дві фази (наприклад, Швидкий Hotstuff та Diem-BFT): одна фаза для отримання Сертифікату Кворуму (заблокувати блок з ≥2f+1 голосів) і друга фаза, де наступний лідер будує на цьому СК та фіксує блок.

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

MonadBFT в основному дозволяє вважати транзакцію достатньою фінальною (безпечною для дії) після всього одного раунду голосування. Це називається спекулятивною остаточністю.

Коли лідер пропонує блок, а валідатори голосують за створення КС для цього блоку, цей блок зараз перебуває в стані "Проголосовано" (він заблокований кворумом). У MonadBFT валідатори виконують транзакції блоку, як тільки вони формують КС, навіть відправляють попереднє підтвердження клієнтам, вказуючи, що блок (спекулятивно) прийнятий. Це подібно до того, як кажуть: "У нас є супербільшість, що погоджується з цим блоком. Якщо не відбудеться щось дуже несподіване, вважайте цей блок підтвердженим."

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

Ви можете розглядати спекулятивну остаточність як приємний побічний продукт опору чубатого виливання. Опір чубатому виливанню гарантує, що навіть якщо наступний лідер аварійно впаде, поточна пропозиція не буде опущена (завдяки правилам повторної пропозиції та NEC). Таким чином, єдиний час, коли спекулятивно виконаний блок вилучається, це випадок, якщо початковий пропонувальник зробив еквівокацію (подвійне підписання, яке можна довести як зловживання), яке: 1) виявляється за конфліктними QС, 2) може призвести до штрафу та 3) є надзвичайно рідкісним.

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

Оптимістична відповідальність

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

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

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

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

• У щасливому сценарії (означає, що у нас є чесний лідер): немає вбудованої затримки у пропозиції або голосуванні. Як тільки лідер отримує чергу, він пропонує блок. Як тільки валідатори отримують дійсну пропозицію, вони голосують. У момент, коли лідер (або, точніше, наступний лідер, оскільки голоси йдуть наступному пропоненту в конвеєрному HotStuff) отримує 2f+1 голос, QC формується і може бути розповсюджений. У оптимістично реактивному дизайні це спричиняє негайний перехід до наступної фази.

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

Воно не чекає, наприклад, повну секунду "час слоту", якщо цього не потрібно. Це відмінно від основної мережі Ethereum, яка дотримуєтьсямодель слоту та епохиНа Ethereum виробництво блоків фіксовано на інтервалах у 12 секунд. Навіть якщо всі готові раніше, протокол чекає.

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

• У невдачному шляху (відмова лідера): У багатьох протоколах консенсусу, коли лідер не може запропонувати блок, інші вузли розуміють це лише після того, як мине тайм-аут Δ. Якщо, наприклад, Δ дорівнює 1 секунді, то цей час фактично втрачено. MonadBFT обробляє це по-іншому. Коли валідатори виявляють відсутність пропозиції, вони негайно розповсюджують повідомлення про тайм-аут (TC або Сертифікат тайм-ауту). Як тільки бачать 2f+1 таких тайм-аутів, наступний лідер бере владу. Перехід до нового перегляду спричинюється доказами на основі кворуму, а не годинником.

Порівняння з консенсусом сім'ї hotstuff

MonadBFT ґрунтується на лінії протоколів узгодження сімейства HotStuff, але виділяється досягненням комбінації бажаних властивостей, які жоден попередній дизайн не зміг повністю інтегрувати без уступок. Раніше протоколи часто оптимізувались для деяких розмірностей, таких як пропускна здатність з конвеєром або лінійна комунікація, але доводилося жертвувати іншими. MonadBFT унікально поєднує лінійну складність повідомлень, робить коміти з конвеєром, має міцний опір хвостовому розділенню, миттєву реакцію без фіксованих затримок та ефективні механізми відновлення, все це зберігаючи швидку остаточність і високі гарантії активності. У таблиці нижче узагальнено, як MonadBFT порівнюється з іншими протоколами BFT з обертальним лідером за цими критичними розмірами.

Що це означає для розробників та користувачів?

Для розробників, MonadBFT має кілька значень:

• Простіша модель остаточності: З MonadBFT ви можете розглядати блок, який має QC (супербільшість голосів), як ефективно остаточний для більшості цілей, оскільки протокол його остаточно завершить або стримає. Розробники можуть безпечно діяти на підтвердженнях 1 блоку з високою впевненістю.
• Покращений досвід користувача для додатків: Якщо ви створюєте додаток з високою пропускною здатністю (біржа, гра і т.д.), низька затримка та стійкість до відгалужень MonadBFT перекладаються в більш плавний досвід користувача. Користувачі майже миттєво бачать підтвердження своїх дій і рідко стикаються з заплутаними переорганізаціями або відкатами. Це дозволяє вам створювати додатки, які передбачають остаточність та швидке оновлення.
• Визначений Поведінка: Суворі правила MonadBFT (такі як вимога до повторного запропонування) зменшують недетермінованість у включенні блоку. Є менше "крайових випадків", де блок може бути включений або пропущений в залежності від тонкої часової ситуації, такої як те, чи до лідера першим дійшло голосування чи тайм-аут. MonadBFT замінює таку часочутливу неоднозначність чіткими правилами та перевірними доказами. Це полегшує міркування про коректність протоколу та його тестування. Воно також надає чіткі підстави для ідентифікації несправних вузлів (наприклад, якщо хтось не вдається повторно запропонувати або запропонувати конфліктуючий блок, ви знаєте, що вони порушили протокол).
• Запас масштабовості: якщо ви розробник, який турбується про масштабування, MonadBFT дарує вам більше запасу перед досягненням пунктів перегрузки. Ви можете зручніше збільшувати розміри блоків або кількість перевіряючих, ніж на квадратичному протоколі. Такі функції, як розповсюдження блоків з кодуванням видалень означають, що ви можете передавати велику кількість даних через мережу, не перевантажуючи окремі вузли. Це дозволяє мета для вищої продуктивності, що відкриває простір для більш амбіційних додатків на ланці

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

• Швидше підтвердження: Транзакції (наприклад, відправлення токенів, обмін активами, випуск NFT, виконання угод) будуть дуже швидко підтверджені.
• Менше сюрпризів: Послідовність стану ланцюга вища, оскільки такі речі, як хвостове вилучення, яке суттєво є реорганізацією, усуваються
• Справедливість та прозорість: покращення в консенсусі непрямо означає, що робота ланцюжка стає справедливішою. Жоден окремий перевіряючий не може легко цензурувати транзакції або грати замовлянням блоків.

Висновок

Підсумовуючи, MonadBFT вводить чотири основні інновації на основі консенсусу у стилі HotStuff з розгалуженим потоком:

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

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

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

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

Відмова від відповідальності:

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