Summering av genombrottet i MonadBFT Igår släppte Category Labs artikeln MonadBFT, som beskriver den konsensusmekanism som kommer att driva Monad på mainnet. MonadBFT är en viktig utveckling inom konsensusforskning eftersom det är första gången som Pipelined HotStuff blir resistent mot tail-forking. Tail-forking inträffar när en missad plats gör att det tidigare förslaget kasseras och bryts på nytt. Det är ett allvarligt problem i tidigare Pipelined HotStuff-formuleringar eftersom det öppnar upp för MEV-attacker med flera block som destabiliserar konsensus. Att lindra detta problem är en stor sak eftersom det ger oss alla fördelar med Pipelined HotStuff - frekventa block, låg latens, stora valideringsuppsättningar - samtidigt som vi undviker den största nackdelen. MonadBFT erbjuder också en enorm uppgradering för slutgiltighet. Den har en enda plats (500 ms) spekulativ slutgiltighet och två fack (1s) hård slutgiltighet. "Spekulativ slutgiltighet" betyder "slutgiltighet som endast kommer att återgå i händelse av tvetydighet (dubbelsignering) av en majoritet av validerarna". Tvetydighet är ett stort brott i de flesta blockkedjesystem och straffas vanligtvis med slashing; Ju större straffet för tvetydighet är, desto närmare kan du tänka dig "spekulativ slutgiltighet" till slutgiltighet. One-slot speculative finality är en enorm upplåsning för högpresterande applikationer, som med säkerhet kan visa det uppdaterade tillståndet i världen omedelbart efter att nästa block har tagits emot. Dessa egenskaper gör MonadBFT till ett stort framsteg inom konsensus och ett värdigt komplement till andra sammansatta förbättringar i Monad, inklusive Asynchronous Execution, Optimistic Parallel Execution och MonadDb. Resten av den här artikeln fungerar som en sammanfattning av hur successiva förbättringar i HotStuff har byggt på varandra, för att förklara problemet som MonadBFT löser. För att sammanfatta: 1. HotStuff ger oss linjär kommunikationskomplexitet så att vi kan ha stora valideringsuppsättningar, men det är inte särskilt effektivt 2. Pipelined HotStuff ger oss effektivitet och låg latens från att föreslå block varje plats, men lider av problemet med svansgafflar 3. MonadBFT ger oss motstånd mot bakgaffeln och spekulativ slutgiltighet i ett fack --- HotStuff: Linjär kommunikationskomplexitet möjliggör stort antal noder HotStuffs algoritmer slutförs under flera kommunikationsrundor, som i allmänhet tar formen av "fläkt ut, fläkt in"-kommunikation direkt från ledare till validerare tillbaka till ledare. Varje omgång börjar med att ledaren skickar ett meddelande direkt till andra validerare, som var och en skickar tillbaka ett signerat meddelande som intygar att de har tagit emot meddelandet. Förutsatt att en supermajoritet (2/3) av validerarna skickar tillbaka ett intyg, avslutas varje omgång med att ledaren sammanställer de undertecknade intygen till ett kvorumcertifikat (QC), som fungerar som bevis på att supermajoriteten intygade det tidigare meddelandet. HotStuff-algoritmer har flera kommunikationsrundor som denna. - Det första meddelandet från ledaren är ett blockförslag - Det andra meddelandet är QC för det blockförslaget - Det tredje meddelandet är en QC om den tidigare QC (dvs. en QC-on-QC) - och så vidare Om proceduren avbryts när som helst innan den är slutgiltig, misslyckas blocket att slutföras och kasseras; Transaktioner från det blocket måste inkluderas på nytt i nästa block. Det ursprungliga HotStuff-protokollet har ingen pipelining och har 3 kommunikationsrundor innan det är slutgiltigt; Samma validerare spelar rollen som ledare för varje omgång. --- Pipelined HotStuff: Ett nytt block varje plats ökar effektiviteten Pipelining är vad vi alla gör intuitivt när vi har två tvättar att slutföra. Istället för att vänta på att last 1 ska avsluta hela cykeln innan vi startar last 2, lägger vi vid pipelining last 1 i torktumlaren samtidigt som last 2 går in i tvättmaskinen. Du kan tänka på det ursprungliga HotStuff som det naiva sättet att tvätta (börja inte på last 2 förrän last 1 är helt klar), medan Pipelined HotStuff gör det intuitiva beteendet att utveckla flera tvättlaster på ett förskjutet sätt. I Pipelined HotStuff sprider vi ut förslagen, så att det finns ett nytt block som föreslås vid varje omgång, med det nya blocket piggybacking ovanpå meddelandet som bär QC från det föregående blocket. Blockförslag marscherar mot slutgiltighet under loppet av flera omgångar. Fördelarna med pipelining är betydande. Pipelining ökar densiteten i blockförslagen, eftersom ett blockförslag görs i varje fack, vilket ökar genomströmningen och minskar tiden till slut. Det finns dock en stor nackdel med pipelining, som bäst illustreras med ett exempel. Anta att ledarna för block N, N+1 och N+2 är Alice, Bob och Charlie. Om Bob missar sin plats kommer Alices förslag också att ogiltigförklaras, eftersom Bobs meddelande innehåller både hans förslag och en QC för Alices förslag. När detta händer slutar det med att Charlie uppmanas att producera ett block som om Alices förslag aldrig hade funnits. Vi kallar det här beteendet för "tail-forking", och det kan ses som en mini-reorg av djup 1. Risken för svansförgrening har betydande konsekvenser, eftersom missade slots inte nödvändigtvis är av misstag. Om det finns en möjlighet att utvinna värde genom att bryta Alices block igen samtidigt som de ordnar om eller utelämnar några av transaktionerna, kan Bob och Charlie konspirera för att Bob avsiktligt ska missa sin plats, vilket utlöser en möjlighet för Charlie att bryta Alices block igen. Detta har varit en betydande nackdel med Pipelined HotStuff-protokoll (av vilka några finns i mainnet idag). --- MonadBFT ändrar på detta MonadBFT är det första protokollet som möjliggör pipelining samtidigt som algoritmen är resistent mot bakgaffeln. Detta resistens mot stjärtgaffeln kommer från reservproceduren när Bob missar sin plats, vilket gör det möjligt för validerare att pussla ihop sin samlade kunskap om Alices förslag och dess nivå av konsensus inom validatoruppsättningen. I synnerhet, enligt MonadBFT, om Bob missar sin plats, har reservproceduren att validerare kommunicerar med varandra med undertecknade intyg som anger om de såg Alices block. Om supermajoriteten intygar Alices blockering är Charlie tvungen att föreslå Alices blockering på nytt. Om Charlie vill föreslå ett annat block måste han tillhandahålla ett undertecknat intyg från majoriteten av validerarna som intygar att han inte såg Alices block i tid. I det typiska fallet där Charlie föreslår Alices block igen, får han sedan föreslå sitt block i den efterföljande omgången. Resultatet är två viktiga egenskaper: motstånd mot bakgaffel och spekulativ slutgiltighet i ett spår. Vi har redan talat om motstånd mot svansförgrening, men låt oss förstå effekten på slutgiltigheten. Som tidigare antar du att ledarna för block N, N+1 och N+2 är Alice, Bob och Charlie. Under Pipelined 2-Phase HotStuff - dvs. före MonadBFT - som en validerare (eller en fullständig nod), kan du inte slutföra Alices blockförslag förrän du ser Charlies blockförslag. Varför? För om du slutför så fort du ser Bobs förslag, är det möjligt att Bob med dig genom att BARA vidarebefordra sitt förslag till dig, och han planerar faktiskt att misslyckas med att skicka sitt förslag till alla andra, och därmed missa sin plats. Men i MonadBFT, så snart du ser Bobs förslag, kan du "spekulativt" slutföra Alices förslag eftersom Bobs förslag inkluderar en QC på Alices förslag, vilket är ett bevis på att 2/3 av nätverket intygade Alices förslag. Även om Bob med dig genom att BARA vidarebefordra sitt förslag till dig, och det kommer att sluta med att han missar sin plats, vet du att en supermajoritet av nätverket såg Alices förslag och, när de deltar i reservförfarandet, kommer att underteckna Alices förslag igen. Det enda sättet som Alices blockering inte kommer att slutföras är om validerarna tvetydigar och signerar och säger att de inte såg Alices meddelande. Detta fel är lätt att bevisa - vi har signerat motstridiga meddelanden från dem. Om straffet för tvetydighet är betydande - och det bör det vara - är denna "spekulativa" slutgiltighet i själva verket inte så spekulativ. --- Lärdomar MonadBFT är en extremt spännande utveckling för konsensus, och är ett värdigt komplement till andra sammansatta förbättringar i Monad, inklusive Asynchronous Execution, Optimistic Parallel Execution och MonadDb. Stort grattis till @MohammadMJalal1 och @KushalBabel för detta betydande genombrott. MonadBFT kommer inom kort att implementeras på Monad Testnet, som för närvarande implementerar Pipelined 2-Phase HotStuff. För vidare läsning, se det länkade blogginlägget och artikeln i nästa tweet.