Samenvatting van de doorbraak in MonadBFT Gisteren heeft Category Labs de MonadBFT-paper uitgebracht, waarin het consensusmechanisme wordt beschreven dat Monad op het mainnet zal aandrijven. MonadBFT is een belangrijke ontwikkeling in consensusonderzoek, aangezien het de eerste keer is dat Pipelined HotStuff resistent wordt tegen tail-forking. Tail-forking treedt op wanneer een gemist slot ervoor zorgt dat het vorige voorstel wordt weggegooid en opnieuw wordt gemined. Het is een ernstig probleem in eerdere Pipelined HotStuff-formuleringen, omdat het multi-block MEV-aanvallen opent die de consensus destabiliseren. Het verlichten van dit probleem is een groot probleem, omdat het ons alle voordelen van Pipelined HotStuff biedt - frequente blokken, lage latentie, grote validatorsets - terwijl het grootste nadeel wordt vermeden. MonadBFT biedt ook een enorme upgrade voor finaliteit. Het beschikt over speculatieve finaliteit met één slot (500 ms) en harde finaliteit met twee slots (1s). "Speculatieve finaliteit" betekent "finaliteit die alleen zal terugkeren in het geval van dubbelzinnigheid (dubbele ondertekening) door een meerderheid van de validators". Dubbelzinnigheid is een groot misdrijf in de meeste blockchain-systemen en wordt vaak bestraft met snijden; Hoe groter de straf voor dubbelzinnigheid, hoe dichter je bij de finaliteit kunt denken van "speculatieve finaliteit". Speculatieve finaliteit met één slot is een enorme ontgrendeling voor krachtige applicaties, die vol vertrouwen de bijgewerkte toestand van de wereld kunnen weergeven onmiddellijk nadat het volgende blok is ontvangen. Deze eigenschappen maken MonadBFT tot een enorme vooruitgang in consensus en een waardige aanvulling op andere samengestelde verbeteringen in Monad, waaronder asynchrone uitvoering, optimistische parallelle uitvoering en MonadDb. De rest van dit artikel dient als een samenvatting van hoe opeenvolgende verbeteringen in HotStuff op elkaar hebben voortgebouwd, om het probleem uit te leggen dat MonadBFT oplost. Samenvattend: 1. HotStuff geeft ons lineaire communicatiecomplexiteit zodat we grote validatorsets kunnen hebben, maar het is niet erg efficiënt 2. Pipelined HotStuff geeft ons efficiëntie en lage latentie door het voorstellen van blokken voor elk slot, maar lijdt aan het probleem van tail forks 3. MonadBFT geeft ons achtervorkweerstand en speculatieve finaliteit met één slot --- HotStuff: Lineaire communicatiecomplexiteit maakt grote aantallen knooppunten mogelijk HotStuff-algoritmen worden voltooid in de loop van verschillende communicatierondes, die over het algemeen de vorm aannemen van "fan out, fan in"-communicatie rechtstreeks van leiders naar validators terug naar leiders. Elke ronde begint met de leider die een bericht rechtstreeks naar andere validators stuurt, die elk een ondertekend bericht terugsturen waarin wordt bevestigd dat ze het bericht hebben ontvangen. Op voorwaarde dat een supermeerderheid (2/3) van de validators een attest terugstuurt, eindigt elke ronde met de leider die de ondertekende attesten samenvoegt tot een quorumcertificaat (QC), dat dient als bewijs dat de supermeerderheid het vorige bericht heeft bevestigd. HotStuff-algoritmen hebben meerdere communicatierondes zoals deze. - Het eerste bericht van de leider is een blokvoorstel - Het tweede bericht is de QC voor dat blokvoorstel - Het derde bericht is een QC over de vorige QC (d.w.z. een QC-op-QC) - enzovoort Als de procedure op enig moment vóór de finaliteit wordt onderbroken, wordt de blokkering niet afgerond en wordt deze weggegooid; Transacties uit dat blok zullen opnieuw moeten worden opgenomen in het volgende blok. Het originele HotStuff-protocol heeft geen pipelining en heeft 3 communicatierondes voordat het definitief wordt; Dezelfde validator speelt voor elke ronde de rol van leider. --- Pipelined HotStuff: Een nieuw blok elke slot verhoogt de efficiëntie Pipelining is wat we allemaal intuïtief doen als we twee wasbeurten moeten doen. In plaats van te wachten tot belasting 1 de volledige cyclus heeft voltooid voordat belasting 2 wordt gestart, plaatsen we in pipelining belasting 1 in de droger op hetzelfde moment dat belasting 2 in de wasmachine gaat. Je kunt de originele HotStuff zien als die naïeve benadering van het doen van de was (begin niet met lading 2 totdat lading 1 helemaal klaar is), terwijl Pipelined HotStuff het intuïtieve gedrag vertoont van het gespreid uitvoeren van meerdere wasbeurten. In Pipelined HotStuff spreiden we voorstellen, zodat er bij elke ronde een nieuw blok wordt voorgesteld, waarbij het nieuwe blok meelift bovenop het bericht met de QC van het vorige blok. Blokvoorstellen marcheren in de loop van meerdere rondes naar finaliteit. De voordelen van pipelining zijn aanzienlijk. Pipelining verhoogt de dichtheid van blokvoorstellen, omdat in elk slot een blokvoorstel wordt gedaan, wat de doorvoer verhoogt en de time-to-finality verlaagt. Er is echter één groot nadeel van pipelining, dat het best kan worden geïllustreerd met een voorbeeld. Stel dat de leiders voor de blokken N, N+1 en N+2 Alice, Bob en Charlie zijn. Als Bob zijn plaats mist, wordt het voorstel van Alice ook ongeldig verklaard, omdat het bericht van Bob zowel zijn voorstel als een QC voor het voorstel van Alice bevat. Wanneer dit gebeurt, wordt Charlie uiteindelijk opgeroepen om een blok te maken alsof Alice's voorstel nooit heeft bestaan. We noemen dit gedrag "tail-forking", en het kan worden gezien als een mini-reorganisatie van diepte 1. De mogelijkheid van tail-forking heeft aanzienlijke gevolgen, omdat gemiste slots niet per se per ongeluk zijn. Als er een mogelijkheid is om waarde te extraheren door Alice's blok opnieuw te minen terwijl je een aantal transacties opnieuw ordent of weglaat, dan kunnen Bob en Charlie samenspannen om Bob opzettelijk zijn slot te laten missen, waardoor Charlie de kans krijgt om Alice's blok opnieuw te minen. Dit is een belangrijk nadeel geweest van Pipelined HotStuff-protocollen (waarvan sommige tegenwoordig in het mainnet zitten). --- MonadBFT brengt hier verandering in MonadBFT is het eerste protocol dat pipelining mogelijk maakt en tegelijkertijd het algoritme vorkbestendig maakt. Deze tail fork-weerstand komt voort uit de terugvalprocedure wanneer Bob zijn slot mist, waardoor validators hun collectieve kennis van Alice's voorstel en het niveau van consensus binnen de validatorset kunnen samenvoegen. In het bijzonder, onder MonadBFT, als Bob zijn slot mist, zorgt de terugvalprocedure ervoor dat validators met elkaar communiceren met ondertekende attesten waarin staat of ze Alice's blok hebben gezien. Als de supermeerderheid getuigt van het blok van Alice, dan wordt Charlie gedwongen om het blok van Alice opnieuw voor te stellen. Als Charlie een ander blok wil voorstellen, moet hij een ondertekend attest overleggen van de meerderheid van de validators waaruit blijkt dat hij het blok van Alice niet op tijd heeft gezien. In het typische geval waarin Charlie Alice's blok opnieuw voorstelt, mag hij zijn blok in de volgende ronde voorstellen. Het resultaat zijn twee belangrijke eigenschappen: tail-forking weerstand en speculatieve single slot finaliteit. We hebben het al gehad over tail-forking weerstand, maar laten we de impact op de finaliteit begrijpen. Ga er net als eerder van uit dat de leiders voor de blokken N, N+1 en N+2 Alice, Bob en Charlie zijn. Onder Pipelined 2-Phase HotStuff - d.w.z. vóór MonadBFT - als een validator (of een full node), kun je het blokvoorstel van Alice niet afronden totdat je Charlie's blokvoorstel ziet. Waarom? Want als je het voorstel van Bob afrondt zodra je het voorstel van Bob ziet, is het mogelijk dat Bob met je rotzooit door ALLEEN zijn voorstel naar jou door te sturen, en hij is eigenlijk van plan zijn voorstel niet naar iedereen te sturen, waardoor hij zijn slot mist. Maar in MonadBFT, zodra je het voorstel van Bob ziet, kun je het voorstel van Alice "speculatief" afronden, omdat het voorstel van Bob een QC bevat over het voorstel van Alice, wat het bewijs is dat 2/3 van het netwerk het voorstel van Alice bevestigde. Zelfs als Bob met je rotzooit door ALLEEN zijn voorstel naar jou door te sturen, en uiteindelijk zijn slot zal missen, weet je dat een overgrote meerderheid van het netwerk het voorstel van Alice heeft gezien en, wanneer ze deelnemen aan de terugvalprocedure, het voorstel van Alice opnieuw zal ondertekenen. De enige manier waarop Alice's blok niet wordt afgerond, is als de validators dubbelzinnig zijn en ondertekenen dat ze het bericht van Alice niet hebben gezien. Deze fout is gemakkelijk te bewijzen - we hebben tegenstrijdige berichten van hen ondertekend. Als de straf voor dubbelzinnigheid substantieel is - en dat zou het moeten zijn - is deze "speculatieve" finaliteit eigenlijk niet zo speculatief. --- Afhaalrestaurants MonadBFT is een buitengewoon opwindende ontwikkeling voor consensus en is een waardige aanvulling op andere samengestelde verbeteringen in Monad, waaronder Asynchronous Execution, Optimistic Parallel Execution en MonadDb. Van harte gefeliciteerd @MohammadMJalal1 en @KushalBabel met deze belangrijke doorbraak. MonadBFT zal binnenkort worden geïmplementeerd op Monad Testnet, dat momenteel Pipelined 2-Phase HotStuff implementeert. Zie voor meer informatie de gelinkte blogpost en het artikel in de volgende tweet.