Hvordan skalerer Monad EVM samtidig som desentraliseringen opprettholdes? MonadBFT er konsensusalgoritmen som brukes i Monad, det er den første halegaffelresistente implementeringen av Hotstuff (wtf betyr det?) Slik kan MonadBFT skaleres til 1000-vis av validatorer mens de er ytende 🧵

1/7 konsensusmekanismer Mekanismen blokkjeder bruker for å sikre at nye blokker blir enige om av et flertall av validatorer. Konsensusalgoritmer er så langt ikke i stand til å skalere utover noen få hundre validatorer siden kompleksiteten øker basert på kvadratet av antall validatorer (i de fleste tilfeller) Siden hver validator snakker med alle andre validatorer for å bli enige om blokkene: n validatorer x n meldinger = n-kvadrat meldinger. Derfor øker kompleksiteten betydelig med antall validatorer.

2/7 Hotstuff er en konsensusalgoritme som kan skalere lineært (direkte proporsjonalt med antall validatorer) ved å unngå alt-til-alle-meldingene og la en enkelt "leder" kommunisere med alle validatorer for konsensus. Dermed kan Hotstuff skalere mer effektivt enn tradisjonell PBFT-konsensus, men den er sårbar for tailforking-angrep. MonadBFT er den første halegaffelbestandige implementeringen av Hotstuff.

3/7 Hva er tailforking? Tailforking skjer når den neste lederen (validatoren som foreslår den neste blokken), med vilje eller ved et uhell unnlater å inkludere QC-en til den forrige lederens gyldige blokk i sitt forslag til den nye blokken. (QC står for quorum certificate som er et bevis på at alle validatorer har blitt enige om den forrige blokken) Som et resultat blir den forrige blokken, til tross for at den er gyldig og har flertallsstøtte, stående uforpliktet og til slutt foreldreløs eller erstattet av en annen blokk i samme høyde. Dette forstyrrer insentivmekanismen: ærlige forslagsstillere kan ikke motta blokkbelønninger eller gebyrer hvis blokkeringen deres hoppes over, noe som oppmuntrer til urettferdig oppførsel og svekker sikkerheten til nettverket.

4/7 Hvordan fungerer MonadBFT? → En leder (Alice) sender et signert blokkforslag til alle andre noder (fan out), som bekrefter gyldigheten ved å sende en signert attestasjon til neste leder Bob (fan in). → Bob samler attestene til et "Quorum Certificate" (QC) → Bob kringkaster QC til alle nodene, som bekrefter å ha mottatt den ved å sende en melding til den tredje lederen (Charlie) som samler disse attestene. Siden attestene handler om en QC, kaller vi denne nye QC-en en QC-on-QC. → Charlie sender QC-on-QC til alle. Etter å ha mottatt QC-on-QC, vet alle at Alices blokkering er ferdigstilt.

5/7 Rørforing I historien ovenfor sender Bob og Charlie bare ut QC-er eller QC-er-på-QC-er, men i virkeligheten er forslagene pipeline: Bobs melding inneholder både QC-en for Alices blokk og også innholdet i en ny blokk. Charlies melding inneholder QC for Bobs blokk (som er en QC-on-QC for Alices blokk) og inneholder også transaksjonene for en ny blokk. Når validatorer sender en attestasjon for Bobs melding, bekrefter de både gyldigheten av Bobs blokkering og gyldigheten av QC. Denne pipeliningen øker gjennomstrømningen til nettverket siden hver spor en ny blokk blir produsert.

6/7 Raptorcast: Monads blokkpropogasjonsprotokoll MonadBFT krever at lederen sender blokkforslag til hver validator. Blokkene kan imidlertid være ganske store: 10 000 transaksjoner/s * 200 byte/tx = 2 MB/s. Å sende direkte til 200 validatorer vil kreve 400 MB/s. Ideelt sett bør validatorer ikke ha så høy opplastingsbåndbredde. Det er her Raptorcast kommer inn. → Blokker er slettekodet av lederen (slettingskoding betyr at meldingen er delt inn i et sett med biter, og den kan dekodes fra et stort nok delsett av disse bitene) → Lederen distribuerer et annet sett med biter til alle validatorene i nettverket (validatorer med høyere innsats mottar proporsjonalt mer) → Hver validator sender bitene sine på nytt til alle andre validatorer i nettverket På denne måten brukes hele båndbredden til nettverket til å spre blokkforslag.