Yhteenveto MonadBFT:n läpimurrosta Eilen Category Labs julkaisi MonadBFT-paperin, jossa kuvataan konsensusmekanismia, joka toimii Monadin pääverkossa. MonadBFT on merkittävä edistysaskel konsensustutkimuksessa, koska se on ensimmäinen kerta, kun Pipelined HotStuff tulee vastustuskykyiseksi häntähaarukkaa vastaan. Hännän haarautuminen tapahtuu, kun menetetty paikka aiheuttaa edellisen ehdotuksen hylkäämisen ja uudelleen louhimisen. Se on vakava ongelma aiemmissa Pipelined HotStuff -koostumuksissa, koska se avaa monilohkoisia MEV-hyökkäyksiä, jotka horjuttavat konsensusta. Tämän ongelman lievittäminen on valtava juttu, koska se antaa meille kaikki Pipelined HotStuffin edut - toistuvat lohkot, alhainen latenssi, suuret validointisarjat - välttäen samalla suurimmat haitat. MonadBFT tarjoaa myös valtavan päivityksen lopullisuuteen. Siinä on yhden paikan (500 ms) spekulatiivinen lopullisuus ja kahden paikan (1s) kova lopullisuus. "Spekulatiivinen lopullisuus" tarkoittaa "lopullisuutta, joka palautuu vain, jos validoijien enemmistö tekee epäselvyyden (kaksoisallekirjoituksen)". Epäselvyys on suuri rikos useimmissa lohkoketjujärjestelmissä, ja siitä rangaistaan yleisesti viiltohaavalla; Mitä suurempi rangaistus epäselvyydestä on, sitä lähempänä "spekulatiivista lopullisuutta" voi ajatella. Yhden paikan spekulatiivinen lopullisuus on valtava avaus tehokkaille sovelluksille, jotka voivat luottavaisesti näyttää päivitetyn maailman tilan heti seuraavan lohkon vastaanottamisen jälkeen. Nämä ominaisuudet tekevät MonadBFT:stä valtavan edistysaskeleen konsensuksessa ja arvokkaan täydennyksen muille Monadin yhdistelmäparannuksille, mukaan lukien Asynchronous Execution, Optimistic Parallel Execution ja MonadDb. Tämän artikkelin loppuosa toimii yhteenvetona siitä, kuinka HotStuffin peräkkäiset parannukset ovat rakentuneet toistensa päälle, selittääkseen MonadBFT:n ratkaiseman ongelman. Yhteenvetona: 1. HotStuff antaa meille lineaarisen viestinnän monimutkaisuuden, jotta meillä voi olla suuria validointisarjoja, mutta se ei ole kovin tehokasta 2. Pipelined HotStuff antaa meille tehokkuutta ja alhaisen latenssin ehdottamalla lohkoja jokaiseen paikkaan, mutta kärsii häntähaarukoiden ongelmasta 3. MonadBFT antaa meille häntähaarukan vastuksen ja yhden paikan spekulatiivisen lopullisuuden --- HotStuff: Lineaarisen tiedonsiirron monimutkaisuus mahdollistaa suuret solmumäärät HotStuff-algoritmit valmistuvat useiden viestintäkierrosten aikana, jotka yleensä tapahtuvat "fan out, fan in" -viestinnässä suoraan johtajilta validoijille takaisin johtajille. Jokainen kierros alkaa sillä, että johtaja lähettää viestin suoraan muille validoijille, jotka lähettävät takaisin allekirjoitetun viestin, joka todistaa vastaanottaneensa viestin. Edellyttäen, että ylivoimainen enemmistö (2/3) validoijista lähettää takaisin todistuksen, jokainen kierros päättyy siihen, että johtaja kokoaa allekirjoitetut todistukset koorumitodistukseksi (QC), joka toimii todisteena siitä, että ylivoimainen enemmistö on vahvistanut edellisen viestin. HotStuff-algoritmeilla on useita tällaisia viestintäkierroksia. - Ensimmäinen viesti johtajalta on lohkoehdotus - Toinen viesti on tuon lohkoehdotuksen laadunvalvonta - Kolmas viesti on QC edellisestä QC:stä (eli QC-on-QC) - ja niin edelleen Jos menettely keskeytetään milloin tahansa ennen lopullisuutta, lohkoa ei voida viimeistellä ja se hylätään; Kyseisen lohkon tapahtumat on sisällytettävä uudelleen seuraavaan lohkoon. Alkuperäisessä HotStuff-protokollassa ei ole putkilinjausta, ja siinä on 3 viestintäkierrosta ennen lopullisuutta; Sama validoija toimii johtajana jokaisella kierroksella. --- Pipelined HotStuff: Uusi lohko jokaisessa paikassa lisää tehokkuutta Putkilinjaus on se, mitä me kaikki teemme intuitiivisesti, kun meillä on kaksi koneellista pyykkiä suoritettavana. Sen sijaan, että odottaisimme kuorman 1 lopettavan koko syklin ennen kuorman 2 aloittamista, putkilinjauksessa laitamme kuorman 1 kuivausrumpuun samaan aikaan, kun kuorma 2 menee pesukoneeseen. Voit ajatella alkuperäistä HotStuffia naiivina lähestymistapana pyykinpesuun (älä aloita kuormalla 2 ennen kuin kuorma 1 on täysin valmis), kun taas Pipelined HotStuff tekee intuitiivisen käyttäytymisen etenemällä useita pyykkimääriä porrastetusti. Pipelined HotStuffissa porrastamme ehdotuksia siten, että jokaisella kierroksella ehdotetaan uutta lohkoa, ja uusi lohko on edellisen lohkon laadunvalvontaa sisältävän viestin päällä. Lohkoehdotukset marssivat kohti lopullisuutta useiden kierrosten aikana. Putkilinjauksen edut ovat merkittävät. Putkilinjaus lisää lohkoehdotusten tiheyttä, koska lohkoehdotus tehdään jokaiseen paikkaan, mikä lisää suorituskykyä ja lyhentää lopullisuuteen kuluvaa aikaa. Putkilinjauksessa on kuitenkin yksi suuri haittapuoli, jota havainnollistaa parhaiten esimerkillä. Oletetaan, että lohkojen N, N+1 ja N+2 johtajat ovat Alice, Bob ja Charlie. Jos Bob jättää paikkansa väliin, myös Alicen ehdotus mitätöidään, koska Bobin viesti sisältää sekä hänen ehdotuksensa että QC:n Alicen ehdotukselle. Kun näin tapahtuu, Charlieta pyydetään tuottamaan lohko ikään kuin Alicen ehdotusta ei olisi koskaan ollut olemassa. Kutsumme tätä käyttäytymistä "hännän haarautumiseksi", ja sitä voidaan ajatella syvyyden 1 mini-uudelleenjärjestelynä. Hännän haarautumisen mahdollisuudella on merkittäviä seurauksia, koska menetetyt kolikkopelit eivät välttämättä ole sattumaa. Jos on mahdollisuus saada arvoa louhimalla Alicen lohko uudelleen samalla kun he järjestävät uudelleen tai jättävät pois osan transaktioista, Bob ja Charlie voivat tehdä salaisen yhteistyön, jotta Bob jättää tarkoituksella väliin, jolloin Charlie voi louhia Alicen lohkon uudelleen. Tämä on ollut merkittävä haittapuoli Pipelined HotStuff -protokollissa (joista osa on nykyään pääverkossa). --- MonadBFT muuttaa tätä MonadBFT on ensimmäinen protokolla, joka mahdollistaa putkilinjauksen ja tekee algoritmista häntähaarukan kestävän. Tämä häntähaarukan vastus johtuu varamenettelystä, kun Bob menettää paikkansa, jonka avulla validoijat voivat koota yhteen kollektiivisen tietämyksensä Alicen ehdotuksesta ja sen konsensuksen tasosta validaattorijoukossa. Erityisesti MonadBFT:ssä, jos Bob jättää paikkansa väliin, varamenettelyssä validoijat kommunikoivat keskenään allekirjoitetuilla todistuksilla, joissa kerrotaan, näkivätkö he Alicen lohkon. Jos ylivoimainen enemmistö todistaa Alicen lohkon, Charlien on pakko ehdottaa Alicen blokkia uudelleen. Jos Charlie haluaa ehdottaa toista lohkoa, hänen on toimitettava allekirjoitettu todistus useimmilta validoijilta, jotka todistavat, ettei hän nähnyt Alicen estoa ajoissa. Tyypillisessä tapauksessa, jossa Charlie ehdottaa uudelleen Alicen blokkia, hän saa sitten ehdottaa blokkiaan seuraavalla kierroksella. Tuloksena on kaksi tärkeää ominaisuutta: hännän haarautumisvastus ja spekulatiivinen yhden paikan lopullisuus. Olemme jo puhuneet hännän haarautumisresistenssistä, mutta ymmärretään sen vaikutus lopullisuuteen. Kuten aiemminkin, oletetaan, että lohkojen N, N+1 ja N+2 johtajat ovat Alice, Bob ja Charlie. Pipelined 2-Phase HotStuffissa - eli ennen MonadBFT:tä - validaattorina (tai kokonaisena solmuna) et voi viimeistellä Alicen lohkoehdotusta ennen kuin näet Charlien lohkoehdotuksen. Miksi? Koska jos viimeistelet heti kun näet Bobin ehdotuksen, on mahdollista, että Bob sotkee kanssasi välittämällä VAIN ehdotuksensa sinulle, ja hän itse asiassa aikoo jättää ehdotuksensa lähettämättä kaikille muille, jolloin hän menettää paikkansa. Mutta MonadBFT:ssä, heti kun näet Bobin ehdotuksen, voit "spekulatiivisesti" viimeistellä Alicen ehdotuksen, koska Bobin ehdotus sisältää QC:n Alicen ehdotuksesta, mikä on todiste siitä, että 2/3 verkostosta todisti Alicen ehdotuksen. Vaikka Bob sotkee kanssasi lähettämällä VAIN ehdotuksensa sinulle, ja päätyy menettämään paikkansa, tiedät, että verkon superenemmistö näki Alicen ehdotuksen ja kun he osallistuvat varamenettelyyn, he allekirjoittavat Alicen ehdotuksen uudelleen. Ainoa tapa, jolla Alicen estoa ei viimeistellä, on se, että validoijat epäilevät ja allekirjoittavat sanomalla, etteivät he nähneet Alicen viestiä. Tämä vika on helposti todistettavissa - olemme allekirjoittaneet heiltä ristiriitaisia viestejä. Jos rangaistus epäselvyydestä on huomattava - ja sen pitäisi olla - tämä "spekulatiivinen" lopullisuus ei itse asiassa ole kovin spekulatiivinen. --- Takeawayt MonadBFT on erittäin jännittävä kehitys konsensuksen kannalta, ja se on arvokas täydennys muille Monadin yhdistäville parannuksille, mukaan lukien Asynchronous Execution, Optimistic Parallel Execution ja MonadDb. Suuret onnittelut @MohammadMJalal1 ja @KushalBabel tästä merkittävästä läpimurrosta. MonadBFT otetaan pian käyttöön Monad Testnetissä, joka toteuttaa tällä hetkellä Pipelined 2-Phase HotStuffia. Lue lisää linkitetystä blogikirjoituksesta ja artikkelista seuraavassa twiitissä.