Monad-konsensusklienten er nå åpen kildekode (lenke nedenfor). Dette er resultatet av tusenvis av timer med innsats fra teamet på @category_xyz. Nyte

Oppsummerer gjennombruddet i MonadBFT I går ga Category Labs ut MonadBFT-artikkelen, som beskriver konsensusmekanismen som vil drive Monad på hovednettet. MonadBFT er en betydelig utvikling innen konsensusforskning siden det er første gang Pipelined HotStuff blir motstandsdyktig mot haleforking. Haleforking oppstår når et tapt spor fører til at det forrige forslaget blir forkastet og minert på nytt. Det er et alvorlig problem i tidligere Pipelined HotStuff-formuleringer siden det åpner for MEV-angrep med flere blokker som destabiliserer konsensus. Å lindre dette problemet er en stor sak fordi det gir oss alle fordelene med Pipelined HotStuff - hyppige blokkeringer, lav ventetid, store validatorsett - samtidig som vi unngår den største ulempen. MonadBFT tilbyr også en enorm oppgradering for finalitet. Den har enkeltspor (500 ms) spekulativ finalitet og to-spor (1s) hard finalitet. «Spekulativ endelighet» betyr «endelighet som bare vil gå tilbake i tilfelle tvetydighet (dobbeltsignering) av et flertall av validatorer». Tvetydighet er et stort lovbrudd i de fleste blokkjedesystemer og straffes ofte med slashing; Jo større straffen for tvetydighet er, jo nærmere kan du tenke på «spekulativ endelighet» til endelighet. En spilleautomat spekulativ finalitet er en enorm opplåsing for høyytelsesapplikasjoner, som trygt kan vise den oppdaterte tilstanden til verden umiddelbart etter at neste blokk er mottatt. Disse egenskapene gjør MonadBFT til et stort fremskritt i konsensus, og et verdig supplement til andre sammensatte forbedringer i Monad, inkludert asynkron utførelse, optimistisk parallell utførelse og MonadDb. Resten av denne artikkelen fungerer som en oppsummering av hvordan påfølgende forbedringer i HotStuff har bygget på hverandre, for å forklare problemet som MonadBFT løser. For å oppsummere: 1. HotStuff gir oss lineær kommunikasjonskompleksitet slik at vi kan ha store validatorsett, men det er ikke veldig effektivt 2. Pipelined HotStuff gir oss effektivitet og lav ventetid fra å foreslå blokker hvert spor, men lider av problemet med halegafler 3. MonadBFT gir oss gir oss halegaffelmotstand og spekulativ finalitet med ett spor --- HotStuff: Lineær kommunikasjonskompleksitet muliggjør store nodetall HotStuff-algoritmer fullføres i løpet av flere kommunikasjonsrunder, som vanligvis tar form av "fan ut, vifte inn"-kommunikasjon direkte fra ledere til validatorer tilbake til ledere. Hver runde begynner med at lederen sender en melding direkte til andre validatorer, som hver sender tilbake en signert melding som bekrefter at de har mottatt meldingen. Forutsatt at et superflertall (2/3) av validatorene sender tilbake en attestering, avsluttes hver runde med at lederen samler de signerte attestene til et quorumssertifikat (QC), som fungerer som bevis på at superflertallet bekreftet den forrige meldingen. HotStuff-algoritmer har flere kommunikasjonsrunder som dette. - Den første meldingen fra lederen er et blokkforslag - Den andre meldingen er QC for det blokkeringsforslaget - Den tredje meldingen er en QC om forrige QC (dvs. en QC-on-QC) - og så videre Hvis prosedyren avbrytes når som helst før endelighet, klarer ikke blokken å fullføres og forkastes; Transaksjoner fra den blokken må inkluderes på nytt i neste blokk. Den originale HotStuff-protokollen har ingen pipelining og har 3 runder med kommunikasjon før finalitet; Den samme validatoren spiller rollen som leder for hver runde. --- Pipelined HotStuff: En ny blokk hver plass øker effektiviteten Pipelining er det vi alle gjør intuitivt når vi har to lass med klesvask å fullføre. I stedet for å vente på at last 1 skal fullføre hele syklusen før vi starter last 2, legger vi i rørforing last 1 i tørketrommelen samtidig som last 2 går i vaskemaskinen. Du kan tenke på den originale HotStuff som den naive tilnærmingen til å vaske klær (ikke start på last 2 før last 1 er helt ferdig), mens Pipelined HotStuff gjør den intuitive oppførselen til å utvikle flere klesvasker på en forskjøvet måte. I Pipelined HotStuff forskyver vi forslag, slik at det er en ny blokk foreslått i hver runde, med den nye blokken piggybacking på toppen av meldingen som bærer QC fra forrige blokk. Blokkforslag marsjerer mot endelighet i løpet av flere runder. Fordelene med pipelining er betydelige. Pipelining øker tettheten av blokkforslag, siden det lages et blokkforslag i hvert spor, noe som øker gjennomstrømningen og senker tiden til slutt. Det er imidlertid en stor ulempe med pipelining, som best illustreres med et eksempel. Anta at lederne for blokkene N, N+1 og N+2 er Alice, Bob og Charlie. Hvis Bob bommer på plassen sin, vil Alices forslag også bli ugyldiggjort, fordi Bobs melding inneholder både hans forslag og en QC for Alices forslag. Når dette skjer, ender Charlie opp med å bli bedt om å produsere en blokk som om Alices frieri aldri hadde eksistert. Vi refererer til denne oppførselen som "hale-forking", og det kan betraktes som en mini-reorg av dybde 1. Muligheten for hale-gaffling har betydelige konsekvenser, fordi tapte spor ikke nødvendigvis er ved et uhell. Hvis det er en mulighet til å utvinne verdi ved å utvinne Alices blokk på nytt mens du omorganiserer eller utelater noen av transaksjonene, kan Bob og Charlie samarbeide for å få Bob til å bomme på plassen sin med vilje, noe som utløser en mulighet for Charlie til å utvinne Alices blokk på nytt. Dette har vært en betydelig ulempe med Pipelined HotStuff-protokoller (hvorav noen er i mainnet i dag). --- MonadBFT endrer dette MonadBFT er den første protokollen som muliggjør pipelining samtidig som algoritmen blir halegaffelbestandig. Denne halegaffelmotstanden kommer fra reserveprosedyren når Bob bommer på plassen sin, noe som gjør det mulig for validatorer å sette sammen sin kollektive kunnskap om Alices forslag og dets konsensusnivå i validatorsettet. Spesielt under MonadBFT, hvis Bob bommer på plassen sin, får reserveprosedyren validatorer til å kommunisere med hverandre med signerte attester som sier om de så Alices blokkering. Hvis superflertallet bekrefter Alices blokkering, blir Charlie tvunget til å foreslå Alices blokkering på nytt. Hvis Charlie ønsker å foreslå en annen blokkering, må han gi en signert attest fra flertallet av validatorene som bekrefter at han ikke så Alices blokk i tide. I det typiske tilfellet der Charlie foreslår Alices blokk på nytt, får han deretter foreslå blokken sin i den påfølgende runden. Resultatet er to viktige egenskaper: hale-gafflingsmotstand og spekulativ enkeltspor-finalitet. Vi har allerede snakket om motstand mot haleforking, men la oss forstå virkningen på endeligheten. Som før, anta at lederne for blokkene N, N+1 og N+2 er Alice, Bob og Charlie. Under Pipelined 2-Phase HotStuff - det vil si før MonadBFT - som en validator (eller en full node), kan du ikke fullføre Alices blokkforslag før du ser Charlies blokkeringsforslag. Hvorfor? For hvis du fullfører så snart du ser Bobs forslag, er det mulig at Bob roter med deg ved BARE å videresende forslaget sitt til deg, og han planlegger faktisk å mislykkes i å sende forslaget sitt til alle andre, og dermed gå glipp av plassen sin. Men i MonadBFT, så snart du ser Bobs forslag, kan du "spekulativt" fullføre Alices forslag fordi Bobs forslag inkluderer en QC på Alices forslag, som er bevis på at 2/3 av nettverket bekreftet Alices forslag. Selv om Bob roter med deg ved BARE å videresende forslaget sitt til deg, og kommer til å ende opp med å gå glipp av plassen sin, vet du at et overveldende flertall av nettverket så Alices frieri, og når de deltar i reserveprosedyren, vil de signere Alices forslag igjen. Den eneste måten Alices blokkering ikke blir fullført på, er hvis validatorene tvetydige og signerer og sier at de ikke så Alices melding. Denne feilen er lett å bevise - vi har signert motstridende meldinger fra dem. Hvis straffen for tvetydighet er betydelig - og det burde den være - er denne "spekulative" finaliteten egentlig ikke så spekulativ. --- Takeaways MonadBFT er en ekstremt spennende utvikling for konsensus, og er et verdig supplement til andre sammensatte forbedringer i Monad, inkludert asynkron utførelse, optimistisk parallell utførelse og MonadDb. Stor gratulasjon til @MohammadMJalal1 og @KushalBabel med dette betydelige gjennombruddet. MonadBFT vil snart bli implementert på Monad Testnet, som for tiden implementerer Pipelined 2-Phase HotStuff. For videre lesing, se det lenkede blogginnlegget og artikkelen i neste tweet.

Les gjerne dette vanvittig gode blogginnlegget fra @category_xyz om RaptorCast - muliggjør effektiv kringkasting av store blokker samtidig som feiltoleransen opprettholdes samtidig som det minimerer krav til båndbredde Du vil lære mye!