Rezumând descoperirea din MonadBFT Ieri Category Labs a lansat lucrarea MonadBFT, care descrie mecanismul de consens care va alimenta Monad pe mainnet. MonadBFT este o dezvoltare semnificativă în cercetarea consensului, deoarece este prima dată când Pipelined HotStuff devine rezistent la furcarea cozii. Tail-forking-ul apare atunci când un slot ratat face ca propunerea anterioară să fie eliminată și reexploatată. Este o problemă gravă în formulările anterioare Pipelined HotStuff, deoarece deschide atacuri MEV multi-bloc care destabilizează consensul. Atenuarea acestei probleme este o afacere uriașă, deoarece ne oferă toate beneficiile Pipelined HotStuff - blocări frecvente, latență scăzută, seturi mari de validatoare - evitând în același timp cel mai mare dezavantaj. MonadBFT oferă, de asemenea, un upgrade uriaș pentru finalitate. Are finalitate speculativă cu un singur slot (500 ms) și finalitate hard cu două sloturi (1s). "Finalitate speculativă" înseamnă "finalitate care va reveni numai în caz de echivoc (dublă semnare) de către majoritatea validatorilor". Echivocul este o infracțiune majoră în majoritatea sistemelor blockchain și este de obicei penalizat cu tăiere; cu cât este mai mare pedeapsa pentru echivoc, cu atât te poți gândi la "finalitatea speculativă" mai aproape de finalitate. Finalitatea speculativă cu un slot este o deblocare uriașă pentru aplicațiile de înaltă performanță, care pot afișa cu încredere starea actualizată a lumii imediat după primirea următorului bloc. Aceste proprietăți fac din MonadBFT un progres uriaș în consens și o completare demnă a altor îmbunătățiri compuse din Monad, inclusiv execuția asincronă, execuția paralelă optimistă și MonadDb. Restul acestui articol servește ca un rezumat al modului în care îmbunătățirile succesive din HotStuff s-au construit una pe cealaltă, pentru a explica problema pe care MonadBFT o rezolvă. Pentru a rezuma: 1. HotStuff ne oferă complexitate de comunicare liniară, astfel încât să putem avea seturi mari de validatoare, dar nu este foarte eficient 2. Pipelined HotStuff ne oferă eficiență și latență scăzută de la propunerea de blocuri în fiecare slot, dar suferă de problema furcilor de coadă 3. MonadBFT ne oferă rezistență la furca cozii și finalitate speculativă cu un slot --- HotStuff: Complexitatea comunicării liniare permite un număr mare de noduri Algoritmii HotStuff se finalizează pe parcursul mai multor runde de comunicare, care iau în general forma unei comunicări direct de la lideri la validatori înapoi la lideri. Fiecare rundă începe cu liderul trimițând un mesaj direct altor validatori, care trimit fiecare înapoi un mesaj semnat care atestă că a primit mesajul. Cu condiția ca o supermajoritate (2/3) dintre validatori să trimită înapoi o atestare, fiecare rundă se încheie cu liderul agregând atestările semnate într-un certificat de cvorum (QC), care servește drept dovadă că supermajoritatea a atestat mesajul anterior. Algoritmii HotStuff au mai multe runde de comunicare ca aceasta. - Primul mesaj de la lider este o propunere de bloc - Al doilea mesaj este QC pentru acea propunere de blocare - Al treilea mesaj este un QC despre QC anterior (adică un QC-on-QC) - și așa mai departe Dacă procedura este întreruptă în orice moment înainte de finalizare, blocarea nu reușește să se finalizeze și este eliminată; Tranzacțiile din acel bloc vor trebui reincluse în următorul bloc. Protocolul original HotStuff nu are pipelining și are 3 runde de comunicare înainte de finalizare; Același validator joacă rolul de lider pentru fiecare rundă. --- Pipelined HotStuff: Un nou bloc în fiecare slot crește eficiența Pipelining este ceea ce facem cu toții intuitiv atunci când avem două încărcături de rufe de completat. În loc să așteptăm ca încărcătura 1 să termine ciclul complet înainte de a începe sarcina 2, în conducte punem sarcina 1 în uscător în același timp cu sarcina 2 în mașina de spălat. Vă puteți gândi la HotStuff original ca la acea abordare naivă a spălării rufelor (nu începeți cu încărcătura 2 până când încărcarea 1 nu este complet terminată), în timp ce Pipelined HotStuff face comportamentul intuitiv de a progresa mai multe încărcături de rufe într-un mod eșalonat. În Pipelined HotStuff eșalonăm propunerile, astfel încât să existe un nou bloc propus la fiecare rundă, cu noul bloc deasupra mesajului care poartă QC din blocul anterior. Propunerile de bloc mărșăluiesc spre finalitate pe parcursul mai multor runde. Beneficiile conductelor sunt semnificative. Pipelining crește densitatea propunerilor de bloc, deoarece o propunere de bloc este făcută în fiecare slot, ceea ce crește randamentul și scade timpul până la finalizare. Cu toate acestea, există un dezavantaj major al pipelining, care este cel mai bine ilustrat cu un exemplu. Să presupunem că liderii pentru blocurile N, N+1 și N+2 sunt Alice, Bob și Charlie. Dacă Bob își ratează locul, atunci și propunerea lui Alice va fi invalidată, deoarece mesajul lui Bob poartă atât propunerea lui, cât și un QC pentru propunerea lui Alice. Când se întâmplă acest lucru, Charlie ajunge să fie chemat să producă un bloc ca și cum propunerea lui Alice nu ar fi existat niciodată. Ne referim la acest comportament ca "tail-forking" și poate fi considerat ca o mini-reorganizare a adâncimii 1. Posibilitatea de bifurcare a cozii are consecințe semnificative, deoarece sloturile ratate nu sunt neapărat accidentale. Dacă există o oportunitate de a extrage valoare prin re-minarea blocului lui Alice în timp ce reordonează sau omite unele dintre tranzacții, atunci Bob și Charlie pot conspira pentru ca Bob să-și piardă intenționat slotul, declanșând o oportunitate pentru Charlie de a re-mina blocul lui Alice. Acesta a fost un dezavantaj semnificativ al protocoalelor Pipelined HotStuff (dintre care unele sunt astăzi în rețeaua principală). --- MonadBFT schimbă acest lucru MonadBFT este primul protocol care permite pipelining în timp ce face algoritmul rezistent la furca de coadă. Această rezistență la furca de coadă provine din procedura de rezervă atunci când Bob își ratează slotul, ceea ce permite validatorilor să-și pună cap la cap cunoștințele colective despre propunerea lui Alice și nivelul său de consens în cadrul setului de validatori. În special, sub MonadBFT, dacă Bob își ratează slotul, atunci procedura de rezervă face ca validatorii să comunice între ei cu atestări semnate care să precizeze dacă au văzut blocajul lui Alice. Dacă supermajoritatea atestă blocarea lui Alice, atunci Charlie este forțat să propună din nou blocarea lui Alice. Dacă Charlie dorește să propună un bloc diferit, atunci trebuie să furnizeze o atestare semnată de majoritatea validatorilor care să ateste că nu a văzut blocarea lui Alice la timp. În cazul tipic în care Charlie propune din nou blocajul lui Alice, el ajunge apoi să-și propună blocul în runda următoare. Rezultatul este două proprietăți importante: rezistența la furcarea cozii și finalitatea speculativă a unui singur slot. Am vorbit deja despre rezistența la furcarea cozii, dar să înțelegem impactul asupra finalității. Ca și înainte, să presupunem că liderii pentru blocurile N, N+1 și N+2 sunt Alice, Bob și Charlie. Sub Pipelined 2-Phase HotStuff - adică înainte de MonadBFT - ca validator (sau un nod complet), nu puteți finaliza propunerea de bloc a lui Alice până când nu vedeți propunerea de bloc a lui Charlie. De ce? Pentru că dacă finalizezi imediat ce vezi propunerea lui Bob, este posibil ca Bob să se încurce cu tine DOAR trimițându-ți propunerea și de fapt plănuiește să nu trimită propunerea tuturor celorlalți, ratând astfel slotul său. Dar în MonadBFT, de îndată ce vezi propunerea lui Bob, poți finaliza "speculativ" propunerea lui Alice, deoarece propunerea lui Bob include un QC asupra propunerii lui Alice, ceea ce este dovada că 2/3 din rețea a atestat propunerea lui Alice. Chiar dacă Bob se încurcă cu tine DOAR trimițându-ți propunerea și va sfârși prin a-și pierde locul, știi că o supermajoritate a rețelei a văzut propunerea lui Alice și, atunci când vor participa la procedura de rezervă, vor semna din nou propunerea lui Alice. Singurul mod în care blocarea lui Alice nu va fi finalizată este dacă validatorii se echivocează și semnează spunând că nu au văzut mesajul lui Alice. Această eroare este ușor de dovedit - am semnat mesaje contradictorii de la ei. Dacă pedeapsa pentru echivoc este substanțială - și ar trebui să fie - această finalitate "speculativă" nu este de fapt atât de speculativă. --- Concluzii MonadBFT este o dezvoltare extrem de interesantă pentru consens și este o completare demnă a altor îmbunătățiri compuse din Monad, inclusiv execuția asincronă, execuția paralelă optimistă și MonadDb. Felicitări imense @MohammadMJalal1 și @KushalBabel pentru această descoperire semnificativă. MonadBFT va fi implementat în curând pe Monad Testnet, care implementează în prezent Pipelined 2-Phase HotStuff. Pentru lecturi suplimentare, consultați postarea de blog și lucrarea legată în următorul tweet.