Як Monad масштабує EVM, зберігаючи децентралізацію? MonadBFT — це алгоритм консенсусу, який використовується в Monad, це перша реалізація Hotstuff, яка стійка до задніх вилок (що це означає?) Ось як MonadBFT може масштабуватися до 1000 валідаторів, залишаючись при цьому продуктивним 🧵

1/7 Механізми консенсусу Механізм, який блокчейни використовують, щоб переконатися, що нові блоки узгоджені більшістю валідаторів. Алгоритми консенсусу поки що не здатні масштабуватися за межі кількох сотень валідаторів, оскільки складність зростає залежно від квадрата кількості валідаторів (у більшості випадків) Оскільки кожен валідатор спілкується з усіма іншими валідаторами, щоб домовитися про блоки: n валідаторів x n повідомлень = n-квадрат повідомлень. Отже, складність значно зростає зі збільшенням кількості валідаторів.

2/7 Hotstuff — це алгоритм консенсусу, який може масштабуватися лінійно (прямо пропорційно кількості валідаторів), уникаючи обміну повідомленнями «все до всього» та дозволяючи одному «лідеру» спілкуватися з усіма валідаторами для досягнення консенсусу. Таким чином, Hotstuff може масштабуватися ефективніше, ніж традиційний консенсус PBFT, але він вразливий до атак tailforking. MonadBFT – це перша реалізація Hotstuff, стійка до задніх вил.

3/7 Що таке хвостові вилки? Tailforking відбувається, коли наступний лідер (валідатор, який пропонує наступний блок) навмисно або випадково не включає QC валідного блоку попереднього лідера у свою пропозицію щодо нового блоку. (QC розшифровується як сертифікат кворуму, що є доказом того, що всі валідатори погодилися з попереднім блоком) В результаті, попередній блок, незважаючи на те, що він дійсний і має підтримку більшості, залишається незобов'язаним і в кінцевому підсумку осиротілим або замінюється іншим блоком на тій же висоті. Це порушує механізм заохочення: чесні ініціатори можуть не отримати винагороду за блок або комісію, якщо їхній блок буде пропущено, заохочуючи несправедливу поведінку та послаблюючи безпеку мережі.

4/7 Як працює MonadBFT? → Лідер (Аліса) передає пропозицію підписаного блоку всім іншим вузлам (fan out), які визнають його дійсність, надсилаючи підписану атестацію наступному лідеру Бобу (fan in). → Боб об'єднує атестації в «Сертифікат кворуму» (QC) → Боб транслює QC всім вузлам, які засвідчують його отримання, надсилаючи повідомлення 3-му лідеру (Чарлі), який агрегує ці атестації. Оскільки атестації стосуються КК, ми називаємо цей новий КК QC-on-QC. → Чарлі розсилає QC-on-QC всім бажаючим. Отримавши QC-on-QC, всі знають, що блок Аліси доопрацьований.

5/7 Трубопроводи У наведеній вище історії, Боб і Чарлі лише розсилають QC або QCS-on-QC, але насправді пропозиції надходять по черзі: повідомлення Боба містить як QC для блоку Аліси, так і вміст нового блоку. Повідомлення Чарлі містить QC для блоку Боба (який є QC-on-QC для блоку Аліси), а також містить транзакції для нового блоку. Коли валідатори надсилають атестацію для повідомлення Боба, вони підтверджують як валідність блоку Боба, так і валідність QC. Така трубопровідна система підвищує пропускну здатність мережі, оскільки з кожним слотом утворюється новий блок.

6/7 Raptorcast: протокол поширення блоку Monad MonadBFT вимагає, щоб лідер надсилав пропозиції щодо блоків кожному валідатору. Однак блоки можуть бути досить великими: 10 000 транзакцій/с * 200 байт/тх = 2 МБ/с. Для надсилання безпосередньо 200 валідаторам знадобиться 400 МБ/с. В ідеалі валідатори не повинні мати таку високу пропускну здатність завантаження. Саме тут на допомогу приходить Raptorcast. → Блоки кодуються стиранням лідером (Erasure code означає, що повідомлення розбивається на набір фрагментів, і воно може бути декодоване з досить великої підмножини цих фрагментів) → Лідер розподіляє різний набір фрагментів між усіма валідаторами в мережі (валідатори з вищою ставкою отримують пропорційно більше) → Кожен валідатор ретранслює свої фрагменти всім іншим валідаторам у мережі Таким чином, вся пропускна здатність мережі використовується для поширення пропозицій блоків.