Підбиваємо підсумки прориву в MonadBFT Вчора Category Labs випустила документ MonadBFT, в якому описаний механізм консенсусу, який забезпечить роботу Monad в основній мережі. MonadBFT є значною подією в дослідженнях консенсусу, оскільки це перший випадок, коли Pipelined HotStuff стає стійким до розгалуження. Розгалуження хвоста відбувається, коли пропущений слот призводить до того, що попередня пропозиція відкидається та знову видобується. Це серйозна проблема в попередніх формулах Pipelined HotStuff, оскільки вона відкриває багатоблокові MEV-атаки, які дестабілізують консенсус. Полегшення цієї проблеми є величезною справою, оскільки це дає нам усі переваги Pipelined HotStuff - часті блокування, низьку затримку, великі набори валідаторів - уникаючи при цьому найбільшого недоліку. MonadBFT також пропонує величезне оновлення для остаточності. Він має однослотову (500 мс) спекулятивну фіналічність і жорстку фіналізацію з двома слотами (1 с). «Спекулятивна остаточність» означає «остаточність, яка скасується лише у випадку еквівалентності (подвійного підписання) більшістю валідаторів». Еквівокація є серйозним правопорушенням у більшості блокчейн-систем і зазвичай карається скороченням; Чим більший штраф за двозначність, тим ближче можна думати про «спекулятивну завершеність» до остаточності. Однослотова спекулятивна фінальність – це величезний розлок для високопродуктивних додатків, які можуть впевнено відображати оновлений стан світу відразу після надходження чергового блоку. Ці властивості роблять MonadBFT величезним прогресом у досягненні консенсусу та гідним доповненням до інших складних покращень у Monad, включаючи асинхронне виконання, оптимістичне паралельне виконання та MonadDb. Решта цієї статті слугує підсумком того, як послідовні вдосконалення в HotStuff спиралися одне на одного, щоб пояснити проблему, яку вирішує MonadBFT. Підіб'ємо підсумки: 1. HotStuff надає нам лінійну складність зв'язку, щоб ми могли мати великі набори валідаторів, але це не дуже ефективно 2. Pipelineed HotStuff дає нам ефективність і низьку затримку від пропозиції блоків у кожному слоті, але страждає від проблеми хвостових вилок 3. MonadBFT дає нам опір задньої вилки та спекулятивну завершеність з одним слотом --- HotStuff: Лінійна складність зв'язку дозволяє здійснювати велику кількість вузлів Алгоритми HotStuff завершуються протягом кількох раундів комунікації, які зазвичай мають форму комунікації «віяло, віяло» безпосередньо від лідерів до валідаторів і назад до лідерів. Кожен раунд починається з того, що лідер надсилає повідомлення безпосередньо іншим валідаторам, кожен з яких надсилає назад підписане повідомлення, що підтверджує отримання повідомлення. За умови, що переважна більшість (2/3) валідаторів надсилає атестацію назад, кожен раунд закінчується тим, що лідер об'єднує підписані атестації в Сертифікат кворуму (QC), який служить доказом того, що супербільшість підтвердила попереднє повідомлення. Алгоритми HotStuff мають кілька таких раундів зв'язку. - Перше повідомлення від керівника – пропозиція блоку - Друге повідомлення – це КК для цієї пропозиції блоку - Третє повідомлення — це КК про попередній КК (тобто КК-на-КК) - і так далі Якщо процедура переривається в будь-який час до остаточності, блок не може завершитися і відкидається; Транзакції з цього блоку повинні бути повторно включені в наступний блок. Оригінальний протокол HotStuff не має конвеєра та має 3 раунди зв'язку до фіналізації; Один і той же валідатор грає роль лідера для кожного раунду. --- Pipelineed HotStuff: новий блок у кожному слоті підвищує ефективність Трубопровідна обробка – це те, що ми всі робимо інтуїтивно, коли нам потрібно виконати два завантаження білизни. Замість того, щоб чекати, поки завантаження 1 завершить повний цикл перед запуском завантаження 2, під час трубопроводу ми розміщуємо завантаження 1 у сушарці одночасно із завантаженням 2 у пральній машині. Ви можете думати про оригінальний HotStuff як про наївний підхід до прання білизни (не починайте з завантаження 2, поки завантаження 1 не буде повністю завершено), тоді як Pipelined HotStuff виконує інтуїтивну поведінку послідовного завантаження кількох завантажень білизни в шаховому порядку. У Pipelined HotStuff ми розподіляємо пропозиції в шаховому порядку так, що на кожному раунді пропонується новий блок, з новим блоком, який розміщується поверх повідомлення, що несе QC з попереднього блоку. Пропозиції блоків рухаються до фіналу протягом кількох раундів. Переваги трубопроводів значні. Конвеєризація підвищує щільність пропозицій блоків, оскільки пропозиція блоку робиться в кожному слоті, що підвищує пропускну здатність і знижує час до завершення. Однак є один істотний недолік пайплайнінгу, який найкраще проілюструвати на прикладі. Припустимо, що лідерами для блоків N, N+1 і N+2 є Аліса, Боб і Чарлі. Якщо Боб пропустить своє місце, то пропозиція Аліси також буде визнана недійсною, оскільки повідомлення Боба містить як його пропозицію, так і QC для пропозиції Аліси. Коли це трапляється, Чарлі в кінцевому підсумку викликають виготовити блок, ніби пропозиції Аліси ніколи не існувало. Ми називаємо цю поведінку «хвостовим розгалуженням», і її можна розглядати як міні-реорганізацію глибини 1. Можливість заднього вилка має значні наслідки, тому що пропущені слоти не обов'язково випадкові. Якщо є можливість отримати цінність шляхом повторного видобутку блоку Аліси при змінному порядку або пропуску деяких транзакцій, то Боб і Чарлі можуть вступити в змову, щоб Боб навмисно пропустив свій слот, що дасть можливість Чарлі повторно видобути блок Аліси. Це було значним недоліком протоколів Pipelined HotStuff (деякі з яких сьогодні є в основній мережі). --- MonadBFT змінює це MonadBFT — це перший протокол, який дозволив конвеєрну роботу, роблячи алгоритм стійким до вилок. Цей опір хвостовому вилку виникає через процедуру резервного варіанту, коли Боб пропускає свій слот, що дозволяє валідаторам зібрати воєдино свої колективні знання про пропозицію Аліси та рівень її консенсусу в наборі валідаторів. Зокрема, відповідно до MonadBFT, якщо Боб пропустить свій слот, то резервна процедура змушує валідаторів спілкуватися один з одним підписаними атестаціями про те, чи бачили вони блок Аліси. Якщо більшість засвідчує блок Аліси, то Чарлі змушений повторно запропонувати блок Аліси. Якщо Чарлі бажає запропонувати інший блок, то він повинен надати підписану атестацію від більшості валідаторів, яка підтверджує, що не бачить блок Аліси вчасно. У типовому випадку, коли Чарлі повторно пропонує блок Аліси, він потім може запропонувати свій блок у наступному раунді. Результатом є дві важливі властивості: стійкість до хвостового вилки та спекулятивна завершеність одного слота. Ми вже говорили про стійкість до вилки хвоста, але давайте розберемося, як це впливає на остаточність. Як і раніше, припустимо, що лідерами для блоків N, N+1 і N+2 є Аліса, Боб і Чарлі. Під Pipelined 2-Phase HotStuff - тобто до MonadBFT - як валідатор (або повний вузол), ви не можете завершити пропозицію блоку Аліси, поки не побачите пропозицію блоку Чарлі. Чому? Тому що, якщо ви завершите роботу, як тільки побачите пропозицію Боба, можливо, Боб возиться з вами, пересилаючи ТІЛЬКИ свою пропозицію вам, і він насправді планує не надсилати свою пропозицію всім іншим, тим самим пропустивши своє місце. Але в MonadBFT, як тільки ви побачите пропозицію Боба, ви можете «спекулятивно» доопрацювати пропозицію Аліси, тому що пропозиція Боба включає QC на пропозицію Аліси, що є доказом того, що 2/3 мережі підтвердили пропозицію Аліси. Навіть якщо Боб возиться з вами, пересилаючи вам ТІЛЬКИ свою пропозицію, і в кінцевому підсумку пропустить своє місце, ви знаєте, що переважна більшість мережі побачила пропозицію Аліси і, коли вони візьмуть участь у запасній процедурі, знову підпишуться під пропозицією Аліси. Єдиний спосіб, за допомогою якого блок Аліси не буде завершено, це якщо валідатори заперечать і підпишуть, що не бачили повідомлення Аліси. Цю помилку легко довести - ми підписали від них суперечливі повідомлення. Якщо покарання за двозначність є значним – а так має бути – ця «спекулятивна» остаточність насправді не така вже й спекулятивна. --- Висновки MonadBFT є надзвичайно захоплюючою розробкою для досягнення консенсусу, і вона є гідним доповненням до інших складних покращень у Monad, включаючи асинхронне виконання, оптимістичне паралельне виконання та MonadDb. Величезні вітання @MohammadMJalal1 та @KushalBabel з цим значним проривом. MonadBFT незабаром буде впроваджено на Monad Testnet, яка в даний час реалізує Pipelined 2-Phase HotStuff. Для подальшого читання дивіться пов'язану публікацію в блозі та статтю в наступному твіті.