Hur skalar Monad upp EVM samtidigt som decentraliseringen bevaras? MonadBFT är konsensusalgoritmen som används i Monad, det är den första tailfork-resistenta implementationen av Hotstuff (wtf betyder det?) Så här kan MonadBFT skalas till 1000-tals validerare samtidigt som det är högpresterande 🧵

1/7 Mekanismer för konsensus Mekanismen som blockkedjor använder för att se till att nya block godkänns av en majoritet av validerarna. Konsensusalgoritmer har hittills inte kunnat skalas längre än några hundra validerare eftersom komplexiteten ökar baserat på kvadraten på antalet validerare (i de flesta fall) Eftersom varje validerare pratar med alla andra validerare för att komma överens om blocken: n validerare x n meddelanden = n-kvadrat meddelanden. Därför ökar komplexiteten avsevärt med antalet validerare.

2/7 Hotstuff är en konsensusalgoritm som kan skalas linjärt (direkt proportionellt mot antalet validerare) genom att undvika allt-till-alla-meddelanden och tillåta en enda "ledare" att kommunicera med alla validerare för konsensus. Således kan Hotstuff skala mer effektivt än traditionell PBFT-konsensus, men det är sårbart för tailforking-attacker. MonadBFT är den första bakgaffelresistenta implementeringen av Hotstuff.

3/7 Vad är tailforking? Tailforking sker när nästa ledare (validerare som föreslår nästa block), avsiktligt eller oavsiktligt misslyckas med att inkludera QC för den föregående ledarens giltiga block i sitt förslag för det nya blocket. (QC står för quorum certificate som är ett bevis på att alla validerare har kommit överens om det tidigare blocket) Som ett resultat av detta lämnas det tidigare blocket, trots att det är giltigt och har majoritetsstöd, oengagerat och blir så småningom övergivet eller ersatt av ett annat block på samma höjd. Detta stör incitamentsmekanismen: ärliga förslagsställare kanske inte får blockbelöningar eller avgifter om deras blockering hoppas över, vilket uppmuntrar till orättvist beteende och försvagar nätverkets säkerhet.

4/7 Hur fungerar MonadBFT? → En ledare (Alice) sänder ett signerat blockförslag till alla andra noder (ut), som bekräftar dess giltighet genom att skicka ett undertecknat intyg till nästa ledare Bob (in). → Bob sammanställer attesteringarna till ett "kvorumcertifikat" (QC) → Bob sänder QC till alla noder, som intygar att de tar emot den genom att skicka ett meddelande till den 3:e ledaren (Charlie) som sammanställer dessa intyg. Eftersom attesteringarna handlar om en QC kallar vi denna nya QC för en QC-on-QC. → Charlie skickar QC-on-QC till alla. När de får QC-on-QC vet alla att Alices block har slutförts.

5/7 Rörläggning I historien ovan skickar Bob och Charlie bara ut QC:er eller QC:er på QC:er, men i verkligheten är förslagen pipelines: Bobs meddelande innehåller både QC för Alices block och även innehållet i ett nytt block. Charlies meddelande innehåller QC för Bobs block (som är en QC-on-QC för Alices block) och innehåller även transaktionerna för ett nytt block. När validerare skickar ett intyg för Bobs meddelande intygar de både giltigheten av Bobs block och giltigheten av QC. Denna pipelining ökar genomströmningen i nätverket eftersom varje plats ett nytt block produceras.

6/7 Raptorcast: Monads protokoll för blockförökning MonadBFT kräver att ledaren skickar blockförslag till varje validerare. Blocken kan dock vara ganska stora: 10 000 transaktioner/s * 200 byte/tx = 2 MB/s. Att skicka direkt till 200 validerare skulle kräva 400 MB/s. Helst bör validerare inte ha så hög uppladdningsbandbredd. Det är här Raptorcast kommer in. → Block är raderingskodade av ledaren (raderingskodning innebär att meddelandet delas upp i en uppsättning bitar, och det kan avkodas från en tillräckligt stor delmängd av dessa bitar) → Ledaren delar ut en annan uppsättning delar till alla validerare i nätverket (validerare med högre insatser får proportionellt mer) → Varje validerare sänder sina delar till alla andra validerare i nätverket På så sätt används hela nätverkets bandbredd för att sprida blockförslag.