Miten Monad skaalaa EVM:ää säilyttäen hajauttamisen? MonadBFT on Monadissa käytetty konsensusalgoritmi, se on Hotstuffin ensimmäinen takahaarukan kestävä toteutus (mitä se tarkoittaa?) Näin MonadBFT voi skaalautua 1000 validoijaan ja olla suorituskykyinen 🧵

1/7 Konsensusmekanismit Mekanismi, jota lohkoketjut käyttävät varmistaakseen, että suurin osa validoijista hyväksyy uudet lohkot. Konsensusalgoritmit eivät toistaiseksi pysty skaalautumaan muutamaa sataa validoijaa pidemmälle, koska monimutkaisuus kasvaa validoijien lukumäärän neliön perusteella (useimmissa tapauksissa) Koska jokainen validoija keskustelee kaikkien muiden validoijien kanssa sopiakseen lohkoista: n validaattoria x n viestiä = n-neliön viestiä. Siksi monimutkaisuus kasvaa merkittävästi validoijien määrän myötä.

2/7 Hotstuff on konsensusalgoritmi, joka voi skaalautua lineaarisesti (suoraan verrannollinen validoijien määrään) välttämällä all-to-all-viestejä ja sallimalla yhden "johtajan" kommunikoida kaikkien validoijien kanssa konsensuksen saavuttamiseksi. Näin ollen Hotstuff voi skaalautua tehokkaammin kuin perinteinen PBFT-konsensus, mutta se on altis takahaarukkahyökkäyksille. MonadBFT on Hotstuffin ensimmäinen takahaarukan kestävä toteutus.

3/7 Mikä on tailforking? Tailforking tapahtuu, kun seuraava johtaja (seuraavaa lohkoa ehdottava validoija) jättää tahallaan tai vahingossa sisällyttämättä edellisen johtajan kelvollisen lohkon QC:tä ehdotukseensa uudesta lohkosta. (QC on lyhenne sanoista quorum certificate, joka on todiste siitä, että kaikki validoijat ovat sopineet edellisestä lohkosta) Tämän seurauksena edellinen lohko, vaikka se oli voimassa ja sillä on enemmistön tuki, jätetään sitomatta ja lopulta jää orvoksi tai korvataan toisella lohkolla samalla korkeudella. Tämä häiritsee kannustinmekanismia: rehelliset ehdottajat eivät välttämättä saa lohkopalkkioita tai palkkioita, jos heidän estonsa ohitetaan, mikä kannustaa epäreiluun käytökseen ja heikentää verkon turvallisuutta.

4/7 Miten MonadBFT toimii? → Johtaja (Alice) lähettää allekirjoitetun lohkoehdotuksen kaikille muille solmuille (tuulettimelle), jotka vahvistavat sen pätevyyden lähettämällä allekirjoitetun todistuksen seuraavalle johtajalle Bobille (tuuletin sisään). → Bob kokoaa todistukset koorumitodistukseksi (QC) → Bob lähettää QC:n kaikille solmuille, jotka todistavat vastaanottaneensa sen lähettämällä viestin 3. johtajalle (Charlie), joka kokoaa nämä todistukset. Koska todistukset koskevat laadunvalvontaa, kutsumme tätä uutta laadunvalvontaa QC-on-QC:ksi. → Charlie lähettää QC-on-QC:n kaikille. Saatuaan QC-on-QC:n kaikki tietävät, että Alicen lohko on viimeistelty.

5/7 Putkilinjaus Yllä olevassa tarinassa Bob ja Charlie lähettävät vain QC:itä tai QC:itä QC:lle, mutta todellisuudessa ehdotukset ovat putkissa: Bobin viesti sisältää sekä Alicen lohkon QC:n että uuden lohkon sisällön. Charlien viesti sisältää Bobin lohkon QC:n (joka on QC-on-QC Alicen lohkolle) ja sisältää myös uuden lohkon tapahtumat. Kun validoijat lähettävät todistuksen Bobin viestistä, he todistavat sekä Bobin lohkon että QC:n pätevyyden. Tämä putkilinjaus lisää verkon suorituskykyä, koska jokaisessa paikassa tuotetaan uusi lohko.

6/7 Raptorcast: Monadin lohkojen levittämisprotokolla MonadBFT edellyttää, että johtaja lähettää lohkoehdotukset jokaiselle validoijalle. Lohkot voivat kuitenkin olla melko suuria: 10 000 transaktiota/s * 200 tavua/tx = 2 Mt/s. Lähettäminen suoraan 200 validoijalle vaatisi 400 Mt/s. Ihannetapauksessa validoijilla ei pitäisi olla näin suurta latauskaistanleveyttä. Tässä Raptorcast tulee kuvaan. → Lohkot poistetaan johtajan toimesta (Poistokoodaus tarkoittaa, että viesti jaetaan lohkoihin, ja se voidaan purkaa riittävän suuresta osajoukosta näistä paloista) → Johtaja jakaa erilaisen joukon paloja kaikille verkoston validoijille (korkeamman panoksen validoijat saavat suhteellisesti enemmän) → Kukin validoija lähettää palansa uudelleen kaikille muille verkon validoijille Tällä tavalla verkon koko kaistanleveyttä käytetään lohkoehdotusten levittämiseen.